Hi, Does inclusion of parameter user=phone guarantee that the user part confirms to rfc 2806 or is it that it may confirm.
Rgds Krishna ----- Original Message ----- From: [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 2:00 pm Subject: Sip-implementors Digest, Vol 12, Issue 27 > Send Sip-implementors mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. RE: Doubt on CPC parameter (Brett Tate) > 2. Re: Doubt on CPC parameter (Paul Kyzivat) > 3. Re: Doubt on CPC parameter (Takuya Sawada) > 4. Re: Instant Message Exchange (Upaya) > > > ------------------------------------------------------------------- > --- > > Message: 1 > Date: Mon, 22 Mar 2004 12:34:05 -0500 > From: "Brett Tate" <[EMAIL PROTECTED]> > Subject: RE: [Sip-implementors] Doubt on CPC parameter > To: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > > > cpc parameter is to be defined as tel uri > > > > parameter, neither as sip uri parameter > > > > nor as any header parameter. > > > > So, I think, the correct answer is putting > > > > it in the user part of sip uri like: > > > > > > > > From: <sip:+17005554141;[EMAIL PROTECTED]>;tag=1928301774 > > > > > > > > This issue is explained in detail in the > > > > section 19.1.6, RFC 3261. > > > > > > The sip-uri parameter setting user=phone is also needed. > > > > > > <sip:+17005554141;[EMAIL PROTECTED];user=phone> > > > > > > > In my understanding, user=phone is not necessarily > > needed. Probably, it is RECOMMENDED to be put in > > sip URI when user part includes tel URI. Even without > > user parameter, user part is syntactically correct > > and can still be interpreted as E.164 number under > > the designated domain. > > > > User parameter MAY be required to be interpreted > > as E.164, depending on the policies and the > > implementations. But, I assume, the domain which > > can handle E.164 number SHOULD be able to recognize > > and, if it is possible, interpret user part as > > E.164 even without user=phone. > > The following text from RFC 3261 section 19.1.1 > hopefully clarifies emphasis level. > > "If the user string contains a telephone number > formatted as a telephone-subscriber, the user > parameter value "phone" SHOULD be present. > Even without this parameter, recipients of SIP > and SIPS URIs MAY interpret the pre-@ part as a > telephone number if local restrictions on the > name space for user name allow it." > > > > ------------------------------ > > Message: 2 > Date: Mon, 22 Mar 2004 12:56:52 -0500 > From: Paul Kyzivat <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Doubt on CPC parameter > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii; format=flowed > > The point here is that cpc is a parameter related to phone > numbers, not > general sip addresses. So while the following *could* be valid, > you > shouldn't count on it: > > From: <sip:pkyzivat;[EMAIL PROTECTED]>;tag=1928301774 > > Paul > > Brett Tate wrote: > >>>>cpc parameter is to be defined as tel uri > >>>>parameter, neither as sip uri parameter > >>>>nor as any header parameter. > >>>>So, I think, the correct answer is putting > >>>>it in the user part of sip uri like: > >>>> > >>>>From: <sip:+17005554141;[EMAIL PROTECTED]>;tag=1928301774 > >>>> > >>>>This issue is explained in detail in the > >>>>section 19.1.6, RFC 3261. > >>> > >>>The sip-uri parameter setting user=phone is also needed. > >>> > >>><sip:+17005554141;[EMAIL PROTECTED];user=phone> > >>> > >>In my understanding, user=phone is not necessarily > >>needed. Probably, it is RECOMMENDED to be put in > >>sip URI when user part includes tel URI. Even without > >>user parameter, user part is syntactically correct > >>and can still be interpreted as E.164 number under > >>the designated domain. > >> > >>User parameter MAY be required to be interpreted > >>as E.164, depending on the policies and the > >>implementations. But, I assume, the domain which > >>can handle E.164 number SHOULD be able to recognize > >>and, if it is possible, interpret user part as > >>E.164 even without user=phone. > > > > > > The following text from RFC 3261 section 19.1.1 > > hopefully clarifies emphasis level. > > > > "If the user string contains a telephone number > > formatted as a telephone-subscriber, the user > > parameter value "phone" SHOULD be present. > > Even without this parameter, recipients of SIP > > and SIPS URIs MAY interpret the pre-@ part as a > > telephone number if local restrictions on the > > name space for user name allow it." > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 23 Mar 2004 14:10:13 +0900 > From: Takuya Sawada <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Doubt on CPC parameter > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hi, > > > > > > cpc parameter is to be defined as tel uri > > > > > parameter, neither as sip uri parameter > > > > > nor as any header parameter. > > > > > So, I think, the correct answer is putting > > > > > it in the user part of sip uri like: > > > > > > > > > > From: <sip:+17005554141;[EMAIL PROTECTED]>;tag=1928301774 > > > > > > > > > > This issue is explained in detail in the > > > > > section 19.1.6, RFC 3261. > > > > > > > > The sip-uri parameter setting user=phone is also needed. > > > > > > > > <sip:+17005554141;[EMAIL PROTECTED];user=phone> > > > > > > > > > > In my understanding, user=phone is not necessarily > > > needed. Probably, it is RECOMMENDED to be put in > > > sip URI when user part includes tel URI. Even without > > > user parameter, user part is syntactically correct > > > and can still be interpreted as E.164 number under > > > the designated domain. > > > > > > User parameter MAY be required to be interpreted > > > as E.164, depending on the policies and the > > > implementations. But, I assume, the domain which > > > can handle E.164 number SHOULD be able to recognize > > > and, if it is possible, interpret user part as > > > E.164 even without user=phone. > > > > The following text from RFC 3261 section 19.1.1 > > hopefully clarifies emphasis level. > > > > "If the user string contains a telephone number > > formatted as a telephone-subscriber, the user > > parameter value "phone" SHOULD be present. > > Even without this parameter, recipients of SIP > > and SIPS URIs MAY interpret the pre-@ part as a > > telephone number if local restrictions on the > > name space for user name allow it." > > > Probably, this is what my understanding came from. > My last SHOULD may be too strong, though. > Thank you for the clarification. > > New tel URI format, currently developped in 2806bis(-05 version), > is more restricted than it is in RFC 2806. > Revised draft requires "+" sign or globally unique phone-context > parameter. This makes it easier to distinguish tel URI format from > others without help of user parameter. > > Anyway, I hope that the implementation can > - send with user=phone, if user part denotes tel URI, and > - accept even without user=phone, if configuration allows. > along with the principle; > "Be liberal in what you accept, and conservative in what you > send." > > Regards, > Takuya > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10, Iidabashi, > Chiyoda-ku, Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0286 > [EMAIL PROTECTED] > > > ------------------------------ > > Message: 4 > Date: Mon, 22 Mar 2004 21:47:29 -0800 (PST) > From: Upaya <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Instant Message Exchange > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hi Paul, > > Do you suggest that I should send some sort of hidden > INVITE at the beginning of the message session to > establish a dialog? > > Thanks, > > Wendy > > --- Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > Upaya, > > > > This is one of the reasons we are working on > > session-mode IM. Use of the > > MESSAGE message is page-mode IM. In page mode, there > > is no session, so > > in general the proxy will be involved in routing > > each message. And if > > the target has multiple UASs then each message may > > be forked. Responses > > are a bit of an issue as well - in general the best > > you can do is > > address a response to the From address in the > > request. > > > > Technically you can send MESSAGE messages within a > > dialog and so > > guarantee a consistent pair of endpoints are > > interacting, and generally > > cut the proxy out as well. (I believe this is what > > MS does.) But that is > > not recommended behavior. And because MESSAGE is not > > dialog establishing > > you need to do something else to establish the > > dialog, such as send a > > media-less invite. > > > > While not yet complete, the direction we are > > pursuing for session > > oriented IM is to send an invite with an offer for a > > message-session > > media stream. And then send the IMs via that stream > > rather than via > > MESSAGE messages. The protocol for this is still in > > progress, with the > > working name of MSRP. (Message Session Relay > > Protocol.) > > > > Paul > > > > Upaya wrote: > > > Thank you and Smith for the reply on my previous > > > message. > > > > > > I have a question regarding an IM conversation. > > > Similar to MSN Messenger and Yahoo Messenger, > > users > > > can exchange messages in one session/window. > > > > > > For example: A Short Conversation > > > > > > > > >>John wrote: Hi Mary! > > >>Mary wrote: Hello John > > >>John wrote: How are you? > > > > > > > > > Based on RFC3428, John sends the first message to > > the > > > proxy server, then the proxy server forwards the > > > message to Mary. > > > > > > What about the second and the third message? Does > > it > > > still need the proxy server to perform lookup and > > > forward? Also, all three messages above should be > > in > > > the same session, right? > > > > > > Thanks, > > > > > > Wendy > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Search - Find what you抮e looking for > > faster > > > http://search.yahoo.com > > > _______________________________________________ > > > Sip-implementors mailing list > > > [EMAIL PROTECTED] > > > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance Tax Center - File online. File on time. > http://taxes.yahoo.com/filing.html > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > End of Sip-implementors Digest, Vol 12, Issue 27 > ************************************************ > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
