Paul, Comments in line.
Dai -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 1:47 PM To: Ngo, Dai (c) Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Re: Need clarification on callerprefs Dai - thanks for responding. I have included further discussion below. Paul > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0, > sip:[EMAIL PROTECTED]; language="es"; q=0.2 > > My question is: is this a legal construction in a Contact header? > >>>>>> yes. > Normally, if there had been a prior registration of > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0 > > and a new registration was received containing > > Contact: sip:[EMAIL PROTECTED]; language="es"; q=0.2 > > then the new contact would *replace* the old one. > >>>>>> No. These are two different contacts because the language parameter > is used for matching. >Why do you say that? The callerprefs draft gives rules for matching >between the Accept-Contact and Reject-Contact in a request to a set of >Contact entries. But it says nothing about changing the matching rules >used by a registrar when processing a REGISTER request. The bis document >says >"If a SIP URI in a registration Contact header field differs from >existing registrations according to the rules in Section 2.1, it is >added to the list of registration. If it is equivalent, according to >these rules, to an existing registration, all Contact header field >parameters for this entry are updated accordingly." >In other words, the matching is on the url only. These parameters are >not url parameters, they are extension header parameters, and so should >not participate in the matching. ****** You're right. The callerprefs draft spec does not explicitly say it. It's just my interpretation. Here is the extraction from section 2 "Overview of Operation" of the callerprefs draft that I based on: "When a UA registers, it places these parameters in the Contact headers to characterize the URIs it is registering. This allows the proxy to have information about the contact addresses for a user. The parameters are also mirrored in the Contact header in a REGISTER response." And in section 5.1 "Contact, Accept-Contact and Reject-Contact Parameters" of the same draft, it says: "This specification adds the following extension parameters to the Contact header field and defines the same parameters for the Accept- Contact and Reject-Contact header fields. These parameters apply to a single URI. When used in a Contact header, they specify characteristics of the URI in the header. When used in the Accept- Contact or Reject-Contact headers, they specify rules to apply for matching URIs." It also states that the description, methods and priority parameters will not participate in the matching operation. > > 2) a REGISTER request with multiple contact entries is processed much > like multiple REGISTER requests each with a single contact entry. If two > contact entries mention the same URI, each one in turn replaces the > previous one. Only the last remains. No error occurs. > > >>>>> I think this is the current behavior. >Whose? Is this behavior conformant to the documents, or are the >documents ambiguous? **** You're correct again. My statement came as a result of the response from J. Rosenberg included as follows: From: Ngo, Dai (c) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 10, 2001 3:36 PM To: [EMAIL PROTECTED] Subject: [Simple] Preference for Individual URI >All, >In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of the >draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter, >Description parameter, and priority parameter for a contact header are NOT >used in the matching operation described in Section 6.4.1 of the same draft. >In addition, the contact URI comparison is based on SIP URI matching >rules. >This implies that in the following example described in the draft-ietf-simple- >presence-01.txt, the second contact: ><sip:[EMAIL PROTECTED]>;methods="SUBSCRIBE" will completely *REPLACE* the >first contact: <sip:[EMAIL PROTECTED]>;methods=MESSAGE;description="open" due >to the fact that the contact URI <sip:[EMAIL PROTECTED]> is the same >for >both: > REGISTER sip:example.com SIP/2.0 > Via: SIP/2.0/UDP pua.example.com:5060 > To: <sip:[EMAIL PROTECTED]> > From: <sip:[EMAIL PROTECTED]> > Call-ID: [EMAIL PROTECTED] > CSeq: 1 REGISTER > Contact: <sip:[EMAIL PROTECTED]>;methods="MESSAGE" > ;description="open" > Contact: <sip:[EMAIL PROTECTED]>;methods="SUBSCRIBE" > Expires: 600 Excellent observation. You are correct. > >So if I'm login into a computer and have one SIP URI <sip:[EMAIL PROTECTED]>, >the only choice I have is to send a REGISTER with: > contact: <sip:[EMAIL PROTECTED]>;methods="MESSAGE, >SUBSCRIBE";description="open". Yes. > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
