From exim@www1.ietf.org Tue Sep 2 08:26:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16438 for ; Tue, 2 Sep 2003 08:26:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5vX-0005KO-Jl for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 03:50:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h827oBQI020473 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 03:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4ug-0003un-Ni; Tue, 02 Sep 2003 02:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Rf-0003e0-DG for sip@optimus.ietf.org; Mon, 01 Sep 2003 23:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05578 for ; Mon, 1 Sep 2003 23:02:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1RZ-00069V-00 for sip@ietf.org; Mon, 01 Sep 2003 23:02:58 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19tkJX-0004Jz-00 for sip@ietf.org; Mon, 01 Sep 2003 04:45:32 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h818jUB21196 for ; Mon, 1 Sep 2003 11:45:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Sep 2003 11:45:30 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 11:45:30 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 11:45:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 1 Sep 2003 11:45:29 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797039@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNuplV9EORUnVTvQ4W83+vZu18RSABvgWLw To: , , Cc: , X-OriginalArrivalTime: 01 Sep 2003 08:45:29.0942 (UTC) FILETIME=[65DBD760:01C37065] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable So, I'll ask the question again, this time for real: Under the informative text in 2806bis labeled "A Use of "tel" URIs with = SIP (Informative)", it says: " 2. The outbound proxy does not use the same phone context, but can route to a proxy that handles this phone context. This routing can be done via a lookup table or the domain name of the phone context might be set up to reflect the SIP domain name of a suitable proxy. For example, a proxy may always route calls with tel URIs like tel:1234;phone-context=3Dmunich.example.com to the SIP proxy located at munich.example.com."=20 So, how does the proxy route this message to munich.example.com? Or how = does it discover the proxy at munich.example.com? The reason I'm asking this again is due to my proposal in earlier emails = to use a tel URI for dial strings and sip URI for pure sip users. Is there something wrong with mandating that if an entity placed a = tel-URI in a sip request along with a phone-context carrying a domain = name, then that domain name must be the address of a sip proxy?=20 /Hisham > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, August 30, 2003 2:48 AM > To: Stastny Richard; Khartabil Hisham (NMP/Helsinki); Dean Willis > Cc: Brian Rosen; sip@ietf.org > Subject: Re: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > I don't know what I was thinking - I gave the wrong answer.=20 > The context in > the tel does not at mean you should attempt to route the call=20 > to there - it > is just an identifier of the namespace of who understands the number. >=20 > On 8/29/03 13:50, "Stastny Richard" wrote: >=20 > >>> So, how does the proxy route this message to munich.example.com? > >>>=20 > >>> /Hisham > >>>=20 > >>=20 > >> The same way it routes sip:fluffy@munich.example.com > >=20 > > Tell that to Dean :) He thinks it is not routable (that's=20 > the point I was > > trying to make). > >=20 > > Warning: this needs NOT to be true and IMHO this part of > > the informational section is misleading. In section 5.1.4=20 > Local numbers > > it is clearly stated: > >=20 > > "There are two ways to label the context: via a global=20 > number or any | > > number of its leading digits (e.g., "+33") and via a=20 > domain name, | > > e.g., "houston.example.com". The choice between the two is=20 > left to | > > the "owner" of the local number and is governed by whether=20 > there is a | > > global number or domain name that is a valid identifier=20 > for a | > > particular local number. > > | > > The domain name does not have to resolve to any actual=20 > host, but MUST | > > be under the administrative control of the entity managing=20 > the local | > > phone context. " > >=20 > > Since the domain name does not have to resolve to an actual host, > > one cannot rely on this, so your statement may be wrong. > >=20 > > Richard > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Gesendet: Fr 29.08.2003 17:31 > > An: fluffy@cisco.com; dean.willis@softarmor.com > > Cc: Brian.Rosen@marconi.com; sip@ietf.org > > Betreff: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Friday, August 29, 2003 5:51 PM > >> To: Khartabil Hisham (NMP/Helsinki); Dean Willis > >> Cc: Brian Rosen; sip@ietf.org > >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >>=20 > >>=20 > >> On 8/29/03 1:03, "hisham.khartabil@nokia.com" > >> > >> wrote: > >>=20 > >>> Under the informative text in 2806bis labeled "A Use of > >> "tel" URIs with SIP > >>> (Informative)", it says: > >>>=20 > >>> " > >>> 2. The outbound proxy does not use the same phone > >>> context, but can route to a proxy that=20 > handles this > >>> phone context. This routing can be done=20 > via a lookup > >>> table or the domain name of the phone > >> context might be > >>> set up to reflect the SIP domain name of=20 > a suitable > >>> proxy. For example, a proxy may always route calls > >>> with tel URIs like > >>>=20 > >>> tel:1234;phone-context=3Dmunich.example.com > >>>=20 > >>> to the SIP proxy located at munich.example.com." > >>>=20 > >>>=20 > >>> So, how does the proxy route this message to munich.example.com? > >>>=20 > >>> /Hisham > >>>=20 > >>=20 > >> The same way it routes sip:fluffy@munich.example.com > >=20 > > Tell that to Dean :) He thinks it is not routable (that's=20 > the point I was > > trying to make). > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>=20 > >>=20 > >>=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 08:56:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18994 for ; Tue, 2 Sep 2003 08:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6UN-0002aU-C2 for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 04:26:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h828QB2O009932 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 04:26:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5B0-0006cN-Ce; Tue, 02 Sep 2003 03:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1SD-0003hA-0f for sip@optimus.ietf.org; Mon, 01 Sep 2003 23:03:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05683 for ; Mon, 1 Sep 2003 23:03:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1S7-0006M2-00 for sip@ietf.org; Mon, 01 Sep 2003 23:03:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19tguw-0004Tg-00 for sip@ietf.org; Mon, 01 Sep 2003 01:07:54 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Aug 2003 22:18:45 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8157NgM019616; Sun, 31 Aug 2003 22:07:23 -0700 (PDT) Received: from [10.0.1.2] (rtp-vpn1-100.cisco.com [10.82.224.100]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHQ58953; Sun, 31 Aug 2003 22:07:20 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Aug 2003 08:55:43 -0700 Subject: Re: [Sip] Update of display name during a call From: Cullen Jennings To: Henry Chen , "Elwell, John" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well the PAI is a network asserted From. You are talking about a network asserted To. I suspect putting both in the same field with lead to problems. On 8/29/03 10:49, "Henry Chen" wrote: > > The caller's name can be authenticated and put in a PAI header by a > proxy in the initial Invite according to RFC3325. > > The problem is how to pass called party name to the call originator when > the call is forwarded by the proxy. > > Is there any problem to put called party id or display name in a PAI > header in the response to Invite by the proxy in the trusted domain > serving the call? > > Thanks, > > Henry > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, August 29, 2003 8:32 AM > To: 'Cullen Jennings'; sip@ietf.org > Subject: RE: [Sip] Update of display name during a call > > > Cullen, > > In trusted situations where P-Asserted-ID is in use, I think it would be > reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or > UPDATE. > > John (john.elwell@siemens.com) > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 August 2003 21:11 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Update of display name during a call > > > > There has been some discussion on the issues of changing the display > name associated with a call during the call. This has come up in QSIG > cases, it has come up in B2BUA cases, and in some other PBX and PSTN > interoperability issues. I think it is worth solving. > > How about this as a proposal. The UA can send an re-INVITE or UPDATE (as > appropriate) with an AIB. The AIB can be authenticated in the normal > way. The From and To inside the AIB can have a modified display name. > The tag will not be changed. If a 2543 device receives one of these > message, it may end up ignoring it but it will not cause harm. If a > device that receives one of these and understands it, it SHOULD update > the display name information. This can happen both from callee to caller > and caller to callee. The AIB might have a PAI in it too. > > Section 12.2.1.1 of 3261 says > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. > > Clearly this is in line with that. > > AIBs are about identity and solve some of the complex issues of third > parties asserting identity on behalf of others. I think this is a good > place to deal with issues that is about the displayed identity. > > Thoughts? Issues with this? Better Ideas... > > Thanks, Cullen > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 09:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22168 for ; Tue, 2 Sep 2003 09:29:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u84I-0006F8-E4 for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 06:07:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82A7Lvh023920 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 06:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4tB-0003eW-VI; Tue, 02 Sep 2003 02:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Cg-00028X-4v for sip@optimus.ietf.org; Mon, 01 Sep 2003 22:47:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00622 for ; Mon, 1 Sep 2003 22:47:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1Cb-0001qF-00 for sip@ietf.org; Mon, 01 Sep 2003 22:47:29 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19tqqY-00063t-00 for sip@ietf.org; Mon, 01 Sep 2003 11:44:02 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HKJ00E01KZ577@siemenscomms.co.uk> for sip@ietf.org; Mon, 01 Sep 2003 16:42:41 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HKJ00DKDKZ4RR@siemenscomms.co.uk>; Mon, 01 Sep 2003 16:42:40 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 01 Sep 2003 16:43:29 +0100 Content-return: allowed Date: Mon, 01 Sep 2003 16:38:21 +0100 From: "Elwell, John" Subject: RE: [Sip] Update of display name during a call To: "'Cullen Jennings'" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266761FCA9@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Cullen, See [JRE] in-line. John (john.elwell@siemens.com) -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: 29 August 2003 16:26 To: Elwell, John; sip@ietf.org Subject: Re: [Sip] Update of display name during a call I did think about using the PAI header and it seemed to have some problems. One is that it is only usable in walled gardens and it would be nice to have a more generic solution than that but ignoring this, there are other problems too. [JRE] I am not opposing the more generic solution. I would just like to see PAI allowed for display update during a call in scenarios where PAI is used. Consider a call that passes through two trust different trust domains. The first trust domain MUST remove the PAI before it passes it to the second. Even if it did not remove it, the second MUST ignore it. Even if both domains failed to do this, the information being passed in the PAI is a network assertion of identity inside a single trust domain and may not correspond at all to the display information. For example, a trust domain might decide to use their billing identifier for the subscriber in the PAI. [JRE] You seem to be suggesting that PAI is not (necessarily) for an identity that is to be displayed. However, section 8 of RFC3325 states "Typically, a user agent renders the value of a P-Asserted-Identity header field that it receives to its user." This suggests that PAI is indeed for display. I'm fine with the PAI possibly overriding that From inside a AIB in the same way that a UA today can choose to trust the PAI more than the From. I don't think that PAI really works to pass display name updates in and out of trust domains and inside a trust domain it overloads two things that may be different on to one header. Cullen On 8/29/03 6:31, "Elwell, John" wrote: > Cullen, > > In trusted situations where P-Asserted-ID is in use, I think it would be > reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or UPDATE. > > John (john.elwell@siemens.com) > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 August 2003 21:11 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Update of display name during a call > > > > There has been some discussion on the issues of changing the display name > associated with a call during the call. This has come up in QSIG cases, it > has come up in B2BUA cases, and in some other PBX and PSTN interoperability > issues. I think it is worth solving. > > How about this as a proposal. The UA can send an re-INVITE or UPDATE (as > appropriate) with an AIB. The AIB can be authenticated in the normal way. > The From and To inside the AIB can have a modified display name. The tag > will not be changed. If a 2543 device receives one of these message, it may > end up ignoring it but it will not cause harm. If a device that receives one > of these and understands it, it SHOULD update the display name information. > This can happen both from callee to caller and caller to callee. The AIB > might have a PAI in it too. > > Section 12.2.1.1 of 3261 says > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. > > Clearly this is in line with that. > > AIBs are about identity and solve some of the complex issues of third > parties asserting identity on behalf of others. I think this is a good place > to deal with issues that is about the displayed identity. > > Thoughts? Issues with this? Better Ideas... > > Thanks, Cullen > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 09:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24536 for ; Tue, 2 Sep 2003 09:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u9BN-0007P9-4Y for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 07:18:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82BIjrL028457 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 07:18:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4zP-0004rg-Ot; Tue, 02 Sep 2003 02:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u23t-0007r5-B6 for sip@optimus.ietf.org; Mon, 01 Sep 2003 23:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14472 for ; Mon, 1 Sep 2003 23:42:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u235-0007YI-00 for sip@ietf.org; Mon, 01 Sep 2003 23:41:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19u215-0007L2-00 for sip@ietf.org; Mon, 01 Sep 2003 23:39:39 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2003 20:39:13 -0700 Received: from amer.unity.cisco.com (ipcbu-exchange.cisco.com [64.101.140.91]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h823dAi1017590; Mon, 1 Sep 2003 20:39:11 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] Update of display name during a call Date: Mon, 1 Sep 2003 22:39:09 -0500 Message-ID: Thread-Topic: [Sip] Update of display name during a call Thread-Index: AcNwRvFPNZq4Xk2eRWKOU5a8k3F5HAAvEnbg From: "Henry Chen" To: "Cullen Jennings" , "Elwell, John" , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Not really since a UA only expect to receive PAI, called party receives it in a request and calling party receives it in the response.=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Sunday, August 31, 2003 10:56 AM To: Henry Chen; Elwell, John; sip@ietf.org Subject: Re: [Sip] Update of display name during a call Well the PAI is a network asserted From. You are talking about a network asserted To. I suspect putting both in the same field with lead to problems. On 8/29/03 10:49, "Henry Chen" wrote: >=20 > The caller's name can be authenticated and put in a PAI header by a=20 > proxy in the initial Invite according to RFC3325. >=20 > The problem is how to pass called party name to the call originator=20 > when the call is forwarded by the proxy. >=20 > Is there any problem to put called party id or display name in a PAI=20 > header in the response to Invite by the proxy in the trusted domain=20 > serving the call? >=20 > Thanks, >=20 > Henry >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, August 29, 2003 8:32 AM > To: 'Cullen Jennings'; sip@ietf.org > Subject: RE: [Sip] Update of display name during a call >=20 >=20 > Cullen, >=20 > In trusted situations where P-Asserted-ID is in use, I think it would=20 > be reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or > UPDATE. >=20 > John (john.elwell@siemens.com) >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 August 2003 21:11 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Update of display name during a call >=20 >=20 >=20 > There has been some discussion on the issues of changing the display=20 > name associated with a call during the call. This has come up in QSIG=20 > cases, it has come up in B2BUA cases, and in some other PBX and PSTN=20 > interoperability issues. I think it is worth solving. >=20 > How about this as a proposal. The UA can send an re-INVITE or UPDATE=20 > (as > appropriate) with an AIB. The AIB can be authenticated in the normal > way. The From and To inside the AIB can have a modified display name. > The tag will not be changed. If a 2543 device receives one of these > message, it may end up ignoring it but it will not cause harm. If a > device that receives one of these and understands it, it SHOULD update > the display name information. This can happen both from callee to caller > and caller to callee. The AIB might have a PAI in it too. >=20 > Section 12.2.1.1 of 3261 says > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. >=20 > Clearly this is in line with that. >=20 > AIBs are about identity and solve some of the complex issues of third=20 > parties asserting identity on behalf of others. I think this is a good > place to deal with issues that is about the displayed identity. >=20 > Thoughts? Issues with this? Better Ideas... >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 09:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24818 for ; Tue, 2 Sep 2003 09:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u69G-0007bg-1I for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 04:04:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8284Lib029234 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 04:04:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u58O-0006Ha-Q8; Tue, 02 Sep 2003 02:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Pf-0003RZ-VM for sip@optimus.ietf.org; Mon, 01 Sep 2003 23:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04818 for ; Mon, 1 Sep 2003 23:00:52 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1Pa-0005Vw-00 for sip@ietf.org; Mon, 01 Sep 2003 23:00:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19tksF-0001A8-00 for sip@ietf.org; Mon, 01 Sep 2003 05:21:24 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h819LN421829 for ; Mon, 1 Sep 2003 12:21:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Sep 2003 12:21:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:21:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 1 Sep 2003 12:21:22 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179703B@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNuplV9EORUnVTvQ4W83+vZu18RSABvgWLwAAFdMCIAABb6kA== To: , , Cc: , X-OriginalArrivalTime: 01 Sep 2003 09:21:23.0457 (UTC) FILETIME=[69742710:01C3706A] Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 U28sIHRoZSBhbnN3ZXIgaW4gYW55IGNhc2UgaXMgdGhhdCBpdCBpcyBzb21laG93IHJvdXRhYmxl LiBUaGVyZWZvcmUgSSBjb25jbHVkZSB0aGUgYWxsb3dpbmcgYSBzaXAgVVJJIHRvIGNhcnJ5IGEg ZGlhbCBzdHJpbmdzIGlzIG5vdCBuZWVkZWQuDQoNCi9IaXNoYW0NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgU3Rhc3RueSBSaWNoYXJkIFttYWlsdG86UmljaGFy ZC5TdGFzdG55QG9lZmVnLmF0XQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAwMSwgMjAwMyAx MjoyMCBQTQ0KPiBUbzogS2hhcnRhYmlsIEhpc2hhbSAoTk1QL0hlbHNpbmtpKTsgZmx1ZmZ5QGNp c2NvLmNvbTsNCj4gZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbQ0KPiBDYzogQnJpYW4uUm9zZW5A bWFyY29uaS5jb207IHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBBVzogQVc6IEFXOiBbU2lwXSBT SVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCA7dXNlcj1waG9uZQ0KPiANCj4gDQo+IFlvdSBzaG91 bGQgbm90IG5lZWQgdG8gcm91dGUgdGhpcyBjYWxsIGFueXdheSwgYmVjYXVzZSANCj4gbm9ybWFs bHkgeW91IHNob3VsZA0KPiBub3Qgc2VlIHN1Y2ggYSBjb250ZXh0IG91dCBvZiB0aGUgY29udGV4 dC4gVGhlIGlkZWEgaXM6IGlmIA0KPiB5b3Uga25vdyB0aGUgY29udGV4dA0KPiB0aGVuIHlvdSBh bHNvIGtub3cgaG93IHRvIHJvdXRlIHRoZSBjYWxsLCBpZiB5b3UgZG8gbm90IGtub3cgDQo+IHRo ZSBjb250ZXh0LA0KPiB5b3UganVzdCBzYXkgaW52YWxpZCBudW1iZXIuIEluIG90aGVyIGNvbnRl eHRzIG9ubHkgZ2xvYmFsIA0KPiB1bmRlcnN0YW5kYWJsZQ0KPiBVUklzIHNob3VsZCBiZSB1c2Vk DQo+ICANCj4gUmljaGFyZA0KPiANCj4gCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t LS0gDQo+IAlWb246IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tIA0KPiBbbWFpbHRvOmhpc2hh bS5raGFydGFiaWxAbm9raWEuY29tXSANCj4gCUdlc2VuZGV0OiBNbyAwMS4wOS4yMDAzIDEwOjQ1 IA0KPiAJQW46IGZsdWZmeUBjaXNjby5jb207IFN0YXN0bnkgUmljaGFyZDsgDQo+IGRlYW4ud2ls bGlzQHNvZnRhcm1vci5jb20gDQo+IAlDYzogQnJpYW4uUm9zZW5AbWFyY29uaS5jb207IHNpcEBp ZXRmLm9yZyANCj4gCUJldHJlZmY6IFJFOiBBVzogQVc6IFtTaXBdIFNJUElUIEludGVyb3AgcHJv YmxlbSB3aXRoIA0KPiA7dXNlcj1waG9uZQ0KPiAJDQo+IAkNCj4gDQo+IAlTbywgSSdsbCBhc2sg dGhlIHF1ZXN0aW9uIGFnYWluLCB0aGlzIHRpbWUgZm9yIHJlYWw6DQo+IAkNCj4gCVVuZGVyIHRo ZSBpbmZvcm1hdGl2ZSB0ZXh0IGluIDI4MDZiaXMgbGFiZWxlZCAiQSBVc2Ugb2YgDQo+ICJ0ZWwi IFVSSXMgd2l0aCBTSVAgKEluZm9ybWF0aXZlKSIsIGl0IHNheXM6DQo+IAkNCj4gCSINCj4gCSAg ICAgICAgICAgICAyLiAgIFRoZSBvdXRib3VuZCBwcm94eSBkb2VzIG5vdCB1c2UgdGhlIHNhbWUg cGhvbmUNCj4gCSAgICAgICAgICAgICAgICAgIGNvbnRleHQsIGJ1dCBjYW4gcm91dGUgdG8gYSBw cm94eSANCj4gdGhhdCBoYW5kbGVzIHRoaXMNCj4gCSAgICAgICAgICAgICAgICAgIHBob25lIGNv bnRleHQuIFRoaXMgcm91dGluZyBjYW4gYmUgDQo+IGRvbmUgdmlhIGEgbG9va3VwDQo+IAkgICAg ICAgICAgICAgICAgICB0YWJsZSBvciB0aGUgZG9tYWluIG5hbWUgb2YgdGhlIHBob25lIA0KPiBj b250ZXh0IG1pZ2h0IGJlDQo+IAkgICAgICAgICAgICAgICAgICBzZXQgdXAgdG8gcmVmbGVjdCB0 aGUgU0lQIGRvbWFpbiBuYW1lIA0KPiBvZiBhIHN1aXRhYmxlDQo+IAkgICAgICAgICAgICAgICAg ICBwcm94eS4gRm9yIGV4YW1wbGUsIGEgcHJveHkgbWF5IA0KPiBhbHdheXMgcm91dGUgY2FsbHMN Cj4gCSAgICAgICAgICAgICAgICAgIHdpdGggdGVsIFVSSXMgbGlrZQ0KPiAJDQo+IAkgICAgICAg ICAgICAgICAgICB0ZWw6MTIzNDtwaG9uZS1jb250ZXh0PW11bmljaC5leGFtcGxlLmNvbQ0KPiAJ DQo+IAkgICAgICAgICAgICAgICAgICB0byB0aGUgU0lQIHByb3h5IGxvY2F0ZWQgYXQgDQo+IG11 bmljaC5leGFtcGxlLmNvbS4iDQo+IAkNCj4gCQ0KPiAJU28sIGhvdyBkb2VzIHRoZSBwcm94eSBy b3V0ZSB0aGlzIG1lc3NhZ2UgdG8gDQo+IG11bmljaC5leGFtcGxlLmNvbT8gT3IgaG93IGRvZXMg aXQgZGlzY292ZXIgdGhlIHByb3h5IGF0IA0KPiBtdW5pY2guZXhhbXBsZS5jb20/DQo+IAkNCj4g CVRoZSByZWFzb24gSSdtIGFza2luZyB0aGlzIGFnYWluIGlzIGR1ZSB0byBteSBwcm9wb3NhbCAN Cj4gaW4gZWFybGllciBlbWFpbHMgdG8gdXNlIGEgdGVsIFVSSSBmb3IgZGlhbCBzdHJpbmdzIGFu ZCBzaXAgDQo+IFVSSSBmb3IgcHVyZSBzaXAgdXNlcnMuDQo+IAkNCj4gCUlzIHRoZXJlIHNvbWV0 aGluZyB3cm9uZyB3aXRoIG1hbmRhdGluZyB0aGF0IGlmIGFuIA0KPiBlbnRpdHkgcGxhY2VkIGEg dGVsLVVSSSBpbiBhIHNpcCByZXF1ZXN0IGFsb25nIHdpdGggYSANCj4gcGhvbmUtY29udGV4dCBj YXJyeWluZyBhIGRvbWFpbiBuYW1lLCB0aGVuIHRoYXQgZG9tYWluIG5hbWUgDQo+IG11c3QgYmUg dGhlIGFkZHJlc3Mgb2YgYSBzaXAgcHJveHk/DQo+IAkNCj4gCS9IaXNoYW0NCj4gCQ0KPiAJPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAJPiBGcm9tOiBleHQgQ3VsbGVuIEplbm5pbmdz IFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0NCj4gCT4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAz MCwgMjAwMyAyOjQ4IEFNDQo+IAk+IFRvOiBTdGFzdG55IFJpY2hhcmQ7IEtoYXJ0YWJpbCBIaXNo YW0gKE5NUC9IZWxzaW5raSk7IA0KPiBEZWFuIFdpbGxpcw0KPiAJPiBDYzogQnJpYW4gUm9zZW47 IHNpcEBpZXRmLm9yZw0KPiAJPiBTdWJqZWN0OiBSZTogQVc6IEFXOiBbU2lwXSBTSVBJVCBJbnRl cm9wIHByb2JsZW0gd2l0aCANCj4gO3VzZXI9cGhvbmUNCj4gCT4NCj4gCT4NCj4gCT4NCj4gCT4g SSBkb24ndCBrbm93IHdoYXQgSSB3YXMgdGhpbmtpbmcgLSBJIGdhdmUgdGhlIHdyb25nIGFuc3dl ci4NCj4gCT4gVGhlIGNvbnRleHQgaW4NCj4gCT4gdGhlIHRlbCBkb2VzIG5vdCBhdCBtZWFuIHlv dSBzaG91bGQgYXR0ZW1wdCB0byByb3V0ZSB0aGUgY2FsbA0KPiAJPiB0byB0aGVyZSAtIGl0DQo+ IAk+IGlzIGp1c3QgYW4gaWRlbnRpZmllciBvZiB0aGUgbmFtZXNwYWNlIG9mIHdobyANCj4gdW5k ZXJzdGFuZHMgdGhlIG51bWJlci4NCj4gCT4NCj4gCT4gT24gOC8yOS8wMyAxMzo1MCwgIlN0YXN0 bnkgUmljaGFyZCIgDQo+IDxSaWNoYXJkLlN0YXN0bnlAb2VmZWcuYXQ+IHdyb3RlOg0KPiAJPg0K PiAJPiA+Pj4gU28sIGhvdyBkb2VzIHRoZSBwcm94eSByb3V0ZSB0aGlzIG1lc3NhZ2UgdG8gDQo+ IG11bmljaC5leGFtcGxlLmNvbT8NCj4gCT4gPj4+DQo+IAk+ID4+PiAvSGlzaGFtDQo+IAk+ID4+ Pg0KPiAJPiA+Pg0KPiAJPiA+PiBUaGUgc2FtZSB3YXkgaXQgcm91dGVzIHNpcDpmbHVmZnlAbXVu aWNoLmV4YW1wbGUuY29tDQo+IAk+ID4NCj4gCT4gPiBUZWxsIHRoYXQgdG8gRGVhbiA6KSBIZSB0 aGlua3MgaXQgaXMgbm90IHJvdXRhYmxlICh0aGF0J3MNCj4gCT4gdGhlIHBvaW50IEkgd2FzDQo+ IAk+ID4gdHJ5aW5nIHRvIG1ha2UpLg0KPiAJPiA+DQo+IAk+ID4gV2FybmluZzogdGhpcyBuZWVk cyBOT1QgdG8gYmUgdHJ1ZSBhbmQgSU1ITyB0aGlzIHBhcnQgb2YNCj4gCT4gPiB0aGUgaW5mb3Jt YXRpb25hbCBzZWN0aW9uIGlzIG1pc2xlYWRpbmcuIEluIHNlY3Rpb24gNS4xLjQNCj4gCT4gTG9j YWwgbnVtYmVycw0KPiAJPiA+IGl0IGlzIGNsZWFybHkgc3RhdGVkOg0KPiAJPiA+DQo+IAk+ID4g IlRoZXJlIGFyZSB0d28gd2F5cyB0byBsYWJlbCB0aGUgY29udGV4dDogdmlhIGEgZ2xvYmFsDQo+ IAk+IG51bWJlciBvciBhbnkgICAgfA0KPiAJPiA+ICBudW1iZXIgb2YgaXRzIGxlYWRpbmcgZGln aXRzIChlLmcuLCAiKzMzIikgYW5kIHZpYSBhDQo+IAk+IGRvbWFpbiBuYW1lLCAgICAgIHwNCj4g CT4gPiAgZS5nLiwgImhvdXN0b24uZXhhbXBsZS5jb20iLiBUaGUgY2hvaWNlIGJldHdlZW4gdGhl IHR3byBpcw0KPiAJPiBsZWZ0IHRvICAgICB8DQo+IAk+ID4gIHRoZSAib3duZXIiIG9mIHRoZSBs b2NhbCBudW1iZXIgYW5kIGlzIGdvdmVybmVkIGJ5IHdoZXRoZXINCj4gCT4gdGhlcmUgaXMgYSAg fA0KPiAJPiA+ICBnbG9iYWwgbnVtYmVyIG9yIGRvbWFpbiBuYW1lIHRoYXQgaXMgYSB2YWxpZCBp ZGVudGlmaWVyDQo+IAk+IGZvciBhICAgICAgICAgIHwNCj4gCT4gPiAgcGFydGljdWxhciBsb2Nh bCBudW1iZXIuDQo+IAk+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+IAk+ID4gIFRoZSBkb21haW4gbmFtZSBkb2VzIG5vdCBoYXZlIHRvIHJlc29sdmUg dG8gYW55IGFjdHVhbA0KPiAJPiBob3N0LCBidXQgTVVTVCAgfA0KPiAJPiA+ICBiZSB1bmRlciB0 aGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvZiB0aGUgZW50aXR5IG1hbmFnaW5nDQo+IAk+IHRo ZSBsb2NhbCAgIHwNCj4gCT4gPiAgcGhvbmUgY29udGV4dC4gIg0KPiAJPiA+DQo+IAk+ID4gU2lu Y2UgdGhlIGRvbWFpbiBuYW1lIGRvZXMgbm90IGhhdmUgdG8gcmVzb2x2ZSB0byANCj4gYW4gYWN0 dWFsIGhvc3QsDQo+IAk+ID4gb25lIGNhbm5vdCByZWx5IG9uIHRoaXMsIHNvIHlvdXIgc3RhdGVt ZW50IG1heSBiZSB3cm9uZy4NCj4gCT4gPg0KPiAJPiA+IFJpY2hhcmQNCj4gCT4gPg0KPiAJPiA+ IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gCT4gPiBWb246IGhpc2hhbS5r aGFydGFiaWxAbm9raWEuY29tIA0KPiBbbWFpbHRvOmhpc2hhbS5raGFydGFiaWxAbm9raWEuY29t XQ0KPiAJPiA+IEdlc2VuZGV0OiBGciAyOS4wOC4yMDAzIDE3OjMxDQo+IAk+ID4gQW46IGZsdWZm eUBjaXNjby5jb207IGRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20NCj4gCT4gPiBDYzogQnJpYW4u Um9zZW5AbWFyY29uaS5jb207IHNpcEBpZXRmLm9yZw0KPiAJPiA+IEJldHJlZmY6IFJFOiBBVzog W1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggDQo+IDt1c2VyPXBob25lDQo+IAk+ID4N Cj4gCT4gPg0KPiAJPiA+DQo+IAk+ID4NCj4gCT4gPg0KPiAJPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiAJPiA+PiBGcm9tOiBleHQgQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1 ZmZ5QGNpc2NvLmNvbV0NCj4gCT4gPj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMjksIDIwMDMgNTo1 MSBQTQ0KPiAJPiA+PiBUbzogS2hhcnRhYmlsIEhpc2hhbSAoTk1QL0hlbHNpbmtpKTsgRGVhbiBX aWxsaXMNCj4gCT4gPj4gQ2M6IEJyaWFuIFJvc2VuOyBzaXBAaWV0Zi5vcmcNCj4gCT4gPj4gU3Vi amVjdDogUmU6IEFXOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCANCj4gO3VzZXI9 cGhvbmUNCj4gCT4gPj4NCj4gCT4gPj4NCj4gCT4gPj4gT24gOC8yOS8wMyAxOjAzLCAiaGlzaGFt LmtoYXJ0YWJpbEBub2tpYS5jb20iDQo+IAk+ID4+IDxoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNv bT4NCj4gCT4gPj4gd3JvdGU6DQo+IAk+ID4+DQo+IAk+ID4+PiBVbmRlciB0aGUgaW5mb3JtYXRp dmUgdGV4dCBpbiAyODA2YmlzIGxhYmVsZWQgIkEgVXNlIG9mDQo+IAk+ID4+ICJ0ZWwiIFVSSXMg d2l0aCBTSVANCj4gCT4gPj4+IChJbmZvcm1hdGl2ZSkiLCBpdCBzYXlzOg0KPiAJPiA+Pj4NCj4g CT4gPj4+ICINCj4gCT4gPj4+ICAgICAgICAgICAgMi4gICBUaGUgb3V0Ym91bmQgcHJveHkgZG9l cyBub3QgdXNlIA0KPiB0aGUgc2FtZSBwaG9uZQ0KPiAJPiA+Pj4gICAgICAgICAgICAgICAgIGNv bnRleHQsIGJ1dCBjYW4gcm91dGUgdG8gYSBwcm94eSB0aGF0DQo+IAk+IGhhbmRsZXMgdGhpcw0K PiAJPiA+Pj4gICAgICAgICAgICAgICAgIHBob25lIGNvbnRleHQuIFRoaXMgcm91dGluZyBjYW4g YmUgZG9uZQ0KPiAJPiB2aWEgYSBsb29rdXANCj4gCT4gPj4+ICAgICAgICAgICAgICAgICB0YWJs ZSBvciB0aGUgZG9tYWluIG5hbWUgb2YgdGhlIHBob25lDQo+IAk+ID4+IGNvbnRleHQgbWlnaHQg YmUNCj4gCT4gPj4+ICAgICAgICAgICAgICAgICBzZXQgdXAgdG8gcmVmbGVjdCB0aGUgU0lQIGRv bWFpbiBuYW1lIG9mDQo+IAk+IGEgc3VpdGFibGUNCj4gCT4gPj4+ICAgICAgICAgICAgICAgICBw cm94eS4gRm9yIGV4YW1wbGUsIGEgcHJveHkgbWF5IA0KPiBhbHdheXMgcm91dGUgY2FsbHMNCj4g CT4gPj4+ICAgICAgICAgICAgICAgICB3aXRoIHRlbCBVUklzIGxpa2UNCj4gCT4gPj4+DQo+IAk+ ID4+PiAgICAgICAgICAgICAgICAgdGVsOjEyMzQ7cGhvbmUtY29udGV4dD1tdW5pY2guZXhhbXBs ZS5jb20NCj4gCT4gPj4+DQo+IAk+ID4+PiAgICAgICAgICAgICAgICAgdG8gdGhlIFNJUCBwcm94 eSBsb2NhdGVkIGF0IA0KPiBtdW5pY2guZXhhbXBsZS5jb20uIg0KPiAJPiA+Pj4NCj4gCT4gPj4+ DQo+IAk+ID4+PiBTbywgaG93IGRvZXMgdGhlIHByb3h5IHJvdXRlIHRoaXMgbWVzc2FnZSB0byAN Cj4gbXVuaWNoLmV4YW1wbGUuY29tPw0KPiAJPiA+Pj4NCj4gCT4gPj4+IC9IaXNoYW0NCj4gCT4g Pj4+DQo+IAk+ID4+DQo+IAk+ID4+IFRoZSBzYW1lIHdheSBpdCByb3V0ZXMgc2lwOmZsdWZmeUBt dW5pY2guZXhhbXBsZS5jb20NCj4gCT4gPg0KPiAJPiA+IFRlbGwgdGhhdCB0byBEZWFuIDopIEhl IHRoaW5rcyBpdCBpcyBub3Qgcm91dGFibGUgKHRoYXQncw0KPiAJPiB0aGUgcG9pbnQgSSB3YXMN Cj4gCT4gPiB0cnlpbmcgdG8gbWFrZSkuDQo+IAk+ID4NCj4gCT4gPiBSZWdhcmRzLA0KPiAJPiA+ IEhpc2hhbQ0KPiAJPiA+DQo+IAk+ID4NCj4gCT4gPj4NCj4gCT4gPj4NCj4gCT4gPj4NCj4gCT4g Pg0KPiAJPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IAk+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwDQo+IAk+ID4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2Yg dGhlIGNvcmUgU0lQIFByb3RvY29sDQo+IAk+ID4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29s dW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgDQo+IG9uIGN1cnJlbnQgc2lwDQo+IAk+ID4gVXNlIHNp cHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIA0KPiBhcHBsaWNhdGlv biBvZiBzaXANCj4gCT4gPg0KPiAJPiA+DQo+IAk+DQo+IAk+DQo+IAk+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IAk+IFNpcCBtYWlsaW5nIGxpc3Qg IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KPiAJPiBUaGlzIGxp c3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gCT4g VXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gDQo+ IGN1cnJlbnQgc2lwDQo+IAk+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9uIHRoZSANCj4gYXBwbGljYXRpb24gb2Ygc2lwDQo+IAk+DQo+IAkNCj4gDQo+IA0K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 09:41:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24951 for ; Tue, 2 Sep 2003 09:41:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBG5-0008Pf-ME for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 09:31:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DVjFG032333 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 09:31:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u69z-0007pd-HJ; Tue, 02 Sep 2003 04:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1QN-0003Wb-2q for sip@optimus.ietf.org; Mon, 01 Sep 2003 23:01:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05079 for ; Mon, 1 Sep 2003 23:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1QI-0005gB-00 for sip@ietf.org; Mon, 01 Sep 2003 23:01:38 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19tkmj-00017K-00 for sip@ietf.org; Mon, 01 Sep 2003 05:15:41 -0400 content-class: urn:content-classes:message Subject: AW: AW: AW: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 1 Sep 2003 11:19:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233801@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNuplV9EORUnVTvQ4W83+vZu18RSABvgWLwAAFdMCI= From: "Stastny Richard" To: , , Cc: , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 WW91IHNob3VsZCBub3QgbmVlZCB0byByb3V0ZSB0aGlzIGNhbGwgYW55d2F5LCBiZWNhdXNlIG5v cm1hbGx5IHlvdSBzaG91bGQNCm5vdCBzZWUgc3VjaCBhIGNvbnRleHQgb3V0IG9mIHRoZSBjb250 ZXh0LiBUaGUgaWRlYSBpczogaWYgeW91IGtub3cgdGhlIGNvbnRleHQNCnRoZW4geW91IGFsc28g a25vdyBob3cgdG8gcm91dGUgdGhlIGNhbGwsIGlmIHlvdSBkbyBub3Qga25vdyB0aGUgY29udGV4 dCwNCnlvdSBqdXN0IHNheSBpbnZhbGlkIG51bWJlci4gSW4gb3RoZXIgY29udGV4dHMgb25seSBn bG9iYWwgdW5kZXJzdGFuZGFibGUNClVSSXMgc2hvdWxkIGJlIHVzZWQNCiANClJpY2hhcmQNCg0K CS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBoaXNoYW0ua2hhcnRh YmlsQG5va2lhLmNvbSBbbWFpbHRvOmhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tXSANCglHZXNl bmRldDogTW8gMDEuMDkuMjAwMyAxMDo0NSANCglBbjogZmx1ZmZ5QGNpc2NvLmNvbTsgU3Rhc3Ru eSBSaWNoYXJkOyBkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tIA0KCUNjOiBCcmlhbi5Sb3NlbkBt YXJjb25pLmNvbTsgc2lwQGlldGYub3JnIA0KCUJldHJlZmY6IFJFOiBBVzogQVc6IFtTaXBdIFNJ UElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJDQoJDQoNCglTbywgSSdsbCBh c2sgdGhlIHF1ZXN0aW9uIGFnYWluLCB0aGlzIHRpbWUgZm9yIHJlYWw6DQoJDQoJVW5kZXIgdGhl IGluZm9ybWF0aXZlIHRleHQgaW4gMjgwNmJpcyBsYWJlbGVkICJBIFVzZSBvZiAidGVsIiBVUklz IHdpdGggU0lQIChJbmZvcm1hdGl2ZSkiLCBpdCBzYXlzOg0KCQ0KCSINCgkgICAgICAgICAgICAg Mi4gICBUaGUgb3V0Ym91bmQgcHJveHkgZG9lcyBub3QgdXNlIHRoZSBzYW1lIHBob25lDQoJICAg ICAgICAgICAgICAgICAgY29udGV4dCwgYnV0IGNhbiByb3V0ZSB0byBhIHByb3h5IHRoYXQgaGFu ZGxlcyB0aGlzDQoJICAgICAgICAgICAgICAgICAgcGhvbmUgY29udGV4dC4gVGhpcyByb3V0aW5n IGNhbiBiZSBkb25lIHZpYSBhIGxvb2t1cA0KCSAgICAgICAgICAgICAgICAgIHRhYmxlIG9yIHRo ZSBkb21haW4gbmFtZSBvZiB0aGUgcGhvbmUgY29udGV4dCBtaWdodCBiZQ0KCSAgICAgICAgICAg ICAgICAgIHNldCB1cCB0byByZWZsZWN0IHRoZSBTSVAgZG9tYWluIG5hbWUgb2YgYSBzdWl0YWJs ZQ0KCSAgICAgICAgICAgICAgICAgIHByb3h5LiBGb3IgZXhhbXBsZSwgYSBwcm94eSBtYXkgYWx3 YXlzIHJvdXRlIGNhbGxzDQoJICAgICAgICAgICAgICAgICAgd2l0aCB0ZWwgVVJJcyBsaWtlDQoJ DQoJICAgICAgICAgICAgICAgICAgdGVsOjEyMzQ7cGhvbmUtY29udGV4dD1tdW5pY2guZXhhbXBs ZS5jb20NCgkNCgkgICAgICAgICAgICAgICAgICB0byB0aGUgU0lQIHByb3h5IGxvY2F0ZWQgYXQg bXVuaWNoLmV4YW1wbGUuY29tLiINCgkNCgkNCglTbywgaG93IGRvZXMgdGhlIHByb3h5IHJvdXRl IHRoaXMgbWVzc2FnZSB0byBtdW5pY2guZXhhbXBsZS5jb20/IE9yIGhvdyBkb2VzIGl0IGRpc2Nv dmVyIHRoZSBwcm94eSBhdCBtdW5pY2guZXhhbXBsZS5jb20/DQoJDQoJVGhlIHJlYXNvbiBJJ20g YXNraW5nIHRoaXMgYWdhaW4gaXMgZHVlIHRvIG15IHByb3Bvc2FsIGluIGVhcmxpZXIgZW1haWxz IHRvIHVzZSBhIHRlbCBVUkkgZm9yIGRpYWwgc3RyaW5ncyBhbmQgc2lwIFVSSSBmb3IgcHVyZSBz aXAgdXNlcnMuDQoJDQoJSXMgdGhlcmUgc29tZXRoaW5nIHdyb25nIHdpdGggbWFuZGF0aW5nIHRo YXQgaWYgYW4gZW50aXR5IHBsYWNlZCBhIHRlbC1VUkkgaW4gYSBzaXAgcmVxdWVzdCBhbG9uZyB3 aXRoIGEgcGhvbmUtY29udGV4dCBjYXJyeWluZyBhIGRvbWFpbiBuYW1lLCB0aGVuIHRoYXQgZG9t YWluIG5hbWUgbXVzdCBiZSB0aGUgYWRkcmVzcyBvZiBhIHNpcCBwcm94eT8NCgkNCgkvSGlzaGFt DQoJDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogZXh0IEN1bGxlbiBK ZW5uaW5ncyBbbWFpbHRvOmZsdWZmeUBjaXNjby5jb21dDQoJPiBTZW50OiBTYXR1cmRheSwgQXVn dXN0IDMwLCAyMDAzIDI6NDggQU0NCgk+IFRvOiBTdGFzdG55IFJpY2hhcmQ7IEtoYXJ0YWJpbCBI aXNoYW0gKE5NUC9IZWxzaW5raSk7IERlYW4gV2lsbGlzDQoJPiBDYzogQnJpYW4gUm9zZW47IHNp cEBpZXRmLm9yZw0KCT4gU3ViamVjdDogUmU6IEFXOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBw cm9ibGVtIHdpdGggO3VzZXI9cGhvbmUNCgk+DQoJPg0KCT4NCgk+IEkgZG9uJ3Qga25vdyB3aGF0 IEkgd2FzIHRoaW5raW5nIC0gSSBnYXZlIHRoZSB3cm9uZyBhbnN3ZXIuDQoJPiBUaGUgY29udGV4 dCBpbg0KCT4gdGhlIHRlbCBkb2VzIG5vdCBhdCBtZWFuIHlvdSBzaG91bGQgYXR0ZW1wdCB0byBy b3V0ZSB0aGUgY2FsbA0KCT4gdG8gdGhlcmUgLSBpdA0KCT4gaXMganVzdCBhbiBpZGVudGlmaWVy IG9mIHRoZSBuYW1lc3BhY2Ugb2Ygd2hvIHVuZGVyc3RhbmRzIHRoZSBudW1iZXIuDQoJPg0KCT4g T24gOC8yOS8wMyAxMzo1MCwgIlN0YXN0bnkgUmljaGFyZCIgPFJpY2hhcmQuU3Rhc3RueUBvZWZl Zy5hdD4gd3JvdGU6DQoJPg0KCT4gPj4+IFNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhp cyBtZXNzYWdlIHRvIG11bmljaC5leGFtcGxlLmNvbT8NCgk+ID4+Pg0KCT4gPj4+IC9IaXNoYW0N Cgk+ID4+Pg0KCT4gPj4NCgk+ID4+IFRoZSBzYW1lIHdheSBpdCByb3V0ZXMgc2lwOmZsdWZmeUBt dW5pY2guZXhhbXBsZS5jb20NCgk+ID4NCgk+ID4gVGVsbCB0aGF0IHRvIERlYW4gOikgSGUgdGhp bmtzIGl0IGlzIG5vdCByb3V0YWJsZSAodGhhdCdzDQoJPiB0aGUgcG9pbnQgSSB3YXMNCgk+ID4g dHJ5aW5nIHRvIG1ha2UpLg0KCT4gPg0KCT4gPiBXYXJuaW5nOiB0aGlzIG5lZWRzIE5PVCB0byBi ZSB0cnVlIGFuZCBJTUhPIHRoaXMgcGFydCBvZg0KCT4gPiB0aGUgaW5mb3JtYXRpb25hbCBzZWN0 aW9uIGlzIG1pc2xlYWRpbmcuIEluIHNlY3Rpb24gNS4xLjQNCgk+IExvY2FsIG51bWJlcnMNCgk+ ID4gaXQgaXMgY2xlYXJseSBzdGF0ZWQ6DQoJPiA+DQoJPiA+ICJUaGVyZSBhcmUgdHdvIHdheXMg dG8gbGFiZWwgdGhlIGNvbnRleHQ6IHZpYSBhIGdsb2JhbA0KCT4gbnVtYmVyIG9yIGFueSAgICB8 DQoJPiA+ICBudW1iZXIgb2YgaXRzIGxlYWRpbmcgZGlnaXRzIChlLmcuLCAiKzMzIikgYW5kIHZp YSBhDQoJPiBkb21haW4gbmFtZSwgICAgICB8DQoJPiA+ICBlLmcuLCAiaG91c3Rvbi5leGFtcGxl LmNvbSIuIFRoZSBjaG9pY2UgYmV0d2VlbiB0aGUgdHdvIGlzDQoJPiBsZWZ0IHRvICAgICB8DQoJ PiA+ICB0aGUgIm93bmVyIiBvZiB0aGUgbG9jYWwgbnVtYmVyIGFuZCBpcyBnb3Zlcm5lZCBieSB3 aGV0aGVyDQoJPiB0aGVyZSBpcyBhICB8DQoJPiA+ICBnbG9iYWwgbnVtYmVyIG9yIGRvbWFpbiBu YW1lIHRoYXQgaXMgYSB2YWxpZCBpZGVudGlmaWVyDQoJPiBmb3IgYSAgICAgICAgICB8DQoJPiA+ ICBwYXJ0aWN1bGFyIGxvY2FsIG51bWJlci4NCgk+ID4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQoJPiA+ICBUaGUgZG9tYWluIG5hbWUgZG9lcyBub3QgaGF2 ZSB0byByZXNvbHZlIHRvIGFueSBhY3R1YWwNCgk+IGhvc3QsIGJ1dCBNVVNUICB8DQoJPiA+ICBi ZSB1bmRlciB0aGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvZiB0aGUgZW50aXR5IG1hbmFnaW5n DQoJPiB0aGUgbG9jYWwgICB8DQoJPiA+ICBwaG9uZSBjb250ZXh0LiAiDQoJPiA+DQoJPiA+IFNp bmNlIHRoZSBkb21haW4gbmFtZSBkb2VzIG5vdCBoYXZlIHRvIHJlc29sdmUgdG8gYW4gYWN0dWFs IGhvc3QsDQoJPiA+IG9uZSBjYW5ub3QgcmVseSBvbiB0aGlzLCBzbyB5b3VyIHN0YXRlbWVudCBt YXkgYmUgd3JvbmcuDQoJPiA+DQoJPiA+IFJpY2hhcmQNCgk+ID4NCgk+ID4gLS0tLS1VcnNwcsO8 bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCT4gPiBWb246IGhpc2hhbS5raGFydGFiaWxAbm9raWEu Y29tIFttYWlsdG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dDQoJPiA+IEdlc2VuZGV0OiBG ciAyOS4wOC4yMDAzIDE3OjMxDQoJPiA+IEFuOiBmbHVmZnlAY2lzY28uY29tOyBkZWFuLndpbGxp c0Bzb2Z0YXJtb3IuY29tDQoJPiA+IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGll dGYub3JnDQoJPiA+IEJldHJlZmY6IFJFOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVt IHdpdGggO3VzZXI9cGhvbmUNCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+PiBGcm9tOiBleHQgQ3VsbGVuIEplbm5pbmdz IFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0NCgk+ID4+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI5 LCAyMDAzIDU6NTEgUE0NCgk+ID4+IFRvOiBLaGFydGFiaWwgSGlzaGFtIChOTVAvSGVsc2lua2kp OyBEZWFuIFdpbGxpcw0KCT4gPj4gQ2M6IEJyaWFuIFJvc2VuOyBzaXBAaWV0Zi5vcmcNCgk+ID4+ IFN1YmplY3Q6IFJlOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9 cGhvbmUNCgk+ID4+DQoJPiA+Pg0KCT4gPj4gT24gOC8yOS8wMyAxOjAzLCAiaGlzaGFtLmtoYXJ0 YWJpbEBub2tpYS5jb20iDQoJPiA+PiA8aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20+DQoJPiA+ PiB3cm90ZToNCgk+ID4+DQoJPiA+Pj4gVW5kZXIgdGhlIGluZm9ybWF0aXZlIHRleHQgaW4gMjgw NmJpcyBsYWJlbGVkICJBIFVzZSBvZg0KCT4gPj4gInRlbCIgVVJJcyB3aXRoIFNJUA0KCT4gPj4+ IChJbmZvcm1hdGl2ZSkiLCBpdCBzYXlzOg0KCT4gPj4+DQoJPiA+Pj4gIg0KCT4gPj4+ICAgICAg ICAgICAgMi4gICBUaGUgb3V0Ym91bmQgcHJveHkgZG9lcyBub3QgdXNlIHRoZSBzYW1lIHBob25l DQoJPiA+Pj4gICAgICAgICAgICAgICAgIGNvbnRleHQsIGJ1dCBjYW4gcm91dGUgdG8gYSBwcm94 eSB0aGF0DQoJPiBoYW5kbGVzIHRoaXMNCgk+ID4+PiAgICAgICAgICAgICAgICAgcGhvbmUgY29u dGV4dC4gVGhpcyByb3V0aW5nIGNhbiBiZSBkb25lDQoJPiB2aWEgYSBsb29rdXANCgk+ID4+PiAg ICAgICAgICAgICAgICAgdGFibGUgb3IgdGhlIGRvbWFpbiBuYW1lIG9mIHRoZSBwaG9uZQ0KCT4g Pj4gY29udGV4dCBtaWdodCBiZQ0KCT4gPj4+ICAgICAgICAgICAgICAgICBzZXQgdXAgdG8gcmVm bGVjdCB0aGUgU0lQIGRvbWFpbiBuYW1lIG9mDQoJPiBhIHN1aXRhYmxlDQoJPiA+Pj4gICAgICAg ICAgICAgICAgIHByb3h5LiBGb3IgZXhhbXBsZSwgYSBwcm94eSBtYXkgYWx3YXlzIHJvdXRlIGNh bGxzDQoJPiA+Pj4gICAgICAgICAgICAgICAgIHdpdGggdGVsIFVSSXMgbGlrZQ0KCT4gPj4+DQoJ PiA+Pj4gICAgICAgICAgICAgICAgIHRlbDoxMjM0O3Bob25lLWNvbnRleHQ9bXVuaWNoLmV4YW1w bGUuY29tDQoJPiA+Pj4NCgk+ID4+PiAgICAgICAgICAgICAgICAgdG8gdGhlIFNJUCBwcm94eSBs b2NhdGVkIGF0IG11bmljaC5leGFtcGxlLmNvbS4iDQoJPiA+Pj4NCgk+ID4+Pg0KCT4gPj4+IFNv LCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhpcyBtZXNzYWdlIHRvIG11bmljaC5leGFtcGxl LmNvbT8NCgk+ID4+Pg0KCT4gPj4+IC9IaXNoYW0NCgk+ID4+Pg0KCT4gPj4NCgk+ID4+IFRoZSBz YW1lIHdheSBpdCByb3V0ZXMgc2lwOmZsdWZmeUBtdW5pY2guZXhhbXBsZS5jb20NCgk+ID4NCgk+ ID4gVGVsbCB0aGF0IHRvIERlYW4gOikgSGUgdGhpbmtzIGl0IGlzIG5vdCByb3V0YWJsZSAodGhh dCdzDQoJPiB0aGUgcG9pbnQgSSB3YXMNCgk+ID4gdHJ5aW5nIHRvIG1ha2UpLg0KCT4gPg0KCT4g PiBSZWdhcmRzLA0KCT4gPiBIaXNoYW0NCgk+ID4NCgk+ID4NCgk+ID4+DQoJPiA+Pg0KCT4gPj4N Cgk+ID4NCgk+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCgk+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwDQoJPiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRo ZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJp YS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCT4gPiBVc2Ugc2lwcGluZ0BpZXRm Lm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoJPiA+ DQoJPiA+DQoJPg0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoJPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXANCgk+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9m IHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1i aWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCgk+IFVzZSBzaXBwaW5nQGlldGYu b3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCgk+DQoJ DQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 10:03:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27866 for ; Tue, 2 Sep 2003 10:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkd-0002e0-CX for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 10:03:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82E3JDb010109 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 10:03:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBkO-0002Xs-9X; Tue, 02 Sep 2003 10:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBk6-0002UM-Of for sip@optimus.ietf.org; Tue, 02 Sep 2003 10:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27687 for ; Tue, 2 Sep 2003 10:02:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBk2-0000xS-00 for sip@ietf.org; Tue, 02 Sep 2003 10:02:43 -0400 Received: from ns.kapsch.net ([193.154.217.100]) by ietf-mx with esmtp (Exim 4.12) id 19uBWe-0000Ki-00 for sip@ietf.org; Tue, 02 Sep 2003 09:48:52 -0400 Received: from dumbo.kapsch.co.at (dumbo.kapsch.co.at) by ns.kapsch.net (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Tue, 2 Sep 2003 15:48:17 +0200 Received: from aviese80.atc.co.at ([193.80.173.13]) by dumbo.kapsch.co.at with Microsoft SMTPSVC (5.0.2195.2966); Tue, 2 Sep 2003 15:48:16 +0200 Received: from ([193.80.84.5]) by aviese80; Tue, 02 Sep 2003 15:45:27 +0200 (MEST) Received: from aviepexs (aviepex2.atc.co.at [193.80.69.23]) Received: by aviepexs.atc.co.at with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Sep 2003 15:49:47 +0200 Message-ID: From: Kolinowitz Bernd To: "'SIP list'" Date: Tue, 2 Sep 2003 15:49:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 02 Sep 2003 13:48:16.0814 (UTC) FILETIME=[DC9244E0:01C37158] Subject: [Sip] Sending an announcement!! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi! We want to implement a typical PSTN feature in our SIP proxy. If caller A sends an INVITE (including audio in the sdp) to the sip-proxy, the proxy should send an announcement (like a jingle) to caller A while it is trying to reach the callee. We are now searching for a way to implement the feature concerning RFC 3264 (offer/answer model of SDP). First we thought to answer with early media, that means to send a 183 response including the SDP for the announcement and demanding a PRACK request. Next we have thought to forward the 200 response from the callee to the caller. Now there is our problem: What should the caller do with the SDP? The good version: He accept the SDP from the callee as an answer of his SDP offer in the first INVITE-request and sends an empty ACK. The bad version: The SDP in the 200 response will be treated as a new offer and he sends an SDP answer in the ACK request. How will the client react? Is there another way to realize this feature? Thanks in advance Bernd _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 10:57:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04571 for ; Tue, 2 Sep 2003 10:57:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCan-0007vc-Mo for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 10:57:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82EvD6k030475 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 10:57:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCac-0007tW-Oh; Tue, 02 Sep 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCZj-0007pJ-Jm for sip@optimus.ietf.org; Tue, 02 Sep 2003 10:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04103 for ; Tue, 2 Sep 2003 10:56:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCYs-0003F0-00 for sip@ietf.org; Tue, 02 Sep 2003 10:55:14 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 19uCI5-0002cE-00 for sip@ietf.org; Tue, 02 Sep 2003 10:37:53 -0400 Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h82Ebnu03899 for ; Tue, 2 Sep 2003 17:37:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 17:37:49 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 17:37:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 2 Sep 2003 17:37:47 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797058@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNxV7BUSgx6l+MXS9aYEh5/BBz63wAAsyGQ To: , , , Cc: X-OriginalArrivalTime: 02 Sep 2003 14:37:49.0163 (UTC) FILETIME=[C83ABBB0:01C3715F] Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0IFJvc2VuLCBCcmlh biBbbWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMDIsIDIwMDMgNDozOCBQTQ0KPiBUbzogS2hhcnRhYmlsIEhpc2hhbSAoTk1QL0hlbHNp bmtpKTsgUmljaGFyZC5TdGFzdG55QG9lZmVnLmF0Ow0KPiBmbHVmZnlAY2lzY28uY29tOyBkZWFu LndpbGxpc0Bzb2Z0YXJtb3IuY29tDQo+IENjOiBzaXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6 IEFXOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUNCj4g DQo+IA0KPiBHZXR0aW5nIG1vcmUgYW5kIG1vcmUgY29uZnVzZWQuDQo+IA0KPiBBICJkaWFsIHN0 cmluZyIgY2Fubm90IGdvIGluIGEgdGVsIHVyaS4NCj4gSXQgY2FuIGdvIGluIHRoZSB1c2VyIHBh cnQgb2YgYSBzaXAgdXJpLg0KPiANCj4gU28sIGlmIGEgc2lwIFVBIGRvZXMgbm90IGhhdmUgdGhl IGFiaWxpdHkgdG8gYXV0b21hdGljYWxseQ0KPiB0cmFuc2xhdGUgZGlhbCBzdHJpbmdzIHRvIHJv dXRhYmxlIHRlbGVwaG9uZSBudW1iZXJzLCBpdCBoYXMNCj4gdG8gYmUgaW4gYSBzaXAgdXJpIHVz ZXIgcGFydC4gIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcw0KPiBjb250cm92ZXJzaWFsLg0KDQpJIGNh biBoYW5kIGEgTm9raWEgY29sbGVhZ3VlIGEgYnVzaW5lc3MgY2FyZCB0aGF0IGhhcyB0aGUgZm9s bG93aW5nIGluZm86DQoNClRlbDogMDQwMTIzNDUNClNJUDogMDQwNjc4OTFAbm9raWEuY29tDQoN CkhlIGRpYWxzICszNTg0MDEyMzQ1LiBIb3cgZG9lcyB0aGUgVUEga25vdyBpZiBpdCBzaG91bGQg YXBwZW5kIEBub2tpYS5jb20gYW5kIG1ha2UgaXQgYSBzaXAgVVJJIG9yIGp1c3QgbWFrZSBpdCBh IHRlbCBVUkk/DQoNCk9wdGlvbnMgKGlmIHRoZSB1c2VyIGluZGljYXRlZCBpdHMgY2hvaWNlKQ0K LSBUaGUgZGlhbGxlZCBkaWdpdHMgcGxhY2VkIGluIGEgdGVsIFVSSSB3aXRoIGEgcGhvbmUtY29u dGV4dC4NCi0gSWYgdGhlIFVBIGRvZXMgbm90IGhhdmUgYSByb3V0aW5nIHRhYmxlIGFuZCBjYW5u b3QgcGxhY2UgYSBwaG9uZS1jb250ZXh0LCB0aGVuIGl0IG5lZWRzIHRvIHBsYWNlIHRoZSBkaWFs bGVkIGRpZ2l0cyBpbiBhIHNpcCBVUkkuIEJ1dCBJIGJlbGlldmUgaXQgc2hvdWxkIGluZGljYXRl IHRoZSB1c2VyIGFzIGEgZGlhbCBzdHJpbmcgKGFzIHlvdSBzdWdnZXN0KS4gVGhlIHJlYXNvbiBJ IHNheSBzbyBpcw0KDQpURUw6IDA0MDEyMzQ1DQpTSVA6IDA0MDEyMzQ1QG5va2lhLmNvbSAobm90 ZSBkaWdpdHMgYXJlIHRoZSBzYW1lKQ0KDQptYXkgYWN0dWFsbHkgYmUgZGlmZmVyZW50IHVzZXJz IG9uIHRoZSBzeXN0ZW0uDQoNCi0gSWYgdGhlIHVzZXIgZGlhbHMgY291bnR5IGNvZGUgYW5kIGFy ZWEgY29kZSAoMzU4NDAxMjM0NSksIHRoZSBkaWFsbGVkIGRpZ2l0cyBwbGFjZWQgaW4gYSB0ZWwg VVJJIHdpdGggbm8gcGhvbmUtY29udGV4dC4NCg0KSSBhZ3JlZSB0aGlzIGlzIHRvbyBjb21wbGlj YXRlZCBmb3IgdGhlIHVzZXIuIFNvIHdoYXQgZG8gd2UgZG8gdG8gbWFrZSBsaWZlIGVhc2llciBm b3IgdGhlIGVuZCB1c2Vycz8gU2hvdWxkIHdlIGdpdmUgdGhlIGZyZWVkb20gdG8gdGhlIHVzZXIg dG8ganVzdCBlbnRlciBkaWdpdHMgYW5kIHdlIG5lZWQgdG8gdGVjaG5pY2FsbHkgZmlndXJlIG91 dCB3aGF0IGhpcyBpbnRlbnNpb24gaXM/DQoNCg0KL0hpc2hhbQ0KDQo+IA0KPiBUaGUgcXVlc3Rp b24gaXMsIGRvZXMgdGhlIFVBIG5lZWQgdG8gbWFyayB0aGUgdXNlciBwYXJ0IGFzDQo+IGEgZGlh bCBzdHJpbmcsIG9yIGlzIGl0IGVub3VnaCBmb3IgdGhlIGhvc3QgbWVudGlvbmVkIGluIHRoZQ0K PiBkb21haW4gcGFydCBvZiB0aGUgc2lwIHVyaSB0byBqdXN0IGtub3cgdGhlIGRpZmZlcmVuY2U/ DQo+IEknZCBwcmVmZXIgdG8gbWFyayB0aGUgdXNlcnBhcnQgYXMgYSBkaWFsIHN0cmluZywgYnV0 IEkgY2FuDQo+IGNvcGUgaWYgd2UgZG9uJ3QuDQo+IA0KPiBCcmlhbg0KPiANCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29t IFttYWlsdG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMDEsIDIwMDMgNToyMSBBTQ0KPiA+IFRvOiBSaWNoYXJkLlN0YXN0bnlAb2VmZWcu YXQ7IGZsdWZmeUBjaXNjby5jb207DQo+ID4gZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbQ0KPiA+ IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGlldGYub3JnDQo+ID4gU3ViamVjdDog UkU6IEFXOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUN Cj4gPiANCj4gPiANCj4gPiBTbywgdGhlIGFuc3dlciBpbiBhbnkgY2FzZSBpcyB0aGF0IGl0IGlz IHNvbWVob3cgcm91dGFibGUuIA0KPiA+IFRoZXJlZm9yZSBJIGNvbmNsdWRlIHRoZSBhbGxvd2lu ZyBhIHNpcCBVUkkgdG8gY2FycnkgYSBkaWFsIA0KPiA+IHN0cmluZ3MgaXMgbm90IG5lZWRlZC4N Cj4gPiANCj4gPiAvSGlzaGFtDQo+ID4gDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+ID4gRnJvbTogZXh0IFN0YXN0bnkgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmQuU3Rhc3Ru eUBvZWZlZy5hdF0NCj4gPiA+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDAxLCAyMDAzIDEyOjIw IFBNDQo+ID4gPiBUbzogS2hhcnRhYmlsIEhpc2hhbSAoTk1QL0hlbHNpbmtpKTsgZmx1ZmZ5QGNp c2NvLmNvbTsNCj4gPiA+IGRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20NCj4gPiA+IENjOiBCcmlh bi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBBVzogQVc6 IEFXOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCA7dXNlcj1waG9uZQ0KPiA+ID4g DQo+ID4gPiANCj4gPiA+IFlvdSBzaG91bGQgbm90IG5lZWQgdG8gcm91dGUgdGhpcyBjYWxsIGFu eXdheSwgYmVjYXVzZSANCj4gPiA+IG5vcm1hbGx5IHlvdSBzaG91bGQNCj4gPiA+IG5vdCBzZWUg c3VjaCBhIGNvbnRleHQgb3V0IG9mIHRoZSBjb250ZXh0LiBUaGUgaWRlYSBpczogaWYgDQo+ID4g PiB5b3Uga25vdyB0aGUgY29udGV4dA0KPiA+ID4gdGhlbiB5b3UgYWxzbyBrbm93IGhvdyB0byBy b3V0ZSB0aGUgY2FsbCwgaWYgeW91IGRvIG5vdCBrbm93IA0KPiA+ID4gdGhlIGNvbnRleHQsDQo+ ID4gPiB5b3UganVzdCBzYXkgaW52YWxpZCBudW1iZXIuIEluIG90aGVyIGNvbnRleHRzIG9ubHkg Z2xvYmFsIA0KPiA+ID4gdW5kZXJzdGFuZGFibGUNCj4gPiA+IFVSSXMgc2hvdWxkIGJlIHVzZWQN Cj4gPiA+ICANCj4gPiA+IFJpY2hhcmQNCj4gPiA+IA0KPiA+ID4gCS0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0gDQo+ID4gPiAJVm9uOiBoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNv bSANCj4gPiA+IFttYWlsdG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dIA0KPiA+ID4gCUdl c2VuZGV0OiBNbyAwMS4wOS4yMDAzIDEwOjQ1IA0KPiA+ID4gCUFuOiBmbHVmZnlAY2lzY28uY29t OyBTdGFzdG55IFJpY2hhcmQ7IA0KPiA+ID4gZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbSANCj4g PiA+IAlDYzogQnJpYW4uUm9zZW5AbWFyY29uaS5jb207IHNpcEBpZXRmLm9yZyANCj4gPiA+IAlC ZXRyZWZmOiBSRTogQVc6IEFXOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCANCj4g PiA+IDt1c2VyPXBob25lDQo+ID4gPiAJDQo+ID4gPiAJDQo+ID4gPiANCj4gPiA+IAlTbywgSSds bCBhc2sgdGhlIHF1ZXN0aW9uIGFnYWluLCB0aGlzIHRpbWUgZm9yIHJlYWw6DQo+ID4gPiAJDQo+ ID4gPiAJVW5kZXIgdGhlIGluZm9ybWF0aXZlIHRleHQgaW4gMjgwNmJpcyBsYWJlbGVkICJBIFVz ZSBvZiANCj4gPiA+ICJ0ZWwiIFVSSXMgd2l0aCBTSVAgKEluZm9ybWF0aXZlKSIsIGl0IHNheXM6 DQo+ID4gPiAJDQo+ID4gPiAJIg0KPiA+ID4gCSAgICAgICAgICAgICAyLiAgIFRoZSBvdXRib3Vu ZCBwcm94eSBkb2VzIG5vdCB1c2UgdGhlIHNhbWUgcGhvbmUNCj4gPiA+IAkgICAgICAgICAgICAg ICAgICBjb250ZXh0LCBidXQgY2FuIHJvdXRlIHRvIGEgcHJveHkgDQo+ID4gPiB0aGF0IGhhbmRs ZXMgdGhpcw0KPiA+ID4gCSAgICAgICAgICAgICAgICAgIHBob25lIGNvbnRleHQuIFRoaXMgcm91 dGluZyBjYW4gYmUgDQo+ID4gPiBkb25lIHZpYSBhIGxvb2t1cA0KPiA+ID4gCSAgICAgICAgICAg ICAgICAgIHRhYmxlIG9yIHRoZSBkb21haW4gbmFtZSBvZiB0aGUgcGhvbmUgDQo+ID4gPiBjb250 ZXh0IG1pZ2h0IGJlDQo+ID4gPiAJICAgICAgICAgICAgICAgICAgc2V0IHVwIHRvIHJlZmxlY3Qg dGhlIFNJUCBkb21haW4gbmFtZSANCj4gPiA+IG9mIGEgc3VpdGFibGUNCj4gPiA+IAkgICAgICAg ICAgICAgICAgICBwcm94eS4gRm9yIGV4YW1wbGUsIGEgcHJveHkgbWF5IA0KPiA+ID4gYWx3YXlz IHJvdXRlIGNhbGxzDQo+ID4gPiAJICAgICAgICAgICAgICAgICAgd2l0aCB0ZWwgVVJJcyBsaWtl DQo+ID4gPiAJDQo+ID4gPiAJICAgICAgICAgICAgICAgICAgdGVsOjEyMzQ7cGhvbmUtY29udGV4 dD1tdW5pY2guZXhhbXBsZS5jb20NCj4gPiA+IAkNCj4gPiA+IAkgICAgICAgICAgICAgICAgICB0 byB0aGUgU0lQIHByb3h5IGxvY2F0ZWQgYXQgDQo+ID4gPiBtdW5pY2guZXhhbXBsZS5jb20uIg0K PiA+ID4gCQ0KPiA+ID4gCQ0KPiA+ID4gCVNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhp cyBtZXNzYWdlIHRvIA0KPiA+ID4gbXVuaWNoLmV4YW1wbGUuY29tPyBPciBob3cgZG9lcyBpdCBk aXNjb3ZlciB0aGUgcHJveHkgYXQgDQo+ID4gPiBtdW5pY2guZXhhbXBsZS5jb20/DQo+ID4gPiAJ DQo+ID4gPiAJVGhlIHJlYXNvbiBJJ20gYXNraW5nIHRoaXMgYWdhaW4gaXMgZHVlIHRvIG15IHBy b3Bvc2FsIA0KPiA+ID4gaW4gZWFybGllciBlbWFpbHMgdG8gdXNlIGEgdGVsIFVSSSBmb3IgZGlh bCBzdHJpbmdzIGFuZCBzaXAgDQo+ID4gPiBVUkkgZm9yIHB1cmUgc2lwIHVzZXJzLg0KPiA+ID4g CQ0KPiA+ID4gCUlzIHRoZXJlIHNvbWV0aGluZyB3cm9uZyB3aXRoIG1hbmRhdGluZyB0aGF0IGlm IGFuIA0KPiA+ID4gZW50aXR5IHBsYWNlZCBhIHRlbC1VUkkgaW4gYSBzaXAgcmVxdWVzdCBhbG9u ZyB3aXRoIGEgDQo+ID4gPiBwaG9uZS1jb250ZXh0IGNhcnJ5aW5nIGEgZG9tYWluIG5hbWUsIHRo ZW4gdGhhdCBkb21haW4gbmFtZSANCj4gPiA+IG11c3QgYmUgdGhlIGFkZHJlc3Mgb2YgYSBzaXAg cHJveHk/DQo+ID4gPiAJDQo+ID4gPiAJL0hpc2hhbQ0KPiA+ID4gCQ0KPiA+ID4gCT4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IAk+IEZyb206IGV4dCBDdWxsZW4gSmVubmluZ3Mg W21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiA+ID4gCT4gU2VudDogU2F0dXJkYXksIEF1Z3Vz dCAzMCwgMjAwMyAyOjQ4IEFNDQo+ID4gPiAJPiBUbzogU3Rhc3RueSBSaWNoYXJkOyBLaGFydGFi aWwgSGlzaGFtIChOTVAvSGVsc2lua2kpOyANCj4gPiA+IERlYW4gV2lsbGlzDQo+ID4gPiAJPiBD YzogQnJpYW4gUm9zZW47IHNpcEBpZXRmLm9yZw0KPiA+ID4gCT4gU3ViamVjdDogUmU6IEFXOiBB VzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggDQo+ID4gPiA7dXNlcj1waG9uZQ0K PiA+ID4gCT4NCj4gPiA+IAk+DQo+ID4gPiAJPg0KPiA+ID4gCT4gSSBkb24ndCBrbm93IHdoYXQg SSB3YXMgdGhpbmtpbmcgLSBJIGdhdmUgdGhlIHdyb25nIGFuc3dlci4NCj4gPiA+IAk+IFRoZSBj b250ZXh0IGluDQo+ID4gPiAJPiB0aGUgdGVsIGRvZXMgbm90IGF0IG1lYW4geW91IHNob3VsZCBh dHRlbXB0IHRvIHJvdXRlIHRoZSBjYWxsDQo+ID4gPiAJPiB0byB0aGVyZSAtIGl0DQo+ID4gPiAJ PiBpcyBqdXN0IGFuIGlkZW50aWZpZXIgb2YgdGhlIG5hbWVzcGFjZSBvZiB3aG8gDQo+ID4gPiB1 bmRlcnN0YW5kcyB0aGUgbnVtYmVyLg0KPiA+ID4gCT4NCj4gPiA+IAk+IE9uIDgvMjkvMDMgMTM6 NTAsICJTdGFzdG55IFJpY2hhcmQiIA0KPiA+ID4gPFJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdD4g d3JvdGU6DQo+ID4gPiAJPg0KPiA+ID4gCT4gPj4+IFNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91 dGUgdGhpcyBtZXNzYWdlIHRvIA0KPiA+ID4gbXVuaWNoLmV4YW1wbGUuY29tPw0KPiA+ID4gCT4g Pj4+DQo+ID4gPiAJPiA+Pj4gL0hpc2hhbQ0KPiA+ID4gCT4gPj4+DQo+ID4gPiAJPiA+Pg0KPiA+ ID4gCT4gPj4gVGhlIHNhbWUgd2F5IGl0IHJvdXRlcyBzaXA6Zmx1ZmZ5QG11bmljaC5leGFtcGxl LmNvbQ0KPiA+ID4gCT4gPg0KPiA+ID4gCT4gPiBUZWxsIHRoYXQgdG8gRGVhbiA6KSBIZSB0aGlu a3MgaXQgaXMgbm90IHJvdXRhYmxlICh0aGF0J3MNCj4gPiA+IAk+IHRoZSBwb2ludCBJIHdhcw0K PiA+ID4gCT4gPiB0cnlpbmcgdG8gbWFrZSkuDQo+ID4gPiAJPiA+DQo+ID4gPiAJPiA+IFdhcm5p bmc6IHRoaXMgbmVlZHMgTk9UIHRvIGJlIHRydWUgYW5kIElNSE8gdGhpcyBwYXJ0IG9mDQo+ID4g PiAJPiA+IHRoZSBpbmZvcm1hdGlvbmFsIHNlY3Rpb24gaXMgbWlzbGVhZGluZy4gSW4gc2VjdGlv biA1LjEuNA0KPiA+ID4gCT4gTG9jYWwgbnVtYmVycw0KPiA+ID4gCT4gPiBpdCBpcyBjbGVhcmx5 IHN0YXRlZDoNCj4gPiA+IAk+ID4NCj4gPiA+IAk+ID4gIlRoZXJlIGFyZSB0d28gd2F5cyB0byBs YWJlbCB0aGUgY29udGV4dDogdmlhIGEgZ2xvYmFsDQo+ID4gPiAJPiBudW1iZXIgb3IgYW55ICAg IHwNCj4gPiA+IAk+ID4gIG51bWJlciBvZiBpdHMgbGVhZGluZyBkaWdpdHMgKGUuZy4sICIrMzMi KSBhbmQgdmlhIGENCj4gPiA+IAk+IGRvbWFpbiBuYW1lLCAgICAgIHwNCj4gPiA+IAk+ID4gIGUu Zy4sICJob3VzdG9uLmV4YW1wbGUuY29tIi4gVGhlIGNob2ljZSBiZXR3ZWVuIHRoZSB0d28gaXMN Cj4gPiA+IAk+IGxlZnQgdG8gICAgIHwNCj4gPiA+IAk+ID4gIHRoZSAib3duZXIiIG9mIHRoZSBs b2NhbCBudW1iZXIgYW5kIGlzIGdvdmVybmVkIGJ5IHdoZXRoZXINCj4gPiA+IAk+IHRoZXJlIGlz IGEgIHwNCj4gPiA+IAk+ID4gIGdsb2JhbCBudW1iZXIgb3IgZG9tYWluIG5hbWUgdGhhdCBpcyBh IHZhbGlkIGlkZW50aWZpZXINCj4gPiA+IAk+IGZvciBhICAgICAgICAgIHwNCj4gPiA+IAk+ID4g IHBhcnRpY3VsYXIgbG9jYWwgbnVtYmVyLg0KPiA+ID4gCT4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+IAk+ID4gIFRoZSBkb21haW4gbmFtZSBk b2VzIG5vdCBoYXZlIHRvIHJlc29sdmUgdG8gYW55IGFjdHVhbA0KPiA+ID4gCT4gaG9zdCwgYnV0 IE1VU1QgIHwNCj4gPiA+IAk+ID4gIGJlIHVuZGVyIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9s IG9mIHRoZSBlbnRpdHkgbWFuYWdpbmcNCj4gPiA+IAk+IHRoZSBsb2NhbCAgIHwNCj4gPiA+IAk+ ID4gIHBob25lIGNvbnRleHQuICINCj4gPiA+IAk+ID4NCj4gPiA+IAk+ID4gU2luY2UgdGhlIGRv bWFpbiBuYW1lIGRvZXMgbm90IGhhdmUgdG8gcmVzb2x2ZSB0byANCj4gPiA+IGFuIGFjdHVhbCBo b3N0LA0KPiA+ID4gCT4gPiBvbmUgY2Fubm90IHJlbHkgb24gdGhpcywgc28geW91ciBzdGF0ZW1l bnQgbWF5IGJlIHdyb25nLg0KPiA+ID4gCT4gPg0KPiA+ID4gCT4gPiBSaWNoYXJkDQo+ID4gPiAJ PiA+DQo+ID4gPiAJPiA+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPiA+ IAk+ID4gVm9uOiBoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNvbSANCj4gPiA+IFttYWlsdG86aGlz aGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dDQo+ID4gPiAJPiA+IEdlc2VuZGV0OiBGciAyOS4wOC4y MDAzIDE3OjMxDQo+ID4gPiAJPiA+IEFuOiBmbHVmZnlAY2lzY28uY29tOyBkZWFuLndpbGxpc0Bz b2Z0YXJtb3IuY29tDQo+ID4gPiAJPiA+IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lw QGlldGYub3JnDQo+ID4gPiAJPiA+IEJldHJlZmY6IFJFOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJv cCBwcm9ibGVtIHdpdGggDQo+ID4gPiA7dXNlcj1waG9uZQ0KPiA+ID4gCT4gPg0KPiA+ID4gCT4g Pg0KPiA+ID4gCT4gPg0KPiA+ID4gCT4gPg0KPiA+ID4gCT4gPg0KPiA+ID4gCT4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IAk+ID4+IEZyb206IGV4dCBDdWxsZW4gSmVubmlu Z3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiA+ID4gCT4gPj4gU2VudDogRnJpZGF5LCBB dWd1c3QgMjksIDIwMDMgNTo1MSBQTQ0KPiA+ID4gCT4gPj4gVG86IEtoYXJ0YWJpbCBIaXNoYW0g KE5NUC9IZWxzaW5raSk7IERlYW4gV2lsbGlzDQo+ID4gPiAJPiA+PiBDYzogQnJpYW4gUm9zZW47 IHNpcEBpZXRmLm9yZw0KPiA+ID4gCT4gPj4gU3ViamVjdDogUmU6IEFXOiBbU2lwXSBTSVBJVCBJ bnRlcm9wIHByb2JsZW0gd2l0aCANCj4gPiA+IDt1c2VyPXBob25lDQo+ID4gPiAJPiA+Pg0KPiA+ ID4gCT4gPj4NCj4gPiA+IAk+ID4+IE9uIDgvMjkvMDMgMTowMywgImhpc2hhbS5raGFydGFiaWxA bm9raWEuY29tIg0KPiA+ID4gCT4gPj4gPGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tPg0KPiA+ ID4gCT4gPj4gd3JvdGU6DQo+ID4gPiAJPiA+Pg0KPiA+ID4gCT4gPj4+IFVuZGVyIHRoZSBpbmZv cm1hdGl2ZSB0ZXh0IGluIDI4MDZiaXMgbGFiZWxlZCAiQSBVc2Ugb2YNCj4gPiA+IAk+ID4+ICJ0 ZWwiIFVSSXMgd2l0aCBTSVANCj4gPiA+IAk+ID4+PiAoSW5mb3JtYXRpdmUpIiwgaXQgc2F5czoN Cj4gPiA+IAk+ID4+Pg0KPiA+ID4gCT4gPj4+ICINCj4gPiA+IAk+ID4+PiAgICAgICAgICAgIDIu ICAgVGhlIG91dGJvdW5kIHByb3h5IGRvZXMgbm90IHVzZSANCj4gPiA+IHRoZSBzYW1lIHBob25l DQo+ID4gPiAJPiA+Pj4gICAgICAgICAgICAgICAgIGNvbnRleHQsIGJ1dCBjYW4gcm91dGUgdG8g YSBwcm94eSB0aGF0DQo+ID4gPiAJPiBoYW5kbGVzIHRoaXMNCj4gPiA+IAk+ID4+PiAgICAgICAg ICAgICAgICAgcGhvbmUgY29udGV4dC4gVGhpcyByb3V0aW5nIGNhbiBiZSBkb25lDQo+ID4gPiAJ PiB2aWEgYSBsb29rdXANCj4gPiA+IAk+ID4+PiAgICAgICAgICAgICAgICAgdGFibGUgb3IgdGhl IGRvbWFpbiBuYW1lIG9mIHRoZSBwaG9uZQ0KPiA+ID4gCT4gPj4gY29udGV4dCBtaWdodCBiZQ0K PiA+ID4gCT4gPj4+ICAgICAgICAgICAgICAgICBzZXQgdXAgdG8gcmVmbGVjdCB0aGUgU0lQIGRv bWFpbiBuYW1lIG9mDQo+ID4gPiAJPiBhIHN1aXRhYmxlDQo+ID4gPiAJPiA+Pj4gICAgICAgICAg ICAgICAgIHByb3h5LiBGb3IgZXhhbXBsZSwgYSBwcm94eSBtYXkgDQo+ID4gPiBhbHdheXMgcm91 dGUgY2FsbHMNCj4gPiA+IAk+ID4+PiAgICAgICAgICAgICAgICAgd2l0aCB0ZWwgVVJJcyBsaWtl DQo+ID4gPiAJPiA+Pj4NCj4gPiA+IAk+ID4+PiAgICAgICAgICAgICAgICAgdGVsOjEyMzQ7cGhv bmUtY29udGV4dD1tdW5pY2guZXhhbXBsZS5jb20NCj4gPiA+IAk+ID4+Pg0KPiA+ID4gCT4gPj4+ ICAgICAgICAgICAgICAgICB0byB0aGUgU0lQIHByb3h5IGxvY2F0ZWQgYXQgDQo+ID4gPiBtdW5p Y2guZXhhbXBsZS5jb20uIg0KPiA+ID4gCT4gPj4+DQo+ID4gPiAJPiA+Pj4NCj4gPiA+IAk+ID4+ PiBTbywgaG93IGRvZXMgdGhlIHByb3h5IHJvdXRlIHRoaXMgbWVzc2FnZSB0byANCj4gPiA+IG11 bmljaC5leGFtcGxlLmNvbT8NCj4gPiA+IAk+ID4+Pg0KPiA+ID4gCT4gPj4+IC9IaXNoYW0NCj4g PiA+IAk+ID4+Pg0KPiA+ID4gCT4gPj4NCj4gPiA+IAk+ID4+IFRoZSBzYW1lIHdheSBpdCByb3V0 ZXMgc2lwOmZsdWZmeUBtdW5pY2guZXhhbXBsZS5jb20NCj4gPiA+IAk+ID4NCj4gPiA+IAk+ID4g VGVsbCB0aGF0IHRvIERlYW4gOikgSGUgdGhpbmtzIGl0IGlzIG5vdCByb3V0YWJsZSAodGhhdCdz DQo+ID4gPiAJPiB0aGUgcG9pbnQgSSB3YXMNCj4gPiA+IAk+ID4gdHJ5aW5nIHRvIG1ha2UpLg0K PiA+ID4gCT4gPg0KPiA+ID4gCT4gPiBSZWdhcmRzLA0KPiA+ID4gCT4gPiBIaXNoYW0NCj4gPiA+ IAk+ID4NCj4gPiA+IAk+ID4NCj4gPiA+IAk+ID4+DQo+ID4gPiAJPiA+Pg0KPiA+ID4gCT4gPj4N Cj4gPiA+IAk+ID4NCj4gPiA+IAk+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IAk+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gPiAJPiA+IFRoaXMgbGlzdCBpcyBm b3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KPiA+ID4gCT4gPiBV c2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyANCj4gPiA+ IG9uIGN1cnJlbnQgc2lwDQo+ID4gPiAJPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcg ZGV2ZWxvcG1lbnRzIG9uIHRoZSANCj4gPiA+IGFwcGxpY2F0aW9uIG9mIHNpcA0KPiA+ID4gCT4g Pg0KPiA+ID4gCT4gPg0KPiA+ID4gCT4NCj4gPiA+IAk+DQo+ID4gPiAJPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gCT4gU2lwIG1haWxpbmcg bGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gPiAJ PiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9j b2wNCj4gPiA+IAk+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVl c3Rpb25zIG9uIA0KPiA+ID4gY3VycmVudCBzaXANCj4gPiA+IAk+IFVzZSBzaXBwaW5nQGlldGYu b3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSANCj4gPiA+IGFwcGxpY2F0aW9uIG9mIHNp cA0KPiA+ID4gCT4NCj4gPiA+IAkNCj4gPiA+IA0KPiA+ID4gDQo+ID4gSipmailiCWJtPww+ID4N Cj4gMCd+ZmZYKd+jIjhiWCsfRFnXr3paKWF5K3kiDz4tJVLHrFd6e2gscm552596Ynsoy6sqVCIn fn57B15oZycXYnFieh8NCj4gPiANCj4gDQo= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 11:15:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06191 for ; Tue, 2 Sep 2003 11:15:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCsB-0000sm-Ns for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 11:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82FFB8a003332 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 11:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCs3-0000pH-7F; Tue, 02 Sep 2003 11:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCr6-0000hp-J4 for sip@optimus.ietf.org; Tue, 02 Sep 2003 11:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05587 for ; Tue, 2 Sep 2003 11:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCr5-00048c-00 for sip@ietf.org; Tue, 02 Sep 2003 11:14:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uCf2-0003gu-00 for sip@ietf.org; Tue, 02 Sep 2003 11:01:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05958; Tue, 2 Sep 2003 11:01:04 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07553; Tue, 2 Sep 2003 11:01:05 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Sep 2003 11:01:04 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DA7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com Cc: sip@ietf.org Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 2 Sep 2003 11:01:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > He dials +3584012345. How does the UA know if it should > append @nokia.com and make it a sip URI or just make it a tel URI? By definition, if the UA does not know how to translate dial strings to phone numbers, it MUST use a sip uri. There is no option to use a tel uri. I think your example not ideal only because a UA could have a trivial rule that a number starting with + is known to be a globally dialable number, and thus COULD be put in a tel uri. However, I would hope that phones did not do a lot of guessing; if they have knowledge of the local dialing plan and special dialing options, then they should interpret the dial string and do the right thing. If they don't they should put the dial string in a sip uri and let a proxy figure it out. > > Options (if the user indicated its choice) > - The dialled digits placed in a tel URI with a phone-context. This cannot work because the dial string may not be a phone number, and thus this would not be in conformance with 2806bis. > - If the UA does not have a routing table and cannot place a > phone-context, then it needs to place the dialled digits in a > sip URI. But I believe it should indicate the user as a dial > string (as you suggest). I agree. ....snip > > - If the user dials county code and area code (3584012345), > the dialled digits placed in a tel URI with no phone-context. This is only possible if the phone understands the local dialing plan. Otherwise, it is not in a position to know what a "country code" and "area code" are. whether they are present, or in fact if this string of digits is actually a phone number at all. > > I agree this is too complicated for the user. So what do we > do to make life easier for the end users? Should we give the > freedom to the user to just enter digits and we need to > technically figure out what his intension is? Either the phone does it, or a proxy does it. The mechanism isn't very complicated either way, but since it seems clear that not all phones will do it themselves, we need mechanisms in proxies to offer the service. They need a way to know that it should be invoked. It may be possible to deduce it, but I'd prefer to make it explicit. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 12:41:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13314 for ; Tue, 2 Sep 2003 12:41:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEDb-0007Lj-HB for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 12:41:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82GfN0u028246 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 12:41:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEDF-0007KK-Ki; Tue, 02 Sep 2003 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uECi-0007DC-C8 for sip@optimus.ietf.org; Tue, 02 Sep 2003 12:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13267 for ; Tue, 2 Sep 2003 12:40:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uECg-0007MF-00 for sip@ietf.org; Tue, 02 Sep 2003 12:40:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uECf-0007Lv-00 for sip@ietf.org; Tue, 02 Sep 2003 12:40:25 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2003 09:39:55 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h82GdogO015082; Tue, 2 Sep 2003 09:39:53 -0700 (PDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMF18396; Tue, 2 Sep 2003 09:39:49 -0700 (PDT) Message-ID: <3F54C7D5.3070208@cisco.com> Date: Tue, 02 Sep 2003 12:39:49 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes CC: Jean-Francois Mule , "'sip@ietf.org'" , "'rohan@cisco.com'" References: <870397D7C140C84DB081B88396458DAF578BC0@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi mary, thanks very much for your comments. jean-francios and i will address them very soon. kevin Mary Barnes wrote: > Hi all, > > Per my assignment, I've reviewed sections 7.2 and 8 through 10 of the MIB, > with the following general comments and nits. I have a few specific points > that require discussion that I'll post in separate emails to facilitate WG > discussion and hopefully to allow easier tracking of issues. I did try to > conscientiously review previous comments on the mailing list and to review > previous versions to make sure that I wasn't bringing up things for which > there had been consensus. I do apologize if I inadvertently open an issue > that was truly closed by the WG. > > - Section 7.2, page 14. The descriptions need to be updated to reflect RFC > 3261 (section 6) terminology/definitions for User Agent, Proxy Server, > Redirect Server and Registrar. > > - Section 7.2, page 15. Really minor nit, but I found it very difficult to > read the common MIB objects with no blank lines between the comment lines > and the object definitions. > > - Section 7.2, page 20. sipEntitytype. Per Cullen's comments not > separating the Proxy and Redirect Server, this would need to be reflected in > this object definition. > > - Section 8: My understanding is that this section should be removed by the > RFC Editor. Thus, I would suggest adding a comment as such (something like: > "This section to be removed by RFC Editor before publication." and moving > this section just prior to the Author's address to facilitate that process. > > - Section 9, page 109. The statement "If these objects are SET maliciously, > it may result in > incorrect or unwanted protocol operation." is probably a bit of an > understatement with regards to the timer, retry and expire values being > misconfigured. Certainly, a well designed system would but reasonable > boundaries on how these things can be configured, so as to hopefully prevent > significant problems. Cullen had brought up the more general issue of > whether all the timers should be configurable in his comments. Like Cullen, > I haven't thought about this enough to decide whether all these timers > should be configurable, but at a minimum, I think the security section > needs a more robust statement. > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > > > > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 12:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13996 for ; Tue, 2 Sep 2003 12:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEO1-0008Vn-Gy for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 12:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Gq9mg032658 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 12:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uENt-0008TM-SA; Tue, 02 Sep 2003 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uENW-0008Op-3a for sip@optimus.ietf.org; Tue, 02 Sep 2003 12:51:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13945 for ; Tue, 2 Sep 2003 12:51:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uENU-0007c1-00 for sip@ietf.org; Tue, 02 Sep 2003 12:51:36 -0400 Received: from [65.200.90.207] (helo=mail.sylantro.com) by ietf-mx with esmtp (Exim 4.12) id 19uENT-0007bH-00 for sip@ietf.org; Tue, 02 Sep 2003 12:51:35 -0400 Received: from 10.10.5.1 by mail.sylantro.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.5.3)); Tue, 02 Sep 2003 09:50:46 -0700 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 2 Sep 2003 09:49:42 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCC84@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Henry Chen'" , "Cullen Jennings" , "Elwell, John" , sip@ietf.org Subject: RE: [Sip] Update of display name during a call Date: Tue, 2 Sep 2003 09:49:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 134A15EC383-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That's exactly what we proposed in http://www.ietf.org/internet-drafts/draft-venkatar-sipping-called-name-00.tx t. regards, Venkatesh -----Original Message----- From: Henry Chen [mailto:hjlechen@cisco.com] Sent: Monday, September 01, 2003 8:39 PM To: Cullen Jennings; Elwell, John; sip@ietf.org Subject: RE: [Sip] Update of display name during a call Not really since a UA only expect to receive PAI, called party receives it in a request and calling party receives it in the response. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Sunday, August 31, 2003 10:56 AM To: Henry Chen; Elwell, John; sip@ietf.org Subject: Re: [Sip] Update of display name during a call Well the PAI is a network asserted From. You are talking about a network asserted To. I suspect putting both in the same field with lead to problems. On 8/29/03 10:49, "Henry Chen" wrote: > > The caller's name can be authenticated and put in a PAI header by a > proxy in the initial Invite according to RFC3325. > > The problem is how to pass called party name to the call originator > when the call is forwarded by the proxy. > > Is there any problem to put called party id or display name in a PAI > header in the response to Invite by the proxy in the trusted domain > serving the call? > > Thanks, > > Henry > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, August 29, 2003 8:32 AM > To: 'Cullen Jennings'; sip@ietf.org > Subject: RE: [Sip] Update of display name during a call > > > Cullen, > > In trusted situations where P-Asserted-ID is in use, I think it would > be reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or > UPDATE. > > John (john.elwell@siemens.com) > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 August 2003 21:11 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Update of display name during a call > > > > There has been some discussion on the issues of changing the display > name associated with a call during the call. This has come up in QSIG > cases, it has come up in B2BUA cases, and in some other PBX and PSTN > interoperability issues. I think it is worth solving. > > How about this as a proposal. The UA can send an re-INVITE or UPDATE > (as > appropriate) with an AIB. The AIB can be authenticated in the normal > way. The From and To inside the AIB can have a modified display name. > The tag will not be changed. If a 2543 device receives one of these > message, it may end up ignoring it but it will not cause harm. If a > device that receives one of these and understands it, it SHOULD update > the display name information. This can happen both from callee to caller > and caller to callee. The AIB might have a PAI in it too. > > Section 12.2.1.1 of 3261 says > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. > > Clearly this is in line with that. > > AIBs are about identity and solve some of the complex issues of third > parties asserting identity on behalf of others. I think this is a good > place to deal with issues that is about the displayed identity. > > Thoughts? Issues with this? Better Ideas... > > Thanks, Cullen > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 12:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14068 for ; Tue, 2 Sep 2003 12:53:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEOu-0000Jr-QK for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 12:53:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Gr4Z3001202 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 12:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEOs-0000Ip-B2; Tue, 02 Sep 2003 12:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEOK-00006Y-7c for sip@optimus.ietf.org; Tue, 02 Sep 2003 12:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13992 for ; Tue, 2 Sep 2003 12:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEOI-0007d6-00 for sip@ietf.org; Tue, 02 Sep 2003 12:52:26 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19uEOG-0007d3-00 for sip@ietf.org; Tue, 02 Sep 2003 12:52:25 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19uENp-0000H4-00; Tue, 02 Sep 2003 19:51:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16212.51884.997759.415195@harjus.tutpro.com> Date: Tue, 2 Sep 2003 19:51:56 +0300 To: hisham.khartabil@nokia.com Cc: , , , , Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797058@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797058@esebe019.ntc.nokia.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com writes: > I can hand a Nokia colleague a business card that has the following info: > > Tel: 04012345 > SIP: 04067891@nokia.com > > He dials +3584012345. How does the UA know if it should append > @nokia.com and make it a sip URI or just make it a tel URI? if i dial +3584012345 from my sip phone, it will not append @nokia.com to the number. instead it will append @tutpro.com, which is the domain of the phone. then the phone will forward the call to the proxy of tutpro.com, which will do enum lookup on the number and, if that succeeds, forward the call according to the reply, and if is doesn't succeed, forward the call to our pstn gw. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 12:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14275 for ; Tue, 2 Sep 2003 12:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEQt-0000qI-2p for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 12:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Gt71q003197 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 12:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEQq-0000oz-Lh; Tue, 02 Sep 2003 12:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEQm-0000nb-1D for sip@optimus.ietf.org; Tue, 02 Sep 2003 12:55:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14211 for ; Tue, 2 Sep 2003 12:54:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEQk-0007iE-00 for sip@ietf.org; Tue, 02 Sep 2003 12:54:58 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19uEQj-0007iA-00 for sip@ietf.org; Tue, 02 Sep 2003 12:54:57 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19uEQT-0000HM-00; Tue, 02 Sep 2003 19:54:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16212.52049.564896.161434@harjus.tutpro.com> Date: Tue, 2 Sep 2003 19:54:41 +0300 To: "Rosen, Brian" Cc: "'hisham.khartabil@nokia.com'" , Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com, sip@ietf.org Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <313680C9A886D511A06000204840E1CF070B5DA7@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5DA7@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian writes: > I think your example not ideal only because a UA could > have a trivial rule that a number starting with + is known to > be a globally dialable number, and thus COULD be put in a tel > uri. no matter what number the user dials (with or without +), my sip phone will do the same thing: append its own domain to the number and forward the call to the proxy of the domain. the proxy of the phone's domain will then interpret the number according to the conventions that exist within the domain. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 13:35:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19444 for ; Tue, 2 Sep 2003 13:35:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uF3j-0004MA-Ae for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 13:35:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82HZFLk016740 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 13:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uF3W-0004LK-HJ; Tue, 02 Sep 2003 13:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uF3E-0004Ks-21 for sip@optimus.ietf.org; Tue, 02 Sep 2003 13:34:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19314 for ; Tue, 2 Sep 2003 13:34:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uF3B-0001ND-00 for sip@ietf.org; Tue, 02 Sep 2003 13:34:41 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uF3A-0001M9-00 for sip@ietf.org; Tue, 02 Sep 2003 13:34:40 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11404; Tue, 2 Sep 2003 13:34:08 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29514; Tue, 2 Sep 2003 13:34:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Sep 2003 13:34:09 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DAB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Juha Heinanen'" Cc: "'hisham.khartabil@nokia.com'" , Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com, sip@ietf.org Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 2 Sep 2003 13:34:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Many phones do this. Some phones have the local dial plan interpreted in the phone, and only emit "complete" (within the domain) phone numbers. Some will send a tel uri, some will send the number in a sip uri in the local (configured) domain. I think that for most dial plans you can safely translate such a number again by the proxy, but I worry that that is not ALWAYS true. So, I think it might be useful to mark a sip uri with an uninterpreted dial string differently from a sip uri with an interpreted phone number. I also wonder if it might be helpful in other circumstances; for example, where there are several proxies in the path which have the capability to translate dial strings to phone numbers. Generally, I think it's always the case that the first proxy encountered that has the capability should do the translation. I think it might be useful for a succeeding proxy to know that it should NOT translate (because it has already been translated). Brian > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Tuesday, September 02, 2003 12:55 PM > To: Rosen, Brian > Cc: 'hisham.khartabil@nokia.com'; Richard.Stastny@oefeg.at; > fluffy@cisco.com; dean.willis@softarmor.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Rosen, Brian writes: > > > I think your example not ideal only because a UA could > > have a trivial rule that a number starting with + is known to > > be a globally dialable number, and thus COULD be put in a tel > > uri. > > > no matter what number the user dials (with or without +), my sip phone > will do the same thing: append its own domain to the number > and forward > the call to the proxy of the domain. the proxy of the phone's domain > will then interpret the number according to the conventions that exist > within the domain. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 13:45:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20787 for ; Tue, 2 Sep 2003 13:45:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFDK-0005Uk-OZ for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 13:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82HjAfY021062 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 13:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFDC-0005T1-2t; Tue, 02 Sep 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFCV-0005Q3-R6 for sip@optimus.ietf.org; Tue, 02 Sep 2003 13:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20622 for ; Tue, 2 Sep 2003 13:44:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uFCT-0001oF-00 for sip@ietf.org; Tue, 02 Sep 2003 13:44:17 -0400 Received: from natsmtp01.webmailer.de ([192.67.198.81] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19uFCS-0001oC-00 for sip@ietf.org; Tue, 02 Sep 2003 13:44:16 -0400 Received: from sip (pD9055985.dip.t-dialin.net [217.5.89.133]) by post.webmailer.de (8.12.9/8.8.7) with ESMTP id h82HiEts022355; Tue, 2 Sep 2003 19:44:15 +0200 (MEST) From: "Christian Stredicke" To: "'Kolinowitz Bernd'" Cc: "'SIP list'" Subject: AW: [Sip] Sending an announcement!! Date: Tue, 2 Sep 2003 19:44:32 +0200 Message-ID: <008901c37179$de777ca0$2f00a8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Bernd,=20 just include the announcement UA in the forking. If then someone else picks up (what a surprise) the phone has to deal with it. It will then receive another SDP answer. Please also take a look at Alert-Info. CS > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von > Kolinowitz Bernd > Gesendet: Dienstag, 2. September 2003 15:50 > An: 'SIP list' > Betreff: [Sip] Sending an announcement!! >=20 >=20 > Hi! >=20 > We want to implement a typical PSTN feature in our SIP proxy. If caller A > sends an INVITE (including audio in the sdp) to the sip-proxy, the proxy > should send an announcement (like a jingle) to caller A while it is trying > to reach the callee. >=20 > We are now searching for a way to implement the feature concerning RFC > 3264 (offer/answer model of SDP). First we thought to answer with early > media, that means to send a 183 response including the SDP for the > announcement and demanding a PRACK request. > Next we have thought to forward the 200 response from the callee to the > caller. > Now there is our problem: What should the caller do with the SDP? >=20 > The good version: He accept the SDP from the callee as an answer of his > SDP offer in the first INVITE-request and sends an empty ACK. > The bad version: The SDP in the 200 response will be treated as a new > offer and he sends an SDP answer in the ACK request. >=20 > How will the client react? Is there another way to realize this feature? >=20 > Thanks in advance > Bernd >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 15:03:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27443 for ; Tue, 2 Sep 2003 15:03:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uGR7-0001da-GF for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 15:03:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82J3SxH006231 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 15:03:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uGQl-0001ax-LM; Tue, 02 Sep 2003 15:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uGPn-0001Yw-Pw for sip@optimus.ietf.org; Tue, 02 Sep 2003 15:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27284 for ; Tue, 2 Sep 2003 15:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uGPk-00041r-00 for sip@ietf.org; Tue, 02 Sep 2003 15:02:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uGPk-00040p-00 for sip@ietf.org; Tue, 02 Sep 2003 15:02:04 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2003 12:01:34 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h82J1WgM022787; Tue, 2 Sep 2003 12:01:32 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALB14837; Tue, 2 Sep 2003 11:51:36 -0700 (PDT) Date: Tue, 2 Sep 2003 12:04:49 -0700 Subject: Re: [Sip] Sending an announcement!! Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'SIP list'" To: Kolinowitz Bernd From: Rohan Mahy In-Reply-To: Message-Id: <53290B7D-DD78-11D7-8883-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Depending on how you implement this feature you may no longer be just a proxy. I can think of three ways to accomplish this behavior. 1) the proxy inserts an Alert-Info header in the 180 responses returned by the callee. This header contains a URL which points to the jingle. This puts a very small amount of work on the UAC, and requires almost no work on the proxy (best of both worlds) 2) a user agent which is co-located with the your proxy sends an INVITE with Join request to the UAC (this session has its own separate SDP). This puts all the hard work on the UAC, and is more desirable if you want to be involved for an extended period of time. 3) your device becomes a B2BUA, and uses 3pcc to INVITE an announcement service to play the jingle, then uses lots of reINVITEs, UPDATEs, PRACKs, and reliable provisionals to manipulate the session with the UAC. this is the most complicated for you, but still requires PRACK and UPDATE to be supported (all 6 possible combinations of offer/answer) to be implemented on the UAC. Hope this helps. Note: in future you should send these types of questions to sipping@ietf.org instead. thanks, -rohan On Tuesday, September 2, 2003, at 06:49 AM, Kolinowitz Bernd wrote: > > Hi! > > We want to implement a typical PSTN feature in our SIP proxy. If > caller A sends an INVITE (including audio in the sdp) to the > sip-proxy, the proxy should send an announcement (like a jingle) to > caller A while it is trying to reach the callee. > > We are now searching for a way to implement the feature concerning RFC > 3264 (offer/answer model of SDP). First we thought to answer with > early media, that means to send a 183 response including the SDP for > the announcement and demanding a PRACK request. > Next we have thought to forward the 200 response from the callee to > the caller. > Now there is our problem: What should the caller do with the SDP? > > The good version: He accept the SDP from the callee as an answer of > his SDP offer in the first INVITE-request and sends an empty ACK. > The bad version: The SDP in the 200 response will be treated as a new > offer and he sends an SDP answer in the ACK request. > > How will the client react? Is there another way to realize this > feature? > > Thanks in advance > Bernd > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 17:35:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09385 for ; Tue, 2 Sep 2003 17:35:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uInz-0001fJ-Il for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 17:35:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82LZEad006341 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 17:35:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uInp-0001dt-4s; Tue, 02 Sep 2003 17:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uInZ-0001dH-06 for sip@optimus.ietf.org; Tue, 02 Sep 2003 17:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09263 for ; Tue, 2 Sep 2003 17:34:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uInW-0000Ea-00 for sip@ietf.org; Tue, 02 Sep 2003 17:34:46 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uInV-0000DZ-00 for sip@ietf.org; Tue, 02 Sep 2003 17:34:45 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h82LYEt0017476; Tue, 2 Sep 2003 14:34:14 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHR68919; Tue, 2 Sep 2003 14:34:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 02 Sep 2003 13:29:18 -0700 Subject: Re: [Sip] Update of display name during a call From: Cullen Jennings To: Henry Chen , "Elwell, John" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think I might be having a disconnect here. John and Henry - you are both imagining a situation where an IP phone (not a PSTN GW) is inside the trust domain? How does an anonymous call work in this case - does the phone receive the PAI information and promise not to display it to the user? I don't think 3325 imagined devices end the end users possession being part of the trust domain. On 9/1/03 8:39 PM, "Henry Chen" wrote: > > Not really since a UA only expect to receive PAI, called party receives > it in a request and calling party receives it in the response. > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, August 31, 2003 10:56 AM > To: Henry Chen; Elwell, John; sip@ietf.org > Subject: Re: [Sip] Update of display name during a call > > > > Well the PAI is a network asserted From. You are talking about a network > asserted To. I suspect putting both in the same field with lead to > problems. > > On 8/29/03 10:49, "Henry Chen" wrote: > >> >> The caller's name can be authenticated and put in a PAI header by a >> proxy in the initial Invite according to RFC3325. >> >> The problem is how to pass called party name to the call originator >> when the call is forwarded by the proxy. >> >> Is there any problem to put called party id or display name in a PAI >> header in the response to Invite by the proxy in the trusted domain >> serving the call? >> >> Thanks, >> >> Henry >> >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, August 29, 2003 8:32 AM >> To: 'Cullen Jennings'; sip@ietf.org >> Subject: RE: [Sip] Update of display name during a call >> >> >> Cullen, >> >> In trusted situations where P-Asserted-ID is in use, I think it would >> be reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or > >> UPDATE. >> >> John (john.elwell@siemens.com) >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 28 August 2003 21:11 >> To: sip@ietf.org >> Cc: Cullen Jennings >> Subject: [Sip] Update of display name during a call >> >> >> >> There has been some discussion on the issues of changing the display >> name associated with a call during the call. This has come up in QSIG >> cases, it has come up in B2BUA cases, and in some other PBX and PSTN >> interoperability issues. I think it is worth solving. >> >> How about this as a proposal. The UA can send an re-INVITE or UPDATE >> (as >> appropriate) with an AIB. The AIB can be authenticated in the normal >> way. The From and To inside the AIB can have a modified display name. >> The tag will not be changed. If a 2543 device receives one of these >> message, it may end up ignoring it but it will not cause harm. If a >> device that receives one of these and understands it, it SHOULD update >> the display name information. This can happen both from callee to > caller >> and caller to callee. The AIB might have a PAI in it too. >> >> Section 12.2.1.1 of 3261 says >> Usage of the URI from the To and From fields in the original >> request within subsequent requests is done for backwards >> compatibility with RFC 2543, which used the URI for dialog >> identification. In this specification, only the tags are used for >> dialog identification. It is expected that mandatory reflection >> of the original To and From URI in mid-dialog requests will be >> deprecated in a subsequent revision of this specification. >> >> Clearly this is in line with that. >> >> AIBs are about identity and solve some of the complex issues of third >> parties asserting identity on behalf of others. I think this is a good > >> place to deal with issues that is about the displayed identity. >> >> Thoughts? Issues with this? Better Ideas... >> >> Thanks, Cullen >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 2 18:02:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11438 for ; Tue, 2 Sep 2003 18:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJE1-0002zQ-AY for sip-archive@odin.ietf.org; Tue, 02 Sep 2003 18:02:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82M29iD011492 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 18:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJDv-0002zF-GG; Tue, 02 Sep 2003 18:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJDB-0002wq-6T for sip@optimus.ietf.org; Tue, 02 Sep 2003 18:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11363 for ; Tue, 2 Sep 2003 18:01:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJD8-00013E-00 for sip@ietf.org; Tue, 02 Sep 2003 18:01:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uJD6-00010n-00 for sip@ietf.org; Tue, 02 Sep 2003 18:01:13 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Sep 2003 15:12:28 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h82M0ds4026744; Tue, 2 Sep 2003 15:00:40 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACA47454; Tue, 2 Sep 2003 18:00:38 -0400 (EDT) Message-ID: <3F551306.1000007@cisco.com> Date: Tue, 02 Sep 2003 18:00:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Rosen, Brian'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Adam Roach wrote: > > It used to be that you could do the same in a tel uri, but we > > "fixed" that. > > ...meaning that, if we were to do nothing but rev 3261 with > updated references, using bare, unscoped digit strings with > "user=phone" would automatically become deprecated. How did we break it? Even in 2806 a uri like was illegal - it required a phone-context parameter. AFAIK, the wording in 2543 and all its successors has always suggested that IF you transform from tel to sip you should add user=phone. But they have never stated the converse - that if you have a uri of form then the nnn should conform to 2806. As a result, normal dial strings have been representable as sip uris *without* user=phone. Meanwhile, on this discussion as a whole, I think the real problem is when the UAC has a dial string and doesn't know the dial plan itself. The suggestion seems to be to patch it into a sip url and let some proxy fix it. For instance, maybe I dial 1234, and my UAC turns this into INVITE sip:1234@myproxy.com To: sip:1234@myproxy.com ... Then maybe myproxy turns this into: INVITE: sip:+19785551234@otherproxy.com;user=phone To: sip:1234@myproxy.com and maybe that becomes: INVITE: sip:you@yourphone.com To: sip:1234@myproxy.com So things have worked - the call got where it should go. BUT, sometimes the UAS might care where the call was originally addressed. For instance it might want to recognize when it has received redirected calls (calls not addressed "To" it) and do the alerting in a different manner. Trouble is, done this way the To address is meaningless to anyone except the caller. Unless you know the dialplan of the caller it is just junk. Worse, it might even disclose information about you that you might not want disclosed - like whether you have a speed dial number defined for this number. The obvious solution to this is for the dial plan to be implemented in the UAC. Then the result of expanding the number via the dialplan can be included in both the To and request uris. If the UAC is too feeble to do that, then ideally the UAC would have its local proxy do the expansion and then use that in both the To and request URIs. Having the proxy return the translation in a 3xx is almost the right thing. There are two issues with that: - how does proxy know to return 3xx rather than proxy? This is solvable via Request-Disposition from callerprefs. - how does the UAC know to replace both the request uri AND the To uri? This is a problem - normally on a 3xx the To should not be changed. Maybe a solution would be to define a new 3xx code that means exactly this. Regarding usefulness of user=phone: I agree it is largely a matter of whether you think there can be a conflict between "regular" usernames and telephone numbers or dial strings. This doesn't seem to be too much of a problem with 2806 conformant numbers, because they either start with + or contain ";phone-context". But it could be a problem for arbitrary dial strings. Remember that phone numbers (and presumably dial strings) are permitted to contain more than just digits. They can contain ".-()*#ABCDpw". So things like "BAD", "A-DABA" or "A.B.C.D" might be valid dial strings. I am not comfortable saying that nothing that might be a valid dial string can be assigned as a valid username. The best solution to me is for the UAC to be configured to always turn dial strings into some kind of valid telephone-subscriber string. If it can't turn it into a global-phone-number, then it should turn it into a local-phone-number, using some configured phone-context. When there is no better solution, it can simply paste a phone-context onto the end of the dial string. Once this is done, it must turn this into a URL. It can make a tel: url trivially. Or it can make a sip or sips url with user=phone by supplying a configured domain name. Of these, I prefer tel, because using sip doesn't seem to add anything and it further constrains where and how transformations can be made. (Phone-context in a tel can be translated by anybody that understands it, but in a sip url can only be translated by a server that is responsible for the domain.) Proxies that want to can still handle dial strings in sip urls without user=phone for backward compatibility with old phones. But as long as they do there will be the possibility of conflict with usernames. They could always limit this problem by restricting the kinds of dial strings they will accept. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 05:47:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18552 for ; Wed, 3 Sep 2003 05:47:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUEX-0004kl-S7 for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 05:47:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h839lPPu018267 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 05:47:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUEA-0004jm-0I; Wed, 03 Sep 2003 05:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUDO-0004j4-MP for sip@optimus.ietf.org; Wed, 03 Sep 2003 05:46:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18479 for ; Wed, 3 Sep 2003 05:46:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uUDL-0007HX-00 for sip@ietf.org; Wed, 03 Sep 2003 05:46:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19uUDJ-0007H3-00 for sip@ietf.org; Wed, 03 Sep 2003 05:46:09 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h839jv409821 for ; Wed, 3 Sep 2003 12:46:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Sep 2003 12:45:56 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 12:45:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 12:45:54 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179706B@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNxcokO9tMe1iWYRV2Ng5Nc12xt5gAjUCvw To: Cc: , , , , X-OriginalArrivalTime: 03 Sep 2003 09:45:55.0807 (UTC) FILETIME=[2BDE6EF0:01C37200] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable When if I hand you this on a business card: Phone: 0401234567 and one of your colleagues hands you this: SIP: 0401234567@tutpro.com What do you dial to call me and what do you dial to call your colleague, = using your phone? How does your proxy tell the difference? /Hisham > -----Original Message----- > From: ext Juha Heinanen [mailto:jh@tutpro.com] > Sent: Tuesday, September 02, 2003 7:52 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at;=20 > fluffy@cisco.com; > dean.willis@softarmor.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > hisham.khartabil@nokia.com writes: >=20 > > I can hand a Nokia colleague a business card that has the=20 > following info: > >=20 > > Tel: 04012345 > > SIP: 04067891@nokia.com > >=20 > > He dials +3584012345. How does the UA know if it should append > > @nokia.com and make it a sip URI or just make it a tel URI? >=20 > if i dial +3584012345 from my sip phone, it will not append @nokia.com > to the number. instead it will append @tutpro.com, which is=20 > the domain > of the phone. then the phone will forward the call to the proxy of > tutpro.com, which will do enum lookup on the number and, if that > succeeds, forward the call according to the reply, and if is doesn't > succeed, forward the call to our pstn gw. >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 06:19:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20314 for ; Wed, 3 Sep 2003 06:19:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUjF-0006Qh-3T for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 06:19:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83AJ9g5024712 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 06:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUj8-0006QA-6r; Wed, 03 Sep 2003 06:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUix-0006Pm-UO for sip@optimus.ietf.org; Wed, 03 Sep 2003 06:18:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20260 for ; Wed, 3 Sep 2003 06:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uUit-0001n6-00 for sip@ietf.org; Wed, 03 Sep 2003 06:18:47 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19uUis-0001mU-00 for sip@ietf.org; Wed, 03 Sep 2003 06:18:46 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HKM00C01V93FQ@siemenscomms.co.uk> for sip@ietf.org; Wed, 03 Sep 2003 11:17:27 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HKM00C8LV9381@siemenscomms.co.uk>; Wed, 03 Sep 2003 11:17:27 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 03 Sep 2003 11:18:16 +0100 Content-return: allowed Date: Wed, 03 Sep 2003 11:13:08 +0100 From: "Elwell, John" Subject: RE: [Sip] Update of display name during a call To: "'Cullen Jennings'" Cc: Henry Chen , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266761FCB6@ntht201e> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Cullen, The last sentence of section 5 (proxy behaviour) of RFC3325 states: "If it does not trust the element, then the proxy MUST examine the Privacy header field (if present) to determine if the user requested that asserted identity information be kept private." This implies that an identity for which privacy is not required can be sent to an untrusted entity, in this case a UA. John -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: 02 September 2003 21:29 To: Henry Chen; Elwell, John; sip@ietf.org Subject: Re: [Sip] Update of display name during a call I think I might be having a disconnect here. John and Henry - you are both imagining a situation where an IP phone (not a PSTN GW) is inside the trust domain? How does an anonymous call work in this case - does the phone receive the PAI information and promise not to display it to the user? I don't think 3325 imagined devices end the end users possession being part of the trust domain. On 9/1/03 8:39 PM, "Henry Chen" wrote: > > Not really since a UA only expect to receive PAI, called party receives > it in a request and calling party receives it in the response. > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, August 31, 2003 10:56 AM > To: Henry Chen; Elwell, John; sip@ietf.org > Subject: Re: [Sip] Update of display name during a call > > > > Well the PAI is a network asserted From. You are talking about a network > asserted To. I suspect putting both in the same field with lead to > problems. > > On 8/29/03 10:49, "Henry Chen" wrote: > >> >> The caller's name can be authenticated and put in a PAI header by a >> proxy in the initial Invite according to RFC3325. >> >> The problem is how to pass called party name to the call originator >> when the call is forwarded by the proxy. >> >> Is there any problem to put called party id or display name in a PAI >> header in the response to Invite by the proxy in the trusted domain >> serving the call? >> >> Thanks, >> >> Henry >> >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Friday, August 29, 2003 8:32 AM >> To: 'Cullen Jennings'; sip@ietf.org >> Subject: RE: [Sip] Update of display name during a call >> >> >> Cullen, >> >> In trusted situations where P-Asserted-ID is in use, I think it would >> be reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or > >> UPDATE. >> >> John (john.elwell@siemens.com) >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 28 August 2003 21:11 >> To: sip@ietf.org >> Cc: Cullen Jennings >> Subject: [Sip] Update of display name during a call >> >> >> >> There has been some discussion on the issues of changing the display >> name associated with a call during the call. This has come up in QSIG >> cases, it has come up in B2BUA cases, and in some other PBX and PSTN >> interoperability issues. I think it is worth solving. >> >> How about this as a proposal. The UA can send an re-INVITE or UPDATE >> (as >> appropriate) with an AIB. The AIB can be authenticated in the normal >> way. The From and To inside the AIB can have a modified display name. >> The tag will not be changed. If a 2543 device receives one of these >> message, it may end up ignoring it but it will not cause harm. If a >> device that receives one of these and understands it, it SHOULD update >> the display name information. This can happen both from callee to > caller >> and caller to callee. The AIB might have a PAI in it too. >> >> Section 12.2.1.1 of 3261 says >> Usage of the URI from the To and From fields in the original >> request within subsequent requests is done for backwards >> compatibility with RFC 2543, which used the URI for dialog >> identification. In this specification, only the tags are used for >> dialog identification. It is expected that mandatory reflection >> of the original To and From URI in mid-dialog requests will be >> deprecated in a subsequent revision of this specification. >> >> Clearly this is in line with that. >> >> AIBs are about identity and solve some of the complex issues of third >> parties asserting identity on behalf of others. I think this is a good > >> place to deal with issues that is about the displayed identity. >> >> Thoughts? Issues with this? Better Ideas... >> >> Thanks, Cullen >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 06:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21339 for ; Wed, 3 Sep 2003 06:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUvm-0007CB-Rn for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 06:32:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83AW6Ze027623 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 06:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUvi-0007Ap-DA; Wed, 03 Sep 2003 06:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUv8-00079h-0R for sip@optimus.ietf.org; Wed, 03 Sep 2003 06:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21264 for ; Wed, 3 Sep 2003 06:31:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uUv3-0002Tq-00 for sip@ietf.org; Wed, 03 Sep 2003 06:31:21 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19uUv1-0002Tf-00 for sip@ietf.org; Wed, 03 Sep 2003 06:31:20 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19uUue-0000I7-00; Wed, 03 Sep 2003 13:30:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16213.49888.57844.41486@harjus.tutpro.com> Date: Wed, 3 Sep 2003 13:30:56 +0300 To: Cc: , , , , Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179706B@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179706B@esebe019.ntc.nokia.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com writes: > When if I hand you this on a business card: > > Phone: 0401234567 > > and one of your colleagues hands you this: > > SIP: 0401234567@tutpro.com > > What do you dial to call me and what do you dial to call your > colleague, using your phone? How does your proxy tell the difference? what would the phone network do if someone in india dials the number you gave? it would do the same as my proxy: route the call to a destination in a wrong local network or declare the destination unreachable. it is thus the responsibility of the user to figure out, how to turn 0401234567 into something that is correctly routable by the proxy of that user the user might, for example, try to figure out from the address on the business card in which country the person lives and then add the corresponding cc into the number. that is what people do every day when they have to deal with local phone numbers in other regions. i don't understand why we discuss this on a mailing list of a standards body. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 06:35:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21563 for ; Wed, 3 Sep 2003 06:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUyf-0007Tv-Fy for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 06:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83AZ54t028734 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 06:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUyd-0007T2-CK; Wed, 03 Sep 2003 06:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uUyL-0007SV-7n for sip@optimus.ietf.org; Wed, 03 Sep 2003 06:34:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21482 for ; Wed, 3 Sep 2003 06:34:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uUyH-00030H-00 for sip@ietf.org; Wed, 03 Sep 2003 06:34:41 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19uUyG-0002zf-00 for sip@ietf.org; Wed, 03 Sep 2003 06:34:40 -0400 content-class: urn:content-classes:message Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Sep 2003 12:38:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620EA082@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNyByx6tSu5biEhQeG8jt7FNzwaBQAAIp1w From: "Stastny Richard" To: "Juha Heinanen" , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Juha wrote: >=20 > it is thus the responsibility of the user to figure out, how=20 > to turn 0401234567 into something that is correctly routable=20 > by the proxy of that user the user might, for example, try to=20 > figure out from the address on the business card in which=20 > country the person lives and then add the corresponding cc=20 > into the number. =20 >=20 > that is what people do every day when they have to deal with=20 > local phone numbers in other regions. i don't understand why=20 > we discuss this on a mailing list of a standards body. >=20 > -- juha >=20 Amen, Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 06:59:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23495 for ; Wed, 3 Sep 2003 06:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVLy-0000Vr-0z for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 06:59:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Ax96b001969 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 06:59:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVLq-0000V9-3y; Wed, 03 Sep 2003 06:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVLI-0000UI-LI for sip@optimus.ietf.org; Wed, 03 Sep 2003 06:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23393 for ; Wed, 3 Sep 2003 06:58:19 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uVLE-0004SB-00 for sip@ietf.org; Wed, 03 Sep 2003 06:58:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19uVLC-0004S3-00 for sip@ietf.org; Wed, 03 Sep 2003 06:58:22 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h83AwA407869 for ; Wed, 3 Sep 2003 13:58:22 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Sep 2003 13:58:10 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 13:58:10 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 13:58:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 13:58:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179706E@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNyBoBIckvH/Bg3SOm7fFI/Z805qwAA6SNw To: Cc: , , , , X-OriginalArrivalTime: 03 Sep 2003 10:58:09.0974 (UTC) FILETIME=[433BD560:01C3720A] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable We both live in Finland. You expect me to dial +358 every time I call = you? > -----Original Message----- > From: ext Juha Heinanen [mailto:jh@tutpro.com] > Sent: Wednesday, September 03, 2003 1:31 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at;=20 > fluffy@cisco.com; > dean.willis@softarmor.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > hisham.khartabil@nokia.com writes: >=20 > > When if I hand you this on a business card: > >=20 > > Phone: 0401234567 > >=20 > > and one of your colleagues hands you this: > >=20 > > SIP: 0401234567@tutpro.com > >=20 > > What do you dial to call me and what do you dial to call your > > colleague, using your phone? How does your proxy tell the=20 > difference? >=20 > what would the phone network do if someone in india dials the=20 > number you > gave? it would do the same as my proxy: route the call to a > destination in a wrong local network or declare the destination > unreachable. >=20 > it is thus the responsibility of the user to figure out, how to turn > 0401234567 into something that is correctly routable by the proxy of > that user the user might, for example, try to figure out from the > address on the business card in which country the person=20 > lives and then > add the corresponding cc into the number. =20 >=20 > that is what people do every day when they have to deal with=20 > local phone > numbers in other regions. i don't understand why we discuss this on a > mailing list of a standards body. >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 08:37:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28855 for ; Wed, 3 Sep 2003 08:37:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWst-0005jO-Ah for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 08:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83CbFgk021969 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 08:37:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWsg-0005hG-Qz; Wed, 03 Sep 2003 08:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWri-0005df-OO for sip@optimus.ietf.org; Wed, 03 Sep 2003 08:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28769 for ; Wed, 3 Sep 2003 08:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uWrh-0003HU-00 for sip@ietf.org; Wed, 03 Sep 2003 08:36:01 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uWrg-0003Gn-00 for sip@ietf.org; Wed, 03 Sep 2003 08:36:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00168; Wed, 3 Sep 2003 08:35:28 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03037; Wed, 3 Sep 2003 08:35:28 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 08:35:28 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DB5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , Adam Roach Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 08:35:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > > > It used to be that you could do the same in a tel uri, but we > > > "fixed" that. > > > > ...meaning that, if we were to do nothing but rev 3261 with > > updated references, using bare, unscoped digit strings with > > "user=phone" would automatically become deprecated. > > How did we break it? Even in 2806 a uri like was > illegal - it > required a phone-context parameter. We "broke" it by explicitly declaring in 2806bis that the number could NOT be a dial string. You would always have a context with a dial string, the dial string passers were never unhappy requiring a context in a tel uri. > > AFAIK, the wording in 2543 and all its successors has always > suggested > that IF you transform from tel to sip you should add user=phone. But > they have never stated the converse - that if you have a uri of form > then the nnn should conform to 2806. I've never understood that user=phone was intended for tel to sip uri conversion. It was always supposed to be the differentiator between a numeric username and a phone number or dial string. > > As a result, normal dial strings have been representable as sip uris > *without* user=phone. Well, I agree that they can be representable, but then if you don't mark the uri as a dial string you re-introduce the problem of confusing a dial string with a user name, and your expansion below, pointing out that dial strings are not necessarily numeric makes this a worse problem. > > Meanwhile, on this discussion as a whole, I think the real problem is > when the UAC has a dial string and doesn't know the dial plan itself. > The suggestion seems to be to patch it into a sip url and let > some proxy > fix it. For instance, maybe I dial 1234, and my UAC turns this into > > INVITE sip:1234@myproxy.com > To: sip:1234@myproxy.com > ... I'm not sure why you would use the word "patch", but yes, lots and lots of phones do this, and are going to do this. > > Then maybe myproxy turns this into: > > INVITE: sip:+19785551234@otherproxy.com;user=phone > To: sip:1234@myproxy.com Well, I'm arguing that this is wrong, or at least we need to be able to differentiate between a phone number and a dial string, which user=phone COULD be used for (although I'm not sure that's the best answer). I would really prefer that this example be wrong. If the proxy knows how to expand a dial string to a phone number, but does not understand how to route phone numbers, then it would convert the dial string to a tel uri, and route that. Presumably, a downstream proxy would understand how to turn the tel uri into a routable sip uri, perhaps by an enum dip. If the proxy knew how to convert a phone number to a routable uri, then it would do so, and it would NOT have a user=phone on the uri. I would argue that it would be preferable to mark such a uri that it was indeed a translated phone number, so that no more processing was done by any further downstream proxies. > > and maybe that becomes: > > INVITE: sip:you@yourphone.com > To: sip:1234@myproxy.com This would be the result of converting a phone number to a routable sip uri, by enum for example, as above. > > So things have worked - the call got where it should go. > > BUT, sometimes the UAS might care where the call was originally > addressed. For instance it might want to recognize when it > has received > redirected calls (calls not addressed "To" it) and do the > alerting in a > different manner. > > Trouble is, done this way the To address is meaningless to > anyone except > the caller. Unless you know the dialplan of the caller it is > just junk. > Worse, it might even disclose information about you that you > might not > want disclosed - like whether you have a speed dial number > defined for > this number. > > The obvious solution to this is for the dial plan to be > implemented in > the UAC. Then the result of expanding the number via the > dialplan can be > included in both the To and request uris. I agree that it is a good solution, and I want it to be possible to have this occur. The result would be a tel uri, unless you want the phone to do the enum dip. > > If the UAC is too feeble to do that, then ideally the UAC > would have its > local proxy do the expansion and then use that in both the To and > request URIs. Having the proxy return the translation in a > 3xx is almost > the right thing. There are two issues with that: > > - how does proxy know to return 3xx rather than proxy? > This is solvable via Request-Disposition from callerprefs. > > - how does the UAC know to replace both the request uri AND > the To uri? > This is a problem - normally on a 3xx the To should not be changed. > Maybe a solution would be to define a new 3xx code that means > exactly this. Seems like a good idea > > Regarding usefulness of user=phone: > > I agree it is largely a matter of whether you think there can be a > conflict between "regular" usernames and telephone numbers or > dial strings. Yes, I think all three are different, and need to be disambiguated > > This doesn't seem to be too much of a problem with 2806 conformant > numbers, because they either start with + or contain > ";phone-context". Anything with a tel uri is a phone number, by definition. > But it could be a problem for arbitrary dial strings. Remember that > phone numbers (and presumably dial strings) are permitted to contain > more than just digits. They can contain ".-()*#ABCDpw". So > things like > "BAD", "A-DABA" or "A.B.C.D" might be valid dial strings. I am not > comfortable saying that nothing that might be a valid dial > string can be > assigned as a valid username. It's more complicated than that, because when you are finished translating a phone number into a routable uri, you may very well have a numeric username. For example, you may translate to a string that is the set of digits to be dialed by a gateway such a string is not a dial string, it is not a phone number, and is not a "username", although it functionally works like a username. > > The best solution to me is for the UAC to be configured to > always turn > dial strings into some kind of valid telephone-subscriber > string. If it > can't turn it into a global-phone-number, then it should turn > it into a > local-phone-number, using some configured phone-context. When > there is > no better solution, it can simply paste a phone-context onto > the end of > the dial string. You can't send such a thing in a tel uri. You can send it in a username part of a sip uri, but I think it should be marked as a dial string > > Once this is done, it must turn this into a URL. It can make > a tel: url > trivially. Or it can make a sip or sips url with user=phone > by supplying > a configured domain name. Of these, I prefer tel, because using sip > doesn't seem to add anything and it further constrains where and how > transformations can be made. (Phone-context in a tel can be > translated > by anybody that understands it, but in a sip url can only be > translated > by a server that is responsible for the domain.) No, the wording of 2806 bis explicitly forbids the number to be a dial string. It has to be a phone number (in the context). > > Proxies that want to can still handle dial strings in sip > urls without > user=phone for backward compatibility with old phones. But as long as > they do there will be the possibility of conflict with > usernames. They > could always limit this problem by restricting the kinds of > dial strings > they will accept. We need to more positively disambiguate the circumstances. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 08:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29144 for ; Wed, 3 Sep 2003 08:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWxb-0006TB-6R for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 08:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Cg73F024862 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 08:42:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWxV-0006Om-7Z; Wed, 03 Sep 2003 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uWwr-0006Nm-SF for sip@optimus.ietf.org; Wed, 03 Sep 2003 08:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29091 for ; Wed, 3 Sep 2003 08:41:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uWwq-0003S6-00 for sip@ietf.org; Wed, 03 Sep 2003 08:41:20 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uWwp-0003RH-00 for sip@ietf.org; Wed, 03 Sep 2003 08:41:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00357; Wed, 3 Sep 2003 08:40:47 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03630; Wed, 3 Sep 2003 08:40:47 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 08:40:47 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DB7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , jh@tutpro.com Cc: Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com, sip@ietf.org Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 08:40:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think you have been given the wrong answer. Phone: 0401234567 if dialed, you would enter the digits 0-4-1-2-3-4-5-6-7, and the uac, if it did not know how to translate dial strings to telephone numbers would send 0401234567@localdomain; user=phone SIP: 0401234567@tutpro.com if dialed, would result in the uac sending 0401234567@tutpro.com The original reason for user=phone was to differentiate between these two cases, where localdomain=tutpro.com, and it was intended that the resulting uas was different. I would say that the former results in a dial string, and the latter does not. I think it is very useful for the proxy to be able to know that the user part of the uri is a dial string and not a phone number and not a username. I think a phone number should be sent in a tel uri, at least on a go forward basis, and not in a sip uri. If some proxy has turned a phone number into a sip uri (by an enum dip for example), then the result will be a sip uri which is NOT a phone number, nor a dial string. This may or may not have numeric username. A downstream proxy should be able to differentiate all of these cases, so that, for example, it does not invoke dial string to phone number processing, or another enum dip. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, September 03, 2003 6:58 AM > To: jh@tutpro.com > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at; > fluffy@cisco.com; > dean.willis@softarmor.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone > > > We both live in Finland. You expect me to dial +358 every > time I call you? > > > -----Original Message----- > > From: ext Juha Heinanen [mailto:jh@tutpro.com] > > Sent: Wednesday, September 03, 2003 1:31 PM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at; > > fluffy@cisco.com; > > dean.willis@softarmor.com; sip@ietf.org > > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > > > hisham.khartabil@nokia.com writes: > > > > > When if I hand you this on a business card: > > > > > > Phone: 0401234567 > > > > > > and one of your colleagues hands you this: > > > > > > SIP: 0401234567@tutpro.com > > > > > > What do you dial to call me and what do you dial to call your > > > colleague, using your phone? How does your proxy tell the > > difference? > > > > what would the phone network do if someone in india dials the > > number you > > gave? it would do the same as my proxy: route the call to a > > destination in a wrong local network or declare the destination > > unreachable. > > > > it is thus the responsibility of the user to figure out, how to turn > > 0401234567 into something that is correctly routable by the proxy of > > that user the user might, for example, try to figure out from the > > address on the business card in which country the person > > lives and then > > add the corresponding cc into the number. > > > > that is what people do every day when they have to deal with > > local phone > > numbers in other regions. i don't understand why we > discuss this on a > > mailing list of a standards body. > > > > -- juha > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 08:55:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00132 for ; Wed, 3 Sep 2003 08:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXAC-000706-HC for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 08:55:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Ct8ZY026893 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 08:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXA7-0006zE-GD; Wed, 03 Sep 2003 08:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uX9L-0006xO-Hi for sip@optimus.ietf.org; Wed, 03 Sep 2003 08:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00053 for ; Wed, 3 Sep 2003 08:54:09 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uX9J-0003qi-00 for sip@ietf.org; Wed, 03 Sep 2003 08:54:13 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19uX9I-0003qc-00 for sip@ietf.org; Wed, 03 Sep 2003 08:54:13 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h83Cs7B03025 for ; Wed, 3 Sep 2003 15:54:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Sep 2003 15:54:06 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 15:54:05 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 15:54:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 15:54:04 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797071@esebe019.ntc.nokia.com> Thread-Topic: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNyGM8O2jEt3eO/QJCCyq+8ZmziBgAAHgDQ To: , Cc: , , , X-OriginalArrivalTime: 03 Sep 2003 12:54:05.0584 (UTC) FILETIME=[7519B100:01C3721A] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I agree with everything that Brian just posted. There is one small issue left: Should we require the user to always = input the domain name in a sip address (the @tutpro.com even if its a = local call). I'm too lazy to type it into my phone if I'm calling a = someone in the same domain (this is a handset configuration issue). If the handset enables you to just type the username part of a sip = address for local calls, then you have to tell it if you intension was = to dial 0401234567 or 0401234567 So it know to put user=3Dphone or not. /Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, September 03, 2003 3:41 PM > To: Khartabil Hisham (NMP/Helsinki); jh@tutpro.com > Cc: Richard.Stastny@oefeg.at; fluffy@cisco.com; > dean.willis@softarmor.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > I think you have been given the wrong answer. > Phone: 0401234567 > if dialed, you would enter the digits 0-4-1-2-3-4-5-6-7, > and the uac, if it did not know how to translate dial strings > to telephone numbers would send > 0401234567@localdomain; user=3Dphone >=20 > SIP: 0401234567@tutpro.com > if dialed, would result in the uac sending > 0401234567@tutpro.com >=20 > The original reason for user=3Dphone was to differentiate > between these two cases, where localdomain=3Dtutpro.com, > and it was intended that the resulting uas was different.=20 >=20 > I would say that the former results in a dial string, and > the latter does not. I think it is very useful for the > proxy to be able to know that the user part of the uri is > a dial string and not a phone number and not a username. >=20 > I think a phone number should be sent in a tel uri, at least > on a go forward basis, and not in a sip uri. If some proxy > has turned a phone number into a sip uri (by an enum dip for > example), then the result will be a sip uri which is NOT > a phone number, nor a dial string. This may or may not have > numeric username. A downstream proxy should be able to > differentiate all of these cases, so that, for example, > it does not invoke dial string to phone number processing, > or another enum dip. =20 >=20 > Brian >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, September 03, 2003 6:58 AM > > To: jh@tutpro.com > > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at;=20 > > fluffy@cisco.com; > > dean.willis@softarmor.com; sip@ietf.org > > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > We both live in Finland. You expect me to dial +358 every=20 > > time I call you? > >=20 > > > -----Original Message----- > > > From: ext Juha Heinanen [mailto:jh@tutpro.com] > > > Sent: Wednesday, September 03, 2003 1:31 PM > > > To: Khartabil Hisham (NMP/Helsinki) > > > Cc: Brian.Rosen@marconi.com; Richard.Stastny@oefeg.at;=20 > > > fluffy@cisco.com; > > > dean.willis@softarmor.com; sip@ietf.org > > > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with = ;user=3Dphone > > >=20 > > >=20 > > > hisham.khartabil@nokia.com writes: > > >=20 > > > > When if I hand you this on a business card: > > > >=20 > > > > Phone: 0401234567 > > > >=20 > > > > and one of your colleagues hands you this: > > > >=20 > > > > SIP: 0401234567@tutpro.com > > > >=20 > > > > What do you dial to call me and what do you dial to call your > > > > colleague, using your phone? How does your proxy tell the=20 > > > difference? > > >=20 > > > what would the phone network do if someone in india dials the=20 > > > number you > > > gave? it would do the same as my proxy: route the call to a > > > destination in a wrong local network or declare the destination > > > unreachable. > > >=20 > > > it is thus the responsibility of the user to figure out,=20 > how to turn > > > 0401234567 into something that is correctly routable by=20 > the proxy of > > > that user the user might, for example, try to figure out from the > > > address on the business card in which country the person=20 > > > lives and then > > > add the corresponding cc into the number. =20 > > >=20 > > > that is what people do every day when they have to deal with=20 > > > local phone > > > numbers in other regions. i don't understand why we=20 > > discuss this on a > > > mailing list of a standards body. > > >=20 > > > -- juha > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 09:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02747 for ; Wed, 3 Sep 2003 09:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXg7-00006R-Ur for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 09:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83DS7rl000345 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 09:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXg1-000054-5K; Wed, 03 Sep 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uXfq-0008WO-1R for sip@optimus.ietf.org; Wed, 03 Sep 2003 09:27:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02684 for ; Wed, 3 Sep 2003 09:27:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uXfo-0004y1-00 for sip@ietf.org; Wed, 03 Sep 2003 09:27:48 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19uXfn-0004xy-00 for sip@ietf.org; Wed, 03 Sep 2003 09:27:47 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19uXfc-0000Jy-00; Wed, 03 Sep 2003 16:27:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16213.60488.481004.475355@harjus.tutpro.com> Date: Wed, 3 Sep 2003 16:27:36 +0300 To: Cc: , , , , Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179706E@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179706E@esebe019.ntc.nokia.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com writes: > We both live in Finland. You expect me to dial +358 every time I call > you? no, if 0401234567 is in finland, but that was now know based on the information you gave. as i said, the user would need more info, such as the address, in order to figure out, how to call such a number. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 10:16:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07369 for ; Wed, 3 Sep 2003 10:16:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYQi-0002Qi-ED for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 10:16:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83EGGFh009334 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 10:16:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYQS-0002P9-Uo; Wed, 03 Sep 2003 10:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uYQE-0002Oe-6T for sip@optimus.ietf.org; Wed, 03 Sep 2003 10:15:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07073 for ; Wed, 3 Sep 2003 10:15:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uYQB-0006ZA-00 for sip@ietf.org; Wed, 03 Sep 2003 10:15:43 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uYQ9-0006YJ-00 for sip@ietf.org; Wed, 03 Sep 2003 10:15:41 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2003 07:27:05 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h83EF5lx025183; Wed, 3 Sep 2003 07:15:08 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACA90805; Wed, 3 Sep 2003 10:15:04 -0400 (EDT) Message-ID: <3F55F768.7070708@cisco.com> Date: Wed, 03 Sep 2003 10:15:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: Adam Roach , sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5DB5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >> > > It used to be that you could do the same in a tel uri, but we >> > > "fixed" that. >> > >> > ...meaning that, if we were to do nothing but rev 3261 with >> > updated references, using bare, unscoped digit strings with >> > "user=phone" would automatically become deprecated. >> >>How did we break it? Even in 2806 a uri like was >>illegal - it >>required a phone-context parameter. > > We "broke" it by explicitly declaring in 2806bis that the number > could NOT be a dial string. You would always have a context with > a dial string, the dial string passers were never unhappy requiring > a context in a tel uri. I'm afraid I don't find the added prohibition you do. I agree that the body of the tel url can't *be* a dial string, but I see no prohibition against it *containing* a dial string. It is all a matter of context. I think of the numbers I dial as phone numbers within the particular context my service provider provides. So I certainly don't see anything wrong with tel:1234;phone-context=mycontext.acme.com tel:911;phone-context=mycontext.acme.com or even tel:*69;phone-context=mycontext.acme.com Certainly these are valid according to the syntax of 2806bis. And they should be valid according to the semantics as well as long as the context is appropriately defined. >>AFAIK, the wording in 2543 and all its successors has always >>suggested >>that IF you transform from tel to sip you should add user=phone. But >>they have never stated the converse - that if you have a uri of form >> then the nnn should conform to 2806. > > I've never understood that user=phone was intended for tel to sip uri > conversion. Well, maybe not. But clearly a lot of people do, including me. Section 19.1.6 of 3261 is pretty clear: When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes sip:+358-555-1234567;postd=pp22@foo.com;user=phone ... > It was always supposed to be the differentiator between > a numeric username and a phone number or dial string. A little more than that. Section 19.1.1 includes the following: The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. 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. This clearly says that strings conforming to telephone-subscriber in 2806 can be used as the userpart of a sip url and SHOULD be disambiguated from user names by including user=phone. If a dial string can be encoded as a telephone-subscriber then this applies. >>As a result, normal dial strings have been representable as sip uris >>*without* user=phone. > > Well, I agree that they can be representable, but then if you don't > mark the uri as a dial string you re-introduce the problem of confusing > a dial string with a user name, and your expansion below, pointing out > that dial strings are not necessarily numeric makes this a worse problem. I agree with you that it is generally a bad idea to form a sip url from a dial string without including user=phone. >>Meanwhile, on this discussion as a whole, I think the real problem is >>when the UAC has a dial string and doesn't know the dial plan itself. >>The suggestion seems to be to patch it into a sip url and let >>some proxy >>fix it. For instance, maybe I dial 1234, and my UAC turns this into >> >> INVITE sip:1234@myproxy.com >> To: sip:1234@myproxy.com >> ... > > I'm not sure why you would use the word "patch", but yes, lots and lots > of phones do this, and are going to do this. Didn't mean anything special by patch. Use "insert" if you prefer. >>Then maybe myproxy turns this into: >> >> INVITE: sip:+19785551234@otherproxy.com;user=phone >> To: sip:1234@myproxy.com > > Well, I'm arguing that this is wrong, or at least we need to be > able to differentiate between a phone number and a dial string, > which user=phone COULD be used for (although I'm not sure that's > the best answer). I agree that it should be possible to disambiguate between a dial string and a phone number. In the example above this is possible because the dial string was in a sip url without user=phone, and the phone number was in a sip url with user=phone. But that still has the problem of ambiguity between dial string and username in the sip url. My solution to that is for both dial strings and phone numbers to be represented as 2806 telephone-subscribers. (In either tel urls or sip urls with user=phone.) These can be disambiguated from one another by using different forms of telephone-subscriber, in a variety of ways: - dial strings should always have a phone-context. In really dumb phones this can be a single statically configured value. In smarter phones there might be partial dial plans in the phone that yield different contexts. - the proxy that understands and translates the dial plan context could always general global numbers with no context, which would certainly disambiguate them. Or it could generate local urls with a different context. Or the translation could be stable, with the output of translation being itself a valid dial string. All of these approaches are workable. > I would really prefer that this example be wrong. > If the proxy knows how to expand a dial string to a phone number, > but does not understand how to route phone numbers, then it would > convert the dial string to a tel uri, and route that. Presumably, > a downstream proxy would understand how to turn the tel uri into > a routable sip uri, perhaps by an enum dip. In general I think this is a good approach. But I think there is flexibility in permitting the sip;user=phone representation as well. For instance, one proxy may want to insert a domain so that the call can be routed (perhaps multiple hops) according to that domain, and then at the end reach a device (e.g. gateway) that needs the telephone-subscriber representation. > If the proxy knew how to convert a phone number to a routable uri, > then it would do so, and it would NOT have a user=phone on the uri. > I would argue that it would be preferable to mark such a uri that > it was indeed a translated phone number, so that no more processing > was done by any further downstream proxies. I don't see that routable uri and telephone-subscriber representation of the userpart are mutually exclusive. >>The obvious solution to this is for the dial plan to be >>implemented in >>the UAC. Then the result of expanding the number via the >>dialplan can be >>included in both the To and request uris. > > I agree that it is a good solution, and I want it to be possible > to have this occur. The result would be a tel uri, unless you > want the phone to do the enum dip. I agree that in general this would be a tel: uri. But conversion to a sip uri containing the telephone-subscriber part, some domain name, and user=phone *could* be done by the phone or some downstream proxy. This would have to be a matter of local configuration, and assumes a relationship between the device doing the conversion and the domain of the resulting url. I find lots of people wanting to do this. One argument is to limit the set of devices that must understand how to deal with tel: uris. While I personally don't see a lot of benefit to this I don't see it as a battle worth fighting. >>If the UAC is too feeble to do that, then ideally the UAC >>would have its >>local proxy do the expansion and then use that in both the To and >>request URIs. Having the proxy return the translation in a >>3xx is almost >>the right thing. There are two issues with that: >> >>- how does proxy know to return 3xx rather than proxy? >> This is solvable via Request-Disposition from callerprefs. >> >>- how does the UAC know to replace both the request uri AND >>the To uri? >> This is a problem - normally on a 3xx the To should not be changed. >> Maybe a solution would be to define a new 3xx code that means >> exactly this. > > Seems like a good idea Lets see what others think. I believe there is a real problem that this fixes. >>Regarding usefulness of user=phone: >> >>I agree it is largely a matter of whether you think there can be a >>conflict between "regular" usernames and telephone numbers or >>dial strings. > > Yes, I think all three are different, and need to be disambiguated As stated above, I think they can all be disambiguated: - regular usernames use sip or sips urls without user=phone - both telephone numbers and dial strings use either tel urls or sip/sips urls with user=phone - dial strings always have a phone-context, with the particular phone context having semantics that specify how to expand the dial string into a phone number. - phone numbers are either global or else have a phone context with appropriate semantics for identification of the intended device. This requires knowledge of the context to distinguish between a phone number and a dial string, but that isn't a problem to me. >>The best solution to me is for the UAC to be configured to >>always turn >>dial strings into some kind of valid telephone-subscriber >>string. If it >>can't turn it into a global-phone-number, then it should turn >>it into a >>local-phone-number, using some configured phone-context. When >>there is >>no better solution, it can simply paste a phone-context onto >>the end of >>the dial string. > > You can't send such a thing in a tel uri. You can send it in > a username part of a sip uri, but I think it should be marked > as a dial string Why can't I do this as a tel url, or as a sip url with user=phone? > No, the wording of 2806 bis explicitly forbids the number to be > a dial string. It has to be a phone number (in the context). I'm not asking it to *be* a dial string, only to contain one. Where do you see this forbidden? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 10:55:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12296 for ; Wed, 3 Sep 2003 10:55:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZ2R-0004b5-Ah for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 10:55:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83EtFip017665 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 10:55:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZ2E-0004aH-P1; Wed, 03 Sep 2003 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZ1l-0004ZG-LK for sip@optimus.ietf.org; Wed, 03 Sep 2003 10:54:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12178 for ; Wed, 3 Sep 2003 10:54:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZ1i-0000cA-00 for sip@ietf.org; Wed, 03 Sep 2003 10:54:30 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uZ1h-0000aZ-00 for sip@ietf.org; Wed, 03 Sep 2003 10:54:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06162; Wed, 3 Sep 2003 10:53:57 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24672; Wed, 3 Sep 2003 10:53:58 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 10:53:57 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DBF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 10:53:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , What part of: "Dial strings are beyond the scope of this document." is not clear? cf draft-ietf-iptel-rfc2806bis-02 There are at least two ways one can envision making a telephone connection. In the first approach, a URI contains the dial string, which is then passed to an entity that can reproduce the actions ... Another approach has the URI specify the telephone number, which can be either globally unique or only be valid within a local context. ... The document below assumes the second model. I think it is crystal clear that a 2806bis compliant UA cannot put a dial string in a tel uri. That was the intention. The folks in iptel who wrote that seemed quite clear that dial strings were a quagmire that they didn't want to walk in, and they defined a tel uri as not containing a dial string. That's okay, but we need a way to pass a dial string, and know it's a dial string, in a sip uri. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, September 03, 2003 10:15 AM > To: Rosen, Brian > Cc: Adam Roach; sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > > Rosen, Brian wrote: > >> > > It used to be that you could do the same in a tel uri, but we > >> > > "fixed" that. > >> > > >> > ...meaning that, if we were to do nothing but rev 3261 with > >> > updated references, using bare, unscoped digit strings with > >> > "user=phone" would automatically become deprecated. > >> > >>How did we break it? Even in 2806 a uri like was > >>illegal - it > >>required a phone-context parameter. > > > > We "broke" it by explicitly declaring in 2806bis that the number > > could NOT be a dial string. You would always have a context with > > a dial string, the dial string passers were never unhappy requiring > > a context in a tel uri. > > I'm afraid I don't find the added prohibition you do. > > I agree that the body of the tel url can't *be* a dial > string, but I see > no prohibition against it *containing* a dial string. > > It is all a matter of context. I think of the numbers I dial as phone > numbers within the particular context my service provider > provides. So I > certainly don't see anything wrong with > > tel:1234;phone-context=mycontext.acme.com > tel:911;phone-context=mycontext.acme.com > or even > tel:*69;phone-context=mycontext.acme.com > > Certainly these are valid according to the syntax of 2806bis. > And they > should be valid according to the semantics as well as long as the > context is appropriately defined. > > >>AFAIK, the wording in 2543 and all its successors has always > >>suggested > >>that IF you transform from tel to sip you should add > user=phone. But > >>they have never stated the converse - that if you have a > uri of form > >> then the nnn should conform to 2806. > > > > I've never understood that user=phone was intended for tel > to sip uri > > conversion. > > Well, maybe not. But clearly a lot of people do, including > me. Section > 19.1.6 of 3261 is pretty clear: > > When a tel URL (RFC 2806 [9]) is converted to a SIP or > SIPS URI, the > entire telephone-subscriber portion of the tel URL, including any > parameters, is placed into the userinfo part of the SIP > or SIPS URI. > > Thus, tel:+358-555-1234567;postd=pp22 becomes > > sip:+358-555-1234567;postd=pp22@foo.com;user=phone > ... > > > It was always supposed to be the differentiator between > > a numeric username and a phone number or dial string. > > A little more than that. > > Section 19.1.1 includes the following: > > The set of valid telephone-subscriber strings is a subset of > valid user strings. The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. 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. > > This clearly says that strings conforming to telephone-subscriber in > 2806 can be used as the userpart of a sip url and SHOULD be > disambiguated from user names by including user=phone. > > If a dial string can be encoded as a telephone-subscriber > then this applies. > > >>As a result, normal dial strings have been representable as > sip uris > >>*without* user=phone. > > > > Well, I agree that they can be representable, but then if you don't > > mark the uri as a dial string you re-introduce the problem > of confusing > > a dial string with a user name, and your expansion below, > pointing out > > that dial strings are not necessarily numeric makes this a > worse problem. > > I agree with you that it is generally a bad idea to form a > sip url from > a dial string without including user=phone. > > >>Meanwhile, on this discussion as a whole, I think the real > problem is > >>when the UAC has a dial string and doesn't know the dial > plan itself. > >>The suggestion seems to be to patch it into a sip url and let > >>some proxy > >>fix it. For instance, maybe I dial 1234, and my UAC turns this into > >> > >> INVITE sip:1234@myproxy.com > >> To: sip:1234@myproxy.com > >> ... > > > > I'm not sure why you would use the word "patch", but yes, > lots and lots > > of phones do this, and are going to do this. > > Didn't mean anything special by patch. Use "insert" if you prefer. > > >>Then maybe myproxy turns this into: > >> > >> INVITE: sip:+19785551234@otherproxy.com;user=phone > >> To: sip:1234@myproxy.com > > > > Well, I'm arguing that this is wrong, or at least we need to be > > able to differentiate between a phone number and a dial string, > > which user=phone COULD be used for (although I'm not sure that's > > the best answer). > > I agree that it should be possible to disambiguate between a > dial string > and a phone number. > > In the example above this is possible because the dial string > was in a > sip url without user=phone, and the phone number was in a sip > url with > user=phone. > > But that still has the problem of ambiguity between dial string and > username in the sip url. > > My solution to that is for both dial strings and phone numbers to be > represented as 2806 telephone-subscribers. (In either tel urls or sip > urls with user=phone.) These can be disambiguated from one another by > using different forms of telephone-subscriber, in a variety of ways: > > - dial strings should always have a phone-context. In really > dumb phones > this can be a single statically configured value. In smarter phones > there might be partial dial plans in the phone that yield different > contexts. > > - the proxy that understands and translates the dial plan context > could always general global numbers with no context, which would > certainly disambiguate them. Or it could generate local urls > with a different context. Or the translation could be stable, > with the output of translation being itself a valid dial string. > All of these approaches are workable. > > > I would really prefer that this example be wrong. > > If the proxy knows how to expand a dial string to a phone number, > > but does not understand how to route phone numbers, then it would > > convert the dial string to a tel uri, and route that. Presumably, > > a downstream proxy would understand how to turn the tel uri into > > a routable sip uri, perhaps by an enum dip. > > In general I think this is a good approach. But I think there is > flexibility in permitting the sip;user=phone representation as well. > > For instance, one proxy may want to insert a domain so that > the call can > be routed (perhaps multiple hops) according to that domain, > and then at > the end reach a device (e.g. gateway) that needs the > telephone-subscriber representation. > > > If the proxy knew how to convert a phone number to a routable uri, > > then it would do so, and it would NOT have a user=phone on the uri. > > I would argue that it would be preferable to mark such a uri that > > it was indeed a translated phone number, so that no more processing > > was done by any further downstream proxies. > > I don't see that routable uri and telephone-subscriber > representation of > the userpart are mutually exclusive. > > >>The obvious solution to this is for the dial plan to be > >>implemented in > >>the UAC. Then the result of expanding the number via the > >>dialplan can be > >>included in both the To and request uris. > > > > I agree that it is a good solution, and I want it to be possible > > to have this occur. The result would be a tel uri, unless you > > want the phone to do the enum dip. > > I agree that in general this would be a tel: uri. But conversion to a > sip uri containing the telephone-subscriber part, some domain > name, and > user=phone *could* be done by the phone or some downstream > proxy. This > would have to be a matter of local configuration, and assumes a > relationship between the device doing the conversion and the > domain of > the resulting url. > > I find lots of people wanting to do this. One argument is to > limit the > set of devices that must understand how to deal with tel: > uris. While I > personally don't see a lot of benefit to this I don't see it > as a battle > worth fighting. > > >>If the UAC is too feeble to do that, then ideally the UAC > >>would have its > >>local proxy do the expansion and then use that in both the To and > >>request URIs. Having the proxy return the translation in a > >>3xx is almost > >>the right thing. There are two issues with that: > >> > >>- how does proxy know to return 3xx rather than proxy? > >> This is solvable via Request-Disposition from callerprefs. > >> > >>- how does the UAC know to replace both the request uri AND > >>the To uri? > >> This is a problem - normally on a 3xx the To should not > be changed. > >> Maybe a solution would be to define a new 3xx code that means > >> exactly this. > > > > Seems like a good idea > > Lets see what others think. I believe there is a real problem > that this > fixes. > > >>Regarding usefulness of user=phone: > >> > >>I agree it is largely a matter of whether you think there can be a > >>conflict between "regular" usernames and telephone numbers or > >>dial strings. > > > > Yes, I think all three are different, and need to be disambiguated > > As stated above, I think they can all be disambiguated: > > - regular usernames use sip or sips urls without user=phone > - both telephone numbers and dial strings use either tel urls > or sip/sips urls with user=phone > - dial strings always have a phone-context, with the particular > phone context having semantics that specify how to expand the > dial string into a phone number. > - phone numbers are either global or else have a phone context > with appropriate semantics for identification of the > intended device. > > This requires knowledge of the context to distinguish between a phone > number and a dial string, but that isn't a problem to me. > > >>The best solution to me is for the UAC to be configured to > >>always turn > >>dial strings into some kind of valid telephone-subscriber > >>string. If it > >>can't turn it into a global-phone-number, then it should turn > >>it into a > >>local-phone-number, using some configured phone-context. When > >>there is > >>no better solution, it can simply paste a phone-context onto > >>the end of > >>the dial string. > > > > You can't send such a thing in a tel uri. You can send it in > > a username part of a sip uri, but I think it should be marked > > as a dial string > > Why can't I do this as a tel url, or as a sip url with user=phone? > > > No, the wording of 2806 bis explicitly forbids the number to be > > a dial string. It has to be a phone number (in the context). > > I'm not asking it to *be* a dial string, only to contain one. > Where do > you see this forbidden? > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 13:23:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22620 for ; Wed, 3 Sep 2003 13:23:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubLe-0003xW-N8 for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 13:23:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83HNEtm015214 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 13:23:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubLR-0003wR-U1; Wed, 03 Sep 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubKX-0003us-4l for sip@optimus.ietf.org; Wed, 03 Sep 2003 13:22:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22563 for ; Wed, 3 Sep 2003 13:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ubKV-0004gd-00 for sip@ietf.org; Wed, 03 Sep 2003 13:22:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ubKU-0004gO-00 for sip@ietf.org; Wed, 03 Sep 2003 13:22:02 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Sep 2003 10:21:32 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h83HLTlv020329; Wed, 3 Sep 2003 10:21:30 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACB11263; Wed, 3 Sep 2003 13:21:28 -0400 (EDT) Message-ID: <3F562318.1020604@cisco.com> Date: Wed, 03 Sep 2003 13:21:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5DBF@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > What part of: > > "Dial strings are beyond the scope of this document." > is not clear? To me, "out of scope" is different than "can't be used for". (It is akin to the off-label use of drugs - for purposes other than what they are marketed for.) So, if I can describe a phone context in which dial strings can be considered to be phone numbers, then I can encode dial strings that way. If necessary, we could write a separate draft that explicitly describes doing so. I don't think it is necessary - it is up to the phone to decide how to map dial strings into numbers. If it happens to do so by simply attaching a phone context to the dial string then that is its business. This is just a degenerate case of the phone containing a dial plan. > cf draft-ietf-iptel-rfc2806bis-02 > > There are at least two ways one can envision making a telephone > connection. In the first approach, a URI contains the dial string, > which is then passed to an entity that can reproduce the actions > ... > > Another approach has the URI specify the telephone number, which can > be either globally unique or only be valid within a local context. > ... The document below assumes the second model. > > I think it is crystal clear that a 2806bis compliant UA cannot > put a dial string in a tel uri. Can you describe to me what sorts of transformations to the dial string are acceptable for inclusion in a tel uri, vs those that are not? Apparently you think the null transformation isn't acceptable. What if I put a "." in front of the dial string? Would that make you feel better? > That was the intention. > The folks in iptel who wrote that seemed quite clear that dial strings > were a quagmire that they didn't want to walk in, and they defined > a tel uri as not containing a dial string. Local numbers with contexts are also a quagmire that they did walk into. What I am suggesting simply leverages that in what I am arguing is a compliant way. > That's okay, but we need a way to pass a dial string, and know > it's a dial string, in a sip uri. What I am suggesting requires no changes, and allows those who need to know with a way to distinguish dial strings. Paul P.S. What I am suggesting requires use of a phone-context within which a valid dial string has an unambiguous meaning. But this can always be accomplished. If need be, the UAC can use its own FQDN as the phone-context, so that everything including its own private speed dial numbers have unique definitions. So I might have something like: INVITE tel:*3;phone-context=myphone.acme.com To: tel:*3;phone-context=myphone.acme.com From: sip:line1@myphone.acme.com Route: sip:proxy.acme.com;lr This would go off to proxy.acme.com, which would apply the dial plan for myphone.acme.com. It would look up my private definition for *3 and substitute it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 13:37:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24747 for ; Wed, 3 Sep 2003 13:37:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubZ9-0004n5-TY for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 13:37:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83HbBqF018354 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 13:37:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubZ1-0004fg-Hr; Wed, 03 Sep 2003 13:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ubYf-0004ei-Jx for sip@optimus.ietf.org; Wed, 03 Sep 2003 13:36:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24638 for ; Wed, 3 Sep 2003 13:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ubYd-0005fM-00 for sip@ietf.org; Wed, 03 Sep 2003 13:36:39 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19ubYc-0005cS-00 for sip@ietf.org; Wed, 03 Sep 2003 13:36:38 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11724; Wed, 3 Sep 2003 13:36:07 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17581; Wed, 3 Sep 2003 13:36:08 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 13:36:08 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DC6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 13:36:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I don't have much problem putting a dial string in a tel uri except for the words that seem to me to indicate that it's not allowed. I actually argued with Henning et al to explicitly allow a dial string, but they thought it was too much of a quagmire. I would prefer to have a rule/convention/whatever that differentiated a dialstring from a phone number, but I actually can't think of any case where there is an overlap (that is, where a dial string in a context could be a number in the same context but not the same destination). It would seem to me, however, that given the words in 2806bis, it has to change, or an RFC has to be created that allows dial strings in a tel uri. I don't think you can finesse it any other way. Do you agree that there is a need to distinguish a translated tel uri (which would be a sip uri which may have a numeric username) from a dialstring or an untranslated number? How would you propose to do that? Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, September 03, 2003 1:21 PM > To: Rosen, Brian > Cc: sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > > Rosen, Brian wrote: > > What part of: > > > > "Dial strings are beyond the scope of this document." > > is not clear? > > To me, "out of scope" is different than "can't be used for". > (It is akin > to the off-label use of drugs - for purposes other than what they are > marketed for.) > > So, if I can describe a phone context in which dial strings can be > considered to be phone numbers, then I can encode dial > strings that way. > > If necessary, we could write a separate draft that explicitly > describes > doing so. I don't think it is necessary - it is up to the phone to > decide how to map dial strings into numbers. If it happens to > do so by > simply attaching a phone context to the dial string then that is its > business. > > This is just a degenerate case of the phone containing a dial plan. > > > cf draft-ietf-iptel-rfc2806bis-02 > > > > There are at least two ways one can envision making a telephone > > connection. In the first approach, a URI contains the > dial string, > > which is then passed to an entity that can reproduce the actions > > ... > > > > Another approach has the URI specify the telephone > number, which can > > be either globally unique or only be valid within a > local context. > > ... The document below assumes the second model. > > > > I think it is crystal clear that a 2806bis compliant UA cannot > > put a dial string in a tel uri. > > Can you describe to me what sorts of transformations to the > dial string > are acceptable for inclusion in a tel uri, vs those that are not? > > Apparently you think the null transformation isn't > acceptable. What if I > put a "." in front of the dial string? Would that make you > feel better? > > > That was the intention. > > The folks in iptel who wrote that seemed quite clear that > dial strings > > were a quagmire that they didn't want to walk in, and they defined > > a tel uri as not containing a dial string. > > Local numbers with contexts are also a quagmire that they did > walk into. > What I am suggesting simply leverages that in what I am arguing is a > compliant way. > > > That's okay, but we need a way to pass a dial string, and know > > it's a dial string, in a sip uri. > > What I am suggesting requires no changes, and allows those > who need to > know with a way to distinguish dial strings. > > Paul > > P.S. What I am suggesting requires use of a phone-context > within which a > valid dial string has an unambiguous meaning. But this can always be > accomplished. If need be, the UAC can use its own FQDN as the > phone-context, so that everything including its own private > speed dial > numbers have unique definitions. So I might have something like: > > INVITE tel:*3;phone-context=myphone.acme.com > To: tel:*3;phone-context=myphone.acme.com > From: sip:line1@myphone.acme.com > Route: sip:proxy.acme.com;lr > > This would go off to proxy.acme.com, which would apply the > dial plan for > myphone.acme.com. It would look up my private definition for *3 and > substitute it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 17:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08854 for ; Wed, 3 Sep 2003 17:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uf9g-0005kG-7d for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 17:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83LR8bm022080 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 17:27:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uf9b-0005jR-KR; Wed, 03 Sep 2003 17:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uf9B-0005iL-MV for sip@optimus.ietf.org; Wed, 03 Sep 2003 17:26:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08792 for ; Wed, 3 Sep 2003 17:26:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uf99-0002KY-00 for sip@ietf.org; Wed, 03 Sep 2003 17:26:35 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uf97-0002Jn-00 for sip@ietf.org; Wed, 03 Sep 2003 17:26:33 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Sep 2003 14:26:02 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h83LQ0t0009865; Wed, 3 Sep 2003 14:26:01 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACB40106; Wed, 3 Sep 2003 17:25:59 -0400 (EDT) Message-ID: <3F565C67.1090803@cisco.com> Date: Wed, 03 Sep 2003 17:25:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5DC6@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I don't have much problem putting a dial string in a tel uri > except for the words that seem to me to indicate that it's > not allowed. As I said in prior message, I don't think 2806bis disallows this - it only declares it out of scope. Putting it back in scope could be done by another draft, but I also think it can be put in scope by policy of an endpoint without violating the letter of the draft. > I actually argued with Henning et al to explicitly > allow a dial string, but they thought it was too much of > a quagmire. I would prefer to have a rule/convention/whatever > that differentiated a dialstring from a phone number, but I > actually can't think of any case where there is an overlap > (that is, where a dial string in a context could be a > number in the same context but not the same destination). Again, as I said in prior message, I think this can simply be an issue for the owners of the context to resolve: - If there is some conflict between the format of dial strings and the translated results, then the node doing the translation should change the context in the translation. - If there is no conflict between dial strings and the translated results, then the translator can leave the context unchanged. > It would seem to me, however, that given the words in > 2806bis, it has to change, or an RFC has to be created that > allows dial strings in a tel uri. I don't think you can finesse > it any other way. I am trying. Maybe you don't agree my finesse is valid, but you didn't answer my questions that were intended to highlight the finesse: >>Can you describe to me what sorts of transformations to the >>dial string are acceptable for inclusion in a tel uri, vs those that >>are not? >> >>Apparently you think the null transformation isn't acceptable. >>What if I put a "." in front of the dial string? Would that make you >>feel better? > Do you agree that there is a need to distinguish a translated > tel uri (which would be a sip uri which may have a numeric username) > from a dialstring or an untranslated number? How would you > propose to do that? I agree that any node which understands the phone context must be able to make this distinction if it matters. (It doesn't always matter, if translation is idempotent.) I would propose to do that by having the node doing the translation change the context, from one that indicates dial strings requiring translation to one indicating translated numbers not requiring further translation. Note that a translation that yields a global number will remove the context, which serves the purpose. So, some contexts identify dial strings, some don't. The nodes that understand the context can know which it is. This is just one aspect of understanding the context. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 19:44:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18004 for ; Wed, 3 Sep 2003 19:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhIK-00034h-98 for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 19:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83NiCL3011815 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 19:44:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhIA-000341-2O; Wed, 03 Sep 2003 19:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhHp-00033W-Sa for sip@optimus.ietf.org; Wed, 03 Sep 2003 19:43:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17947 for ; Wed, 3 Sep 2003 19:43:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uhHn-0005op-00 for sip@ietf.org; Wed, 03 Sep 2003 19:43:39 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx with esmtp (Exim 4.12) id 19uhHn-0005nf-00 for sip@ietf.org; Wed, 03 Sep 2003 19:43:39 -0400 Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-8.00) id AC491F1028E; Wed, 03 Sep 2003 19:42:01 -0400 Message-ID: <002601c37275$19c38550$2300000a@BPenfield> From: "Bob Penfield" To: References: <1061561455.1787.9.camel@RjS.localdomain> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 19:42:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Getting back to the problem Robert described in the original mail, the interoperability problems are a result of that fact that what is a valid userinfo part of a SIP URL with a user=phone parameter has steadily gotten stricter without any consideration for backwards compatibility. The specific problem he described resulted because a SIP URL created with 2543 rules was rejected by a server applying 3261/2806 rules. The new 2806bis rules are even stricter. I have no problem with those rules for tel-URLs. In spite of the lack of normative text on user-phone, the statements in 2543 and 3261 to the effect that it is used to distinguish phone numbers from usernames leads one to the reasonable conclusion that when it is present, the 'telephone-subscriber' BNF applies. This is the conclusion that we and a number of our vendors and customers came to when we ran into interop problems. However, its not that simple since a 'telephone-subscriber' keeps changing. >From some of the posting on this subject, there seems to be value in distinguishing a telephone number from username that happens to look like a telephone number without requiring that the user part be a tel-URL. What I would propose is that while we make the rules for user=phone clearer, they ought to be closer to the 2543 rules which in my experience a lot of existing implementation seem to follow. If the userinfo begins with "+" or contains a phone-context, then it is reasonable to interpret it as a tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of 2543) should apply. A server which is not responsible for the domain of the SIP URL should not reject a SIP URL because phone-context is missing. Actually, I believe it is reasonable to take the SIP URL host part as the 'default' phone-context when it is missing. Also, we could add 'user=tel' for userinfo that MUST be tel-URLs. In that case, rejecting a local number without a phone-context would be perfectly reasonable. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 19:49:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18345 for ; Wed, 3 Sep 2003 19:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhN1-0003PE-90 for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 19:49:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Nn3wj013056 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 19:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhMz-0003O7-BW; Wed, 03 Sep 2003 19:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhMo-0003NM-CM for sip@optimus.ietf.org; Wed, 03 Sep 2003 19:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18293 for ; Wed, 3 Sep 2003 19:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uhMm-00062c-00 for sip@ietf.org; Wed, 03 Sep 2003 19:48:48 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19uhMl-00062Z-00 for sip@ietf.org; Wed, 03 Sep 2003 19:48:47 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h83Nmmc6032551; Wed, 3 Sep 2003 19:48:48 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 19:55:20 -0400 Message-ID: <000e01c37276$d5b62fa0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3F551306.1000007@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > ...meaning that, if we were to do nothing but rev 3261 with > > updated references, using bare, unscoped digit strings with > > "user=phone" would automatically become deprecated. > > How did we break it? Even in 2806 a uri > like was illegal - it > required a phone-context parameter. RFC 2806 does not require it; section 2.5.2 lists it at SHOULD strength. And RFC 3398 section 12 mentions the following: " When the '+' sign is not present, but a telephone number is represented by the user portion of the URI, the SIP URI SHOULD contain the optional ';user=phone' parameter; e.g., To: sip:83000@sip.example.net;user=phone " And because there are many deployments that followed the SHOULD of RFC 3398 instead of the SHOULD of RFC 2806, it is going to be a pain to start interworking with devices that intend to return a 400 response because of the MUST mentioned in 2806bis. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 21:03:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22242 for ; Wed, 3 Sep 2003 21:03:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uiWr-0006Jx-5Y for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 21:03:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8413H9Z024298 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 21:03:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uiWb-0006JJ-Nm; Wed, 03 Sep 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uiWS-0006If-M1 for sip@optimus.ietf.org; Wed, 03 Sep 2003 21:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22191 for ; Wed, 3 Sep 2003 21:02:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uiWQ-0000a5-00 for sip@ietf.org; Wed, 03 Sep 2003 21:02:50 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uiWO-0000ZD-00 for sip@ietf.org; Wed, 03 Sep 2003 21:02:49 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h84122F17410; Wed, 3 Sep 2003 20:02:02 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 18:02:03 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AA88A03@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Paul Kyzivat'" , "'Rosen, Brian'" Cc: "'sip@ietf.org'" Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 18:02:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37280.252F2876" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37280.252F2876 Content-Type: text/plain > If necessary, we could write a separate draft that explicitly > describes > doing so. I don't think it is necessary - it is up to the phone to > decide how to map dial strings into numbers. If it happens to > do so by > simply attaching a phone context to the dial string then that is its > business. I agree. In fact, I tought I tought that was made pretty clear at the last meeting. > P.S. What I am suggesting requires use of a phone-context > within which a > valid dial string has an unambiguous meaning. But this can always be > accomplished. If need be, the UAC can use its own FQDN as the > phone-context, so that everything including its own private > speed dial > numbers have unique definitions. So I might have something like: > > INVITE tel:*3;phone-context=myphone.acme.com > To: tel:*3;phone-context=myphone.acme.com > From: sip:line1@myphone.acme.com > Route: sip:proxy.acme.com;lr > > This would go off to proxy.acme.com, which would apply the > dial plan for > myphone.acme.com. It would look up my private definition for *3 and > substitute it. In general, really what we should be recommending to SIP phone manufacturers is the ability for a phone to be configured both with the FQDN of its proxy, and an arbitrary phone-context for potentially varying types of numbers. One of those types of numbers can be an unqualified number (which we sometimes call dial string). If the phone-context for those numbers is the Domain name of the proxy (meaning all phones associated with that proxy have the same dialing plan), that's fine. If the phone-context is unique per phone, that's fine too (but more complex for the proxy): it would allow for dial plan to vary per phone. If it is another phone-context (as per 2806), then it can have a different scope. The important is that the phone is configurabled with an arbitrary phone-context string corresponding to an "unqualified number" (a.k.a., "dialed string", "unprocessed" string, etc.). That will allow the "generic" SIP phone to be used in any environment. (Of course, a smarter phone could do the +CC URI, or even have additional phone contexes for extensions, or other private number). ------_=_NextPart_001_01C37280.252F2876 Content-Type: text/html RE: AW: [Sip] SIPIT Interop problem with ;user=phone

> If necessary, we could write a separate draft that explicitly
> describes
> doing so. I don't think it is necessary - it is up to the phone to
> decide how to map dial strings into numbers. If it happens to
> do so by
> simply attaching a phone context to the dial string then that is its
> business.

I agree. In fact, I tought I tought that was made pretty clear at the
last meeting.

<stuff deleted>


> P.S. What I am suggesting requires use of a phone-context
> within which a
> valid dial string has an unambiguous meaning. But this can always be
> accomplished. If need be, the UAC can use its own FQDN as the
> phone-context, so that everything including its own private
> speed dial
> numbers have unique definitions. So I might have something like:
>
>       INVITE tel:*3;phone-context=myphone.acme.com
>       To: tel:*3;phone-context=myphone.acme.com
>       From: sip:line1@myphone.acme.com
>       Route: sip:proxy.acme.com;lr
>
> This would go off to proxy.acme.com, which would apply the
> dial plan for
> myphone.acme.com. It would look up my private definition for *3 and
> substitute it.


In general, really what we should be recommending to SIP phone manufacturers
is the ability for a phone to be configured both with the FQDN of its proxy, and
an arbitrary phone-context for potentially varying types of numbers. One of those
types of numbers can be an unqualified number (which we sometimes call
dial string). If the phone-context for those numbers is the Domain name of
the proxy (meaning all phones associated with that proxy have the same dialing plan),
that's fine. If the phone-context is unique per phone, that's fine too (but
more complex for the proxy): it would allow for dial plan to vary per phone. If it
is another phone-context (as per 2806), then it can have a different scope.

The important is that the phone is configurabled with an arbitrary phone-context
string corresponding to an "unqualified number" (a.k.a., "dialed string",
"unprocessed" string, etc.).

That will allow the "generic" SIP phone to be used in any environment.

(Of course, a smarter phone could do the +CC URI, or even have additional phone
contexes for extensions, or other private number).


------_=_NextPart_001_01C37280.252F2876-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 3 21:23:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23187 for ; Wed, 3 Sep 2003 21:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uiq4-0007D5-HM for sip-archive@odin.ietf.org; Wed, 03 Sep 2003 21:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h841N8cW027676 for sip-archive@odin.ietf.org; Wed, 3 Sep 2003 21:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uipx-0007Bp-Jy; Wed, 03 Sep 2003 21:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uip0-0007Ay-Bl for sip@optimus.ietf.org; Wed, 03 Sep 2003 21:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23133 for ; Wed, 3 Sep 2003 21:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uiox-0001AI-00 for sip@ietf.org; Wed, 03 Sep 2003 21:21:59 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uiow-00019l-00 for sip@ietf.org; Wed, 03 Sep 2003 21:21:58 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h841L9F18506; Wed, 3 Sep 2003 20:21:09 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 18:21:10 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AA88A3A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Paul Kyzivat'" , "'Rosen, Brian'" Cc: "'Adam Roach'" , "'sip@ietf.org'" Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 3 Sep 2003 18:21:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37282.D25BB4EA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37282.D25BB4EA Content-Type: text/plain > > I've never understood that user=phone was intended for tel > to sip uri > > conversion. > > Well, maybe not. But clearly a lot of people do, including > me. Section > 19.1.6 of 3261 is pretty clear: > > When a tel URL (RFC 2806 [9]) is converted to a SIP or > SIPS URI, the > entire telephone-subscriber portion of the tel URL, including any > parameters, is placed into the userinfo part of the SIP > or SIPS URI. This is fairly important. It is also stated in the BNF in note on page 223 that the telephone-subscriber definition is as per RFC2806. What is not explicitely said, but probably should, is that having a URI with a user-info composed with a telephone-subscriber (as opposed to a user), as per the BNF definition, it means that the user=phone user-param needs to be included. This is somewhat implicit in the examples in 19.1.6, but it should probably be more explicit. And we should probably clarify that you user=phone shouldn't be used for other purposes, such as saying that the end-device looks like a phone. I've asked the same question a few months ago on this list and the answer I got (from Jonathan Rosenberg if my memory serves me right) was that indeed having user=phone user-param included in the SIP-URI meant that the userinfo included a telephone-subscriber and not a user. I think we should stick to this, and make it explicit in RFC3261. This would clarify that user=phone means that 2806 format is used in the SIP-URI, and not that the user is talking into a "physical" phone. ------_=_NextPart_001_01C37282.D25BB4EA Content-Type: text/html RE: AW: [Sip] SIPIT Interop problem with ;user=phone

> > I've never understood that user=phone was intended for tel
> to sip uri
> > conversion.
>
> Well, maybe not. But clearly a lot of people do, including
> me. Section
> 19.1.6 of 3261 is pretty clear:
>
>     When a tel URL (RFC 2806 [9]) is converted to a SIP or
> SIPS URI, the
>     entire telephone-subscriber portion of the tel URL, including any
>     parameters, is placed into the userinfo part of the SIP
> or SIPS URI.

This is fairly important. It is also stated in the BNF in note on page 223
that the telephone-subscriber definition is as per RFC2806.

What is not explicitely said, but probably should, is that having
a URI with a user-info composed with a telephone-subscriber (as opposed
to a user), as per the BNF definition, it means that the user=phone
user-param needs to be included. This is somewhat implicit in the examples
in 19.1.6, but it should probably be more explicit. And we should probably
clarify that you user=phone shouldn't be used for other purposes, such as
saying that the end-device looks like a phone.

I've asked the same question a few months ago on this list and the answer
I got (from Jonathan Rosenberg if my memory serves me right) was that indeed having
user=phone user-param included in the SIP-URI meant that the userinfo included a
telephone-subscriber and not a user.

I think we should stick to this, and make it explicit in RFC3261. This would
clarify that user=phone means that 2806 format is used in the SIP-URI, and not
that the user is talking into a "physical" phone.

------_=_NextPart_001_01C37282.D25BB4EA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 06:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08652 for ; Thu, 4 Sep 2003 06:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur8x-00082I-34 for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 06:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84AFBrp030886 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 06:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur8p-00081G-3U; Thu, 04 Sep 2003 06:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur8F-000802-1N for sip@optimus.ietf.org; Thu, 04 Sep 2003 06:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08578 for ; Thu, 4 Sep 2003 06:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ur8B-0006hd-00 for sip@ietf.org; Thu, 04 Sep 2003 06:14:23 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19ur8A-0006ha-00 for sip@ietf.org; Thu, 04 Sep 2003 06:14:22 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h84AEG31015337; Thu, 4 Sep 2003 12:14:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 4 Sep 2003 12:15:42 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 4 Sep 2003 12:14:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I would support Bob's proposal, saying that a "+" indicates global-phone-number, according to RFC2806(or bis). I don't think there would be any backward compability issues, because I doubt anyone is using "+" for any other purpose - at least not as the first character of the user part. Of course, nodes that really REQUIRE user=phone to be present, in order to accept the request in the first, place would have to be changed. Of course, user=tel could also be used, but I really see no use for that if the "+" rule applies. Also, user=tel COULD cause backward compability issues. Then, since there doesn't seem to be an agreement on what user=phone really means, related BOTH to the userpart syntax and the message routing, we could remove it completely. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: 4. syyskuuta 2003 2:43 > To: sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > Getting back to the problem Robert described in the original mail, the > interoperability problems are a result of that fact that what > is a valid > userinfo part of a SIP URL with a user=phone parameter has > steadily gotten > stricter without any consideration for backwards > compatibility. The specific > problem he described resulted because a SIP URL created with > 2543 rules was > rejected by a server applying 3261/2806 rules. The new > 2806bis rules are > even stricter. I have no problem with those rules for tel-URLs. > > In spite of the lack of normative text on user-phone, the > statements in 2543 > and 3261 to the effect that it is used to distinguish phone > numbers from > usernames leads one to the reasonable conclusion that when it > is present, > the 'telephone-subscriber' BNF applies. This is the > conclusion that we and a > number of our vendors and customers came to when we ran into interop > problems. > > However, its not that simple since a 'telephone-subscriber' > keeps changing. > > >From some of the posting on this subject, there seems to be value in > distinguishing a telephone number from username that happens > to look like a > telephone number without requiring that the user part be a > tel-URL. What I > would propose is that while we make the rules for user=phone > clearer, they > ought to be closer to the 2543 rules which in my experience a lot of > existing implementation seem to follow. If the userinfo > begins with "+" or > contains a phone-context, then it is reasonable to interpret it as a > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > 2543) should > apply. A server which is not responsible for the domain of the SIP URL > should not reject a SIP URL because phone-context is missing. > Actually, I > believe it is reasonable to take the SIP URL host part as the > 'default' > phone-context when it is missing. > > Also, we could add 'user=tel' for userinfo that MUST be > tel-URLs. In that > case, rejecting a local number without a phone-context would > be perfectly > reasonable. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 07:09:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11856 for ; Thu, 4 Sep 2003 07:09:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19urzH-0001uv-HK for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 07:09:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84B9FFW007370 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 07:09:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19urz4-0001uL-Tb; Thu, 04 Sep 2003 07:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uryn-0001ti-AO for sip@optimus.ietf.org; Thu, 04 Sep 2003 07:08:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11811 for ; Thu, 4 Sep 2003 07:08:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uryi-0001qQ-00 for sip@ietf.org; Thu, 04 Sep 2003 07:08:40 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19uryh-0001py-00 for sip@ietf.org; Thu, 04 Sep 2003 07:08:39 -0400 content-class: urn:content-classes:message Subject: RE: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Sep 2003 13:12:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F16223380D@oefeg-s02.oefeg.loc> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNyzjxNXtM0cO16RQCqZr63gfVbxAAAvgtw From: "Stastny Richard" To: "Christer Holmberg (JO/LMF)" , "Bob Penfield" , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I do not really understand this discussion, because IMHO not even ;user=3Dphone is necessary, not to talk about any additional parameters. As Christer said, sip:+xxx@foo.bar or tel:+xxx shall work in any case (if E.164 numbers are supported). For local numbers and dialstrings the system currently implemented between FWD et. al. perfectly works (without ;user=3Dphone) It is using only sip: URIs in the following way: If you use an UAC where you may enter a complete sip: URI the INVITE is forwarded to the proper domain as is. If you use a "phone" and enter a numeric string forwarded to the default proxy foo.bar in the format ddddd@foo.bar It is now up to this proxy to analyze the ddddd. If it does not support numbers or dialstrings at all, he may reject it anyway. If it support numbers, it first checks if the number is used as an alias for a user (e.g. 10000 for jeff) If this is not the case, it may be a dialstring e.g. (**7476691290 for a sipphone user) E.g sipphone is not using **, they use dummy areacodes: you dial 17476691290 for own users (=3Dalias), but 139310000 for FWD and 14788781 for an iptel.org user FWD is even allowing transit calls: so from sipphone you may access an iptel.org user either with entering 8781@iptel.org in messenger or dial 1393**4788781 on the grandstream phone What is happening here is classical digit translation: the phone is sending sip:1393**4788781@proxy01.sipphone.com siphone is sending sip:**4788781@fwd.pulver.com FWD is sending 8781@iptel.org Personal note: I do not think that this approach is feasable for the interconnection of may different proxies, but it works.Finally we=20 should end up using only FQDN E.164 numbers or sip AoRs. To summarise: either you use a global number with + or a local dialing (numbering) plan You normally can use only one local dialing plan as default (same as in the PSTN). You may access another dialing plan directly by sending a sip URI directly to the domain in question (as in the above examples sending 8781@iptel.org directly) but this does not make much sense on a phone, because if you do this, you do not need=20 a dialing plan anyway, you could also enter a sip AoR . regards Richard > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, September 04, 2003 12:14 PM > To: 'Bob Penfield'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > Hi, >=20 > I would support Bob's proposal, saying that a "+" indicates=20 > global-phone-number, according to RFC2806(or bis). I don't=20 > think there would be any backward compability issues, because=20 > I doubt anyone is using "+" for any other purpose - at least=20 > not as the first character of the user part. Of course, nodes=20 > that really REQUIRE user=3Dphone to be present, in order to=20 > accept the request in the first, place would have to be changed. >=20 > Of course, user=3Dtel could also be used, but I really see no=20 > use for that if the "+" rule applies. Also, user=3Dtel COULD=20 > cause backward compability issues. >=20 > Then, since there doesn't seem to be an agreement on what=20 > user=3Dphone really means, related BOTH to the userpart syntax=20 > and the message routing, we could remove it completely. >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: 4. syyskuuta 2003 2:43 > > To: sip@ietf.org > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > Getting back to the problem Robert described in the=20 > original mail, the=20 > > interoperability problems are a result of that fact that what is a=20 > > valid userinfo part of a SIP URL with a user=3Dphone parameter has > > steadily gotten > > stricter without any consideration for backwards=20 > > compatibility. The specific > > problem he described resulted because a SIP URL created with=20 > > 2543 rules was > > rejected by a server applying 3261/2806 rules. The new=20 > > 2806bis rules are > > even stricter. I have no problem with those rules for tel-URLs. > >=20 > > In spite of the lack of normative text on user-phone, the > > statements in 2543 > > and 3261 to the effect that it is used to distinguish phone=20 > > numbers from > > usernames leads one to the reasonable conclusion that when it=20 > > is present, > > the 'telephone-subscriber' BNF applies. This is the=20 > > conclusion that we and a > > number of our vendors and customers came to when we ran into interop > > problems. > >=20 > > However, its not that simple since a 'telephone-subscriber' > > keeps changing. > >=20 > > >From some of the posting on this subject, there seems to=20 > be value in > > distinguishing a telephone number from username that happens > > to look like a > > telephone number without requiring that the user part be a=20 > > tel-URL. What I > > would propose is that while we make the rules for user=3Dphone=20 > > clearer, they > > ought to be closer to the 2543 rules which in my experience a lot of > > existing implementation seem to follow. If the userinfo=20 > > begins with "+" or > > contains a phone-context, then it is reasonable to interpret it as a > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of=20 > > 2543) should > > apply. A server which is not responsible for the domain of=20 > the SIP URL > > should not reject a SIP URL because phone-context is missing.=20 > > Actually, I > > believe it is reasonable to take the SIP URL host part as the=20 > > 'default' > > phone-context when it is missing. > >=20 > > Also, we could add 'user=3Dtel' for userinfo that MUST be > > tel-URLs. In that > > case, rejecting a local number without a phone-context would=20 > > be perfectly > > reasonable. > >=20 > > cheers, > > (-:bob > >=20 > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 07:53:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14652 for ; Thu, 4 Sep 2003 07:53:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usfo-0003mZ-HX for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 07:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84BrCdS014532 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 07:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usfd-0003lR-Jl; Thu, 04 Sep 2003 07:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usf2-0003kN-1z for sip@optimus.ietf.org; Thu, 04 Sep 2003 07:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14552 for ; Thu, 4 Sep 2003 07:52:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19usf1-0004Id-00 for sip@ietf.org; Thu, 04 Sep 2003 07:52:23 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19usez-0004Ia-00 for sip@ietf.org; Thu, 04 Sep 2003 07:52:22 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h84BqI427396 for ; Thu, 4 Sep 2003 14:52:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Sep 2003 14:52:18 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 4 Sep 2003 14:52:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 4 Sep 2003 14:52:17 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179707F@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNyzjxNXtM0cO16RQCqZr63gfVbxAAAvgtwAAHDt2A= To: , , , X-OriginalArrivalTime: 04 Sep 2003 11:52:17.0839 (UTC) FILETIME=[FD8673F0:01C372DA] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, September 04, 2003 2:13 PM > To: Christer Holmberg (JO/LMF); Bob Penfield; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > I do not really understand this discussion, because IMHO > not even ;user=3Dphone is necessary, not to talk about any additional > parameters. >=20 > As Christer said, sip:+xxx@foo.bar or tel:+xxx shall work in any case > (if E.164 numbers are supported). >=20 > For local numbers and dialstrings the system currently implemented > between FWD et. al. perfectly works (without ;user=3Dphone) > It is using only sip: URIs in the following way: >=20 > If you use an UAC where you may enter a complete sip: URI > the INVITE is forwarded to the proper domain as is. >=20 > If you use a "phone" and enter a numeric string forwarded to > the default proxy foo.bar in the format ddddd@foo.bar >=20 > It is now up to this proxy to analyze the ddddd. If it does not > support numbers or dialstrings at all, he may reject it anyway. What if the domain is the sip URI is the same domain as where the = default proxy is. So, if I enter sip:12345@foo.bar or just enter the digits 12345, they = will both be placed in the INVITE as sip:12345@foo.bar. How is the proxy = foo.bar supposed to know the difference? Especially is user with phone = 12345 is different that user with URI sip:12345@foo.bar There are 2 solutions in my mind (I can't see how this can be solved = without user input): 1. Mandate that endpoints support tel URIs. If user inputs digits, the = they are placed in a tel URI. In this case, the endpoint must not accept = a invalid tel URI entry without a phone-context. For local calls, the = endpoint prepends the +CountryCode-AreaCode it is configured with (if = the user is not required to enter them). 2. Mandate that users select what type of URI s/he is typing in (a sip = or tel URI). Based on that, place user=3Dphone.=20 Note, this is different than that Brain is talking about where the proxy = translates a tel URI in to a sip URI using ENUM. There he wants the = proxy to place something like user=3Dtranslated-from-tel. Regards, Hisham >=20 > If it support numbers, it first checks if the number is used=20 > as an alias > for a user (e.g. 10000 for jeff) >=20 > If this is not the case, it may be a dialstring e.g.=20 > (**7476691290 for a > sipphone user) >=20 > E.g sipphone is not using **, they use dummy areacodes: > you dial 17476691290 for own users (=3Dalias), but 139310000 for FWD > and 14788781 for an iptel.org user >=20 > FWD is even allowing transit calls: > so from sipphone you may access an iptel.org user > either with entering 8781@iptel.org in messenger or > dial 1393**4788781 on the grandstream phone >=20 > What is happening here is classical digit translation: > the phone is sending sip:1393**4788781@proxy01.sipphone.com > siphone is sending sip:**4788781@fwd.pulver.com > FWD is sending 8781@iptel.org >=20 > Personal note: I do not think that this approach is feasable for > the interconnection of may different proxies, but it works.Finally we=20 > should end up using only FQDN E.164 numbers or sip AoRs. >=20 > To summarise: either you use a global number with + or a local dialing > (numbering) plan > You normally can use only one local dialing plan as default=20 > (same as in > the PSTN). >=20 > You may access another dialing plan directly by sending a sip URI > directly > to the domain in question (as in the above examples sending > 8781@iptel.org directly) > but this does not make much sense on a phone, because if you do this, > you do not need=20 > a dialing plan anyway, you could also enter a sip AoR . >=20 > regards > Richard >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com]=20 > > Sent: Thursday, September 04, 2003 12:14 PM > > To: 'Bob Penfield'; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > >=20 > > Hi, > >=20 > > I would support Bob's proposal, saying that a "+" indicates=20 > > global-phone-number, according to RFC2806(or bis). I don't=20 > > think there would be any backward compability issues, because=20 > > I doubt anyone is using "+" for any other purpose - at least=20 > > not as the first character of the user part. Of course, nodes=20 > > that really REQUIRE user=3Dphone to be present, in order to=20 > > accept the request in the first, place would have to be changed. > >=20 > > Of course, user=3Dtel could also be used, but I really see no=20 > > use for that if the "+" rule applies. Also, user=3Dtel COULD=20 > > cause backward compability issues. > >=20 > > Then, since there doesn't seem to be an agreement on what=20 > > user=3Dphone really means, related BOTH to the userpart syntax=20 > > and the message routing, we could remove it completely. > >=20 > > Regards, > >=20 > > Christer Holmberg > > Ericsson Finland > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > Sent: 4. syyskuuta 2003 2:43 > > > To: sip@ietf.org > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > >=20 > > >=20 > > > Getting back to the problem Robert described in the=20 > > original mail, the=20 > > > interoperability problems are a result of that fact that=20 > what is a=20 > > > valid userinfo part of a SIP URL with a user=3Dphone parameter has > > > steadily gotten > > > stricter without any consideration for backwards=20 > > > compatibility. The specific > > > problem he described resulted because a SIP URL created with=20 > > > 2543 rules was > > > rejected by a server applying 3261/2806 rules. The new=20 > > > 2806bis rules are > > > even stricter. I have no problem with those rules for tel-URLs. > > >=20 > > > In spite of the lack of normative text on user-phone, the > > > statements in 2543 > > > and 3261 to the effect that it is used to distinguish phone=20 > > > numbers from > > > usernames leads one to the reasonable conclusion that when it=20 > > > is present, > > > the 'telephone-subscriber' BNF applies. This is the=20 > > > conclusion that we and a > > > number of our vendors and customers came to when we ran=20 > into interop > > > problems. > > >=20 > > > However, its not that simple since a 'telephone-subscriber' > > > keeps changing. > > >=20 > > > >From some of the posting on this subject, there seems to=20 > > be value in > > > distinguishing a telephone number from username that happens > > > to look like a > > > telephone number without requiring that the user part be a=20 > > > tel-URL. What I > > > would propose is that while we make the rules for user=3Dphone=20 > > > clearer, they > > > ought to be closer to the 2543 rules which in my=20 > experience a lot of > > > existing implementation seem to follow. If the userinfo=20 > > > begins with "+" or > > > contains a phone-context, then it is reasonable to=20 > interpret it as a > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of=20 > > > 2543) should > > > apply. A server which is not responsible for the domain of=20 > > the SIP URL > > > should not reject a SIP URL because phone-context is missing.=20 > > > Actually, I > > > believe it is reasonable to take the SIP URL host part as the=20 > > > 'default' > > > phone-context when it is missing. > > >=20 > > > Also, we could add 'user=3Dtel' for userinfo that MUST be > > > tel-URLs. In that > > > case, rejecting a local number without a phone-context would=20 > > > be perfectly > > > reasonable. > > >=20 > > > cheers, > > > (-:bob > > >=20 > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > bpenfield@acmepacket.com > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current=20 > > sip Use sipping@ietf.org for new developments on the=20 > > application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 08:12:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15694 for ; Thu, 4 Sep 2003 08:12:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usxs-0004lO-NZ for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 08:11:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84CBqJb018310 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 08:11:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19usxP-0004gb-QT; Thu, 04 Sep 2003 08:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uswd-0004fI-2w for sip@optimus.ietf.org; Thu, 04 Sep 2003 08:10:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15577 for ; Thu, 4 Sep 2003 08:10:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uswb-0005HO-00 for sip@ietf.org; Thu, 04 Sep 2003 08:10:33 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19uswa-0005GJ-00 for sip@ietf.org; Thu, 04 Sep 2003 08:10:33 -0400 content-class: urn:content-classes:message Subject: RE: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Sep 2003 14:14:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F16223380E@oefeg-s02.oefeg.loc> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNyzjxNXtM0cO16RQCqZr63gfVbxAAAvgtwAAHDt2AAAMcyIA== From: "Stastny Richard" To: , , , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > What if the domain is the sip URI is the same domain as where=20 > the default proxy is. >=20 > So, if I enter sip:12345@foo.bar or just enter the digits=20 > 12345, they will both be placed in the INVITE as=20 > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > the difference? Especially is user with phone 12345 is=20 > different that user with URI sip:12345@foo.bar The simplest solution to this problem is very trivial: there is no difference: sip:12345@foo.bar is sip:12345@foo.bar (surprise, surprise) The is BTW exactly how it is implemented in the examples I gave. 12345@foo.bar is e.g. an alias of hisham@foo.bar The only restriction you have to keep in mind here is that 12345 is also a number from a numbering plan. If you now also implement a dialing plan you have to leave number ranges free in your aliases for access codes=20 (e.g. start no alias with 0 to allow dialing 00 or 011 or whatever.) BTW, we use this also to map this "numbers" as partial numbers to E.164 numbers: My SIP AoR is e.g. richard@iphone.at, the alias is 32@iphone.at, so within my context I can be "dialed" also with 32. The E.164 number mapped with=20 ENUM is +4317978032, which translates to sip:32@iphone.at (You may look up the NAPTR in 2.3.0.8.7.9.7.1.3.4.e164.arpa) regards Richard > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Thursday, September 04, 2003 1:52 PM > To: Stastny Richard; christer.holmberg@ericsson.com;=20 > bpenfield@acmepacket.com; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 > > -----Original Message----- > > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, September 04, 2003 2:13 PM > > To: Christer Holmberg (JO/LMF); Bob Penfield; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > I do not really understand this discussion, because IMHO > > not even ;user=3Dphone is necessary, not to talk about any = additional=20 > > parameters. > >=20 > > As Christer said, sip:+xxx@foo.bar or tel:+xxx shall work=20 > in any case=20 > > (if E.164 numbers are supported). > >=20 > > For local numbers and dialstrings the system currently implemented=20 > > between FWD et. al. perfectly works (without ;user=3Dphone)=20 > It is using=20 > > only sip: URIs in the following way: > >=20 > > If you use an UAC where you may enter a complete sip: URI > > the INVITE is forwarded to the proper domain as is. > >=20 > > If you use a "phone" and enter a numeric string forwarded to the=20 > > default proxy foo.bar in the format ddddd@foo.bar > >=20 > > It is now up to this proxy to analyze the ddddd. If it does not=20 > > support numbers or dialstrings at all, he may reject it anyway. >=20 > What if the domain is the sip URI is the same domain as where=20 > the default proxy is. >=20 > So, if I enter sip:12345@foo.bar or just enter the digits=20 > 12345, they will both be placed in the INVITE as=20 > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > the difference? Especially is user with phone 12345 is=20 > different that user with URI sip:12345@foo.bar >=20 > There are 2 solutions in my mind (I can't see how this can be=20 > solved without user input): >=20 > 1. Mandate that endpoints support tel URIs. If user inputs=20 > digits, the they are placed in a tel URI. In this case, the=20 > endpoint must not accept a invalid tel URI entry without a=20 > phone-context. For local calls, the endpoint prepends the=20 > +CountryCode-AreaCode it is configured with (if the user is=20 > not required to enter them). >=20 > 2. Mandate that users select what type of URI s/he is typing=20 > in (a sip or tel URI). Based on that, place user=3Dphone.=20 >=20 > Note, this is different than that Brain is talking about=20 > where the proxy translates a tel URI in to a sip URI using=20 > ENUM. There he wants the proxy to place something like=20 > user=3Dtranslated-from-tel. >=20 > Regards, > Hisham >=20 > >=20 > > If it support numbers, it first checks if the number is used > > as an alias > > for a user (e.g. 10000 for jeff) > >=20 > > If this is not the case, it may be a dialstring e.g. > > (**7476691290 for a > > sipphone user) > >=20 > > E.g sipphone is not using **, they use dummy areacodes: > > you dial 17476691290 for own users (=3Dalias), but 139310000=20 > for FWD and=20 > > 14788781 for an iptel.org user > >=20 > > FWD is even allowing transit calls: > > so from sipphone you may access an iptel.org user > > either with entering 8781@iptel.org in messenger or > > dial 1393**4788781 on the grandstream phone > >=20 > > What is happening here is classical digit translation: > > the phone is sending sip:1393**4788781@proxy01.sipphone.com > > siphone is sending sip:**4788781@fwd.pulver.com > > FWD is sending 8781@iptel.org > >=20 > > Personal note: I do not think that this approach is=20 > feasable for the=20 > > interconnection of may different proxies, but it works.Finally we=20 > > should end up using only FQDN E.164 numbers or sip AoRs. > >=20 > > To summarise: either you use a global number with + or a=20 > local dialing > > (numbering) plan > > You normally can use only one local dialing plan as default > > (same as in > > the PSTN). > >=20 > > You may access another dialing plan directly by sending a sip URI=20 > > directly to the domain in question (as in the above examples sending > > 8781@iptel.org directly) > > but this does not make much sense on a phone, because if=20 > you do this, > > you do not need=20 > > a dialing plan anyway, you could also enter a sip AoR . > >=20 > > regards > > Richard > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com]=20 > > > Sent: Thursday, September 04, 2003 12:14 PM > > > To: 'Bob Penfield'; sip@ietf.org > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > I would support Bob's proposal, saying that a "+" indicates > > > global-phone-number, according to RFC2806(or bis). I don't=20 > > > think there would be any backward compability issues, because=20 > > > I doubt anyone is using "+" for any other purpose - at least=20 > > > not as the first character of the user part. Of course, nodes=20 > > > that really REQUIRE user=3Dphone to be present, in order to=20 > > > accept the request in the first, place would have to be changed. > > >=20 > > > Of course, user=3Dtel could also be used, but I really see no > > > use for that if the "+" rule applies. Also, user=3Dtel COULD=20 > > > cause backward compability issues. > > >=20 > > > Then, since there doesn't seem to be an agreement on what > > > user=3Dphone really means, related BOTH to the userpart syntax=20 > > > and the message routing, we could remove it completely. > > >=20 > > > Regards, > > >=20 > > > Christer Holmberg > > > Ericsson Finland > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > > Sent: 4. syyskuuta 2003 2:43 > > > > To: sip@ietf.org > > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > > >=20 > > > >=20 > > > > Getting back to the problem Robert described in the > > > original mail, the > > > > interoperability problems are a result of that fact that > > what is a > > > > valid userinfo part of a SIP URL with a user=3Dphone=20 > parameter has=20 > > > > steadily gotten stricter without any consideration for backwards > > > > compatibility. The specific > > > > problem he described resulted because a SIP URL created with=20 > > > > 2543 rules was > > > > rejected by a server applying 3261/2806 rules. The new=20 > > > > 2806bis rules are > > > > even stricter. I have no problem with those rules for tel-URLs. > > > >=20 > > > > In spite of the lack of normative text on user-phone, the=20 > > > > statements in 2543 and 3261 to the effect that it is used to=20 > > > > distinguish phone numbers from > > > > usernames leads one to the reasonable conclusion that when it=20 > > > > is present, > > > > the 'telephone-subscriber' BNF applies. This is the=20 > > > > conclusion that we and a > > > > number of our vendors and customers came to when we ran=20 > > into interop > > > > problems. > > > >=20 > > > > However, its not that simple since a=20 > 'telephone-subscriber' keeps=20 > > > > changing. > > > >=20 > > > > >From some of the posting on this subject, there seems to > > > be value in > > > > distinguishing a telephone number from username that happens to=20 > > > > look like a telephone number without requiring that the=20 > user part=20 > > > > be a tel-URL. What I > > > > would propose is that while we make the rules for user=3Dphone=20 > > > > clearer, they > > > > ought to be closer to the 2543 rules which in my=20 > > experience a lot of > > > > existing implementation seem to follow. If the userinfo > > > > begins with "+" or > > > > contains a phone-context, then it is reasonable to=20 > > interpret it as a > > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > > > 2543) should > > > > apply. A server which is not responsible for the domain of=20 > > > the SIP URL > > > > should not reject a SIP URL because phone-context is missing. > > > > Actually, I > > > > believe it is reasonable to take the SIP URL host part as the=20 > > > > 'default' > > > > phone-context when it is missing. > > > >=20 > > > > Also, we could add 'user=3Dtel' for userinfo that MUST be=20 > tel-URLs.=20 > > > > In that case, rejecting a local number without a phone-context=20 > > > > would be perfectly > > > > reasonable. > > > >=20 > > > > cheers, > > > > (-:bob > > > >=20 > > > > Robert F. Penfield > > > > Chief Software Architect > > > > Acme Packet, Inc. > > > > 130 New Boston Street > > > > Woburn, MA 01801 > > > > bpenfield@acmepacket.com > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 08:18:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16096 for ; Thu, 4 Sep 2003 08:18:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut3t-0005CT-TA for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 08:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84CI5qY019989 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 08:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut3p-0005BT-F9; Thu, 04 Sep 2003 08:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut39-00059q-BX for sip@optimus.ietf.org; Thu, 04 Sep 2003 08:17:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16009 for ; Thu, 4 Sep 2003 08:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut38-0005eb-00 for sip@ietf.org; Thu, 04 Sep 2003 08:17:18 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19ut37-0005a6-00 for sip@ietf.org; Thu, 04 Sep 2003 08:17:17 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 13:16:46 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SBMR7LN6; Thu, 4 Sep 2003 13:16:36 +0100 From: "Conroy, Lawrence (SMTP)" To: hisham.khartabil@nokia.com, Richard.Stastny@oefeg.at, christer.holmberg@ericsson.com, bpenfield@acmepacket.com, sip@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179707F@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70179707F@esebe019.ntc.nokia.com> Date: Thu, 4 Sep 2003 13:16:29 +0100 Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 2:52 pm +0300 4/9/03, hisham.khartabil@nokia.com wrote: >What if the domain is the sip URI is the same domain as where the >default proxy is. > >So, if I enter sip:12345@foo.bar or just enter the digits 12345, >they will both be placed in the INVITE as sip:12345@foo.bar. How is >the proxy foo.bar supposed to know the difference? Especially is >user with phone 12345 is different that user with URI >sip:12345@foo.bar Hi Folks, I am losing the plot here. At what point did someone seriously suggest that sip:12345@foo.bar is different from sip:12345@foo.bar? I've seen these comments but assumed that they were typos. Apparently not. If two URIs match according to the rules in 3261 then they're the same. Thus if my phone constructs an INVITE with 'sip:12345@foo.bar' as the To: field (whilst I typed in the digits '12345'), this is NO different from me entering '12345@foo.bar' onto the phone and it constructing an INVITE with 'sip:12345@foo.bar' as the To: field. The recipient of this INVITE will (normally) process the two as the same. If your proxy wants to use some other magic to differentiate between this destination, that's an internal issue for the Proxy and not a protocol issue. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 08:27:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16624 for ; Thu, 4 Sep 2003 08:27:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utCg-00063K-QR for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 08:27:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84CRAGA023265 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 08:27:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utCX-0005z3-IA; Thu, 04 Sep 2003 08:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utC9-0005yL-VC for sip@optimus.ietf.org; Thu, 04 Sep 2003 08:26:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16575 for ; Thu, 4 Sep 2003 08:26:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19utC8-0006Du-00 for sip@ietf.org; Thu, 04 Sep 2003 08:26:36 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19utC6-0006Di-00 for sip@ietf.org; Thu, 04 Sep 2003 08:26:35 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h84CQJB23531 for ; Thu, 4 Sep 2003 15:26:30 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Sep 2003 15:26:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 4 Sep 2003 15:26:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 4 Sep 2003 15:26:18 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797082@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNyzjxNXtM0cO16RQCqZr63gfVbxAAAvgtwAAHDt2AAAMcyIAAA9jog To: , , , X-OriginalArrivalTime: 04 Sep 2003 12:26:19.0223 (UTC) FILETIME=[BE48EE70:01C372DF] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, September 04, 2003 3:15 PM > To: Khartabil Hisham (NMP/Helsinki); christer.holmberg@ericsson.com; > bpenfield@acmepacket.com; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > > What if the domain is the sip URI is the same domain as where=20 > > the default proxy is. > >=20 > > So, if I enter sip:12345@foo.bar or just enter the digits=20 > > 12345, they will both be placed in the INVITE as=20 > > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > > the difference? Especially is user with phone 12345 is=20 > > different that user with URI sip:12345@foo.bar >=20 > The simplest solution to this problem is very trivial: there is no > difference: >=20 > sip:12345@foo.bar is sip:12345@foo.bar (surprise, surprise) You cannot make that conclusion. I belong to operator1.com that gave me = this number 12345 as my telephone number. You are with operator2 and = they gave you the sip address 12345@operator2.com Now, someone, not you, from operator2.com (your operator) wants to call = me. They dial 12345. Using your logic, your phone ends up ringing = instead of mine. /Hisham >=20 > The is BTW exactly how it is implemented in the examples I gave. > 12345@foo.bar is e.g. an alias of hisham@foo.bar >=20 > The only restriction you have to keep in mind here is that=20 > 12345 is also > a number from a numbering plan. If you now also implement a=20 > dialing plan > you > have to leave number ranges free in your aliases for access codes=20 > (e.g. start no alias with 0 to allow dialing 00 or 011 or whatever.) >=20 > BTW, we use this also to map this "numbers" as partial=20 > numbers to E.164 > numbers: >=20 > My SIP AoR is e.g. richard@iphone.at, the alias is 32@iphone.at, so > within > my context I can be "dialed" also with 32. The E.164 number=20 > mapped with=20 > ENUM is +4317978032, which translates to sip:32@iphone.at > (You may look up the NAPTR in 2.3.0.8.7.9.7.1.3.4.e164.arpa) >=20 > regards > Richard >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com]=20 > > Sent: Thursday, September 04, 2003 1:52 PM > > To: Stastny Richard; christer.holmberg@ericsson.com;=20 > > bpenfield@acmepacket.com; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > > > -----Original Message----- > > > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, September 04, 2003 2:13 PM > > > To: Christer Holmberg (JO/LMF); Bob Penfield; sip@ietf.org > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > >=20 > > >=20 > > > I do not really understand this discussion, because IMHO > > > not even ;user=3Dphone is necessary, not to talk about any=20 > additional=20 > > > parameters. > > >=20 > > > As Christer said, sip:+xxx@foo.bar or tel:+xxx shall work=20 > > in any case=20 > > > (if E.164 numbers are supported). > > >=20 > > > For local numbers and dialstrings the system currently=20 > implemented=20 > > > between FWD et. al. perfectly works (without ;user=3Dphone)=20 > > It is using=20 > > > only sip: URIs in the following way: > > >=20 > > > If you use an UAC where you may enter a complete sip: URI > > > the INVITE is forwarded to the proper domain as is. > > >=20 > > > If you use a "phone" and enter a numeric string forwarded to the=20 > > > default proxy foo.bar in the format ddddd@foo.bar > > >=20 > > > It is now up to this proxy to analyze the ddddd. If it does not=20 > > > support numbers or dialstrings at all, he may reject it anyway. > >=20 > > What if the domain is the sip URI is the same domain as where=20 > > the default proxy is. > >=20 > > So, if I enter sip:12345@foo.bar or just enter the digits=20 > > 12345, they will both be placed in the INVITE as=20 > > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > > the difference? Especially is user with phone 12345 is=20 > > different that user with URI sip:12345@foo.bar > >=20 > > There are 2 solutions in my mind (I can't see how this can be=20 > > solved without user input): > >=20 > > 1. Mandate that endpoints support tel URIs. If user inputs=20 > > digits, the they are placed in a tel URI. In this case, the=20 > > endpoint must not accept a invalid tel URI entry without a=20 > > phone-context. For local calls, the endpoint prepends the=20 > > +CountryCode-AreaCode it is configured with (if the user is=20 > > not required to enter them). > >=20 > > 2. Mandate that users select what type of URI s/he is typing=20 > > in (a sip or tel URI). Based on that, place user=3Dphone.=20 > >=20 > > Note, this is different than that Brain is talking about=20 > > where the proxy translates a tel URI in to a sip URI using=20 > > ENUM. There he wants the proxy to place something like=20 > > user=3Dtranslated-from-tel. > >=20 > > Regards, > > Hisham > >=20 > > >=20 > > > If it support numbers, it first checks if the number is used > > > as an alias > > > for a user (e.g. 10000 for jeff) > > >=20 > > > If this is not the case, it may be a dialstring e.g. > > > (**7476691290 for a > > > sipphone user) > > >=20 > > > E.g sipphone is not using **, they use dummy areacodes: > > > you dial 17476691290 for own users (=3Dalias), but 139310000=20 > > for FWD and=20 > > > 14788781 for an iptel.org user > > >=20 > > > FWD is even allowing transit calls: > > > so from sipphone you may access an iptel.org user > > > either with entering 8781@iptel.org in messenger or > > > dial 1393**4788781 on the grandstream phone > > >=20 > > > What is happening here is classical digit translation: > > > the phone is sending sip:1393**4788781@proxy01.sipphone.com > > > siphone is sending sip:**4788781@fwd.pulver.com > > > FWD is sending 8781@iptel.org > > >=20 > > > Personal note: I do not think that this approach is=20 > > feasable for the=20 > > > interconnection of may different proxies, but it works.Finally we=20 > > > should end up using only FQDN E.164 numbers or sip AoRs. > > >=20 > > > To summarise: either you use a global number with + or a=20 > > local dialing > > > (numbering) plan > > > You normally can use only one local dialing plan as default > > > (same as in > > > the PSTN). > > >=20 > > > You may access another dialing plan directly by sending a sip URI=20 > > > directly to the domain in question (as in the above=20 > examples sending > > > 8781@iptel.org directly) > > > but this does not make much sense on a phone, because if=20 > > you do this, > > > you do not need=20 > > > a dialing plan anyway, you could also enter a sip AoR . > > >=20 > > > regards > > > Richard > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com]=20 > > > > Sent: Thursday, September 04, 2003 12:14 PM > > > > To: 'Bob Penfield'; sip@ietf.org > > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > >=20 > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > I would support Bob's proposal, saying that a "+" indicates > > > > global-phone-number, according to RFC2806(or bis). I don't=20 > > > > think there would be any backward compability issues, because=20 > > > > I doubt anyone is using "+" for any other purpose - at least=20 > > > > not as the first character of the user part. Of course, nodes=20 > > > > that really REQUIRE user=3Dphone to be present, in order to=20 > > > > accept the request in the first, place would have to be changed. > > > >=20 > > > > Of course, user=3Dtel could also be used, but I really see no > > > > use for that if the "+" rule applies. Also, user=3Dtel COULD=20 > > > > cause backward compability issues. > > > >=20 > > > > Then, since there doesn't seem to be an agreement on what > > > > user=3Dphone really means, related BOTH to the userpart syntax=20 > > > > and the message routing, we could remove it completely. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer Holmberg > > > > Ericsson Finland > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > > > Sent: 4. syyskuuta 2003 2:43 > > > > > To: sip@ietf.org > > > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > >=20 > > > > >=20 > > > > > Getting back to the problem Robert described in the > > > > original mail, the > > > > > interoperability problems are a result of that fact that > > > what is a > > > > > valid userinfo part of a SIP URL with a user=3Dphone=20 > > parameter has=20 > > > > > steadily gotten stricter without any consideration=20 > for backwards > > > > > compatibility. The specific > > > > > problem he described resulted because a SIP URL created with=20 > > > > > 2543 rules was > > > > > rejected by a server applying 3261/2806 rules. The new=20 > > > > > 2806bis rules are > > > > > even stricter. I have no problem with those rules for=20 > tel-URLs. > > > > >=20 > > > > > In spite of the lack of normative text on user-phone, the=20 > > > > > statements in 2543 and 3261 to the effect that it is used to=20 > > > > > distinguish phone numbers from > > > > > usernames leads one to the reasonable conclusion that when it=20 > > > > > is present, > > > > > the 'telephone-subscriber' BNF applies. This is the=20 > > > > > conclusion that we and a > > > > > number of our vendors and customers came to when we ran=20 > > > into interop > > > > > problems. > > > > >=20 > > > > > However, its not that simple since a=20 > > 'telephone-subscriber' keeps=20 > > > > > changing. > > > > >=20 > > > > > >From some of the posting on this subject, there seems to > > > > be value in > > > > > distinguishing a telephone number from username that=20 > happens to=20 > > > > > look like a telephone number without requiring that the=20 > > user part=20 > > > > > be a tel-URL. What I > > > > > would propose is that while we make the rules for user=3Dphone = > > > > > clearer, they > > > > > ought to be closer to the 2543 rules which in my=20 > > > experience a lot of > > > > > existing implementation seem to follow. If the userinfo > > > > > begins with "+" or > > > > > contains a phone-context, then it is reasonable to=20 > > > interpret it as a > > > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > > > > 2543) should > > > > > apply. A server which is not responsible for the domain of=20 > > > > the SIP URL > > > > > should not reject a SIP URL because phone-context is missing. > > > > > Actually, I > > > > > believe it is reasonable to take the SIP URL host part as the=20 > > > > > 'default' > > > > > phone-context when it is missing. > > > > >=20 > > > > > Also, we could add 'user=3Dtel' for userinfo that MUST be=20 > > tel-URLs.=20 > > > > > In that case, rejecting a local number without a=20 > phone-context=20 > > > > > would be perfectly > > > > > reasonable. > > > > >=20 > > > > > cheers, > > > > > (-:bob > > > > >=20 > > > > > Robert F. Penfield > > > > > Chief Software Architect > > > > > Acme Packet, Inc. > > > > > 130 New Boston Street > > > > > Woburn, MA 01801 > > > > > bpenfield@acmepacket.com > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 08:38:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17229 for ; Thu, 4 Sep 2003 08:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utNM-0006mH-Bz for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 08:38:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84CcCIr025993 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 08:38:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utND-0006ij-Sm; Thu, 04 Sep 2003 08:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utMt-0006h7-Kp for sip@optimus.ietf.org; Thu, 04 Sep 2003 08:37:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17163 for ; Thu, 4 Sep 2003 08:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19utMs-00073y-00 for sip@ietf.org; Thu, 04 Sep 2003 08:37:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19utMr-000735-00 for sip@ietf.org; Thu, 04 Sep 2003 08:37:41 -0400 content-class: urn:content-classes:message Subject: RE: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Sep 2003 14:41:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F16223380F@oefeg-s02.oefeg.loc> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNyzjxNXtM0cO16RQCqZr63gfVbxAAAvgtwAAHDt2AAAMcyIAAA9jogAABJYpA= From: "Stastny Richard" To: , , , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > You cannot make that conclusion. Yes, I can >I belong to operator1.com=20 > that gave me this number 12345 as my telephone number. You=20 > are with operator2 and they gave you the sip address=20 > 12345@operator2.com >=20 > Now, someone, not you, from operator2.com (your operator)=20 > wants to call me. They dial 12345. Using your logic, your=20 > phone ends up ringing instead of mine. Correct, if I am in 32@iphone.at and you are in 32@foo.bar and someone dials 32 in foo.bar, your phone rings. To get my phone ringing you either have to enter=20 32@iphone.at or you dial +4317978032 or YOUR operator has agreed with my operator on a short cut with an access code eg. 932 or **55 32. This is called cross trunks or cross connections in PBX quack-speech and established since centuries. Richard > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Thursday, September 04, 2003 2:26 PM > To: Stastny Richard; christer.holmberg@ericsson.com;=20 > bpenfield@acmepacket.com; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, September 04, 2003 3:15 PM > > To: Khartabil Hisham (NMP/Helsinki);=20 > christer.holmberg@ericsson.com;=20 > > bpenfield@acmepacket.com; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > > What if the domain is the sip URI is the same domain as where > > > the default proxy is. > > >=20 > > > So, if I enter sip:12345@foo.bar or just enter the digits > > > 12345, they will both be placed in the INVITE as=20 > > > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > > > the difference? Especially is user with phone 12345 is=20 > > > different that user with URI sip:12345@foo.bar > >=20 > > The simplest solution to this problem is very trivial: there is no > > difference: > >=20 > > sip:12345@foo.bar is sip:12345@foo.bar (surprise, surprise) >=20 > You cannot make that conclusion. I belong to operator1.com=20 > that gave me this number 12345 as my telephone number. You=20 > are with operator2 and they gave you the sip address=20 > 12345@operator2.com >=20 > Now, someone, not you, from operator2.com (your operator)=20 > wants to call me. They dial 12345. Using your logic, your=20 > phone ends up ringing instead of mine. >=20 > /Hisham >=20 > >=20 > > The is BTW exactly how it is implemented in the examples I gave.=20 > > 12345@foo.bar is e.g. an alias of hisham@foo.bar > >=20 > > The only restriction you have to keep in mind here is that > > 12345 is also > > a number from a numbering plan. If you now also implement a=20 > > dialing plan > > you > > have to leave number ranges free in your aliases for access codes=20 > > (e.g. start no alias with 0 to allow dialing 00 or 011 or whatever.) > >=20 > > BTW, we use this also to map this "numbers" as partial > > numbers to E.164 > > numbers: > >=20 > > My SIP AoR is e.g. richard@iphone.at, the alias is 32@iphone.at, so=20 > > within my context I can be "dialed" also with 32. The E.164 number > > mapped with=20 > > ENUM is +4317978032, which translates to sip:32@iphone.at > > (You may look up the NAPTR in 2.3.0.8.7.9.7.1.3.4.e164.arpa) > >=20 > > regards > > Richard > >=20 > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > Sent: Thursday, September 04, 2003 1:52 PM > > > To: Stastny Richard; christer.holmberg@ericsson.com; > > > bpenfield@acmepacket.com; sip@ietf.org > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > >=20 > > > > -----Original Message----- > > > > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, September 04, 2003 2:13 PM > > > > To: Christer Holmberg (JO/LMF); Bob Penfield; sip@ietf.org > > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > >=20 > > > >=20 > > > > I do not really understand this discussion, because=20 > IMHO not even=20 > > > > ;user=3Dphone is necessary, not to talk about any > > additional > > > > parameters. > > > >=20 > > > > As Christer said, sip:+xxx@foo.bar or tel:+xxx shall work > > > in any case > > > > (if E.164 numbers are supported). > > > >=20 > > > > For local numbers and dialstrings the system currently > > implemented > > > > between FWD et. al. perfectly works (without ;user=3Dphone) > > > It is using > > > > only sip: URIs in the following way: > > > >=20 > > > > If you use an UAC where you may enter a complete sip: URI the=20 > > > > INVITE is forwarded to the proper domain as is. > > > >=20 > > > > If you use a "phone" and enter a numeric string forwarded to the > > > > default proxy foo.bar in the format ddddd@foo.bar > > > >=20 > > > > It is now up to this proxy to analyze the ddddd. If it does not > > > > support numbers or dialstrings at all, he may reject it anyway. > > >=20 > > > What if the domain is the sip URI is the same domain as where > > > the default proxy is. > > >=20 > > > So, if I enter sip:12345@foo.bar or just enter the digits > > > 12345, they will both be placed in the INVITE as=20 > > > sip:12345@foo.bar. How is the proxy foo.bar supposed to know=20 > > > the difference? Especially is user with phone 12345 is=20 > > > different that user with URI sip:12345@foo.bar > > >=20 > > > There are 2 solutions in my mind (I can't see how this can be > > > solved without user input): > > >=20 > > > 1. Mandate that endpoints support tel URIs. If user inputs > > > digits, the they are placed in a tel URI. In this case, the=20 > > > endpoint must not accept a invalid tel URI entry without a=20 > > > phone-context. For local calls, the endpoint prepends the=20 > > > +CountryCode-AreaCode it is configured with (if the user is > > > not required to enter them). > > >=20 > > > 2. Mandate that users select what type of URI s/he is typing > > > in (a sip or tel URI). Based on that, place user=3Dphone.=20 > > >=20 > > > Note, this is different than that Brain is talking about > > > where the proxy translates a tel URI in to a sip URI using=20 > > > ENUM. There he wants the proxy to place something like=20 > > > user=3Dtranslated-from-tel. > > >=20 > > > Regards, > > > Hisham > > >=20 > > > >=20 > > > > If it support numbers, it first checks if the number is=20 > used as an=20 > > > > alias for a user (e.g. 10000 for jeff) > > > >=20 > > > > If this is not the case, it may be a dialstring e.g.=20 > (**7476691290=20 > > > > for a sipphone user) > > > >=20 > > > > E.g sipphone is not using **, they use dummy areacodes:=20 > you dial=20 > > > > 17476691290 for own users (=3Dalias), but 139310000 > > > for FWD and > > > > 14788781 for an iptel.org user > > > >=20 > > > > FWD is even allowing transit calls: > > > > so from sipphone you may access an iptel.org user > > > > either with entering 8781@iptel.org in messenger or > > > > dial 1393**4788781 on the grandstream phone > > > >=20 > > > > What is happening here is classical digit translation:=20 > the phone=20 > > > > is sending sip:1393**4788781@proxy01.sipphone.com > > > > siphone is sending sip:**4788781@fwd.pulver.com > > > > FWD is sending 8781@iptel.org > > > >=20 > > > > Personal note: I do not think that this approach is > > > feasable for the > > > > interconnection of may different proxies, but it=20 > works.Finally we > > > > should end up using only FQDN E.164 numbers or sip AoRs. > > > >=20 > > > > To summarise: either you use a global number with + or a > > > local dialing > > > > (numbering) plan > > > > You normally can use only one local dialing plan as=20 > default (same=20 > > > > as in the PSTN). > > > >=20 > > > > You may access another dialing plan directly by sending=20 > a sip URI > > > > directly to the domain in question (as in the above=20 > > examples sending > > > > 8781@iptel.org directly) > > > > but this does not make much sense on a phone, because if > > > you do this, > > > > you do not need > > > > a dialing plan anyway, you could also enter a sip AoR . > > > >=20 > > > > regards > > > > Richard > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF)=20 > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Thursday, September 04, 2003 12:14 PM > > > > > To: 'Bob Penfield'; sip@ietf.org > > > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I would support Bob's proposal, saying that a "+" indicates=20 > > > > > global-phone-number, according to RFC2806(or bis). I=20 > don't think=20 > > > > > there would be any backward compability issues,=20 > because I doubt=20 > > > > > anyone is using "+" for any other purpose - at least=20 > not as the=20 > > > > > first character of the user part. Of course, nodes=20 > that really=20 > > > > > REQUIRE user=3Dphone to be present, in order to accept=20 > the request=20 > > > > > in the first, place would have to be changed. > > > > >=20 > > > > > Of course, user=3Dtel could also be used, but I really=20 > see no use=20 > > > > > for that if the "+" rule applies. Also, user=3Dtel COULD cause = > > > > > backward compability issues. > > > > >=20 > > > > > Then, since there doesn't seem to be an agreement on what=20 > > > > > user=3Dphone really means, related BOTH to the userpart=20 > syntax and=20 > > > > > the message routing, we could remove it completely. > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > > > > Sent: 4. syyskuuta 2003 2:43 > > > > > > To: sip@ietf.org > > > > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > >=20 > > > > > >=20 > > > > > > Getting back to the problem Robert described in the > > > > > original mail, the > > > > > > interoperability problems are a result of that fact that > > > > what is a > > > > > > valid userinfo part of a SIP URL with a user=3Dphone > > > parameter has > > > > > > steadily gotten stricter without any consideration > > for backwards > > > > > > compatibility. The specific > > > > > > problem he described resulted because a SIP URL created with > > > > > > 2543 rules was > > > > > > rejected by a server applying 3261/2806 rules. The new=20 > > > > > > 2806bis rules are > > > > > > even stricter. I have no problem with those rules for=20 > > tel-URLs. > > > > > >=20 > > > > > > In spite of the lack of normative text on user-phone, the > > > > > > statements in 2543 and 3261 to the effect that it=20 > is used to=20 > > > > > > distinguish phone numbers from > > > > > > usernames leads one to the reasonable conclusion=20 > that when it=20 > > > > > > is present, > > > > > > the 'telephone-subscriber' BNF applies. This is the=20 > > > > > > conclusion that we and a > > > > > > number of our vendors and customers came to when we ran=20 > > > > into interop > > > > > > problems. > > > > > >=20 > > > > > > However, its not that simple since a > > > 'telephone-subscriber' keeps > > > > > > changing. > > > > > >=20 > > > > > > >From some of the posting on this subject, there seems to > > > > > be value in > > > > > > distinguishing a telephone number from username that > > happens to > > > > > > look like a telephone number without requiring that the > > > user part > > > > > > be a tel-URL. What I > > > > > > would propose is that while we make the rules for = user=3Dphone > > > > > > clearer, they > > > > > > ought to be closer to the 2543 rules which in my=20 > > > > experience a lot of > > > > > > existing implementation seem to follow. If the=20 > userinfo begins=20 > > > > > > with "+" or contains a phone-context, then it is=20 > reasonable to > > > > interpret it as a > > > > > > tel-URL. Otherwise, the 'local-phone-number' (from=20 > Table 4 of > > > > > > 2543) should > > > > > > apply. A server which is not responsible for the domain of > > > > > the SIP URL > > > > > > should not reject a SIP URL because phone-context=20 > is missing.=20 > > > > > > Actually, I believe it is reasonable to take the=20 > SIP URL host=20 > > > > > > part as the 'default' > > > > > > phone-context when it is missing. > > > > > >=20 > > > > > > Also, we could add 'user=3Dtel' for userinfo that MUST be > > > tel-URLs. > > > > > > In that case, rejecting a local number without a > > phone-context > > > > > > would be perfectly > > > > > > reasonable. > > > > > >=20 > > > > > > cheers, > > > > > > (-:bob > > > > > >=20 > > > > > > Robert F. Penfield > > > > > > Chief Software Architect > > > > > > Acme Packet, Inc. > > > > > > 130 New Boston Street > > > > > > Woburn, MA 01801 > > > > > > bpenfield@acmepacket.com > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > > current sip Use > > > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use > > > > > sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 09:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22763 for ; Thu, 4 Sep 2003 09:52:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uuWr-0002k3-QG for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 09:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Dq5EI010513 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 09:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uuWn-0002iu-4J; Thu, 04 Sep 2003 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uuWl-0002ig-7o for sip@optimus.ietf.org; Thu, 04 Sep 2003 09:51:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22713 for ; Thu, 4 Sep 2003 09:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uuWj-0003CH-00 for sip@ietf.org; Thu, 04 Sep 2003 09:51:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uuWi-0003BX-00 for sip@ietf.org; Thu, 04 Sep 2003 09:51:56 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2003 06:51:26 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h84DpNHg011759; Thu, 4 Sep 2003 06:51:24 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACB86970; Thu, 4 Sep 2003 09:51:23 -0400 (EDT) Message-ID: <3F57435B.7080104@cisco.com> Date: Thu, 04 Sep 2003 09:51:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Rosen, Brian'" , "'sip@ietf.org'" Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <2F1FC1DEA077D5119FAD00508BCFD6D20AA88A03@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We might argue about the details, but I agree in principle with Francois. Paul Francois Audet wrote: > > In general, really what we should be recommending to SIP phone > manufacturers > is the ability for a phone to be configured both with the FQDN of its > proxy, and > an arbitrary phone-context for potentially varying types of numbers. One > of those > types of numbers can be an unqualified number (which we sometimes call > dial string). If the phone-context for those numbers is the Domain name of > the proxy (meaning all phones associated with that proxy have the same > dialing plan), > that's fine. If the phone-context is unique per phone, that's fine too (but > more complex for the proxy): it would allow for dial plan to vary per > phone. If it > is another phone-context (as per 2806), then it can have a different scope. > > The important is that the phone is configurabled with an arbitrary > phone-context > string corresponding to an "unqualified number" (a.k.a., "dialed string", > "unprocessed" string, etc.). > > That will allow the "generic" SIP phone to be used in any environment. > > (Of course, a smarter phone could do the +CC URI, or even have > additional phone > contexes for extensions, or other private number). > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 10:26:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25929 for ; Thu, 4 Sep 2003 10:26:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uv3z-0004co-1Y for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 10:26:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84EQJJZ017774 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 10:26:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uv3o-0004c7-A3; Thu, 04 Sep 2003 10:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uv36-0004b4-IP for sip@optimus.ietf.org; Thu, 04 Sep 2003 10:25:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25844 for ; Thu, 4 Sep 2003 10:25:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uv34-0003wH-00 for sip@ietf.org; Thu, 04 Sep 2003 10:25:22 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uv33-0003vv-00 for sip@ietf.org; Thu, 04 Sep 2003 10:25:21 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2003 07:36:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h84EOkaQ008337; Thu, 4 Sep 2003 07:24:48 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACB90610; Thu, 4 Sep 2003 10:24:45 -0400 (EDT) Message-ID: <3F574B2D.7080807@cisco.com> Date: Thu, 04 Sep 2003 10:24:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" CC: "'Bob Penfield'" , sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I disagree with some of the details below, but some points are good. First, the rules about who can interpret the userpart of a sip url apply regardless of whether user=phone is present or not. So nobody should be rejecting a sip url because of perceived problems with the userpart if it isn't their domain. Included in the above is construction of sip uris by phones. You have no business transforming dialed digits into a sip uri unless you are prepared to play by the rules of the domain you stick in that uri. Since the domain is probably provisioned into the phone, at that time you had better ensure that the phone can play by the rules for that domain. That should take care of most issues of 2543 vs 3261/2806bis. However, for the same reasons I think it preferable for phones to use tel: urls. The reason is that sip urls from other domains can't be deconstructed to provide reasonable displays on devices that deal primarily with numbers. Compatibility of various versions telephone-subscriber could be a problem when dealing with tel urls. The usual guideline to be strict in what you send and forgiving of what you receive should apply here and ought to be sufficient. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > I would support Bob's proposal, saying that a "+" indicates global-phone-number, according to RFC2806(or bis). I don't think there would be any backward compability issues, because I doubt anyone is using "+" for any other purpose - at least not as the first character of the user part. Of course, nodes that really REQUIRE user=phone to be present, in order to accept the request in the first, place would have to be changed. > > Of course, user=tel could also be used, but I really see no use for that if the "+" rule applies. Also, user=tel COULD cause backward compability issues. > > Then, since there doesn't seem to be an agreement on what user=phone really means, related BOTH to the userpart syntax and the message routing, we could remove it completely. > > Regards, > > Christer Holmberg > Ericsson Finland > >>-----Original Message----- >>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>Sent: 4. syyskuuta 2003 2:43 >>To: sip@ietf.org >>Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >> >> >>Getting back to the problem Robert described in the original mail, the >>interoperability problems are a result of that fact that what >>is a valid >>userinfo part of a SIP URL with a user=phone parameter has >>steadily gotten >>stricter without any consideration for backwards >>compatibility. The specific >>problem he described resulted because a SIP URL created with >>2543 rules was >>rejected by a server applying 3261/2806 rules. The new >>2806bis rules are >>even stricter. I have no problem with those rules for tel-URLs. >> >>In spite of the lack of normative text on user-phone, the >>statements in 2543 >>and 3261 to the effect that it is used to distinguish phone >>numbers from >>usernames leads one to the reasonable conclusion that when it >>is present, >>the 'telephone-subscriber' BNF applies. This is the >>conclusion that we and a >>number of our vendors and customers came to when we ran into interop >>problems. >> >>However, its not that simple since a 'telephone-subscriber' >>keeps changing. >> >>>From some of the posting on this subject, there seems to be value in >>distinguishing a telephone number from username that happens >>to look like a >>telephone number without requiring that the user part be a >>tel-URL. What I >>would propose is that while we make the rules for user=phone >>clearer, they >>ought to be closer to the 2543 rules which in my experience a lot of >>existing implementation seem to follow. If the userinfo >>begins with "+" or >>contains a phone-context, then it is reasonable to interpret it as a >>tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of >>2543) should >>apply. A server which is not responsible for the domain of the SIP URL >>should not reject a SIP URL because phone-context is missing. >>Actually, I >>believe it is reasonable to take the SIP URL host part as the >>'default' >>phone-context when it is missing. >> >>Also, we could add 'user=tel' for userinfo that MUST be >>tel-URLs. In that >>case, rejecting a local number without a phone-context would >>be perfectly >>reasonable. >> >>cheers, >>(-:bob >> >>Robert F. Penfield >>Chief Software Architect >>Acme Packet, Inc. >>130 New Boston Street >>Woburn, MA 01801 >>bpenfield@acmepacket.com >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 10:40:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27504 for ; Thu, 4 Sep 2003 10:40:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvHh-00060U-MC for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 10:40:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84EeTen023030 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 10:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvHK-0005jd-5e; Thu, 04 Sep 2003 10:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvGL-0005hX-I0 for sip@optimus.ietf.org; Thu, 04 Sep 2003 10:39:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27235; Thu, 4 Sep 2003 10:38:57 -0400 (EDT) Message-Id: <200309041438.KAA27235@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 04 Sep 2003 10:38:57 -0400 Subject: [Sip] I-D ACTION:draft-camarillo-sip-rfc3312-update-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interactions of Preconditions with Session Mobility in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, P. Kyzivat Filename : draft-camarillo-sip-rfc3312-update-00.txt Pages : 8 Date : 2003-9-4 This document describes how to use SIP preconditions in situations that involve session mobility. This document updates RFC3312, which defines the framework for SIP preconditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-rfc3312-update-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-sip-rfc3312-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sip-rfc3312-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-4095446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-rfc3312-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-rfc3312-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-4095446.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 11:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00394 for ; Thu, 4 Sep 2003 11:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uviW-0007f4-P3 for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 11:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84F8CP3029374 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 11:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uviN-0007bk-Se; Thu, 04 Sep 2003 11:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvi1-0007YD-LS for sip@optimus.ietf.org; Thu, 04 Sep 2003 11:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00290 for ; Thu, 4 Sep 2003 11:07:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uvhy-0005LP-00 for sip@ietf.org; Thu, 04 Sep 2003 11:07:38 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19uvhx-0005LM-00 for sip@ietf.org; Thu, 04 Sep 2003 11:07:37 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h84F7QAv006680; Thu, 4 Sep 2003 17:07:26 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 4 Sep 2003 17:08:53 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" Cc: "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 4 Sep 2003 17:07:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I don't think the biggest issue is how terminals build the Request-URI. The problem, I think, is when a server (especially gateways) receive the Request-URI. If the server receives a SIP-URI, and there is a "+", or visual separators, in the userpart, the server needs to know how to handle those. I also think it's a little dangerous to say that a terminal must use tel-url if it sends a dial string. Will that work in call redirection cases, will it work in call forwarding cases, etc etc etc? In other words, are there cases the terminal simply must use a SIP-URI? Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 4. syyskuuta 2003 17:25 > To: Christer Holmberg (JO/LMF) > Cc: 'Bob Penfield'; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > I disagree with some of the details below, but some points are good. > > First, the rules about who can interpret the userpart of a > sip url apply > regardless of whether user=phone is present or not. So nobody > should be > rejecting a sip url because of perceived problems with the > userpart if > it isn't their domain. > > Included in the above is construction of sip uris by phones. > You have no > business transforming dialed digits into a sip uri unless you are > prepared to play by the rules of the domain you stick in that > uri. Since > the domain is probably provisioned into the phone, at that > time you had > better ensure that the phone can play by the rules for that domain. > > That should take care of most issues of 2543 vs 3261/2806bis. > > However, for the same reasons I think it preferable for phones to use > tel: urls. The reason is that sip urls from other domains can't be > deconstructed to provide reasonable displays on devices that deal > primarily with numbers. > > Compatibility of various versions telephone-subscriber could be a > problem when dealing with tel urls. The usual guideline to be > strict in > what you send and forgiving of what you receive should apply here and > ought to be sufficient. > > Paul > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > I would support Bob's proposal, saying that a "+" indicates > global-phone-number, according to RFC2806(or bis). I don't > think there would be any backward compability issues, because > I doubt anyone is using "+" for any other purpose - at least > not as the first character of the user part. Of course, nodes > that really REQUIRE user=phone to be present, in order to > accept the request in the first, place would have to be changed. > > > > Of course, user=tel could also be used, but I really see no > use for that if the "+" rule applies. Also, user=tel COULD > cause backward compability issues. > > > > Then, since there doesn't seem to be an agreement on what > user=phone really means, related BOTH to the userpart syntax > and the message routing, we could remove it completely. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > >>-----Original Message----- > >>From: Bob Penfield [mailto:bpenfield@acmepacket.com] > >>Sent: 4. syyskuuta 2003 2:43 > >>To: sip@ietf.org > >>Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > >> > >> > >>Getting back to the problem Robert described in the > original mail, the > >>interoperability problems are a result of that fact that what > >>is a valid > >>userinfo part of a SIP URL with a user=phone parameter has > >>steadily gotten > >>stricter without any consideration for backwards > >>compatibility. The specific > >>problem he described resulted because a SIP URL created with > >>2543 rules was > >>rejected by a server applying 3261/2806 rules. The new > >>2806bis rules are > >>even stricter. I have no problem with those rules for tel-URLs. > >> > >>In spite of the lack of normative text on user-phone, the > >>statements in 2543 > >>and 3261 to the effect that it is used to distinguish phone > >>numbers from > >>usernames leads one to the reasonable conclusion that when it > >>is present, > >>the 'telephone-subscriber' BNF applies. This is the > >>conclusion that we and a > >>number of our vendors and customers came to when we ran into interop > >>problems. > >> > >>However, its not that simple since a 'telephone-subscriber' > >>keeps changing. > >> > >>>From some of the posting on this subject, there seems to > be value in > >>distinguishing a telephone number from username that happens > >>to look like a > >>telephone number without requiring that the user part be a > >>tel-URL. What I > >>would propose is that while we make the rules for user=phone > >>clearer, they > >>ought to be closer to the 2543 rules which in my experience a lot of > >>existing implementation seem to follow. If the userinfo > >>begins with "+" or > >>contains a phone-context, then it is reasonable to interpret it as a > >>tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > >>2543) should > >>apply. A server which is not responsible for the domain of > the SIP URL > >>should not reject a SIP URL because phone-context is missing. > >>Actually, I > >>believe it is reasonable to take the SIP URL host part as the > >>'default' > >>phone-context when it is missing. > >> > >>Also, we could add 'user=tel' for userinfo that MUST be > >>tel-URLs. In that > >>case, rejecting a local number without a phone-context would > >>be perfectly > >>reasonable. > >> > >>cheers, > >>(-:bob > >> > >>Robert F. Penfield > >>Chief Software Architect > >>Acme Packet, Inc. > >>130 New Boston Street > >>Woburn, MA 01801 > >>bpenfield@acmepacket.com > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 12:48:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06807 for ; Thu, 4 Sep 2003 12:48:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxHG-0004eo-Gw for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 12:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84GmAAO017842 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 12:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxH8-0004cU-Ac; Thu, 04 Sep 2003 12:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxGu-0004bb-7D for sip@optimus.ietf.org; Thu, 04 Sep 2003 12:47:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06711 for ; Thu, 4 Sep 2003 12:47:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uxGs-0007ZQ-00 for sip@ietf.org; Thu, 04 Sep 2003 12:47:46 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19uxGp-0007Ys-00 for sip@ietf.org; Thu, 04 Sep 2003 12:47:44 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19uxGb-0000Gz-00 for ; Thu, 04 Sep 2003 19:47:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.27809.144836.956440@harjus.tutpro.com> Date: Thu, 4 Sep 2003 19:47:29 +0300 To: sip@ietf.org X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Subject: [Sip] verification of diversion header (draft-levy) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit according to draft-levy-sip-diversion-06.txt, an UAS can include a diversion header in 302 reply. how can the proxy or UAC verify that the uri included the diversion header really belongs to the user of the UAS? security section of draft-levy doesn't mentions any problems related to faked uri in the diversion header, but they can be very serious, e.g., cause someone else pay for the call diverted to an expensive pstn number. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 15:43:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18301 for ; Thu, 4 Sep 2003 15:43:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v00d-0002xc-5T for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 15:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84JhB4m011320 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 15:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v00U-0002w3-3K; Thu, 04 Sep 2003 15:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v002-0002v9-FO for sip@optimus.ietf.org; Thu, 04 Sep 2003 15:42:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18221 for ; Thu, 4 Sep 2003 15:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v000-0003MG-00 for sip@ietf.org; Thu, 04 Sep 2003 15:42:32 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19v000-0003MD-00 for sip@ietf.org; Thu, 04 Sep 2003 15:42:32 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h84JgVtX002217; Thu, 4 Sep 2003 15:42:31 -0400 (EDT) Reply-To: From: "Brett Tate" To: Cc: "sip-ietf \(E-mail\)" Date: Thu, 4 Sep 2003 15:49:03 -0400 Message-ID: <003e01c3731d$983a28a0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] sip-session-timer-11: why explicitly impose proxy restrictions on all the b2bua's Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Why does draft-ietf-sip-session-timer-11 explicitly impose proxy related restrictions on all the B2BUA's? I agree that some of the proxy concepts are good recommendations for some types of B2BUA's; however they definitely do not apply to all types of B2BUA's. And in general, I am surprised to see any draft explicitly requiring a B2BUA to act like a proxy. Some B2BUA's act completely like a UA; others act mostly like a proxy; and others act at various degrees between a proxy and UA. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 15:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18478 for ; Thu, 4 Sep 2003 15:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v03Q-0003JK-K9 for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 15:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Jk4Tb012666 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 15:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v03N-0003E2-SP; Thu, 04 Sep 2003 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v02X-0003Ay-Fg for sip@optimus.ietf.org; Thu, 04 Sep 2003 15:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18387 for ; Thu, 4 Sep 2003 15:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v02V-0003PF-00 for sip@ietf.org; Thu, 04 Sep 2003 15:45:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19v02U-0003OZ-00 for sip@ietf.org; Thu, 04 Sep 2003 15:45:06 -0400 Received: from meastman-w2k01.cisco.com (dhcp-64-102-99-172.cisco.com [64.102.99.172]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h84JiZ9C014877; Thu, 4 Sep 2003 15:44:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> X-Sender: meastman@bounty.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Sep 2003 15:30:37 -0400 To: rsparks@dynamincsoft.com.cnri.reston.va.us, sip@ietf.org From: "Mark Eastman (meastman)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Canceling REFER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, I have a question about how to deal with canceling a REFER. Let's say I REFER Bob to Betty, but then decide I want to REFER Bob to someone else before the transfer is complete. Are there existing call flows describing such behavior? I know the REFER rfc states handling multiple refers is valid, but is that how one would handle this situation (Sending a new REFER with either a new target or perhaps method=CANCEL). If so, call flows describing such behavior would be nice. Thanks, Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 16:31:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20639 for ; Thu, 4 Sep 2003 16:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0lK-00057i-Vs for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 16:31:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84KVKqg019405 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 16:31:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0l4-00052Y-1w; Thu, 04 Sep 2003 16:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0kS-00051Z-T8 for sip@optimus.ietf.org; Thu, 04 Sep 2003 16:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20557 for ; Thu, 4 Sep 2003 16:30:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v0kQ-0004AN-00 for sip@ietf.org; Thu, 04 Sep 2003 16:30:30 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19v0kQ-00049w-00 for sip@ietf.org; Thu, 04 Sep 2003 16:30:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h84KTLd08129; Thu, 4 Sep 2003 15:29:21 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: "Mark Eastman (meastman)" Cc: rsparks@dynamincsoft.com.cnri.reston.va.us, sip@ietf.org In-Reply-To: <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> References: <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> Content-Type: text/plain Message-Id: <1062707358.1444.53.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Sep 2003 15:29:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There is no defined "Stop trying to access the resource I've REFERed you to" mechanism. REFER is not designed to be a remote-control for a peer endpoint. CANCELing the REFER won't make sense - the REFER is accepted or rejected immediately and processing the reference happens after that - the REFER transaction is already gone. Attempting to construct a REFER to a CANCEL that would match an INVITE triggered by a previous REFER is difficult. You don't have the appropriate Call-ID/tags handy and even if you could get them, there's language in the REFER draft that encourages an agent accepting a REFER to ignore them. So - if this functionality is something that we have a real need for, its a new method (NEVERMIND perhaps?). RjS On Thu, 2003-09-04 at 14:30, Mark Eastman (meastman) wrote: > Hello, > > I have a question about how to deal with canceling a REFER. Let's say I > REFER Bob to Betty, but then decide I want to REFER Bob to someone else > before the transfer is complete. Are there existing call flows describing > such behavior? I know the REFER rfc states handling multiple refers is > valid, but is that how one would handle this situation (Sending a new REFER > with either a new target or perhaps method=CANCEL). If so, call flows > describing such behavior would be nice. > > Thanks, > Mark > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 17:39:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24293 for ; Thu, 4 Sep 2003 17:39:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1ov-00086B-NR for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 17:39:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84LdD2G031071 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 17:39:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1ok-00084Y-5F; Thu, 04 Sep 2003 17:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1of-00084C-Q7 for sip@optimus.ietf.org; Thu, 04 Sep 2003 17:38:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24248 for ; Thu, 4 Sep 2003 17:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1od-0005Sp-00 for sip@ietf.org; Thu, 04 Sep 2003 17:38:55 -0400 Received: from web41511.mail.yahoo.com ([66.218.93.94]) by ietf-mx with smtp (Exim 4.12) id 19v1oc-0005SI-00 for sip@ietf.org; Thu, 04 Sep 2003 17:38:54 -0400 Message-ID: <20030904213823.76230.qmail@web41511.mail.yahoo.com> Received: from [207.46.228.14] by web41511.mail.yahoo.com via HTTP; Thu, 04 Sep 2003 14:38:23 PDT Date: Thu, 4 Sep 2003 14:38:23 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Canceling REFER To: "Mark Eastman \(meastman\)" , rsparks@dynamincsoft.com.cnri.reston.va.us, sip@ietf.org In-Reply-To: <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , A REFER with a method=CANCEL sounds like an interesting option. The call flow should not be difficult to come up with . --- "Mark Eastman (meastman)" wrote: > Hello, > > I have a question about how to deal with canceling a > REFER. Let's say I > REFER Bob to Betty, but then decide I want to REFER > Bob to someone else > before the transfer is complete. Are there existing > call flows describing > such behavior? I know the REFER rfc states handling > multiple refers is > valid, but is that how one would handle this > situation (Sending a new REFER > with either a new target or perhaps method=CANCEL). > If so, call flows > describing such behavior would be nice. > > Thanks, > Mark > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 20:56:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06210 for ; Thu, 4 Sep 2003 20:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4tW-0007ZB-5R for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 20:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h850uAPg029079 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 20:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4tO-0007YQ-A3; Thu, 04 Sep 2003 20:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4sj-0007Wm-EN for sip@optimus.ietf.org; Thu, 04 Sep 2003 20:55:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06093 for ; Thu, 4 Sep 2003 20:55:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v4sg-0002E8-00 for sip@ietf.org; Thu, 04 Sep 2003 20:55:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19v4sg-0002DD-00 for sip@ietf.org; Thu, 04 Sep 2003 20:55:18 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2003 18:06:53 -0700 Received: from [10.32.254.186] (stealth-10-32-254-186.cisco.com [10.32.254.186]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h850sbUR016470; Thu, 4 Sep 2003 17:54:38 -0700 (PDT) Date: Thu, 04 Sep 2003 20:54:37 -0400 From: "David R. Oran" To: Sean Olson , "Mark Eastman (meastman)" , rsparks@dynamincsoft.com.cnri.reston.va.us, sip@ietf.org Subject: Re: [Sip] Canceling REFER Message-ID: <32075125.1062708877@[10.32.254.186]> In-Reply-To: <20030904213823.76230.qmail@web41511.mail.yahoo.com> References: <20030904213823.76230.qmail@web41511.mail.yahoo.com> X-Mailer: Mulberry/3.1.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, September 04, 2003 2:38 PM -0700 Sean Olson wrote: > A REFER with a method=CANCEL sounds like an > interesting option. The call flow should not be > difficult to come up with > . I suggest we call this either "RECALL-MISSLES" or "ZEN-REFER" (the Refer that un-refers the previous refer). Dave. > --- "Mark Eastman (meastman)" > wrote: >> Hello, >> >> I have a question about how to deal with canceling a >> REFER. Let's say I >> REFER Bob to Betty, but then decide I want to REFER >> Bob to someone else >> before the transfer is complete. Are there existing >> call flows describing >> such behavior? I know the REFER rfc states handling >> multiple refers is >> valid, but is that how one would handle this >> situation (Sending a new REFER >> with either a new target or perhaps method=CANCEL). >> If so, call flows >> describing such behavior would be nice. >> >> Thanks, >> Mark >> >> >> _______________________________________________ >> Sip mailing list >> https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP >> Protocol >> Use sip-implementors@cs.columbia.edu for questions >> on current sip >> Use sipping@ietf.org for new developments on the >> application of sip > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 21:26:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07947 for ; Thu, 4 Sep 2003 21:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5MY-0000Ss-1K for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 21:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h851Q9s4001730 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 21:26:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5MP-0000RQ-OD; Thu, 04 Sep 2003 21:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5LQ-0000QJ-Tk for sip@optimus.ietf.org; Thu, 04 Sep 2003 21:25:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07859 for ; Thu, 4 Sep 2003 21:24:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v5LO-000370-00 for sip@ietf.org; Thu, 04 Sep 2003 21:24:58 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19v5LM-00036n-00 for sip@ietf.org; Thu, 04 Sep 2003 21:24:57 -0400 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h851PrU06628 for ; Fri, 5 Sep 2003 09:25:53 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h851Om809791 for ; Fri, 5 Sep 2003 09:24:49 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 09:24:47 +0800 Message-ID: <23BCA2174A77D111A52D00A0C967A6E2095712E7@HP5> From: "Chen Zaifeng,BISC R&D SA(BJ)" To: sip@ietf.org Date: Fri, 5 Sep 2003 09:14:00 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] How to operate presence contact list? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear All: For SIP based presence service an end user always needs to create, modify, and delete a contact list, or make such operations on the members of the list, would you please introduce me your ideas about how to operate and manage user contact lists stored at presence server? Through SIP or HTTP, or whatever else? And, how to maintain the consistency of a contact list if it is stored at both a user terminal and presence server? Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. TD/DEW No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 E-mail: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 22:48:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13022 for ; Thu, 4 Sep 2003 22:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6e3-0004Si-G9 for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 22:48:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h852mJHZ017030 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 22:48:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dn-0004KB-KF; Thu, 04 Sep 2003 22:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dc-0004Ix-NE for sip@optimus.ietf.org; Thu, 04 Sep 2003 22:47:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12927 for ; Thu, 4 Sep 2003 22:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v6dZ-0005jX-00 for sip@ietf.org; Thu, 04 Sep 2003 22:47:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19v6dY-0005ip-00 for sip@ietf.org; Thu, 04 Sep 2003 22:47:48 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2003 19:47:19 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h852lF8g002905; Thu, 4 Sep 2003 19:47:17 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn2-814.cisco.com [10.21.115.46]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU31783; Thu, 4 Sep 2003 19:47:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 04 Sep 2003 19:28:41 -0700 Subject: Re: [Sip] verification of diversion header (draft-levy) From: Cullen Jennings To: Juha Heinanen , Message-ID: In-Reply-To: <16215.27809.144836.956440@harjus.tutpro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/4/03 9:47 AM, "Juha Heinanen" wrote: > according to draft-levy-sip-diversion-06.txt, an UAS can include a > diversion header in 302 reply. how can the proxy or UAC verify that the > uri included the diversion header really belongs to the user of the UAS? > > security section of draft-levy doesn't mentions any problems related to > faked uri in the diversion header, but they can be very serious, e.g., > cause someone else pay for the call diverted to an expensive pstn > number. > > -- juha > Agreed - I don't think it can. It part of the end to middle authentication problem. This problem has been brought up before - I think the History requirements include requirements to be able to solve this problem. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 22:48:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13021 for ; Thu, 4 Sep 2003 22:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6e3-0004Sj-Ga for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 22:48:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h852mJFk017028 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 22:48:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6do-0004KU-S3; Thu, 04 Sep 2003 22:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dd-0004J4-0C for sip@optimus.ietf.org; Thu, 04 Sep 2003 22:47:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12928 for ; Thu, 4 Sep 2003 22:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v6dZ-0005jU-00 for sip@ietf.org; Thu, 04 Sep 2003 22:47:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19v6dX-0005ip-00 for sip@ietf.org; Thu, 04 Sep 2003 22:47:48 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2003 19:47:18 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h852lGAw019089; Thu, 4 Sep 2003 19:47:16 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn2-814.cisco.com [10.21.115.46]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU31784; Thu, 4 Sep 2003 19:47:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 04 Sep 2003 19:31:03 -0700 Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy restrictions on all the b2bua's From: Cullen Jennings To: , Jonathan Rosenberg CC: "sip-ietf (E-mail)" Message-ID: In-Reply-To: <003e01c3731d$983a28a0$2b01a8c0@broadsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/4/03 12:49 PM, "Brett Tate" wrote: > Why does draft-ietf-sip-session-timer-11 > explicitly impose proxy related restrictions > on all the B2BUA's? > > I agree that some of the proxy concepts are > good recommendations for some types of B2BUA's; > however they definitely do not apply to all > types of B2BUA's. > > And in general, I am surprised to see > any draft explicitly requiring a B2BUA to act > like a proxy. Some B2BUA's act completely like > a UA; others act mostly like a proxy; and others > act at various degrees between a proxy and UA. In fact one of the most common B2BUA in use, a GW connected to the PSTN connected to a GW, never looks like a proxy. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 4 23:58:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17264 for ; Thu, 4 Sep 2003 23:58:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v7jm-0007XC-8V for sip-archive@odin.ietf.org; Thu, 04 Sep 2003 23:58:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h853wI2r028902 for sip-archive@odin.ietf.org; Thu, 4 Sep 2003 23:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v7jW-0007V0-0p; Thu, 04 Sep 2003 23:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v7ie-0007Sz-6m for sip@optimus.ietf.org; Thu, 04 Sep 2003 23:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17210 for ; Thu, 4 Sep 2003 23:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v7ib-0000Ax-00 for sip@ietf.org; Thu, 04 Sep 2003 23:57:05 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19v7ib-00009l-00 for sip@ietf.org; Thu, 04 Sep 2003 23:57:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h853uNd15363; Thu, 4 Sep 2003 22:56:24 -0500 Subject: Re: [Sip] How to operate presence contact list? From: Robert Sparks To: "Chen Zaifeng,BISC R&D ""SA(BJ)" Cc: sip@ietf.org In-Reply-To: <23BCA2174A77D111A52D00A0C967A6E2095712E7@HP5> References: <23BCA2174A77D111A52D00A0C967A6E2095712E7@HP5> Content-Type: text/plain Message-Id: <1062734179.1443.73.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Sep 2003 22:56:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please look at the work on data manipulation in the SIMPLE working group. (see http://www.ietf.org/html.charters/simple-charter.html particularly http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-03.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-00.txt And be sure to scan the mailing list archives available at https://www1.ietf.org/mailman/listinfo/simple ) RjS On Thu, 2003-09-04 at 20:14, Chen Zaifeng,BISC R&D SA(BJ) wrote: > Dear All: > For SIP based presence service an end user always needs to create, modify, and delete a contact list, or make such operations on the members > of the list, would you please introduce me your ideas about how to operate and manage user contact lists stored at presence server? Through SIP or HTTP, or whatever else? > And, how to maintain the consistency of a contact list if it is stored at both a user terminal and presence server? > Thanks! > Sincerely yours, > Chen Zaifeng > -------------------------------------------------------------------------- > Beijing International Switching System Corporation Ltd. > TD/DEW > No. 14 Jiu Xian Qiao Road > Beijing 100016, P. R. China > Tel: +86-10-8457 1921 > Fax: +86-10-6436 7732 > E-mail: > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 00:46:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20208 for ; Fri, 5 Sep 2003 00:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v8UC-000199-Jp for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 00:46:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h854kGTg004347 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 00:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v8Ty-00013L-67; Fri, 05 Sep 2003 00:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v8TC-00011h-Aj for sip@optimus.ietf.org; Fri, 05 Sep 2003 00:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20017 for ; Fri, 5 Sep 2003 00:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v8T9-0001lb-00 for sip@ietf.org; Fri, 05 Sep 2003 00:45:11 -0400 Received: from [203.124.156.99] (helo=chandgate2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19v8T7-0001lV-00 for sip@ietf.org; Fri, 05 Sep 2003 00:45:10 -0400 Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h854JnGq001541 for ; Fri, 5 Sep 2003 09:49:55 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Fri, 05 Sep 2003 10:18:50 +0530 Date: Fri, 05 Sep 2003 10:18:50 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: faeez@mahindrabt.com Received: from dscp00973 ([10.5.14.132]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id KAA11057 for ; Fri, 5 Sep 2003 10:14:51 +0530 X-MSReally-From: faeez@mahindrabt.com Message-ID: <00bb01c37367$08abac00$840e050a@mahindrabt.com> From: "Faeez" To: References: <23BCA2174A77D111A52D00A0C967A6E2095712E7@HP5> <1062734179.1443.73.camel@RjS.localdomain> Date: Fri, 5 Sep 2003 10:04:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Proxy with muliple simultaneous requests.... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have a question.. If a SIP proxy receives multiple requests from various UACs AT THE SAME TIME how does it go about handling those requests? Meaning. what is the best way to implement the proxy so that it can gracefully handle all requests without crashing and without losing any request. Someone suggested THREADS.. but then how?? Thanks ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 01:30:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21818 for ; Fri, 5 Sep 2003 01:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9Am-0002Mn-Mm for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 01:30:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h855UGWA009037 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 01:30:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9AZ-0002LI-32; Fri, 05 Sep 2003 01:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9AA-0002Kn-Vv for sip@optimus.ietf.org; Fri, 05 Sep 2003 01:29:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21755 for ; Fri, 5 Sep 2003 01:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v99W-0002x9-00 for sip@ietf.org; Fri, 05 Sep 2003 01:28:58 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19v996-0002uS-00 for sip@ietf.org; Fri, 05 Sep 2003 01:28:32 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19v95w-00006s-00; Fri, 05 Sep 2003 08:25:16 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16216.7740.897248.985080@harjus.tutpro.com> Date: Fri, 5 Sep 2003 08:25:16 +0300 To: Cullen Jennings Cc: Subject: Re: [Sip] verification of diversion header (draft-levy) In-Reply-To: References: <16215.27809.144836.956440@harjus.tutpro.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings writes: > Agreed - I don't think it can. It part of the end to middle authentication > problem. This problem has been brought up before - I think the History > requirements include requirements to be able to solve this problem. i guess the root of the problem is in the fact that a 302 diversion header sip reply contains information that should be challenged and sip protocol doesn't allow challenging replies. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 01:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22304 for ; Fri, 5 Sep 2003 01:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9R7-00036H-5n for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 01:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h855l9lg011894 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 01:47:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9R0-00035Q-0m; Fri, 05 Sep 2003 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v9Qp-00034b-SJ for sip@optimus.ietf.org; Fri, 05 Sep 2003 01:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22276 for ; Fri, 5 Sep 2003 01:46:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v9Qh-0003FT-00 for sip@ietf.org; Fri, 05 Sep 2003 01:46:43 -0400 Received: from mta1.huawei.com ([61.144.161.40]) by ietf-mx with esmtp (Exim 4.12) id 19v9QH-0003Bd-00 for sip@ietf.org; Fri, 05 Sep 2003 01:46:17 -0400 Received: from Natarajucl1127 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HKQ00FPE7MIJA@mta1.huawei.com> for sip@ietf.org; Fri, 05 Sep 2003 13:37:34 +0800 (CST) Date: Fri, 05 Sep 2003 11:17:03 +0530 From: "Nataraju A.B." Subject: Re: [Sip] SIP Proxy with muliple simultaneous requests.... To: Faeez , sip@ietf.org Message-id: <011001c37371$23f14920$3d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_jp8nGGD8YdPwv6ZW8CvROw)" X-Priority: 3 X-MSMail-priority: Normal References: <23BCA2174A77D111A52D00A0C967A6E2095712E7@HP5> <1062734179.1443.73.camel@RjS.localdomain> <00bb01c37367$08abac00$840e050a@mahindrabt.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_jp8nGGD8YdPwv6ZW8CvROw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Not exactly multi-threadng required as long as u have multi-processor system You can have single threaded stack where in that Transport daemon serializes the received request from diff UACs for this we need to have a diff tasks. One for stack and and other for Tpt Daemon... as long as the number of requests/responses are within the bufering limit of Tpt daemmon no request will be dropped... ----- Original Message ----- From: Faeez To: sip@ietf.org Sent: Friday, September 05, 2003 10:18 AM Subject: [Sip] SIP Proxy with muliple simultaneous requests.... Hi, I have a question.. If a SIP proxy receives multiple requests from various UACs AT THE SAME TIME how does it go about handling those requests? Meaning. what is the best way to implement the proxy so that it can gracefully handle all requests without crashing and without losing any request. Someone suggested THREADS.. but then how?? Thanks ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --Boundary_(ID_jp8nGGD8YdPwv6ZW8CvROw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Not exactly multi-threadng required as long as u have multi-processor system
 
You can have single threaded stack where in that Transport daemon serializes the received request from diff UACs
 
for this we need to have a diff tasks. One for stack and and other for Tpt Daemon...
 
as long as the number of requests/responses are within the bufering limit of Tpt daemmon no request will be dropped...
 
----- Original Message -----
From: Faeez
Sent: Friday, September 05, 2003 10:18 AM
Subject: [Sip] SIP Proxy with muliple simultaneous requests....

Hi,
    I have a question.. If a SIP proxy receives multiple requests from
various UACs AT THE SAME TIME how does it go about handling those requests?
Meaning. what is the best way to implement the proxy so that it can
gracefully handle all requests without crashing and without losing any
request.
    Someone suggested THREADS.. but then how??
Thanks

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Boundary_(ID_jp8nGGD8YdPwv6ZW8CvROw)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 02:49:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06512 for ; Fri, 5 Sep 2003 02:49:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vAP8-0006pH-8E for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 02:49:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h856nAbm026238 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 02:49:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vAP0-0006ob-2u; Fri, 05 Sep 2003 02:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vAO7-0006jk-Se for sip@optimus.ietf.org; Fri, 05 Sep 2003 02:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06483 for ; Fri, 5 Sep 2003 02:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vANy-0004WO-00 for sip@ietf.org; Fri, 05 Sep 2003 02:47:58 -0400 Received: from web41509.mail.yahoo.com ([66.218.93.92]) by ietf-mx with smtp (Exim 4.12) id 19vANT-0004JT-00 for sip@ietf.org; Fri, 05 Sep 2003 02:47:27 -0400 Message-ID: <20030905054331.44147.qmail@web41509.mail.yahoo.com> Received: from [12.235.146.159] by web41509.mail.yahoo.com via HTTP; Thu, 04 Sep 2003 22:43:31 PDT Date: Thu, 4 Sep 2003 22:43:31 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Canceling REFER To: "David R. Oran" , "Mark Eastman \(meastman\)" , rsparks@dynamincsoft.com.cnri.reston.va.us, sip@ietf.org In-Reply-To: <32075125.1062708877@[10.32.254.186]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Don't you mean P-RECALL-MISSLES? --- "David R. Oran" wrote: > --On Thursday, September 04, 2003 2:38 PM -0700 Sean > Olson > wrote: > > > A REFER with a method=CANCEL sounds like an > > interesting option. The call flow should not be > > difficult to come up with > > . > I suggest we call this either "RECALL-MISSLES" or > "ZEN-REFER" (the Refer > that un-refers the previous refer). > > Dave. > > > --- "Mark Eastman (meastman)" > > wrote: > >> Hello, > >> > >> I have a question about how to deal with > canceling a > >> REFER. Let's say I > >> REFER Bob to Betty, but then decide I want to > REFER > >> Bob to someone else > >> before the transfer is complete. Are there > existing > >> call flows describing > >> such behavior? I know the REFER rfc states > handling > >> multiple refers is > >> valid, but is that how one would handle this > >> situation (Sending a new REFER > >> with either a new target or perhaps > method=CANCEL). > >> If so, call flows > >> describing such behavior would be nice. > >> > >> Thanks, > >> Mark > >> > >> > >> _______________________________________________ > >> Sip mailing list > >> https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP > >> Protocol > >> Use sip-implementors@cs.columbia.edu for > questions > >> on current sip > >> Use sipping@ietf.org for new developments on the > >> application of sip > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > > http://sitebuilder.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 04:43:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09901 for ; Fri, 5 Sep 2003 04:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vCBV-0002ug-Ap for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 04:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h858hD8X011197 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 04:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vCBK-0002u8-0f; Fri, 05 Sep 2003 04:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vCAG-0002sq-Bq for sip@optimus.ietf.org; Fri, 05 Sep 2003 04:42:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09851 for ; Fri, 5 Sep 2003 04:41:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vCA3-0006Z2-00 for sip@ietf.org; Fri, 05 Sep 2003 04:41:43 -0400 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 19vC9c-0006Xp-00 for sip@ietf.org; Fri, 05 Sep 2003 04:41:17 -0400 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id LAA07683; Fri, 5 Sep 2003 11:44:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Sep 2003 10:39:18 +0200 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A0D5C2D@MAILSRV.uns.t-systems.tss> Thread-Topic: Question regarding correct SIP behaviour in unregistration Thread-Index: AcNziTIpgci7AaigQ6OpK8Y4T5PCWQ== From: =?iso-8859-2?Q?Szel=E9nyi_Csaba?= To: , , Cc: =?iso-8859-2?Q?Attila_Petr=F3czi_=28E-mail=29?= , "Gabor Feher (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question regarding correct SIP behaviour in unregistration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, I am sorry about cross-posting this mail to the lists SIP, SIP Forum = Discussion and SIP CTWG. I could not decide, which forum is or which = forums are appropriate to be addressed with these questions.=20 Q1: IMHO RFC 3261 Section 10.3 Item 6 does not cover a case: what is the = right behaviour of the Registrar on receipt an unregistration request = for bindings that cannot be found in its database? 6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value "*" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails. When no binding is registered for the specified AOR, upon receiving a = REGISTER request with Expires header field value of zero and Contact = header field value set to '*' (i.e. there is no binding to be removed = for the given AOR, therefore the Registrar is unable to check the = Call-ID), what response must/should be sent? Is a '404 Not Found' = response or a '200 OK' response appropriate?=20 Q2: Similarly to Q1, what would be the right response ('404 Not Found' = or '200 OK') for unregistration requests, if the binding requested for = removal already expired? The binding may exist in the database for a = short time after expiration, as we have seen it checking some = implementations. If the record of the binding has been removed, we get = beck to Q1.=20 Would it be a possible answer to the questions, that it is not regulated = by RFC 3261, therefore it is up to the implementation, what to do? Any help, URL or reference would be highly appreciated. Thank you in anticipation, Szelenyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 08:56:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18498 for ; Fri, 5 Sep 2003 08:56:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vG8U-0002bI-DV for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 08:56:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85CuMPw009990 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 08:56:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vG8B-0002Zo-2E; Fri, 05 Sep 2003 08:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vG7j-0002V7-P2 for sip@optimus.ietf.org; Fri, 05 Sep 2003 08:55:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18321 for ; Fri, 5 Sep 2003 08:55:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vG7i-0004oL-00 for sip@ietf.org; Fri, 05 Sep 2003 08:55:34 -0400 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 19vG7g-0004nV-00 for sip@ietf.org; Fri, 05 Sep 2003 08:55:32 -0400 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id QAA21739; Fri, 5 Sep 2003 16:00:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Sep 2003 14:55:04 +0200 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A0D5C2E@MAILSRV.uns.t-systems.tss> Thread-Topic: Questions regarding ETSI TIPHON DTS06021-1 Thread-Index: AcNzrO2OJWW5V7vSSeG6QKyd5JuoFg== From: =?iso-8859-2?Q?Szel=E9nyi_Csaba?= To: Cc: =?iso-8859-2?Q?Attila_Petr=F3czi_=28E-mail=29?= , "Gabor Feher (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Questions regarding ETSI TIPHON DTS06021-1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, I have some questions regarding the ETSI TIPHON DTS06021-1 document. I = hope, that this is the right forum for these questions. If not, any = help, URL or advise is appreciated, where to ask questions regarding = DTS06021-1.=20 I refer to the following version of the document in this mail: http://docbox.etsi.org/TIPHON/TIPHON/07-drafts/wg6/RTS06021-1[2]/v2.0.12/= Q1:=20 The test cases SIP_CC_OE_CE_V_016 and SIP_CC_OE_CE_V_023 refer to the = 'Calling state' and I could not find any similar test case, which refer = to the 'Proceeding' state. IMHO the same tests must be executed also in = the 'Proceeding' state, as RFC 3261 states in section 17.1.1.2: When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC Is there any reason, why these test cases are not tested in the = 'Proceeding' state?=20 TPId: SIP_CC_OE_CE_V_016 Status: Mandatory Ref: 12.2.1.1[1], 13.2.2.4 [1], figure 5 [1], 17.1.1.3 [1] Purpose: Ensure that the IUT when an INVITE client transaction is in = the Calling state, on receipt of a Success (200 OK) response sends an = ACK request with the same CSeq sequence number as in the original INVITE = request and the CSeq method field value set to "ACK". TPId: SIP_CC_OE_CE_V_023 Status: Mandatory Ref: 12.2.1.1[1], 13.2.2.4 [1], figure 5 [1] Purpose: Ensure that the IUT when an INVITE client transaction is in = the Calling state, on receipt of a Success (200 OK) response with a = Record-Route header set to a list in which the last element does not = contain lr parameter, sends an ACK request with the Request-URI set to = this element and a Route header set to the remainder list in a reverse = order of the received Record-Route appended with the received Contact = URI. Q2: Why is test case SIP_CC_OE_CE_V_045 only recommended and not mandatory? = According to RFC 3261 section 20.14 it should be 'mandatory' for TCP and = can be 'recommended' only for UDP, IMHO. The Content-Length header field indicates the size of the message- body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used. TPId: SIP_CC_OE_CE_V_045 Status: Recommended Ref: 20.14 [1], 13.2.1 [1] Purpose: Ensure that the IUT while is establishing a call, sends a = Content-Length header set to the size of the body in the message that = contains the session description. Q3: Why is test case SIP_CC_TE_CE_V_010 not 'mandatory'? IMHO this test case = should be 'mandatory' according to RFC 3261 section 8.2.3: Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood ... TPId: SIP_CC_TE_CE_V_010 Status: Recommended Ref: 8.2.3 [1], 13.2.1 [1], 13.3.1 [1], 20.11 [1] Purpose: Ensure that the IUT on receipt of an INVITE request including = a Content-Language header value that it cannot understood, a = Content-Disposition header including a handling empty sends an = Unsupported Media Type (415 Unsupported Media Type) response with an = Accept header that lists the types of all bodies it understands. Q4: IMHO there might be a contradiction in test case SIP_CC_PR_MP_RS_V_006, = which is valid for stateless proxies: stateless proxies cannot have = transactions, so the clause "that does not match to an existing client = transaction" should be removed from the test case description. TPId: SIP_CC_PR_MP_RS_V_006 Status: Mandatory for Stateless Ref: 16.7 [1], 16.11 [1]=20 Purpose: Ensure that the IUT, on receipt of a Trying (100 Trying) = provisional response that does not match to an existing client = transaction, removes the topmost via from the response and forwards it = to the address indicated in the next Via header. Any help, URL or reference regarding any of the questions would be = highly appreciated. Thank you in anticipation, Szelenyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 09:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20073 for ; Fri, 5 Sep 2003 09:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGWT-0004W6-Ea for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85DL9iV017336 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:21:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGWM-0004UQ-49; Fri, 05 Sep 2003 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGVn-0004NS-2L for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:20:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19987 for ; Fri, 5 Sep 2003 09:20:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGVl-0006TT-00 for sip@ietf.org; Fri, 05 Sep 2003 09:20:25 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19vGVk-0006QN-00 for sip@ietf.org; Fri, 05 Sep 2003 09:20:24 -0400 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA11236 for ; Fri, 5 Sep 2003 09:19:52 -0400 (EDT) From: "Tolga Asveren" To: Subject: Re: [Sip] Canceling REFER Date: Fri, 5 Sep 2003 09:21:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure described in RFC3265 is valid. Tolga --- "Mark Eastman (meastman)" wrote: > Hello, > > I have a question about how to deal with canceling a > REFER. Let's say I > REFER Bob to Betty, but then decide I want to REFER > Bob to someone else > before the transfer is complete. Are there existing > call flows describing > such behavior? I know the REFER rfc states handling > multiple refers is > valid, but is that how one would handle this > situation (Sending a new REFER > with either a new target or perhaps method=CANCEL). > If so, call flows > describing such behavior would be nice. > > Thanks, > Mark > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 09:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20573 for ; Fri, 5 Sep 2003 09:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGfC-0005iP-VL for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85DUAtL021961 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:30:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGf5-0005dI-8w; Fri, 05 Sep 2003 09:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGef-0005aS-KS for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:29:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20488 for ; Fri, 5 Sep 2003 09:29:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGed-0007NJ-00 for sip@ietf.org; Fri, 05 Sep 2003 09:29:35 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19vGec-0007N6-00 for sip@ietf.org; Fri, 05 Sep 2003 09:29:34 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 65BCE312B; Fri, 5 Sep 2003 15:21:01 +0200 (CEST) Received: from jku07.iptel.org (dhcp155.fokus.fraunhofer.de [195.37.78.155]) by fox.iptel.org (Postfix) with ESMTP id 9D74E3120; Fri, 5 Sep 2003 15:21:00 +0200 (CEST) Message-Id: <5.2.0.9.0.20030905152710.04105008@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 05 Sep 2003 15:29:22 +0200 To: "Tolga Asveren" , From: Jiri Kuthan Subject: Re: [Sip] Canceling REFER In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think CANCEL would be better off. User's location can change before P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination than the original REFER. CANCEL guarantees that you use the same transport destination as the original request. -Jiri At 03:21 PM 9/5/2003, Tolga Asveren wrote: >What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. >Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure >described in RFC3265 is valid. > > Tolga >--- "Mark Eastman (meastman)" wrote: >> Hello, >> >> I have a question about how to deal with canceling a >> REFER. Let's say I >> REFER Bob to Betty, but then decide I want to REFER >> Bob to someone else >> before the transfer is complete. Are there existing >> call flows describing >> such behavior? I know the REFER rfc states handling >> multiple refers is >> valid, but is that how one would handle this >> situation (Sending a new REFER >> with either a new target or perhaps method=CANCEL). >> If so, call flows >> describing such behavior would be nice. >> >> Thanks, >> Mark >> >> >> _______________________________________________ >> Sip mailing list >> https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP >> Protocol >> Use sip-implementors@cs.columbia.edu for questions >> on current sip >> Use sipping@ietf.org for new developments on the >> application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 09:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22090 for ; Fri, 5 Sep 2003 09:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGwa-0008C6-0P for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Dm7uk031444 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGwT-00089Q-S8; Fri, 05 Sep 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGw9-000870-Vk for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22037 for ; Fri, 5 Sep 2003 09:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGw8-0001pt-00 for sip@ietf.org; Fri, 05 Sep 2003 09:47:40 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vGw7-0001mT-00 for sip@ietf.org; Fri, 05 Sep 2003 09:47:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85Dkxd24656; Fri, 5 Sep 2003 08:46:59 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: Tolga Asveren Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1062769619.928.11.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 08:46:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >From RFC3515: Terminating a subscription, either by explicitly unsubscribing or rejecting NOTIFY, is not an indication that the referenced request should be withdrawn or abandoned. In particular, an agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests because the agent sending the REFER terminated its subscription to the refer event before the referenced request completes. RjS On Fri, 2003-09-05 at 08:21, Tolga Asveren wrote: > What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure > described in RFC3265 is valid. > > Tolga > --- "Mark Eastman (meastman)" wrote: > > Hello, > > > > I have a question about how to deal with canceling a > > REFER. Let's say I > > REFER Bob to Betty, but then decide I want to REFER > > Bob to someone else > > before the transfer is complete. Are there existing > > call flows describing > > such behavior? I know the REFER rfc states handling > > multiple refers is > > valid, but is that how one would handle this > > situation (Sending a new REFER > > with either a new target or perhaps method=CANCEL). > > If so, call flows > > describing such behavior would be nice. > > > > Thanks, > > Mark > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 09:51:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22404 for ; Fri, 5 Sep 2003 09:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGzS-0000Wb-DD for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:51:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Dp661002014 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:51:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGzN-0000S4-I7; Fri, 05 Sep 2003 09:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGzK-0000RW-Al for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22320 for ; Fri, 5 Sep 2003 09:50:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGzI-0002D5-00 for sip@ietf.org; Fri, 05 Sep 2003 09:50:56 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vGzH-00029O-00 for sip@ietf.org; Fri, 05 Sep 2003 09:50:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85DoEd24723; Fri, 5 Sep 2003 08:50:14 -0500 Subject: Re: [Sip] Question regarding correct SIP behaviour in unregistration From: Robert Sparks To: =?ISO-8859-1?Q?Szel=E9nyi?= Csaba Cc: sip@ietf.org, sipforum-discussion@lists.su.se, certificationwg@sipforum.org, Attila =?ISO-8859-1?Q?Petr=F3czi?= "(E-mail)" , "Gabor Feher (E-mail)" In-Reply-To: <29026DD9543DBF4BB2B4F9325683E47A0D5C2D@MAILSRV.uns.t-systems.tss> References: <29026DD9543DBF4BB2B4F9325683E47A0D5C2D@MAILSRV.uns.t-systems.tss> Content-Type: text/plain; charset=UTF-8 Message-Id: <1062769812.921.15.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 08:50:13 -0500 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dyn-tx-arch-crash.dfw.dynamicsoft.com id h85DoEd24723 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable If the AOR exists, then the response in both cases is still 200 - You've accepted and processed the registration request. You indicate that there are no bindings by not returning any contacts in the 200 response. If the AOR does not exist, you would have returned a 404 before looking to see if there were any bindings. Deleting a contact that does not exist is not an error. RjS On Fri, 2003-09-05 at 03:39, Szel=C3=A9nyi Csaba wrote: > Hello, >=20 > I am sorry about cross-posting this mail to the lists SIP, SIP Forum Di= scussion and SIP CTWG. I could not decide, which forum is or which forums= are appropriate to be addressed with these questions.=20 >=20 > Q1: IMHO RFC 3261 Section 10.3 Item 6 does not cover a case: what is th= e right behaviour of the Registrar on receipt an unregistration request f= or bindings that cannot be found in its database? >=20 > 6. The registrar checks whether the request contains the Contact > header field. If not, it skips to the last step. If the > Contact header field is present, the registrar checks if there > is one Contact field value that contains the special value "*" > and an Expires field. If the request has additional Contact > fields or an expiration time other than zero, the request is > invalid, and the server MUST return a 400 (Invalid Request) an= d > skip the remaining steps. If not, the registrar checks whethe= r > the Call-ID agrees with the value stored for each binding. If > not, it MUST remove the binding. If it does agree, it MUST > remove the binding only if the CSeq in the request is higher > than the value stored for that binding. Otherwise, the update > MUST be aborted and the request fails. >=20 > When no binding is registered for the specified AOR, upon receiving a R= EGISTER request with Expires header field value of zero and Contact heade= r field value set to '*' (i.e. there is no binding to be removed for the = given AOR, therefore the Registrar is unable to check the Call-ID), what = response must/should be sent? Is a '404 Not Found' response or a '200 OK'= response appropriate?=20 >=20 > Q2: Similarly to Q1, what would be the right response ('404 Not Found' = or '200 OK') for unregistration requests, if the binding requested for re= moval already expired? The binding may exist in the database for a short = time after expiration, as we have seen it checking some implementations. = If the record of the binding has been removed, we get beck to Q1.=20 >=20 > Would it be a possible answer to the questions, that it is not regulate= d by RFC 3261, therefore it is up to the implementation, what to do? >=20 > Any help, URL or reference would be highly appreciated. >=20 > Thank you in anticipation, >=20 > Szelenyi Csaba > T-Systems RIC > mailto:Csaba.Szelenyi@t-systems.co.hu > +36 1 456 5507 > +36 20 477 7778 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 09:58:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22968 for ; Fri, 5 Sep 2003 09:58:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vH6H-0001UP-Kj for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Dw9PD005724 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:58:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vH6A-0001T4-6O; Fri, 05 Sep 2003 09:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vH5S-0001OK-OS for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:57:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22864 for ; Fri, 5 Sep 2003 09:57:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vH5Q-0002uP-00 for sip@ietf.org; Fri, 05 Sep 2003 09:57:16 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19vH5C-0002oL-00 for sip@ietf.org; Fri, 05 Sep 2003 09:57:02 -0400 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA22346 for ; Fri, 5 Sep 2003 09:56:29 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sip] Canceling REFER Date: Fri, 5 Sep 2003 09:58:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1062769619.928.11.camel@RjS.localdomain> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From RFC3515: The implicit subscription created by a REFER is the same as a subscription created with a SUBSCRIBE request. The agent issuing the REFER can terminate this subscription prematurely by unsubscribing using the mechanisms described in [2]. Terminating a subscription, either by explicitly unsubscribing or rejecting NOTIFY, is not an indication that the referenced request should be withdrawn or abandoned. In particular, an agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests because the agent sending the REFER terminated its subscription to the refer event before the referenced request completes. Are the second and third sentences not in conflict? Because such a SUBSCRIBE is going to be sent also in the same dialogue, I would think is a better option than a "NEVERMIND", because it will follow the same mechanism as decribed in RFC3265. Tolga > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > Sparks > Sent: Friday, September 05, 2003 9:47 AM > To: Tolga Asveren > Cc: sip@ietf.org > Subject: Re: [Sip] Canceling REFER > > > >From RFC3515: > > Terminating a subscription, > either by explicitly unsubscribing or rejecting NOTIFY, is not an > indication that the referenced request should be withdrawn or > abandoned. In particular, an agent acting on a REFER request SHOULD > NOT issue a CANCEL to any referenced SIP requests because the agent > sending the REFER terminated its subscription to the refer event > before the referenced request completes. > > RjS > > On Fri, 2003-09-05 at 08:21, Tolga Asveren wrote: > > What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > > Afterall RFC3515 states also in 2.4.4 that for unsubscribing, > the procedure > > described in RFC3265 is valid. > > > > Tolga > > --- "Mark Eastman (meastman)" wrote: > > > Hello, > > > > > > I have a question about how to deal with canceling a > > > REFER. Let's say I > > > REFER Bob to Betty, but then decide I want to REFER > > > Bob to someone else > > > before the transfer is complete. Are there existing > > > call flows describing > > > such behavior? I know the REFER rfc states handling > > > multiple refers is > > > valid, but is that how one would handle this > > > situation (Sending a new REFER > > > with either a new target or perhaps method=CANCEL). > > > If so, call flows > > > describing such behavior would be nice. > > > > > > Thanks, > > > Mark > > > > > > > > > _______________________________________________ > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 10:07:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24252 for ; Fri, 5 Sep 2003 10:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHF3-0002x4-Cd for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 10:07:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85E7Cdf011245 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 10:07:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHEr-0002pA-QY; Fri, 05 Sep 2003 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHE6-0002fB-00 for sip@optimus.ietf.org; Fri, 05 Sep 2003 10:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23985 for ; Fri, 5 Sep 2003 10:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHE3-0003vq-00 for sip@ietf.org; Fri, 05 Sep 2003 10:06:11 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vHE3-0003sP-00 for sip@ietf.org; Fri, 05 Sep 2003 10:06:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85E5Yd25057; Fri, 5 Sep 2003 09:05:34 -0500 Subject: RE: [Sip] Canceling REFER From: Robert Sparks To: Tolga Asveren Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1062770732.928.28.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 09:05:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit No, there is no conflict. The subscription can be terminated without affecting the referenced request. On Fri, 2003-09-05 at 08:58, Tolga Asveren wrote: > >From RFC3515: > The implicit subscription created by a REFER is the same as a > subscription created with a SUBSCRIBE request. The agent issuing the > REFER can terminate this subscription prematurely by unsubscribing > using the mechanisms described in [2]. Terminating a subscription, > either by explicitly unsubscribing or rejecting NOTIFY, is not an > indication that the referenced request should be withdrawn or > abandoned. In particular, an agent acting on a REFER request SHOULD > NOT issue a CANCEL to any referenced SIP requests because the agent > sending the REFER terminated its subscription to the refer event > before the referenced request completes. > > Are the second and third sentences not in conflict? > > Because such a SUBSCRIBE is going to be sent also in the same dialogue, I > would think is a better option than a "NEVERMIND", because it will follow > the same mechanism as decribed in RFC3265. A dialog is a dialog - sending any request on it is well defined. What do you see different between a SUBSCRIBE and any other method in this situation? > > > Tolga > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > > Sparks > > Sent: Friday, September 05, 2003 9:47 AM > > To: Tolga Asveren > > Cc: sip@ietf.org > > Subject: Re: [Sip] Canceling REFER > > > > > > >From RFC3515: > > > > Terminating a subscription, > > either by explicitly unsubscribing or rejecting NOTIFY, is not an > > indication that the referenced request should be withdrawn or > > abandoned. In particular, an agent acting on a REFER request SHOULD > > NOT issue a CANCEL to any referenced SIP requests because the agent > > sending the REFER terminated its subscription to the refer event > > before the referenced request completes. > > > > RjS > > > > On Fri, 2003-09-05 at 08:21, Tolga Asveren wrote: > > > What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > > > Afterall RFC3515 states also in 2.4.4 that for unsubscribing, > > the procedure > > > described in RFC3265 is valid. > > > > > > Tolga > > > --- "Mark Eastman (meastman)" wrote: > > > > Hello, > > > > > > > > I have a question about how to deal with canceling a > > > > REFER. Let's say I > > > > REFER Bob to Betty, but then decide I want to REFER > > > > Bob to someone else > > > > before the transfer is complete. Are there existing > > > > call flows describing > > > > such behavior? I know the REFER rfc states handling > > > > multiple refers is > > > > valid, but is that how one would handle this > > > > situation (Sending a new REFER > > > > with either a new target or perhaps method=CANCEL). > > > > If so, call flows > > > > describing such behavior would be nice. > > > > > > > > Thanks, > > > > Mark > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list > > > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP > > > > Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > > > > on current sip > > > > Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 10:07:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24258 for ; Fri, 5 Sep 2003 10:07:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHF3-0002wv-BN for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 10:07:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85E7Civ011246 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 10:07:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHEv-0002r6-6g; Fri, 05 Sep 2003 10:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHEo-0002oC-1A for sip@optimus.ietf.org; Fri, 05 Sep 2003 10:06:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24103 for ; Fri, 5 Sep 2003 10:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHEl-00041S-00 for sip@ietf.org; Fri, 05 Sep 2003 10:06:55 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19vHEk-0003xD-00 for sip@ietf.org; Fri, 05 Sep 2003 10:06:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00665; Fri, 5 Sep 2003 10:06:19 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15359; Fri, 5 Sep 2003 10:06:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 10:06:19 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DF2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'brett@broadsoft.com'" , jdrosen@dynamicsoft.com Cc: "sip-ietf (E-mail)" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Fri, 5 Sep 2003 10:06:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I thought it was because the two sessions the B2BUA bridges ought to be considered one session wrt the session timer. If one side dies, the other one needs to be cleaned up. That being said, if one side can support session timer, and the other can't, the B2BUA could, if it was smart enough, maintain the session timer on the one side, and clean up the other side on failure. It couldn't detect failure of the non-session-timer side of course. I was about to release -12, with only minor updates. I guess I'll let this thread play out before I release it. I could soften the text pretty easily. I personally liked the fact that B2BUA behavior was discussed. Brian > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Thursday, September 04, 2003 3:49 PM > To: jdrosen@dynamicsoft.com > Cc: sip-ietf (E-mail) > Subject: [Sip] sip-session-timer-11: why explicitly impose proxy > restrictions on all the b2bua's > > > Why does draft-ietf-sip-session-timer-11 > explicitly impose proxy related restrictions > on all the B2BUA's? > > I agree that some of the proxy concepts are > good recommendations for some types of B2BUA's; > however they definitely do not apply to all > types of B2BUA's. > > And in general, I am surprised to see > any draft explicitly requiring a B2BUA to act > like a proxy. Some B2BUA's act completely like > a UA; others act mostly like a proxy; and others > act at various degrees between a proxy and UA. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 10:35:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22091 for ; Fri, 5 Sep 2003 09:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGwZ-0008Bp-Tu for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 09:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Dm7kH031439 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 09:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGwS-000898-MK; Fri, 05 Sep 2003 09:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGvr-000856-BO for sip@optimus.ietf.org; Fri, 05 Sep 2003 09:47:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21984 for ; Fri, 5 Sep 2003 09:47:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGvp-0001nw-00 for sip@ietf.org; Fri, 05 Sep 2003 09:47:21 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vGvo-0001kE-00 for sip@ietf.org; Fri, 05 Sep 2003 09:47:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85DkRd24652; Fri, 5 Sep 2003 08:46:27 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: Jiri Kuthan Cc: Tolga Asveren , sip@ietf.org In-Reply-To: <5.2.0.9.0.20030905152710.04105008@localhost> References: <5.2.0.9.0.20030905152710.04105008@localhost> Content-Type: text/plain Message-Id: <1062769585.921.9.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 08:46:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jiri - I posted earlier why CANCEL can't be made to work. Could you respond to that (or let me know if it didn't get reflected by the list server). As for getting to the right endpoint, the NEVERMIND request could be issued inside the dialog created by the REFER. RjS On Fri, 2003-09-05 at 08:29, Jiri Kuthan wrote: > I think CANCEL would be better off. User's location can change before > P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination > than the original REFER. CANCEL guarantees that you use the same > transport destination as the original request. > > -Jiri > > At 03:21 PM 9/5/2003, Tolga Asveren wrote: > >What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > >Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure > >described in RFC3265 is valid. > > > > Tolga > >--- "Mark Eastman (meastman)" wrote: > >> Hello, > >> > >> I have a question about how to deal with canceling a > >> REFER. Let's say I > >> REFER Bob to Betty, but then decide I want to REFER > >> Bob to someone else > >> before the transfer is complete. Are there existing > >> call flows describing > >> such behavior? I know the REFER rfc states handling > >> multiple refers is > >> valid, but is that how one would handle this > >> situation (Sending a new REFER > >> with either a new target or perhaps method=CANCEL). > >> If so, call flows > >> describing such behavior would be nice. > >> > >> Thanks, > >> Mark > >> > >> > >> _______________________________________________ > >> Sip mailing list > >> https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP > >> Protocol > >> Use sip-implementors@cs.columbia.edu for questions > >> on current sip > >> Use sipping@ietf.org for new developments on the > >> application of sip > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > -- > Jiri Kuthan http://iptel.org/~jiri/ > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 10:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27568 for ; Fri, 5 Sep 2003 10:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHom-0008Qy-Gr for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 10:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Ei8ev032416 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 10:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHof-0008PW-HB; Fri, 05 Sep 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHoc-0008Ot-7J for sip@optimus.ietf.org; Fri, 05 Sep 2003 10:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27520 for ; Fri, 5 Sep 2003 10:43:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHoZ-00002Z-00 for sip@ietf.org; Fri, 05 Sep 2003 10:43:55 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19vHoY-0007mq-00 for sip@ietf.org; Fri, 05 Sep 2003 10:43:54 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h85EhGoD001917; Fri, 5 Sep 2003 10:43:16 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 09:43:17 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8640A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , "'brett@broadsoft.com'" , Jonathan Rosenberg Cc: "sip-ietf (E-mail)" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Fri, 5 Sep 2003 09:43:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think the major point is that, with B2BUAs, all bets are off. As long as they look like SIP UAs on both sides, they meet spec. There's nothing we can do about this. Cullen points out exactly what I was going to. I'll expand on this some. I have a SIP phone on my desk. So does Alan. However, because I'm lazy, I often pick up my SIP phone and call his normal PSTN number. That goes to my PSTN gateway, through the PSTN to Alan's gateway, and rings Alan's SIP phone. From a protocol perspective, my PSTN gateway, the PSTN, and Alan's PSTN gateway, as an aggregate, form a B2BUA. Is there any reasonable way you can impose a restriction on such a system as a whole? No. As long as each SIP User Agent acts as a proper User Agent, everything else is completely dependant on the purpose of the system. /a > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, September 05, 2003 9:06 > To: 'brett@broadsoft.com'; jdrosen@dynamicsoft.com > Cc: sip-ietf (E-mail) > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy > restr ictions on all the b2bua's > > > I thought it was because the two sessions the B2BUA bridges ought > to be considered one session wrt the session timer. If one side > dies, the other one needs to be cleaned up. > > That being said, if one side can support session timer, and the > other can't, the B2BUA could, if it was smart enough, maintain > the session timer on the one side, and clean up the other side > on failure. It couldn't detect failure of the non-session-timer > side of course. > > I was about to release -12, with only minor updates. I guess > I'll let this thread play out before I release it. I could > soften the text pretty easily. > > I personally liked the fact that B2BUA behavior was discussed. > > Brian > > > -----Original Message----- > > From: Brett Tate [mailto:brett@broadsoft.com] > > Sent: Thursday, September 04, 2003 3:49 PM > > To: jdrosen@dynamicsoft.com > > Cc: sip-ietf (E-mail) > > Subject: [Sip] sip-session-timer-11: why explicitly impose proxy > > restrictions on all the b2bua's > > > > > > Why does draft-ietf-sip-session-timer-11 > > explicitly impose proxy related restrictions > > on all the B2BUA's? > > > > I agree that some of the proxy concepts are > > good recommendations for some types of B2BUA's; > > however they definitely do not apply to all > > types of B2BUA's. > > > > And in general, I am surprised to see > > any draft explicitly requiring a B2BUA to act > > like a proxy. Some B2BUA's act completely like > > a UA; others act mostly like a proxy; and others > > act at various degrees between a proxy and UA. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 10:58:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28497 for ; Fri, 5 Sep 2003 10:58:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vI2R-00023e-3X for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 10:58:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85EwEW3007849 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 10:58:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vI2D-00020m-NE; Fri, 05 Sep 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vI1n-0001xM-Ij for sip@optimus.ietf.org; Fri, 05 Sep 2003 10:57:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28450 for ; Fri, 5 Sep 2003 10:57:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vI1j-0002uH-00 for sip@ietf.org; Fri, 05 Sep 2003 10:57:31 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19vI1i-0002n6-00 for sip@ietf.org; Fri, 05 Sep 2003 10:57:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03015; Fri, 5 Sep 2003 10:56:58 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23195; Fri, 5 Sep 2003 10:56:59 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 10:56:59 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Adam Roach'" , "'brett@broadsoft.com'" , Jonathan Rosenberg Cc: "sip-ietf (E-mail)" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Fri, 5 Sep 2003 10:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I understand why you claim such a system is a B2BUA. Of course, with that example, there are no rules whatsoever on a B2BUA, except that each side is a UA. Does that imply that there should not be any mention of B2BUAs at all in any document other than 3261, which is quite deliberately vague? I would AT LEAST want to point out issues, such as the "one side fails, the other side should be brought down". By your reckoning, would that be out of scope for a standards track document, and merely notes in some BCP? I've been seeing lots of B2BUA "misuse" lately. The common one is "I have a proxy that modifies headers, therefore I call it a B2BUA, and everyone is fine". There are no protocol police, and there are no "architecture" police, but I think it is in the community's interest to at least provide expert guidance on how B2BUAs 'should' work. This is an example. 'Should' is okay with me; it would let your example be "legal". Brian > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Friday, September 05, 2003 10:43 AM > To: 'Rosen, Brian'; 'brett@broadsoft.com'; Jonathan Rosenberg > Cc: sip-ietf (E-mail) > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy > restr ictions on all the b2bua's > > > I think the major point is that, with B2BUAs, all bets are off. > As long as they look like SIP UAs on both sides, they meet > spec. There's nothing we can do about this. Cullen points > out exactly what I was going to. I'll expand on this some. > > I have a SIP phone on my desk. So does Alan. However, > because I'm lazy, I often pick up my SIP phone and call > his normal PSTN number. That goes to my PSTN gateway, > through the PSTN to Alan's gateway, and rings Alan's > SIP phone. > > From a protocol perspective, my PSTN gateway, the PSTN, > and Alan's PSTN gateway, as an aggregate, form a B2BUA. > > Is there any reasonable way you can impose a restriction > on such a system as a whole? No. As long as each SIP User > Agent acts as a proper User Agent, everything else is > completely dependant on the purpose of the system. > > /a > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, September 05, 2003 9:06 > > To: 'brett@broadsoft.com'; jdrosen@dynamicsoft.com > > Cc: sip-ietf (E-mail) > > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy > > restr ictions on all the b2bua's > > > > > > I thought it was because the two sessions the B2BUA bridges ought > > to be considered one session wrt the session timer. If one side > > dies, the other one needs to be cleaned up. > > > > That being said, if one side can support session timer, and the > > other can't, the B2BUA could, if it was smart enough, maintain > > the session timer on the one side, and clean up the other side > > on failure. It couldn't detect failure of the non-session-timer > > side of course. > > > > I was about to release -12, with only minor updates. I guess > > I'll let this thread play out before I release it. I could > > soften the text pretty easily. > > > > I personally liked the fact that B2BUA behavior was discussed. > > > > Brian > > > > > -----Original Message----- > > > From: Brett Tate [mailto:brett@broadsoft.com] > > > Sent: Thursday, September 04, 2003 3:49 PM > > > To: jdrosen@dynamicsoft.com > > > Cc: sip-ietf (E-mail) > > > Subject: [Sip] sip-session-timer-11: why explicitly impose proxy > > > restrictions on all the b2bua's > > > > > > > > > Why does draft-ietf-sip-session-timer-11 > > > explicitly impose proxy related restrictions > > > on all the B2BUA's? > > > > > > I agree that some of the proxy concepts are > > > good recommendations for some types of B2BUA's; > > > however they definitely do not apply to all > > > types of B2BUA's. > > > > > > And in general, I am surprised to see > > > any draft explicitly requiring a B2BUA to act > > > like a proxy. Some B2BUA's act completely like > > > a UA; others act mostly like a proxy; and others > > > act at various degrees between a proxy and UA. > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 11:25:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00720 for ; Fri, 5 Sep 2003 11:25:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vISV-0005og-Uo for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 11:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85FPBgh022357 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 11:25:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vISM-0005mu-VH; Fri, 05 Sep 2003 11:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vIS8-0005l6-J9 for sip@optimus.ietf.org; Fri, 05 Sep 2003 11:24:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00627 for ; Fri, 5 Sep 2003 11:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vIS7-0006ms-00 for sip@ietf.org; Fri, 05 Sep 2003 11:24:47 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19vIS6-0006jR-00 for sip@ietf.org; Fri, 05 Sep 2003 11:24:46 -0400 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id LAA13730 for ; Fri, 5 Sep 2003 11:24:16 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sip] Canceling REFER Date: Fri, 5 Sep 2003 11:26:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1062770732.928.28.camel@RjS.localdomain> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > Sparks > Sent: Friday, September 05, 2003 10:06 AM > To: Tolga Asveren > Cc: sip@ietf.org > Subject: RE: [Sip] Canceling REFER > > > No, there is no conflict. The subscription can be terminated without > affecting the referenced request. [TOLGA] O.K. , I see, yes they are different things. > > On Fri, 2003-09-05 at 08:58, Tolga Asveren wrote: > > >From RFC3515: > > The implicit subscription created by a REFER is the same as a > > subscription created with a SUBSCRIBE request. The agent issuing the > > REFER can terminate this subscription prematurely by unsubscribing > > using the mechanisms described in [2]. Terminating a subscription, > > either by explicitly unsubscribing or rejecting NOTIFY, is not an > > indication that the referenced request should be withdrawn or > > abandoned. In particular, an agent acting on a REFER request SHOULD > > NOT issue a CANCEL to any referenced SIP requests because the agent > > sending the REFER terminated its subscription to the refer event > > before the referenced request completes. > > > > Are the second and third sentences not in conflict? > > > > Because such a SUBSCRIBE is going to be sent also in the same > dialogue, I > > would think is a better option than a "NEVERMIND", because it > will follow > > the same mechanism as decribed in RFC3265. > > A dialog is a dialog - sending any request on it is well defined. What > do you see different between a SUBSCRIBE and any other method in this > situation? [TOLGA]That was my point, that a SUBSCRIBE is also just a method inside a dialogue. But because of the above -that SUBSCRIBE does terminate the subscription, not the referenced request-, SUBSCRIBE is not a solution, unless that behaviour is changed. But still, I would think, changing semantics for SUBSCRIBE/0 -and allowing it to abandon a pending referenced request- should work. What was the reason, not to allow SUBSCRIBE/0 to do so? > > > > > > > Tolga > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Robert > > > Sparks > > > Sent: Friday, September 05, 2003 9:47 AM > > > To: Tolga Asveren > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] Canceling REFER > > > > > > > > > >From RFC3515: > > > > > > Terminating a subscription, > > > either by explicitly unsubscribing or rejecting NOTIFY, is not an > > > indication that the referenced request should be withdrawn or > > > abandoned. In particular, an agent acting on a REFER > request SHOULD > > > NOT issue a CANCEL to any referenced SIP requests because the agent > > > sending the REFER terminated its subscription to the refer event > > > before the referenced request completes. > > > > > > RjS > > > > > > On Fri, 2003-09-05 at 08:21, Tolga Asveren wrote: > > > > What about sending SUBSCRIBE with Expires=0 , as described > in RFC3265. > > > > Afterall RFC3515 states also in 2.4.4 that for unsubscribing, > > > the procedure > > > > described in RFC3265 is valid. > > > > > > > > Tolga > > > > --- "Mark Eastman (meastman)" wrote: > > > > > Hello, > > > > > > > > > > I have a question about how to deal with canceling a > > > > > REFER. Let's say I > > > > > REFER Bob to Betty, but then decide I want to REFER > > > > > Bob to someone else > > > > > before the transfer is complete. Are there existing > > > > > call flows describing > > > > > such behavior? I know the REFER rfc states handling > > > > > multiple refers is > > > > > valid, but is that how one would handle this > > > > > situation (Sending a new REFER > > > > > with either a new target or perhaps method=CANCEL). > > > > > If so, call flows > > > > > describing such behavior would be nice. > > > > > > > > > > Thanks, > > > > > Mark > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list > > > > > https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP > > > > > Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions > > > > > on current sip > > > > > Use sipping@ietf.org for new developments on the > > > > > application of sip > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 11:45:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01904 for ; Fri, 5 Sep 2003 11:45:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vIly-0000Ug-Vf for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 11:45:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85FjI7u001836 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 11:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vIlk-0000Je-EK; Fri, 05 Sep 2003 11:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vIkw-0000E8-Dh for sip@optimus.ietf.org; Fri, 05 Sep 2003 11:44:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01815 for ; Fri, 5 Sep 2003 11:44:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vIkv-0000yW-00 for sip@ietf.org; Fri, 05 Sep 2003 11:44:13 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vIku-0000v2-00 for sip@ietf.org; Fri, 05 Sep 2003 11:44:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85FhXd26774; Fri, 5 Sep 2003 10:43:33 -0500 Subject: RE: [Sip] Canceling REFER From: Robert Sparks To: Tolga Asveren Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1062776611.928.81.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 10:43:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-09-05 at 10:26, Tolga Asveren wrote: > [TOLGA]That was my point, that a SUBSCRIBE is also just a method inside a > dialogue. But because of the above -that SUBSCRIBE does terminate the > subscription, not the referenced request-, SUBSCRIBE is not a solution, > unless that behaviour is changed. But still, I would think, changing > semantics for SUBSCRIBE/0 -and allowing it to abandon a pending referenced > request- should work. What was the reason, not to allow SUBSCRIBE/0 to do > so? Things like allowing endpoints that don't care about the result of the reference (true "blind" transfer for example) to not have to take on subscription state by rejecting the first NOTIFY. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:14:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06632 for ; Fri, 5 Sep 2003 13:14:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vK9z-0003L1-Lr for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:14:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85HEB4d012825 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vK9q-0003Jc-08; Fri, 05 Sep 2003 13:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vK9S-0003HF-30 for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:13:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06603 for ; Fri, 5 Sep 2003 13:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vK9P-0002Bb-00 for sip@ietf.org; Fri, 05 Sep 2003 13:13:36 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19vK9O-00028l-00 for sip@ietf.org; Fri, 05 Sep 2003 13:13:35 -0400 Received: from softarmor.com (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h85HD498020157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Sep 2003 12:13:04 -0500 Message-ID: <3F58C41C.9040105@softarmor.com> Date: Fri, 05 Sep 2003 12:13:00 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <2038BCC78B1AD641891A0D1AE133DBB701797082@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797082@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: >>sip:12345@foo.bar is sip:12345@foo.bar (surprise, surprise) >> >> > >You cannot make that conclusion. I belong to operator1.com that gave me this number 12345 as my telephone number. You are with operator2 and they gave you the sip address 12345@operator2.com > >Now, someone, not you, from operator2.com (your operator) wants to call me. They dial 12345. Using your logic, your phone ends up ringing instead of mine. > > Well, I think we know how to tell 12345@operator1.com from 12345@operator2.com, with or without user=phone. There's certainly no particular reason that the operator1.com proxy should know to forward 12345@operator1.com;user=phone to 12345@operator2.com, One COULD manually configure that sort of rule, but it seems likely to break the universe if you tried to do it for ever possible phone number. You're asking "If @operator1.com is the default domain, how do I dial something @operator2.com"? The answer is -- the user has to enter that part, somehow. If your email client adds @nokia.com to outgoing email that doesn't specify a domain, and you send an email to "dean.willis", I imagine that the nokia email sever is likely to reject it -- unless they've decided to offer me enough money to defect and I haven't found out yet (I'm easy, but not cheap). What I think you WANT to be asking is "How does a user entering a short-form request indicate whether he wants it treated as a phone number (looked up in ENUM or sent to a PSTN gateway) or treated as a SIP username?" I don't have an answer for that. None of the phones I use seem to have a mechanism for entering this distinction. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07077 for ; Fri, 5 Sep 2003 13:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKGe-0004Mh-WF for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85HL4VK016748 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKGc-0004LJ-7w; Fri, 05 Sep 2003 13:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKGH-0004IG-7i for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:20:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07004 for ; Fri, 5 Sep 2003 13:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vKGF-0002x0-00 for sip@ietf.org; Fri, 05 Sep 2003 13:20:39 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19vKGE-0002tw-00 for sip@ietf.org; Fri, 05 Sep 2003 13:20:38 -0400 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id NAA07719 for ; Fri, 5 Sep 2003 13:20:08 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sip] Canceling REFER Date: Fri, 5 Sep 2003 13:22:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1062776611.928.81.camel@RjS.localdomain> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > Sparks > Sent: Friday, September 05, 2003 11:44 AM > To: Tolga Asveren > Cc: sip@ietf.org > Subject: RE: [Sip] Canceling REFER > > > On Fri, 2003-09-05 at 10:26, Tolga Asveren wrote: > > [TOLGA]That was my point, that a SUBSCRIBE is also just a > method inside a > > dialogue. But because of the above -that SUBSCRIBE does terminate the > > subscription, not the referenced request-, SUBSCRIBE is not a solution, > > unless that behaviour is changed. But still, I would think, changing > > semantics for SUBSCRIBE/0 -and allowing it to abandon a pending > referenced > > request- should work. What was the reason, not to allow > SUBSCRIBE/0 to do > > so? > > Things like allowing endpoints that don't care about the result of the > reference (true "blind" transfer for example) to not have to take on > subscription state by rejecting the first NOTIFY. [TOLGA]Even to cover such a case: a)rejecting NOTIFY ===>go ahead with request but cancel the subscription b)SUBSCRIBE/0 ====>if request is pending send CANCEL, and cancel the subscription seems working. Now, the above just won't cover the case, where the initiator of REFER decides *after it send the response for NOTIFY*, that it is no more interested in the result of request but also does not want the request to be cancelled. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07478 for ; Fri, 5 Sep 2003 13:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKNS-0005Q5-0o for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85HS5MG020816 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKNO-0005Oq-FW; Fri, 05 Sep 2003 13:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKNK-0005OC-CE for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:27:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07445 for ; Fri, 5 Sep 2003 13:27:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vKNI-0003hU-00 for sip@ietf.org; Fri, 05 Sep 2003 13:27:56 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19vKNH-0003eJ-00 for sip@ietf.org; Fri, 05 Sep 2003 13:27:55 -0400 Received: from softarmor.com (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h85HRO98020258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Sep 2003 12:27:25 -0500 Message-ID: <3F58C779.5010302@softarmor.com> Date: Fri, 05 Sep 2003 12:27:21 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "sip-ietf (E-mail)" Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's References: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >I understand why you claim such a system is a B2BUA. >Of course, with that example, there are no rules whatsoever >on a B2BUA, except that each side is a UA. > > > Congratulations, you've perfectly restated the definition of B2BUA, >Does that imply that there should not be any mention >of B2BUAs at all in any document other than 3261, which >is quite deliberately vague? > > In general, a B2BUA is a UA, and is bound by all the requirements of a UA. I suggest that mentioning B2BUAs in IETF documents is only appropriate in a document specific to B2BUA behaviors, such as the proposed informational on how to build a B2BUA that works as much like a proxy as possible. >I would AT LEAST want to point out issues, such as >the "one side fails, the other side should be brought down". >By your reckoning, would that be out of scope for a standards >track document, and merely notes in some BCP? > > Is that actually the correct behavior for a B2BUA? What is the function of the B2BUA we're talking about? How do you know? For example, the Asterisk conference bridge is a B2BUA that has the behavior of bridging the audio between multiple external UAs. If one party on a conference expires, does that mean that the whole conference needs to be torn down? >I've been seeing lots of B2BUA "misuse" lately. The common >one is "I have a proxy that modifies headers, therefore >I call it a B2BUA, and everyone is fine". There are >no protocol police, and there are no "architecture" police, >but I think it is in the community's interest to at least >provide expert guidance on how B2BUAs 'should' work. >This is an example. 'Should' is okay with me; it would let >your example be "legal". > > Again, you're thinking of the "mostly transparent b2bua that sort of works like a proxy, kindof, maybe, sometimes". This is probably a worthwhile topic for discussion, but shouldn't impact mainstream specifications in any way. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:45:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08527 for ; Fri, 5 Sep 2003 13:45:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKe1-0007kF-GQ for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:45:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85HjDt3029710 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKdq-0007e1-N4; Fri, 05 Sep 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKdO-0007bF-Ir for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08436 for ; Fri, 5 Sep 2003 13:44:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vKdM-0005Nc-00 for sip@ietf.org; Fri, 05 Sep 2003 13:44:32 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19vKdL-0005KN-00 for sip@ietf.org; Fri, 05 Sep 2003 13:44:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h85Hhod28912; Fri, 5 Sep 2003 12:43:54 -0500 Subject: RE: [Sip] Canceling REFER From: Robert Sparks To: Tolga Asveren Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1062783828.921.102.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 05 Sep 2003 12:43:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-09-05 at 12:22, Tolga Asveren wrote: > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert > > Sparks > > Sent: Friday, September 05, 2003 11:44 AM > > To: Tolga Asveren > > Cc: sip@ietf.org > > Subject: RE: [Sip] Canceling REFER > > > > > > On Fri, 2003-09-05 at 10:26, Tolga Asveren wrote: > > > [TOLGA]That was my point, that a SUBSCRIBE is also just a > > method inside a > > > dialogue. But because of the above -that SUBSCRIBE does terminate the > > > subscription, not the referenced request-, SUBSCRIBE is not a solution, > > > unless that behaviour is changed. But still, I would think, changing > > > semantics for SUBSCRIBE/0 -and allowing it to abandon a pending > > referenced > > > request- should work. What was the reason, not to allow > > SUBSCRIBE/0 to do > > > so? > > > > Things like allowing endpoints that don't care about the result of the > > reference (true "blind" transfer for example) to not have to take on > > subscription state by rejecting the first NOTIFY. > [TOLGA]Even to cover such a case: > a)rejecting NOTIFY ===>go ahead with request but cancel the subscription > b)SUBSCRIBE/0 ====>if request is pending send CANCEL, and cancel the > subscription > seems working. > Now, the above just won't cover the case, where the initiator of REFER > decides *after it send the response for NOTIFY*, that it is no more > interested in the result of request but also does not want the request to be > cancelled. Hence, SUBSCRIBE/0 is really not where we want to go. Among other things, it would take us (again) down a path where we overload an operation to mean two things that really need to be handled separately. So - =IF= we want to pursue this, it really does need to be a new method. Lets focus on that "if" for awhile instead of the mechanics of "how". What's the compelling first application of having such a tool? RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:50:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08801 for ; Fri, 5 Sep 2003 13:50:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKij-0008Sh-90 for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Ho5xK032510 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:50:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKih-0008RI-1s; Fri, 05 Sep 2003 13:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKhl-0008LI-AX for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:49:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08760 for ; Fri, 5 Sep 2003 13:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vKhi-0005rd-00 for sip@ietf.org; Fri, 05 Sep 2003 13:49:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19vKhg-0005oO-00 for sip@ietf.org; Fri, 05 Sep 2003 13:49:00 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 05 Sep 2003 10:48:31 -0700 Received: from [10.32.254.186] (stealth-10-32-254-186.cisco.com [10.32.254.186]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id h85HmQbe019315; Fri, 5 Sep 2003 10:48:27 -0700 (PDT) Date: Fri, 05 Sep 2003 13:48:25 -0400 From: "David R. Oran" To: "Rosen, Brian" , "'Adam Roach'" , "'brett@broadsoft.com'" , Jonathan Rosenberg cc: "sip-ietf (E-mail)" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Message-ID: <92903390.1062769705@[10.32.254.186]> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comm s.marconi.com> X-Mailer: Mulberry/3.1.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ah, dej=E1 vu all over again... I'll repeat the argument I made many moons ago that we should delete all=20 references to anything called a "B2BUA", except to perhaps have an=20 expansion of the acronym in our WG lexicon, and a statement somewhere,=20 perhaps SIPCHANGE which says, in effect: "A B2BUA is, loosely speaking, two SIP user agents glued together in=20 completely unspecified ways. A SIP specification intended for standards=20 track MUST NOT use the term B2BUA in any normative language. SIP=20 specifications of any category SHOULD NOT use this term in descriptions of=20 algorithms or protocol usage. The term MAY be used to compare alternatives, = e.g. in requirements documents, or where the concept helps in elucidating=20 the problem being addressed." Dave. --On Friday, September 05, 2003 10:56 AM -0400 "Rosen, Brian"=20 wrote: > I understand why you claim such a system is a B2BUA. > Of course, with that example, there are no rules whatsoever > on a B2BUA, except that each side is a UA. > > Does that imply that there should not be any mention > of B2BUAs at all in any document other than 3261, which > is quite deliberately vague? > > I would AT LEAST want to point out issues, such as > the "one side fails, the other side should be brought down". > By your reckoning, would that be out of scope for a standards > track document, and merely notes in some BCP? > > I've been seeing lots of B2BUA "misuse" lately. The common > one is "I have a proxy that modifies headers, therefore > I call it a B2BUA, and everyone is fine". There are > no protocol police, and there are no "architecture" police, > but I think it is in the community's interest to at least > provide expert guidance on how B2BUAs 'should' work. > This is an example. 'Should' is okay with me; it would let > your example be "legal". > > Brian > >> -----Original Message----- >> From: Adam Roach [mailto:adam@dynamicsoft.com] >> Sent: Friday, September 05, 2003 10:43 AM >> To: 'Rosen, Brian'; 'brett@broadsoft.com'; Jonathan Rosenberg >> Cc: sip-ietf (E-mail) >> Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy >> restr ictions on all the b2bua's >> >> >> I think the major point is that, with B2BUAs, all bets are off. >> As long as they look like SIP UAs on both sides, they meet >> spec. There's nothing we can do about this. Cullen points >> out exactly what I was going to. I'll expand on this some. >> >> I have a SIP phone on my desk. So does Alan. However, >> because I'm lazy, I often pick up my SIP phone and call >> his normal PSTN number. That goes to my PSTN gateway, >> through the PSTN to Alan's gateway, and rings Alan's >> SIP phone. >> >> From a protocol perspective, my PSTN gateway, the PSTN, >> and Alan's PSTN gateway, as an aggregate, form a B2BUA. >> >> Is there any reasonable way you can impose a restriction >> on such a system as a whole? No. As long as each SIP User >> Agent acts as a proper User Agent, everything else is >> completely dependant on the purpose of the system. >> >> /a >> >> >> > -----Original Message----- >> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> > Sent: Friday, September 05, 2003 9:06 >> > To: 'brett@broadsoft.com'; jdrosen@dynamicsoft.com >> > Cc: sip-ietf (E-mail) >> > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy >> > restr ictions on all the b2bua's >> > >> > >> > I thought it was because the two sessions the B2BUA bridges ought >> > to be considered one session wrt the session timer. If one side >> > dies, the other one needs to be cleaned up. >> > >> > That being said, if one side can support session timer, and the >> > other can't, the B2BUA could, if it was smart enough, maintain >> > the session timer on the one side, and clean up the other side >> > on failure. It couldn't detect failure of the non-session-timer >> > side of course. >> > >> > I was about to release -12, with only minor updates. I guess >> > I'll let this thread play out before I release it. I could >> > soften the text pretty easily. >> > >> > I personally liked the fact that B2BUA behavior was discussed. >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: Brett Tate [mailto:brett@broadsoft.com] >> > > Sent: Thursday, September 04, 2003 3:49 PM >> > > To: jdrosen@dynamicsoft.com >> > > Cc: sip-ietf (E-mail) >> > > Subject: [Sip] sip-session-timer-11: why explicitly impose proxy >> > > restrictions on all the b2bua's >> > > >> > > >> > > Why does draft-ietf-sip-session-timer-11 >> > > explicitly impose proxy related restrictions >> > > on all the B2BUA's? >> > > >> > > I agree that some of the proxy concepts are >> > > good recommendations for some types of B2BUA's; >> > > however they definitely do not apply to all >> > > types of B2BUA's. >> > > >> > > And in general, I am surprised to see >> > > any draft explicitly requiring a B2BUA to act >> > > like a proxy. Some B2BUA's act completely like >> > > a UA; others act mostly like a proxy; and others >> > > act at various degrees between a proxy and UA. >> > > >> > > >> > > _______________________________________________ >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > This list is for NEW development of the core SIP Protocol >> > > Use sip-implementors@cs.columbia.edu for questions on current sip >> > > Use sipping@ietf.org for new developments on the >> application of sip >> > > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 13:54:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09062 for ; Fri, 5 Sep 2003 13:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKmb-0000jw-T8 for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 13:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Hs5mr002835 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 13:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKmY-0000is-CQ; Fri, 05 Sep 2003 13:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vKmQ-0000hV-Nn for sip@optimus.ietf.org; Fri, 05 Sep 2003 13:53:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09005 for ; Fri, 5 Sep 2003 13:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vKmO-0006LZ-00 for sip@ietf.org; Fri, 05 Sep 2003 13:53:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19vKmN-0006IS-00 for sip@ietf.org; Fri, 05 Sep 2003 13:53:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2003 11:05:42 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h85HrHAw027935; Fri, 5 Sep 2003 10:53:18 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACD15140; Fri, 5 Sep 2003 13:53:16 -0400 (EDT) Message-ID: <3F58CD8B.2090303@cisco.com> Date: Fri, 05 Sep 2003 13:53:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Adam Roach'" , "'brett@broadsoft.com'" , Jonathan Rosenberg , "sip-ietf (E-mail)" Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's References: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I understand why you claim such a system is a B2BUA. > Of course, with that example, there are no rules whatsoever > on a B2BUA, except that each side is a UA. > > Does that imply that there should not be any mention > of B2BUAs at all in any document other than 3261, which > is quite deliberately vague? > > I would AT LEAST want to point out issues, such as > the "one side fails, the other side should be brought down". > By your reckoning, would that be out of scope for a standards > track document, and merely notes in some BCP? I can easily come up with cases where "one side fails, the other side should be brought down" is the wrong policy. Yes, it might be a good thing for some BCP. I think that it is true that as long as a B2BUA acts properly as a UA on both sides then it is compliant. Any other limitations that might be imposed really apply to particular specializations of B2BUA that *could* be defined and standardized if somebody comes up with a good reason. > I've been seeing lots of B2BUA "misuse" lately. The common > one is "I have a proxy that modifies headers, therefore > I call it a B2BUA, and everyone is fine". Maybe we really do need to define the fabled "transparent B2BUA" to cover this case. But I suspect if we do that we will find disagreement on exactly how transparent it should be. > There are > no protocol police, and there are no "architecture" police, > but I think it is in the community's interest to at least > provide expert guidance on how B2BUAs 'should' work. > This is an example. 'Should' is okay with me; it would let > your example be "legal". Better to let people hang themselves with the rope we have given them. We can fix if we find too many dead people. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 14:10:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09899 for ; Fri, 5 Sep 2003 14:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vL27-0002q0-5r for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 14:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85IA7vJ010883 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 14:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vL23-0002og-1o; Fri, 05 Sep 2003 14:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vL1q-0002nJ-Qk for sip@optimus.ietf.org; Fri, 05 Sep 2003 14:09:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09818 for ; Fri, 5 Sep 2003 14:09:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vL1o-00003M-00 for sip@ietf.org; Fri, 05 Sep 2003 14:09:48 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19vL1n-00003J-00 for sip@ietf.org; Fri, 05 Sep 2003 14:09:47 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h85I9l0x082572; Fri, 5 Sep 2003 14:09:47 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'sip-ietf \(E-mail\)'" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Fri, 5 Sep 2003 14:16:24 -0400 Message-ID: <006e01c373d9$d14c4580$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Does that imply that there should not be any mention > of B2BUAs at all in any document other than 3261, > which is quite deliberately vague? > > I would AT LEAST want to point out issues, such as > the "one side fails, the other side should be brought > down". Even that is not necessarily always true since some b2bua's might want to connect the still active side to treatments or trigger another call to the dropped party. > By your reckoning, would that be out of scope > for a standards track document, and merely notes > in some BCP? Unless the standards track document is explicitly associated with how one must or should implement a particular category of b2bua, I do not think that a document should impose a MUST or SHOULD upon how a B2BUA bridges the two call halves. > I've been seeing lots of B2BUA "misuse" lately. > The common one is "I have a proxy that modifies > headers, therefore I call it a B2BUA, and everyone > is fine". There are no protocol police, and there > are no "architecture" police, but I think it is in > the community's interest to at least provide expert > guidance on how B2BUAs 'should' work. > This is an example. 'Should' is okay with me; > it would let your example be "legal". The SHOULD is fine for some types of b2bua's. However SHOULD NOT is more appropriate for other types of b2bua's. Thus I'd prefer the text not be in the document. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 5 15:24:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14510 for ; Fri, 5 Sep 2003 15:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vMBs-00037v-C5 for sip-archive@odin.ietf.org; Fri, 05 Sep 2003 15:24:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85JOGOh011959 for sip-archive@odin.ietf.org; Fri, 5 Sep 2003 15:24:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vMBd-00035E-UC; Fri, 05 Sep 2003 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vMAm-00030C-QX for sip@optimus.ietf.org; Fri, 05 Sep 2003 15:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14454 for ; Fri, 5 Sep 2003 15:23:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vMAk-00078D-00 for sip@ietf.org; Fri, 05 Sep 2003 15:23:06 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19vMAj-00075J-00 for sip@ietf.org; Fri, 05 Sep 2003 15:23:05 -0400 Received: from softarmor.com (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h85JMQ98020868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Sep 2003 14:22:26 -0500 Message-ID: <3F58E26D.3010201@softarmor.com> Date: Fri, 05 Sep 2003 14:22:21 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David R. Oran" CC: "sip-ietf (E-mail)" Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's References: <313680C9A886D511A06000204840E1CF070B5DF3@whq-msgusr-02.pit.comm s.marconi.com> <92903390.1062769705@[10.32.254.186]> In-Reply-To: <92903390.1062769705@[10.32.254.186]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave said: > "A B2BUA is, loosely speaking, two SIP user agents glued together in > completely unspecified ways. A SIP specification intended for standards > track MUST NOT use the term B2BUA in any normative language. SIP > specifications of any category SHOULD NOT use this term in descriptions > of algorithms or protocol usage. The term MAY be used to compare > alternatives, e.g. in requirements documents, or where the concept helps > in elucidating the problem being addressed." Well said. I think I'll add this to my .sig file. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 8 00:05:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04216 for ; Mon, 8 Sep 2003 00:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wDGa-0005RY-D3 for sip-archive@odin.ietf.org; Mon, 08 Sep 2003 00:04:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8844e5F020861 for sip-archive@odin.ietf.org; Mon, 8 Sep 2003 00:04:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wDGG-0005EH-8l; Mon, 08 Sep 2003 00:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w9hg-0007wX-1F for sip@optimus.ietf.org; Sun, 07 Sep 2003 20:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20890 for ; Sun, 7 Sep 2003 20:16:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w9hd-0005iv-00 for sip@ietf.org; Sun, 07 Sep 2003 20:16:21 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19w9hd-0005hL-00 for sip@ietf.org; Sun, 07 Sep 2003 20:16:21 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id E34FF3129; Mon, 8 Sep 2003 02:07:27 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-41-90.reverse.qsc.de [212.202.41.90]) by fox.iptel.org (Postfix) with ESMTP id 544D53125 for ; Mon, 8 Sep 2003 02:07:27 +0200 (CEST) Message-Id: <5.2.0.9.0.20030908015727.04caaeb0@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 08 Sep 2003 02:15:14 +0200 To: sip@ietf.org From: Jiri Kuthan Subject: Re: [Sip] Canceling REFER In-Reply-To: <1062707358.1444.53.camel@RjS.localdomain> References: <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> <4.3.2.7.2.20030904152028.0469ed38@bounty.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 10:29 PM 9/4/2003, Robert Sparks wrote: >There is no defined "Stop trying to access the resource I've REFERed >you to" mechanism. REFER is not designed to be a remote-control for >a peer endpoint. > >CANCELing the REFER won't make sense - the REFER is accepted or >rejected immediately and processing the reference happens after >that - the REFER transaction is already gone. > >Attempting to construct a REFER to a CANCEL that would match an >INVITE triggered by a previous REFER is difficult. You don't have >the appropriate Call-ID/tags handy and even if you could get them, >there's language in the REFER draft that encourages an agent accepting >a REFER to ignore them. > >So - if this functionality is something that we have a real need for, >its a new method (NEVERMIND perhaps?). > >RjS On the contrary to what I posted before, I agree CANCEL is not applicable here. I didn't realize that REFER creates dialog. What I'm not sure about is how to NEVERMIND forked out-of-band REFERs. In such a case, dialog is established to forking winner and NEVERMIND does not reach the other branches. -jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 8 16:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19531 for ; Mon, 8 Sep 2003 16:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSeL-0005Hh-NO for sip-archive@odin.ietf.org; Mon, 08 Sep 2003 16:30:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88KUDBq020253 for sip-archive@odin.ietf.org; Mon, 8 Sep 2003 16:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSeB-0005Fr-KP; Mon, 08 Sep 2003 16:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSe7-0005FT-6E for sip@optimus.ietf.org; Mon, 08 Sep 2003 16:29:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19467 for ; Mon, 8 Sep 2003 16:29:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wSe5-0007QD-00 for sip@ietf.org; Mon, 08 Sep 2003 16:29:57 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19wSe4-0007Pu-00 for sip@ietf.org; Mon, 08 Sep 2003 16:29:56 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h88KTFLb014338; Mon, 8 Sep 2003 16:29:15 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 15:29:15 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8641C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , Adam Roach , "'brett@broadsoft.com'" , Jonathan Rosenberg Cc: "sip-ietf (E-mail)" Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Mon, 8 Sep 2003 15:29:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: > I understand why you claim such a system is a B2BUA. > Of course, with that example, there are no rules whatsoever > on a B2BUA, except that each side is a UA. Cool. I got my point across on the first try. I must be getting better at this. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 00:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05736 for ; Tue, 9 Sep 2003 00:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wZvI-0002Fi-Jh for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 00:16:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h894GCMQ008654 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 00:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wZv8-0002F7-2H; Tue, 09 Sep 2003 00:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wZus-0002Ee-BH for sip@optimus.ietf.org; Tue, 09 Sep 2003 00:15:46 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05717 for ; Tue, 9 Sep 2003 00:15:37 -0400 (EDT) Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2003 21:28:02 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h894FD9F002076 for ; Mon, 8 Sep 2003 21:15:13 -0700 (PDT) Received: from [192.168.2.29] (rtp-vpn2-400.cisco.com [10.82.241.144]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHX21868; Mon, 8 Sep 2003 21:15:11 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 08 Sep 2003 16:42:15 -0700 Subject: Re: [Sip] Canceling REFER From: Cullen Jennings To: Message-ID: In-Reply-To: <5.2.0.9.0.20030905152710.04105008@localhost> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Before we continue the discussion on how to implement the time travel machine that P-RECALL-MISSLES will require, can anyone provide any reason we would need to cancel a REFER and perhaps we can just solve that problem instead. On 9/5/03 6:29, "Jiri Kuthan" wrote: > I think CANCEL would be better off. User's location can change before > P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination > than the original REFER. CANCEL guarantees that you use the same > transport destination as the original request. > > -Jiri > > At 03:21 PM 9/5/2003, Tolga Asveren wrote: >> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. >> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure >> described in RFC3265 is valid. >> >> Tolga >> --- "Mark Eastman (meastman)" wrote: >>> Hello, >>> >>> I have a question about how to deal with canceling a >>> REFER. Let's say I >>> REFER Bob to Betty, but then decide I want to REFER >>> Bob to someone else >>> before the transfer is complete. Are there existing >>> call flows describing >>> such behavior? I know the REFER rfc states handling >>> multiple refers is >>> valid, but is that how one would handle this >>> situation (Sending a new REFER >>> with either a new target or perhaps method=CANCEL). >>> If so, call flows >>> describing such behavior would be nice. >>> >>> Thanks, >>> Mark >>> >>> >>> _______________________________________________ >>> Sip mailing list >>> https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP >>> Protocol >>> Use sip-implementors@cs.columbia.edu for questions >>> on current sip >>> Use sipping@ietf.org for new developments on the >>> application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jiri Kuthan http://iptel.org/~jiri/ > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 02:49:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22579 for ; Tue, 9 Sep 2003 02:49:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wcJT-0007xw-VZ for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 02:49:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h896nJf1030617 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 02:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wcJD-0007x5-33; Tue, 09 Sep 2003 02:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wcIV-0007w6-9D for sip@optimus.ietf.org; Tue, 09 Sep 2003 02:48:19 -0400 Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22540 for ; Tue, 9 Sep 2003 02:48:06 -0400 (EDT) Received: from sip (pD9587B62.dip.t-dialin.net [217.88.123.98]) by post.webmailer.de (8.12.9/8.8.7) with ESMTP id h895l9kO020409; Tue, 9 Sep 2003 07:47:10 +0200 (MEST) From: "Christian Stredicke" To: Cc: "'Cullen Jennings'" Subject: AW: [Sip] Canceling REFER Date: Tue, 9 Sep 2003 07:47:37 +0200 Message-ID: <022201c37695$e0dd9ad0$020ba8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think Cullen is right. If you do care about the caller, you do an attended transfer. The "blind" transfer with the option to recall missiles can be implemented using an attended transfer: 1) Put "A" on hold by referring him to the entertainment server 2) call "B" 3) upon reception of 18x from B refer A to the ringback server 4) upon reception of 2xx from B refer A to B using Replaces 5) upon reception of 3456xx from B pick up the call again 6) upon wish to cancel, cancel the call to B and get A back My only concern would be speed, especially the experience of B when picking up that call. CS > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von Cullen > Jennings > Gesendet: Dienstag, 9. September 2003 01:42 > An: sip@ietf.org > Betreff: Re: [Sip] Canceling REFER >=20 >=20 > Before we continue the discussion on how to implement the time travel > machine that P-RECALL-MISSLES will require, can anyone provide any reason > we > would need to cancel a REFER and perhaps we can just solve that problem > instead. >=20 >=20 > On 9/5/03 6:29, "Jiri Kuthan" wrote: >=20 > > I think CANCEL would be better off. User's location can change before > > P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different > destination > > than the original REFER. CANCEL guarantees that you use the same > > transport destination as the original request. > > > > -Jiri > > > > At 03:21 PM 9/5/2003, Tolga Asveren wrote: > >> What about sending SUBSCRIBE with Expires=3D0 , as described in RFC3265. > >> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the > procedure > >> described in RFC3265 is valid. > >> > >> Tolga > >> --- "Mark Eastman (meastman)" wrote: > >>> Hello, > >>> > >>> I have a question about how to deal with canceling a > >>> REFER. Let's say I > >>> REFER Bob to Betty, but then decide I want to REFER > >>> Bob to someone else > >>> before the transfer is complete. Are there existing > >>> call flows describing > >>> such behavior? I know the REFER rfc states handling > >>> multiple refers is > >>> valid, but is that how one would handle this > >>> situation (Sending a new REFER > >>> with either a new target or perhaps method=3DCANCEL). > >>> If so, call flows > >>> describing such behavior would be nice. > >>> > >>> Thanks, > >>> Mark > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list > >>> https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP > >>> Protocol > >>> Use sip-implementors@cs.columbia.edu for questions > >>> on current sip > >>> Use sipping@ietf.org for new developments on the > >>> application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Jiri Kuthan http://iptel.org/~jiri/ > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 03:53:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24679 for ; Tue, 9 Sep 2003 03:53:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdJM-00025D-FK for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 03:53:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h897rGwI007947 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 03:53:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdJ8-00022s-1R; Tue, 09 Sep 2003 03:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdID-0001x5-Ir for sip@optimus.ietf.org; Tue, 09 Sep 2003 03:52:10 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24617 for ; Tue, 9 Sep 2003 03:51:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h897pxB27617 for ; Tue, 9 Sep 2003 10:52:01 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 10:51:59 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 10:51:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Tue, 9 Sep 2003 10:51:58 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B6@esebe019.ntc.nokia.com> Thread-Topic: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Thread-Index: AcNz1jaGp83mO6JsR+CmKD1zMS/YcAC0PVQQ To: , , , , Cc: X-OriginalArrivalTime: 09 Sep 2003 07:51:59.0383 (UTC) FILETIME=[3F856A70:01C376A7] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable What ever happened to Application Servers?? /Hisham > -----Original Message----- > From: ext David R. Oran [mailto:oran@cisco.com] > Sent: Friday, September 05, 2003 8:48 PM > To: Rosen, Brian; 'Adam Roach'; 'brett@broadsoft.com'; Jonathan > Rosenberg > Cc: sip-ietf (E-mail) > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy > restr ictions on all the b2bua's >=20 >=20 > Ah, dej=E1 vu all over again... >=20 > I'll repeat the argument I made many moons ago that we should=20 > delete all=20 > references to anything called a "B2BUA", except to perhaps have an=20 > expansion of the acronym in our WG lexicon, and a statement=20 > somewhere,=20 > perhaps SIPCHANGE which says, in effect: >=20 > "A B2BUA is, loosely speaking, two SIP user agents glued together in=20 > completely unspecified ways. A SIP specification intended for=20 > standards=20 > track MUST NOT use the term B2BUA in any normative language. SIP=20 > specifications of any category SHOULD NOT use this term in=20 > descriptions of=20 > algorithms or protocol usage. The term MAY be used to compare=20 > alternatives,=20 > e.g. in requirements documents, or where the concept helps in=20 > elucidating=20 > the problem being addressed." >=20 >=20 > Dave. >=20 > --On Friday, September 05, 2003 10:56 AM -0400 "Rosen, Brian"=20 > wrote: >=20 > > I understand why you claim such a system is a B2BUA. > > Of course, with that example, there are no rules whatsoever > > on a B2BUA, except that each side is a UA. > > > > Does that imply that there should not be any mention > > of B2BUAs at all in any document other than 3261, which > > is quite deliberately vague? > > > > I would AT LEAST want to point out issues, such as > > the "one side fails, the other side should be brought down". > > By your reckoning, would that be out of scope for a standards > > track document, and merely notes in some BCP? > > > > I've been seeing lots of B2BUA "misuse" lately. The common > > one is "I have a proxy that modifies headers, therefore > > I call it a B2BUA, and everyone is fine". There are > > no protocol police, and there are no "architecture" police, > > but I think it is in the community's interest to at least > > provide expert guidance on how B2BUAs 'should' work. > > This is an example. 'Should' is okay with me; it would let > > your example be "legal". > > > > Brian > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@dynamicsoft.com] > >> Sent: Friday, September 05, 2003 10:43 AM > >> To: 'Rosen, Brian'; 'brett@broadsoft.com'; Jonathan Rosenberg > >> Cc: sip-ietf (E-mail) > >> Subject: RE: [Sip] sip-session-timer-11: why explicitly=20 > impose proxy > >> restr ictions on all the b2bua's > >> > >> > >> I think the major point is that, with B2BUAs, all bets are off. > >> As long as they look like SIP UAs on both sides, they meet > >> spec. There's nothing we can do about this. Cullen points > >> out exactly what I was going to. I'll expand on this some. > >> > >> I have a SIP phone on my desk. So does Alan. However, > >> because I'm lazy, I often pick up my SIP phone and call > >> his normal PSTN number. That goes to my PSTN gateway, > >> through the PSTN to Alan's gateway, and rings Alan's > >> SIP phone. > >> > >> From a protocol perspective, my PSTN gateway, the PSTN, > >> and Alan's PSTN gateway, as an aggregate, form a B2BUA. > >> > >> Is there any reasonable way you can impose a restriction > >> on such a system as a whole? No. As long as each SIP User > >> Agent acts as a proper User Agent, everything else is > >> completely dependant on the purpose of the system. > >> > >> /a > >> > >> > >> > -----Original Message----- > >> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >> > Sent: Friday, September 05, 2003 9:06 > >> > To: 'brett@broadsoft.com'; jdrosen@dynamicsoft.com > >> > Cc: sip-ietf (E-mail) > >> > Subject: RE: [Sip] sip-session-timer-11: why explicitly=20 > impose proxy > >> > restr ictions on all the b2bua's > >> > > >> > > >> > I thought it was because the two sessions the B2BUA bridges ought > >> > to be considered one session wrt the session timer. If one side > >> > dies, the other one needs to be cleaned up. > >> > > >> > That being said, if one side can support session timer, and the > >> > other can't, the B2BUA could, if it was smart enough, maintain > >> > the session timer on the one side, and clean up the other side > >> > on failure. It couldn't detect failure of the non-session-timer > >> > side of course. > >> > > >> > I was about to release -12, with only minor updates. I guess > >> > I'll let this thread play out before I release it. I could > >> > soften the text pretty easily. > >> > > >> > I personally liked the fact that B2BUA behavior was discussed. > >> > > >> > Brian > >> > > >> > > -----Original Message----- > >> > > From: Brett Tate [mailto:brett@broadsoft.com] > >> > > Sent: Thursday, September 04, 2003 3:49 PM > >> > > To: jdrosen@dynamicsoft.com > >> > > Cc: sip-ietf (E-mail) > >> > > Subject: [Sip] sip-session-timer-11: why explicitly=20 > impose proxy > >> > > restrictions on all the b2bua's > >> > > > >> > > > >> > > Why does draft-ietf-sip-session-timer-11 > >> > > explicitly impose proxy related restrictions > >> > > on all the B2BUA's? > >> > > > >> > > I agree that some of the proxy concepts are > >> > > good recommendations for some types of B2BUA's; > >> > > however they definitely do not apply to all > >> > > types of B2BUA's. > >> > > > >> > > And in general, I am surprised to see > >> > > any draft explicitly requiring a B2BUA to act > >> > > like a proxy. Some B2BUA's act completely like > >> > > a UA; others act mostly like a proxy; and others > >> > > act at various degrees between a proxy and UA. > >> > > > >> > > > >> > > _______________________________________________ > >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > > This list is for NEW development of the core SIP Protocol > >> > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > >> > > Use sipping@ietf.org for new developments on the > >> application of sip > >> > > > >> > > >> > _______________________________________________ > >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current sip > >> > Use sipping@ietf.org for new developments on the=20 > application of sip > >> > > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 04:05:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25067 for ; Tue, 9 Sep 2003 04:05:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdUu-0002sk-UQ for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 04:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8985C71011077 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 04:05:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdUm-0002s4-6E; Tue, 09 Sep 2003 04:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wdTu-0002rD-Ru for sip@optimus.ietf.org; Tue, 09 Sep 2003 04:04:10 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25015 for ; Tue, 9 Sep 2003 04:03:42 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8983iB13506 for ; Tue, 9 Sep 2003 11:03:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Sep 2003 11:03:44 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 11:03:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 9 Sep 2003 11:03:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Canceling REFER Date: Tue, 9 Sep 2003 11:03:43 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970B7@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Canceling REFER Thread-Index: AcNzLQdQVhMFD33gRUeSZh7wSZ8X1wDe5+Uw To: , , , X-OriginalArrivalTime: 09 Sep 2003 08:03:43.0978 (UTC) FILETIME=[E37E14A0:01C376A8] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This is not a half bad idea, if we can guarantee that the CANCEL can = have the same call-id, cseq, etc as the INVITE. But then, you might have created 2 implicit subscriptions. Is that bad? /Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Friday, September 05, 2003 12:38 AM > To: Mark Eastman (meastman);=20 > rsparks@dynamincsoft.com.cnri.reston.va.us; > sip@ietf.org > Subject: Re: [Sip] Canceling REFER >=20 >=20 > A REFER with a method=3DCANCEL sounds like an > interesting option. The call flow should not be > difficult to come up with > . > --- "Mark Eastman (meastman)" > wrote: > > Hello, > >=20 > > I have a question about how to deal with canceling a > > REFER. Let's say I=20 > > REFER Bob to Betty, but then decide I want to REFER > > Bob to someone else=20 > > before the transfer is complete. Are there existing > > call flows describing=20 > > such behavior? I know the REFER rfc states handling > > multiple refers is=20 > > valid, but is that how one would handle this > > situation (Sending a new REFER=20 > > with either a new target or perhaps method=3DCANCEL).=20 > > If so, call flows=20 > > describing such behavior would be nice. > >=20 > > Thanks, > > Mark > >=20 > >=20 > > _______________________________________________ > > Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip >=20 >=20 > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 08:12:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02799 for ; Tue, 9 Sep 2003 08:12:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19whLN-0002Yk-G4 for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 08:11:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89CBbcn009778 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 08:11:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19whKo-0002X6-JU; Tue, 09 Sep 2003 08:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19whJw-0002WM-W6 for sip@optimus.ietf.org; Tue, 09 Sep 2003 08:10:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02749 for ; Tue, 9 Sep 2003 08:09:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19whJo-0001im-00 for sip@ietf.org; Tue, 09 Sep 2003 08:10:00 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19whJc-0001iO-00 for sip@ietf.org; Tue, 09 Sep 2003 08:09:49 -0400 Received: from dynamicsoft.com ([195.145.128.178]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h89C6w98021344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Sep 2003 07:07:00 -0500 Message-ID: <3F5DC251.3050309@dynamicsoft.com> Date: Tue, 09 Sep 2003 07:06:41 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: oran@cisco.com, Brian.Rosen@marconi.com, adam@dynamicsoft.com, brett@broadsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's References: <2038BCC78B1AD641891A0D1AE133DBB7017970B6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970B6@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > What ever happened to Application Servers?? > > /Hisham > Well, if dynamicsoft's SIP Application Server acts as a B2BUA, then it's actually two (or more) different UA threads connected by a Java program. What does the Java program do? Anything it wants to -- since it's Java, by definition it's a 500-pound gorilla, so the punch line applies ;-). Seriously - - If an INVITE is received by one of the UAs, is it retransmitted by the other(s)? Maybe, if the application is written to do that. If it wasn't, would this break other applications trying to use the B2BUA as a proxy? Yep, sure would. That's why it isn't a proxy -- it doesn't meet the rules of being a proxy, so guess what -- A B2BUA that doesn't obey all the rules of a proxy IS NOT A PROXY and by definition WILL BREAK some applications that would have worked through a proxy. That's why B2BUAs must be used VERY CAREFULLY, in LIMITED ENVIRONMENTS, by TRAINED PROFESSIONALS ONLY. Don't try this at home kids, your calls might not go through! Somebody ought to collect all the B2BUA discussions off of this list and make some kind of a book out of them . . . of course, nobody would ever read it, since they don't seem to read the discussions the first time around. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 09:09:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04969 for ; Tue, 9 Sep 2003 09:09:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiF8-0004hn-Im for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 09:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89D9EhY018027 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 09:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiEw-0004gL-3d; Tue, 09 Sep 2003 09:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiEX-0004fS-CE for sip@optimus.ietf.org; Tue, 09 Sep 2003 09:08:49 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04898 for ; Tue, 9 Sep 2003 09:08:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21495; Tue, 9 Sep 2003 09:06:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21747; Tue, 9 Sep 2003 09:06:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Sep 2003 09:06:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E0B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" , hisham.khartabil@nokia.com Cc: oran@cisco.com, adam@dynamicsoft.com, brett@broadsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's Date: Tue, 9 Sep 2003 09:06:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Unless someone speaks up real soon, I'm going to eliminate references to B2BUAs from the session timer doc and release a draft I hope will we do a WGLC on soon. Speak now, OFHYP. Brian > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Tuesday, September 09, 2003 8:07 AM > To: hisham.khartabil@nokia.com > Cc: oran@cisco.com; Brian.Rosen@marconi.com; adam@dynamicsoft.com; > brett@broadsoft.com; jdrosen@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] sip-session-timer-11: why explicitly impose proxy > restr ictions on all the b2bua's > > > hisham.khartabil@nokia.com wrote: > > > What ever happened to Application Servers?? > > > > /Hisham > > > > Well, if dynamicsoft's SIP Application Server acts as a > B2BUA, then it's > actually two (or more) different UA threads connected by a > Java program. > > What does the Java program do? Anything it wants to -- since > it's Java, > by definition it's a 500-pound gorilla, so the punch line applies ;-). > > Seriously - - > > If an INVITE is received by one of the UAs, is it > retransmitted by the > other(s)? Maybe, if the application is written to do that. If > it wasn't, > would this break other applications trying to use the B2BUA > as a proxy? > Yep, sure would. That's why it isn't a proxy -- it doesn't meet the > rules of being a proxy, so guess what -- A B2BUA that doesn't > obey all > the rules of a proxy IS NOT A PROXY and by definition WILL BREAK some > applications that would have worked through a proxy. > > That's why B2BUAs must be used VERY CAREFULLY, in LIMITED > ENVIRONMENTS, > by TRAINED PROFESSIONALS ONLY. Don't try this at home kids, > your calls > might not go through! > > Somebody ought to collect all the B2BUA discussions off of > this list and > make some kind of a book out of them . . . of course, nobody > would ever > read it, since they don't seem to read the discussions the first time > around. > > > -- > Dean > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 09:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08227 for ; Tue, 9 Sep 2003 09:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiyV-0006gW-Fh for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 09:56:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Du7XB025690 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 09:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wiyO-0006fu-Pd; Tue, 09 Sep 2003 09:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wixk-0006eg-Cw for sip@optimus.ietf.org; Tue, 09 Sep 2003 09:55:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08162 for ; Tue, 9 Sep 2003 09:55:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wixi-00036o-00 for sip@ietf.org; Tue, 09 Sep 2003 09:55:18 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 19wixh-00035M-00 for sip@ietf.org; Tue, 09 Sep 2003 09:55:17 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h89DoGv8027540; Tue, 9 Sep 2003 08:50:16 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.129]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R58KX6G4; Tue, 9 Sep 2003 08:50:01 -0500 Message-ID: <3F5DDA96.5090401@ericsson.com> Date: Tue, 09 Sep 2003 16:50:14 +0300 X-Sybari-Trust: f824c123 0f2b92c8 6ad59f72 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip CC: pkyzivat@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Update to RFC 3312 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Paul and I have put together a draft that addresses some issues related to the use of preconditions when there is session mobility. http://www.ietf.org/internet-drafts/draft-camarillo-sip-rfc3312-update-00.txt Comments are welcome. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 9 10:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08629 for ; Tue, 9 Sep 2003 10:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wj3L-0007Ha-Nh for sip-archive@odin.ietf.org; Tue, 09 Sep 2003 10:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89E170H027977 for sip-archive@odin.ietf.org; Tue, 9 Sep 2003 10:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wj3F-0007C6-OF; Tue, 09 Sep 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wj37-0007BW-9D for sip@optimus.ietf.org; Tue, 09 Sep 2003 10:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08580 for ; Tue, 9 Sep 2003 10:00:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wj35-0003F1-00 for sip@ietf.org; Tue, 09 Sep 2003 10:00:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19wj34-0003EN-00 for sip@ietf.org; Tue, 09 Sep 2003 10:00:50 -0400 Received: from meastman-w2k01.cisco.com (dhcp-64-102-99-172.cisco.com [64.102.99.172]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h89E0HS5000018; Tue, 9 Sep 2003 07:00:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20030909095135.046f7008@bounty.cisco.com> X-Sender: meastman@bounty.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Sep 2003 10:00:16 -0400 To: Cullen Jennings From: "Mark Eastman (meastman)" Subject: Re: [Sip] Canceling REFER Cc: In-Reply-To: References: <5.2.0.9.0.20030905152710.04105008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, The scenario is this. A REFER has already been sent and the transferor has decided he/she wants to transfer the call somewhere else. At this point in time the transferee will have received the REFER and sent out the triggered INVITE. I don't see a way that this can be stopped. The question is, is there a way the transferor can cause that triggered INVITE to be canceled? Sounds like no with current methods. A REFER with method CANCEL is insuffecient because the transferee has insufficient information about the call leg being canceled (No callid and tags). What about another refer with a different target in the refer-to header (REFER within a REFER). Is it safe to imply that this means canceling the previous triggered INVITE? I would think not. Thanks, Mark At 04:42 PM 9/8/2003 -0700, Cullen Jennings wrote: >Before we continue the discussion on how to implement the time travel >machine that P-RECALL-MISSLES will require, can anyone provide any reason we >would need to cancel a REFER and perhaps we can just solve that problem >instead. > > >On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > I think CANCEL would be better off. User's location can change before > > P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination > > than the original REFER. CANCEL guarantees that you use the same > > transport destination as the original request. > > > > -Jiri > > > > At 03:21 PM 9/5/2003, Tolga Asveren wrote: > >> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > >> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the > procedure > >> described in RFC3265 is valid. > >> > >> Tolga > >> --- "Mark Eastman (meastman)" wrote: > >>> Hello, > >>> > >>> I have a question about how to deal with canceling a > >>> REFER. Let's say I > >>> REFER Bob to Betty, but then decide I want to REFER > >>> Bob to someone else > >>> before the transfer is complete. Are there existing > >>> call flows describing > >>> such behavior? I know the REFER rfc states handling > >>> multiple refers is > >>> valid, but is that how one would handle this > >>> situation (Sending a new REFER > >>> with either a new target or perhaps method=CANCEL). > >>> If so, call flows > >>> describing such behavior would be nice. > >>> > >>> Thanks, > >>> Mark > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list > >>> https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP > >>> Protocol > >>> Use sip-implementors@cs.columbia.edu for questions > >>> on current sip > >>> Use sipping@ietf.org for new developments on the > >>> application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Jiri Kuthan http://iptel.org/~jiri/ > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 10 19:30:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22918 for ; Wed, 10 Sep 2003 19:30:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEPf-0004OU-U0 for sip-archive@odin.ietf.org; Wed, 10 Sep 2003 19:30:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ANUFVJ016890 for sip-archive@odin.ietf.org; Wed, 10 Sep 2003 19:30:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEPT-0004Mm-1m; Wed, 10 Sep 2003 19:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEOu-0004Jc-4X for sip@optimus.ietf.org; Wed, 10 Sep 2003 19:29:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22870 for ; Wed, 10 Sep 2003 19:29:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xEOs-0001KN-00 for sip@ietf.org; Wed, 10 Sep 2003 19:29:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xEOq-0001HV-00 for sip@ietf.org; Wed, 10 Sep 2003 19:29:24 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8ANSrbs022636; Wed, 10 Sep 2003 16:28:53 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHZ33117; Wed, 10 Sep 2003 16:28:52 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 10 Sep 2003 16:28:55 -0700 Subject: Re: [Sip] Canceling REFER From: Cullen Jennings To: Cullen Jennings , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/8/03 16:42, "Cullen Jennings" wrote: I had some out of band discussion to track down the requirements on this. I think the question actually turned into the the question of what happen when you send a REFER to an early dialog. If the refer is accepted and a new dialog is formed, I believe the old dialog should be ended - in this case since it is an early dialog, it will be ended by sending a CANCEL. Do folks agree on this? Thanks, Cullen > > Before we continue the discussion on how to implement the time travel > machine that P-RECALL-MISSLES will require, can anyone provide any reason we > would need to cancel a REFER and perhaps we can just solve that problem > instead. > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > >> I think CANCEL would be better off. User's location can change before >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination >> than the original REFER. CANCEL guarantees that you use the same >> transport destination as the original request. >> >> -Jiri >> >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure >>> described in RFC3265 is valid. >>> >>> Tolga >>> --- "Mark Eastman (meastman)" wrote: >>>> Hello, >>>> >>>> I have a question about how to deal with canceling a >>>> REFER. Let's say I >>>> REFER Bob to Betty, but then decide I want to REFER >>>> Bob to someone else >>>> before the transfer is complete. Are there existing >>>> call flows describing >>>> such behavior? I know the REFER rfc states handling >>>> multiple refers is >>>> valid, but is that how one would handle this >>>> situation (Sending a new REFER >>>> with either a new target or perhaps method=CANCEL). >>>> If so, call flows >>>> describing such behavior would be nice. >>>> >>>> Thanks, >>>> Mark >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list >>>> https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP >>>> Protocol >>>> Use sip-implementors@cs.columbia.edu for questions >>>> on current sip >>>> Use sipping@ietf.org for new developments on the >>>> application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> -- >> Jiri Kuthan http://iptel.org/~jiri/ >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 10 19:54:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23449 for ; Wed, 10 Sep 2003 19:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEmo-0007Ei-Pf for sip-archive@odin.ietf.org; Wed, 10 Sep 2003 19:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ANsAMX027789 for sip-archive@odin.ietf.org; Wed, 10 Sep 2003 19:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEmg-0007Cm-SH; Wed, 10 Sep 2003 19:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xEm5-00078n-Jh for sip@optimus.ietf.org; Wed, 10 Sep 2003 19:53:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23404 for ; Wed, 10 Sep 2003 19:53:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xEm2-0003Pp-00 for sip@ietf.org; Wed, 10 Sep 2003 19:53:22 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19xEm1-0003Kf-00 for sip@ietf.org; Wed, 10 Sep 2003 19:53:21 -0400 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id TAA13352 for ; Wed, 10 Sep 2003 19:52:27 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sip] Canceling REFER Date: Wed, 10 Sep 2003 19:53:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Cullen > Jennings > Sent: Wednesday, September 10, 2003 7:29 PM > To: Cullen Jennings; sip@ietf.org > Subject: Re: [Sip] Canceling REFER > > > On 9/8/03 16:42, "Cullen Jennings" wrote: > > > I had some out of band discussion to track down the requirements > on this. I > think the question actually turned into the the question of what > happen when > you send a REFER to an early dialog. If the refer is accepted and a new > dialog is formed, I believe the old dialog should be ended - in this case > since it is an early dialog, it will be ended by sending a CANCEL. [TOLGA]And how to stimulate a CANCEL for an early dialogue, if we don't want to do a new refer and just want to give up -and want the related dialogue to terminate, if it is not confirmed-? > > Do folks agree on this? Thanks, Cullen > > > > > > Before we continue the discussion on how to implement the time travel > > machine that P-RECALL-MISSLES will require, can anyone provide > any reason we > > would need to cancel a REFER and perhaps we can just solve that problem > > instead. > > > > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > >> I think CANCEL would be better off. User's location can change before > >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different > destination > >> than the original REFER. CANCEL guarantees that you use the same > >> transport destination as the original request. > >> > >> -Jiri > >> > >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: > >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, > the procedure > >>> described in RFC3265 is valid. > >>> > >>> Tolga > >>> --- "Mark Eastman (meastman)" wrote: > >>>> Hello, > >>>> > >>>> I have a question about how to deal with canceling a > >>>> REFER. Let's say I > >>>> REFER Bob to Betty, but then decide I want to REFER > >>>> Bob to someone else > >>>> before the transfer is complete. Are there existing > >>>> call flows describing > >>>> such behavior? I know the REFER rfc states handling > >>>> multiple refers is > >>>> valid, but is that how one would handle this > >>>> situation (Sending a new REFER > >>>> with either a new target or perhaps method=CANCEL). > >>>> If so, call flows > >>>> describing such behavior would be nice. > >>>> > >>>> Thanks, > >>>> Mark > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list > >>>> https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP > >>>> Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions > >>>> on current sip > >>>> Use sipping@ietf.org for new developments on the > >>>> application of sip > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >> > >> -- > >> Jiri Kuthan http://iptel.org/~jiri/ > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 02:02:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02483 for ; Thu, 11 Sep 2003 02:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKWP-0004lo-JV for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 02:01:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B61bl6018276 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 02:01:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKVw-0004ho-0Y; Thu, 11 Sep 2003 02:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKVZ-0004f3-Bu for sip@optimus.ietf.org; Thu, 11 Sep 2003 02:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00978 for ; Thu, 11 Sep 2003 02:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xKVV-00040N-00 for sip@ietf.org; Thu, 11 Sep 2003 02:00:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xKVV-0003xv-00 for sip@ietf.org; Thu, 11 Sep 2003 02:00:41 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8B60AS4001048; Wed, 10 Sep 2003 23:00:10 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn1-408.cisco.com [10.21.97.152]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHZ60378; Wed, 10 Sep 2003 23:00:08 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 10 Sep 2003 23:00:10 -0700 Subject: Re: [Sip] Canceling REFER From: Cullen Jennings To: Tolga Asveren , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/10/03 16:53, "Tolga Asveren" wrote: >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Cullen >> Jennings >> Sent: Wednesday, September 10, 2003 7:29 PM >> To: Cullen Jennings; sip@ietf.org >> Subject: Re: [Sip] Canceling REFER >> >> >> On 9/8/03 16:42, "Cullen Jennings" wrote: >> >> >> I had some out of band discussion to track down the requirements >> on this. I >> think the question actually turned into the the question of what >> happen when >> you send a REFER to an early dialog. If the refer is accepted and a new >> dialog is formed, I believe the old dialog should be ended - in this case >> since it is an early dialog, it will be ended by sending a CANCEL. > [TOLGA]And how to stimulate a CANCEL for an early dialogue, if we don't want > to do a new refer and just want to give up -and want the related dialogue to > terminate, if it is not confirmed-? >> The problem I tracked down did not seem to require this. Do you have a situation that does require this? Can you describe the requirements of what you want to accomplish and perhaps we can figure it out. One possibility is to transfer the dialog back to the sender of the refer then send a BYE to end the dialog. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 05:25:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16262 for ; Thu, 11 Sep 2003 05:25:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xNha-0006UK-B5 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 05:25:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B9PLsi024878 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 05:25:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xNhH-0006Rn-86; Thu, 11 Sep 2003 05:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6lq-0000EY-OE for sip@optimus.ietf.org; Wed, 10 Sep 2003 11:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03562 for ; Wed, 10 Sep 2003 11:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6lp-0004hX-00 for sip@ietf.org; Wed, 10 Sep 2003 11:20:37 -0400 Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 19x6lo-0004hU-00 for sip@ietf.org; Wed, 10 Sep 2003 11:20:36 -0400 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19x6lf-0005KW-00 for ; Wed, 10 Sep 2003 17:20:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: sip@ietf.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19x6kh-0005FX-00 for ; Wed, 10 Sep 2003 17:19:27 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19x6kj-00058c-00 for ; Wed, 10 Sep 2003 17:19:29 +0200 From: "Matt Guertin" Date: Wed, 10 Sep 2003 11:20:26 -0400 Lines: 15 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I read through all the SIP specs that I know of, and believe to have implement our SIP Conference "focus" correctly. We have what is sometimes referred to as a SIP Conference Bridge Marshal Server (in vocal speak anyway). When I go to do a REGISTER request, the authentication fails, because the username/password does not match with the ConferenceURI. I can only register with ConferenceURIs which have usernames/password provisioned. This doesn't work for Ad Hoc conferences, and even for scheduled conferences for that matter. It is unacceptable in a practical application to send mail to an administrator every time a new conference is scheduled to generate a username/password for the conference. The administrator may not get around to adding the new username/password for hours or even days. Am I missing something? We are using the contact field the way it is spec'ed in the conference framework draft (ie., the isfocus flag is set). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 09:06:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20997 for ; Thu, 11 Sep 2003 09:06:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xR9E-0005as-9t for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 09:06:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BD686I021498 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 09:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xR98-0005aK-Tj; Thu, 11 Sep 2003 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xR92-0005Zw-JI for sip@optimus.ietf.org; Thu, 11 Sep 2003 09:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20975 for ; Thu, 11 Sep 2003 09:05:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xR91-000122-00 for sip@ietf.org; Thu, 11 Sep 2003 09:05:55 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xR90-00011n-00 for sip@ietf.org; Thu, 11 Sep 2003 09:05:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21351; Thu, 11 Sep 2003 09:05:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24779; Thu, 11 Sep 2003 09:05:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 09:05:19 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Matt Guertin'" , sip@ietf.org Subject: RE: [Sip] Cannot REGISTER Ad Hoc SIP Conference? Date: Thu, 11 Sep 2003 09:05:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , We make this work roughly (code is evolving) the following way: We provision (actually, it's learned) the name of the local conference factory uri. This is a fixed uri, and is local to the domain of the conference host. The conference host registers with this well known address. It is an actual "user" in the system. We start with a 1on1 call, between the first two parties When we add the third party, the UA initiating this action sends an INVITE to the conference factory uri. The conference host returns a Contact header with a unique conference uri. The conference uri is constructed using a pattern known to the outgoing proxy The UA initiating the conference REFERs all three parties to the conference using the conference uri Invites with a username matching the pattern are routed to the conference host Brian > -----Original Message----- > From: Matt Guertin [mailto:mguertin@sonexis.com] > Sent: Wednesday, September 10, 2003 11:20 AM > To: sip@ietf.org > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > I read through all the SIP specs that I know of, and believe to have > implement our SIP Conference "focus" correctly. We have what > is sometimes > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > anyway). When I go to do a REGISTER request, the > authentication fails, > because the username/password does not match with the > ConferenceURI. I can > only register with ConferenceURIs which have > usernames/password provisioned. > This doesn't work for Ad Hoc conferences, and even for > scheduled conferences > for that matter. It is unacceptable in a practical > application to send mail > to an administrator every time a new conference is scheduled > to generate a > username/password for the conference. The administrator may > not get around > to adding the new username/password for hours or even days. > Am I missing > something? We are using the contact field the way it is > spec'ed in the > conference framework draft (ie., the isfocus flag is set). > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 10:24:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24988 for ; Thu, 11 Sep 2003 10:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSMp-00008i-OI for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:24:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BEOF1e000537 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSMb-00007a-H4; Thu, 11 Sep 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSLq-00006j-DY for sip@optimus.ietf.org; Thu, 11 Sep 2003 10:23:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24943 for ; Thu, 11 Sep 2003 10:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSLo-0001jO-00 for sip@ietf.org; Thu, 11 Sep 2003 10:23:12 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xSLd-0001io-00 for sip@ietf.org; Thu, 11 Sep 2003 10:23:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8BELrd08408; Thu, 11 Sep 2003 09:21:53 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: Cullen Jennings Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1063290112.884.5.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 11 Sep 2003 09:21:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This would close the door on any applications that would try to send REFERs to more than one destination (inside a given dialog) at once. I don't think that would be good for us in the long run. RjS On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote: > On 9/8/03 16:42, "Cullen Jennings" wrote: > > > I had some out of band discussion to track down the requirements on this. I > think the question actually turned into the the question of what happen when > you send a REFER to an early dialog. If the refer is accepted and a new > dialog is formed, I believe the old dialog should be ended - in this case > since it is an early dialog, it will be ended by sending a CANCEL. > > Do folks agree on this? Thanks, Cullen > > > > > > Before we continue the discussion on how to implement the time travel > > machine that P-RECALL-MISSLES will require, can anyone provide any reason we > > would need to cancel a REFER and perhaps we can just solve that problem > > instead. > > > > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > >> I think CANCEL would be better off. User's location can change before > >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination > >> than the original REFER. CANCEL guarantees that you use the same > >> transport destination as the original request. > >> > >> -Jiri > >> > >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: > >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure > >>> described in RFC3265 is valid. > >>> > >>> Tolga > >>> --- "Mark Eastman (meastman)" wrote: > >>>> Hello, > >>>> > >>>> I have a question about how to deal with canceling a > >>>> REFER. Let's say I > >>>> REFER Bob to Betty, but then decide I want to REFER > >>>> Bob to someone else > >>>> before the transfer is complete. Are there existing > >>>> call flows describing > >>>> such behavior? I know the REFER rfc states handling > >>>> multiple refers is > >>>> valid, but is that how one would handle this > >>>> situation (Sending a new REFER > >>>> with either a new target or perhaps method=CANCEL). > >>>> If so, call flows > >>>> describing such behavior would be nice. > >>>> > >>>> Thanks, > >>>> Mark > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list > >>>> https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP > >>>> Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions > >>>> on current sip > >>>> Use sipping@ietf.org for new developments on the > >>>> application of sip > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >> > >> -- > >> Jiri Kuthan http://iptel.org/~jiri/ > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 10:29:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25145 for ; Thu, 11 Sep 2003 10:29:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSRX-0000Qk-GZ for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:29:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BET7Cn001648 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSRS-0000Q3-7D; Thu, 11 Sep 2003 10:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSQt-0000PU-DD for sip@optimus.ietf.org; Thu, 11 Sep 2003 10:28:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25115 for ; Thu, 11 Sep 2003 10:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSQr-0001mB-00 for sip@ietf.org; Thu, 11 Sep 2003 10:28:25 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19xSQg-0001lv-00 for sip@ietf.org; Thu, 11 Sep 2003 10:28:14 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8BEREAv029376; Thu, 11 Sep 2003 16:27:14 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 11 Sep 2003 16:29:06 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "Christer Holmberg (JO/LMF)" , "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 11 Sep 2003 16:26:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, So, is Bob's proposal something which could be accepted, or at least worked futher on? Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Christer Holmberg (JO/LMF) > Sent: 4. syyskuuta 2003 13:14 > To: 'Bob Penfield'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > Hi, > > I would support Bob's proposal, saying that a "+" indicates > global-phone-number, according to RFC2806(or bis). I don't > think there would be any backward compability issues, because > I doubt anyone is using "+" for any other purpose - at least > not as the first character of the user part. Of course, nodes > that really REQUIRE user=phone to be present, in order to > accept the request in the first, place would have to be changed. > > Of course, user=tel could also be used, but I really see no > use for that if the "+" rule applies. Also, user=tel COULD > cause backward compability issues. > > Then, since there doesn't seem to be an agreement on what > user=phone really means, related BOTH to the userpart syntax > and the message routing, we could remove it completely. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: 4. syyskuuta 2003 2:43 > > To: sip@ietf.org > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > > > Getting back to the problem Robert described in the > original mail, the > > interoperability problems are a result of that fact that what > > is a valid > > userinfo part of a SIP URL with a user=phone parameter has > > steadily gotten > > stricter without any consideration for backwards > > compatibility. The specific > > problem he described resulted because a SIP URL created with > > 2543 rules was > > rejected by a server applying 3261/2806 rules. The new > > 2806bis rules are > > even stricter. I have no problem with those rules for tel-URLs. > > > > In spite of the lack of normative text on user-phone, the > > statements in 2543 > > and 3261 to the effect that it is used to distinguish phone > > numbers from > > usernames leads one to the reasonable conclusion that when it > > is present, > > the 'telephone-subscriber' BNF applies. This is the > > conclusion that we and a > > number of our vendors and customers came to when we ran into interop > > problems. > > > > However, its not that simple since a 'telephone-subscriber' > > keeps changing. > > > > >From some of the posting on this subject, there seems to > be value in > > distinguishing a telephone number from username that happens > > to look like a > > telephone number without requiring that the user part be a > > tel-URL. What I > > would propose is that while we make the rules for user=phone > > clearer, they > > ought to be closer to the 2543 rules which in my experience a lot of > > existing implementation seem to follow. If the userinfo > > begins with "+" or > > contains a phone-context, then it is reasonable to interpret it as a > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > 2543) should > > apply. A server which is not responsible for the domain of > the SIP URL > > should not reject a SIP URL because phone-context is missing. > > Actually, I > > believe it is reasonable to take the SIP URL host part as the > > 'default' > > phone-context when it is missing. > > > > Also, we could add 'user=tel' for userinfo that MUST be > > tel-URLs. In that > > case, rejecting a local number without a phone-context would > > be perfectly > > reasonable. > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 10:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25360 for ; Thu, 11 Sep 2003 10:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSWL-0000lA-CM for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BEY5dh002894 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSWH-0000kG-PF; Thu, 11 Sep 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSVk-0000jq-LW for sip@optimus.ietf.org; Thu, 11 Sep 2003 10:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25317 for ; Thu, 11 Sep 2003 10:33:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSVi-0001pX-00 for sip@ietf.org; Thu, 11 Sep 2003 10:33:26 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xSVX-0001pI-00 for sip@ietf.org; Thu, 11 Sep 2003 10:33:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8BEVUd08601; Thu, 11 Sep 2003 09:31:30 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: Cullen Jennings Cc: sip@ietf.org In-Reply-To: <1063290112.884.5.camel@RjS.localdomain> References: <1063290112.884.5.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1063290690.883.8.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 11 Sep 2003 09:31:30 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I just had a small AHA moment. For the application you are looking at, what if the second REFER referred-to something like an INVITE-replaces, but instead of trying to replace state at the thing receiving the invite, it replaces state at the thing sending the invite? RjS On Thu, 2003-09-11 at 09:21, Robert Sparks wrote: > This would close the door on any applications that would try to > send REFERs to more than one destination (inside a given dialog) > at once. I don't think that would be good for us in the long run. > > RjS > > On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote: > > On 9/8/03 16:42, "Cullen Jennings" wrote: > > > > > > I had some out of band discussion to track down the requirements on this. I > > think the question actually turned into the the question of what happen when > > you send a REFER to an early dialog. If the refer is accepted and a new > > dialog is formed, I believe the old dialog should be ended - in this case > > since it is an early dialog, it will be ended by sending a CANCEL. > > > > Do folks agree on this? Thanks, Cullen > > > > > > > > > > Before we continue the discussion on how to implement the time travel > > > machine that P-RECALL-MISSLES will require, can anyone provide any reason we > > > would need to cancel a REFER and perhaps we can just solve that problem > > > instead. > > > > > > > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > > > >> I think CANCEL would be better off. User's location can change before > > >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination > > >> than the original REFER. CANCEL guarantees that you use the same > > >> transport destination as the original request. > > >> > > >> -Jiri > > >> > > >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: > > >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > > >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure > > >>> described in RFC3265 is valid. > > >>> > > >>> Tolga > > >>> --- "Mark Eastman (meastman)" wrote: > > >>>> Hello, > > >>>> > > >>>> I have a question about how to deal with canceling a > > >>>> REFER. Let's say I > > >>>> REFER Bob to Betty, but then decide I want to REFER > > >>>> Bob to someone else > > >>>> before the transfer is complete. Are there existing > > >>>> call flows describing > > >>>> such behavior? I know the REFER rfc states handling > > >>>> multiple refers is > > >>>> valid, but is that how one would handle this > > >>>> situation (Sending a new REFER > > >>>> with either a new target or perhaps method=CANCEL). > > >>>> If so, call flows > > >>>> describing such behavior would be nice. > > >>>> > > >>>> Thanks, > > >>>> Mark > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Sip mailing list > > >>>> https://www1.ietf.org/mailman/listinfo/sip > > >>>> This list is for NEW development of the core SIP > > >>>> Protocol > > >>>> Use sip-implementors@cs.columbia.edu for questions > > >>>> on current sip > > >>>> Use sipping@ietf.org for new developments on the > > >>>> application of sip > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol > > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > > >>> Use sipping@ietf.org for new developments on the application of sip > > >> > > >> -- > > >> Jiri Kuthan http://iptel.org/~jiri/ > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > >> > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 10:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25473 for ; Thu, 11 Sep 2003 10:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSZG-00011E-68 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BEb5TM003888 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSZC-0000ze-DG; Thu, 11 Sep 2003 10:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSYI-0000yw-OW for sip@optimus.ietf.org; Thu, 11 Sep 2003 10:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25447 for ; Thu, 11 Sep 2003 10:35:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSYG-0001s0-00 for sip@ietf.org; Thu, 11 Sep 2003 10:36:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19xSY5-0001rT-00 for sip@ietf.org; Thu, 11 Sep 2003 10:35:54 -0400 Received: from meastman-w2k01.cisco.com (dhcp-64-102-99-172.cisco.com [64.102.99.172]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8BEYthi015602; Thu, 11 Sep 2003 10:34:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20030911103310.04604ff8@bounty.cisco.com> X-Sender: meastman@bounty.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Sep 2003 10:34:55 -0400 To: Robert Sparks From: "Mark Eastman (meastman)" Subject: Re: [Sip] Canceling REFER Cc: Cullen Jennings , sip@ietf.org In-Reply-To: <1063290112.884.5.camel@RjS.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , So basically, you feel receiving a REFER within another REFER dialog, should not cause the triggered INVITE from the first REFER to be canceled? Thanks, Mark At 09:21 AM 9/11/2003 -0500, Robert Sparks wrote: >This would close the door on any applications that would try to >send REFERs to more than one destination (inside a given dialog) >at once. I don't think that would be good for us in the long run. > >RjS > >On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote: > > On 9/8/03 16:42, "Cullen Jennings" wrote: > > > > > > I had some out of band discussion to track down the requirements on this. I > > think the question actually turned into the the question of what happen > when > > you send a REFER to an early dialog. If the refer is accepted and a new > > dialog is formed, I believe the old dialog should be ended - in this case > > since it is an early dialog, it will be ended by sending a CANCEL. > > > > Do folks agree on this? Thanks, Cullen > > > > > > > > > > Before we continue the discussion on how to implement the time travel > > > machine that P-RECALL-MISSLES will require, can anyone provide any > reason we > > > would need to cancel a REFER and perhaps we can just solve that problem > > > instead. > > > > > > > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > > > >> I think CANCEL would be better off. User's location can change before > > >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different > destination > > >> than the original REFER. CANCEL guarantees that you use the same > > >> transport destination as the original request. > > >> > > >> -Jiri > > >> > > >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: > > >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > > >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the > procedure > > >>> described in RFC3265 is valid. > > >>> > > >>> Tolga > > >>> --- "Mark Eastman (meastman)" wrote: > > >>>> Hello, > > >>>> > > >>>> I have a question about how to deal with canceling a > > >>>> REFER. Let's say I > > >>>> REFER Bob to Betty, but then decide I want to REFER > > >>>> Bob to someone else > > >>>> before the transfer is complete. Are there existing > > >>>> call flows describing > > >>>> such behavior? I know the REFER rfc states handling > > >>>> multiple refers is > > >>>> valid, but is that how one would handle this > > >>>> situation (Sending a new REFER > > >>>> with either a new target or perhaps method=CANCEL). > > >>>> If so, call flows > > >>>> describing such behavior would be nice. > > >>>> > > >>>> Thanks, > > >>>> Mark > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Sip mailing list > > >>>> https://www1.ietf.org/mailman/listinfo/sip > > >>>> This list is for NEW development of the core SIP > > >>>> Protocol > > >>>> Use sip-implementors@cs.columbia.edu for questions > > >>>> on current sip > > >>>> Use sipping@ietf.org for new developments on the > > >>>> application of sip > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol > > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > > >>> Use sipping@ietf.org for new developments on the application of sip > > >> > > >> -- > > >> Jiri Kuthan http://iptel.org/~jiri/ > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > >> > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 10:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25886 for ; Thu, 11 Sep 2003 10:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xShy-0001ci-HE for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BEk6ZU006221 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 10:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xShu-0001bs-3X; Thu, 11 Sep 2003 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSh7-0001al-JF for sip@optimus.ietf.org; Thu, 11 Sep 2003 10:45:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25829 for ; Thu, 11 Sep 2003 10:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSh5-0001vn-00 for sip@ietf.org; Thu, 11 Sep 2003 10:45:11 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19xSgu-0001vN-00 for sip@ietf.org; Thu, 11 Sep 2003 10:45:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8BEiAd08779; Thu, 11 Sep 2003 09:44:10 -0500 Subject: Re: [Sip] Canceling REFER From: Robert Sparks To: "Mark Eastman (meastman)" Cc: Cullen Jennings , sip@ietf.org In-Reply-To: <4.3.2.7.2.20030911103310.04604ff8@bounty.cisco.com> References: <4.3.2.7.2.20030911103310.04604ff8@bounty.cisco.com> Content-Type: text/plain Message-Id: <1063291449.884.11.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 11 Sep 2003 09:44:09 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Correct. As an example, imagine that I am in an INVITE created dialog with my conference server and I want to send it REFERs to bring both you and Cullen into this same conference. I don't want to have my INVITE to Cullen CANCEL my INVITE to you. RjS On Thu, 2003-09-11 at 09:34, Mark Eastman (meastman) wrote: > So basically, you feel receiving a REFER within another REFER dialog, > should not cause the triggered INVITE from the first REFER to be canceled? > > Thanks, > Mark > > > At 09:21 AM 9/11/2003 -0500, Robert Sparks wrote: > >This would close the door on any applications that would try to > >send REFERs to more than one destination (inside a given dialog) > >at once. I don't think that would be good for us in the long run. > > > >RjS > > > >On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote: > > > On 9/8/03 16:42, "Cullen Jennings" wrote: > > > > > > > > > I had some out of band discussion to track down the requirements on this. I > > > think the question actually turned into the the question of what happen > > when > > > you send a REFER to an early dialog. If the refer is accepted and a new > > > dialog is formed, I believe the old dialog should be ended - in this case > > > since it is an early dialog, it will be ended by sending a CANCEL. > > > > > > Do folks agree on this? Thanks, Cullen > > > > > > > > > > > > > > Before we continue the discussion on how to implement the time travel > > > > machine that P-RECALL-MISSLES will require, can anyone provide any > > reason we > > > > would need to cancel a REFER and perhaps we can just solve that problem > > > > instead. > > > > > > > > > > > > On 9/5/03 6:29, "Jiri Kuthan" wrote: > > > > > > > >> I think CANCEL would be better off. User's location can change before > > > >> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different > > destination > > > >> than the original REFER. CANCEL guarantees that you use the same > > > >> transport destination as the original request. > > > >> > > > >> -Jiri > > > >> > > > >> At 03:21 PM 9/5/2003, Tolga Asveren wrote: > > > >>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. > > > >>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the > > procedure > > > >>> described in RFC3265 is valid. > > > >>> > > > >>> Tolga > > > >>> --- "Mark Eastman (meastman)" wrote: > > > >>>> Hello, > > > >>>> > > > >>>> I have a question about how to deal with canceling a > > > >>>> REFER. Let's say I > > > >>>> REFER Bob to Betty, but then decide I want to REFER > > > >>>> Bob to someone else > > > >>>> before the transfer is complete. Are there existing > > > >>>> call flows describing > > > >>>> such behavior? I know the REFER rfc states handling > > > >>>> multiple refers is > > > >>>> valid, but is that how one would handle this > > > >>>> situation (Sending a new REFER > > > >>>> with either a new target or perhaps method=CANCEL). > > > >>>> If so, call flows > > > >>>> describing such behavior would be nice. > > > >>>> > > > >>>> Thanks, > > > >>>> Mark > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Sip mailing list > > > >>>> https://www1.ietf.org/mailman/listinfo/sip > > > >>>> This list is for NEW development of the core SIP > > > >>>> Protocol > > > >>>> Use sip-implementors@cs.columbia.edu for questions > > > >>>> on current sip > > > >>>> Use sipping@ietf.org for new developments on the > > > >>>> application of sip > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >>> This list is for NEW development of the core SIP Protocol > > > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > > > >>> Use sipping@ietf.org for new developments on the application of sip > > > >> > > > >> -- > > > >> Jiri Kuthan http://iptel.org/~jiri/ > > > >> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol > > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > > >> Use sipping@ietf.org for new developments on the application of sip > > > >> > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 11:01:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26482 for ; Thu, 11 Sep 2003 11:01:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSwa-0002PT-38 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 11:01:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BF1Ckm009261 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 11:01:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSwR-0002L6-Eu; Thu, 11 Sep 2003 11:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xSva-0002JF-Rv for sip@optimus.ietf.org; Thu, 11 Sep 2003 11:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26402 for ; Thu, 11 Sep 2003 10:59:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xSvT-00023c-00 for sip@ietf.org; Thu, 11 Sep 2003 11:00:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xSvI-00022u-00 for sip@ietf.org; Thu, 11 Sep 2003 10:59:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26171; Thu, 11 Sep 2003 10:58:34 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11937; Thu, 11 Sep 2003 10:58:34 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 10:58:34 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E45@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christer Holmberg (JO/LMF)'" , "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 11 Sep 2003 10:58:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , It doesn't address dial strings, which is a big problem. For example > >Otherwise, the 'local-phone-number' (from Table 4 of > >2543) should apply. is problematic I think. I don't have a problem with the "+" or phone context and user=phone implying it's equivalent to a tel uri. Brian > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, September 11, 2003 10:27 AM > To: Christer Holmberg (JO/LMF); 'Bob Penfield'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > Hi, > > So, is Bob's proposal something which could be accepted, or > at least worked futher on? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > Sent: 4. syyskuuta 2003 13:14 > > To: 'Bob Penfield'; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > Hi, > > > > I would support Bob's proposal, saying that a "+" indicates > > global-phone-number, according to RFC2806(or bis). I don't > > think there would be any backward compability issues, because > > I doubt anyone is using "+" for any other purpose - at least > > not as the first character of the user part. Of course, nodes > > that really REQUIRE user=phone to be present, in order to > > accept the request in the first, place would have to be changed. > > > > Of course, user=tel could also be used, but I really see no > > use for that if the "+" rule applies. Also, user=tel COULD > > cause backward compability issues. > > > > Then, since there doesn't seem to be an agreement on what > > user=phone really means, related BOTH to the userpart syntax > > and the message routing, we could remove it completely. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > -----Original Message----- > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > Sent: 4. syyskuuta 2003 2:43 > > > To: sip@ietf.org > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > Getting back to the problem Robert described in the > > original mail, the > > > interoperability problems are a result of that fact that what > > > is a valid > > > userinfo part of a SIP URL with a user=phone parameter has > > > steadily gotten > > > stricter without any consideration for backwards > > > compatibility. The specific > > > problem he described resulted because a SIP URL created with > > > 2543 rules was > > > rejected by a server applying 3261/2806 rules. The new > > > 2806bis rules are > > > even stricter. I have no problem with those rules for tel-URLs. > > > > > > In spite of the lack of normative text on user-phone, the > > > statements in 2543 > > > and 3261 to the effect that it is used to distinguish phone > > > numbers from > > > usernames leads one to the reasonable conclusion that when it > > > is present, > > > the 'telephone-subscriber' BNF applies. This is the > > > conclusion that we and a > > > number of our vendors and customers came to when we ran > into interop > > > problems. > > > > > > However, its not that simple since a 'telephone-subscriber' > > > keeps changing. > > > > > > >From some of the posting on this subject, there seems to > > be value in > > > distinguishing a telephone number from username that happens > > > to look like a > > > telephone number without requiring that the user part be a > > > tel-URL. What I > > > would propose is that while we make the rules for user=phone > > > clearer, they > > > ought to be closer to the 2543 rules which in my > experience a lot of > > > existing implementation seem to follow. If the userinfo > > > begins with "+" or > > > contains a phone-context, then it is reasonable to > interpret it as a > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > > 2543) should > > > apply. A server which is not responsible for the domain of > > the SIP URL > > > should not reject a SIP URL because phone-context is missing. > > > Actually, I > > > believe it is reasonable to take the SIP URL host part as the > > > 'default' > > > phone-context when it is missing. > > > > > > Also, we could add 'user=tel' for userinfo that MUST be > > > tel-URLs. In that > > > case, rejecting a local number without a phone-context would > > > be perfectly > > > reasonable. > > > > > > cheers, > > > (-:bob > > > > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > bpenfield@acmepacket.com > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 14:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04602 for ; Thu, 11 Sep 2003 14:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWQR-0001gq-RG for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:44:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BIiFuJ006490 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:44:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWQD-0001fz-Cp; Thu, 11 Sep 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWPg-0001fc-Mo for sip@optimus.ietf.org; Thu, 11 Sep 2003 14:43:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04557 for ; Thu, 11 Sep 2003 14:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWPd-0004By-00 for sip@ietf.org; Thu, 11 Sep 2003 14:43:25 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19xWPd-0004Bv-00 for sip@ietf.org; Thu, 11 Sep 2003 14:43:25 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h8BIhPIl006402 for ; Thu, 11 Sep 2003 11:43:25 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h8BIhNCi024544 for ; Thu, 11 Sep 2003 13:43:23 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 11 Sep 2003 13:43:23 -0500 Message-ID: <8F37768D4D9CD71192CF00065BF2598B931F0A@il27exm02.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: sip@ietf.org Date: Thu, 11 Sep 2003 13:43:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37894.93E69B04" Subject: [Sip] Question on CALL HOLD... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37894.93E69B04 Content-Type: text/plain Hi, I was going through call flow for CALL HOLD in the services draft http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-05.txt . and I had a simple question. Assume a scenario where a UA is on HOLD, so it has received the INVITE (hold) and has stopped sending the audio (media) to the peer. Now assume that the party on HOLD receives a new INVITE from another peer which it wants to take. A normal way of doing this would be to put the existing call on hold and accept the new call. But in this case the existing call is already on HOLD, so what should the UA do. - Should it still send the INVITE (hold), but this will reverse the direction of the audio (a=sendonly instead of a=recvonly). - Or Should it accept the new call w/o doing anything with the existing call since it is already on HOLD. In this case when the peer takes the existing call OFF HOLD, then that would interfere with the audio on the new call. - Should it go with the second option, but in addition when the peer takes the call OFF HOLD, it should respond back with a 200 OK that contains (a=sendonly) in the SDP body, thus putting the peer on HOLD. Appreciate your help on this. - Ajay ------_=_NextPart_001_01C37894.93E69B04 Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxucz0iaHR0 cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ Vj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0K DQoNCjxtZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9 R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIj4NCjxtZXRhIG5hbWU9T3JpZ2lu YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhy ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDMzc4NkEuQTg2MkNFNjAiPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25D U1MvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0 YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpH cmFtbWFyU3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50 S2luZD4NCiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdH cmlkRXZlcnk+MDwvdzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OkRp c3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MDwvdzpEaXNwbGF5VmVydGljYWxEcmF3aW5n R3JpZEV2ZXJ5Pg0KICA8dzpVc2VNYXJnaW5zRm9yRHJhd2luZ0dyaWRPcmlnaW4vPg0KICA8dzpD b21wYXRpYmlsaXR5Pg0KICAgPHc6Rm9vdG5vdGVMYXlvdXRMaWtlV1c4Lz4NCiAgIDx3OlNoYXBl TGF5b3V0TGlrZVdXOC8+DQogICA8dzpBbGlnblRhYmxlc1Jvd0J5Um93Lz4NCiAgIDx3OkZvcmdl dExhc3RUYWJBbGlnbm1lbnQvPg0KICAgPHc6RG9Ob3RVc2VIVE1MUGFyYWdyYXBoQXV0b1NwYWNp bmcvPg0KICAgPHc6TGF5b3V0UmF3VGFibGVXaWR0aC8+DQogICA8dzpMYXlvdXRUYWJsZVJvd3NB cGFydC8+DQogICA8dzpVc2VXb3JkOTdMaW5lQnJlYWtpbmdSdWxlcy8+DQogIDwvdzpDb21wYXRp YmlsaXR5Pg0KICA8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6 QnJvd3NlckxldmVsPg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxz dHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28t Zm9udC1jaGFyc2V0OjI7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9u dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MCAyNjg0MzU0NTYgMCAwIC0y MTQ3NDgzNjQ4IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9y cGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OkFyaWFsOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3Bs LWU6eWVzO30NCnNwYW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5 ZXM7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMjVpbiAxLjBpbiAxLjI1aW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9v dGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlvbjENCgl7 cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE1MDg3ODUxNDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjI4MTU1NzE0MCAxNjkwODg5MzIyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XDIwMTM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi4yNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtp ZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJs ZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28t dHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNv LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1h bHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJh LW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0 eWxlPg0KPCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZSBzdHlsZT0ndGFiLWludGVydmFsOi41aW4nPg0KDQo8ZGl2IGNsYXNzPVNl Y3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+SGksPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6 QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5JIHdhcyBnb2luZyB0aHJvdWdoIGNhbGwgZmxvdyBm b3IgQ0FMTCBIT0xEIGluIHRoZSBzZXJ2aWNlcw0KZHJhZnQgPGENCmhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwcGluZy1zZXJ2aWNlLWV4YW1w bGVzLTA1LnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1zaXBwaW5nLXNlcnZpY2UtZXhhbXBsZXMtMDUudHh0PC9hPi4NCjxzcGFuIGNsYXNzPUdyYW1F PmFuZDwvc3Bhbj4gSSBoYWQgYSBzaW1wbGUgcXVlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OkFyaWFsJz5Bc3N1bWUgYSBzY2VuYXJpbyB3aGVyZSBhIFVBIGlzIG9uIEhPTEQsIHNvIGl0 IGhhcyByZWNlaXZlZA0KdGhlIElOVklURSAoaG9sZCkgYW5kIGhhcyBzdG9wcGVkIHNlbmRpbmcg dGhlIGF1ZGlvIChtZWRpYSkgdG8gdGhlIHBlZXIuIE5vdw0KYXNzdW1lIHRoYXQgdGhlIHBhcnR5 IG9uIEhPTEQgcmVjZWl2ZXMgYSBuZXcgSU5WSVRFIGZyb20gYW5vdGhlciBwZWVyIHdoaWNoIGl0 DQp3YW50cyB0byB0YWtlLiBBIG5vcm1hbCB3YXkgb2YgZG9pbmcgdGhpcyB3b3VsZCBiZSB0byBw dXQgdGhlIGV4aXN0aW5nIGNhbGwgb24NCmhvbGQgYW5kIGFjY2VwdCB0aGUgbmV3IGNhbGwuIEJ1 dCBpbiB0aGlzIGNhc2UgdGhlIGV4aXN0aW5nIGNhbGwgaXMgYWxyZWFkeSBvbg0KSE9MRCwgc28g d2hhdCBzaG91bGQgdGhlIFVBIGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4y NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTsNCnRhYi1zdG9w czpsaXN0IC4yNWluJz48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPTIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPi08Zm9udCBzaXplPTENCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+ PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2Zv bnQtZmFtaWx5OkFyaWFsJz5TaG91bGQgaXQgc3RpbGwgc2VuZCB0aGUgSU5WSVRFIChob2xkKSwg YnV0IHRoaXMgd2lsbA0KcmV2ZXJzZSB0aGUgZGlyZWN0aW9uIG9mIHRoZSBhdWRpbyAoYT08c3Bh biBjbGFzcz1TcGVsbEU+c2VuZG9ubHk8L3NwYW4+DQppbnN0ZWFkIG9mIGE9PHNwYW4gY2xhc3M9 U3BlbGxFPnJlY3Zvbmx5PC9zcGFuPikuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7DQp0YWItc3RvcHM6bGlzdCAuMjVpbic+PCFb aWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz4tPGZvbnQgc2l6ZT0xDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFb ZW5kaWZdPjxmb250IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LWZhbWlseTpBcmlhbCc+ T3IgPHNwYW4gY2xhc3M9R3JhbUU+U2hvdWxkPC9zcGFuPiBpdCBhY2NlcHQgdGhlIG5ldw0KY2Fs bCB3L28gZG9pbmcgYW55dGhpbmcgd2l0aCB0aGUgZXhpc3RpbmcgY2FsbCBzaW5jZSBpdCBpcyBh bHJlYWR5IG9uIEhPTEQuIEluDQp0aGlzIGNhc2Ugd2hlbiB0aGUgcGVlciB0YWtlcyB0aGUgZXhp c3RpbmcgY2FsbCBPRkYgSE9MRCwgdGhlbiB0aGF0IHdvdWxkIGludGVyZmVyZQ0Kd2l0aCB0aGUg YXVkaW8gb24gdGhlIG5ldyBjYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xOw0KdGFiLXN0b3BzOmxpc3QgLjI1aW4nPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ LTxmb250IHNpemU9MQ0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udDo3 LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2Vu ZGlmXT48Zm9udCBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1mYW1pbHk6QXJpYWwnPlNo b3VsZCBpdCBnbyB3aXRoIHRoZSBzZWNvbmQgb3B0aW9uLCBidXQgaW4gYWRkaXRpb24NCndoZW4g dGhlIHBlZXIgdGFrZXMgdGhlIGNhbGwgT0ZGIEhPTEQsIGl0IHNob3VsZCByZXNwb25kIGJhY2sg d2l0aCBhIDIwMCBPSw0KdGhhdCBjb250YWlucyAoYT08c3BhbiBjbGFzcz1TcGVsbEU+c2VuZG9u bHk8L3NwYW4+KSBpbiB0aGUgU0RQIGJvZHksIHRodXMNCnB1dHRpbmcgdGhlIHBlZXIgb24gSE9M RC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkFwcHJlY2lhdGUgeW91ciBoZWxwIG9u IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz4tIEFqYXk8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C37894.93E69B04-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 14:51:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05366 for ; Thu, 11 Sep 2003 14:51:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWX8-0002Il-He for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BIpASj008830 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWX0-0002E4-ME; Thu, 11 Sep 2003 14:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWWP-0002Bn-8R for sip@optimus.ietf.org; Thu, 11 Sep 2003 14:50:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05054; Thu, 11 Sep 2003 14:50:18 -0400 (EDT) Message-Id: <200309111850.OAA05054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 11 Sep 2003 14:50:17 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-publish-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol (SIP) Extension for Event State Publication Author(s) : A. Niemi Filename : draft-ietf-sip-publish-00.txt Pages : 32 Date : 2003-9-11 This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the framework for SIP Event Notification. The first application of this extension is targeted at the publication of presence information. The mechanism described in this document can be extended to support publication of any event state, for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose (FTP, HTTP, etc.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-publish-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-publish-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-11123340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-publish-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-publish-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-11123340.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 14:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05825 for ; Thu, 11 Sep 2003 14:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWeo-0002vj-Pc for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BIx65n011263 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 14:59:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWej-0002vE-U1; Thu, 11 Sep 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWdu-0002ul-QU for sip@optimus.ietf.org; Thu, 11 Sep 2003 14:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05793 for ; Thu, 11 Sep 2003 14:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWdr-0004Ph-00 for sip@ietf.org; Thu, 11 Sep 2003 14:58:07 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xWdr-0004P2-00 for sip@ietf.org; Thu, 11 Sep 2003 14:58:07 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03025; Thu, 11 Sep 2003 14:57:35 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13922; Thu, 11 Sep 2003 14:57:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 14:57:36 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E4F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Matt Guertin'" , "'sip@ietf.org'" Date: Thu, 11 Sep 2003 14:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Matt Generally, when we say "ad hoc conference", we mean something that happens at the spur of the moment; it's not scheduled. A scheduled conference is something else. Really, there is very little difference, at least in terms of how the mechanisms work: 1) You go to the conference factory to get a conference uri 2) You either hand it out, and people INVITE themselves in, or you REFER people to the conference-id The important point is that the conference factory uri is well known, and generally doesn't change, but the conference-uri is different for every conference. From the point of view of a participant, a conference uri is just a uri. How it gets it (by INVITE to conference factory uri, or email, or "good guess", doesn't matter. It has one. The crux of your question, as stated, was how the proxy server routes calls. I gave one answer, you have another. In mine, the proxy server has a routing rule based on a pattern match on the uri. For example, it might say that any username starting with "bridge2-" is routed to a particular conference bridge. Then conference uris handed out by the conference factory might be something like "bridge2-922ac44a00@example.com", but they could also look like "bridge-2-weekly-sales-conf@example.com". Your suggestion has the conference factory registering each uri it hands out. That also will work. Hybrids will work. For example, I could register "weekly-sales-call@example.com" as an alias for "bridge2-99n77h7h7777@example.com", if my proxy server allowed aliases. I don't think that we want to have locked down specifications for this kind of thing, at least right now. I think a stand-alone conference server, which was not a proxy server, might want to be able to register every conference, but it might want to be configurable so that such a mechanism was controllable. I'll point out that registration isn't particularly desirable for what I call an ad-hoc conference, primarily because I don't want to incur the registration delay between the time I press the "CONF" button on my phone, and the time the party I'm calling's phone rings. One thing I'm curious about. Have you ever used a conference bridge, or service, that literally kicked you out at the scheduled time? They are pretty uncommon, and, in my own experience, frustrating. Meetings that conclude on schedule are pretty rare, around here anyway. Nearly every conference service I've ever used does not enforce a time limit. I've seen some video bridges that do that. Not a matter for standardization of course; if you want to build one that way, I don't want to stop you :) Brian -----Original Message----- From: Matt Guertin [mailto:MGuertin@sonexis.com] Sent: Thursday, September 11, 2003 2:36 PM To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org' Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? Hi Brian, Thanks for taking the time to respond to my posting. What you describe sounds like it will work for very small conferences. However, we support "open-ended" conferences, where anyone who knows the "conference-id" can get in, even if the host does not explicitly invite them. In addition, for a scheduled conference, the host can send out invitations to dozens of people, knowing that only maybe half will be able to participate. But the real "gotcha" here is that the conference always has an end time. For example, if there is a 1:00PM sales meeting, it will go until maybe 2:00PM. Then that's it. There may be another one tomorrow, or next week at the same time, but the conference is over until then. You wouldn't want to tie up the ports on a conference bridge for a conference that's over. You would let someone else use them for another conference, and/or the earlier host to use them again for some other meeting. I don't see why the SIP proxy server can't just forward the requests for the additional URIs in the contact field. That would solve all the problems associated with "time-based" conferences. 1) The SIP proxy would know that it is dealing with a conference bridge, which will have many "aliases" for conferences. 2) The conference bridge is still looked at as a single user agent, with a single username and password. For example: REGISTER sip:10.1.4.35:5060 SIP/2.0 From: sip:2038@10.20.20.201:5060 To: sip:2038@10.20.20.201 Contact: ;isfocus Contact: ;isfocus Contact: ;isfocus Call-ID: 12707648587750000@SONEXIS-C723CFA CSeq: 85 REGISTER Content-Length: 0 Expires: 1200 Proxy-Authorization: Digest username="2038",realm=... The above might represent registering three concurrent conferences going on at a conference bridge called 2038. Of course, the conference bridge would only register "active" conferences, and unregister them when they are over. And when someone issued an INVITE request to the conference bridge it would be responsible for placing the participant in the correct conference. -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marcon i.com... > We make this work roughly (code is evolving) the following way: > We provision (actually, it's learned) the name of the local > conference factory uri. This is a fixed uri, and is > local to the domain of the conference host. > The conference host registers with this well known > address. It is an actual "user" in the system. > We start with a 1on1 call, between the first two parties > When we add the third party, the UA initiating this action > sends an INVITE to the conference factory uri. > The conference host returns a Contact header with > a unique conference uri. The conference uri is > constructed using a pattern known to the outgoing proxy > The UA initiating the conference REFERs all three parties to > the conference using the conference uri > Invites with a username matching the pattern are routed to > the conference host > > Brian > > > > -----Original Message----- > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > Sent: Wednesday, September 10, 2003 11:20 AM > > To: sip@ietf.org > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > I read through all the SIP specs that I know of, and believe to have > > implement our SIP Conference "focus" correctly. We have what > > is sometimes > > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > > anyway). When I go to do a REGISTER request, the > > authentication fails, > > because the username/password does not match with the > > ConferenceURI. I can > > only register with ConferenceURIs which have > > usernames/password provisioned. > > This doesn't work for Ad Hoc conferences, and even for > > scheduled conferences > > for that matter. It is unacceptable in a practical > > application to send mail > > to an administrator every time a new conference is scheduled > > to generate a > > username/password for the conference. The administrator may > > not get around > > to adding the new username/password for hours or even days. > > Am I missing > > something? We are using the contact field the way it is > > spec'ed in the > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 16:07:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12162 for ; Thu, 11 Sep 2003 16:07:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXin-0005mH-JR for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BK7HbA022197 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:07:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXiY-0005gc-Vf; Thu, 11 Sep 2003 16:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXiI-0005fK-Nw for sip@optimus.ietf.org; Thu, 11 Sep 2003 16:06:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11969 for ; Thu, 11 Sep 2003 16:06:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXiH-0005r4-00 for sip@ietf.org; Thu, 11 Sep 2003 16:06:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xXiG-0005qr-00 for sip@ietf.org; Thu, 11 Sep 2003 16:06:44 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2003 13:19:39 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8BK6CS4011263; Thu, 11 Sep 2003 13:06:13 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIA21852; Thu, 11 Sep 2003 13:06:12 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 11 Sep 2003 13:06:15 -0700 Subject: Re: [Sip] Canceling REFER From: Cullen Jennings To: Robert Sparks , "Mark Eastman (meastman)" CC: Message-ID: In-Reply-To: <1063291449.884.11.camel@RjS.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry, I should have been more specific - I think we agree. I was only discussion the replaces case not the general Refer case. On 9/11/03 7:44, "Robert Sparks" wrote: > Correct. As an example, imagine that I am in an INVITE created dialog > with my conference server and I want to send it REFERs to bring both > you and Cullen into this same conference. I don't want to have my > INVITE to Cullen CANCEL my INVITE to you. > > RjS > > On Thu, 2003-09-11 at 09:34, Mark Eastman (meastman) wrote: >> So basically, you feel receiving a REFER within another REFER dialog, >> should not cause the triggered INVITE from the first REFER to be canceled? >> >> Thanks, >> Mark >> >> >> At 09:21 AM 9/11/2003 -0500, Robert Sparks wrote: >>> This would close the door on any applications that would try to >>> send REFERs to more than one destination (inside a given dialog) >>> at once. I don't think that would be good for us in the long run. >>> >>> RjS >>> >>> On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote: >>>> On 9/8/03 16:42, "Cullen Jennings" wrote: >>>> >>>> >>>> I had some out of band discussion to track down the requirements on this. I >>>> think the question actually turned into the the question of what happen >>> when >>>> you send a REFER to an early dialog. If the refer is accepted and a new >>>> dialog is formed, I believe the old dialog should be ended - in this case >>>> since it is an early dialog, it will be ended by sending a CANCEL. >>>> >>>> Do folks agree on this? Thanks, Cullen >>>> >>>> >>>>> >>>>> Before we continue the discussion on how to implement the time travel >>>>> machine that P-RECALL-MISSLES will require, can anyone provide any >>> reason we >>>>> would need to cancel a REFER and perhaps we can just solve that problem >>>>> instead. >>>>> >>>>> >>>>> On 9/5/03 6:29, "Jiri Kuthan" wrote: >>>>> >>>>>> I think CANCEL would be better off. User's location can change before >>>>>> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different >>> destination >>>>>> than the original REFER. CANCEL guarantees that you use the same >>>>>> transport destination as the original request. >>>>>> >>>>>> -Jiri >>>>>> >>>>>> At 03:21 PM 9/5/2003, Tolga Asveren wrote: >>>>>>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265. >>>>>>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the >>> procedure >>>>>>> described in RFC3265 is valid. >>>>>>> >>>>>>> Tolga >>>>>>> --- "Mark Eastman (meastman)" wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a question about how to deal with canceling a >>>>>>>> REFER. Let's say I >>>>>>>> REFER Bob to Betty, but then decide I want to REFER >>>>>>>> Bob to someone else >>>>>>>> before the transfer is complete. Are there existing >>>>>>>> call flows describing >>>>>>>> such behavior? I know the REFER rfc states handling >>>>>>>> multiple refers is >>>>>>>> valid, but is that how one would handle this >>>>>>>> situation (Sending a new REFER >>>>>>>> with either a new target or perhaps method=CANCEL). >>>>>>>> If so, call flows >>>>>>>> describing such behavior would be nice. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mark >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list >>>>>>>> https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP >>>>>>>> Protocol >>>>>>>> Use sip-implementors@cs.columbia.edu for questions >>>>>>>> on current sip >>>>>>>> Use sipping@ietf.org for new developments on the >>>>>>>> application of sip >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol >>>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>>> Use sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> -- >>>>>> Jiri Kuthan http://iptel.org/~jiri/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of sip >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 16:34:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12762 for ; Thu, 11 Sep 2003 16:34:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xY8z-0006Vk-Bo for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:34:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BKYLbS024968 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:34:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xY8f-0006TU-S7; Thu, 11 Sep 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xY8G-0006Sx-E6 for sip@optimus.ietf.org; Thu, 11 Sep 2003 16:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12696 for ; Thu, 11 Sep 2003 16:33:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xY89-00060l-00 for sip@ietf.org; Thu, 11 Sep 2003 16:33:29 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xY88-00060O-00 for sip@ietf.org; Thu, 11 Sep 2003 16:33:28 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06092; Thu, 11 Sep 2003 16:31:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27104; Thu, 11 Sep 2003 16:31:44 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 16:31:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E5A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Matt Guertin'" , "'sip@ietf.org'" Date: Thu, 11 Sep 2003 16:31:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Well, our proxy server allows rule based routing with regexps. I've seen others that have similar capabilities. I've also seen registrars that can be configured to accept certain classes of registrations without username/password challenges. This is BCP stuff, not specification work, but we might have to do it. One easy way for you to solve your problem is to implement your own proxy server which does routing the way you want it. Then, the existing proxy servers can have simple routing for "conferencing.example.com", for example. Nearly every proxy can handle that. Brian -----Original Message----- From: Matt Guertin [mailto:MGuertin@sonexis.com] Sent: Thursday, September 11, 2003 4:12 PM To: 'Rosen, Brian'; 'sip@ietf.org' Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? Hi Brian, Our product has a web-based interface for setting up conferences. If you select that you want to start a conference "now" we declare it to be an "ad hoc" conference. But we still make the user specify an end time. This is the main, and I think only, difference between your definition and ours. I agree about conference-uris, it doesn't really matter how they come into existence, for this discussion, once you have one, you have one. Each instance of a conference has a unique conference uri. All of this is clear in the specs. The problem is that let's say, we send out email saying that conference so-and-so is starting now (or at 1:00PM - it doesn't really matter). There is a SIP uri in the email invitation. And at the specified time, the caller uses his/her softphone to dial in. But the proxy server needs to understand that this sip uri needs to go to the conference bridge. The problem we have right now, is that we don't control the proxy servers. So how can we follow the standards (or draft standards) and still get this to work? I don't know of any sip proxy server which allows the flexibility you describe (i.e., rule-based / policy-based routing). Trying to register the conference-uri's didn't work because of authentication - each conference uri can't have a unique username / password associated with it - the overhead would kill us. I don't see how the REFER style would work for large conferences, and we use a participant dial-in model, anyway. I thought that the proxy servers would be smart enough to understand that the contact fields can be used as aliases when the 'isfocus' flag is used. But unfortunately not. This all boils down to resource allocation. Since audio ports are a valuable resource, we can't tie them up unless we know they are being used. Hence, the need for scheduling. If a conference goes over its allocated time slot, it keeps going as long as there are audio ports available. If someone else scheduled a conference right after yours and there are too few audio ports, the expired conference is stopped so that the next group can use the audio ports. What if you had an important conference scheduled, and had some important people on the call, but you couldn't start the conference because the people in the earlier conference didn't want to end theirs? It's a lot like a conference room scheduling program, there's the rooms and there are people who can fit in the room, and there are time ranges. Scheduled audio conferences are becoming extremely popular and going to be around for a long time, because they are more practical in most business applications than open-ended and ad hoc conferences. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, September 11, 2003 2:58 PM To: 'Matt Guertin'; 'sip@ietf.org' Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? Matt Generally, when we say "ad hoc conference", we mean something that happens at the spur of the moment; it's not scheduled. A scheduled conference is something else. Really, there is very little difference, at least in terms of how the mechanisms work: 1) You go to the conference factory to get a conference uri 2) You either hand it out, and people INVITE themselves in, or you REFER people to the conference-id The important point is that the conference factory uri is well known, and generally doesn't change, but the conference-uri is different for every conference. From the point of view of a participant, a conference uri is just a uri. How it gets it (by INVITE to conference factory uri, or email, or "good guess", doesn't matter. It has one. The crux of your question, as stated, was how the proxy server routes calls. I gave one answer, you have another. In mine, the proxy server has a routing rule based on a pattern match on the uri. For example, it might say that any username starting with "bridge2-" is routed to a particular conference bridge. Then conference uris handed out by the conference factory might be something like "bridge2-922ac44a00@example.com", but they could also look like "bridge-2-weekly-sales-conf@example.com". Your suggestion has the conference factory registering each uri it hands out. That also will work. Hybrids will work. For example, I could register "weekly-sales-call@example.com" as an alias for "bridge2-99n77h7h7777@example.com", if my proxy server allowed aliases. I don't think that we want to have locked down specifications for this kind of thing, at least right now. I think a stand-alone conference server, which was not a proxy server, might want to be able to register every conference, but it might want to be configurable so that such a mechanism was controllable. I'll point out that registration isn't particularly desirable for what I call an ad-hoc conference, primarily because I don't want to incur the registration delay between the time I press the "CONF" button on my phone, and the time the party I'm calling's phone rings. One thing I'm curious about. Have you ever used a conference bridge, or service, that literally kicked you out at the scheduled time? They are pretty uncommon, and, in my own experience, frustrating. Meetings that conclude on schedule are pretty rare, around here anyway. Nearly every conference service I've ever used does not enforce a time limit. I've seen some video bridges that do that. Not a matter for standardization of course; if you want to build one that way, I don't want to stop you :) Brian -----Original Message----- From: Matt Guertin [mailto:MGuertin@sonexis.com] Sent: Thursday, September 11, 2003 2:36 PM To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org' Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? Hi Brian, Thanks for taking the time to respond to my posting. What you describe sounds like it will work for very small conferences. However, we support "open-ended" conferences, where anyone who knows the "conference-id" can get in, even if the host does not explicitly invite them. In addition, for a scheduled conference, the host can send out invitations to dozens of people, knowing that only maybe half will be able to participate. But the real "gotcha" here is that the conference always has an end time. For example, if there is a 1:00PM sales meeting, it will go until maybe 2:00PM. Then that's it. There may be another one tomorrow, or next week at the same time, but the conference is over until then. You wouldn't want to tie up the ports on a conference bridge for a conference that's over. You would let someone else use them for another conference, and/or the earlier host to use them again for some other meeting. I don't see why the SIP proxy server can't just forward the requests for the additional URIs in the contact field. That would solve all the problems associated with "time-based" conferences. 1) The SIP proxy would know that it is dealing with a conference bridge, which will have many "aliases" for conferences. 2) The conference bridge is still looked at as a single user agent, with a single username and password. For example: REGISTER sip:10.1.4.35:5060 SIP/2.0 From: sip:2038@10.20.20.201:5060 To: sip:2038@10.20.20.201 Contact: ;isfocus Contact: ;isfocus Contact: ;isfocus Call-ID: 12707648587750000@SONEXIS-C723CFA CSeq: 85 REGISTER Content-Length: 0 Expires: 1200 Proxy-Authorization: Digest username="2038",realm=... The above might represent registering three concurrent conferences going on at a conference bridge called 2038. Of course, the conference bridge would only register "active" conferences, and unregister them when they are over. And when someone issued an INVITE request to the conference bridge it would be responsible for placing the participant in the correct conference. -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marcon i.com... > We make this work roughly (code is evolving) the following way: > We provision (actually, it's learned) the name of the local > conference factory uri. This is a fixed uri, and is > local to the domain of the conference host. > The conference host registers with this well known > address. It is an actual "user" in the system. > We start with a 1on1 call, between the first two parties > When we add the third party, the UA initiating this action > sends an INVITE to the conference factory uri. > The conference host returns a Contact header with > a unique conference uri. The conference uri is > constructed using a pattern known to the outgoing proxy > The UA initiating the conference REFERs all three parties to > the conference using the conference uri > Invites with a username matching the pattern are routed to > the conference host > > Brian > > > > -----Original Message----- > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > Sent: Wednesday, September 10, 2003 11:20 AM > > To: sip@ietf.org > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > I read through all the SIP specs that I know of, and believe to have > > implement our SIP Conference "focus" correctly. We have what > > is sometimes > > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > > anyway). When I go to do a REGISTER request, the > > authentication fails, > > because the username/password does not match with the > > ConferenceURI. I can > > only register with ConferenceURIs which have > > usernames/password provisioned. > > This doesn't work for Ad Hoc conferences, and even for > > scheduled conferences > > for that matter. It is unacceptable in a practical > > application to send mail > > to an administrator every time a new conference is scheduled > > to generate a > > username/password for the conference. The administrator may > > not get around > > to adding the new username/password for hours or even days. > > Am I missing > > something? We are using the contact field the way it is > > spec'ed in the > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 11 16:46:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13080 for ; Thu, 11 Sep 2003 16:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYJr-00077F-S1 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:45:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BKjZR2027352 for sip-archive@odin.ietf.org; Thu, 11 Sep 2003 16:45:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYJM-00076C-Sk; Thu, 11 Sep 2003 16:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYIv-00075E-Ue for sip@optimus.ietf.org; Thu, 11 Sep 2003 16:44:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13026 for ; Thu, 11 Sep 2003 16:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYIt-00067e-00 for sip@ietf.org; Thu, 11 Sep 2003 16:44:35 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xYIo-00066z-00 for sip@ietf.org; Thu, 11 Sep 2003 16:44:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06511; Thu, 11 Sep 2003 16:43:55 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28787; Thu, 11 Sep 2003 16:43:55 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 16:43:55 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E5D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Matt Guertin'" , "'sip@ietf.org'" Subject: RE: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? Date: Thu, 11 Sep 2003 16:43:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Commenting on my own message. What is the difference between a proxy server that forwards all calls in it's domain to a single UA, plus a UA that accepts all usernames sent to it vs a UA that accepts all usernames sent to it? Answer - nothing. Just allow your UA to have a DNS hostname, and have the proxy route calls to you (ie *@hostname.example.com). No need to register. The existing proxy doesn't know, and doesn't care, that the next hop isn't a proxy server, it's just the next hop. Brian > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, September 11, 2003 4:32 PM > To: 'Matt Guertin'; 'sip@ietf.org' > Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? > > > Well, our proxy server allows rule based routing with regexps. > I've seen others that have similar capabilities. > I've also seen registrars that can be configured to accept > certain classes of registrations without username/password challenges. > This is BCP stuff, not specification work, but we might have to > do it. > > One easy way for you to solve your problem is to implement your > own proxy server which does routing the way you want it. > Then, the existing proxy servers can have simple routing for > "conferencing.example.com", for example. Nearly every proxy > can handle that. > > Brian > -----Original Message----- > From: Matt Guertin [mailto:MGuertin@sonexis.com] > Sent: Thursday, September 11, 2003 4:12 PM > To: 'Rosen, Brian'; 'sip@ietf.org' > Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? > > > Hi Brian, > Our product has a web-based interface for setting up > conferences. If you select that you want to start a conference > "now" we declare it to be an "ad hoc" conference. But we > still make the user specify an end time. This is the main, > and I think only, difference between your definition and ours. > I agree about conference-uris, it doesn't really matter how > they come into existence, for this discussion, once you have > one, you have one. Each instance of a conference has a unique > conference uri. All of this is clear in the specs. > The problem is that let's say, we send out email saying that > conference so-and-so is starting now (or at 1:00PM - it > doesn't really matter). There is a SIP uri in the email > invitation. And at the specified time, the caller uses > his/her softphone to dial in. But the proxy server needs > to understand that this sip uri needs to go to the conference > bridge. The problem we have right now, is that we don't > control the proxy servers. So how can we follow the standards > (or draft standards) and still get this to work? I don't know > of any sip proxy server which allows the flexibility you > describe (i.e., rule-based / policy-based routing). Trying to > register the conference-uri's didn't work because of > authentication - each conference uri can't have a unique > username / password associated with it - the overhead would > kill us. I don't see how the REFER style would work for large > conferences, and we use a participant dial-in model, anyway. > I thought that the proxy servers would be smart enough to > understand that the contact fields can be used as aliases > when the 'isfocus' flag is used. But unfortunately not. > This all boils down to resource allocation. Since audio ports > are a valuable resource, we can't tie them up unless we know > they are being used. Hence, the need for scheduling. If a > conference goes over its allocated time slot, it keeps going > as long as there are audio ports available. If someone else > scheduled a conference right after yours and there are too > few audio ports, the expired conference is stopped so that the > next group can use the audio ports. What if you had an > important conference scheduled, and had some important people > on the call, but you couldn't start the conference because the > people in the earlier conference didn't want to end theirs? > It's a lot like a conference room scheduling program, there's > the rooms and there are people who can fit in the room, and > there are time ranges. Scheduled audio conferences are > becoming extremely popular and going to be around for a long > time, because they are more practical in most business > applications than open-ended and ad hoc conferences. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, September 11, 2003 2:58 PM > To: 'Matt Guertin'; 'sip@ietf.org' > Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? > > > Matt > Generally, when we say "ad hoc conference", we mean something that > happens at the spur of the moment; it's not scheduled. > A scheduled conference is something else. > Really, there is very little difference, at least in terms of how > the mechanisms work: > 1) You go to the conference factory to get a conference uri > 2) You either hand it out, and people INVITE themselves in, > or you REFER people to the conference-id > The important point is that the conference factory uri is well > known, and generally doesn't change, but the conference-uri > is different for every conference. > From the point of view of a participant, a conference uri is > just a uri. How it gets it (by INVITE to conference factory > uri, or email, or "good guess", doesn't matter. It has one. > The crux of your question, as stated, was how the proxy server > routes calls. I gave one answer, you have another. In mine, > the proxy server has a routing rule based on a pattern match > on the uri. For example, it might say that any username starting > with "bridge2-" is routed to a particular conference bridge. > Then conference uris handed out by the conference factory might > be something like "bridge2-922ac44a00@example.com", but they > could also look like "bridge-2-weekly-sales-conf@example.com". > Your suggestion has the conference factory registering each uri > it hands out. That also will work. Hybrids will work. For example, > I could register "weekly-sales-call@example.com" as an alias for > "bridge2-99n77h7h7777@example.com", if my proxy server allowed > aliases. I don't think that we want to have locked down > specifications > for this kind of thing, at least right now. I think a stand-alone > conference server, which was not a proxy server, might want to be > able to register every conference, but it might want to be > configurable > so that such a mechanism was controllable. > I'll point out that registration isn't particularly desirable for > what I call an ad-hoc conference, primarily because I don't want to > incur the registration delay between the time I press the > "CONF" button > on my phone, and the time the party I'm calling's phone rings. > One thing I'm curious about. Have you ever used a conference bridge, > or service, that literally kicked you out at the scheduled time? > They are pretty uncommon, and, in my own experience, frustrating. > Meetings that conclude on schedule are pretty rare, around > here anyway. > Nearly every conference service I've ever used does not enforce a > time limit. I've seen some video bridges that do that. Not a matter > for standardization of course; if you want to build one that way, I > don't want to stop you :) > Brian > -----Original Message----- > From: Matt Guertin [mailto:MGuertin@sonexis.com] > Sent: Thursday, September 11, 2003 2:36 PM > To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org' > Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? > > > Hi Brian, > Thanks for taking the time to respond to my posting. What you > describe > sounds like it will work for very small conferences. > However, we support > "open-ended" conferences, where anyone who knows the > "conference-id" can get > > in, even if the host does not explicitly invite them. In > addition, for a > scheduled conference, the host can send out invitations to > dozens of people, > > knowing that only maybe half will be able to participate. But > the real > "gotcha" here is that the conference always has an end time. > For example, > if there is a 1:00PM sales meeting, it will go until maybe > 2:00PM. Then > that's it. There may be another one tomorrow, or next week > at the same > time, but the conference is over until then. You wouldn't > want to tie up > the ports on a conference bridge for a conference that's > over. You would > let someone else use them for another conference, and/or the > earlier host to > > use them again for some other meeting. > I don't see why the SIP proxy server can't just forward the > requests for the > > additional URIs in the contact field. That would solve all > the problems > associated with "time-based" conferences. 1) The SIP proxy > would know that > it is dealing with a conference bridge, which will have many > "aliases" for > conferences. 2) The conference bridge is still looked at as a > single user > agent, with a single username and password. For example: > REGISTER sip:10.1.4.35:5060 SIP/2.0 > From: sip:2038@10.20.20.201:5060 > To: sip:2038@10.20.20.201 > Contact: ;isfocus > Contact: ;isfocus > Contact: ;isfocus > Call-ID: 12707648587750000@SONEXIS-C723CFA > CSeq: 85 REGISTER > Content-Length: 0 > Expires: 1200 > Proxy-Authorization: Digest username="2038",realm=... > > > The above might represent registering three concurrent > conferences going on > at a conference bridge called 2038. Of course, the > conference bridge would > only register "active" conferences, and unregister them when > they are over. > And when someone issued an INVITE request to the conference > bridge it would > be responsible for placing the participant in the correct conference. > -Matt. > > > > "Rosen, Brian" wrote in message > news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pi > t.comms.marcon > > i.com... > > We make this work roughly (code is evolving) the following way: > > We provision (actually, it's learned) the name of the local > > conference factory uri. This is a fixed uri, and is > > local to the domain of the conference host. > > The conference host registers with this well known > > address. It is an actual "user" in the system. > > We start with a 1on1 call, between the first two parties > > When we add the third party, the UA initiating this action > > sends an INVITE to the conference factory uri. > > The conference host returns a Contact header with > > a unique conference uri. The conference uri is > > constructed using a pattern known to the outgoing proxy > > The UA initiating the conference REFERs all three parties to > > the conference using the conference uri > > Invites with a username matching the pattern are routed to > > the conference host > > > > Brian > > > > > > > -----Original Message----- > > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > > Sent: Wednesday, September 10, 2003 11:20 AM > > > To: sip@ietf.org > > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > > > > I read through all the SIP specs that I know of, and > believe to have > > > implement our SIP Conference "focus" correctly. We have what > > > is sometimes > > > referred to as a SIP Conference Bridge Marshal Server (in > vocal speak > > > anyway). When I go to do a REGISTER request, the > > > authentication fails, > > > because the username/password does not match with the > > > ConferenceURI. I can > > > only register with ConferenceURIs which have > > > usernames/password provisioned. > > > This doesn't work for Ad Hoc conferences, and even for > > > scheduled conferences > > > for that matter. It is unacceptable in a practical > > > application to send mail > > > to an administrator every time a new conference is scheduled > > > to generate a > > > username/password for the conference. The administrator may > > > not get around > > > to adding the new username/password for hours or even days. > > > Am I missing > > > something? We are using the contact field the way it is > > > spec'ed in the > > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 01:51:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26944 for ; Fri, 12 Sep 2003 01:51:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xgpw-0005PG-Te for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 01:51:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8C5pGkG020778 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 01:51:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xgpi-0005Oe-Dm; Fri, 12 Sep 2003 01:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xgom-0005O3-JG for sip@optimus.ietf.org; Fri, 12 Sep 2003 01:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26932 for ; Fri, 12 Sep 2003 01:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xgoj-0002Ey-00 for sip@ietf.org; Fri, 12 Sep 2003 01:50:01 -0400 Received: from mailout1.samsung.com ([203.254.224.24] helo=mailout1) by ietf-mx with esmtp (Exim 4.12) id 19xgoi-0002Ev-00 for sip@ietf.org; Fri, 12 Sep 2003 01:50:00 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HL3003016U6T0@mailout1.samsung.com> for sip@ietf.org; Fri, 12 Sep 2003 14:49:18 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HL300G0F6U5UW@mailout1.samsung.com> for sip@ietf.org; Fri, 12 Sep 2003 14:49:18 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HL30089B6TZ3A@mmp2.samsung.com> for sip@ietf.org; Fri, 12 Sep 2003 14:49:17 +0900 (KST) Date: Fri, 12 Sep 2003 11:11:54 +0530 From: Ranjit Avasarala Subject: RE: [Sip] Question on CALL HOLD... In-reply-to: <8F37768D4D9CD71192CF00065BF2598B931F0A@il27exm02.cig.mot.com> To: "'Idnani Ajaykumar-AIDNANI1'" , sip@ietf.org Reply-to: ranjitk@samsung.com Message-id: <000501c378f0$95d711d0$e9076c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_QeweXUyngJiKj0s3b4cvnA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_QeweXUyngJiKj0s3b4cvnA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Ajay When UA is on hold, then that particular call session is on hold. So now when u receive a new call, then first place ur UA must be capabale of receiving multiple calls (i.e call waiting enabled). Else the second call will be dropped. So assuming call wait is enabled, u can accept the new call as the prev call is already on hold. So this functionality depends on sip stack implementation. Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Idnani Ajaykumar-AIDNANI1 Sent: Friday, September 12, 2003 12:13 AM To: sip@ietf.org Subject: [Sip] Question on CALL HOLD... Hi, I was going through call flow for CALL HOLD in the services draft http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples- 05.txt. and I had a simple question. Assume a scenario where a UA is on HOLD, so it has received the INVITE (hold) and has stopped sending the audio (media) to the peer. Now assume that the party on HOLD receives a new INVITE from another peer which it wants to take. A normal way of doing this would be to put the existing call on hold and accept the new call. But in this case the existing call is already on HOLD, so what should the UA do. - Should it still send the INVITE (hold), but this will reverse the direction of the audio (a=sendonly instead of a=recvonly). - Or Should it accept the new call w/o doing anything with the existing call since it is already on HOLD. In this case when the peer takes the existing call OFF HOLD, then that would interfere with the audio on the new call. - Should it go with the second option, but in addition when the peer takes the call OFF HOLD, it should respond back with a 200 OK that contains (a=sendonly) in the SDP body, thus putting the peer on HOLD. Appreciate your help on this. - Ajay --Boundary_(ID_QeweXUyngJiKj0s3b4cvnA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Hi Ajay
 
When UA is on hold, then that particular call session is on hold. So now when u receive a new call, then first place ur UA must be capabale of receiving multiple calls (i.e call waiting enabled). Else the second call will be dropped.
 
So assuming call wait is enabled, u can accept the new call as the prev call is already on hold. So this functionality depends on sip stack implementation.
 
Ranjit
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Idnani Ajaykumar-AIDNANI1
Sent: Friday, September 12, 2003 12:13 AM
To: sip@ietf.org
Subject: [Sip] Question on CALL HOLD...

Hi,

 

I was going through call flow for CALL HOLD in the services draft http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-05.txt. and I had a simple question.

 

Assume a scenario where a UA is on HOLD, so it has received the INVITE (hold) and has stopped sending the audio (media) to the peer. Now assume that the party on HOLD receives a new INVITE from another peer which it wants to take. A normal way of doing this would be to put the existing call on hold and accept the new call. But in this case the existing call is already on HOLD, so what should the UA do.

 

-         Should it still send the INVITE (hold), but this will reverse the direction of the audio (a=sendonly instead of a=recvonly).

-         Or Should it accept the new call w/o doing anything with the existing call since it is already on HOLD. In this case when the peer takes the existing call OFF HOLD, then that would interfere with the audio on the new call.

-         Should it go with the second option, but in addition when the peer takes the call OFF HOLD, it should respond back with a 200 OK that contains (a=sendonly) in the SDP body, thus putting the peer on HOLD.

 

Appreciate your help on this.

 

- Ajay

--Boundary_(ID_QeweXUyngJiKj0s3b4cvnA)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 03:53:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12211 for ; Fri, 12 Sep 2003 03:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xijw-0002dZ-MJ for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 03:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8C7rCE7010136 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 03:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xijm-0002cr-1H; Fri, 12 Sep 2003 03:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xiit-0002c6-18 for sip@optimus.ietf.org; Fri, 12 Sep 2003 03:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12179 for ; Fri, 12 Sep 2003 03:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xiiq-0003Jk-00 for sip@ietf.org; Fri, 12 Sep 2003 03:52:04 -0400 Received: from [62.119.82.43] (helo=hotsip.com) by ietf-mx with esmtp (Exim 4.12) id 19xiiq-0003JX-00 for sip@ietf.org; Fri, 12 Sep 2003 03:52:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on CALL HOLD... [html] Date: Fri, 12 Sep 2003 09:51:29 +0200 Message-ID: Thread-Topic: [Sip] Question on CALL HOLD... [html] Thread-Index: AcN4lOrTTjauOFoxTd+AF7V3ItfScgAZ098A From: "Christian Jansson" To: "Idnani Ajaykumar-AIDNANI1" , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As hold is unidirectional in nature, I see no problem in letting the UA (B) that received the HOLD invite also send a HOLD invite in the other direction (to A) with a=3Dinactive. =20 A B C | INVITE | | |---------------------->| | | 200 | | |<----------------------| | | ACK | | |---------------------->| | | RTP | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = | | | | | | | | | | | INVITE HOLD sendonly | | |---------------------->| | | 200 recvonly | | |<----------------------| | | ACK | | |---------------------->| | | No RTP | | | | | | | INVITE | | INVITE HOLD inactive |<----------------------| |<----------------------| 200 | | 200 inactive |---------------------->| |---------------------->| ACK | | ACK |<----------------------| |<----------------------| RTP | | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | | Either A or B can now remove their part of the double-HOLD by sending an INVITE to the other side with a=3Dsendrecv. If the other side still wants to keep its HOLD the response contains a=3Dsendonly, or if it also wants to remove its HOLD a=3Dsendrecv. This scenario does not seem to be described anywhere but I think this should work even though some simpler implementations might want to deny the user to do this because of the complexity of describing to the user the state of the call. / Christian Jansson, Hotsip > Hi, > =20 > I was going through call flow for CALL HOLD in the services=20 > draft=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > -examples-05.txt. and I had a simple question. > =20 > Assume a scenario where a UA is on HOLD, so it has received=20 > the INVITE (hold) and has stopped sending the audio (media)=20 > to the peer. Now assume that the party on HOLD receives a new=20 > INVITE from another peer which it wants to take. A normal way=20 > of doing this would be to put the existing call on hold and=20 > accept the new call. But in this case the existing call is=20 > already on HOLD, so what should the UA do. > =20 > - Should it still send the INVITE (hold), but this=20 > will reverse the direction of the audio (a=3Dsendonly instead=20 > of a=3Drecvonly). > - Or Should it accept the new call w/o doing anything=20 > with the existing call since it is already on HOLD. In this=20 > case when the peer takes the existing call OFF HOLD, then=20 > that would interfere with the audio on the new call. > - Should it go with the second option, but in=20 > addition when the peer takes the call OFF HOLD, it should=20 > respond back with a 200 OK that contains (a=3Dsendonly) in the=20 > SDP body, thus putting the peer on HOLD. > =20 > Appreciate your help on this. > =20 > - Ajay >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 07:53:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17335 for ; Fri, 12 Sep 2003 07:53:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmUI-0001Bt-3i for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 07:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CBrIRc004573 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 07:53:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmU2-0001BG-HB; Fri, 12 Sep 2003 07:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmTh-0001Ay-9v for sip@optimus.ietf.org; Fri, 12 Sep 2003 07:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17310 for ; Fri, 12 Sep 2003 07:52:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xmTg-0004zr-00 for sip@ietf.org; Fri, 12 Sep 2003 07:52:40 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx with esmtp (Exim 4.12) id 19xmTg-0004zg-00 for sip@ietf.org; Fri, 12 Sep 2003 07:52:40 -0400 Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-8.00) id A31D75802D0; Fri, 12 Sep 2003 07:50:53 -0400 Message-ID: <002801c37924$4868b0f0$2300000a@BPenfield> From: "Bob Penfield" To: References: <313680C9A886D511A06000204840E1CF070B5E45@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 12 Sep 2003 07:52:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Rosen, Brian" > It doesn't address dial strings, which is a big problem. > For example > > >Otherwise, the 'local-phone-number' (from Table 4 of > > >2543) should apply. > is problematic I think. > > I don't have a problem with the "+" or phone context > and user=phone implying it's equivalent to a tel uri. > If we allow user=phone without the restriction that the userinfo be a tel-URI (i.e. neither a + or a phone-context present), it would allow the userinfo to be a dial string (which 2543's local-phone-number allows) with the assumption that the SIP server of the host/domain of the SIP-URI knows how to interpret it. I believe this is the way that a lot of implementations use user=phone now. Having dial plans in the endpoints may not be practical from a maintenance perspective unless there is a standard way for the endpoint to download a dial plan. It is often more practical to have the proxy interpret a dial string. I think we need to specify user=phone in a backward compatible way that matches the way most implementations use it today. cheers, (-:bob > Brian > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, September 11, 2003 10:27 AM > > To: Christer Holmberg (JO/LMF); 'Bob Penfield'; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > Hi, > > > > So, is Bob's proposal something which could be accepted, or > > at least worked futher on? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > Sent: 4. syyskuuta 2003 13:14 > > > To: 'Bob Penfield'; sip@ietf.org > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > > > > Hi, > > > > > > I would support Bob's proposal, saying that a "+" indicates > > > global-phone-number, according to RFC2806(or bis). I don't > > > think there would be any backward compability issues, because > > > I doubt anyone is using "+" for any other purpose - at least > > > not as the first character of the user part. Of course, nodes > > > that really REQUIRE user=phone to be present, in order to > > > accept the request in the first, place would have to be changed. > > > > > > Of course, user=tel could also be used, but I really see no > > > use for that if the "+" rule applies. Also, user=tel COULD > > > cause backward compability issues. > > > > > > Then, since there doesn't seem to be an agreement on what > > > user=phone really means, related BOTH to the userpart syntax > > > and the message routing, we could remove it completely. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > > Sent: 4. syyskuuta 2003 2:43 > > > > To: sip@ietf.org > > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > > > > Getting back to the problem Robert described in the > > > original mail, the > > > > interoperability problems are a result of that fact that what > > > > is a valid > > > > userinfo part of a SIP URL with a user=phone parameter has > > > > steadily gotten > > > > stricter without any consideration for backwards > > > > compatibility. The specific > > > > problem he described resulted because a SIP URL created with > > > > 2543 rules was > > > > rejected by a server applying 3261/2806 rules. The new > > > > 2806bis rules are > > > > even stricter. I have no problem with those rules for tel-URLs. > > > > > > > > In spite of the lack of normative text on user-phone, the > > > > statements in 2543 > > > > and 3261 to the effect that it is used to distinguish phone > > > > numbers from > > > > usernames leads one to the reasonable conclusion that when it > > > > is present, > > > > the 'telephone-subscriber' BNF applies. This is the > > > > conclusion that we and a > > > > number of our vendors and customers came to when we ran > > into interop > > > > problems. > > > > > > > > However, its not that simple since a 'telephone-subscriber' > > > > keeps changing. > > > > > > > > >From some of the posting on this subject, there seems to > > > be value in > > > > distinguishing a telephone number from username that happens > > > > to look like a > > > > telephone number without requiring that the user part be a > > > > tel-URL. What I > > > > would propose is that while we make the rules for user=phone > > > > clearer, they > > > > ought to be closer to the 2543 rules which in my > > experience a lot of > > > > existing implementation seem to follow. If the userinfo > > > > begins with "+" or > > > > contains a phone-context, then it is reasonable to > > interpret it as a > > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > > > 2543) should > > > > apply. A server which is not responsible for the domain of > > > the SIP URL > > > > should not reject a SIP URL because phone-context is missing. > > > > Actually, I > > > > believe it is reasonable to take the SIP URL host part as the > > > > 'default' > > > > phone-context when it is missing. > > > > > > > > Also, we could add 'user=tel' for userinfo that MUST be > > > > tel-URLs. In that > > > > case, rejecting a local number without a phone-context would > > > > be perfectly > > > > reasonable. > > > > > > > > cheers, > > > > (-:bob > > > > > > > > Robert F. Penfield > > > > Chief Software Architect > > > > Acme Packet, Inc. > > > > 130 New Boston Street > > > > Woburn, MA 01801 > > > > bpenfield@acmepacket.com > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 07:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17515 for ; Fri, 12 Sep 2003 07:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmYu-0001T0-3F for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 07:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CBw4UW005611 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 07:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmYr-0001Rp-9f; Fri, 12 Sep 2003 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmXu-0001R3-Qf for sip@optimus.ietf.org; Fri, 12 Sep 2003 07:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17451 for ; Fri, 12 Sep 2003 07:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xmXt-00052Q-00 for sip@ietf.org; Fri, 12 Sep 2003 07:57:02 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19xmXt-00052J-00 for sip@ietf.org; Fri, 12 Sep 2003 07:57:01 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h8CBuUcJ013853 for ; Fri, 12 Sep 2003 13:56:30 +0200 Received: from vies141a.sie.siemens.at (nets109x.sie.siemens.at [158.226.134.96]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h8CBuTmv019661 for ; Fri, 12 Sep 2003 13:56:29 +0200 (MET DST) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 13:58:30 +0200 Message-ID: From: Horvath Ernst To: "'sip@ietf.org'" Subject: [Sip] Question on draft-ietf-sip-publish-00.txt (Request-URI usa ge) Date: Fri, 12 Sep 2003 13:58:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Can someone explain why the Request-URI in the example flows is set in the way shown? In particular, why is the Request-URI in the NOTIFY messages "presentity@domain.com" and not "watcher@domain.com" as I would have expected from examples elsewhere, for instance in the service-examples draft? Thanks, Ernst _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 08:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18637 for ; Fri, 12 Sep 2003 08:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmrK-0002FK-Q7 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 08:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CCH629008630 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 08:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmrF-0002Em-Du; Fri, 12 Sep 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmqe-0002Cz-Av for sip@optimus.ietf.org; Fri, 12 Sep 2003 08:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18624 for ; Fri, 12 Sep 2003 08:16:17 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xmqd-0005SE-00 for sip@ietf.org; Fri, 12 Sep 2003 08:16:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19xmqc-0005SA-00 for sip@ietf.org; Fri, 12 Sep 2003 08:16:22 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8CCGCB06726 for ; Fri, 12 Sep 2003 15:16:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Sep 2003 15:16:10 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 12 Sep 2003 15:16:12 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 12 Sep 2003 15:16:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on draft-ietf-sip-publish-00.txt (Request-URI usage) Date: Fri, 12 Sep 2003 15:16:11 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194536C@esebe013.ntc.nokia.com> Thread-Topic: [Sip] Question on draft-ietf-sip-publish-00.txt (Request-URI usage) Thread-Index: AcN5JTQAIdwP0aLeSb+g88wg55gFUQAAEZig To: , X-OriginalArrivalTime: 12 Sep 2003 12:16:12.0133 (UTC) FILETIME=[A7BC5950:01C37927] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ernst, That is an obvious typo, in fact I thought I had cleaned up the example = messages but this apparently still slipped in. The Request-URI in the NOTIFY should be whatever the SUBSCRIBE Contact = had, in this case "watcher@domain.com". Cheers, Aki > -----Original Message----- > From: ext Horvath Ernst [mailto:ernst.horvath@siemens.com] > Sent: 12 September, 2003 14:59 > To: 'sip@ietf.org' > Subject: [Sip] Question on draft-ietf-sip-publish-00.txt (Request-URI > usage) >=20 >=20 > Can someone explain why the Request-URI in the example flows=20 > is set in the > way shown?=20 >=20 > In particular, why is the Request-URI in the NOTIFY messages > "presentity@domain.com" and not "watcher@domain.com"=20 > as I would have expected from examples elsewhere, for instance in the > service-examples draft? >=20 > Thanks, > Ernst >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 08:50:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19352 for ; Fri, 12 Sep 2003 08:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnNL-0003GU-Ul for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 08:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CCoBg9012547 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 08:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnND-0003Fo-DU; Fri, 12 Sep 2003 08:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnMq-0003Ez-0g for sip@optimus.ietf.org; Fri, 12 Sep 2003 08:49:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19323 for ; Fri, 12 Sep 2003 08:49:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xnMo-0005l1-00 for sip@ietf.org; Fri, 12 Sep 2003 08:49:38 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19xnMo-0005kv-00 for sip@ietf.org; Fri, 12 Sep 2003 08:49:38 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18753; Fri, 12 Sep 2003 08:49:05 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04435; Fri, 12 Sep 2003 08:49:06 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 08:49:06 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E66@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 12 Sep 2003 08:49:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I agree that user=phone with no "+" and no context in most phones means that the username is a dial string, and for backwards compatibility, that's the way we must leave it. Getting rid of user=phone means that there is no way to distinguish between a dial string and a username that looks like a dial string. That's bad. If we leave it at that, I won't have a lot of heartburn. I'd prefer to have a more unambiguous designation for a dial string. I'd prefer a way to distinguish the following from each other: A raw dial string A real phone number The results of an ENUM translation a numeric username I also wonder if we shouldn't have a way to distinguish 1-800-BUY-MINE as a dialable phone number. local-phone-number syntax is okay. Note it substitutes "p" for "," Seems like allowing the comma would be acceptable, escaped if you'd like, although strictly speaking "user-unreserved" allows comma. Brian > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, September 12, 2003 7:52 AM > To: sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > ----- Original Message ----- > From: "Rosen, Brian" > > > It doesn't address dial strings, which is a big problem. > > For example > > > >Otherwise, the 'local-phone-number' (from Table 4 of > > > >2543) should apply. > > is problematic I think. > > > > I don't have a problem with the "+" or phone context > > and user=phone implying it's equivalent to a tel uri. > > > > If we allow user=phone without the restriction that the userinfo be a > tel-URI (i.e. neither a + or a phone-context present), it > would allow the > userinfo to be a dial string (which 2543's local-phone-number > allows) with > the assumption that the SIP server of the host/domain of the > SIP-URI knows > how to interpret it. I believe this is the way that a lot of > implementations > use user=phone now. Having dial plans in the endpoints may > not be practical > from a maintenance perspective unless there is a standard way for the > endpoint to download a dial plan. It is often more practical > to have the > proxy interpret a dial string. > > I think we need to specify user=phone in a backward > compatible way that > matches the way most implementations use it today. > > cheers, > (-:bob > > > Brian > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, September 11, 2003 10:27 AM > > > To: Christer Holmberg (JO/LMF); 'Bob Penfield'; sip@ietf.org > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > > > > Hi, > > > > > > So, is Bob's proposal something which could be accepted, or > > > at least worked futher on? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > Sent: 4. syyskuuta 2003 13:14 > > > > To: 'Bob Penfield'; sip@ietf.org > > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > > > > > > > > Hi, > > > > > > > > I would support Bob's proposal, saying that a "+" indicates > > > > global-phone-number, according to RFC2806(or bis). I don't > > > > think there would be any backward compability issues, because > > > > I doubt anyone is using "+" for any other purpose - at least > > > > not as the first character of the user part. Of course, nodes > > > > that really REQUIRE user=phone to be present, in order to > > > > accept the request in the first, place would have to be changed. > > > > > > > > Of course, user=tel could also be used, but I really see no > > > > use for that if the "+" rule applies. Also, user=tel COULD > > > > cause backward compability issues. > > > > > > > > Then, since there doesn't seem to be an agreement on what > > > > user=phone really means, related BOTH to the userpart syntax > > > > and the message routing, we could remove it completely. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > > > Sent: 4. syyskuuta 2003 2:43 > > > > > To: sip@ietf.org > > > > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > > > > > > > Getting back to the problem Robert described in the > > > > original mail, the > > > > > interoperability problems are a result of that fact that what > > > > > is a valid > > > > > userinfo part of a SIP URL with a user=phone parameter has > > > > > steadily gotten > > > > > stricter without any consideration for backwards > > > > > compatibility. The specific > > > > > problem he described resulted because a SIP URL created with > > > > > 2543 rules was > > > > > rejected by a server applying 3261/2806 rules. The new > > > > > 2806bis rules are > > > > > even stricter. I have no problem with those rules for > tel-URLs. > > > > > > > > > > In spite of the lack of normative text on user-phone, the > > > > > statements in 2543 > > > > > and 3261 to the effect that it is used to distinguish phone > > > > > numbers from > > > > > usernames leads one to the reasonable conclusion that when it > > > > > is present, > > > > > the 'telephone-subscriber' BNF applies. This is the > > > > > conclusion that we and a > > > > > number of our vendors and customers came to when we ran > > > into interop > > > > > problems. > > > > > > > > > > However, its not that simple since a 'telephone-subscriber' > > > > > keeps changing. > > > > > > > > > > >From some of the posting on this subject, there seems to > > > > be value in > > > > > distinguishing a telephone number from username that happens > > > > > to look like a > > > > > telephone number without requiring that the user part be a > > > > > tel-URL. What I > > > > > would propose is that while we make the rules for user=phone > > > > > clearer, they > > > > > ought to be closer to the 2543 rules which in my > > > experience a lot of > > > > > existing implementation seem to follow. If the userinfo > > > > > begins with "+" or > > > > > contains a phone-context, then it is reasonable to > > > interpret it as a > > > > > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of > > > > > 2543) should > > > > > apply. A server which is not responsible for the domain of > > > > the SIP URL > > > > > should not reject a SIP URL because phone-context is missing. > > > > > Actually, I > > > > > believe it is reasonable to take the SIP URL host part as the > > > > > 'default' > > > > > phone-context when it is missing. > > > > > > > > > > Also, we could add 'user=tel' for userinfo that MUST be > > > > > tel-URLs. In that > > > > > case, rejecting a local number without a phone-context would > > > > > be perfectly > > > > > reasonable. > > > > > > > > > > cheers, > > > > > (-:bob > > > > > > > > > > Robert F. Penfield > > > > > Chief Software Architect > > > > > Acme Packet, Inc. > > > > > 130 New Boston Street > > > > > Woburn, MA 01801 > > > > > bpenfield@acmepacket.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 09:04:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19624 for ; Fri, 12 Sep 2003 09:04:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnav-0003l3-E5 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 09:04:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CD4DiB014385 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 09:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnaj-0003jV-SL; Fri, 12 Sep 2003 09:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xna8-0003it-Dz for sip@optimus.ietf.org; Fri, 12 Sep 2003 09:03:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19597 for ; Fri, 12 Sep 2003 09:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xna6-0005qa-00 for sip@ietf.org; Fri, 12 Sep 2003 09:03:22 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xna6-0005qQ-00 for sip@ietf.org; Fri, 12 Sep 2003 09:03:22 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2003 06:16:27 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8CD2nXq008901; Fri, 12 Sep 2003 06:02:50 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACI33981; Fri, 12 Sep 2003 09:02:48 -0400 (EDT) Message-ID: <3F61C3F8.5040107@cisco.com> Date: Fri, 12 Sep 2003 09:02:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5E45@whq-msgusr-02.pit.comms.marconi.com> <002801c37924$4868b0f0$2300000a@BPenfield> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > If we allow user=phone without the restriction that the userinfo be a > tel-URI (i.e. neither a + or a phone-context present), it would allow the > userinfo to be a dial string (which 2543's local-phone-number allows) with > the assumption that the SIP server of the host/domain of the SIP-URI knows > how to interpret it. I believe this is the way that a lot of implementations > use user=phone now. Having dial plans in the endpoints may not be practical > from a maintenance perspective unless there is a standard way for the > endpoint to download a dial plan. It is often more practical to have the > proxy interpret a dial string. > > I think we need to specify user=phone in a backward compatible way that > matches the way most implementations use it today. I think this is quite appropriate in order to ensure backward compatibility with current practice. But we then have two possible representations for the dial string case: sip:12345@acme.com;user=phone tel:12345;phone-context=acme.com In many ways these are equivalent, but they do have subtle differences in semantics: - the sip form has well defined routing rules for getting it to a server that ought to understand it - the tel form has more latitute in how it is processed. There can be servers that are familiar with the phone context and can expand it without otherwise being responsible for the domain of the same name. - the tel form doesn't provide any guaranteed way to route it to a server that understands it. - the applicability of the tel form isn't limited to sip. Perhaps they both have their place. But if we are to have interop between phones of one vendor and severs of another, then we must eventually agree on how phones map dial strings to something that servers can process. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 09:19:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20165 for ; Fri, 12 Sep 2003 09:19:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnpN-0004S5-6T for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 09:19:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDJ9hT017096 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 09:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnpG-0004RI-6W; Fri, 12 Sep 2003 09:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnp5-0004Ql-PA for sip@optimus.ietf.org; Fri, 12 Sep 2003 09:18:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20068 for ; Fri, 12 Sep 2003 09:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xnoz-0005z4-00 for sip@ietf.org; Fri, 12 Sep 2003 09:18:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xnoy-0005xq-00 for sip@ietf.org; Fri, 12 Sep 2003 09:18:44 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2003 06:18:13 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8CDI8S6016193; Fri, 12 Sep 2003 06:18:11 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACI35226; Fri, 12 Sep 2003 09:18:07 -0400 (EDT) Message-ID: <3F61C78F.2030907@cisco.com> Date: Fri, 12 Sep 2003 09:18:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Bob Penfield'" , sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5E66@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I agree that user=phone with no "+" and no context in most phones > means that the username is a dial string, and for backwards compatibility, > that's the way we must leave it. Getting rid of user=phone means that there > is no way to distinguish between a dial string and a username that looks > like a dial string. That's bad. If we leave it at that, I won't have > a lot of heartburn. > > I'd prefer to have a more unambiguous designation for a dial string. > I'd prefer a way to distinguish the following from each other: I think we already have it. > A raw dial string For a dial string of 1234, either: tel:1234;phone-context=your-dialplan.foo.bar or sip:1234@dialplan-knowledgable-proxy.foo.bar;user=phone > A real phone number either: tel:+12345678901 or sip:+12345678901@foo.bar;user=phone > The results of an ENUM translation typically, a sip url without user=phone. But more generally any old url usable with sip. This is just like the translation from AOR to contact address - we don't have any way to tell one from the other by inspection, and they aren't disjoint sets. > a numeric username sip:1234@foo.bar > > I also wonder if we shouldn't have a way to distinguish 1-800-BUY-MINE > as a dialable phone number. I presume you mean something other than tel:+1-800-289-6463? How about sip:BUY-MINE@free-call.com? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 10:15:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25541 for ; Fri, 12 Sep 2003 10:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xohg-0000Rp-GA for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 10:15:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CEFGpe001657 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 10:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xohU-0000QC-3P; Fri, 12 Sep 2003 10:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xohE-0000Pq-95 for sip@optimus.ietf.org; Fri, 12 Sep 2003 10:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25436 for ; Fri, 12 Sep 2003 10:14:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xohC-0007Jq-00 for sip@ietf.org; Fri, 12 Sep 2003 10:14:46 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19xohB-0007JP-00 for sip@ietf.org; Fri, 12 Sep 2003 10:14:45 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h8CECjWf014390 for ; Fri, 12 Sep 2003 09:14:15 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3F5B5761001205A4; Fri, 12 Sep 2003 10:12:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 12 Sep 2003 10:14:14 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04E1E445@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN5Lm0IcDhaMS6zR4eNZKRHKo0/iQACJCKw From: "Roy, Radhika R, ALABS" To: "Paul Kyzivat" , "Bob Penfield" Cc: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Inline [RRR] -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, September 12, 2003 9:03 AM To: Bob Penfield Cc: sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone .... Perhaps they both have their place. But if we are to have interop=20 between phones of one vendor and severs of another, then we must=20 eventually agree on how phones map dial strings to something that=20 servers can process. [RRR] I would also think so, even if we have to sacrifice some backward compatibility issues (backward compatibility issues are dragging us too much).=20 [RRR] Which one is of more importance: 1. Global interoperability that is not only required for SIP, but also for all other applications that have been used so long by all of us worldwide, or 2. Backward compatibility that is being used in SIP now in a limited way for some implementations? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 12 20:55:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24069 for ; Fri, 12 Sep 2003 20:55:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xyh6-0001K7-Te for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 20:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8D0tK0G005081 for sip-archive@odin.ietf.org; Fri, 12 Sep 2003 20:55:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xygp-0001JJ-I3; Fri, 12 Sep 2003 20:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xygS-0001Is-5a for sip@optimus.ietf.org; Fri, 12 Sep 2003 20:54:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24045 for ; Fri, 12 Sep 2003 20:54:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xygP-0000Ax-00 for sip@ietf.org; Fri, 12 Sep 2003 20:54:37 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19xygP-0000Aj-00 for sip@ietf.org; Fri, 12 Sep 2003 20:54:37 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8D0rtH21053; Fri, 12 Sep 2003 19:53:55 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 17:53:56 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AE34CAC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Paul Kyzivat'" , "'Rosen, Brian'" Cc: "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 12 Sep 2003 17:53:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37991.822AA9DE" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37991.822AA9DE Content-Type: text/plain > For a dial string of 1234, either: > tel:1234;phone-context=your-dialplan.foo.bar > or > sip:1234@dialplan-knowledgable-proxy.foo.bar;user=phone Your sip URI has the problem that you need one DNS entry for each dialling plan. If an Enterprise has different dialling plan per region (like they do), then the dialplan-knowledgeable proxy needs to figure out which dialling plan should apply based on some criteria such as the source of the original message or black magic, correlated with some database. This is pretty messy. Also, it still seems to me that the "user=phone" is taken by most people to mean that the SIP URI is constructed from a tel URI using the RFC3261/19.1.6. Applying the rules of RFC3261/19.1.6 instead, we'd get: sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone Which (like the tel URI) specifically identifies the dialing plan and does not require one DNS entry per dialling plan. ------_=_NextPart_001_01C37991.822AA9DE Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

> For a dial string of 1234, either:
>       tel:1234;phone-context=your-dialplan.foo.bar
>    or
>       sip:1234@dialplan-knowledgable-proxy.foo.bar;user=phone

Your sip URI has the problem that you need one DNS entry for each
dialling plan. If an Enterprise has different dialling plan per
region (like they do), then the dialplan-knowledgeable proxy needs
to figure out which dialling plan should apply based on
some criteria such as the source of the original message or black
magic, correlated with some database. This is pretty messy.

Also, it still seems to me that the "user=phone" is taken by most
people to mean that the SIP URI is constructed from a tel URI using
the RFC3261/19.1.6.

Applying the rules of RFC3261/19.1.6 instead, we'd get:

        sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone

Which (like the tel URI) specifically identifies the dialing plan and does
not require one DNS entry per dialling plan.

------_=_NextPart_001_01C37991.822AA9DE-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 10:00:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29834 for ; Mon, 15 Sep 2003 10:00:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yttv-0004Ca-O7 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 10:00:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FE0NWS016150 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 10:00:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytta-00049n-Tt; Mon, 15 Sep 2003 10:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytsb-00042y-4C for sip@optimus.ietf.org; Mon, 15 Sep 2003 09:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29658 for ; Mon, 15 Sep 2003 09:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytsY-0001QC-00 for sip@ietf.org; Mon, 15 Sep 2003 09:58:58 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ytsY-0001Mx-00 for sip@ietf.org; Mon, 15 Sep 2003 09:58:58 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2003 06:58:27 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8FDwOS4004425; Mon, 15 Sep 2003 06:58:24 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACJ86340; Mon, 15 Sep 2003 09:58:22 -0400 (EDT) Message-ID: <3F65C57E.8070608@cisco.com> Date: Mon, 15 Sep 2003 09:58:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Rosen, Brian'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <2F1FC1DEA077D5119FAD00508BCFD6D20AE34CAC@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Francois Audet wrote: > > For a dial string of 1234, either: > > tel:1234;phone-context=your-dialplan.foo.bar > > or > > sip:1234@dialplan-knowledgable-proxy.foo.bar;user=phone > > Your sip URI has the problem that you need one DNS entry for each > dialling plan. I agree. The answer to this is "if it hurts, don't do it". In other words, I think that approach only makes sense when the dialplans line up with the proxies you are willing to configure. > If an Enterprise has different dialling plan per > region (like they do), then the dialplan-knowledgeable proxy needs > to figure out which dialling plan should apply based on > some criteria such as the source of the original message or black > magic, correlated with some database. This is pretty messy. Again I agree. The whole point here is to ensure that the url itself is context-free. In my opinion, if the proxy needs to apply context from other parts of the message in order to expand the number, then this is an invalid usage. > Also, it still seems to me that the "user=phone" is taken by most > people to mean that the SIP URI is constructed from a tel URI using > the RFC3261/19.1.6. I'm not sure about the "most" part. Some do, some don't. As spec is currently written, the equivalence between tel and sip/user=phone is only one way. (IF the userpart comes from a tel, then there SHOULD be a user=phone, but the presence of user=phone does not imply the userpart conforms to tel.) I personally am happy with the more strict interpretation. But I am trying to hold out an olive branch in order to reach a level of agreement. > Applying the rules of RFC3261/19.1.6 instead, we'd get: > > sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > > Which (like the tel URI) specifically identifies the dialing plan and does > not require one DNS entry per dialling plan. I agree that this is also a fine usage. But what is benefit of this over using the tel format and then passing the request to sip:foo.bar? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 12:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09753 for ; Mon, 15 Sep 2003 12:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvxS-0003xi-JF for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 12:12:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FGCAgN015226 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 12:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvxK-0003wi-PM; Mon, 15 Sep 2003 12:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvws-0003tg-Dx for sip@optimus.ietf.org; Mon, 15 Sep 2003 12:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09690 for ; Mon, 15 Sep 2003 12:11:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yvwr-0006sR-00 for sip@ietf.org; Mon, 15 Sep 2003 12:11:33 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19yvwq-0006pP-00 for sip@ietf.org; Mon, 15 Sep 2003 12:11:32 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8FGAFa19403; Mon, 15 Sep 2003 11:10:15 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 09:10:15 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AE35320@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Paul Kyzivat'" Cc: "'Rosen, Brian'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 09:10:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37BA3.D73284A6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37BA3.D73284A6 Content-Type: text/plain > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, September 15, 2003 06:58 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone [ stuff deleted as it looks like we are in agreement ] > I'm not sure about the "most" part. Some do, some don't. As spec is > currently written, the equivalence between tel and sip/user=phone is > only one way. (IF the userpart comes from a tel, then there > SHOULD be a > user=phone, but the presence of user=phone does not imply the > userpart > conforms to tel.) > > I personally am happy with the more strict interpretation. But I am > trying to hold out an olive branch in order to reach a level > of agreement. OK. It seems that we are in agreement. My suggestion is to ask the question to the group of is anybody objects to make it explicit that user=phones means that the sip URI is derived from a tel URI? If the answer is no, then I think we can probably finally put this issue to rest. Otherwise, we need to rework the whole thing... So... Does anybody strongly object to explicitly making the user=phone atttribute mean that the SIP URI was derived from a tel URI? > > Applying the rules of RFC3261/19.1.6 instead, we'd get: > > > > > > sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > > > > Which (like the tel URI) specifically identifies the > dialing plan and > > does not require one DNS entry per dialling plan. > > > I agree that this is also a fine usage. > > But what is benefit of this over using the tel format and > then passing > the request to sip:foo.bar? The tel URI format assumes that the proxy knows which proxy is aware of the phone context and tel URIs (it could be itself, or it could know which proxy to route sessions to). The sip URI format lets you route it to a specific proxy that is aware of the phone context, potentially with "generic" SIP proxies in between that have no idea how to route based on phone contextes (or even tel URIs). T They both have merits. ------_=_NextPart_001_01C37BA3.D73284A6 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, September 15, 2003 06:58
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org'
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone

[ stuff deleted as it looks like we are in agreement ]

> I'm not sure about the "most" part. Some do, some don't. As spec is
> currently written, the equivalence between tel and sip/user=phone is
> only one way. (IF the userpart comes from a tel, then there
> SHOULD be a
> user=phone, but the presence of user=phone does not imply the
> userpart
> conforms to tel.)
>
> I personally am happy with the more strict interpretation. But I am
> trying to hold out an olive branch in order to reach a level
> of agreement.

OK. It seems that we are in agreement.

My suggestion is to ask the question to the group of is anybody
objects to make it explicit that user=phones means that the sip URI is derived
from a tel URI?

If the answer is no, then I think we can probably finally put this issue
to rest. Otherwise, we need to rework the whole thing...

So... Does anybody strongly object to explicitly making the user=phone
atttribute mean that the SIP URI was derived from a tel URI?

> > Applying the rules of RFC3261/19.1.6 instead, we'd get:
> >
> >        
> > sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone
> >
> > Which (like the tel URI) specifically identifies the
> dialing plan and
> > does not require one DNS entry per dialling plan.
>
>
> I agree that this is also a fine usage.
>
> But what is benefit of this over using the tel format and
> then passing
> the request to sip:foo.bar?

The tel URI format assumes that the proxy knows which proxy is aware of the phone context
and tel URIs (it could be itself, or it could know which proxy to route sessions to). 

The sip URI format lets you route it to a specific proxy that is aware of the phone
context, potentially with "generic" SIP proxies in between that have no idea how to route
based on phone contextes (or even tel URIs). T


They both have merits.

------_=_NextPart_001_01C37BA3.D73284A6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 13:25:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13789 for ; Mon, 15 Sep 2003 13:25:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yx65-0001AT-D9 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 13:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FHP96B004483 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 13:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yx5z-00019k-5F; Mon, 15 Sep 2003 13:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yx5M-00018V-5H for sip@optimus.ietf.org; Mon, 15 Sep 2003 13:24:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13726 for ; Mon, 15 Sep 2003 13:24:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yx5K-0002TW-00 for sip@ietf.org; Mon, 15 Sep 2003 13:24:22 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19yx5J-0002SS-00 for sip@ietf.org; Mon, 15 Sep 2003 13:24:21 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19271; Mon, 15 Sep 2003 13:23:49 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19088; Mon, 15 Sep 2003 13:23:50 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 13:23:50 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E7A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Francois Audet'" , "'Paul Kyzivat'" Cc: "Rosen, Brian" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 13:23:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Well this goes to the issue Paul and I have disagreed on. I think the wording of the tel uri RFC is quite clear that you can't pass a dial string in one. You certainly can't pass one with star and pound. Therefore, I claim, there is no way to pass a dial string, unless you put it in a username on a SIP uri, and denote that it is a dial string, for which a phone number is a proper subset for most dial plans, by specifying user=phone. Paul disagrees. He thinks he can send a dial string in a tel uri. Without some kind of resolution of that issue, we have a problem. Brian -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Monday, September 15, 2003 12:10 PM To: 'Paul Kyzivat' Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, September 15, 2003 06:58 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone [ stuff deleted as it looks like we are in agreement ] > I'm not sure about the "most" part. Some do, some don't. As spec is > currently written, the equivalence between tel and sip/user=phone is > only one way. (IF the userpart comes from a tel, then there > SHOULD be a > user=phone, but the presence of user=phone does not imply the > userpart > conforms to tel.) > > I personally am happy with the more strict interpretation. But I am > trying to hold out an olive branch in order to reach a level > of agreement. OK. It seems that we are in agreement. My suggestion is to ask the question to the group of is anybody objects to make it explicit that user=phones means that the sip URI is derived from a tel URI? If the answer is no, then I think we can probably finally put this issue to rest. Otherwise, we need to rework the whole thing... So... Does anybody strongly object to explicitly making the user=phone atttribute mean that the SIP URI was derived from a tel URI? > > Applying the rules of RFC3261/19.1.6 instead, we'd get: > > > > > > sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > > > > Which (like the tel URI) specifically identifies the > dialing plan and > > does not require one DNS entry per dialling plan. > > > I agree that this is also a fine usage. > > But what is benefit of this over using the tel format and > then passing > the request to sip:foo.bar? The tel URI format assumes that the proxy knows which proxy is aware of the phone context and tel URIs (it could be itself, or it could know which proxy to route sessions to). The sip URI format lets you route it to a specific proxy that is aware of the phone context, potentially with "generic" SIP proxies in between that have no idea how to route based on phone contextes (or even tel URIs). T They both have merits. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 14:23:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16924 for ; Mon, 15 Sep 2003 14:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yy0C-00047S-M4 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 14:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FIN8WA015833 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 14:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yy06-00046u-4d; Mon, 15 Sep 2003 14:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yxzE-000469-LL for sip@optimus.ietf.org; Mon, 15 Sep 2003 14:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16888 for ; Mon, 15 Sep 2003 14:22:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yxzB-0003eL-00 for sip@ietf.org; Mon, 15 Sep 2003 14:22:06 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19yxzB-0003dq-00 for sip@ietf.org; Mon, 15 Sep 2003 14:22:05 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8FILNa27197; Mon, 15 Sep 2003 13:21:23 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 11:21:24 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AE357E7@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rosen, Brian'" , "'Paul Kyzivat'" Cc: "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 11:21:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37BB6.2A939448" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37BB6.2A939448 Content-Type: text/plain > Well this goes to the issue Paul and I have disagreed on. > > I think the wording of the tel uri RFC is quite clear that > you can't pass a dial string in one. You certainly can't > pass one with > star and pound. Therefore, I claim, there is no way to pass > a dial string, unless you put it in a username on a SIP uri, > and denote that it is a dial string, for which a phone number > is a proper subset for most dial plans, by specifying user=phone. > > Paul disagrees. He thinks he can send a dial string in a tel > uri. Without some kind of resolution of that issue, we have a problem. Let's not be too hung up on terminology. Yes indeed, a pure "dial string" shall not be included in a SIP URI (especially the pound and star). However, it is valid to have a "number" in a tel URI who's format is valid only under a specific context. That context could happen to be closely linked to a "dialing plan", including the "6" prefix in an enterprise, or the "00", "01" in a carrier network. I'm not sure we can call this a "dial string" per se as there will be some sort of minimal processing done by the phone anyways (including removing the star and pound). ------_=_NextPart_001_01C37BB6.2A939448 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

> Well this goes to the issue Paul and I have disagreed on.
>
> I think the wording of the tel uri RFC is quite clear that
> you can't pass a dial string in one.  You certainly can't
> pass one with
> star and pound.   Therefore, I claim, there is no way to pass
> a dial string, unless you put it in a username on a SIP uri,
> and denote that it is a dial string, for which a phone number
> is a proper subset for most dial plans, by specifying user=phone.
>
> Paul disagrees.  He thinks he can send a dial string in a tel
> uri. Without some kind of resolution of that issue, we have a problem.

Let's not be too hung up on terminology. Yes indeed, a pure "dial string" shall
not be included in a SIP URI (especially the pound and star).

However, it is valid to have a "number" in a tel URI who's format is
valid only under a specific context. That context could happen to be closely
linked to a "dialing plan", including the "6" prefix in an enterprise, or
the "00", "01" in a carrier network. I'm not sure we can call this a
"dial string" per se as there will be some sort of minimal processing done
by the phone anyways (including removing the star and pound).

------_=_NextPart_001_01C37BB6.2A939448-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 14:43:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18615 for ; Mon, 15 Sep 2003 14:43:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyJb-0005MW-Le for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 14:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FIhB5c020552 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 14:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyJS-0005Kq-G4; Mon, 15 Sep 2003 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyIY-0005JX-Rv for sip@optimus.ietf.org; Mon, 15 Sep 2003 14:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18522 for ; Mon, 15 Sep 2003 14:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyIV-0004AG-00 for sip@ietf.org; Mon, 15 Sep 2003 14:42:04 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19yyIV-00048q-00 for sip@ietf.org; Mon, 15 Sep 2003 14:42:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22078; Mon, 15 Sep 2003 14:40:58 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29603; Mon, 15 Sep 2003 14:40:58 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 14:40:58 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5E82@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Francois Audet'" Cc: "'Bob Penfield'" , "'Paul Kyzivat'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 14:40:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm sorry, but when the draft says: "Dial strings are beyond the scope of this document." to me, means dial string is not legal in a tel uri. The text describes a dial string the way you (and I) interpret one: Dial string: "Dial strings" are the actual numbers, symbols and pauses entered by a user to place a phone call. A dial- string is consumed by one or more network entities, and understood in the context of the configuration of these entities. It says that it's not in scope. We can create a new RFC that extends this one, but at the moment, you cannot put a dial string in a tel uri. Specifications are all about "terminology". We usually don't create gray areas on purpose -- well, maybe sometimes we do :( It's necessary to have a way to send a dial string that has pound, star and commas (or p/w, which is what 2543 did), which is not allowed in a tel uri. Dial strings are interpretted into something else. That is a phone number, and might need some other processing. You can send what a dial string translates into in a tel uri. We have to have a way to denote that which is not a phone number, but is a dial string. That is what user=phone could do. Brian -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Monday, September 15, 2003 2:21 PM To: 'Rosen, Brian'; 'Paul Kyzivat' Cc: 'Bob Penfield'; 'sip@ietf.org' Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > Well this goes to the issue Paul and I have disagreed on. > > I think the wording of the tel uri RFC is quite clear that > you can't pass a dial string in one. You certainly can't > pass one with > star and pound. Therefore, I claim, there is no way to pass > a dial string, unless you put it in a username on a SIP uri, > and denote that it is a dial string, for which a phone number > is a proper subset for most dial plans, by specifying user=phone. > > Paul disagrees. He thinks he can send a dial string in a tel > uri. Without some kind of resolution of that issue, we have a problem. Let's not be too hung up on terminology. Yes indeed, a pure "dial string" shall not be included in a SIP URI (especially the pound and star). However, it is valid to have a "number" in a tel URI who's format is valid only under a specific context. That context could happen to be closely linked to a "dialing plan", including the "6" prefix in an enterprise, or the "00", "01" in a carrier network. I'm not sure we can call this a "dial string" per se as there will be some sort of minimal processing done by the phone anyways (including removing the star and pound). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 15:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20342 for ; Mon, 15 Sep 2003 15:08:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyho-0006w4-Ad for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 15:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJ8Bj9026598 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 15:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyhf-0006uU-2y; Mon, 15 Sep 2003 15:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyhL-0006pj-Vw for sip@optimus.ietf.org; Mon, 15 Sep 2003 15:07:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20215 for ; Mon, 15 Sep 2003 15:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyhI-0004gY-00 for sip@ietf.org; Mon, 15 Sep 2003 15:07:40 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19yyhI-0004g7-00 for sip@ietf.org; Mon, 15 Sep 2003 15:07:40 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8FJ6wa14714; Mon, 15 Sep 2003 14:06:58 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 12:06:59 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20AE35981@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rosen, Brian'" Cc: "'Bob Penfield'" , "'Paul Kyzivat'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 12:06:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37BBC.85CD49FC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37BBC.85CD49FC Content-Type: text/plain > I'm sorry, but when the draft says: > "Dial strings are beyond the scope of this document." > to me, means dial string is not legal in a tel uri. > > The text describes a dial string the way you (and I) interpret one: > Dial string: "Dial strings" are the actual numbers, symbols and > pauses entered by a user to place a phone call. A dial- > string is consumed by one or more network entities, and > understood in the context of the configuration of these > entities. > It says that it's not in scope. > We can create a new RFC that extends this one, but at the moment, > you cannot put a dial string in a tel uri. > > Specifications are all about "terminology". We usually > don't create gray areas on purpose -- well, maybe sometimes we do :( > > It's necessary to have a way to send a dial string > that has pound, star and commas (or p/w, which is what > 2543 did), which is not allowed in a tel uri. > > Dial strings are interpretted into something else. > That is a phone number, and might need some other processing. > You can send what a dial string translates into in a tel uri. > We have to have a way to denote that which is not a phone > number, but is a dial string. That is what user=phone could do. No, that's not what "user=phone" does. The spec says that if you map a tel URI into a sip URI, then you must put the "user=phone" attribute. So if the tel URI was, say sip:+1-408-555-1212, then it is clearly not a dial string. There are numerous example of this in RFC3261/19.1.6 (i.e., of E.164 numbers in sip URIs with user=phone). Also, on RFC3261/page 150, it says If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Recall that "telephone-subscriber" is defined in 2806-bis for the Tel URI. (Note also that it doesn't say that user=phone can't be used for other purposes, which is what I would like to change, otherwise it is basically useless). Conclusion is that the "user=phone" can NOT mean "dial string". Paul and I are saying that we don't need to send dial digits in a SIP or Tel URI, because of the Tel URI's ability to associate a local phone context is sufficient. I don't see a need for sending "pauses", "pound" and "stars" as part of a number, and argue they should be chewed by the phones. The local context can handle the cases where you don't want to do much parsing of the numbering plan in the phone itself. If you think that it is required to support pauses, pound & star in SIP, then we would have to add it to the spec with a new mechanism. I'm personally not much in favor of that, but it would be good to see if there is much support in the group. ------_=_NextPart_001_01C37BBC.85CD49FC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] SIPIT Interop problem with ;user=3Dphone

> I'm sorry, but when the draft says:
> "Dial strings are beyond the scope of this = document."
> to me, means dial string is not legal in a tel = uri.
>
> The text describes a dial string the way you = (and I) interpret one: 
>  Dial string: "Dial strings" are = the actual numbers, symbols and
>          = ;    pauses entered by a user to place a phone call. A = dial-
>          = ;    string is consumed by one or more network entities, = and
>          = ;    understood in the context of the configuration of = these
>          = ;    entities.
> It says that it's not in scope. 
> We can create a new RFC that extends this one, = but at the moment,
> you cannot put a dial string in a tel = uri. 
>
> Specifications are all about = "terminology".  We usually
> don't create gray areas on purpose -- well, = maybe sometimes we do :(
>
> It's necessary to have a way to send a dial = string
> that has pound, star and commas (or p/w, which = is what
> 2543 did), which is not allowed in a tel = uri.
>
> Dial strings are interpretted into something = else.
> That is a phone number, and might need some = other processing.
> You can send what a dial string translates into = in a tel uri.
> We have to have a way to denote that which is = not a phone
> number, but is a dial string.  That is = what user=3Dphone could do.

No, that's not what "user=3Dphone" does. = The spec says that if you
map a tel URI into a sip URI, then you must put the = "user=3Dphone"
attribute. So if the tel URI was, say = sip:+1-408-555-1212, then
it is clearly not a dial string. There are numerous = example of this
in RFC3261/19.1.6 (i.e., of E.164 numbers in sip = URIs with user=3Dphone).

Also, on RFC3261/page 150, it says
        If the = user string contains a telephone number formatted as a
        telephone-subscriber, the user parameter value = "phone" SHOULD
        be = present.

Recall that "telephone-subscriber" is = defined in 2806-bis for the Tel URI.

(Note also that it doesn't say that user=3Dphone = can't be used for other
purposes, which is what I would like to change, = otherwise it is basically
useless).

Conclusion is that the "user=3Dphone" can = NOT mean "dial string".

Paul and I are saying that we don't need to send dial = digits in a SIP
or Tel URI, because of the Tel URI's ability to = associate a local phone context
is sufficient. I don't see a need for sending = "pauses", "pound" and "stars"
as part of a number, and argue they should be chewed = by the phones.
The local context can handle the cases where you = don't want to do
much parsing of the numbering plan in the phone = itself.

If you think that it is required to support pauses, = pound & star in SIP,
then we would have to add it to the spec with a new = mechanism. I'm personally
not much in favor of that, but it would be good to = see if there is much
support in the group.




------_=_NextPart_001_01C37BBC.85CD49FC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 19:36:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02207 for ; Mon, 15 Sep 2003 19:36:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2tH-0001oB-2P for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNaIBa006866 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2t2-0001gQ-HW; Mon, 15 Sep 2003 19:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2s4-0001e6-Bv for sip@optimus.ietf.org; Mon, 15 Sep 2003 19:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02108 for ; Mon, 15 Sep 2003 19:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z2s2-00007c-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19z2s0-00006w-01 for sip@ietf.org; Mon, 15 Sep 2003 19:35:01 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8FNYqqP002945; Mon, 15 Sep 2003 16:34:52 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO94688; Mon, 15 Sep 2003 16:23:03 -0700 (PDT) Date: Fri, 12 Sep 2003 11:18:16 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Adam Roach , "'Rosen, Brian'" , sip@ietf.org To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F551306.1000007@cisco.com> Message-Id: <7AEF8EDE-E54D-11D7-9721-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with all of Paul's comments except one inline... On Tuesday, September 2, 2003, at 03:00 PM, Paul Kyzivat wrote: > Adam Roach wrote: > > > > It used to be that you could do the same in a tel uri, but we > > > "fixed" that. > > > > ...meaning that, if we were to do nothing but rev 3261 with > > updated references, using bare, unscoped digit strings with > > "user=phone" would automatically become deprecated. > > How did we break it? Even in 2806 a uri like was illegal - > it required a phone-context parameter. > > AFAIK, the wording in 2543 and all its successors has always suggested > that IF you transform from tel to sip you should add user=phone. But > they have never stated the converse - that if you have a uri of form > then the nnn should conform to 2806. > > As a result, normal dial strings have been representable as sip uris > *without* user=phone. > > Meanwhile, on this discussion as a whole, I think the real problem is > when the UAC has a dial string and doesn't know the dial plan itself. > The suggestion seems to be to patch it into a sip url and let some > proxy fix it. For instance, maybe I dial 1234, and my UAC turns this > into > > INVITE sip:1234@myproxy.com > To: sip:1234@myproxy.com > ... > > Then maybe myproxy turns this into: > > INVITE: sip:+19785551234@otherproxy.com;user=phone > To: sip:1234@myproxy.com > > and maybe that becomes: > > INVITE: sip:you@yourphone.com > To: sip:1234@myproxy.com > > So things have worked - the call got where it should go. > > BUT, sometimes the UAS might care where the call was originally > addressed. For instance it might want to recognize when it has > received redirected calls (calls not addressed "To" it) and do the > alerting in a different manner. > > Trouble is, done this way the To address is meaningless to anyone > except the caller. Unless you know the dialplan of the caller it is > just junk. Worse, it might even disclose information about you that > you might not want disclosed - like whether you have a speed dial > number defined for this number. > > The obvious solution to this is for the dial plan to be implemented in > the UAC. Then the result of expanding the number via the dialplan can > be included in both the To and request uris. > > If the UAC is too feeble to do that, then ideally the UAC would have > its local proxy do the expansion and then use that in both the To and > request URIs. Having the proxy return the translation in a 3xx is > almost the right thing. There are two issues with that: > > - how does proxy know to return 3xx rather than proxy? > This is solvable via Request-Disposition from callerprefs. > > - how does the UAC know to replace both the request uri AND the To uri? > This is a problem - normally on a 3xx the To should not be changed. > Maybe a solution would be to define a new 3xx code that means > exactly this. > > Regarding usefulness of user=phone: > > I agree it is largely a matter of whether you think there can be a > conflict between "regular" usernames and telephone numbers or dial > strings. > > This doesn't seem to be too much of a problem with 2806 conformant > numbers, because they either start with + or contain ";phone-context". > But it could be a problem for arbitrary dial strings. Remember that > phone numbers (and presumably dial strings) are permitted to contain > more than just digits. They can contain ".-()*#ABCDpw". So things like > "BAD", "A-DABA" or "A.B.C.D" might be valid dial strings. I am not > comfortable saying that nothing that might be a valid dial string can > be assigned as a valid username. > > The best solution to me is for the UAC to be configured to always turn > dial strings into some kind of valid telephone-subscriber string. If > it can't turn it into a global-phone-number, then it should turn it > into a local-phone-number, using some configured phone-context. When > there is no better solution, it can simply paste a phone-context onto > the end of the dial string. > > Once this is done, it must turn this into a URL. It can make a tel: > url trivially. Or it can make a sip or sips url with user=phone by > supplying a configured domain name. Of these, I prefer tel, because > using sip doesn't seem to add anything and it further constrains where > and how transformations can be made. (Phone-context in a tel can be > translated by anybody that understands it, but in a sip url can only > be translated by a server that is responsible for the domain.) While I do not object to sending tel URIs to SIP proxies, I believe I already articulated some reasons why you might want to use sip or sips instead. 1) want to use SIPS 2) want to route the call to a specific domain that is not the domain of your first hop proxy. 3) want to invoke a loose router for services like transcoding or call history logging that have different tel URI handling rules than you want to use. thanks, -r > Proxies that want to can still handle dial strings in sip urls without > user=phone for backward compatibility with old phones. But as long as > they do there will be the possibility of conflict with usernames. They > could always limit this problem by restricting the kinds of dial > strings they will accept. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 19:36:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02220 for ; Mon, 15 Sep 2003 19:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2tH-0001oC-2l for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNaIMc006861 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2t8-0001jo-88; Mon, 15 Sep 2003 19:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2sA-0001eS-Lw for sip@optimus.ietf.org; Mon, 15 Sep 2003 19:35:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02117 for ; Mon, 15 Sep 2003 19:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z2s8-00007r-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19z2s8-000072-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:08 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2003 16:49:02 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8FNYaqP002715; Mon, 15 Sep 2003 16:34:37 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO94653; Mon, 15 Sep 2003 16:22:44 -0700 (PDT) Date: Fri, 12 Sep 2003 10:12:13 -0700 Subject: Re: [Sip] Question regarding correct SIP behaviour in unregistration Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , =?ISO-8859-1?Q?Attila_Petr=F3czi_=28E-mail=29?= , "Gabor Feher (E-mail)" To: =?ISO-8859-1?Q?Szel=E9nyi_Csaba?= From: Rohan Mahy In-Reply-To: <29026DD9543DBF4BB2B4F9325683E47A0D5C2D@MAILSRV.uns.t-systems.tss> Message-Id: <408B8AB8-E544-11D7-9721-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Friday, September 5, 2003, at 01:39 AM, Szel=E9nyi Csaba wrote: > Hello, > > I am sorry about cross-posting this mail to the lists SIP, SIP Forum=20= > Discussion and SIP CTWG. I could not decide, which forum is or which=20= > forums are appropriate to be addressed with these questions. if you are not sure which list to post to, feel free to email the=20 chairs or moderators individually and ask. alternatively it is better=20= to pick *one* list (even if it the wrong one), as your request will=20 probably be referred to the correct list anyway. the correct list for these questions is actually=20 sip-implementors@cs.columbia.edu > Q1: IMHO RFC 3261 Section 10.3 Item 6 does not cover a case: what is=20= > the right behaviour of the Registrar on receipt an unregistration=20 > request for bindings that cannot be found in its database? I think of a REGISTER request with Expires: 0 meaning "make sure there=20= is no registration for this AOR with this contact". If the AOR exist=20 then the correct behavior is to send a 200-class response. If the AOR=20= does not exist, then a 404 is appropriate. thanks, -rohan > 6. The registrar checks whether the request contains the Contact > header field. If not, it skips to the last step. If the > Contact header field is present, the registrar checks if = there > is one Contact field value that contains the special value = "*" > and an Expires field. If the request has additional Contact > fields or an expiration time other than zero, the request is > invalid, and the server MUST return a 400 (Invalid Request)=20= > and > skip the remaining steps. If not, the registrar checks=20 > whether > the Call-ID agrees with the value stored for each binding. = If > not, it MUST remove the binding. If it does agree, it MUST > remove the binding only if the CSeq in the request is higher > than the value stored for that binding. Otherwise, the = update > MUST be aborted and the request fails. > > When no binding is registered for the specified AOR, upon receiving a=20= > REGISTER request with Expires header field value of zero and Contact=20= > header field value set to '*' (i.e. there is no binding to be removed=20= > for the given AOR, therefore the Registrar is unable to check the=20 > Call-ID), what response must/should be sent? Is a '404 Not Found'=20 > response or a '200 OK' response appropriate? > > Q2: Similarly to Q1, what would be the right response ('404 Not Found'=20= > or '200 OK') for unregistration requests, if the binding requested for=20= > removal already expired? The binding may exist in the database for a=20= > short time after expiration, as we have seen it checking some=20 > implementations. If the record of the binding has been removed, we get=20= > beck to Q1. > > Would it be a possible answer to the questions, that it is not=20 > regulated by RFC 3261, therefore it is up to the implementation, what=20= > to do? > > Any help, URL or reference would be highly appreciated. > > Thank you in anticipation, > > Szelenyi Csaba > T-Systems RIC > mailto:Csaba.Szelenyi@t-systems.co.hu > +36 1 456 5507 > +36 20 477 7778 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 19:36:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02230 for ; Mon, 15 Sep 2003 19:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2tH-0001o9-1y for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNaIj0006862 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2t1-0001fa-96; Mon, 15 Sep 2003 19:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2s2-0001e1-N6 for sip@optimus.ietf.org; Mon, 15 Sep 2003 19:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02105 for ; Mon, 15 Sep 2003 19:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z2s0-00007V-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19z2s0-00006w-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:00 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8FNYkfX016575; Mon, 15 Sep 2003 16:34:46 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO94677; Mon, 15 Sep 2003 16:22:58 -0700 (PDT) Date: Fri, 12 Sep 2003 10:53:29 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Dean Willis , hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, fluffy@cisco.com, sip@ietf.org To: Henning Schulzrinne From: Rohan Mahy In-Reply-To: <3F4EA5EC.9090203@cs.columbia.edu> Message-Id: <049A27E5-E54A-11D7-9721-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Uhhh? Your statement is inconsistent with my recollection of the grammar. Were you specifically referring to the "w"? Can you elaborate please? thanks, -rohan On Thursday, August 28, 2003, at 06:01 PM, Henning Schulzrinne wrote: > Dean Willis wrote: > > >> Citing an example inf RFC 2806: >> tel:0w003585551234567;phone-context=+3585551234 >> This URL places a voice call to the given number. The number format >> is intended for local use: the first zero opens an outside line, >> the >> "w" character waits for a second dial tone, and the number already >> has the international access code appended to it ("00"). This kind >> of >> phone number MUST NOT be used in an environment where all users of >> this URL might not be able to successfully dial out by using this >> number directly. However, this might be appropriate for pages in a >> company intranet. The which is present hints that >> the number is usable only in an environment where the local >> entity's >> phone number starts with the given string (perhaps singling out a >> company-wide block of telephone numbers). > > Note that 2806bis will explicitly disallow this type of dial string > (0w00358...). Thus, this will not be a valid tel URI in the future. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 20:22:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02216 for ; Mon, 15 Sep 2003 19:36:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2tH-0001o8-1h for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNaIDe006865 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2t4-0001hP-Ua; Mon, 15 Sep 2003 19:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2s6-0001eI-1h for sip@optimus.ietf.org; Mon, 15 Sep 2003 19:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02114 for ; Mon, 15 Sep 2003 19:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z2s4-00007k-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19z2s3-000071-01 for sip@ietf.org; Mon, 15 Sep 2003 19:35:03 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2003 16:34:44 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8FNYgqP002794; Mon, 15 Sep 2003 16:34:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO94666; Mon, 15 Sep 2003 16:22:53 -0700 (PDT) Date: Fri, 12 Sep 2003 10:31:08 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: hisham.khartabil@nokia.com, sip@ietf.org To: Dean Willis From: Rohan Mahy In-Reply-To: <3F58C41C.9040105@softarmor.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, September 5, 2003, at 10:13 AM, Dean Willis wrote: > hisham.khartabil@nokia.com wrote: >>> sip:12345@foo.bar is sip:12345@foo.bar (surprise, surprise) >> >> You cannot make that conclusion. I belong to operator1.com that gave >> me this number 12345 as my telephone number. You are with operator2 >> and they gave you the sip address 12345@operator2.com >> >> Now, someone, not you, from operator2.com (your operator) wants to >> call me. They dial 12345. Using your logic, your phone ends up >> ringing instead of mine. >> > > Well, I think we know how to tell 12345@operator1.com from > 12345@operator2.com, with or without user=phone. > > There's certainly no particular reason that the operator1.com proxy > should know to forward 12345@operator1.com;user=phone to > 12345@operator2.com, One COULD manually configure that sort of rule, > but it seems likely to break the universe if you tried to do it for > ever possible phone number. > > You're asking "If @operator1.com is the default domain, how do I dial > something @operator2.com"? The answer is -- the user has to enter that > part, somehow. If your email client adds @nokia.com to outgoing email > that doesn't specify a domain, and you send an email to "dean.willis", > I imagine that the nokia email sever is likely to reject it -- unless > they've decided to offer me enough money to defect and I haven't found > out yet (I'm easy, but not cheap). > > What I think you WANT to be asking is "How does a user entering a > short-form request indicate whether he wants it treated as a phone > number (looked up in ENUM or sent to a PSTN gateway) or treated as a > SIP username?" > > I don't have an answer for that. None of the phones I use seem to have > a mechanism for entering this distinction. One mechanism would be to use a list of regular expressions, or more specifically, a locally-configured dialplan of some sort. Many IP phone vendors have this feature. For example (as an existence proof only): http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ ipp7960/addprot/sip/admin/ver5_1/sipins44.htm#1047995 I would have included references to other vendors as well, but I am on an airplane now.... thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 20:22:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02229 for ; Mon, 15 Sep 2003 19:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2tH-0001oA-2C for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNaIA5006867 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 19:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2t6-0001hu-Ct; Mon, 15 Sep 2003 19:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z2sB-0001eV-Ak for sip@optimus.ietf.org; Mon, 15 Sep 2003 19:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02120 for ; Mon, 15 Sep 2003 19:35:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z2s9-00007w-00 for sip@ietf.org; Mon, 15 Sep 2003 19:35:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19z2s8-000072-01 for sip@ietf.org; Mon, 15 Sep 2003 19:35:08 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 15 Sep 2003 16:49:16 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8FNYnBo020507; Mon, 15 Sep 2003 16:34:50 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO94678; Mon, 15 Sep 2003 16:22:59 -0700 (PDT) Date: Fri, 12 Sep 2003 11:10:20 -0700 Subject: Re: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=UTF-8; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'hisham.khartabil@nokia.com'" , Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com, sip@ietf.org To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5DA4@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <5F0286ED-E54C-11D7-9721-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Tuesday, September 2, 2003, at 06:38 AM, Rosen, Brian wrote: > Getting more and more confused. > > A "dial string" cannot go in a tel uri. > It can go in the user part of a sip uri. I believe that every dial string is a special case of a local number=20 which can be expressed as a tel URI with the appropriate phone context. > So, if a sip UA does not have the ability to automatically > translate dial strings to routable telephone numbers, it has > to be in a sip uri user part. I don't think that is > controversial. No, this is still very controversial. > The question is, does the UA need to mark the user part as > a dial string, or is it enough for the host mentioned in the > domain part of the sip uri to just know the difference? > I'd prefer to mark the userpart as a dial string, but I can > cope if we don't. I would like to use the convention ;user=3Dphone to indicate that the=20 contents of the userpart can be interpreted (only by a host responsible=20= for the domain of the SIP URI) as a valid tel URI. if that host sees a=20= phone-context parameter which it recognizes, then it can interpret that=20= "local number" as appropriate, which IMO includes treating it according=20= to the appropriate dial plan as a "dialed string". I believe that standardizing this convention makes it easier to=20 configure hosts which handle multiple contexts, and easier to configure=20= *senders* that do not understand their own dial plan. (I have no=20 problem with SIP hosts interpreting user parts as phone numbers or=20 dialed strings or email addresses or whatever in a completely locally=20 configured manner when user=3Dip). thus, depending on the level of dial plan awareness configured into a=20 phone in pittsburgh, it might send any of the following URIs sip:0;phone-context=3Dpittsburgh.marconi.com@marconi.com;user=3Dphone sip:0@pittsburgh.marconi.com sip:pittsburgh.operator@marconi.com thanks, -rohan > Brian > >> -----Original Message----- >> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >> Sent: Monday, September 01, 2003 5:21 AM >> To: Richard.Stastny@oefeg.at; fluffy@cisco.com; >> dean.willis@softarmor.com >> Cc: Brian.Rosen@marconi.com; sip@ietf.org >> Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >> >> >> So, the answer in any case is that it is somehow routable. >> Therefore I conclude the allowing a sip URI to carry a dial >> strings is not needed. >> >> /Hisham >> >>> -----Original Message----- >>> From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>> Sent: Monday, September 01, 2003 12:20 PM >>> To: Khartabil Hisham (NMP/Helsinki); fluffy@cisco.com; >>> dean.willis@softarmor.com >>> Cc: Brian.Rosen@marconi.com; sip@ietf.org >>> Subject: AW: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >>> >>> >>> You should not need to route this call anyway, because >>> normally you should >>> not see such a context out of the context. The idea is: if >>> you know the context >>> then you also know how to route the call, if you do not know >>> the context, >>> you just say invalid number. In other contexts only global >>> understandable >>> URIs should be used >>> >>> Richard >>> >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: hisham.khartabil@nokia.com >>> [mailto:hisham.khartabil@nokia.com] >>> Gesendet: Mo 01.09.2003 10:45 >>> An: fluffy@cisco.com; Stastny Richard; >>> dean.willis@softarmor.com >>> Cc: Brian.Rosen@marconi.com; sip@ietf.org >>> Betreff: RE: AW: AW: [Sip] SIPIT Interop problem with >>> ;user=3Dphone >>> =09 >>> =09 >>> >>> So, I'll ask the question again, this time for real: >>> =09 >>> Under the informative text in 2806bis labeled "A Use of >>> "tel" URIs with SIP (Informative)", it says: >>> =09 >>> " >>> 2. The outbound proxy does not use the same phone >>> context, but can route to a proxy >>> that handles this >>> phone context. This routing can be >>> done via a lookup >>> table or the domain name of the phone >>> context might be >>> set up to reflect the SIP domain name >>> of a suitable >>> proxy. For example, a proxy may >>> always route calls >>> with tel URIs like >>> =09 >>> tel:1234;phone-context=3Dmunich.example.com >>> =09 >>> to the SIP proxy located at >>> munich.example.com." >>> =09 >>> =09 >>> So, how does the proxy route this message to >>> munich.example.com? Or how does it discover the proxy at >>> munich.example.com? >>> =09 >>> The reason I'm asking this again is due to my proposal >>> in earlier emails to use a tel URI for dial strings and sip >>> URI for pure sip users. >>> =09 >>> Is there something wrong with mandating that if an >>> entity placed a tel-URI in a sip request along with a >>> phone-context carrying a domain name, then that domain name >>> must be the address of a sip proxy? >>> =09 >>> /Hisham >>> =09 >>> > -----Original Message----- >>> > From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>> > Sent: Saturday, August 30, 2003 2:48 AM >>> > To: Stastny Richard; Khartabil Hisham (NMP/Helsinki); >>> Dean Willis >>> > Cc: Brian Rosen; sip@ietf.org >>> > Subject: Re: AW: AW: [Sip] SIPIT Interop problem with >>> ;user=3Dphone >>> > >>> > >>> > >>> > I don't know what I was thinking - I gave the wrong answer. >>> > The context in >>> > the tel does not at mean you should attempt to route the call >>> > to there - it >>> > is just an identifier of the namespace of who >>> understands the number. >>> > >>> > On 8/29/03 13:50, "Stastny Richard" >>> wrote: >>> > >>> > >>> So, how does the proxy route this message to >>> munich.example.com? >>> > >>> >>> > >>> /Hisham >>> > >>> >>> > >> >>> > >> The same way it routes sip:fluffy@munich.example.com >>> > > >>> > > Tell that to Dean :) He thinks it is not routable (that's >>> > the point I was >>> > > trying to make). >>> > > >>> > > Warning: this needs NOT to be true and IMHO this part of >>> > > the informational section is misleading. In section 5.1.4 >>> > Local numbers >>> > > it is clearly stated: >>> > > >>> > > "There are two ways to label the context: via a global >>> > number or any | >>> > > number of its leading digits (e.g., "+33") and via a >>> > domain name, | >>> > > e.g., "houston.example.com". The choice between the two is >>> > left to | >>> > > the "owner" of the local number and is governed by whether >>> > there is a | >>> > > global number or domain name that is a valid identifier >>> > for a | >>> > > particular local number. >>> > > | >>> > > The domain name does not have to resolve to any actual >>> > host, but MUST | >>> > > be under the administrative control of the entity managing >>> > the local | >>> > > phone context. " >>> > > >>> > > Since the domain name does not have to resolve to >>> an actual host, >>> > > one cannot rely on this, so your statement may be wrong. >>> > > >>> > > Richard >>> > > >>> > > -----Urspr=C3=BCngliche Nachricht----- >>> > > Von: hisham.khartabil@nokia.com >>> [mailto:hisham.khartabil@nokia.com] >>> > > Gesendet: Fr 29.08.2003 17:31 >>> > > An: fluffy@cisco.com; dean.willis@softarmor.com >>> > > Cc: Brian.Rosen@marconi.com; sip@ietf.org >>> > > Betreff: RE: AW: [Sip] SIPIT Interop problem with >>> ;user=3Dphone >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >> -----Original Message----- >>> > >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>> > >> Sent: Friday, August 29, 2003 5:51 PM >>> > >> To: Khartabil Hisham (NMP/Helsinki); Dean Willis >>> > >> Cc: Brian Rosen; sip@ietf.org >>> > >> Subject: Re: AW: [Sip] SIPIT Interop problem with >>> ;user=3Dphone >>> > >> >>> > >> >>> > >> On 8/29/03 1:03, "hisham.khartabil@nokia.com" >>> > >> >>> > >> wrote: >>> > >> >>> > >>> Under the informative text in 2806bis labeled "A Use of >>> > >> "tel" URIs with SIP >>> > >>> (Informative)", it says: >>> > >>> >>> > >>> " >>> > >>> 2. The outbound proxy does not use >>> the same phone >>> > >>> context, but can route to a proxy that >>> > handles this >>> > >>> phone context. This routing can be done >>> > via a lookup >>> > >>> table or the domain name of the phone >>> > >> context might be >>> > >>> set up to reflect the SIP domain name of >>> > a suitable >>> > >>> proxy. For example, a proxy may >>> always route calls >>> > >>> with tel URIs like >>> > >>> >>> > >>> tel:1234;phone-context=3Dmunich.example.com >>> > >>> >>> > >>> to the SIP proxy located at >>> munich.example.com." >>> > >>> >>> > >>> >>> > >>> So, how does the proxy route this message to >>> munich.example.com? >>> > >>> >>> > >>> /Hisham >>> > >>> >>> > >> >>> > >> The same way it routes sip:fluffy@munich.example.com >>> > > >>> > > Tell that to Dean :) He thinks it is not routable (that's >>> > the point I was >>> > > trying to make). >>> > > >>> > > Regards, >>> > > Hisham >>> > > >>> > > >>> > >> >>> > >> >>> > >> >>> > > >>> > > _______________________________________________ >>> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > > This list is for NEW development of the core SIP Protocol >>> > > Use sip-implementors@cs.columbia.edu for questions >>> on current sip >>> > > Use sipping@ietf.org for new developments on the >>> application of sip >>> > > >>> > > >>> > >>> > >>> > _______________________________________________ >>> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > This list is for NEW development of the core SIP Protocol >>> > Use sip-implementors@cs.columbia.edu for questions on >>> current sip >>> > Use sipping@ietf.org for new developments on the >>> application of sip >>> > >>> =09 >>> >>> >> J*fj)b bm?=0C> > 0'~ffX)=DF=A3"8bX+=1FDY=D7=AFzZ)ay+y"=0F>-%R=C7=ACWz{h,rny=DB=9Fzb{(=CB=AB= *T"'~~{=07^hg'=17bqbz=1F >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 15 20:43:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04375 for ; Mon, 15 Sep 2003 20:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3vy-0005is-H2 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 20:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G0hAVa021992 for sip-archive@odin.ietf.org; Mon, 15 Sep 2003 20:43:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3vp-0005iG-Gm; Mon, 15 Sep 2003 20:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z3vW-0005hw-Tq for sip@optimus.ietf.org; Mon, 15 Sep 2003 20:42:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04366 for ; Mon, 15 Sep 2003 20:42:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z3vU-0000ul-00 for sip@ietf.org; Mon, 15 Sep 2003 20:42:40 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19z3vU-0000ui-00 for sip@ietf.org; Mon, 15 Sep 2003 20:42:40 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h8G0gf9Q029193; Mon, 15 Sep 2003 20:42:41 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 15 Sep 2003 20:49:34 -0400 Message-ID: <003601c37bec$66643f50$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D20AE35981@zsc3c030.us.nortel.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > No, that's not what "user=phone" does. > The spec says that if you map a tel URI into > a sip URI, then you must put the "user=phone" > attribute. So if the tel URI was, say > sip:+1-408-555-1212, then it is clearly not > a dial string. There are numerous example of this > in RFC3261/19.1.6 (i.e., of E.164 numbers in > sip URIs with user=phone). > > Also, on RFC3261/page 150, it says > If the user string contains a telephone number > formatted as a telephone-subscriber, the user > parameter value "phone" SHOULD be present. > > Recall that "telephone-subscriber" is defined > in 2806-bis for the Tel URI. It was defined in rfc2543 with one definition. And it is defined in rfc2806 with a different definition. And now it is defined in rfc2806bis with another different definition. And unfortunately "phone-context" was not part of rfc2543. Its usage for local numbers was listed only at a SHOULD strength for rfc2806. And rfc2806bis-02 now makes phone-context mandatory for local numbers. > (Note also that it doesn't say that user=phone > can't be used for other purposes, which is what > I would like to change, otherwise it is basically > useless). I agree. However rfc2806bis-02 has made the previously permissible usages of user=phone for local numbers invalid. Thus it is not backwards compatible with rfc2543, rfc2806, and rfc3398. > Conclusion is that the "user=phone" can NOT > mean "dial string". Paul and I are saying that > we don't need to send dial digits in a SIP > or Tel URI, because of the Tel URI's ability to > associate a local phone context is sufficient. > I don't see a need for sending "pauses", "pound" > and "stars" as part of a number, and argue they > should be chewed by the phones. The local context > can handle the cases where you don't want to do > much parsing of the numbering plan in the phone > itself. If you think that it is required to support > pauses, pound & star in SIP, then we would have > to add it to the spec with a new mechanism. The '*' and '#' are still part of the local number definition within rfc2806bis-02. The pause and wait-for-dial-tone were part of rfc2543 and rfc2806; they are not part of the bis. Because they were hard to interwork, leaving these two out of the bis is fine with me. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:00:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10489 for ; Tue, 16 Sep 2003 09:00:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bS-NA for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0TbQ017380 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRF-0004VG-AS; Tue, 16 Sep 2003 09:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuXh-0001Cr-8D for sip@optimus.ietf.org; Mon, 15 Sep 2003 10:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05247 for ; Mon, 15 Sep 2003 10:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuXe-000697-00 for sip@ietf.org; Mon, 15 Sep 2003 10:41:26 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19yuXd-00066G-00 for sip@ietf.org; Mon, 15 Sep 2003 10:41:26 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8FEetAP026130 for ; Mon, 15 Sep 2003 09:40:55 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 15 Sep 2003 09:40:53 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9211@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: sip@ietf.org Date: Mon, 15 Sep 2003 09:36:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B96.C0DC8858" Subject: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37B96.C0DC8858 Content-Type: text/plain; charset="iso-8859-1" If multiple PUAs publishes information on the same tuple, does it mean that the ESC will have multiple entity-tags associated with that tuple, one for each publishing PUA. Also, the only means to stop a specfic PUA from updating that tuple is through explictly disallowing that PUA from updating the state event for that tuple, in the authorization policies in the ESC. Thanks /gf ------_=_NextPart_001_01C37B96.C0DC8858 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Handling of identical Tuples by Multiple PUAs - PUBLISH 00 =

If multiple PUAs publishes information = on the same tuple, does it mean that the ESC will have multiple = entity-tags associated with that tuple, one for each publishing = PUA.

Also, the only means to stop a specfic = PUA from updating that tuple is through explictly disallowing that PUA = from updating the state event for that tuple, in the authorization = policies in the ESC.

Thanks
/gf
 
 

------_=_NextPart_001_01C37B96.C0DC8858-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:00:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10494 for ; Tue, 16 Sep 2003 09:00:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bT-Nv for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0Sqx017371 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRD-0004Ui-VM; Tue, 16 Sep 2003 09:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yagL-0005Y6-Tm for sip@optimus.ietf.org; Sun, 14 Sep 2003 13:29:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07167; Sun, 14 Sep 2003 13:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yagJ-0006r2-00; Sun, 14 Sep 2003 13:29:03 -0400 Received: from tomts22.bellnexxia.net ([209.226.175.184] helo=tomts22-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19yagI-0006qi-00; Sun, 14 Sep 2003 13:29:02 -0400 Received: from Cheng ([64.230.123.212]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with SMTP id <20030914172857.RDF7231.tomts22-srv.bellnexxia.net@Cheng>; Sun, 14 Sep 2003 13:28:57 -0400 From: "Wijnen, Bert (Bert)" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------4SHFZVX48WMZ48" Message-Id: <20030914172857.RDF7231.tomts22-srv.bellnexxia.net@Cheng> Date: Sun, 14 Sep 2003 13:29:00 -0400 Subject: [Sip] FW: MIB Doctor review of: draft-ietf-mpls-ftn-mib-08.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ------------4SHFZVX48WMZ48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) Sent: woensdag 30 juli 2003 23:33 To: Wijnen, Bert (Bert); 'Joan Cucchiara x302'; 'jcucchiara@mindspring.com' Cc: 'bwijnen@lucent.com'; 'zinin@psg.com'; 'loa@pi.se'; 'swallow@cisco.com'; 'mrm@riverstonenet.c ------------4SHFZVX48WMZ48 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: photo.scr, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------4SHFZVX48WMZ48-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:01:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10541 for ; Tue, 16 Sep 2003 09:01:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bV-QL for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0SDQ017374 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRA-0004Tb-VV; Tue, 16 Sep 2003 09:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXlc-0006Am-06 for sip@optimus.ietf.org; Thu, 11 Sep 2003 16:10:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12234 for ; Thu, 11 Sep 2003 16:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXla-0005tJ-00 for sip@ietf.org; Thu, 11 Sep 2003 16:10:10 -0400 Received: from [68.162.203.2] (helo=sonmail01.sonexis.com) by ietf-mx with esmtp (Exim 4.12) id 19xXlZ-0005tB-00 for sip@ietf.org; Thu, 11 Sep 2003 16:10:09 -0400 Message-ID: <9F0203E4E1C22A409C9E7D1809E448D90BB76D@sonmail.sonexis.com> From: Matt Guertin To: "'Rosen, Brian'" , "'sip@ietf.org'" Date: Thu, 11 Sep 2003 16:11:59 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C378A0.F50BFD50" Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C378A0.F50BFD50 Content-Type: text/plain; charset="iso-8859-1" Hi Brian, Our product has a web-based interface for setting up conferences. If you select that you want to start a conference "now" we declare it to be an "ad hoc" conference. But we still make the user specify an end time. This is the main, and I think only, difference between your definition and ours. I agree about conference-uris, it doesn't really matter how they come into existence, for this discussion, once you have one, you have one. Each instance of a conference has a unique conference uri. All of this is clear in the specs. The problem is that let's say, we send out email saying that conference so-and-so is starting now (or at 1:00PM - it doesn't really matter). There is a SIP uri in the email invitation. And at the specified time, the caller uses his/her softphone to dial in. But the proxy server needs to understand that this sip uri needs to go to the conference bridge. The problem we have right now, is that we don't control the proxy servers. So how can we follow the standards (or draft standards) and still get this to work? I don't know of any sip proxy server which allows the flexibility you describe (i.e., rule-based / policy-based routing). Trying to register the conference-uri's didn't work because of authentication - each conference uri can't have a unique username / password associated with it - the overhead would kill us. I don't see how the REFER style would work for large conferences, and we use a participant dial-in model, anyway. I thought that the proxy servers would be smart enough to understand that the contact fields can be used as aliases when the 'isfocus' flag is used. But unfortunately not. This all boils down to resource allocation. Since audio ports are a valuable resource, we can't tie them up unless we know they are being used. Hence, the need for scheduling. If a conference goes over its allocated time slot, it keeps going as long as there are audio ports available. If someone else scheduled a conference right after yours and there are too few audio ports, the expired conference is stopped so that the next group can use the audio ports. What if you had an important conference scheduled, and had some important people on the call, but you couldn't start the conference because the people in the earlier conference didn't want to end theirs? It's a lot like a conference room scheduling program, there's the rooms and there are people who can fit in the room, and there are time ranges. Scheduled audio conferences are becoming extremely popular and going to be around for a long time, because they are more practical in most business applications than open-ended and ad hoc conferences. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, September 11, 2003 2:58 PM To: 'Matt Guertin'; 'sip@ietf.org' Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? Matt Generally, when we say "ad hoc conference", we mean something that happens at the spur of the moment; it's not scheduled. A scheduled conference is something else. Really, there is very little difference, at least in terms of how the mechanisms work: 1) You go to the conference factory to get a conference uri 2) You either hand it out, and people INVITE themselves in, or you REFER people to the conference-id The important point is that the conference factory uri is well known, and generally doesn't change, but the conference-uri is different for every conference. From the point of view of a participant, a conference uri is just a uri. How it gets it (by INVITE to conference factory uri, or email, or "good guess", doesn't matter. It has one. The crux of your question, as stated, was how the proxy server routes calls. I gave one answer, you have another. In mine, the proxy server has a routing rule based on a pattern match on the uri. For example, it might say that any username starting with "bridge2-" is routed to a particular conference bridge. Then conference uris handed out by the conference factory might be something like "bridge2-922ac44a00@example.com", but they could also look like "bridge-2-weekly-sales-conf@example.com". Your suggestion has the conference factory registering each uri it hands out. That also will work. Hybrids will work. For example, I could register "weekly-sales-call@example.com" as an alias for "bridge2-99n77h7h7777@example.com", if my proxy server allowed aliases. I don't think that we want to have locked down specifications for this kind of thing, at least right now. I think a stand-alone conference server, which was not a proxy server, might want to be able to register every conference, but it might want to be configurable so that such a mechanism was controllable. I'll point out that registration isn't particularly desirable for what I call an ad-hoc conference, primarily because I don't want to incur the registration delay between the time I press the "CONF" button on my phone, and the time the party I'm calling's phone rings. One thing I'm curious about. Have you ever used a conference bridge, or service, that literally kicked you out at the scheduled time? They are pretty uncommon, and, in my own experience, frustrating. Meetings that conclude on schedule are pretty rare, around here anyway. Nearly every conference service I've ever used does not enforce a time limit. I've seen some video bridges that do that. Not a matter for standardization of course; if you want to build one that way, I don't want to stop you :) Brian -----Original Message----- From: Matt Guertin [mailto:MGuertin@sonexis.com] Sent: Thursday, September 11, 2003 2:36 PM To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org' Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? Hi Brian, Thanks for taking the time to respond to my posting. What you describe sounds like it will work for very small conferences. However, we support "open-ended" conferences, where anyone who knows the "conference-id" can get in, even if the host does not explicitly invite them. In addition, for a scheduled conference, the host can send out invitations to dozens of people, knowing that only maybe half will be able to participate. But the real "gotcha" here is that the conference always has an end time. For example, if there is a 1:00PM sales meeting, it will go until maybe 2:00PM. Then that's it. There may be another one tomorrow, or next week at the same time, but the conference is over until then. You wouldn't want to tie up the ports on a conference bridge for a conference that's over. You would let someone else use them for another conference, and/or the earlier host to use them again for some other meeting. I don't see why the SIP proxy server can't just forward the requests for the additional URIs in the contact field. That would solve all the problems associated with "time-based" conferences. 1) The SIP proxy would know that it is dealing with a conference bridge, which will have many "aliases" for conferences. 2) The conference bridge is still looked at as a single user agent, with a single username and password. For example: REGISTER sip:10.1.4.35:5060 SIP/2.0 From: sip:2038@10.20.20.201:5060 To: sip:2038@10.20.20.201 Contact: ;isfocus Contact: ;isfocus Contact: ;isfocus Call-ID: 12707648587750000@SONEXIS-C723CFA CSeq: 85 REGISTER Content-Length: 0 Expires: 1200 Proxy-Authorization: Digest username="2038",realm=... The above might represent registering three concurrent conferences going on at a conference bridge called 2038. Of course, the conference bridge would only register "active" conferences, and unregister them when they are over. And when someone issued an INVITE request to the conference bridge it would be responsible for placing the participant in the correct conference. -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marcon i.com... > We make this work roughly (code is evolving) the following way: > We provision (actually, it's learned) the name of the local > conference factory uri. This is a fixed uri, and is > local to the domain of the conference host. > The conference host registers with this well known > address. It is an actual "user" in the system. > We start with a 1on1 call, between the first two parties > When we add the third party, the UA initiating this action > sends an INVITE to the conference factory uri. > The conference host returns a Contact header with > a unique conference uri. The conference uri is > constructed using a pattern known to the outgoing proxy > The UA initiating the conference REFERs all three parties to > the conference using the conference uri > Invites with a username matching the pattern are routed to > the conference host > > Brian > > > > -----Original Message----- > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > Sent: Wednesday, September 10, 2003 11:20 AM > > To: sip@ietf.org > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > I read through all the SIP specs that I know of, and believe to have > > implement our SIP Conference "focus" correctly. We have what > > is sometimes > > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > > anyway). When I go to do a REGISTER request, the > > authentication fails, > > because the username/password does not match with the > > ConferenceURI. I can > > only register with ConferenceURIs which have > > usernames/password provisioned. > > This doesn't work for Ad Hoc conferences, and even for > > scheduled conferences > > for that matter. It is unacceptable in a practical > > application to send mail > > to an administrator every time a new conference is scheduled > > to generate a > > username/password for the conference. The administrator may > > not get around > > to adding the new username/password for hours or even days. > > Am I missing > > something? We are using the contact field the way it is > > spec'ed in the > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C378A0.F50BFD50 Content-Type: text/html; charset="iso-8859-1" RE: Cannot REGISTER Ad Hoc SIP Conference?

Hi Brian,

Our product has a web-based interface for setting up
conferences. If you select that you want to start a conference
"now" we declare it to be an "ad hoc" conference.  But we
still make the user specify an end time.  This is the main,
and I think only, difference between your definition and ours. 
I agree about conference-uris, it doesn't really matter how
they come into existence, for this discussion, once you have
one, you have one.  Each instance of a conference has a unique
conference uri.  All of this is clear in the specs.

The problem is that let's say, we send out email saying that
conference so-and-so is starting now (or at 1:00PM - it
doesn't really matter). There is a SIP uri in the email
invitation.  And at the specified time, the caller uses
his/her softphone to dial in.  But the proxy server needs
to understand that this sip uri needs to go to the conference
bridge.  The problem we have right now, is that we don't
control the proxy servers.  So how can we follow the standards
(or draft standards) and still get this to work?  I don't know
of any sip proxy server which allows the flexibility you
describe (i.e., rule-based / policy-based routing).  Trying to
register the conference-uri's didn't work because of
authentication - each conference uri can't have a unique
username / password associated with it - the overhead would
kill us.  I don't see how the REFER style would work for large
conferences, and we use a participant dial-in model, anyway.
I thought that the proxy servers would be smart enough to
understand that the contact fields can be used as aliases
when the 'isfocus' flag is used.  But unfortunately not.

This all boils down to resource allocation.  Since audio ports
are a valuable resource, we can't tie them up unless we know
they are being used.  Hence, the need for scheduling.  If a
conference goes over its allocated time slot, it keeps going
as long as there are audio ports available.  If someone else
scheduled a conference right after yours and there are too
few audio ports, the expired conference is stopped so that the
next group can use the audio ports.  What if you had an
important conference scheduled, and had some important people
on the call, but you couldn't start the conference because the
people in the earlier conference didn't want to end theirs?
It's a lot like a conference room scheduling program, there's
the rooms and there are people who can fit in the room, and
there are time ranges.  Scheduled audio conferences are
becoming extremely popular and going to be around for a long
time, because they are more practical in most business
applications than open-ended and ad hoc conferences.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 11, 2003 2:58 PM
To: 'Matt Guertin'; 'sip@ietf.org'
Subject: RE: Cannot REGISTER Ad Hoc SIP Conference?


Matt

Generally, when we say "ad hoc conference", we mean something that
happens at the spur of the moment; it's not scheduled.
A scheduled conference is something else.

Really, there is very little difference, at least in terms of how
the mechanisms work:

1) You go to the conference factory to get a conference uri
2) You either hand it out, and people INVITE themselves in,
or you REFER people to the conference-id

The important point is that the conference factory uri is well
known, and generally doesn't change, but the conference-uri
is different for every conference.

From the point of view of a participant, a conference uri is
just a uri.  How it gets it (by INVITE to conference factory
uri, or email, or "good guess", doesn't matter.  It has one.

The crux of your question, as stated, was how the proxy server
routes calls.  I gave one answer, you have another.  In mine,
the proxy server has a routing rule based on a pattern match
on the uri.  For example, it might say that any username starting
with "bridge2-" is routed to a particular conference bridge.
Then conference uris handed out by the conference factory might
be something like "bridge2-922ac44a00@example.com", but they
could also look like "bridge-2-weekly-sales-conf@example.com".

Your suggestion has the conference factory registering each uri
it hands out.  That also will work.  Hybrids will work. For example,
I could register "weekly-sales-call@example.com" as an alias for
"bridge2-99n77h7h7777@example.com", if my proxy server allowed
aliases.  I don't think that we want to have locked down specifications
for this kind of thing, at least right now.  I think a stand-alone
conference server, which was not a proxy server, might want to be
able to register every conference, but it might want to be configurable
so that such a mechanism was controllable.

I'll point out that registration isn't particularly desirable for
what I call an ad-hoc conference, primarily because I don't want to
incur the registration delay between the time I press the "CONF" button
on my phone, and the time the party I'm calling's phone rings.

One thing I'm curious about.  Have you ever used a conference bridge,
or service, that literally kicked you out at the scheduled time?
They are pretty uncommon, and, in my own experience, frustrating. 
Meetings that conclude on schedule are pretty rare, around here anyway.
Nearly every conference service I've ever used does not enforce a
time limit.  I've seen some video bridges that do that.  Not a matter
for standardization of course; if you want to build one that way, I
don't want to stop you :)

Brian
-----Original Message-----
From: Matt Guertin [mailto:MGuertin@sonexis.com]
Sent: Thursday, September 11, 2003 2:36 PM
To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org'
Subject: Re: Cannot REGISTER Ad Hoc SIP Conference?


Hi Brian,
Thanks for taking the time to respond to my posting. What you describe
sounds like it will work for very small conferences.  However, we support
"open-ended" conferences, where anyone who knows the "conference-id" can get

in, even if the host does not explicitly invite them. In addition, for a
scheduled conference, the host can send out invitations to dozens of people,

knowing that only maybe half will be able to participate. But the real
"gotcha" here is that the conference always has an end time.  For example,
if there is a 1:00PM sales meeting, it will go until maybe 2:00PM.  Then
that's it.  There may be another one tomorrow, or next week at the same
time, but the conference is over until then.  You wouldn't want to tie up
the ports on a conference bridge for a conference that's over.  You would
let someone else use them for another conference, and/or the earlier host to

use them again for some other meeting.
I don't see why the SIP proxy server can't just forward the requests for the

additional URIs in the contact field.  That would solve all the problems
associated with "time-based" conferences.  1) The SIP proxy would know that
it is dealing with a conference bridge, which will have many "aliases" for
conferences. 2) The conference bridge is still looked at as a single user
agent, with a single username and password.  For example:
REGISTER sip:10.1.4.35:5060 SIP/2.0
From: sip:2038@10.20.20.201:5060
To: sip:2038@10.20.20.201
Contact: <sip:weekly_sales@10.20.20.201:5060>;isfocus
Contact: <sip:eng_status@10.20.20.201:5060>;isfocus
Contact: <sip:matts_sip_meeting@10.20.20.201:5060>;isfocus
Call-ID: 12707648587750000@SONEXIS-C723CFA
CSeq: 85 REGISTER
Content-Length: 0
Expires: 1200
Proxy-Authorization: Digest username="2038",realm=...


The above might represent registering three concurrent conferences going on
at a conference bridge called 2038.  Of course, the conference bridge would
only register "active" conferences, and unregister them when they are over.
And when someone issued an INVITE request to the conference bridge it would
be responsible for placing the participant in the correct conference.
-Matt.



"Rosen, Brian" <Brian.Rosen@marconi.com> wrote in message
news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marcon
i.com...
> We make this work roughly (code is evolving) the following way:
> We provision (actually, it's learned) the name of the local
> conference factory uri.  This is a fixed uri, and is
> local to the domain of the conference host.
> The conference host registers with this well known
> address.  It is an actual "user" in the system.
> We start with a 1on1 call, between the first two parties
> When we add the third party, the UA initiating this action
> sends an INVITE to the conference factory uri.
> The conference host returns a Contact header with
> a unique conference uri.  The conference uri is
> constructed using a pattern known to the outgoing proxy
> The UA initiating the conference REFERs all three parties to
> the conference using the conference uri
> Invites with a username matching the pattern are routed to
> the conference host
>
> Brian
>
>
> > -----Original Message-----
> > From: Matt Guertin [mailto:mguertin@sonexis.com]
> > Sent: Wednesday, September 10, 2003 11:20 AM
> > To: sip@ietf.org
> > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference?
> >
> >
> > I read through all the SIP specs that I know of, and believe to have
> > implement our SIP Conference "focus" correctly.  We have what
> > is sometimes
> > referred to as a SIP Conference Bridge Marshal Server (in vocal speak
> > anyway).  When I go to do a REGISTER request, the
> > authentication fails,
> > because the username/password does not match with the
> > ConferenceURI.  I can
> > only register with ConferenceURIs which have
> > usernames/password provisioned.
> > This doesn't work for Ad Hoc conferences, and even for
> > scheduled conferences
> > for that matter.  It is unacceptable in a practical
> > application to send mail
> > to an administrator every time a new conference is scheduled
> > to generate a
> > username/password for the conference.  The administrator may
> > not get around
> > to adding the new username/password for hours or even days.
> > Am I missing
> > something?  We are using the contact field the way it is
> > spec'ed in the
> > conference framework draft (ie., the isfocus flag is set).
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C378A0.F50BFD50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:00:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10530 for ; Tue, 16 Sep 2003 09:00:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bU-Pg for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0SQn017373 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFR6-0004SN-ST; Tue, 16 Sep 2003 09:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWFK-0001HG-JA for sip@optimus.ietf.org; Thu, 11 Sep 2003 14:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04260 for ; Thu, 11 Sep 2003 14:32:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWFH-00047T-00 for sip@ietf.org; Thu, 11 Sep 2003 14:32:43 -0400 Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 19xWFH-00047Q-00 for sip@ietf.org; Thu, 11 Sep 2003 14:32:43 -0400 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19xWFC-000258-00 for ; Thu, 11 Sep 2003 20:32:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: sip@ietf.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19xWFB-000250-00 for ; Thu, 11 Sep 2003 20:32:37 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19xWFF-0007L9-00 for ; Thu, 11 Sep 2003 20:32:41 +0200 From: "Matt Guertin" Date: Thu, 11 Sep 2003 14:33:34 -0400 Lines: 117 Message-ID: References: <313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marconi.com> X-Complaints-To: usenet@sea.gmane.org X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] Re: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Brian, Thanks for taking the time to respond to my posting. What you describe sounds like it will work for very small conferences. However, we support "open-ended" conferences, where anyone who knows the "conference-id" can get in, even if the host does not explicitly invite them. In addition, for a scheduled conference, the host can send out invitations to dozens of people, knowing that only maybe half will be able to participate. But the real "gotcha" here is that the conference always has an end time. For example, if there is a 1:00PM sales meeting, it will go until maybe 2:00PM. Then that's it. There may be another one tomorrow, or next week at the same time, but the conference is over until then. You wouldn't want to tie up the ports on a conference bridge for a conference that's over. You would let someone else use them for another conference, and/or the earlier host to use them again for some other meeting. I don't see why the SIP proxy server can't just forward the requests for the additional URIs in the contact field. That would solve all the problems associated with "time-based" conferences. 1) The SIP proxy would know that it is dealing with a conference bridge, which will have many "aliases" for conferences. 2) The conference bridge is still looked at as a single user agent, with a single username and password. For example: REGISTER sip:10.1.4.35:5060 SIP/2.0 From: sip:2038@10.20.20.201:5060 To: sip:2038@10.20.20.201 Contact: ;isfocus Contact: ;isfocus Contact: ;isfocus Call-ID: 12707648587750000@SONEXIS-C723CFA CSeq: 85 REGISTER Content-Length: 0 Expires: 1200 Proxy-Authorization: Digest username="2038",realm=... The above might represent registering three concurrent conferences going on at a conference bridge called 2038. Of course, the conference bridge would only register "active" conferences, and unregister them when they are over. And when someone issued an INVITE request to the conference bridge it would be responsible for placing the participant in the correct conference. -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marconi.com... > We make this work roughly (code is evolving) the following way: > We provision (actually, it's learned) the name of the local > conference factory uri. This is a fixed uri, and is > local to the domain of the conference host. > The conference host registers with this well known > address. It is an actual "user" in the system. > We start with a 1on1 call, between the first two parties > When we add the third party, the UA initiating this action > sends an INVITE to the conference factory uri. > The conference host returns a Contact header with > a unique conference uri. The conference uri is > constructed using a pattern known to the outgoing proxy > The UA initiating the conference REFERs all three parties to > the conference using the conference uri > Invites with a username matching the pattern are routed to > the conference host > > Brian > > > > -----Original Message----- > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > Sent: Wednesday, September 10, 2003 11:20 AM > > To: sip@ietf.org > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > I read through all the SIP specs that I know of, and believe to have > > implement our SIP Conference "focus" correctly. We have what > > is sometimes > > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > > anyway). When I go to do a REGISTER request, the > > authentication fails, > > because the username/password does not match with the > > ConferenceURI. I can > > only register with ConferenceURIs which have > > usernames/password provisioned. > > This doesn't work for Ad Hoc conferences, and even for > > scheduled conferences > > for that matter. It is unacceptable in a practical > > application to send mail > > to an administrator every time a new conference is scheduled > > to generate a > > username/password for the conference. The administrator may > > not get around > > to adding the new username/password for hours or even days. > > Am I missing > > something? We are using the contact field the way it is > > spec'ed in the > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:47:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10488 for ; Tue, 16 Sep 2003 09:00:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bW-RM for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0SdU017377 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRC-0004UA-LZ; Tue, 16 Sep 2003 09:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yXT4-0008Qu-SV for sip@optimus.ietf.org; Sun, 14 Sep 2003 10:03:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00961; Sun, 14 Sep 2003 10:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yXT1-0003kw-00; Sun, 14 Sep 2003 10:03:07 -0400 Received: from tomts12.bellnexxia.net ([209.226.175.56] helo=tomts12-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19yXT0-0003kT-00; Sun, 14 Sep 2003 10:03:06 -0400 Received: from Cheng ([64.230.123.212]) by tomts12-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with SMTP id <20030914140301.FJMF12420.tomts12-srv.bellnexxia.net@Cheng>; Sun, 14 Sep 2003 10:03:01 -0400 From: zhou.zichun@cisco.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------WTCRL7AX46ED31" Message-Id: <20030914140301.FJMF12420.tomts12-srv.bellnexxia.net@Cheng> Date: Sun, 14 Sep 2003 10:03:03 -0400 Subject: [Sip] Re: Re: [Megaco] A question about H.248 on SCTP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ------------WTCRL7AX46ED31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco. Explicitly recognize that the forwarding function that chooses >an outgoing IP interface (i.e. for bypassed packets and for packets >that have just been encrypted or just been decrypted) need not be >the same function as the SPD selection function. As I said above, the whole point of the lookup was to select the interface, and the SPD has always be ------------WTCRL7AX46ED31 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: image.pif, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------WTCRL7AX46ED31-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 09:47:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10542 for ; Tue, 16 Sep 2003 09:01:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFRV-0004bX-Rd for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GD0S17017378 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 09:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zFR8-0004Sl-Nf; Tue, 16 Sep 2003 09:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWGI-0001Hk-Md for sip@optimus.ietf.org; Thu, 11 Sep 2003 14:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04275 for ; Thu, 11 Sep 2003 14:33:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWGG-00047k-00 for sip@ietf.org; Thu, 11 Sep 2003 14:33:44 -0400 Received: from [68.162.203.2] (helo=sonmail01.sonexis.com) by ietf-mx with esmtp (Exim 4.12) id 19xWGF-00047e-00 for sip@ietf.org; Thu, 11 Sep 2003 14:33:43 -0400 Message-ID: <9F0203E4E1C22A409C9E7D1809E448D90BB76B@sonmail.sonexis.com> From: Matt Guertin To: "'Brian.Rosen@marconi.com'" , "'sip@ietf.org'" Date: Thu, 11 Sep 2003 14:35:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37893.7C527450" Subject: [Sip] Re: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37893.7C527450 Content-Type: text/plain; charset="iso-8859-1" Hi Brian, Thanks for taking the time to respond to my posting. What you describe sounds like it will work for very small conferences. However, we support "open-ended" conferences, where anyone who knows the "conference-id" can get in, even if the host does not explicitly invite them. In addition, for a scheduled conference, the host can send out invitations to dozens of people, knowing that only maybe half will be able to participate. But the real "gotcha" here is that the conference always has an end time. For example, if there is a 1:00PM sales meeting, it will go until maybe 2:00PM. Then that's it. There may be another one tomorrow, or next week at the same time, but the conference is over until then. You wouldn't want to tie up the ports on a conference bridge for a conference that's over. You would let someone else use them for another conference, and/or the earlier host to use them again for some other meeting. I don't see why the SIP proxy server can't just forward the requests for the additional URIs in the contact field. That would solve all the problems associated with "time-based" conferences. 1) The SIP proxy would know that it is dealing with a conference bridge, which will have many "aliases" for conferences. 2) The conference bridge is still looked at as a single user agent, with a single username and password. For example: REGISTER sip:10.1.4.35:5060 SIP/2.0 From: sip:2038@10.20.20.201:5060 To: sip:2038@10.20.20.201 Contact: ;isfocus Contact: ;isfocus Contact: ;isfocus Call-ID: 12707648587750000@SONEXIS-C723CFA CSeq: 85 REGISTER Content-Length: 0 Expires: 1200 Proxy-Authorization: Digest username="2038",realm=... The above might represent registering three concurrent conferences going on at a conference bridge called 2038. Of course, the conference bridge would only register "active" conferences, and unregister them when they are over. And when someone issued an INVITE request to the conference bridge it would be responsible for placing the participant in the correct conference. -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pit.comms.marcon i.com... > We make this work roughly (code is evolving) the following way: > We provision (actually, it's learned) the name of the local > conference factory uri. This is a fixed uri, and is > local to the domain of the conference host. > The conference host registers with this well known > address. It is an actual "user" in the system. > We start with a 1on1 call, between the first two parties > When we add the third party, the UA initiating this action > sends an INVITE to the conference factory uri. > The conference host returns a Contact header with > a unique conference uri. The conference uri is > constructed using a pattern known to the outgoing proxy > The UA initiating the conference REFERs all three parties to > the conference using the conference uri > Invites with a username matching the pattern are routed to > the conference host > > Brian > > > > -----Original Message----- > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > Sent: Wednesday, September 10, 2003 11:20 AM > > To: sip@ietf.org > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > I read through all the SIP specs that I know of, and believe to have > > implement our SIP Conference "focus" correctly. We have what > > is sometimes > > referred to as a SIP Conference Bridge Marshal Server (in vocal speak > > anyway). When I go to do a REGISTER request, the > > authentication fails, > > because the username/password does not match with the > > ConferenceURI. I can > > only register with ConferenceURIs which have > > usernames/password provisioned. > > This doesn't work for Ad Hoc conferences, and even for > > scheduled conferences > > for that matter. It is unacceptable in a practical > > application to send mail > > to an administrator every time a new conference is scheduled > > to generate a > > username/password for the conference. The administrator may > > not get around > > to adding the new username/password for hours or even days. > > Am I missing > > something? We are using the contact field the way it is > > spec'ed in the > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C37893.7C527450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Cannot REGISTER Ad Hoc SIP Conference?

Hi Brian,

Thanks for taking the time to respond to my posting. = What you describe
sounds like it will work for very small = conferences.  However, we support
"open-ended" conferences, where anyone who = knows the "conference-id" can get
in, even if the host does not explicitly invite = them. In addition, for a
scheduled conference, the host can send out = invitations to dozens of people,
knowing that only maybe half will be able to = participate. But the real
"gotcha" here is that the conference = always has an end time.  For example,
if there is a 1:00PM sales meeting, it will go until = maybe 2:00PM.  Then
that's it.  There may be another one tomorrow, = or next week at the same
time, but the conference is over until then.  = You wouldn't want to tie up
the ports on a conference bridge for a conference = that's over.  You would
let someone else use them for another conference, = and/or the earlier host to
use them again for some other meeting.

I don't see why the SIP proxy server can't just = forward the requests for the
additional URIs in the contact field.  That = would solve all the problems
associated with "time-based" = conferences.  1) The SIP proxy would know that
it is dealing with a conference bridge, which will = have many "aliases" for
conferences. 2) The conference bridge is still = looked at as a single user
agent, with a single username and password.  = For example:

REGISTER sip:10.1.4.35:5060 SIP/2.0
From: sip:2038@10.20.20.201:5060
To: sip:2038@10.20.20.201
Contact: = <sip:weekly_sales@10.20.20.201:5060>;isfocus
Contact: = <sip:eng_status@10.20.20.201:5060>;isfocus
Contact: = <sip:matts_sip_meeting@10.20.20.201:5060>;isfocus
Call-ID: 12707648587750000@SONEXIS-C723CFA
CSeq: 85 REGISTER
Content-Length: 0
Expires: 1200
Proxy-Authorization: Digest = username=3D"2038",realm=3D...


The above might represent registering three = concurrent conferences going on
at a conference bridge called 2038.  Of course, = the conference bridge would
only register "active" conferences, and = unregister them when they are over.
And when someone issued an INVITE request to the = conference bridge it would
be responsible for placing the participant in the = correct conference.

-Matt.



"Rosen, Brian" = <Brian.Rosen@marconi.com> wrote in message
news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgu= sr-02.pit.comms.marconi.com...
> We make this work roughly (code is evolving) = the following way:
> We provision (actually, it's learned) the name = of the local
> conference factory uri.  This is a fixed = uri, and is
> local to the domain of the conference = host.
> The conference host registers with this well = known
> address.  It is an actual "user" = in the system.
> We start with a 1on1 call, between the first = two parties
> When we add the third party, the UA initiating = this action
> sends an INVITE to the conference factory = uri.
> The conference host returns a Contact header = with
> a unique conference uri.  The conference = uri is
> constructed using a pattern known to the = outgoing proxy
> The UA initiating the conference REFERs all = three parties to
> the conference using the conference uri
> Invites with a username matching the pattern = are routed to
> the conference host
>
> Brian
>
>
> > -----Original Message-----
> > From: Matt Guertin [mailto:mguertin@sonexis.com]
> > Sent: Wednesday, September 10, 2003 11:20 = AM
> > To: sip@ietf.org
> > Subject: [Sip] Cannot REGISTER Ad Hoc SIP = Conference?
> >
> >
> > I read through all the SIP specs that I = know of, and believe to have
> > implement our SIP Conference = "focus" correctly.  We have what
> > is sometimes
> > referred to as a SIP Conference Bridge = Marshal Server (in vocal speak
> > anyway).  When I go to do a REGISTER = request, the
> > authentication fails,
> > because the username/password does not = match with the
> > ConferenceURI.  I can
> > only register with ConferenceURIs which = have
> > usernames/password provisioned.
> > This doesn't work for Ad Hoc conferences, = and even for
> > scheduled conferences
> > for that matter.  It is unacceptable = in a practical
> > application to send mail
> > to an administrator every time a new = conference is scheduled
> > to generate a
> > username/password for the = conference.  The administrator may
> > not get around
> > to adding the new username/password for = hours or even days.
> > Am I missing
> > something?  We are using the contact = field the way it is
> > spec'ed in the
> > conference framework draft (ie., the = isfocus flag is set).
> >
> >
> >
> >
> > = _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the = core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for = questions on current sip
> > Use sipping@ietf.org for new developments = on the application of sip
> >
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C37893.7C527450-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 10:03:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13722 for ; Tue, 16 Sep 2003 10:03:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGQM-0008GX-O1 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 10:03:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GE3MUP031713 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 10:03:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGQ2-0008Dt-R0; Tue, 16 Sep 2003 10:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGP9-00087v-Nk for sip@optimus.ietf.org; Tue, 16 Sep 2003 10:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13512 for ; Tue, 16 Sep 2003 10:01:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGP7-0001z7-00 for sip@ietf.org; Tue, 16 Sep 2003 10:02:05 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zGP6-0001yl-00 for sip@ietf.org; Tue, 16 Sep 2003 10:02:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8GE1Fd26611; Tue, 16 Sep 2003 09:01:15 -0500 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Robert Sparks To: Rohan Mahy Cc: Paul Kyzivat , Adam Roach , "'Rosen, Brian'" , sip@ietf.org In-Reply-To: <7AEF8EDE-E54D-11D7-9721-0003938AF740@cisco.com> References: <7AEF8EDE-E54D-11D7-9721-0003938AF740@cisco.com> Content-Type: text/plain Message-Id: <1063720874.884.15.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 16 Sep 2003 09:01:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > While I do not object to sending tel URIs to SIP proxies, I believe I > already articulated some reasons why you might want to use sip or sips > instead. > > 1) want to use SIPS Agreed! > 2) want to route the call to a specific domain that is not the domain > of your first hop proxy. > 3) want to invoke a loose router for services like transcoding or call > history logging that have different tel URI handling rules than you > want to use. Both 2 and 3 can be solved by pushing or preloading routes. > > thanks, > -r > > > Proxies that want to can still handle dial strings in sip urls without > > user=phone for backward compatibility with old phones. But as long as > > they do there will be the possibility of conflict with usernames. They > > could always limit this problem by restricting the kinds of dial > > strings they will accept. > > > > Paul > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 10:56:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19738 for ; Tue, 16 Sep 2003 10:56:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zHFZ-0002gW-Vh for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 10:56:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GEuH88010260 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 10:56:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zHFK-0002av-0U; Tue, 16 Sep 2003 10:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zHEd-0002a8-K7 for sip@optimus.ietf.org; Tue, 16 Sep 2003 10:55:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19636 for ; Tue, 16 Sep 2003 10:55:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zHEb-0003b1-00 for sip@ietf.org; Tue, 16 Sep 2003 10:55:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zHEa-0003ax-00 for sip@ietf.org; Tue, 16 Sep 2003 10:55:16 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GEtD403714 for ; Tue, 16 Sep 2003 17:55:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 17:55:13 +0300 Received: from nokia.com ([172.21.11.34]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 17:55:13 +0300 Message-ID: <3F672450.1080906@nokia.com> Date: Tue, 16 Sep 2003 17:55:12 +0300 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext George Foti (QC/EMC)" CC: sip@ietf.org Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 References: <2DBF697D5B36014ABA46E66A96107DA02C9211@lmc37.lmc.ericsson.se> In-Reply-To: <2DBF697D5B36014ABA46E66A96107DA02C9211@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2003 14:55:13.0057 (UTC) FILETIME=[8838D110:01C37C62] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi George, Inline. On 15.09.2003 17:36, ext George Foti (QC/EMC): > If multiple PUAs publishes information on the same tuple, does it mean > that the ESC will have multiple entity-tags associated with that tuple, > one for each publishing PUA. Each PUA publishes its own view of presence. Each view is assigned with an entity-tag, and each view can have tuples that overlap across other PUAs. Resolving these "collisions" is at the hands of the composer. For example, it could automatically take preference for the "newest" view on that tuple. > Also, the only means to stop a specfic PUA from updating that tuple is > through explictly disallowing that PUA from updating the state event for > that tuple, in the authorization policies in the ESC. As it now stands, this requires setting the composer policy in such a way that the unwanted presence information never gets composed into the presence document. Cheers, Aki > > Thanks > /gf > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 12:11:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24161 for ; Tue, 16 Sep 2003 12:11:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIQA-00067A-4J for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 12:11:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GGBIko023498 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 12:11:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIPv-00066Q-8U; Tue, 16 Sep 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zIP1-00065b-S8 for sip@optimus.ietf.org; Tue, 16 Sep 2003 12:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24083 for ; Tue, 16 Sep 2003 12:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zIP0-0004zL-00 for sip@ietf.org; Tue, 16 Sep 2003 12:10:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19zIOz-0004zA-00 for sip@ietf.org; Tue, 16 Sep 2003 12:10:05 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GGA1411833 for ; Tue, 16 Sep 2003 19:10:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 18:46:47 +0300 Received: from nokia.com ([172.21.11.34]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 18:46:47 +0300 Message-ID: <3F673067.5090403@nokia.com> Date: Tue, 16 Sep 2003 18:46:47 +0300 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext George Foti (QC/EMC)" CC: sip@ietf.org Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 References: <2DBF697D5B36014ABA46E66A96107DA02C921F@lmc37.lmc.ericsson.se> In-Reply-To: <2DBF697D5B36014ABA46E66A96107DA02C921F@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2003 15:46:47.0438 (UTC) FILETIME=[BC9DE2E0:01C37C69] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi George, I think the composer policy could simply be that the newest publication wins. That way the zombie PUA's state will not propagate to the watchers. Maybe this is something we ought to state in the draft? But I think shutting down (remotely) such a zombie publisher is somewhat outside the scope of PUBLISH. Personally, I think this problem may be more appropriately solved by designing the PUA such that it doesn't zombie out, e.g., it takes user inactivity as a hint and stops publication refreshes. Other than that, I'm open to suggestions. The main reason for not including event segmentation and collision detection to PUBLISH was that it created a lot of (unnecessary) complexity. Cheers, Aki On 16.09.2003 18:01, ext George Foti (QC/EMC): > Hi Aki, > > I think it should better explained in the draft how will such a > composer policy be set. If I have a PUA that is configured to > automatically publish presence information when I logon and if I > forgot to logoff, then how can I set the composer policy to ignore > that PUA or not include the information from that PUA in this case. > > Should this not be standradized ?? > > Thx/gf > >> -----Original Message----- From: Aki Niemi >> [mailto:aki.niemi@nokia.com] Sent: Tuesday, September 16, 2003 >> 10:55 AM To: George Foti (QC/EMC) Cc: sip@ietf.org Subject: Re: >> [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 >> >> >> Hi George, >> >> Inline. >> >> On 15.09.2003 17:36, ext George Foti (QC/EMC): >>> If multiple PUAs publishes information on the same tuple, >> does it mean >>> that the ESC will have multiple entity-tags associated with >> that tuple, >>> one for each publishing PUA. >> >> Each PUA publishes its own view of presence. Each view is assigned >> with an entity-tag, and each view can have tuples that overlap >> across other PUAs. Resolving these "collisions" is at the hands of >> the composer. For example, it could automatically take preference >> for the "newest" view on that tuple. >> >>> Also, the only means to stop a specfic PUA from updating >> that tuple is >>> through explictly disallowing that PUA from updating the >> state event for >>> that tuple, in the authorization policies in the ESC. >> >> As it now stands, this requires setting the composer policy in such >> a way that the unwanted presence information never gets composed >> into the presence document. >> >> Cheers, Aki >> >> >>> >>> Thanks /gf >>> >>> >>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 13:26:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28146 for ; Tue, 16 Sep 2003 13:26:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJao-0008VB-IK for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 13:26:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GHQMfi032680 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 13:26:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJaV-0008Lr-Ck; Tue, 16 Sep 2003 13:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJZk-0008KT-40 for sip@optimus.ietf.org; Tue, 16 Sep 2003 13:25:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28009 for ; Tue, 16 Sep 2003 13:25:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJZi-0006Ot-00 for sip@ietf.org; Tue, 16 Sep 2003 13:25:14 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zJZg-0006Nv-00 for sip@ietf.org; Tue, 16 Sep 2003 13:25:13 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8GHOdBo014918; Tue, 16 Sep 2003 10:24:40 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALP70789; Tue, 16 Sep 2003 10:12:44 -0700 (PDT) Date: Tue, 16 Sep 2003 09:27:19 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Kyzivat , Adam Roach , "'Rosen, Brian'" , sip@ietf.org To: Robert Sparks From: Rohan Mahy In-Reply-To: <1063720874.884.15.camel@RjS.localdomain> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: > On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > >> While I do not object to sending tel URIs to SIP proxies, I believe I >> already articulated some reasons why you might want to use sip or sips >> instead. >> >> 1) want to use SIPS > > Agreed! > >> 2) want to route the call to a specific domain that is not the domain >> of your first hop proxy. >> 3) want to invoke a loose router for services like transcoding or call >> history logging that have different tel URI handling rules than you >> want to use. > > Both 2 and 3 can be solved by pushing or preloading routes. OK, I was being sloppy. Looking at several options. A. INVITE tel:+14085264000 SIP/2.0 Route: A is not so good, because you have no control over what transcoders.com does with tel URLs (It might reject them, or send you a big bill). B. INVITE tel:+14085264000 SIP/2.0 Route: , B would probably work, but seems much more cumbersome than C. In addition, transcoders.com might forward all calls toward mci.com through some other domain (att.com) which might just take the tel URL and process it itself. C. INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 Route: C is explicit, it works, and it contains no extra info. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 16:20:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09902 for ; Tue, 16 Sep 2003 16:20:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMJC-0007IK-Ks for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 16:20:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GKKMdN028036 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 16:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMIu-0007EO-K5; Tue, 16 Sep 2003 16:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zMIR-0007DT-Rw for sip@optimus.ietf.org; Tue, 16 Sep 2003 16:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09837 for ; Tue, 16 Sep 2003 16:19:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zMIQ-0001m3-00 for sip@ietf.org; Tue, 16 Sep 2003 16:19:34 -0400 Received: from web41505.mail.yahoo.com ([66.218.93.88]) by ietf-mx with smtp (Exim 4.12) id 19zMIP-0001lU-00 for sip@ietf.org; Tue, 16 Sep 2003 16:19:33 -0400 Message-ID: <20030916201902.12400.qmail@web41505.mail.yahoo.com> Received: from [207.46.228.98] by web41505.mail.yahoo.com via HTTP; Tue, 16 Sep 2003 13:19:02 PDT Date: Tue, 16 Sep 2003 13:19:02 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 To: Aki Niemi , "ext George Foti \(QC/EMC\)" Cc: sip@ietf.org In-Reply-To: <3F673067.5090403@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I don't think this is something that the composer policy should necessarily try to solve. A more intelligent client implementation seems like the answer here. Collisions are a different issue and centralized policy is probably the only tenable solution. --- Aki Niemi wrote: > Hi George, > > I think the composer policy could simply be that the > newest publication > wins. That way the zombie PUA's state will not > propagate to the > watchers. Maybe this is something we ought to state > in the draft? > > But I think shutting down (remotely) such a zombie > publisher is somewhat > outside the scope of PUBLISH. Personally, I think > this problem may be > more appropriately solved by designing the PUA such > that it doesn't > zombie out, e.g., it takes user inactivity as a hint > and stops > publication refreshes. > > Other than that, I'm open to suggestions. The main > reason for not > including event segmentation and collision detection > to PUBLISH was that > it created a lot of (unnecessary) complexity. > > Cheers, > Aki > > On 16.09.2003 18:01, ext George Foti (QC/EMC): > > > Hi Aki, > > > > I think it should better explained in the draft > how will such a > > composer policy be set. If I have a PUA that is > configured to > > automatically publish presence information when I > logon and if I > > forgot to logoff, then how can I set the composer > policy to ignore > > that PUA or not include the information from that > PUA in this case. > > > > Should this not be standradized ?? > > > > Thx/gf > > > >> -----Original Message----- From: Aki Niemi > >> [mailto:aki.niemi@nokia.com] Sent: Tuesday, > September 16, 2003 > >> 10:55 AM To: George Foti (QC/EMC) Cc: > sip@ietf.org Subject: Re: > >> [Sip] Handling of identical Tuples by Multiple > PUAs - PUBLISH 00 > >> > >> > >> Hi George, > >> > >> Inline. > >> > >> On 15.09.2003 17:36, ext George Foti (QC/EMC): > >>> If multiple PUAs publishes information on the > same tuple, > >> does it mean > >>> that the ESC will have multiple entity-tags > associated with > >> that tuple, > >>> one for each publishing PUA. > >> > >> Each PUA publishes its own view of presence. Each > view is assigned > >> with an entity-tag, and each view can have tuples > that overlap > >> across other PUAs. Resolving these "collisions" > is at the hands of > >> the composer. For example, it could automatically > take preference > >> for the "newest" view on that tuple. > >> > >>> Also, the only means to stop a specfic PUA from > updating > >> that tuple is > >>> through explictly disallowing that PUA from > updating the > >> state event for > >>> that tuple, in the authorization policies in the > ESC. > >> > >> As it now stands, this requires setting the > composer policy in such > >> a way that the unwanted presence information > never gets composed > >> into the presence document. > >> > >> Cheers, Aki > >> > >> > >>> > >>> Thanks /gf > >>> > >>> > >>> > >> > >> > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 16 20:52:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21658 for ; Tue, 16 Sep 2003 20:52:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQYO-0000RQ-9Q for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 20:52:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H0qKCk001695 for sip-archive@odin.ietf.org; Tue, 16 Sep 2003 20:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQY6-0000Qj-V0; Tue, 16 Sep 2003 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zQXF-0000Op-Km for sip@optimus.ietf.org; Tue, 16 Sep 2003 20:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21621 for ; Tue, 16 Sep 2003 20:51:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zQXD-0005bO-00 for sip@ietf.org; Tue, 16 Sep 2003 20:51:07 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19zQXC-0005bK-00 for sip@ietf.org; Tue, 16 Sep 2003 20:51:06 -0400 Received: from [172.16.1.93] (helo=CCPU00250) by smtp.ccpu.com with smtp (Exim 4.20 #1 (Debian)) id 19zQXC-0001Wl-Pf; Tue, 16 Sep 2003 17:51:06 -0700 From: "Pavitra Krishnaswamy" To: , Cc: "Rashim Anand" Date: Tue, 16 Sep 2003 17:51:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <45730E094814E44488F789C1CDED27AE01E22A64@GBNEWP0758M.eu.ubiquity.net> Content-Transfer-Encoding: 7bit Subject: [Sip] Ambiguity in the SIP ABNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, There seems to be an ambiguity in the SIP ABNF See grammar below: ---------------------------------------------------------------- accept-range = media-range *(SEMI accept-param) media-range = ( "*/* / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string accept-param = ("q" EQUAL qvalue) / generic-param qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string ---------------------------------------------------------------- An instance of ambiguity is when the accept-range construct has the following structure - */*;abc=10;abc=10 In the above text string, "*/*" is the first part of media-range. But what about the text which follows - ";abc=10" ? It conforms to the grammar of m-parameter (by the rule "m-attribute EQUAL m-value" which can be of the type "token EQUAL token"). BUT it also conforms to the grammar of accept-param (by the rule "generic-param" which can be of the type "token EQUAL token"). Since *(SEMI m-parameter) as well as *(SEMI accept-param) can be optional, which grammar rules do the ";abc=10" texts belong to - the *(SEMI m-parameter) OR the *(SEMI accept-param)??? One way to get around the ambiguity would be to change the rule for media-range as follows - media-range = ( "*/* / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( HYPHEN m-parameter ) Has anyone else faced this issue? Any help on this would be appreciated. Thanks, pavitra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 02:28:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25641 for ; Wed, 17 Sep 2003 02:28:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVnV-0005BR-5q for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 02:28:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H6SH0a019925 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 02:28:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVnI-0005A9-Q2; Wed, 17 Sep 2003 02:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zVnF-000590-0e for sip@optimus.ietf.org; Wed, 17 Sep 2003 02:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25108 for ; Wed, 17 Sep 2003 02:27:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zVnB-0001WD-00 for sip@ietf.org; Wed, 17 Sep 2003 02:27:57 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 19zVnA-0001WA-00 for sip@ietf.org; Wed, 17 Sep 2003 02:27:56 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x2.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8H6Rpu25614 for ; Wed, 17 Sep 2003 09:27:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 09:27:50 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 09:27:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 17 Sep 2003 09:27:49 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017970FB@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN8fRP+WR5HlP3TSEWrYamTKqn5vQAZzl/Q To: , Cc: , , , X-OriginalArrivalTime: 17 Sep 2003 06:27:49.0915 (UTC) FILETIME=[D11BBEB0:01C37CE4] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I afraid C has the same problem as B. /Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, September 16, 2003 7:27 PM > To: Robert Sparks > Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: >=20 > > On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > > > >> While I do not object to sending tel URIs to SIP proxies,=20 > I believe I > >> already articulated some reasons why you might want to use=20 > sip or sips > >> instead. > >> > >> 1) want to use SIPS > > > > Agreed! > > > >> 2) want to route the call to a specific domain that is not=20 > the domain > >> of your first hop proxy. > >> 3) want to invoke a loose router for services like=20 > transcoding or call > >> history logging that have different tel URI handling rules than you > >> want to use. > > > > Both 2 and 3 can be solved by pushing or preloading routes. >=20 > OK, I was being sloppy. Looking at several options. >=20 > A. > INVITE tel:+14085264000 SIP/2.0 > Route: >=20 > A is not so good, because you have no control over what=20 > transcoders.com=20 > does with tel URLs (It might reject them, or send you a big bill). >=20 > B. >=20 > INVITE tel:+14085264000 SIP/2.0 > Route: , >=20 > B would probably work, but seems much more cumbersome than C. In=20 > addition, transcoders.com might forward all calls toward mci.com=20 > through some other domain (att.com) which might just take the tel URL=20 > and process it itself. >=20 > C. >=20 > INVITE sip:+14085264000@mci.com;user=3Dphone SIP/2.0 > Route: >=20 > C is explicit, it works, and it contains no extra info. >=20 > thanks, > -rohan >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 05:22:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02514 for ; Wed, 17 Sep 2003 05:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYVs-0003VB-7i for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:22:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H9MGXf013402 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYVe-0003Ta-G4; Wed, 17 Sep 2003 05:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYV2-0003Sy-Io for sip@optimus.ietf.org; Wed, 17 Sep 2003 05:21:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02483 for ; Wed, 17 Sep 2003 05:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zYUz-00035X-00 for sip@ietf.org; Wed, 17 Sep 2003 05:21:21 -0400 Received: from bay1-dav42.bay1.hotmail.com ([65.54.244.100] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19zYUy-00035C-00 for sip@ietf.org; Wed, 17 Sep 2003 05:21:20 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Sep 2003 02:20:50 -0700 Received: from 149.112.191.34 by bay1-dav42.bay1.hotmail.com with DAV; Wed, 17 Sep 2003 09:20:50 +0000 X-Originating-IP: [149.112.191.34] X-Originating-Email: [sharma_u@hotmail.com] Message-Id: <5.2.1.1.0.20030917144317.00aee7d8@127.0.0.1> X-Sender: sharma_u@hotmail.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 17 Sep 2003 14:51:31 +0530 To: sip@ietf.org From: Umesh Sharma Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Sep 2003 09:20:50.0550 (UTC) FILETIME=[FC72F160:01C37CFC] Subject: [Sip] SIP Call flow Document Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Could someone point towards a document containing SIP call flow scenarios. Thanks Umesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 05:27:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02656 for ; Wed, 17 Sep 2003 05:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYac-0003w8-2P for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:27:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H9R9rC015099 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYaV-0003km-BG; Wed, 17 Sep 2003 05:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYZw-0003jn-NA for sip@optimus.ietf.org; Wed, 17 Sep 2003 05:26:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02615 for ; Wed, 17 Sep 2003 05:26:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zYZt-00038u-00 for sip@ietf.org; Wed, 17 Sep 2003 05:26:25 -0400 Received: from 203-195-202-178.now-india.net.in ([203.195.202.178] helo=indiafire.intellinet-india.com) by ietf-mx with esmtp (Exim 4.12) id 19zYZr-00038n-00 for sip@ietf.org; Wed, 17 Sep 2003 05:26:24 -0400 Received: from sponge ([172.16.2.51]) by indiafire.intellinet-india.com (8.11.6/8.11.6) with SMTP id h8H9BRU19103; Wed, 17 Sep 2003 14:41:27 +0530 Message-ID: <025801c37cfe$bf0f3c50$330210ac@india.internal.net> From: "Keshava Murthy" To: , "Umesh Sharma" References: <5.2.1.1.0.20030917144317.00aee7d8@127.0.0.1> Subject: Re: [Sip] SIP Call flow Document Date: Wed, 17 Sep 2003 15:03:26 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit http://www.iptel.org/info/players/ietf/callflows/ ----- Original Message ----- From: "Umesh Sharma" To: Sent: Wednesday, September 17, 2003 2:51 PM Subject: [Sip] SIP Call flow Document > Hi > > Could someone point towards a document containing SIP call flow scenarios. > > Thanks > Umesh > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 05:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02949 for ; Wed, 17 Sep 2003 05:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYhQ-0004Ij-VE for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:34:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H9YCwB016253 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 05:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYhG-0004DE-KQ; Wed, 17 Sep 2003 05:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYgR-0004CH-8i for sip@optimus.ietf.org; Wed, 17 Sep 2003 05:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02882 for ; Wed, 17 Sep 2003 05:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zYgN-0003Dx-00 for sip@ietf.org; Wed, 17 Sep 2003 05:33:07 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19zYgN-0003Df-00 for sip@ietf.org; Wed, 17 Sep 2003 05:33:07 -0400 Received: from Natarajucl1127 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HLC00GTYQDFTQ@mta0.huawei.com> for sip@ietf.org; Wed, 17 Sep 2003 17:29:43 +0800 (CST) Date: Wed, 17 Sep 2003 15:03:39 +0530 From: "Nataraju A.B." Subject: Re: [Sip] SIP Call flow Document To: Umesh Sharma , sip@ietf.org Message-id: <002f01c37cfe$c88a4c70$3d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5.2.1.1.0.20030917144317.00aee7d8@127.0.0.1> Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT u can refer following drafts in ietf.org draft-ietf-sipping-pstn-call-flows-01 draft-ietf-sipping-basic-call-flows-01 also from CISCO web site u can get a very good doc on call folws.. Regards, Natraj ----- Original Message ----- From: "Umesh Sharma" To: Sent: Wednesday, September 17, 2003 2:51 PM Subject: [Sip] SIP Call flow Document > Hi > > Could someone point towards a document containing SIP call flow scenarios. > > Thanks > Umesh > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 07:25:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06292 for ; Wed, 17 Sep 2003 07:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQy-00082I-QT for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HBPKtA030704 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQh-0007xC-NY; Wed, 17 Sep 2003 07:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zHPt-0003G8-6m for sip@optimus.ietf.org; Tue, 16 Sep 2003 11:06:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20618 for ; Tue, 16 Sep 2003 11:06:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zHPq-0003sE-00 for sip@ietf.org; Tue, 16 Sep 2003 11:06:54 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19zHPq-0003rV-00 for sip@ietf.org; Tue, 16 Sep 2003 11:06:54 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8GF6NAP029380; Tue, 16 Sep 2003 10:06:23 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 16 Sep 2003 10:06:21 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C921F@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'Aki Niemi'" Cc: sip@ietf.org Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Date: Tue, 16 Sep 2003 10:01:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Aki, I think it should better explained in the draft how will such a composer policy be set. If I have a PUA that is configured to automatically publish presence information when I logon and if I forgot to logoff, then how can I set the composer policy to ignore that PUA or not include the information from that PUA in this case. Should this not be standradized ?? Thx/gf > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Tuesday, September 16, 2003 10:55 AM > To: George Foti (QC/EMC) > Cc: sip@ietf.org > Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - > PUBLISH 00 > > > Hi George, > > Inline. > > On 15.09.2003 17:36, ext George Foti (QC/EMC): > > If multiple PUAs publishes information on the same tuple, > does it mean > > that the ESC will have multiple entity-tags associated with > that tuple, > > one for each publishing PUA. > > Each PUA publishes its own view of presence. Each view is > assigned with > an entity-tag, and each view can have tuples that overlap > across other > PUAs. Resolving these "collisions" is at the hands of the > composer. For > example, it could automatically take preference for the > "newest" view on > that tuple. > > > Also, the only means to stop a specfic PUA from updating > that tuple is > > through explictly disallowing that PUA from updating the > state event for > > that tuple, in the authorization policies in the ESC. > > As it now stands, this requires setting the composer policy in such a > way that the unwanted presence information never gets > composed into the > presence document. > > Cheers, > Aki > > > > > > Thanks > > /gf > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 08:12:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06293 for ; Wed, 17 Sep 2003 07:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQy-00082K-RG for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HBPKS4030707 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQk-0007yS-4D; Wed, 17 Sep 2003 07:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zJT7-00087L-NY for sip@optimus.ietf.org; Tue, 16 Sep 2003 13:18:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27637 for ; Tue, 16 Sep 2003 13:18:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zJT5-0006Gc-00 for sip@ietf.org; Tue, 16 Sep 2003 13:18:23 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19zJT5-0006GQ-00 for sip@ietf.org; Tue, 16 Sep 2003 13:18:23 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8GHHrAP023246; Tue, 16 Sep 2003 12:17:53 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 16 Sep 2003 12:17:50 -0500 Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C9220@lmc37.lmc.ericsson.se> From: "George Foti (QC/EMC)" To: "'Aki Niemi'" Cc: sip@ietf.org Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Date: Tue, 16 Sep 2003 12:13:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Aki, Well the newest publication policy wont win in all cases. Certainly, not in my example, as the PUA on which I forgot to logoff will become the *newest* once in a while. I was hoping, that similar to the usage of XCAP for setting authorization policies, we have a standardized procedure to control (ignore/consider) policy composers at the PUA level. May be that should be added on to the authorization draft! Forget about segementation, collision detection, etc That is still an option for implementations but need not be standradized. Thx/gf > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Tuesday, September 16, 2003 11:47 AM > To: George Foti (QC/EMC) > Cc: sip@ietf.org > Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - > PUBLIS H 00 > > > Hi George, > > I think the composer policy could simply be that the newest > publication > wins. That way the zombie PUA's state will not propagate to the > watchers. Maybe this is something we ought to state in the draft? > > But I think shutting down (remotely) such a zombie publisher > is somewhat > outside the scope of PUBLISH. Personally, I think this problem may be > more appropriately solved by designing the PUA such that it doesn't > zombie out, e.g., it takes user inactivity as a hint and stops > publication refreshes. > > Other than that, I'm open to suggestions. The main reason for not > including event segmentation and collision detection to > PUBLISH was that > it created a lot of (unnecessary) complexity. > > Cheers, > Aki > > On 16.09.2003 18:01, ext George Foti (QC/EMC): > > > Hi Aki, > > > > I think it should better explained in the draft how will such a > > composer policy be set. If I have a PUA that is configured to > > automatically publish presence information when I logon and if I > > forgot to logoff, then how can I set the composer policy to ignore > > that PUA or not include the information from that PUA in this case. > > > > Should this not be standradized ?? > > > > Thx/gf > > > >> -----Original Message----- From: Aki Niemi > >> [mailto:aki.niemi@nokia.com] Sent: Tuesday, September 16, 2003 > >> 10:55 AM To: George Foti (QC/EMC) Cc: sip@ietf.org Subject: Re: > >> [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 > >> > >> > >> Hi George, > >> > >> Inline. > >> > >> On 15.09.2003 17:36, ext George Foti (QC/EMC): > >>> If multiple PUAs publishes information on the same tuple, > >> does it mean > >>> that the ESC will have multiple entity-tags associated with > >> that tuple, > >>> one for each publishing PUA. > >> > >> Each PUA publishes its own view of presence. Each view is assigned > >> with an entity-tag, and each view can have tuples that overlap > >> across other PUAs. Resolving these "collisions" is at the hands of > >> the composer. For example, it could automatically take preference > >> for the "newest" view on that tuple. > >> > >>> Also, the only means to stop a specfic PUA from updating > >> that tuple is > >>> through explictly disallowing that PUA from updating the > >> state event for > >>> that tuple, in the authorization policies in the ESC. > >> > >> As it now stands, this requires setting the composer policy in such > >> a way that the unwanted presence information never gets composed > >> into the presence document. > >> > >> Cheers, Aki > >> > >> > >>> > >>> Thanks /gf > >>> > >>> > >>> > >> > >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 08:12:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06295 for ; Wed, 17 Sep 2003 07:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQy-00082J-Qt for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HBPKC7030709 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 07:25:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zaQi-0007xU-St; Wed, 17 Sep 2003 07:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zI6v-00051w-NB for sip@optimus.ietf.org; Tue, 16 Sep 2003 11:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23221 for ; Tue, 16 Sep 2003 11:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zI6u-0004h5-00 for sip@ietf.org; Tue, 16 Sep 2003 11:51:24 -0400 Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 19zI6t-0004h2-00 for sip@ietf.org; Tue, 16 Sep 2003 11:51:23 -0400 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19zI6V-0005xB-00 for ; Tue, 16 Sep 2003 17:50:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: sip@ietf.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19zI6U-0005x3-00 for ; Tue, 16 Sep 2003 17:50:58 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19zI6i-0006Zv-00 for ; Tue, 16 Sep 2003 17:51:12 +0200 From: "Matt Guertin" Date: Tue, 16 Sep 2003 11:52:19 -0400 Lines: 341 Message-ID: References: <313680C9A886D511A06000204840E1CF070B5E5D@whq-msgusr-02.pit.comms.marconi.com> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] Re: RE: Cannot REGISTER Ad Hoc SIP Conference? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think I now understand what's happening. We can get this to work by not using authentication when REGISTERing the generated Conference URIs. But that is not a practical solution because we are selling a secure product to customers who will be using SIP Proxy Servers with security/authentication enabled. We would *like* to use the REGISTER technique because we can then leverage presence servers to tell SIP users (who SUBSCRIBE) that the conference is "active". But this is more like a nice-to-have, anyway. We can also get this to work if we don't perform REGISTER requests for the generated conference URIs, and the Proxy Server is configured to forward these to the Conference Bridge (as you just described). But then: 1) why even go through the effort of generating Conference URIs? 2) what if the customer's SIP proxy server doesn't have this capability or they want the "security" of having all INVITE requests authenticated against registered SIP entities (...both of which seem highly unlikely)? and 3) We lose the presence capability. Bottom line is this: now that I see how everything actually works in the _real_ world (so to speak), I just don't understand the logic in the SIP conferencing draft specs about INVITE requests with generated Conference URIs. They could never really work in a secure business environment, because they would never make it past authentication. Therefore, all INVITE requests MUST be for long-lived URIs (such as the Conference factory URI), _OR_ the SIP proxy servers must be configured to allow routing based on 1) prefix, or 2) domain/realm, or 3) some combination. Am I missing something? Isn't there some way to securely register SIP Conference URIs? -Matt. "Rosen, Brian" wrote in message news:313680C9A886D511A06000204840E1CF070B5E5D@whq-msgusr-02.pit.comms.marconi.com... > Commenting on my own message. > > What is the difference between a proxy server that > forwards all calls in it's domain to a single UA, > plus a UA that accepts all usernames sent to it vs > a UA that accepts all usernames sent to it? > Answer - nothing. > > Just allow your UA to have a DNS hostname, and have > the proxy route calls to you (ie *@hostname.example.com). > No need to register. The existing proxy doesn't know, > and doesn't care, that the next hop isn't a proxy server, > it's just the next hop. > > Brian > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, September 11, 2003 4:32 PM > > To: 'Matt Guertin'; 'sip@ietf.org' > > Subject: [Sip] RE: Cannot REGISTER Ad Hoc SIP Conference? > > > > > > Well, our proxy server allows rule based routing with regexps. > > I've seen others that have similar capabilities. > > I've also seen registrars that can be configured to accept > > certain classes of registrations without username/password challenges. > > This is BCP stuff, not specification work, but we might have to > > do it. > > > > One easy way for you to solve your problem is to implement your > > own proxy server which does routing the way you want it. > > Then, the existing proxy servers can have simple routing for > > "conferencing.example.com", for example. Nearly every proxy > > can handle that. > > > > Brian > > -----Original Message----- > > From: Matt Guertin [mailto:MGuertin@sonexis.com] > > Sent: Thursday, September 11, 2003 4:12 PM > > To: 'Rosen, Brian'; 'sip@ietf.org' > > Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? > > > > > > Hi Brian, > > Our product has a web-based interface for setting up > > conferences. If you select that you want to start a conference > > "now" we declare it to be an "ad hoc" conference. But we > > still make the user specify an end time. This is the main, > > and I think only, difference between your definition and ours. > > I agree about conference-uris, it doesn't really matter how > > they come into existence, for this discussion, once you have > > one, you have one. Each instance of a conference has a unique > > conference uri. All of this is clear in the specs. > > The problem is that let's say, we send out email saying that > > conference so-and-so is starting now (or at 1:00PM - it > > doesn't really matter). There is a SIP uri in the email > > invitation. And at the specified time, the caller uses > > his/her softphone to dial in. But the proxy server needs > > to understand that this sip uri needs to go to the conference > > bridge. The problem we have right now, is that we don't > > control the proxy servers. So how can we follow the standards > > (or draft standards) and still get this to work? I don't know > > of any sip proxy server which allows the flexibility you > > describe (i.e., rule-based / policy-based routing). Trying to > > register the conference-uri's didn't work because of > > authentication - each conference uri can't have a unique > > username / password associated with it - the overhead would > > kill us. I don't see how the REFER style would work for large > > conferences, and we use a participant dial-in model, anyway. > > I thought that the proxy servers would be smart enough to > > understand that the contact fields can be used as aliases > > when the 'isfocus' flag is used. But unfortunately not. > > This all boils down to resource allocation. Since audio ports > > are a valuable resource, we can't tie them up unless we know > > they are being used. Hence, the need for scheduling. If a > > conference goes over its allocated time slot, it keeps going > > as long as there are audio ports available. If someone else > > scheduled a conference right after yours and there are too > > few audio ports, the expired conference is stopped so that the > > next group can use the audio ports. What if you had an > > important conference scheduled, and had some important people > > on the call, but you couldn't start the conference because the > > people in the earlier conference didn't want to end theirs? > > It's a lot like a conference room scheduling program, there's > > the rooms and there are people who can fit in the room, and > > there are time ranges. Scheduled audio conferences are > > becoming extremely popular and going to be around for a long > > time, because they are more practical in most business > > applications than open-ended and ad hoc conferences. > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, September 11, 2003 2:58 PM > > To: 'Matt Guertin'; 'sip@ietf.org' > > Subject: RE: Cannot REGISTER Ad Hoc SIP Conference? > > > > > > Matt > > Generally, when we say "ad hoc conference", we mean something that > > happens at the spur of the moment; it's not scheduled. > > A scheduled conference is something else. > > Really, there is very little difference, at least in terms of how > > the mechanisms work: > > 1) You go to the conference factory to get a conference uri > > 2) You either hand it out, and people INVITE themselves in, > > or you REFER people to the conference-id > > The important point is that the conference factory uri is well > > known, and generally doesn't change, but the conference-uri > > is different for every conference. > > From the point of view of a participant, a conference uri is > > just a uri. How it gets it (by INVITE to conference factory > > uri, or email, or "good guess", doesn't matter. It has one. > > The crux of your question, as stated, was how the proxy server > > routes calls. I gave one answer, you have another. In mine, > > the proxy server has a routing rule based on a pattern match > > on the uri. For example, it might say that any username starting > > with "bridge2-" is routed to a particular conference bridge. > > Then conference uris handed out by the conference factory might > > be something like "bridge2-922ac44a00@example.com", but they > > could also look like "bridge-2-weekly-sales-conf@example.com". > > Your suggestion has the conference factory registering each uri > > it hands out. That also will work. Hybrids will work. For example, > > I could register "weekly-sales-call@example.com" as an alias for > > "bridge2-99n77h7h7777@example.com", if my proxy server allowed > > aliases. I don't think that we want to have locked down > > specifications > > for this kind of thing, at least right now. I think a stand-alone > > conference server, which was not a proxy server, might want to be > > able to register every conference, but it might want to be > > configurable > > so that such a mechanism was controllable. > > I'll point out that registration isn't particularly desirable for > > what I call an ad-hoc conference, primarily because I don't want to > > incur the registration delay between the time I press the > > "CONF" button > > on my phone, and the time the party I'm calling's phone rings. > > One thing I'm curious about. Have you ever used a conference bridge, > > or service, that literally kicked you out at the scheduled time? > > They are pretty uncommon, and, in my own experience, frustrating. > > Meetings that conclude on schedule are pretty rare, around > > here anyway. > > Nearly every conference service I've ever used does not enforce a > > time limit. I've seen some video bridges that do that. Not a matter > > for standardization of course; if you want to build one that way, I > > don't want to stop you :) > > Brian > > -----Original Message----- > > From: Matt Guertin [mailto:MGuertin@sonexis.com] > > Sent: Thursday, September 11, 2003 2:36 PM > > To: 'Brian.Rosen@marconi.com'; 'sip@ietf.org' > > Subject: Re: Cannot REGISTER Ad Hoc SIP Conference? > > > > > > Hi Brian, > > Thanks for taking the time to respond to my posting. What you > > describe > > sounds like it will work for very small conferences. > > However, we support > > "open-ended" conferences, where anyone who knows the > > "conference-id" can get > > > > in, even if the host does not explicitly invite them. In > > addition, for a > > scheduled conference, the host can send out invitations to > > dozens of people, > > > > knowing that only maybe half will be able to participate. But > > the real > > "gotcha" here is that the conference always has an end time. > > For example, > > if there is a 1:00PM sales meeting, it will go until maybe > > 2:00PM. Then > > that's it. There may be another one tomorrow, or next week > > at the same > > time, but the conference is over until then. You wouldn't > > want to tie up > > the ports on a conference bridge for a conference that's > > over. You would > > let someone else use them for another conference, and/or the > > earlier host to > > > > use them again for some other meeting. > > I don't see why the SIP proxy server can't just forward the > > requests for the > > > > additional URIs in the contact field. That would solve all > > the problems > > associated with "time-based" conferences. 1) The SIP proxy > > would know that > > it is dealing with a conference bridge, which will have many > > "aliases" for > > conferences. 2) The conference bridge is still looked at as a > > single user > > agent, with a single username and password. For example: > > REGISTER sip:10.1.4.35:5060 SIP/2.0 > > From: sip:2038@10.20.20.201:5060 > > To: sip:2038@10.20.20.201 > > Contact: ;isfocus > > Contact: ;isfocus > > Contact: ;isfocus > > Call-ID: 12707648587750000@SONEXIS-C723CFA > > CSeq: 85 REGISTER > > Content-Length: 0 > > Expires: 1200 > > Proxy-Authorization: Digest username="2038",realm=... > > > > > > The above might represent registering three concurrent > > conferences going on > > at a conference bridge called 2038. Of course, the > > conference bridge would > > only register "active" conferences, and unregister them when > > they are over. > > And when someone issued an INVITE request to the conference > > bridge it would > > be responsible for placing the participant in the correct conference. > > -Matt. > > > > > > > > "Rosen, Brian" wrote in message > > news:313680C9A886D511A06000204840E1CF070B5E35@whq-msgusr-02.pi > > t.comms.marcon > > > > i.com... > > > We make this work roughly (code is evolving) the following way: > > > We provision (actually, it's learned) the name of the local > > > conference factory uri. This is a fixed uri, and is > > > local to the domain of the conference host. > > > The conference host registers with this well known > > > address. It is an actual "user" in the system. > > > We start with a 1on1 call, between the first two parties > > > When we add the third party, the UA initiating this action > > > sends an INVITE to the conference factory uri. > > > The conference host returns a Contact header with > > > a unique conference uri. The conference uri is > > > constructed using a pattern known to the outgoing proxy > > > The UA initiating the conference REFERs all three parties to > > > the conference using the conference uri > > > Invites with a username matching the pattern are routed to > > > the conference host > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Matt Guertin [mailto:mguertin@sonexis.com] > > > > Sent: Wednesday, September 10, 2003 11:20 AM > > > > To: sip@ietf.org > > > > Subject: [Sip] Cannot REGISTER Ad Hoc SIP Conference? > > > > > > > > > > > > I read through all the SIP specs that I know of, and > > believe to have > > > > implement our SIP Conference "focus" correctly. We have what > > > > is sometimes > > > > referred to as a SIP Conference Bridge Marshal Server (in > > vocal speak > > > > anyway). When I go to do a REGISTER request, the > > > > authentication fails, > > > > because the username/password does not match with the > > > > ConferenceURI. I can > > > > only register with ConferenceURIs which have > > > > usernames/password provisioned. > > > > This doesn't work for Ad Hoc conferences, and even for > > > > scheduled conferences > > > > for that matter. It is unacceptable in a practical > > > > application to send mail > > > > to an administrator every time a new conference is scheduled > > > > to generate a > > > > username/password for the conference. The administrator may > > > > not get around > > > > to adding the new username/password for hours or even days. > > > > Am I missing > > > > something? We are using the contact field the way it is > > > > spec'ed in the > > > > conference framework draft (ie., the isfocus flag is set). > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 09:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10528 for ; Wed, 17 Sep 2003 09:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcLm-0005qE-SZ for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 09:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HDS6QY022448 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 09:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcLi-0005pV-BM; Wed, 17 Sep 2003 09:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcKq-0005mM-Uq for sip@optimus.ietf.org; Wed, 17 Sep 2003 09:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10495 for ; Wed, 17 Sep 2003 09:26:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcKp-0005rx-00 for sip@ietf.org; Wed, 17 Sep 2003 09:27:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zcKo-0005rn-00 for sip@ietf.org; Wed, 17 Sep 2003 09:27:06 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 17 Sep 2003 06:23:16 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8HDQXZg008421; Wed, 17 Sep 2003 06:26:34 -0700 (PDT) Received: from cisco.com (dhcp-10-86-165-187.cisco.com [10.86.165.187]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACL75365; Wed, 17 Sep 2003 09:26:32 -0400 (EDT) Message-ID: <3F686108.2070003@cisco.com> Date: Wed, 17 Sep 2003 09:26:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Rosen, Brian'" , sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <7AEF8EDE-E54D-11D7-9721-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > I agree with all of Paul's comments except one inline... ... >> The best solution to me is for the UAC to be configured to always turn >> dial strings into some kind of valid telephone-subscriber string. If >> it can't turn it into a global-phone-number, then it should turn it >> into a local-phone-number, using some configured phone-context. When >> there is no better solution, it can simply paste a phone-context onto >> the end of the dial string. >> >> Once this is done, it must turn this into a URL. It can make a tel: >> url trivially. Or it can make a sip or sips url with user=phone by >> supplying a configured domain name. Of these, I prefer tel, because >> using sip doesn't seem to add anything and it further constrains where >> and how transformations can be made. (Phone-context in a tel can be >> translated by anybody that understands it, but in a sip url can only >> be translated by a server that is responsible for the domain.) > > While I do not object to sending tel URIs to SIP proxies, I believe I > already articulated some reasons why you might want to use sip or sips > instead. > > 1) want to use SIPS > 2) want to route the call to a specific domain that is not the domain of > your first hop proxy. > 3) want to invoke a loose router for services like transcoding or call > history logging that have different tel URI handling rules than you want > to use. I prefer tel: unless there is some compelling reason to do otherwise. The above may be compelling. In those cases, I think it is probably better to form the tel: url first, put it in the To header, then translate to sip or sips to achieve intended result and put that in the request url. In effect, the phone is then acting as its own intelligent first hop proxy doing this translation. Doing it that way gives the recipient the best chance of representing the intended address. Of course there will be situations where other treatment is needed, so there is no one best answer here - just best practice. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 12:33:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19539 for ; Wed, 17 Sep 2003 12:33:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfEb-0005g3-2U for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 12:32:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HGWrT5021820 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 12:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfDn-0005ez-Bl; Wed, 17 Sep 2003 12:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfDO-0005eV-9f for sip@optimus.ietf.org; Wed, 17 Sep 2003 12:31:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19506 for ; Wed, 17 Sep 2003 12:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zfDM-0000mI-00 for sip@ietf.org; Wed, 17 Sep 2003 12:31:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zfDL-0000lE-00 for sip@ietf.org; Wed, 17 Sep 2003 12:31:36 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2003 09:31:16 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8HGV1qP015444; Wed, 17 Sep 2003 09:31:02 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALQ75938; Wed, 17 Sep 2003 09:18:53 -0700 (PDT) Date: Wed, 17 Sep 2003 09:34:41 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , , , , To: From: Rohan Mahy In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017970FB@esebe019.ntc.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, September 16, 2003, at 11:27 PM, wrote: > I afraid C has the same problem as B. No, it doesn't. Nobody except a server authoritative for mci.com is allowed to interpret that URI. This is very clear for SIP and SIPS URIs. We don't have this kind of restriction on tel URIs. thanks, -rohan > /Hisham > > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Tuesday, September 16, 2003 7:27 PM >> To: Robert Sparks >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; sip@ietf.org >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone >> >> >> >> On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: >> >>> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: >>> >>>> While I do not object to sending tel URIs to SIP proxies, >> I believe I >>>> already articulated some reasons why you might want to use >> sip or sips >>>> instead. >>>> >>>> 1) want to use SIPS >>> >>> Agreed! >>> >>>> 2) want to route the call to a specific domain that is not >> the domain >>>> of your first hop proxy. >>>> 3) want to invoke a loose router for services like >> transcoding or call >>>> history logging that have different tel URI handling rules than you >>>> want to use. >>> >>> Both 2 and 3 can be solved by pushing or preloading routes. >> >> OK, I was being sloppy. Looking at several options. >> >> A. >> INVITE tel:+14085264000 SIP/2.0 >> Route: >> >> A is not so good, because you have no control over what >> transcoders.com >> does with tel URLs (It might reject them, or send you a big bill). >> >> B. >> >> INVITE tel:+14085264000 SIP/2.0 >> Route: , >> >> B would probably work, but seems much more cumbersome than C. In >> addition, transcoders.com might forward all calls toward mci.com >> through some other domain (att.com) which might just take the tel URL >> and process it itself. >> >> C. >> >> INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 >> Route: >> >> C is explicit, it works, and it contains no extra info. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 17 23:06:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11251 for ; Wed, 17 Sep 2003 23:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zp7h-0000Bl-8Z for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 23:06:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I36PQw000724 for sip-archive@odin.ietf.org; Wed, 17 Sep 2003 23:06:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zp7M-0000B0-Ff; Wed, 17 Sep 2003 23:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zp6S-0000AE-NU for sip@optimus.ietf.org; Wed, 17 Sep 2003 23:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11229 for ; Wed, 17 Sep 2003 23:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zp6P-0007Pk-00 for sip@ietf.org; Wed, 17 Sep 2003 23:05:05 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19zp6J-0007Ph-00 for sip@ietf.org; Wed, 17 Sep 2003 23:05:03 -0400 Received: from huawei.com (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HLE00LQY396JF@mta2.huawei.com> for sip@ietf.org; Thu, 18 Sep 2003 11:05:31 +0800 (CST) Received: from huawei.com ([172.17.1.59]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HLE00HZ6396FU@mta2.huawei.com> for sip@ietf.org; Thu, 18 Sep 2003 11:05:30 +0800 (CST) Received: from [211.92.72.42] by mailb.huawei.com (mshttpd); Thu, 18 Sep 2003 11:01:16 +0800 Date: Thu, 18 Sep 2003 11:01:16 +0800 From: prasanna 70008 Subject: Re: [Sip] Ambiguity in the SIP ABNF To: Pavitra Krishnaswamy Cc: sip-implementors@cs.columbia.edu, sip@ietf.org, Rashim Anand Message-id: <11aa512099.1209911aa5@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Pavitra, Yes this is an ambiguity. However this is clarified in RFC-2616's (HTTP) section on the accept-params. The media range params and the accept params are seperated by the q parameter. Cheers, Prasanna ----- Original Message ----- From: Pavitra Krishnaswamy Date: Wednesday, September 17, 2003 8:51 am Subject: [Sip] Ambiguity in the SIP ABNF > Hi, > > There seems to be an ambiguity in the SIP ABNF > > See grammar below: > > ---------------------------------------------------------------- > accept-range = media-range *(SEMI accept-param) > media-range = ( "*/* > / ( m-type SLASH "*" ) > / ( m-type SLASH m-subtype ) > ) *( SEMI m-parameter ) > > m-parameter = m-attribute EQUAL m-value > m-attribute = token > m-value = token / quoted-string > > accept-param = ("q" EQUAL qvalue) / generic-param > qvalue = ( "0" [ "." 0*3DIGIT ] ) > / ( "1" [ "." 0*3("0") ] ) > > generic-param = token [ EQUAL gen-value ] > gen-value = token / host / quoted-string > > ---------------------------------------------------------------- > > > An instance of ambiguity is when the accept-range construct has the > following structure - > > */*;abc=10;abc=10 > > In the above text string, "*/*" is the first part of media-range. > > But what about the text which follows - ";abc=10" ? It conforms to the > grammar of m-parameter (by the rule "m-attribute EQUAL m-value" > which can be > of the type "token EQUAL token"). BUT it also conforms to the > grammar of > accept-param (by the rule "generic-param" which can be of the type > "tokenEQUAL token"). > > Since *(SEMI m-parameter) as well as *(SEMI accept-param) can be > optional,which grammar rules do the ";abc=10" texts belong to - > the *(SEMI > m-parameter) OR the *(SEMI accept-param)??? > > One way to get around the ambiguity would be to change the rule for > media-range as follows - > > media-range = ( "*/* > / ( m-type SLASH "*" ) > / ( m-type SLASH m-subtype ) > ) *( HYPHEN m-parameter ) > > Has anyone else faced this issue? Any help on this would be > appreciated. > > Thanks, > pavitra > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 02:39:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29159 for ; Thu, 18 Sep 2003 02:39:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsRg-0007SE-77 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 02:39:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I6dGE1028650 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 02:39:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsRT-0007R0-KA; Thu, 18 Sep 2003 02:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsRC-0007QX-GP for sip@optimus.ietf.org; Thu, 18 Sep 2003 02:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29123 for ; Thu, 18 Sep 2003 02:38:38 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zsR8-0001Yu-00 for sip@ietf.org; Thu, 18 Sep 2003 02:38:42 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zsR8-0001Yr-00 for sip@ietf.org; Thu, 18 Sep 2003 02:38:42 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8I6cgk03499 for ; Thu, 18 Sep 2003 09:38:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 09:38:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 09:38:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 18 Sep 2003 09:38:40 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797102@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN9ORmrUbPLoUwsS8aukvUoKS9WIgAdPheA To: Cc: , , , , X-OriginalArrivalTime: 18 Sep 2003 06:38:40.0729 (UTC) FILETIME=[7F6FD490:01C37DAF] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, September 17, 2003 7:35 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; adam@dynamicsoft.com; > Brian.Rosen@marconi.com; sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > On Tuesday, September 16, 2003, at 11:27 PM,=20 > wrote: >=20 > > I afraid C has the same problem as B. >=20 > No, it doesn't. Nobody except a server authoritative for mci.com is=20 > allowed to interpret that URI. This is very clear for SIP and SIPS=20 > URIs. We don't have this kind of restriction on tel URIs. Section 16.5 states: "If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6)." Section 16.6 states (step 6): "A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination" and step 7: "The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI" Using your example C below, there is nothing restricting transcoder.com = from forwarding the request to att.com even if the request-URI is a sip = URI. Its transcoder.com local policy. /Hisham >=20 > thanks, > -rohan >=20 > > /Hisham > > > > > >> -----Original Message----- > >> From: ext Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Tuesday, September 16, 2003 7:27 PM > >> To: Robert Sparks > >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; sip@ietf.org > >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >> > >> > >> > >> On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: > >> > >>> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > >>> > >>>> While I do not object to sending tel URIs to SIP proxies, > >> I believe I > >>>> already articulated some reasons why you might want to use > >> sip or sips > >>>> instead. > >>>> > >>>> 1) want to use SIPS > >>> > >>> Agreed! > >>> > >>>> 2) want to route the call to a specific domain that is not > >> the domain > >>>> of your first hop proxy. > >>>> 3) want to invoke a loose router for services like > >> transcoding or call > >>>> history logging that have different tel URI handling=20 > rules than you > >>>> want to use. > >>> > >>> Both 2 and 3 can be solved by pushing or preloading routes. > >> > >> OK, I was being sloppy. Looking at several options. > >> > >> A. > >> INVITE tel:+14085264000 SIP/2.0 > >> Route: > >> > >> A is not so good, because you have no control over what > >> transcoders.com > >> does with tel URLs (It might reject them, or send you a big bill). > >> > >> B. > >> > >> INVITE tel:+14085264000 SIP/2.0 > >> Route: , > >> > >> B would probably work, but seems much more cumbersome than C. In > >> addition, transcoders.com might forward all calls toward mci.com > >> through some other domain (att.com) which might just take=20 > the tel URL > >> and process it itself. > >> > >> C. > >> > >> INVITE sip:+14085264000@mci.com;user=3Dphone SIP/2.0 > >> Route: > >> > >> C is explicit, it works, and it contains no extra info. > >> > >> thanks, > >> -rohan > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 04:32:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02154 for ; Thu, 18 Sep 2003 04:32:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuD9-0003dT-2Q for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 04:32:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I8WMEK013913 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 04:32:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuCq-0003bs-U1; Thu, 18 Sep 2003 04:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuCa-0003bG-GG for sip@optimus.ietf.org; Thu, 18 Sep 2003 04:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02137 for ; Thu, 18 Sep 2003 04:31:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zuCX-0002be-00 for sip@ietf.org; Thu, 18 Sep 2003 04:31:45 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19zuCW-0002bJ-00 for sip@ietf.org; Thu, 18 Sep 2003 04:31:45 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id E65E933E25 for ; Thu, 18 Sep 2003 10:31:15 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 8D5203F412; Thu, 18 Sep 2003 10:44:14 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003091810311511357 ; Thu, 18 Sep 2003 10:31:15 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 6D7403F412; Thu, 18 Sep 2003 10:44:14 +0200 (CEST) Received: from pat4135 (pat4135.int-evry.fr [157.159.100.240]) by molure.int-evry.fr (Postfix) with ESMTP id A862FC2203; Thu, 18 Sep 2003 10:31:15 +0200 (CEST) From: "Noel Crespi" To: Cc: "'chadli'" Date: Thu, 18 Sep 2003 10:31:17 +0200 Message-ID: <005801c37dbf$3a9f9bb0$f0649f9d@intevry.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C37DCF.FE286BB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Responses path in SIP. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C37DCF.FE286BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 In the RFC3261 there seems to be a contradiction about the path taken by the responses in a SIP transaction. It is in clear if the responses MUST or SHOULD follow the path defined by the Via header field.=20 =20 Different sections in RFC3261 mandate that responses MUST be sent to the location indicated in the topmost Via header field value, eg: - In section 8.1.1.7: "The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent " =20 - In section 16.7: "The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value" - In section 16.11: "If that address matches the proxy,(it equals a value this proxy has inserted into previous requests)the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value" =20 However section 20.42 states that: "The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses"=20 =20 So, MUST or SHOULD responses in a SIP transaction follow the path defined by the Via header field? =20 Regards. Y.Chadli / N.Crespi INT/GET - Institut National des T=E9l=E9communications ------=_NextPart_000_0059_01C37DCF.FE286BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,=20
In the=20 RFC3261 there seems to be a = contradiction about the path taken by the responses in a SIP=20 transaction. It is in=20 clear if=20 the responses MUST or=20 SHOULD follow = the path=20 defined by the Via header field. 
 
Different sections=20 in RFC3261 mandate that responses MUST be sent to the location indicated = in the=20 topmost Via header field value, eg:
-=20 In section 8.1.1.7: = "The Via=20 header field indicates the transport used for the transaction and=20 identifies the location where the response is to be=20 sent "  
- In section=20 16.7: "The proxy MUST pass the response to the = server=20 transaction associated with the = response=20 context. This will result in the = response=20 being sent to the location now indicated in the=20 topmost Via header field value"
- In section=20 16.11: "If that = address=20 matches the proxy,(it equals a value this proxy has inserted into = previous=20 requests)the proxy MUST remove that header field value from the response = and forward the result to the = location=20 indicated in the next Via header field value"
 
However=20 section 20.42 states that: "The=20 Via header field indicates the path taken by the request so=20 far and indicates the path that should be followed in routing=20 responses" 
 
So,  MUST or SHOULD responses in a = SIP=20 transaction follow  the path defined by the Via header = field?
 
Regards.
Y.Chadli /=20 N.Crespi
INT/GET - = Institut National des=20 T=E9l=E9communications
------=_NextPart_000_0059_01C37DCF.FE286BB0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 06:26:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05741 for ; Thu, 18 Sep 2003 06:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zvzN-0007XJ-F3 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 06:26:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IAQHIR028965 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 06:26:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zvz8-0007Wc-Nx; Thu, 18 Sep 2003 06:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zvyR-0007Vy-AC for sip@optimus.ietf.org; Thu, 18 Sep 2003 06:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05727 for ; Thu, 18 Sep 2003 06:25:10 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zvyN-0003qV-00 for sip@ietf.org; Thu, 18 Sep 2003 06:25:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19zvyM-0003qS-00 for sip@ietf.org; Thu, 18 Sep 2003 06:25:14 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8IAPFk18699 for ; Thu, 18 Sep 2003 13:25:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 13:25:15 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 13:25:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Date: Thu, 18 Sep 2003 13:25:14 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D8FBC@esebe013.ntc.nokia.com> Thread-Topic: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Thread-Index: AcN9DpN6oQ9H4cXCSByWCiZz62KsUgAv3ADg To: Cc: X-OriginalArrivalTime: 18 Sep 2003 10:25:14.0970 (UTC) FILETIME=[263C63A0:01C37DCF] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi,=20 Inline. > -----Original Message----- > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > Sent: 16 September, 2003 20:14 > To: Niemi Aki (NMP/Helsinki) > Cc: sip@ietf.org > Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - > PUBLIS H 00 >=20 >=20 > Hi Aki, > Well the newest publication policy wont win in all cases.=20 > Certainly, not in my example, as the PUA on which I forgot=20 > to logoff will become the *newest* once in a while. Right, but my point was that with the "nexest wins" policy you could = potentially override that zombie information by publishing this same = information from another PUA. However, this would permit you to = override, but not delete that zombie state. =20 > I was hoping, that similar to the usage of XCAP for setting=20 > authorization policies, we have a standardized procedure to=20 > control (ignore/consider) policy composers at the PUA level. > May be that should be added on to the authorization draft! > Forget about segementation, collision detection, etc > That is still an option for implementations but need not be=20 > standradized. Agreed. I too think that the authorization of watchers is very much = similar to authorization of publishers. In fact, authorizing = publications for a given presentity is almost exactly the same as = presence authorization but reduced to apply to only a single watcher - = in this case the PA.=20 In both cases, you will end up specifying which tuples selected, what = sort of authentication needs to be applied, etc. Cheers, Aki=20 >=20 > Thx/gf > > -----Original Message----- > > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, September 16, 2003 11:47 AM > > To: George Foti (QC/EMC) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - > > PUBLIS H 00 > >=20 > >=20 > > Hi George, > >=20 > > I think the composer policy could simply be that the newest=20 > > publication=20 > > wins. That way the zombie PUA's state will not propagate to the=20 > > watchers. Maybe this is something we ought to state in the draft? > >=20 > > But I think shutting down (remotely) such a zombie publisher=20 > > is somewhat=20 > > outside the scope of PUBLISH. Personally, I think this=20 > problem may be=20 > > more appropriately solved by designing the PUA such that=20 > it doesn't=20 > > zombie out, e.g., it takes user inactivity as a hint and stops=20 > > publication refreshes. > >=20 > > Other than that, I'm open to suggestions. The main reason for not=20 > > including event segmentation and collision detection to=20 > > PUBLISH was that=20 > > it created a lot of (unnecessary) complexity. > >=20 > > Cheers, > > Aki > >=20 > > On 16.09.2003 18:01, ext George Foti (QC/EMC): > >=20 > > > Hi Aki, > > >=20 > > > I think it should better explained in the draft how will such a > > > composer policy be set. If I have a PUA that is configured to > > > automatically publish presence information when I logon and if I > > > forgot to logoff, then how can I set the composer policy=20 > to ignore > > > that PUA or not include the information from that PUA in=20 > this case. > > >=20 > > > Should this not be standradized ?? > > >=20 > > > Thx/gf > > >=20 > > >> -----Original Message----- From: Aki Niemi > > >> [mailto:aki.niemi@nokia.com] Sent: Tuesday, September 16, 2003 > > >> 10:55 AM To: George Foti (QC/EMC) Cc: sip@ietf.org Subject: Re: > > >> [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 > > >>=20 > > >>=20 > > >> Hi George, > > >>=20 > > >> Inline. > > >>=20 > > >> On 15.09.2003 17:36, ext George Foti (QC/EMC): > > >>> If multiple PUAs publishes information on the same tuple, > > >> does it mean > > >>> that the ESC will have multiple entity-tags associated with > > >> that tuple, > > >>> one for each publishing PUA. > > >>=20 > > >> Each PUA publishes its own view of presence. Each view=20 > is assigned > > >> with an entity-tag, and each view can have tuples that overlap=20 > > >> across other PUAs. Resolving these "collisions" is at=20 > the hands of > > >> the composer. For example, it could automatically take=20 > preference > > >> for the "newest" view on that tuple. > > >>=20 > > >>> Also, the only means to stop a specfic PUA from updating > > >> that tuple is > > >>> through explictly disallowing that PUA from updating the > > >> state event for > > >>> that tuple, in the authorization policies in the ESC. > > >>=20 > > >> As it now stands, this requires setting the composer=20 > policy in such > > >> a way that the unwanted presence information never gets composed > > >> into the presence document. > > >>=20 > > >> Cheers, Aki > > >>=20 > > >>=20 > > >>>=20 > > >>> Thanks /gf > > >>>=20 > > >>>=20 > > >>>=20 > > >>=20 > > >>=20 > >=20 > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 10:28:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15106 for ; Thu, 18 Sep 2003 10:28:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzla-0006Vy-QZ for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 10:28:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IESICs024983 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 10:28:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzkO-0006Kz-Lp; Thu, 18 Sep 2003 10:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zzkC-0006JN-9T for sip@optimus.ietf.org; Thu, 18 Sep 2003 10:26:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14964 for ; Thu, 18 Sep 2003 10:26:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zzk9-0006h5-00 for sip@ietf.org; Thu, 18 Sep 2003 10:26:50 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19zzk9-0006gI-00 for sip@ietf.org; Thu, 18 Sep 2003 10:26:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8IEPhd07085; Thu, 18 Sep 2003 09:25:43 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Robert Sparks To: Hisham Khartabil Cc: "rohan@cisco.com" , Paul Kyzivat , Adam Roach , Brian.Rosen@marconi.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797102@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797102@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1063895142.887.11.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 18 Sep 2003 09:25:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit . On Thu, 2003-09-18 at 01:38, hisham.khartabil@nokia.com wrote: > Using your example C below, there is nothing restricting transcoder.com from forwarding the request to att.com even if the request-URI is a sip URI. Its transcoder.com local policy. > > /Hisham > > > >> B. > > >> > > >> INVITE tel:+14085264000 SIP/2.0 > > >> Route: , > > >> > > >> > > >> C. > > >> > > >> INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 > > >> Route: > > >> You missed the important part of what Rohan was trying to say I think You are right that transcoders.com could cause either request to go anywhere it wants. Suppose it sends the requests to att.com. In case B, att.com could (and most likely would) legitimately believe it is responsible for figuring out what to do with tel: URIs - nothing malicious - its just normal processing. Suppose it retargets it to one of its gateways. The request would then follow the route, where MCI proxy will forward the request back to the ATT gateway (until MCI gets wise and starts rejecting such requests). In case C, att.com has no legitimate claim on the RURI. It would be constrained to send the message to MCI with its RURI unchanged. So C does have significantly better properties than B. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 11:15:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17402 for ; Thu, 18 Sep 2003 11:15:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00V8-0000J6-At for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 11:15:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IFFMCs001174 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 11:15:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00Us-0000Eo-N4; Thu, 18 Sep 2003 11:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00UP-0000DR-FY for sip@optimus.ietf.org; Thu, 18 Sep 2003 11:14:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17247 for ; Thu, 18 Sep 2003 11:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00UO-0007Nq-00 for sip@ietf.org; Thu, 18 Sep 2003 11:14:36 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1A00UO-0007NI-00 for sip@ietf.org; Thu, 18 Sep 2003 11:14:36 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h8IFN8MR007774; Thu, 18 Sep 2003 11:23:08 -0400 Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h8IFCRZn009064; Thu, 18 Sep 2003 11:12:27 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id LAA49295; Thu, 18 Sep 2003 11:13:48 -0400 (EDT) Date: Thu, 18 Sep 2003 11:13:48 -0400 (EDT) Message-Id: <200309181513.LAA49295@fish.research.att.com> To: sip@ietf.org Cc: rsparks@dynamicsoft.com, hisham.khartabil@nokia.com, rohan@cisco.com, pkyzivat@cisco.com, adam@dynamicsoft.com, Brian.Rosen@marconi.com Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > On Thu, 2003-09-18 at 01:38, hisham.khartabil@nokia.com wrote: > > > Using your example C below, there is nothing restricting transcoder.com from forwarding the request to att.com even if the request-URI is a sip URI. Its transcoder.com local policy. > > > > /Hisham > > > > > > >> B. > > > >> > > > >> INVITE tel:+14085264000 SIP/2.0 > > > >> Route: , > > > >> > > > > >> > > > >> C. > > > >> > > > >> INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 > > > >> Route: > > > >> > > You missed the important part of what Rohan was trying to say I think > > You are right that transcoders.com could cause either request > to go anywhere it wants. Suppose it sends the requests to att.com. > > In case B, att.com could (and most likely would) legitimately > believe it is responsible for figuring out what to do with > tel: URIs - nothing malicious - its just normal processing. > Suppose it retargets it to one of its gateways. The request would > then follow the route, where MCI proxy will forward the request > back to the ATT gateway (until MCI gets wise and starts rejecting > such requests). > > In case C, att.com has no legitimate claim on the RURI. It would be > constrained to send the message to MCI with its RURI unchanged. > > So C does have significantly better properties than B. > > RjS > (and in spite of the domain names being used in this example...) This is exactly the point that I was trying to make much earlier in this thread. That if ";user=phone" means that the username came from a tel: URL, it does NOT (repeat NOT) mean that anyone else in the path can convert it back to a tel: URL and process it. It will only be handled by a proxy responsible for the domain named in the sip: URL. Past proposed wordings that the request would only be handled by proxies that "understand the username part" still concern me, because ";user=phone" (if the resolution here is that it means exactly a tel: URL) could give anyone that understanding. Routing still must be to the domain named in the request-URI, whether ";user=phone" is present or not. I'm fairly certain this point has been agreed by all parties. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 11:27:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18146 for ; Thu, 18 Sep 2003 11:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00gr-0001DE-8U for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 11:27:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IFRTbH004600 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 11:27:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00gR-00013b-2B; Thu, 18 Sep 2003 11:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00fQ-00012U-JJ for sip@optimus.ietf.org; Thu, 18 Sep 2003 11:26:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18085 for ; Thu, 18 Sep 2003 11:25:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00fP-0007fC-00 for sip@ietf.org; Thu, 18 Sep 2003 11:25:59 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A00fP-0007eX-00 for sip@ietf.org; Thu, 18 Sep 2003 11:25:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8IFPNd08103; Thu, 18 Sep 2003 10:25:23 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Robert Sparks To: William Marshall Cc: sip@ietf.org, hisham.khartabil@nokia.com, rohan@cisco.com, pkyzivat@cisco.com, adam@dynamicsoft.com, Brian.Rosen@marconi.com In-Reply-To: <200309181513.LAA49295@fish.research.att.com> References: <200309181513.LAA49295@fish.research.att.com> Content-Type: text/plain Message-Id: <1063898721.893.15.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 18 Sep 2003 10:25:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > (and in spite of the domain names being used in this example...) Point - apologies for my part in propogating that. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 18 12:06:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20301 for ; Thu, 18 Sep 2003 12:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01IU-0003ST-T6 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 12:06:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IG6Ml9013292 for sip-archive@odin.ietf.org; Thu, 18 Sep 2003 12:06:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01IB-0003RZ-FI; Thu, 18 Sep 2003 12:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01Hb-0003Qd-Ah for sip@optimus.ietf.org; Thu, 18 Sep 2003 12:05:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20221 for ; Thu, 18 Sep 2003 12:05:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01Ha-0000bp-00 for sip@ietf.org; Thu, 18 Sep 2003 12:05:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A01HZ-0000b8-00 for sip@ietf.org; Thu, 18 Sep 2003 12:05:25 -0400 Received: from zipper.cisco.com (zipper.cisco.com [171.70.69.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8IG4qfY019818; Thu, 18 Sep 2003 09:04:52 -0700 (PDT) Date: Thu, 18 Sep 2003 09:04:52 -0700 (PDT) From: Rohan Mahy X-X-Sender: rmahy@zipper.cisco.com To: hisham.khartabil@nokia.com cc: rsparks@dynamicsoft.com, pkyzivat@cisco.com, adam@dynamicsoft.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797102@esebe019.ntc.nokia.com> Message-ID: References: <2038BCC78B1AD641891A0D1AE133DBB701797102@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On Thu, 18 Sep 2003 hisham.khartabil@nokia.com wrote: > > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Wednesday, September 17, 2003 7:35 PM > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; adam@dynamicsoft.com; > > Brian.Rosen@marconi.com; sip@ietf.org > > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > On Tuesday, September 16, 2003, at 11:27 PM, > > wrote: > > > > > I afraid C has the same problem as B. > > > > No, it doesn't. Nobody except a server authoritative for mci.com is > > allowed to interpret that URI. This is very clear for SIP and SIPS > > URIs. We don't have this kind of restriction on tel URIs. > > Section 16.5 states: > > "If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." > > Section 16.6 states (step 6): > > "A proxy MAY have a local policy that mandates that a request > visit a specific set of proxies before being delivered to the > destination" > > and step 7: > > "The proxy MAY have a local policy to send the request to a > specific IP address, port, and transport, independent of the > values of the Route and Request-URI" > > Using your example C below, there is nothing restricting transcoder.com from forwarding the request to att.com even if the request-URI is a sip URI. Its transcoder.com local policy. agreed, there is nothing retricting trasncoder.com sending the request to att.com, but att.com then needs to forward this request on the mci.com. att.com does not get to process the userpart of a URI which ends in mci.com. (unless they buy them ;-) however, in case B, att.com could just process the tel URI in the request URI and never send the request to mci.com. thanks, -rohan > /Hisham > > > > > thanks, > > -rohan > > > > > /Hisham > > > > > > > > >> -----Original Message----- > > >> From: ext Rohan Mahy [mailto:rohan@cisco.com] > > >> Sent: Tuesday, September 16, 2003 7:27 PM > > >> To: Robert Sparks > > >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; sip@ietf.org > > >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > >> > > >> > > >> > > >> On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: > > >> > > >>> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > > >>> > > >>>> While I do not object to sending tel URIs to SIP proxies, > > >> I believe I > > >>>> already articulated some reasons why you might want to use > > >> sip or sips > > >>>> instead. > > >>>> > > >>>> 1) want to use SIPS > > >>> > > >>> Agreed! > > >>> > > >>>> 2) want to route the call to a specific domain that is not > > >> the domain > > >>>> of your first hop proxy. > > >>>> 3) want to invoke a loose router for services like > > >> transcoding or call > > >>>> history logging that have different tel URI handling > > rules than you > > >>>> want to use. > > >>> > > >>> Both 2 and 3 can be solved by pushing or preloading routes. > > >> > > >> OK, I was being sloppy. Looking at several options. > > >> > > >> A. > > >> INVITE tel:+14085264000 SIP/2.0 > > >> Route: > > >> > > >> A is not so good, because you have no control over what > > >> transcoders.com > > >> does with tel URLs (It might reject them, or send you a big bill). > > >> > > >> B. > > >> > > >> INVITE tel:+14085264000 SIP/2.0 > > >> Route: , > > >> > > >> B would probably work, but seems much more cumbersome than C. In > > >> addition, transcoders.com might forward all calls toward mci.com > > >> through some other domain (att.com) which might just take > > the tel URL > > >> and process it itself. > > >> > > >> C. > > >> > > >> INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 > > >> Route: > > >> > > >> C is explicit, it works, and it contains no extra info. > > >> > > >> thanks, > > >> -rohan > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > >> > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00037 for ; Fri, 19 Sep 2003 21:36:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh99020140 for ; Fri, 19 Sep 2003 21:36:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PIBFxV010775 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLny-0002e1-B9; Mon, 25 Aug 2003 14:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKFr-0005ot-SG for sip@optimus.ietf.org; Mon, 25 Aug 2003 12:31:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27174; Mon, 25 Aug 2003 12:31:36 -0400 (EDT) Message-Id: <200308251631.MAA27174@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:31:36 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-parameter-registry-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-parameter-registry-00.txt Pages : 6 Date : 2003-8-25 This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-parameter-registry-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-parameter-registry-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-parameter-registry-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-parameter-registry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00036 for ; Fri, 19 Sep 2003 21:36:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh97020140 for ; Fri, 19 Sep 2003 21:36:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PIBJrf011034 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:11:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLo9-0002n9-QB; Mon, 25 Aug 2003 14:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKFx-0005p0-3M for sip@optimus.ietf.org; Mon, 25 Aug 2003 12:31:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27194; Mon, 25 Aug 2003 12:31:42 -0400 (EDT) Message-Id: <200308251631.MAA27194@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:31:41 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-parameter-reg-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-uri-parameter-reg-00.txt Pages : 5 Date : 2003-8-25 This document creates an IANA registry for SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-parameter-reg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-parameter-reg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-parameter-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-parameter-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124356.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00165 for ; Fri, 19 Sep 2003 21:36:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9h020140 for ; Fri, 19 Sep 2003 21:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QASL3Z026186 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 06:28:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rb32-0006mb-Kd; Tue, 26 Aug 2003 06:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rVmq-0004jg-Bg for sip@optimus.ietf.org; Tue, 26 Aug 2003 00:50:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04240 for ; Tue, 26 Aug 2003 00:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rVmn-0003rI-00 for sip@ietf.org; Tue, 26 Aug 2003 00:50:29 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19rVmm-0003rE-00 for sip@ietf.org; Tue, 26 Aug 2003 00:50:28 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7Q4oQAv015157; Tue, 26 Aug 2003 06:50:26 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 26 Aug 2003 06:51:18 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] More on dial plans and user=phones Date: Tue, 26 Aug 2003 06:50:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, If user=phone only means "this is a dial string", but have no syntax assoicated with it (eg telephone-subscriber), then I am not sure the parameter is needed. Instead, a dial string will be like any user identifier. However, once again, that would mean that virtual separators etc can not be used in a SIP-URI, which must be taken into consideration when mapping from TEL-URL to SIP-URI. Also, does that mean that a gateway will have to be able to, using Dean's example, understand both +19735551212 and 0119735551212? Or, can we still have rules defining how dial strings are represented in SIP-URIs - no matter if we use telephone-subscriber or something else... Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: 25. elokuuta 2003 19:13 > To: sip@ietf.org > Subject: [Sip] More on dial plans and user=phones > > > > It's all either far more complicated or far simpler than we > seem to think, > and I'm confused as to which of the above is true. > > Let's talk about a "real" system -- my office, where we've > been running > everyday telephony using SIP phones and proxies and gateways > for > 3 years. > We do phone-number routing, inbound and outbound from PSTN, > and user-name > routing. > > But I'm not sure I've ever seen a user=phone, and I don't > think the system > would know what to do if it did. > > Assume than an INVITE arrives at my proxy with a request URI looking > something like 9724735455@dynamicsoft.com. > > Is this a phone number or a user? Dunno, yet. > > We look in the proxy's configuration and see if 9724735455 is > a defined > user. If it is, we route the number according to the user's > CPL. If not, we > treat it as a phone number and consult the proxy's dial plan table. > > This works for inbound, outbound, complex forwarding, calls > through other > people's proxies (like iptel.org, which I use from the > house), and so on. > > Now: here's the tricky part -- as a user, I have to have some level of > understanding of the dial plan that the proxy understands. > For example, I > know that if I want to dial Dallas phone number 9725551212, I > enter exactly > those digits, but if I want New Jersey's 9735551212, then I > have to add a > leading 1 (19735551212), and if I want international > +19735551212, then I > dial 0119735551212. Oddly enough, this makes the whole thing > work just fine > without downloading any dial plans or using any tel-URIs or > user=phones. > > If I wanted to use iptel.org's routing, I'd set my phone up to send > digits@iptel.org instead, and I'd have to understand the dialing plan > imposed by their proxy. > > This points something out: IF we do download dialing plans, > then the dialing > plan has to stay synched between the phone and its default > proxy, applies > ONLY to calls made through the default proxy, and MUST BE ignored if a > different target domain is entered by the user. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00194 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9r020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QIvmEn017089 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 14:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj0Z-0004JQ-RC; Tue, 26 Aug 2003 14:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rNjl-0008Li-Ez for sip@optimus.ietf.org; Mon, 25 Aug 2003 16:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13984 for ; Mon, 25 Aug 2003 16:14:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rNjj-0006sH-00 for sip@ietf.org; Mon, 25 Aug 2003 16:14:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19rNjh-0006ro-00 for sip@ietf.org; Mon, 25 Aug 2003 16:14:46 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7PKEFUg005149; Mon, 25 Aug 2003 16:14:15 -0400 (EDT) Message-ID: <3F4A6E12.7060104@dynamicsoft.com> Date: Mon, 25 Aug 2003 16:14:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] More on dial plans and user=phones References: <004501c36b23$cb2da720$e1036e3f@txdwillis> In-Reply-To: <004501c36b23$cb2da720$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A few thoughts here, not all directly applicable to Dean's note, but better one email with a consolidated reply than many. Firstly, the motivation for adding the user parameter into the SIP URI was only to give a hint on the BNF for the user part. Nothing more. Interestingly, you really can't even have two URIs in the domain that differ only by the user param. According to rfc3261, a registrar doesnt use the user part as an index to look up routing information on a subscriber: The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), Secondly, the interpretation of the user part is at the discretion of the domain which owns that user part. No one else should be looking at it, or care whether user param is there or not. The combination of these two, to me, imply that the user parameter probably is useless, since if the user part is examined ONLY by the domain that owns it, there are other syntactic hints that can be used by putting things in the user part itself. The problem we are running into is that these URI are being *constructed*. URI are most useful when someone hands them to you, either on a business card or in a web page or in a sip request. When they are handed to you, there is no need to guess at how to build one, or come to agreements on how they are interpreted. So, if you are constructing a URI within a domain, you have to know, ahead of time, what the domain is expecting. Dean is arguing that this is something the user has to know about. Others have argued that the domain has to transfer a script that informs the phone how to construct the URI. The root question here is - who's responsible for figuring out how to convert user input into something that the server processing that input can understand? The issue of convering raw user input into something a server can understand sounds a lot like the scope of the app-interaction work that we have been doing in sipping. Indeed, the scripts that Henning were talking about sound a lot like KPML scripts, except that the result of some user input would not be a push of some stimulus but the transmission of an INVITE message. Either way, the KMPL scripts basically encode the dial plans. -Jonathan R. Dean Willis wrote: > It's all either far more complicated or far simpler than we seem to think, > and I'm confused as to which of the above is true. > > Let's talk about a "real" system -- my office, where we've been running > everyday telephony using SIP phones and proxies and gateways for > 3 years. > We do phone-number routing, inbound and outbound from PSTN, and user-name > routing. > > But I'm not sure I've ever seen a user=phone, and I don't think the system > would know what to do if it did. > > Assume than an INVITE arrives at my proxy with a request URI looking > something like 9724735455@dynamicsoft.com. > > Is this a phone number or a user? Dunno, yet. > > We look in the proxy's configuration and see if 9724735455 is a defined > user. If it is, we route the number according to the user's CPL. If not, we > treat it as a phone number and consult the proxy's dial plan table. > > This works for inbound, outbound, complex forwarding, calls through other > people's proxies (like iptel.org, which I use from the house), and so on. > > Now: here's the tricky part -- as a user, I have to have some level of > understanding of the dial plan that the proxy understands. For example, I > know that if I want to dial Dallas phone number 9725551212, I enter exactly > those digits, but if I want New Jersey's 9735551212, then I have to add a > leading 1 (19735551212), and if I want international +19735551212, then I > dial 0119735551212. Oddly enough, this makes the whole thing work just fine > without downloading any dial plans or using any tel-URIs or user=phones. > > If I wanted to use iptel.org's routing, I'd set my phone up to send > digits@iptel.org instead, and I'd have to understand the dialing plan > imposed by their proxy. > > This points something out: IF we do download dialing plans, then the dialing > plan has to stay synched between the phone and its default proxy, applies > ONLY to calls made through the default proxy, and MUST BE ignored if a > different target domain is entered by the user. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00186 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9l020140 for ; Fri, 19 Sep 2003 21:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U1AwAw022534 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 21:10:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stmS-0004cl-4V; Fri, 29 Aug 2003 20:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sq1G-0002yp-T8 for sip@optimus.ietf.org; Fri, 29 Aug 2003 16:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02929 for ; Fri, 29 Aug 2003 16:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sq1E-0006X3-00 for sip@ietf.org; Fri, 29 Aug 2003 16:38:52 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19sq1D-0006Vy-00 for sip@ietf.org; Fri, 29 Aug 2003 16:38:51 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TKc3w21051; Fri, 29 Aug 2003 15:38:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 15:38:04 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578BC1@zrc2c000.us.nortel.com> From: "Mary Barnes" To: Kevin Lingle , Jean-Francois Mule Cc: "'sip@ietf.org'" , "'rohan@cisco.com'" Date: Fri, 29 Aug 2003 15:37:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] SIP MIB-07: sipMaxSessions -> sipMaxTransactions ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There has been past discussion on possibly renaming this object, but I did not see a clear conclusion. At one point, I had seen a statement that it would be renamed "sipMaxCalls", but call isn't a precise SIP term. Cullen also raised the question in his comments as to whether this should be "Dialogs" or "Transactions". My view would be that "sipMaxTransactions" would be a good choice. Regards, Mary H. Barnes mbarnes@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00193 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9p020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U1AUUb022426 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 21:10:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stmT-0004d3-HF; Fri, 29 Aug 2003 20:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sq1G-0002yo-MB for sip@optimus.ietf.org; Fri, 29 Aug 2003 16:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02924 for ; Fri, 29 Aug 2003 16:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sq1E-0006Wx-00 for sip@ietf.org; Fri, 29 Aug 2003 16:38:52 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19sq1D-0006Vw-00 for sip@ietf.org; Fri, 29 Aug 2003 16:38:51 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TKc3w21052; Fri, 29 Aug 2003 15:38:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 15:38:04 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578BC0@zrc2c000.us.nortel.com> From: "Mary Barnes" To: Kevin Lingle , Jean-Francois Mule Cc: "'sip@ietf.org'" , "'rohan@cisco.com'" Date: Fri, 29 Aug 2003 15:37:56 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] NITS/General Editorial Comments on draft-ietf-sip-mib-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all, Per my assignment, I've reviewed sections 7.2 and 8 through 10 of the MIB, with the following general comments and nits. I have a few specific points that require discussion that I'll post in separate emails to facilitate WG discussion and hopefully to allow easier tracking of issues. I did try to conscientiously review previous comments on the mailing list and to review previous versions to make sure that I wasn't bringing up things for which there had been consensus. I do apologize if I inadvertently open an issue that was truly closed by the WG. - Section 7.2, page 14. The descriptions need to be updated to reflect RFC 3261 (section 6) terminology/definitions for User Agent, Proxy Server, Redirect Server and Registrar. - Section 7.2, page 15. Really minor nit, but I found it very difficult to read the common MIB objects with no blank lines between the comment lines and the object definitions. - Section 7.2, page 20. sipEntitytype. Per Cullen's comments not separating the Proxy and Redirect Server, this would need to be reflected in this object definition. - Section 8: My understanding is that this section should be removed by the RFC Editor. Thus, I would suggest adding a comment as such (something like: "This section to be removed by RFC Editor before publication." and moving this section just prior to the Author's address to facilitate that process. - Section 9, page 109. The statement "If these objects are SET maliciously, it may result in incorrect or unwanted protocol operation." is probably a bit of an understatement with regards to the timer, retry and expire values being misconfigured. Certainly, a well designed system would but reasonable boundaries on how these things can be configured, so as to hopefully prevent significant problems. Cullen had brought up the more general issue of whether all the timers should be configurable in his comments. Like Cullen, I haven't thought about this enough to decide whether all these timers should be configurable, but at a minimum, I think the security section needs a more robust statement. Regards, Mary H. Barnes mbarnes@nortelnetworks.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00637 for ; Fri, 19 Sep 2003 21:36:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAd020140 for ; Fri, 19 Sep 2003 21:36:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PIOvT6018622 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rM18-0004ix-Mc; Mon, 25 Aug 2003 14:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKuh-00071Z-Po for sip@optimus.ietf.org; Mon, 25 Aug 2003 13:13:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00558 for ; Mon, 25 Aug 2003 13:13:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKuf-000407-00 for sip@ietf.org; Mon, 25 Aug 2003 13:13:53 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rKuf-0003zn-00 for sip@ietf.org; Mon, 25 Aug 2003 13:13:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26361; Mon, 25 Aug 2003 13:13:20 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03662; Mon, 25 Aug 2003 13:13:22 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 13:13:21 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D2E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Adam Roach'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 25 Aug 2003 13:13:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Yes, of course, my bad. We do need to point that out in the I-D. Brian > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, August 25, 2003 12:13 PM > To: 'Rosen, Brian'; Adam Roach > Cc: sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: > > > I know that some phones DO have internal translations, > > and they do send user=phone with a global number, but > > that's a valid dial string, no? I'd propose to deprecate > > that (use a tel uri), but allow it for backwards > > compatibility > > I don't think we want to deprecate it. As has been pointed > out already, one of the reasons that people transform tel: > URIs into SIP URIs is that tel: URIs have no inherent routing > properties. Yes, TRIP can be used for routing purposes, but > that information is typically site-specific, not global. Often, > the originating party will want to have more say in where > a call goes than that. > > Consider: > > Route: , , > > > Even if this made sense, I'm left at the mercy of proxy2's > local routing logic with regards to who services my tel URI. > Compare: > > Route: , , > > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00634 for ; Fri, 19 Sep 2003 21:36:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAb020140 for ; Fri, 19 Sep 2003 21:36:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PI1Rsk001738 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:01:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLeM-0000Gf-JC; Mon, 25 Aug 2003 14:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJbL-0004u5-GW for sip@optimus.ietf.org; Mon, 25 Aug 2003 11:49:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25066 for ; Mon, 25 Aug 2003 11:49:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJbK-0002rV-00 for sip@ietf.org; Mon, 25 Aug 2003 11:49:50 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rJbJ-0002rC-00 for sip@ietf.org; Mon, 25 Aug 2003 11:49:49 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24038; Mon, 25 Aug 2003 11:49:18 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23472; Mon, 25 Aug 2003 11:49:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 11:49:18 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D2C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Adam Roach'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 25 Aug 2003 11:49:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > As I said in my original post on this topic, unless someone > wants to invest the effort required to definite precise > semantics of "user=phone", it needs to be deprecated. The > current situation is causing demonstrable interop problems. > > You sound like you're pretty motivated to fix the problem. > Perhaps you can put together an i-d that clarifies the > precise meaning of "user=phone". I can do that. Anyone want to argue that user=phone should not be interpretted as a dial string? I understand why reading the tea leaves of the current RFCs leads to confusion, but I think there is good reason to send dial strings sometimes, and I don't think there is any other reason for user=phone. I know that some phones DO have internal translations, and they do send user=phone with a global number, but that's a valid dial string, no? I'd propose to deprecate that (use a tel uri), but allow it for backwards compatibility Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00879 for ; Fri, 19 Sep 2003 21:36:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhB3020140 for ; Fri, 19 Sep 2003 21:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PIQFtk020240 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:26:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rM2V-00059g-Vn; Mon, 25 Aug 2003 14:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLFu-0007Sh-PH for sip@optimus.ietf.org; Mon, 25 Aug 2003 13:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03131 for ; Mon, 25 Aug 2003 13:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rLFs-0004Yd-00 for sip@ietf.org; Mon, 25 Aug 2003 13:35:48 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19rLFm-0004Y3-00 for sip@ietf.org; Mon, 25 Aug 2003 13:35:47 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 52FD020660F for ; Mon, 25 Aug 2003 13:34:04 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rKHT-00056z-5p for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 12:33:23 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19rKFr-000524-0l for all-ietf@asgard.ietf.org; Mon, 25 Aug 2003 12:31:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27174; Mon, 25 Aug 2003 12:31:36 -0400 (EDT) Message-Id: <200308251631.MAA27174@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:31:36 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+77611_60390224716625_77276972403" Subject: [Sip] I-D ACTION:draft-ietf-sip-parameter-registry-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+77611_60390224716625_77276972403 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-parameter-registry-00.txt Pages : 6 Date : 2003-8-25 This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-parameter-registry-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-parameter-registry-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+77611_60390224716625_77276972403 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+162614_8140579063567_26180357918" --MIMEStream=_1+162614_8140579063567_26180357918 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-parameter-registry-00.txt --MIMEStream=_1+162614_8140579063567_26180357918 Content-Type: Message/External-body; name="draft-ietf-sip-parameter-registry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124346.I-D@ietf.org> --MIMEStream=_1+162614_8140579063567_26180357918-- --MIMEStream=_0+77611_60390224716625_77276972403-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00898 for ; Fri, 19 Sep 2003 21:37:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhB5020140 for ; Fri, 19 Sep 2003 21:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R4LT7H012393 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 00:21:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmok-0005Ay-8U; Tue, 26 Aug 2003 19:01:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rcrQ-0001sc-5G for sip@optimus.ietf.org; Tue, 26 Aug 2003 08:23:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01213 for ; Tue, 26 Aug 2003 08:23:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rcrO-0000Ay-00 for sip@ietf.org; Tue, 26 Aug 2003 08:23:42 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rcrO-0000Aj-00 for sip@ietf.org; Tue, 26 Aug 2003 08:23:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA12767; Tue, 26 Aug 2003 08:22:59 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04133; Tue, 26 Aug 2003 08:22:59 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 08:22:59 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D41@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'William Marshall'" , sip@ietf.org Cc: fluffy@cisco.com, Richard.Stastny@oefeg.at Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 26 Aug 2003 08:22:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Well, in many real systems there are several proxies that understand the local domain. For example, pitt.sip.marconi.com and coventry.sip.marconi.com may understand the marconi.com dialing plan. Often, a phone is given a default domain. Any URL presented to it (such as a dial string) that does not have an explicit domain has the default domain appended to it. So, as long as the proxy that handles the expansion understands the dial plan in the specified domain, then it can process it. I think that's pretty explicit. At the moment, we don't have any specification for a dial string, and while we might evolve one in the configuration work, I would not propose to specify how a dialstring is interpretted. This means there is no global understanding of the user part. Brian > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Tuesday, August 26, 2003 7:22 AM > To: sip@ietf.org > Cc: fluffy@cisco.com; Brian.Rosen@marconi.com; > Richard.Stastny@oefeg.at > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Cullen wrote (entire message quoted below): > > sip:1234@foo.com means send it to foo.com and foo will > figure it out. > > > > sip:1234@foo.com;user=phone means send to to foo.com and > foo will figure it out. > > I think the above statement is exactly right. As Richard > Stastny wrote > > I thought that any server will take his hand off "foo" anyway > > if it is not "bar.com". > > But I get somewhat worried when I see comments like that > contained in a > message from Brian Rosen yesterday (entire message quoted below), > > If you send sip:@;user=phone, then , > > or at least a proxy that understands the dialing plan, > > does the translation. That may or may not be the first hop proxy. > > ***or at least a proxy that understands the dialing plan**** > > If the ";user=phone" requires a strict format and global understanding > of the username of the sip: URI, then everyone can claim to be > a proxy that understands the dialing plan. This is wrong. > > It should instead read: > If you send sip:@;user=phone, then > does the translation. That may or may not be the first hop proxy. > > Bill Marshall > wtm@research.att.com > > -----original messages----- > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > Date: Mon, 25 Aug 2003 09:04:51 +0200 > From: "Stastny Richard" > To: "William Marshall" , > Cc: , , > > Hi folks, > just for my understanding: > > > There is certainly a difference between > > sip:foo@bar.com;user=phone > > and tel:foo > > > > The first is explicitely telling all servers other than > > bar.com to keep their hands off the string "foo". When the > > string "foo" appears in a tel: URL, then all those transit > > servers can modify it, or route the call to their own > > favorite gateway server; when the string "foo" appears in a > > sip: URL, then the transit servers merely pass it > > unchanged to the explicitely named host/gateway. > > > > I thought that any server will take his hand off "foo" anyway > if it is not "bar.com". > Am I missing something? > Richard > > ---------- > From: "Rosen, Brian" > To: "Rosen, Brian" , > "'Henning Schulzrinne'" , > "Conroy, Lawrence (SMTP)" > Cc: Adam Roach , sip@ietf.org, > Richard > Subject: RE: Warning about dial plan assumptions (was RE: AW: > [Sip] SIPIT > Inte rop problem with ;user=phone) > Date: Mon, 25 Aug 2003 11:10:25 -0400 > > Someone just pointed out to me that there could be confusion on > who translates a dial string to a routable number. > If you send sip:@;user=phone, then , > or at least a proxy that understands the dialing plan, > does the translation. That may or may not be the first hop proxy. > > Most phones that I know have configured; you don't type it. > If you did, and it wasn't your local proxy, then you better understand > how whatever you typed interprets your dial string, and your local > proxy better not muck with it. > > Brian > > ---------- > Date: Mon, 25 Aug 2003 11:48:36 -0700 > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > From: Cullen Jennings > To: > > sip:1234@foo.com means send it to foo.com and foo will figure it out. > > sip:1234@foo.com;user=phone means send to to foo.com and foo > will figure it > out. > > Right now it is totally random if the UA puts in the > user=phone or not and > the proxies (as far as I can tell) mostly ignore it. I'm > having a hard time > figuring out what the requirement is for this extra 1 bit of > information > that currently has no semantic meaning. There is a certain amount of > operational experience that indicates this flag is not needed. > > I think the whole thing is bogus unless someone can clearly state a > requirement that says why the proxy might need to know some > extra bit of > information and clearly says how the UA would set this bit of > information > based on something the user entered on the UA. > > Defining something that all UAs will set to the same value or > all proxies > will ignore is useless. > > Cullen > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:36:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00859 for ; Fri, 19 Sep 2003 21:36:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAt020140 for ; Fri, 19 Sep 2003 21:36:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PEKTJF004488 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 10:20:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rICc-00015x-N4; Mon, 25 Aug 2003 10:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIBL-000137-Kz for sip@optimus.ietf.org; Mon, 25 Aug 2003 10:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20226 for ; Mon, 25 Aug 2003 10:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rIBJ-0001ea-00 for sip@ietf.org; Mon, 25 Aug 2003 10:18:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19rIBH-0001eV-00 for sip@ietf.org; Mon, 25 Aug 2003 10:18:52 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7PEIMAv019554; Mon, 25 Aug 2003 16:18:22 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Aug 2003 16:18:52 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Rosen, Brian'" , "'Henning Schulzrinne'" , "Conroy, Lawrence (SMTP)" Cc: Adam Roach , sip@ietf.org, Richard Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Mon, 25 Aug 2003 16:17:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Assuming that user=phone means "this is a dial string", does it also means that the syntax has to be according to the telephone-subscriber ABNF? Ie, do we use "+" instead of "00", can we use visual separators without nodes treating them as actual parts of the actual user identifier, etc etc etc? OR, shall we define a separate syntax for "dial-string" in a SIP-URI? I think THAT is the question that started this discussion at the SIPit. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 25. elokuuta 2003 17:05 > To: 'Henning Schulzrinne'; Conroy, Lawrence (SMTP) > Cc: Adam Roach; sip@ietf.org; Richard > Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] > SIPIT Inte rop problem with ;user=phone) > > > This breaks nearly every existing phone. Is that your intention? > > user=phone, at the moment, means "this is a dial string". > It used to be that you could do the same in a tel uri, but we > "fixed" that. Until we have overwhelming deployment of end devices > that translate dial strings to tel uris (PLEASE do not say > E.164s or global identifier, they are not all global numbers after > translation), we need to leave user=phone as the way to send a dial > string. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Sunday, August 24, 2003 10:52 AM > > To: Conroy, Lawrence (SMTP) > > Cc: Adam Roach; sip@ietf.org; Richard > > Subject: Re: Warning about dial plan assumptions (was RE: AW: [Sip] > > SIPIT Inte rop problem with ;user=phone) > > > > > > In an earlier iteration of this discussion in the IPTEL WG, > there was > > some consensus that the appropriate way is to download a > > dialplan into > > the end system, which then does the translation from dialed > > digits to a > > global identifier. That way, it doesn't matter where the SIP > > or tel URI > > ends up and removes the where-was-this-number-dialed > guessing by the > > outbound proxy. This should be part of the general configuration > > mechanism. I had volunteered to write up a spec for that, but I'm > > waiting for the general shape of the configuration data > > format to settle. > > > > Conroy, Lawrence (SMTP) wrote: > > > > > > > *I* would love such a specification, because it's what my > > > cellphone does. You wouldn't because you are in the NANP. > > > > > > Thus any spec mustn't be "over the wire" - it MUST be at > > > most an end system issue. It's dangerous for a Proxy to > > > interpret, as the expectations of the end user may differ. > > > > > > I'd be confused and miffed if I dialled 0117 and my proxy > > > and PSTN gateway gave me a Russian number rather than the > > > Bristol number I expected. So, no doubt, would the callee :). > > > > > > all the best, > > > Lawrence > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00906 for ; Fri, 19 Sep 2003 21:37:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBF020140 for ; Fri, 19 Sep 2003 21:36:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S7lvDi020239 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 03:47:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCnX-0003IA-4y; Wed, 27 Aug 2003 22:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s7tx-0001GH-Oy for sip@optimus.ietf.org; Wed, 27 Aug 2003 17:32:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10231 for ; Wed, 27 Aug 2003 17:32:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7tv-0000xd-00 for sip@ietf.org; Wed, 27 Aug 2003 17:32:23 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19s7tu-0000xF-00 for sip@ietf.org; Wed, 27 Aug 2003 17:32:22 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 14:41:55 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7RLVp7b005101; Wed, 27 Aug 2003 14:31:51 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN47350; Wed, 27 Aug 2003 14:31:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 27 Aug 2003 14:31:50 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Dean Willis , Brian Rosen CC: Message-ID: In-Reply-To: <1062006197.7417.52.camel@bdsl.greycouncil.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For better or worse, I think pretty much all GW do 2. On 8/27/03 10:43, "Dean Willis" wrote: > brian suggested about user=phone: >> I think it should be used to denote that the user part is a dial string. > > Assume a gateway gets a SIP INVITE that does NOT have a user=phone > parameter, but the host-part of the request-URI matches the > area-of-responsibility for that gateway (for example, it's hostname). > > Should it: > > 1) Respond with a 404 (or related code), because it's a GATEWAY and it > MUST receive a dial-string as the user-part of a SIP(S) request-URI. > > 2) Try to convert the user part) into a phone number anyhow. > > If case 1, I submit that we just added a lot of complexity to other > people's forwarding tables, and I don't think we got anything out of the > effort. > > If case 2, I submit that the user=phone parameter achieved nothing and > might as well be deprecated. > > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01081 for ; Fri, 19 Sep 2003 21:37:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBb020140 for ; Fri, 19 Sep 2003 21:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88DxvuN009255 for sip-archive@odin.ietf.org; Mon, 8 Sep 2003 09:59:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMYY-0002OQ-CL; Mon, 08 Sep 2003 09:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wIza-0003rv-Kj for sip@optimus.ietf.org; Mon, 08 Sep 2003 06:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07519 for ; Mon, 8 Sep 2003 06:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wIzW-0000mn-00 for sip@ietf.org; Mon, 08 Sep 2003 06:11:26 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 19wIzW-0000jb-00 for sip@ietf.org; Mon, 08 Sep 2003 06:11:26 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h88AAvv8009033; Mon, 8 Sep 2003 05:10:57 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.129]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id R58KRJ8P; Mon, 8 Sep 2003 05:10:43 -0500 Message-ID: <3F5C55B0.3040000@ericsson.com> Date: Mon, 08 Sep 2003 13:10:56 +0300 X-Sybari-Trust: 4228dfb9 0f2b92c8 6ad59f72 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Compressing subsequent REGISTER requests References: <2038BCC78B1AD641891A0D1AE133DBB701797010@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797010@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hisham, since you are not creating any dialog, your next REGISTER will be sent to the exact same place as the first one (probably your outbound proxy). If you want to send compressed stuff to a proxy for the first time, you should first send an OPTIONS to check whether or not it supports compression. Gonzalo hisham.khartabil@nokia.com wrote: > Hi, > > RFC3486 says: > > "a user agent server SHOULD add comp=sigcomp to the > Contact header field of the response if the URI of the next upstream > hop in the route set contained the parameter comp=sigcomp" > > I assume this is for dialog creating responses. What about REGISTER? > > If I send the very first REGISTER request uncompressed since I didn't know if it supports sigcomp. I can never learn through a similar mechanism as defined above if any subsequent REGISTER request should be compressed or not. > > One solution is for the registrar to record-route (yuk). The other is to rely on the response being compressed as a hint, but I don't think this is good enough since the registrar did not get the chance to indicate its willingness to receive compressed requests. > > We could also say that if an initial REGISTER is not compressed, then any subsequent REGISTER cannot be compressed. > > Thanks, > Hisham > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01044 for ; Fri, 19 Sep 2003 21:37:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBT020140 for ; Fri, 19 Sep 2003 21:36:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TLY3da021370 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snut-0005HR-6a; Fri, 29 Aug 2003 14:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skdq-00040Z-9v for sip@optimus.ietf.org; Fri, 29 Aug 2003 10:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00412 for ; Fri, 29 Aug 2003 10:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skdn-00055o-00 for sip@ietf.org; Fri, 29 Aug 2003 10:54:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19skdn-00055T-00 for sip@ietf.org; Fri, 29 Aug 2003 10:54:19 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Aug 2003 08:04:20 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7TErgba019859; Fri, 29 Aug 2003 07:53:43 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP23485; Fri, 29 Aug 2003 07:53:41 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Aug 2003 07:53:42 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Brian Rosen , Dean Willis , CC: Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D81@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dial strings have usually been defined to include things like pauses and wait for secondary dial tone. I don't think we need to be able to represent that type of information in SIP. Cullen On 8/28/03 11:15, "Rosen, Brian" wrote: >> Citing an example inf RFC 2806: >> >> tel:0w003585551234567;phone-context=+3585551234 >> > > From 2806bis > Dial string: "Dial strings" are the actual numbers, symbols and > pauses entered by a user to place a phone call. A dial- > string is consumed by one or more network entities, and > understood in the context of the configuration of these > entities. It is used to generate a telephone number so that > a call can be routed. Dial-strings may require pre-pended > digits to handle local PBXs, and they may include post-dial > DTMF signaling that could control an IVR or reach an > extension. Dial strings are beyond the scope of this > document. > > Therefore, you can no longer use your example, and a dial string > MUST be sent as a sip uri. I think that it would be a good idea > to mark such dial strings as dial strings, but YMMV. > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01158 for ; Fri, 19 Sep 2003 21:37:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBn020140 for ; Fri, 19 Sep 2003 21:36:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DeSjE010720 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 09:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBOI-0002hi-6z; Tue, 02 Sep 2003 09:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBN9-0002Oo-A8 for sip@optimus.ietf.org; Tue, 02 Sep 2003 09:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24293 for ; Tue, 2 Sep 2003 09:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBN6-0007ig-00 for sip@ietf.org; Tue, 02 Sep 2003 09:39:00 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19uBN2-0007dm-00 for sip@ietf.org; Tue, 02 Sep 2003 09:38:56 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01853; Tue, 2 Sep 2003 09:38:24 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18240; Tue, 2 Sep 2003 09:38:24 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Sep 2003 09:38:24 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5DA4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , Richard.Stastny@oefeg.at, fluffy@cisco.com, dean.willis@softarmor.com Cc: sip@ietf.org Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 2 Sep 2003 09:38:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Getting more and more confused. A "dial string" cannot go in a tel uri. It can go in the user part of a sip uri. So, if a sip UA does not have the ability to automatically translate dial strings to routable telephone numbers, it has to be in a sip uri user part. I don't think that is controversial. The question is, does the UA need to mark the user part as a dial string, or is it enough for the host mentioned in the domain part of the sip uri to just know the difference? I'd prefer to mark the userpart as a dial string, but I can cope if we don't. Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, September 01, 2003 5:21 AM > To: Richard.Stastny@oefeg.at; fluffy@cisco.com; > dean.willis@softarmor.com > Cc: Brian.Rosen@marconi.com; sip@ietf.org > Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > So, the answer in any case is that it is somehow routable.=20 > Therefore I conclude the allowing a sip URI to carry a dial=20 > strings is not needed. >=20 > /Hisham >=20 > > -----Original Message----- > > From: ext Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Monday, September 01, 2003 12:20 PM > > To: Khartabil Hisham (NMP/Helsinki); fluffy@cisco.com; > > dean.willis@softarmor.com > > Cc: Brian.Rosen@marconi.com; sip@ietf.org > > Subject: AW: AW: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > You should not need to route this call anyway, because=20 > > normally you should > > not see such a context out of the context. The idea is: if=20 > > you know the context > > then you also know how to route the call, if you do not know=20 > > the context, > > you just say invalid number. In other contexts only global=20 > > understandable > > URIs should be used > > =20 > > Richard > >=20 > > -----Urspr=C3=BCngliche Nachricht-----=20 > > Von: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com]=20 > > Gesendet: Mo 01.09.2003 10:45=20 > > An: fluffy@cisco.com; Stastny Richard;=20 > > dean.willis@softarmor.com=20 > > Cc: Brian.Rosen@marconi.com; sip@ietf.org=20 > > Betreff: RE: AW: AW: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > =09 > > =09 > >=20 > > So, I'll ask the question again, this time for real: > > =09 > > Under the informative text in 2806bis labeled "A Use of=20 > > "tel" URIs with SIP (Informative)", it says: > > =09 > > " > > 2. The outbound proxy does not use the same phone > > context, but can route to a proxy=20 > > that handles this > > phone context. This routing can be=20 > > done via a lookup > > table or the domain name of the phone=20 > > context might be > > set up to reflect the SIP domain name=20 > > of a suitable > > proxy. For example, a proxy may=20 > > always route calls > > with tel URIs like > > =09 > > tel:1234;phone-context=3Dmunich.example.com > > =09 > > to the SIP proxy located at=20 > > munich.example.com." > > =09 > > =09 > > So, how does the proxy route this message to=20 > > munich.example.com? Or how does it discover the proxy at=20 > > munich.example.com? > > =09 > > The reason I'm asking this again is due to my proposal=20 > > in earlier emails to use a tel URI for dial strings and sip=20 > > URI for pure sip users. > > =09 > > Is there something wrong with mandating that if an=20 > > entity placed a tel-URI in a sip request along with a=20 > > phone-context carrying a domain name, then that domain name=20 > > must be the address of a sip proxy? > > =09 > > /Hisham > > =09 > > > -----Original Message----- > > > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Saturday, August 30, 2003 2:48 AM > > > To: Stastny Richard; Khartabil Hisham (NMP/Helsinki);=20 > > Dean Willis > > > Cc: Brian Rosen; sip@ietf.org > > > Subject: Re: AW: AW: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > > > > > > > > > > > I don't know what I was thinking - I gave the wrong answer. > > > The context in > > > the tel does not at mean you should attempt to route the call > > > to there - it > > > is just an identifier of the namespace of who=20 > > understands the number. > > > > > > On 8/29/03 13:50, "Stastny Richard"=20 > > wrote: > > > > > > >>> So, how does the proxy route this message to=20 > > munich.example.com? > > > >>> > > > >>> /Hisham > > > >>> > > > >> > > > >> The same way it routes sip:fluffy@munich.example.com > > > > > > > > Tell that to Dean :) He thinks it is not routable (that's > > > the point I was > > > > trying to make). > > > > > > > > Warning: this needs NOT to be true and IMHO this part of > > > > the informational section is misleading. In section 5.1.4 > > > Local numbers > > > > it is clearly stated: > > > > > > > > "There are two ways to label the context: via a global > > > number or any | > > > > number of its leading digits (e.g., "+33") and via a > > > domain name, | > > > > e.g., "houston.example.com". The choice between the two is > > > left to | > > > > the "owner" of the local number and is governed by whether > > > there is a | > > > > global number or domain name that is a valid identifier > > > for a | > > > > particular local number. > > > > | > > > > The domain name does not have to resolve to any actual > > > host, but MUST | > > > > be under the administrative control of the entity managing > > > the local | > > > > phone context. " > > > > > > > > Since the domain name does not have to resolve to=20 > > an actual host, > > > > one cannot rely on this, so your statement may be wrong. > > > > > > > > Richard > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > > Von: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > Gesendet: Fr 29.08.2003 17:31 > > > > An: fluffy@cisco.com; dean.willis@softarmor.com > > > > Cc: Brian.Rosen@marconi.com; sip@ietf.org > > > > Betreff: RE: AW: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] > > > >> Sent: Friday, August 29, 2003 5:51 PM > > > >> To: Khartabil Hisham (NMP/Helsinki); Dean Willis > > > >> Cc: Brian Rosen; sip@ietf.org > > > >> Subject: Re: AW: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > > >> > > > >> > > > >> On 8/29/03 1:03, "hisham.khartabil@nokia.com" > > > >> > > > >> wrote: > > > >> > > > >>> Under the informative text in 2806bis labeled "A Use of > > > >> "tel" URIs with SIP > > > >>> (Informative)", it says: > > > >>> > > > >>> " > > > >>> 2. The outbound proxy does not use=20 > > the same phone > > > >>> context, but can route to a proxy that > > > handles this > > > >>> phone context. This routing can be done > > > via a lookup > > > >>> table or the domain name of the phone > > > >> context might be > > > >>> set up to reflect the SIP domain name of > > > a suitable > > > >>> proxy. For example, a proxy may=20 > > always route calls > > > >>> with tel URIs like > > > >>> > > > >>> tel:1234;phone-context=3Dmunich.example.com > > > >>> > > > >>> to the SIP proxy located at=20 > > munich.example.com." > > > >>> > > > >>> > > > >>> So, how does the proxy route this message to=20 > > munich.example.com? > > > >>> > > > >>> /Hisham > > > >>> > > > >> > > > >> The same way it routes sip:fluffy@munich.example.com > > > > > > > > Tell that to Dean :) He thinks it is not routable (that's > > > the point I was > > > > trying to make). > > > > > > > > Regards, > > > > Hisham > > > > > > > > > > > >> > > > >> > > > >> > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions=20 > > on current sip > > > > Use sipping@ietf.org for new developments on the=20 > > application of sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on=20 > > current sip > > > Use sipping@ietf.org for new developments on the=20 > > application of sip > > > > > =09 > >=20 > >=20 > J*fj)b bm?=0C> 0'~ffX)=DF=A3"8bX+=1FDY=D7=AFzZ)ay+y"=0F>-%R=C7=ACWz{h,rny=DB=9Fzb{(=CB=AB= *T"'~~{=07^hg'=17bqbz=1F >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 21:37:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01202 for ; Fri, 19 Sep 2003 21:37:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhC3020140 for ; Fri, 19 Sep 2003 21:36:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PFLo4w014558 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 11:21:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJ9d-0003d4-NA; Mon, 25 Aug 2003 11:21:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIzy-0003Cy-Nx for sip@optimus.ietf.org; Mon, 25 Aug 2003 11:11:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23141 for ; Mon, 25 Aug 2003 11:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rIzw-0002OV-00 for sip@ietf.org; Mon, 25 Aug 2003 11:11:12 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rIzv-0002O9-00 for sip@ietf.org; Mon, 25 Aug 2003 11:11:11 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22507; Mon, 25 Aug 2003 11:10:36 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17707; Mon, 25 Aug 2003 11:10:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 11:10:26 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D2B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "Rosen, Brian" , "'Henning Schulzrinne'" , "Conroy, Lawrence (SMTP)" Cc: Adam Roach , sip@ietf.org, Richard Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Mon, 25 Aug 2003 11:10:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Someone just pointed out to me that there could be confusion on who translates a dial string to a routable number. If you send sip:@;user=phone, then , or at least a proxy that understands the dialing plan, does the translation. That may or may not be the first hop proxy. Most phones that I know have configured; you don't type it. If you did, and it wasn't your local proxy, then you better understand how whatever you typed interprets your dial string, and your local proxy better not muck with it. Brian > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, August 25, 2003 10:05 AM > To: 'Henning Schulzrinne'; Conroy, Lawrence (SMTP) > Cc: Adam Roach; sip@ietf.org; Richard > Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] > SIPIT Inte rop problem with ;user=phone) > > > This breaks nearly every existing phone. Is that your intention? > > user=phone, at the moment, means "this is a dial string". > It used to be that you could do the same in a tel uri, but we > "fixed" that. Until we have overwhelming deployment of end devices > that translate dial strings to tel uris (PLEASE do not say > E.164s or global identifier, they are not all global numbers after > translation), we need to leave user=phone as the way to send a dial > string. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Sunday, August 24, 2003 10:52 AM > > To: Conroy, Lawrence (SMTP) > > Cc: Adam Roach; sip@ietf.org; Richard > > Subject: Re: Warning about dial plan assumptions (was RE: AW: [Sip] > > SIPIT Inte rop problem with ;user=phone) > > > > > > In an earlier iteration of this discussion in the IPTEL WG, > there was > > some consensus that the appropriate way is to download a > > dialplan into > > the end system, which then does the translation from dialed > > digits to a > > global identifier. That way, it doesn't matter where the SIP > > or tel URI > > ends up and removes the where-was-this-number-dialed > guessing by the > > outbound proxy. This should be part of the general configuration > > mechanism. I had volunteered to write up a spec for that, but I'm > > waiting for the general shape of the configuration data > > format to settle. > > > > Conroy, Lawrence (SMTP) wrote: > > > > > > > *I* would love such a specification, because it's what my > > > cellphone does. You wouldn't because you are in the NANP. > > > > > > Thus any spec mustn't be "over the wire" - it MUST be at > > > most an end system issue. It's dangerous for a Proxy to > > > interpret, as the expectations of the end user may differ. > > > > > > I'd be confused and miffed if I dialled 0117 and my proxy > > > and PSTN gateway gave me a Russian number rather than the > > > Bristol number I expected. So, no doubt, would the callee :). > > > > > > all the best, > > > Lawrence > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:03:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01373 for ; Fri, 19 Sep 2003 21:37:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCh020140 for ; Fri, 19 Sep 2003 21:36:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TBwFja012942 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 07:58:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgSJ-0007Ei-57; Fri, 29 Aug 2003 06:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19se6E-0006bx-60 for sip@optimus.ietf.org; Fri, 29 Aug 2003 03:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24242 for ; Fri, 29 Aug 2003 03:55:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19se6B-00041z-00 for sip@ietf.org; Fri, 29 Aug 2003 03:55:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19se6A-00041w-00 for sip@ietf.org; Fri, 29 Aug 2003 03:55:10 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7T7tA416506 for ; Fri, 29 Aug 2003 10:55:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Aug 2003 10:55:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 10:55:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Compressing subsequent REGISTER requests Date: Fri, 29 Aug 2003 10:55:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797027@esebe019.ntc.nokia.com> Thread-Topic: Compressing subsequent REGISTER requests Thread-Index: AcNsrE7rv0Sympw4QlKAoIsm29FjoQBVk3Rw To: Cc: X-OriginalArrivalTime: 29 Aug 2003 07:55:08.0631 (UTC) FILETIME=[DDC71E70:01C36E02] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable A resend since no one replied. ------------------------ Hi, RFC3486 says: "a user agent server SHOULD add comp=3Dsigcomp to the Contact header field of the response if the URI of the next upstream hop in the route set contained the parameter comp=3Dsigcomp" I assume this is for dialog creating responses. What about REGISTER? If I send the very first REGISTER request uncompressed since I didn't = know if it supports sigcomp. I can never learn through a similar = mechanism as defined above if any subsequent REGISTER request should be = compressed or not. One solution is for the registrar to record-route (yuk). The other is to = rely on the response being compressed as a hint, but I don't think this = is good enough since the registrar did not get the chance to indicate = its willingness to receive compressed requests. We could also say that if an initial REGISTER is not compressed, then = any subsequent REGISTER cannot be compressed. Thanks, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:04:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01439 for ; Fri, 19 Sep 2003 21:37:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhD5020140 for ; Fri, 19 Sep 2003 21:36:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TKJ4Vu008105 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 16:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snvx-0005Ss-Dd; Fri, 29 Aug 2003 14:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19slDZ-0006EC-BC for sip@optimus.ietf.org; Fri, 29 Aug 2003 11:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03014 for ; Fri, 29 Aug 2003 11:31:10 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slDY-0005a9-00 for sip@ietf.org; Fri, 29 Aug 2003 11:31:16 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19slDX-0005a6-00 for sip@ietf.org; Fri, 29 Aug 2003 11:31:15 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7TFVD417036 for ; Fri, 29 Aug 2003 18:31:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Aug 2003 18:31:13 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 18:31:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 29 Aug 2003 18:31:12 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797032@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNuPPLbcMlKwRMIQqKuRrlZbfZmZAABXzBA To: , Cc: , X-OriginalArrivalTime: 29 Aug 2003 15:31:12.0210 (UTC) FILETIME=[93BDEB20:01C36E42] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, August 29, 2003 5:51 PM > To: Khartabil Hisham (NMP/Helsinki); Dean Willis > Cc: Brian Rosen; sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > On 8/29/03 1:03, "hisham.khartabil@nokia.com"=20 > > wrote: >=20 > > Under the informative text in 2806bis labeled "A Use of=20 > "tel" URIs with SIP > > (Informative)", it says: > >=20 > > " > > 2. The outbound proxy does not use the same phone > > context, but can route to a proxy that handles this > > phone context. This routing can be done via a lookup > > table or the domain name of the phone=20 > context might be > > set up to reflect the SIP domain name of a suitable > > proxy. For example, a proxy may always route calls > > with tel URIs like > >=20 > > tel:1234;phone-context=3Dmunich.example.com > >=20 > > to the SIP proxy located at munich.example.com." > >=20 > >=20 > > So, how does the proxy route this message to munich.example.com? > >=20 > > /Hisham > > >=20 > The same way it routes sip:fluffy@munich.example.com Tell that to Dean :) He thinks it is not routable (that's the point I = was trying to make). Regards, Hisham >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:05:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01442 for ; Fri, 19 Sep 2003 21:37:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCr020140 for ; Fri, 19 Sep 2003 21:36:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QIrsCE014500 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 14:53:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riwm-0003dX-U6; Tue, 26 Aug 2003 14:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rcUL-0001HQ-FT for sip@optimus.ietf.org; Tue, 26 Aug 2003 07:59:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00452 for ; Tue, 26 Aug 2003 07:59:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rcUK-0007ma-00 for sip@ietf.org; Tue, 26 Aug 2003 07:59:52 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19rcUJ-0007mX-00 for sip@ietf.org; Tue, 26 Aug 2003 07:59:51 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7QBxm401306 for ; Tue, 26 Aug 2003 14:59:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Aug 2003 14:59:47 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 26 Aug 2003 14:59:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 26 Aug 2003 14:59:46 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796FF8@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNqU/X+nVojMdtGQjmJW16vOGIbngBdJ9lw To: , Cc: , X-OriginalArrivalTime: 26 Aug 2003 11:59:47.0127 (UTC) FILETIME=[8B9A9C70:01C36BC9] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Why isn't this the problem of tel: URI? I dare to make the suggestion that the tel URI itself can have a = parameter called "domain" or something similar to accommodate the = scenario Rohan presents? We can then deprecate user=3Dphone and any use of telephone-subscriber = in a sip URI. SIP URI then always carries a SIP URI. Thanks, Hisham=20 > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 24, 2003 6:27 PM > To: Cullen Jennings > Cc: Robert Sparks; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > Hi Folks, >=20 > To tie Cullen's comments more concretely to the discussion, I have=20 > always interpreted the semantics of ;user=3Dphone to mean that the = user=20 > part has been converted from a tel URL but that someone wants=20 > this tel=20 > URL to be handled in the context of a particular SIP domain. >=20 > If a SIP UA just collects a string of digits "1234" (this is=20 > not a tel=20 > URL), slaps on the domain name of their proxy, and then sends these=20 > digits there without interpretation, then you just end up with an=20 > ordinary SIP URI (user=3Dip): >=20 > sip:1234@mylocalproxy.example.com >=20 > however, I think it is much more useful for the UA to generate a tel=20 > URL here instead: >=20 > tel:1234;phone-context=3D+14085551111 >=20 > Note that both of these are correctly scoped. tel:1234 is=20 > illegal, as=20 > should be sip:1234@mylocalproxy.example.com;user=3Dphone (IMO). >=20 >=20 > Why not deprecate ;user=3Dphone entirely? Aside from backwards=20 > compatibility, there is actually a very good reason. Since tel: URIs=20 > don't have a domain portion, there is no way for me to send a tel URL=20 > through a loose-routed service and still convey which domain I would=20 > like the tel URI to be handled in. >=20 > So lets say that I send this INVITE >=20 > INVITE tel:+14085268570 SIP/2.0 > Route: > ... >=20 > transcoders.org will either reject the request or send it to whatever=20 > PSTN gateway it feels like using. I would like to the INVITE=20 > to go to=20 > a specific provider out of a list of several of these, but I do not=20 > want to negotiate the specific user-part naming convention with each=20 > one: >=20 > INVITE sip:+14085268570@provider1.com;user=3Dphone SIP/2.0 > Route: >=20 > Likewise I can use SIPS to go to a different provider: >=20 > INVITE sips:+14085268570@provider2.net;user=3Dphone SIP/2.0 >=20 > Continuing on in this vein, say I REFER Jiri (in Europe) to=20 > call Adam's=20 > cell phone (in Texas). It would be much nicer to provide=20 > this Refer-To=20 > URI: >=20 > sips:+19991234567@dfw-gw.dynamicsoft.com;user=3Dphone (a tel URL=20 > addressed to a particular SIP UA) >=20 > instead of: >=20 > tel:+19991234567 >=20 > (since Jiri may need to discover such a gateway, or be billed for an=20 > International PSTN call when he has a perfectly good Internet he can=20 > use instead for the "expensive" part of the call). >=20 > So, I think the ;user=3Dphone is in fact very useful (even if only as = a=20 > standardized convention). If it is used at all I think the user part=20 > MUST be a valid global-number or local-number with ;phone-context=20 > paramter, if user=3Dphone is in the SIP URI. >=20 >=20 > thanks, > -rohan >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:05:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01286 for ; Fri, 19 Sep 2003 21:37:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCL020140 for ; Fri, 19 Sep 2003 21:36:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG7KYf006422 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:07:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nmo-0001ar-Rq; Fri, 19 Sep 2003 12:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nlr-0001Nt-23 for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06750 for ; Fri, 19 Sep 2003 12:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Byj-0000Mz-00 for sip@ietf.org; Thu, 18 Sep 2003 23:30:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0BoC-0006Sb-00 for sip@ietf.org; Thu, 18 Sep 2003 23:19:49 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2003 20:19:59 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8J3JHJs002108; Thu, 18 Sep 2003 20:19:17 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALS50167; Thu, 18 Sep 2003 20:07:01 -0700 (PDT) Date: Thu, 18 Sep 2003 18:19:54 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Francois Audet'" , "'Bob Penfield'" , "'Paul Kyzivat'" , "'sip@ietf.org'" To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5E82@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <6029BDCC-EA3F-11D7-A981-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, September 15, 2003, at 11:40 AM, Rosen, Brian wrote: > I'm sorry, but when the draft says: > "Dial strings are beyond the scope of this document." > to me, means dial string is not legal in a tel uri. To me this statement simply means that the *internal semantics* of dial strings are not defined in that document. It does not say "you MUST not put a dial string into the phone-number portion of a local-number" Perhaps it should say that no special considerations for dial strings are included in the document. Specifically wait and pause are missing, but that is not what you are describing. thanks, -rohan > The text describes a dial string the way you (and I) interpret one: > Dial string: "Dial strings" are the actual numbers, symbols and > pauses entered by a user to place a phone call. A dial- > string is consumed by one or more network entities, and > understood in the context of the configuration of these > entities. > It says that it's not in scope. > We can create a new RFC that extends this one, but at the moment, > you cannot put a dial string in a tel uri. > > Specifications are all about "terminology". We usually > don't create gray areas on purpose -- well, maybe sometimes we do :( > > It's necessary to have a way to send a dial string > that has pound, star and commas (or p/w, which is what > 2543 did), which is not allowed in a tel uri. > > Dial strings are interpretted into something else. > That is a phone number, and might need some other processing. > You can send what a dial string translates into in a tel uri. > We have to have a way to denote that which is not a phone > number, but is a dial string. That is what user=phone could > do. > > Brian > > -----Original Message----- > From: Francois Audet [mailto:audet@nortelnetworks.com] > Sent: Monday, September 15, 2003 2:21 PM > To: 'Rosen, Brian'; 'Paul Kyzivat' > Cc: 'Bob Penfield'; 'sip@ietf.org' > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > >> Well this goes to the issue Paul and I have disagreed on. >> >> I think the wording of the tel uri RFC is quite clear that >> you can't pass a dial string in one. You certainly can't >> pass one with >> star and pound. Therefore, I claim, there is no way to pass >> a dial string, unless you put it in a username on a SIP uri, >> and denote that it is a dial string, for which a phone number >> is a proper subset for most dial plans, by specifying user=phone. >> >> Paul disagrees. He thinks he can send a dial string in a tel >> uri. Without some kind of resolution of that issue, we have a problem. > Let's not be too hung up on terminology. Yes indeed, a pure "dial > string" > shall > not be included in a SIP URI (especially the pound and star). > However, it is valid to have a "number" in a tel URI who's format is > valid only under a specific context. That context could happen to be > closely > > linked to a "dialing plan", including the "6" prefix in an enterprise, > or > the "00", "01" in a carrier network. I'm not sure we can call this a > "dial string" per se as there will be some sort of minimal processing > done > by the phone anyways (including removing the star and pound). > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:05:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01305 for ; Fri, 19 Sep 2003 21:37:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCP020140 for ; Fri, 19 Sep 2003 21:36:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG7K35006545 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:07:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nmq-0001bB-Lh; Fri, 19 Sep 2003 12:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nlr-0001O0-6M for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06749 for ; Fri, 19 Sep 2003 12:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Byt-0000Q2-00 for sip@ietf.org; Thu, 18 Sep 2003 23:30:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0BoD-0006Sb-00 for sip@ietf.org; Thu, 18 Sep 2003 23:19:49 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2003 20:20:02 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8J3JGJs002102; Thu, 18 Sep 2003 20:19:20 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALS50166; Thu, 18 Sep 2003 20:07:00 -0700 (PDT) Date: Thu, 18 Sep 2003 18:16:59 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Francois Audet'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5E7A@whq-msgusr-02.pit.comms.marconi.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: > Well this goes to the issue Paul and I have disagreed on. > > I think the wording of the tel uri RFC is quite clear that you > can't pass a dial string in one. You certainly can't pass one with > star and pound. Therefore, I claim, there is no way to pass > a dial string Brian, What part of a dial string doesn't fit into: 1*phonedigit ? phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" E corresponds to * and F corresponds to # thanks, -rohan > , unless you put it in a username on a SIP uri, > and denote that it is a dial string, for which a phone number is > a proper subset for most dial plans, by specifying user=phone. > > Paul disagrees. He thinks he can send a dial string in a tel uri. > Without some kind of resolution of that issue, we have a problem. > > Brian > -----Original Message----- > From: Francois Audet [mailto:audet@nortelnetworks.com] > Sent: Monday, September 15, 2003 12:10 PM > To: 'Paul Kyzivat' > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, September 15, 2003 06:58 >> To: Audet, Francois [SC100:4K02:EXCH] >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > [ stuff deleted as it looks like we are in agreement ] >> I'm not sure about the "most" part. Some do, some don't. As spec is >> currently written, the equivalence between tel and sip/user=phone is >> only one way. (IF the userpart comes from a tel, then there >> SHOULD be a >> user=phone, but the presence of user=phone does not imply the >> userpart >> conforms to tel.) >> >> I personally am happy with the more strict interpretation. But I am >> trying to hold out an olive branch in order to reach a level >> of agreement. > OK. It seems that we are in agreement. > My suggestion is to ask the question to the group of is anybody > objects to make it explicit that user=phones means that the sip URI is > derived > from a tel URI? > If the answer is no, then I think we can probably finally put this > issue > to rest. Otherwise, we need to rework the whole thing... > So... Does anybody strongly object to explicitly making the user=phone > atttribute mean that the SIP URI was derived from a tel URI? >>> Applying the rules of RFC3261/19.1.6 instead, we'd get: >>> >>> >>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone >>> >>> Which (like the tel URI) specifically identifies the >> dialing plan and >>> does not require one DNS entry per dialling plan. >> >> >> I agree that this is also a fine usage. >> >> But what is benefit of this over using the tel format and >> then passing >> the request to sip:foo.bar? > The tel URI format assumes that the proxy knows which proxy is aware > of the > phone context > and tel URIs (it could be itself, or it could know which proxy to route > sessions to). > The sip URI format lets you route it to a specific proxy that is aware > of > the phone > context, potentially with "generic" SIP proxies in between that have > no idea > how to route > based on phone contextes (or even tel URIs). T > > > They both have merits. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:05:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01619 for ; Fri, 19 Sep 2003 21:37:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhDf020140 for ; Fri, 19 Sep 2003 21:37:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGDwV6017270 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:13:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nrr-0003uJ-1b; Fri, 19 Sep 2003 12:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NoH-0002OM-8F for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08546 for ; Fri, 19 Sep 2003 12:08:25 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A04OG-0007BY-00 for sip@ietf.org; Thu, 18 Sep 2003 15:24:32 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A04AC-0005u8-00 for sip@ietf.org; Thu, 18 Sep 2003 15:10:00 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8IJ9x607136 for ; Thu, 18 Sep 2003 22:09:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Sep 2003 22:09:59 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 18 Sep 2003 22:09:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 18 Sep 2003 22:09:59 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179710C@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN9/pyB0JENYdc2TnacoNpW5zjHaQAF+kkA To: Cc: , , , , X-OriginalArrivalTime: 18 Sep 2003 19:09:59.0312 (UTC) FILETIME=[745DB900:01C37E18] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This discussion about the use of user=3Dphone is not going anywhere. Let = me list what people want to use it for: 1. to indicate that the userinfo part of a request-uri is really a = tel-uri (Rohan): +123456789@example.com;user=3Dphone 2. to indicate that a tel-uri used to be in the request-uri and has been = translated at some point by some proxy (Brian): = user@example.com;user=3Dthisusedtobeateluri 3. to indicate that a user has entered a dial string. The proxy needs to = figure out if the digits need to be translated into a tel-URI. The UA = does not have a dialling plan: 12345@example.com;user=3Dphone Also there are issues of who should have dialling plans. What use cases = require the UA to have dialling plans? Regards, Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, September 18, 2003 7:05 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; adam@dynamicsoft.com; > Brian.Rosen@marconi.com; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 >=20 > On Thu, 18 Sep 2003 hisham.khartabil@nokia.com wrote: >=20 > > > > > > > -----Original Message----- > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Wednesday, September 17, 2003 7:35 PM > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com;=20 > adam@dynamicsoft.com; > > > Brian.Rosen@marconi.com; sip@ietf.org > > > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > > > > > On Tuesday, September 16, 2003, at 11:27 PM, > > > wrote: > > > > > > > I afraid C has the same problem as B. > > > > > > No, it doesn't. Nobody except a server authoritative for=20 > mci.com is > > > allowed to interpret that URI. This is very clear for SIP and SIPS > > > URIs. We don't have this kind of restriction on tel URIs. > > > > Section 16.5 states: > > > > "If the domain of the Request-URI indicates a domain this element is > > not responsible for, the Request-URI MUST be placed into=20 > the target > > set as the only target, and the element MUST proceed to=20 > the task of > > Request Forwarding (Section 16.6)." > > > > Section 16.6 states (step 6): > > > > "A proxy MAY have a local policy that mandates that a request > > visit a specific set of proxies before being=20 > delivered to the > > destination" > > > > and step 7: > > > > "The proxy MAY have a local policy to send the request to a > > specific IP address, port, and transport,=20 > independent of the > > values of the Route and Request-URI" > > > > Using your example C below, there is nothing restricting=20 > transcoder.com from forwarding the request to att.com even if=20 > the request-URI is a sip URI. Its transcoder.com local policy. >=20 >=20 > agreed, there is nothing retricting trasncoder.com sending=20 > the request to > att.com, but att.com then needs to forward this request on=20 > the mci.com. > att.com does not get to process the userpart of a URI which ends in > mci.com. (unless they buy them ;-) >=20 > however, in case B, att.com could just process the tel URI in=20 > the request > URI and never send the request to mci.com. >=20 > thanks, > -rohan >=20 >=20 > > /Hisham > > > > > > > > thanks, > > > -rohan > > > > > > > /Hisham > > > > > > > > > > > >> -----Original Message----- > > > >> From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > >> Sent: Tuesday, September 16, 2003 7:27 PM > > > >> To: Robert Sparks > > > >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; sip@ietf.org > > > >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > >> > > > >> > > > >> > > > >> On Tuesday, September 16, 2003, at 07:01 AM, Robert=20 > Sparks wrote: > > > >> > > > >>> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: > > > >>> > > > >>>> While I do not object to sending tel URIs to SIP proxies, > > > >> I believe I > > > >>>> already articulated some reasons why you might want to use > > > >> sip or sips > > > >>>> instead. > > > >>>> > > > >>>> 1) want to use SIPS > > > >>> > > > >>> Agreed! > > > >>> > > > >>>> 2) want to route the call to a specific domain that is not > > > >> the domain > > > >>>> of your first hop proxy. > > > >>>> 3) want to invoke a loose router for services like > > > >> transcoding or call > > > >>>> history logging that have different tel URI handling > > > rules than you > > > >>>> want to use. > > > >>> > > > >>> Both 2 and 3 can be solved by pushing or preloading routes. > > > >> > > > >> OK, I was being sloppy. Looking at several options. > > > >> > > > >> A. > > > >> INVITE tel:+14085264000 SIP/2.0 > > > >> Route: > > > >> > > > >> A is not so good, because you have no control over what > > > >> transcoders.com > > > >> does with tel URLs (It might reject them, or send you=20 > a big bill). > > > >> > > > >> B. > > > >> > > > >> INVITE tel:+14085264000 SIP/2.0 > > > >> Route: , > > > >> > > > >> B would probably work, but seems much more cumbersome=20 > than C. In > > > >> addition, transcoders.com might forward all calls=20 > toward mci.com > > > >> through some other domain (att.com) which might just take > > > the tel URL > > > >> and process it itself. > > > >> > > > >> C. > > > >> > > > >> INVITE sip:+14085264000@mci.com;user=3Dphone SIP/2.0 > > > >> Route: > > > >> > > > >> C is explicit, it works, and it contains no extra info. > > > >> > > > >> thanks, > > > >> -rohan > > > >> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol > > > >> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > > > >> Use sipping@ietf.org for new developments on the=20 > application of sip > > > >> > > > > > > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:05:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01648 for ; Fri, 19 Sep 2003 21:37:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEZ020140 for ; Fri, 19 Sep 2003 21:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TLrCi8025465 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19soLy-0006xi-J4; Fri, 29 Aug 2003 14:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snln-0004TB-2O for sip@optimus.ietf.org; Fri, 29 Aug 2003 14:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20085 for ; Fri, 29 Aug 2003 14:14:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19snlk-0002le-00 for sip@ietf.org; Fri, 29 Aug 2003 14:14:44 -0400 Received: from fmr09.intel.com ([192.52.57.35] helo=hermes.hd.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19snlj-0002l5-00 for sip@ietf.org; Fri, 29 Aug 2003 14:14:43 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7TIBu212370 for ; Fri, 29 Aug 2003 18:11:56 GMT Received: from pysmsxvs01.py.intel.com (pysmsxvs01.py.intel.com [146.152.3.51]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7TI96e04323 for ; Fri, 29 Aug 2003 18:09:06 GMT Received: from pysmsx331.amr.corp.intel.com ([146.152.3.52]) by pysmsxvs01.py.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082914141316802 for ; Fri, 29 Aug 2003 14:14:13 -0400 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by pysmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Aug 2003 14:14:12 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E59.597B09EA" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: [Sip] Proposal for 'Transfer-From' INVITE header. Date: Fri, 29 Aug 2003 14:14:12 -0400 Message-ID: <410D4ECF895A5C4BBBA1F6984D0C7AA71A85E2@pysmsx401.amr.corp.intel.com> Thread-Topic: [Sip] Proposal for 'Transfer-From' INVITE header. Thread-Index: AcNuWVg8q/cDcjUnSsy4hxqpSJhrbA== From: "Greier, Tom" To: Cc: "Greier, Tom" X-OriginalArrivalTime: 29 Aug 2003 18:14:12.0888 (UTC) FILETIME=[597AF180:01C36E59] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C36E59.597B09EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, =20 I am usually a passive reader of this forum, but there has been an issue that my development group has been struggling with for a while. We have been using a 'proprietary' header for some time, for which I am hoping to legitimize via a draft or get information as to existing solutions. =20 On most PBX and key system digital stations, in order to perform a supervised transfer of a call, the transferee is put onhold and a new call is automatically created in the dialtone state. The transfer target is then dialed on the new dialtone call. If the transferor decides to complete the transfer, the transferor usually either hangs up or presses a transfer key to complete the transfer. =20 This scenario is a two-step transfer process: =20 1) Put transferee onhold-pend-transfer, which creates new call to be dialed on to reach transfer destination. 2) Complete transfer. =20 The two-step transfer process allows the transferor to possibly abort the transfer, drop the transfer destination and reconnect to the transferee call. =20 In implementing a PBX/SIP gateway to PBX/key systems that operate in this manner, we have a problem with Re-INVITE (hold), INVITE (new party), REFER/replaces to perform the transfer. When the gateway receives the Re-INVITE (hold) method, the gateway does not know the 'intent' of the hold request. Is it a regular 'put the call onhold', or is the requestor intending to later make another outbound call on the same line and transfer the original call. On a PBX, the 'intent' needs to be known upfront, since the way that the call is put onhold depends on the intent of the requester (put the call onhold so another call can be made, or put the call onhold-pend-transfer to eventually dial a transfer target). =20 In order to support this functionality, we have been using our own 'Transfer-From' header. The 'Transfer-From' header is placed in the INVITE that the requestor sends to dial the transfer destination. The 'Transfer-From' header specifies the call-ID of the transferee call that the gateway should put onhold-pend-transfer. The destination specified by the INVITE in the To header is then dialed as the transfer destination. If the requestor later sends a REFER/replaces specifying the transferee and the transfer target, then the gateway completes the transfer. The requestor can also send a BYE or CANCEL on the transfer target dialog to drop the transfer target and unhold the original transferee call. Media is then re-established to the original transferee call upon the gateway receiving a Re-INVITE (unhold) request. =20 I know that this is very specific to a PBX-gateway device, but is what we are doing relevant to any other interfaces/implementations? Is this header viable in any broader sense, is it worth a draft, or is there an existing standard for this type of functionality? =20 Thank you for your help. =20 Tom Greier Intel Corporation Network Building Block Division 55 Dodge Rd. Getzville, NY 14068 =20 Phone: (716) 639-3211 mailto:tom.greier@Intel.com =20 ------_=_NextPart_001_01C36E59.597B09EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello=20 All,
 
I am = usually a=20 passive reader of this forum, but there has been an issue that my = development=20 group has been struggling with for a while. We have been using a = 'proprietary'=20 header for some time, for which I am hoping to legitimize via a draft or = get=20 information as to existing solutions.
 
On = most PBX and key=20 system digital stations, in order to perform a supervised transfer of a = call,=20 the transferee is put onhold and a new call is automatically created in = the=20 dialtone state. The transfer target is then dialed on the new dialtone = call. If=20 the transferor decides to complete the transfer, the transferor usually = either=20 hangs up or presses a transfer key to complete the = transfer.
 
This = scenario is a=20 two-step transfer process:
 
1) Put = transferee=20 onhold-pend-transfer, which creates new call to be dialed on to reach = transfer=20 destination.
2) = Complete=20 transfer.
 
The = two-step=20 transfer process allows the transferor to possibly abort the transfer, = drop the=20 transfer destination and reconnect to the transferee = call.
 
In = implementing a=20 PBX/SIP gateway to PBX/key systems that operate in this manner, we have = a=20 problem with Re-INVITE (hold), INVITE (new party), REFER/replaces to = perform the=20 transfer. When the gateway receives the Re-INVITE (hold) method, the = gateway=20 does not know the 'intent' of the hold request. Is it a regular 'put the = call=20 onhold', or is the requestor intending to later make another outbound = call on=20 the same line and transfer the original call. On a PBX, the 'intent' = needs to be=20 known upfront, since the way that the call is put onhold depends on the = intent=20 of the requester (put the call onhold so another call can be made, or = put the=20 call onhold-pend-transfer to eventually dial a transfer=20 target).
 
In = order to support=20 this functionality, we have been using our own 'Transfer-From' header. = The=20 'Transfer-From' header is placed in the INVITE that the requestor sends = to dial=20 the transfer destination. The 'Transfer-From' header specifies the = call-ID=20 of the transferee call that the gateway should put onhold-pend-transfer. = The=20 destination specified by the INVITE in the To header is then dialed as = the=20 transfer destination. If the requestor later sends a REFER/replaces = specifying=20 the transferee and the transfer target, then the gateway completes the = transfer.=20 The requestor can also send a BYE or CANCEL on the transfer target = dialog to=20 drop the transfer target and unhold the original transferee call. Media = is then=20 re-established to the original transferee call upon the gateway = receiving a=20 Re-INVITE (unhold) request.
 
I know = that this is=20 very specific to a PBX-gateway device, but is what we are doing relevant = to any=20 other interfaces/implementations? Is this header viable in any broader = sense, is=20 it worth a draft, or is there an existing standard for this type of=20 functionality?
 
Thank = you for your=20 help.
 
Tom Greier
Intel = Corporation
Network Building=20 Block Division
55 Dodge Rd.
Getzville, NY = 14068
 
Phone: (716) = 639-3211
mailto:tom.greier@Intel.com
 
=00 ------_=_NextPart_001_01C36E59.597B09EA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00206 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9v020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82KPNkv021344 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 16:25:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uHhz-0005V6-7N; Tue, 02 Sep 2003 16:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uGsY-0002qG-H3 for sip@optimus.ietf.org; Tue, 02 Sep 2003 15:31:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00100 for ; Tue, 2 Sep 2003 15:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uGsX-0004bl-00 for sip@ietf.org; Tue, 02 Sep 2003 15:31:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uGsW-0004bK-00 for sip@ietf.org; Tue, 02 Sep 2003 15:31:48 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h82JVC7f007098 for ; Tue, 2 Sep 2003 12:31:17 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACA31896; Tue, 2 Sep 2003 15:31:12 -0400 (EDT) Message-ID: <3F54F000.40306@cisco.com> Date: Tue, 02 Sep 2003 15:31:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] test - please ignore Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00065 for ; Fri, 19 Sep 2003 21:36:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9J020140 for ; Fri, 19 Sep 2003 21:36:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DfVDS011850 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 09:41:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u688-0007MQ-8O; Tue, 02 Sep 2003 04:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u02E-0003P7-JL for sip@optimus.ietf.org; Mon, 01 Sep 2003 21:32:42 -0400 Received: from web20108.mail.yahoo.com (web20108.mail.yahoo.com [216.136.226.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19675 for ; Mon, 1 Sep 2003 21:32:34 -0400 (EDT) Message-ID: <20030902013238.1298.qmail@web20108.mail.yahoo.com> Received: from [210.22.174.110] by web20108.mail.yahoo.com via HTTP; Mon, 01 Sep 2003 18:32:38 PDT Date: Mon, 1 Sep 2003 18:32:38 -0700 (PDT) From: "xiao'tong liang" Subject: Re: [Sip] Re: the meaning of the user agent field in SIP To: Anu Gupta Cc: sip@vovida.org, sip@ietf.org In-Reply-To: <20030901052211.330.qmail@web40103.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , User Agent in SIP network always means terminals(call originated or terminated entity). Terminals can appear in many kinds: the inner UAs in gateway, the inner UAs in server(such as Voice mail server), also can be a UA in SIP Phone. -- Liang xiaotong newrocktech.com Shanghai --- Anu Gupta wrote: > Hi All, > I am new to SIP and I need the meaning of the > user_agent field in SIP. If anyone knows kindly > reply. > Thanks, > Anu. > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00664 for ; Fri, 19 Sep 2003 21:36:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAr020140 for ; Fri, 19 Sep 2003 21:36:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7Q4dr8t014976 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 00:39:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rVc6-0003p3-QC; Tue, 26 Aug 2003 00:39:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rMOu-0006Dq-SN for sip@optimus.ietf.org; Mon, 25 Aug 2003 14:49:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09080 for ; Mon, 25 Aug 2003 14:49:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rMOs-00060J-00 for sip@ietf.org; Mon, 25 Aug 2003 14:49:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rMOr-0005zb-00 for sip@ietf.org; Mon, 25 Aug 2003 14:49:09 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2003 11:48:40 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7PIma7d028416 for ; Mon, 25 Aug 2003 11:48:38 -0700 (PDT) Received: from [128.107.171.79] ([128.107.171.79]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK98218; Mon, 25 Aug 2003 11:48:35 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 25 Aug 2003 11:48:36 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D2C@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit sip:1234@foo.com means send it to foo.com and foo will figure it out. sip:1234@foo.com;user=phone means send to to foo.com and foo will figure it out. Right now it is totally random if the UA puts in the user=phone or not and the proxies (as far as I can tell) mostly ignore it. I'm having a hard time figuring out what the requirement is for this extra 1 bit of information that currently has no semantic meaning. There is a certain amount of operational experience that indicates this flag is not needed. I think the whole thing is bogus unless someone can clearly state a requirement that says why the proxy might need to know some extra bit of information and clearly says how the UA would set this bit of information based on something the user entered on the UA. Defining something that all UAs will set to the same value or all proxies will ignore is useless. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01008 for ; Fri, 19 Sep 2003 21:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBN020140 for ; Fri, 19 Sep 2003 21:36:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TLUdcF020634 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snuy-0005IB-Kr; Fri, 29 Aug 2003 14:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skay-0003wn-7O for sip@optimus.ietf.org; Fri, 29 Aug 2003 10:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00205 for ; Fri, 29 Aug 2003 10:51:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skav-00052y-00 for sip@ietf.org; Fri, 29 Aug 2003 10:51:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19skav-00052c-00 for sip@ietf.org; Fri, 29 Aug 2003 10:51:21 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2003 07:50:51 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7TEomCb010407; Fri, 29 Aug 2003 07:50:49 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP23331; Fri, 29 Aug 2003 07:50:48 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Aug 2003 07:50:49 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: , Dean Willis CC: Brian Rosen , Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797028@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 8/29/03 1:03, "hisham.khartabil@nokia.com" wrote: > Under the informative text in 2806bis labeled "A Use of "tel" URIs with SIP > (Informative)", it says: > > " > 2. The outbound proxy does not use the same phone > context, but can route to a proxy that handles this > phone context. This routing can be done via a lookup > table or the domain name of the phone context might be > set up to reflect the SIP domain name of a suitable > proxy. For example, a proxy may always route calls > with tel URIs like > > tel:1234;phone-context=munich.example.com > > to the SIP proxy located at munich.example.com." > > > So, how does the proxy route this message to munich.example.com? > > /Hisham > The same way it routes sip:fluffy@munich.example.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00172 for ; Fri, 19 Sep 2003 21:36:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9j020140 for ; Fri, 19 Sep 2003 21:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PI6knP006372 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:06:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLjg-0001Zy-HW; Mon, 25 Aug 2003 14:06:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJxt-0005Vw-Js for sip@optimus.ietf.org; Mon, 25 Aug 2003 12:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26113 for ; Mon, 25 Aug 2003 12:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJxs-00033v-00 for sip@ietf.org; Mon, 25 Aug 2003 12:13:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19rJxr-00033i-00 for sip@ietf.org; Mon, 25 Aug 2003 12:13:07 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7PGCbd8012899; Mon, 25 Aug 2003 12:12:37 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 11:12:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863AA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , Adam Roach Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 25 Aug 2003 11:12:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: > I know that some phones DO have internal translations, > and they do send user=phone with a global number, but > that's a valid dial string, no? I'd propose to deprecate > that (use a tel uri), but allow it for backwards > compatibility I don't think we want to deprecate it. As has been pointed out already, one of the reasons that people transform tel: URIs into SIP URIs is that tel: URIs have no inherent routing properties. Yes, TRIP can be used for routing purposes, but that information is typically site-specific, not global. Often, the originating party will want to have more say in where a call goes than that. Consider: Route: , , Even if this made sense, I'm left at the mercy of proxy2's local routing logic with regards to who services my tel URI. Compare: Route: , , /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01111 for ; Fri, 19 Sep 2003 21:37:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBf020140 for ; Fri, 19 Sep 2003 21:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T63eAk023337 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 02:03:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sa5K-0006Xu-SQ; Thu, 28 Aug 2003 23:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXdz-0007XE-IE for sip@optimus.ietf.org; Thu, 28 Aug 2003 21:01:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07147 for ; Thu, 28 Aug 2003 21:01:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sXdx-0003Bd-00 for sip@ietf.org; Thu, 28 Aug 2003 21:01:37 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19sXdw-0003BY-00 for sip@ietf.org; Thu, 28 Aug 2003 21:01:36 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h7T11X5N024332; Thu, 28 Aug 2003 21:01:33 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h7T11WG15084; Thu, 28 Aug 2003 21:01:33 -0400 Message-ID: <3F4EA5EC.9090203@cs.columbia.edu> Date: Thu, 28 Aug 2003 21:01:32 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: hisham.khartabil@nokia.com, Brian.Rosen@marconi.com, fluffy@cisco.com, sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <2038BCC78B1AD641891A0D1AE133DBB701797014@esebe019.ntc.nokia.com> <1062093817.18183.37.camel@bdsl.greycouncil.com> In-Reply-To: <1062093817.18183.37.camel@bdsl.greycouncil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: > Citing an example inf RFC 2806: > > tel:0w003585551234567;phone-context=+3585551234 > > This URL places a voice call to the given number. The number format > is intended for local use: the first zero opens an outside line, the > "w" character waits for a second dial tone, and the number already > has the international access code appended to it ("00"). This kind of > phone number MUST NOT be used in an environment where all users of > this URL might not be able to successfully dial out by using this > number directly. However, this might be appropriate for pages in a > company intranet. The which is present hints that > the number is usable only in an environment where the local entity's > phone number starts with the given string (perhaps singling out a > company-wide block of telephone numbers). Note that 2806bis will explicitly disallow this type of dial string (0w00358...). Thus, this will not be a valid tel URI in the future. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00209 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9x020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7Q4dxDE015075 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 00:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rVcY-0003ud-AO; Tue, 26 Aug 2003 00:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rMTb-0006Ho-3c for sip@optimus.ietf.org; Mon, 25 Aug 2003 14:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09269 for ; Mon, 25 Aug 2003 14:53:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rMTY-00064E-00 for sip@ietf.org; Mon, 25 Aug 2003 14:54:00 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19rMTX-00063q-00 for sip@ietf.org; Mon, 25 Aug 2003 14:53:59 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7PIrSpF014415 for ; Mon, 25 Aug 2003 11:53:28 -0700 (PDT) Received: from [128.107.171.79] ([128.107.171.79]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHK98813; Mon, 25 Aug 2003 11:53:28 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 25 Aug 2003 11:53:29 -0700 Subject: FW: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Proposing a requirement as a reply to own email on what's the requirement .... A possible requirement is to indicate that a tel URL has been translated to SIP URL and we wish other domains to sent it to the named domain then have the named domain process it as a tel URL. Cullen ------ Forwarded Message From: Cullen Jennings Date: Mon, 25 Aug 2003 11:48:36 -0700 To: Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone sip:1234@foo.com means send it to foo.com and foo will figure it out. sip:1234@foo.com;user=phone means send to to foo.com and foo will figure it out. Right now it is totally random if the UA puts in the user=phone or not and the proxies (as far as I can tell) mostly ignore it. I'm having a hard time figuring out what the requirement is for this extra 1 bit of information that currently has no semantic meaning. There is a certain amount of operational experience that indicates this flag is not needed. I think the whole thing is bogus unless someone can clearly state a requirement that says why the proxy might need to know some extra bit of information and clearly says how the UA would set this bit of information based on something the user entered on the UA. Defining something that all UAs will set to the same value or all proxies will ignore is useless. Cullen ------ End of Forwarded Message _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00212 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhA1020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PI73jb006973 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 14:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLk1-0001kg-Ub; Mon, 25 Aug 2003 14:06:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJyx-0005Zp-9l for sip@optimus.ietf.org; Mon, 25 Aug 2003 12:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26150 for ; Mon, 25 Aug 2003 12:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJyv-00034J-00 for sip@ietf.org; Mon, 25 Aug 2003 12:14:13 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19rJyv-000348-00 for sip@ietf.org; Mon, 25 Aug 2003 12:14:13 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7PGDgvi025245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Aug 2003 11:13:42 -0500 From: "Dean Willis" To: Date: Mon, 25 Aug 2003 11:13:16 -0500 Message-ID: <004501c36b23$cb2da720$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Sip] More on dial plans and user=phones Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable It's all either far more complicated or far simpler than we seem to = think, and I'm confused as to which of the above is true. Let's talk about a "real" system -- my office, where we've been running everyday telephony using SIP phones and proxies and gateways for > 3 = years. We do phone-number routing, inbound and outbound from PSTN, and = user-name routing. But I'm not sure I've ever seen a user=3Dphone, and I don't think the = system would know what to do if it did. Assume than an INVITE arrives at my proxy with a request URI looking something like 9724735455@dynamicsoft.com. Is this a phone number or a user? Dunno, yet. We look in the proxy's configuration and see if 9724735455 is a defined user. If it is, we route the number according to the user's CPL. If not, = we treat it as a phone number and consult the proxy's dial plan table. This works for inbound, outbound, complex forwarding, calls through = other people's proxies (like iptel.org, which I use from the house), and so = on. Now: here's the tricky part -- as a user, I have to have some level of understanding of the dial plan that the proxy understands. For example, = I know that if I want to dial Dallas phone number 9725551212, I enter = exactly those digits, but if I want New Jersey's 9735551212, then I have to add = a leading 1 (19735551212), and if I want international +19735551212, then = I dial 0119735551212. Oddly enough, this makes the whole thing work just = fine without downloading any dial plans or using any tel-URIs or = user=3Dphones. If I wanted to use iptel.org's routing, I'd set my phone up to send digits@iptel.org instead, and I'd have to understand the dialing plan imposed by their proxy. This points something out: IF we do download dialing plans, then the = dialing plan has to stay synched between the phone and its default proxy, = applies ONLY to calls made through the default proxy, and MUST BE ignored if a different target domain is entered by the user. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:24:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01053 for ; Fri, 19 Sep 2003 21:37:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBV020140 for ; Fri, 19 Sep 2003 21:36:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QIwe9m018823 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 14:58:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj1O-0004jV-Hn; Tue, 26 Aug 2003 14:58:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rO92-0000ev-Bl for sip@optimus.ietf.org; Mon, 25 Aug 2003 16:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14942 for ; Mon, 25 Aug 2003 16:40:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rO90-00075J-00 for sip@ietf.org; Mon, 25 Aug 2003 16:40:54 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19rO8z-00074k-00 for sip@ietf.org; Mon, 25 Aug 2003 16:40:53 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HK700L5I01L1Y@firewall.wcom.com> for sip@ietf.org; Mon, 25 Aug 2003 20:39:25 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HK70020101IL2@pmismtp01.wcomnet.com>; Mon, 25 Aug 2003 20:39:22 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.112.36]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HK7000NC01GQL@pmismtp01.wcomnet.com>; Mon, 25 Aug 2003 20:39:19 +0000 (GMT) Date: Mon, 25 Aug 2003 15:39:15 -0500 From: Alan Johnston Subject: Re: [Sip] SIPIT Interop problem with ;user=phone In-reply-to: <1061561455.1787.9.camel@RjS.localdomain> X-Sender: Alan.Johnston@pop.mcit.com To: Robert Sparks , sip@ietf.org Message-id: <5.2.1.1.0.20030825152930.01edb708@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 10:10 AM 8/22/2003 -0400, Robert Sparks wrote: >I've seen a few interoperability failures at SIPIT 13 revolving >around the use of ;user=phone in sip URIs. > >We have some implementations assuming that the presence of ;user=phone >means that the first part of the userinfo portion of the URI MUST >be formatted as a telephone-subscriber. Asking around, I've found >that many people believe this is the case, but the spec does not >support this claim. In fact, all the specification says is >that if the userinfo portion is formatted as a telephone-subscriber >then the URI SHOULD also contain ;user=phone. > >So, is this an oversight? Are we allowing URIs with ;user=phone >but a non telephone-subscriber formatted userinfo part on purpose? > >Those with code making the above assumption fail to interoperate >with devices that gather an arbitrary number of digits and >just slap ;user=phone in the URI when creating a request. >For example: > > > >They reject this as a malformed URI since 15 doesn't parse per >telephone-subscriber. Is this being too strict? Yes - it is very strange to reject this URI. The SIP PSTN Call Flows document currently and always has shown URIs of this form, e.g. sip:551313@gw1.a.example.com;user=phone The SIP world is full of telephone and gateways that include the user=phone parameter - it seems way, way, too late to be defining strict semantics for this parameter or all kinds of bad interoperability things will happen. >Should they >try to interpret this as a "number that has meaning in their >local scope"? It certainly isn't safe to pretend the ;user=phone >wasn't there and try to interpret "15" as a username. What's >the right thing for them to do? > >A companion question is should a UA arbitrarily hang ;user=phone >off a digit string it collects from its user, or should it >transform that string into a telephone-subscriber formatted >number? > >Both questions have clear answers if we explicitly add that >if ;user=phone is present in a URI then the userinfo part >MUST be formatted as a telephone-subscriber. Would anyone >object to adding this requirement? This isn't backwards compatible, so I'd say no. Thanks, Alan Johnston MCI >RjS > > > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00373 for ; Fri, 19 Sep 2003 21:36:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhA9020140 for ; Fri, 19 Sep 2003 21:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TJfWbK002400 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 15:41:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snx8-0005bR-7C; Fri, 29 Aug 2003 14:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snNr-0003E5-Mw for sip@optimus.ietf.org; Fri, 29 Aug 2003 13:50:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17835 for ; Fri, 29 Aug 2003 13:49:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19snNp-00026f-00 for sip@ietf.org; Fri, 29 Aug 2003 13:50:01 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19snNo-00026L-00 for sip@ietf.org; Fri, 29 Aug 2003 13:50:00 -0400 Received: from amer.unity.cisco.com (ipcbu-exchange.cisco.com [64.101.140.91]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with SMTP id h7THnSJm022220; Fri, 29 Aug 2003 13:49:29 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] Update of display name during a call Date: Fri, 29 Aug 2003 12:49:28 -0500 Message-ID: Thread-Topic: [Sip] Update of display name during a call Thread-Index: AcNuUANjIOWMx4ewRcCRZ/TVykZpawABHpiw From: "Henry Chen" To: "Elwell, John" , "Cullen Jennings" , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The caller's name can be authenticated and put in a PAI header by a proxy in the initial Invite according to RFC3325.=20 The problem is how to pass called party name to the call originator when the call is forwarded by the proxy.=20 Is there any problem to put called party id or display name in a PAI header in the response to Invite by the proxy in the trusted domain serving the call? Thanks, Henry -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Friday, August 29, 2003 8:32 AM To: 'Cullen Jennings'; sip@ietf.org Subject: RE: [Sip] Update of display name during a call Cullen, In trusted situations where P-Asserted-ID is in use, I think it would be reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or UPDATE. John (john.elwell@siemens.com) -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 28 August 2003 21:11 To: sip@ietf.org Cc: Cullen Jennings Subject: [Sip] Update of display name during a call There has been some discussion on the issues of changing the display name associated with a call during the call. This has come up in QSIG cases, it has come up in B2BUA cases, and in some other PBX and PSTN interoperability issues. I think it is worth solving. How about this as a proposal. The UA can send an re-INVITE or UPDATE (as appropriate) with an AIB. The AIB can be authenticated in the normal way. The From and To inside the AIB can have a modified display name. The tag will not be changed. If a 2543 device receives one of these message, it may end up ignoring it but it will not cause harm. If a device that receives one of these and understands it, it SHOULD update the display name information. This can happen both from callee to caller and caller to callee. The AIB might have a PAI in it too. Section 12.2.1.1 of 3261 says Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. Clearly this is in line with that. AIBs are about identity and solve some of the complex issues of third parties asserting identity on behalf of others. I think this is a good place to deal with issues that is about the displayed identity. Thoughts? Issues with this? Better Ideas... Thanks, Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01020 for ; Fri, 19 Sep 2003 21:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBP020140 for ; Fri, 19 Sep 2003 21:36:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82IcHOZ001565 for sip-archive@odin.ietf.org; Tue, 2 Sep 2003 14:38:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uG2X-0000Lu-Ei; Tue, 02 Sep 2003 14:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uG2C-0000CK-OX for sip@optimus.ietf.org; Tue, 02 Sep 2003 14:37:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25016 for ; Tue, 2 Sep 2003 14:37:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uG29-0003I0-00 for sip@ietf.org; Tue, 02 Sep 2003 14:37:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19uG1i-0003FA-00 for sip@ietf.org; Tue, 02 Sep 2003 14:37:14 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2003 11:36:45 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h82Iagba002783; Tue, 2 Sep 2003 11:36:43 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALB11075; Tue, 2 Sep 2003 11:26:43 -0700 (PDT) Date: Tue, 2 Sep 2003 11:39:56 -0700 Subject: Re: [Sip] Proposal for 'Transfer-From' INVITE header. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Greier, Tom" From: Rohan Mahy In-Reply-To: <410D4ECF895A5C4BBBA1F6984D0C7AA71A85E2@pysmsx401.amr.corp.intel.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Have you seen this? http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt thanks, -rohan On Friday, August 29, 2003, at 11:14 AM, Greier, Tom wrote: > Hello All, > =A0 > I am usually a passive reader of this forum, but there has been an=20 > issue that my development group has been struggling with for a while.=20= > We have been using a 'proprietary' header for some time, for which I=20= > am hoping to legitimize via a draft or get information as to existing=20= > solutions. > =A0 > On most PBX and key system digital stations, in order to perform a=20 > supervised transfer of a call, the transferee is put onhold and a new=20= > call is automatically created in the dialtone state. The transfer=20 > target is then dialed on the new dialtone call. If the transferor=20 > decides to complete the transfer, the transferor usually either hangs=20= > up or presses a transfer key to complete the transfer. > =A0 > This scenario is a two-step transfer process: > =A0 > 1) Put transferee onhold-pend-transfer, which creates new call to be=20= > dialed on to reach transfer destination. > 2) Complete transfer. > =A0 > The two-step transfer process allows the transferor to possibly abort=20= > the transfer, drop the transfer destination and reconnect to the=20 > transferee call. > =A0 > In implementing a PBX/SIP gateway to PBX/key systems that operate in=20= > this manner, we have a problem with Re-INVITE (hold), INVITE (new=20 > party), REFER/replaces to perform the transfer. When the gateway=20 > receives the Re-INVITE (hold) method, the gateway does not know the=20 > 'intent' of the hold request. Is it a regular 'put the call onhold',=20= > or is the requestor intending to later make another outbound call on=20= > the same line and transfer the original call. On a PBX, the 'intent'=20= > needs to be known upfront, since the way that the call is put onhold=20= > depends on the intent of the requester (put the call onhold so another=20= > call can be made, or put the call onhold-pend-transfer to eventually=20= > dial a transfer target). > =A0 > In order to support this functionality, we have been using our own=20 > 'Transfer-From' header. The 'Transfer-From' header is placed in the=20 > INVITE that the requestor sends to dial the transfer destination.=20 > The=A0'Transfer-From' header specifies the call-ID of the transferee=20= > call that the gateway should put onhold-pend-transfer. The destination=20= > specified by the INVITE in the To header is then dialed as the=20 > transfer destination. If the requestor later sends a REFER/replaces=20 > specifying the transferee and the transfer target, then the gateway=20 > completes the transfer. The requestor can also send a BYE or CANCEL on=20= > the transfer target dialog to drop the transfer target and unhold the=20= > original transferee call. Media is then re-established to the original=20= > transferee call upon the gateway receiving a Re-INVITE (unhold)=20 > request. > =A0 > I know that this is very specific to a PBX-gateway device, but is what=20= > we are doing relevant to any other interfaces/implementations? Is this=20= > header viable in any broader sense, is it worth a draft, or is there=20= > an existing standard for this type of functionality? > =A0 > Thank you for your help. > =A0 > Tom Greier > Intel Corporation > Network Building Block Division > 55 Dodge Rd. > Getzville, NY 14068 > =A0 > Phone: (716) 639-3211 > mailto:tom.greier@Intel.com > =A0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00646 for ; Fri, 19 Sep 2003 21:36:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAj020140 for ; Fri, 19 Sep 2003 21:36:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TL9Eoq016766 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snvK-0005LC-1y; Fri, 29 Aug 2003 14:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl8Z-0005yE-LW for sip@optimus.ietf.org; Fri, 29 Aug 2003 11:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02641 for ; Fri, 29 Aug 2003 11:26:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sl8Y-0005Wj-00 for sip@ietf.org; Fri, 29 Aug 2003 11:26:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19sl8Y-0005W3-00 for sip@ietf.org; Fri, 29 Aug 2003 11:26:06 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 29 Aug 2003 08:36:07 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7TFPX7b008634; Fri, 29 Aug 2003 08:25:34 -0700 (PDT) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP25873; Fri, 29 Aug 2003 08:25:32 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Aug 2003 08:25:33 -0700 Subject: Re: [Sip] Update of display name during a call From: Cullen Jennings To: "Elwell, John" , Message-ID: In-Reply-To: <50B1CBA96870A34799A506B2313F266761FCA2@ntht201e> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I did think about using the PAI header and it seemed to have some problems. One is that it is only usable in walled gardens and it would be nice to have a more generic solution than that but ignoring this, there are other problems too. Consider a call that passes through two trust different trust domains. The first trust domain MUST remove the PAI before it passes it to the second. Even if it did not remove it, the second MUST ignore it. Even if both domains failed to do this, the information being passed in the PAI is a network assertion of identity inside a single trust domain and may not correspond at all to the display information. For example, a trust domain might decide to use their billing identifier for the subscriber in the PAI. I'm fine with the PAI possibly overriding that From inside a AIB in the same way that a UA today can choose to trust the PAI more than the From. I don't think that PAI really works to pass display name updates in and out of trust domains and inside a trust domain it overloads two things that may be different on to one header. Cullen On 8/29/03 6:31, "Elwell, John" wrote: > Cullen, > > In trusted situations where P-Asserted-ID is in use, I think it would be > reasonable to use P-Asserted-ID rather than AIB in the re-INVITE or UPDATE. > > John (john.elwell@siemens.com) > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 August 2003 21:11 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Update of display name during a call > > > > There has been some discussion on the issues of changing the display name > associated with a call during the call. This has come up in QSIG cases, it > has come up in B2BUA cases, and in some other PBX and PSTN interoperability > issues. I think it is worth solving. > > How about this as a proposal. The UA can send an re-INVITE or UPDATE (as > appropriate) with an AIB. The AIB can be authenticated in the normal way. > The From and To inside the AIB can have a modified display name. The tag > will not be changed. If a 2543 device receives one of these message, it may > end up ignoring it but it will not cause harm. If a device that receives one > of these and understands it, it SHOULD update the display name information. > This can happen both from callee to caller and caller to callee. The AIB > might have a PAI in it too. > > Section 12.2.1.1 of 3261 says > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags are used for > dialog identification. It is expected that mandatory reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. > > Clearly this is in line with that. > > AIBs are about identity and solve some of the complex issues of third > parties asserting identity on behalf of others. I think this is a good place > to deal with issues that is about the displayed identity. > > Thoughts? Issues with this? Better Ideas... > > Thanks, Cullen > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00368 for ; Fri, 19 Sep 2003 21:36:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhA7020140 for ; Fri, 19 Sep 2003 21:36:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGLAqa023633 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O0H-00064s-8W; Fri, 19 Sep 2003 12:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nzp-0005uI-2O for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:20:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10138 for ; Fri, 19 Sep 2003 12:20:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Nzn-0005Cj-00 for sip@ietf.org; Fri, 19 Sep 2003 12:20:35 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1A0NzZ-0004m3-00 for sip@ietf.org; Fri, 19 Sep 2003 12:20:22 -0400 Received: from Natarajucl1127 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HLG00KNKY9XNO@mta0.huawei.com> for sip@ietf.org; Sat, 20 Sep 2003 00:10:47 +0800 (CST) Date: Fri, 19 Sep 2003 21:44:42 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Responses path in SIP. To: Noel Crespi , sip@ietf.org Cc: "'chadli'" Message-id: <002d01c37ec9$23112bc0$3d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_B5jUP/wqi9oNSgdyFb+JOg)" X-Priority: 3 X-MSMail-priority: Normal References: <005801c37dbf$3a9f9bb0$f0649f9d@intevry.fr> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_B5jUP/wqi9oNSgdyFb+JOg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- From: "Noel Crespi" To: Cc: "'chadli'" Sent: Thursday, September 18, 2003 2:01 PM Subject: [Sip] Responses path in SIP. Hi, In the RFC3261 there seems to be a contradiction about the path taken by the responses in a SIP transaction. It is in clear if the responses MUST or SHOULD follow the path defined by the Via header field. Different sections in RFC3261 mandate that responses MUST be sent to the location indicated in the topmost Via header field value, eg: - In section 8.1.1.7: "The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent " - In section 16.7: "The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value" - In section 16.11: "If that address matches the proxy,(it equals a value this proxy has inserted into previous requests)the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value" [Nataraj] this section is dealing about Route header not Via = ............. However section 20.42 states that: "The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses" So, MUST or SHOULD responses in a SIP transaction follow the path defined by the Via header field? Regards. Y.Chadli / N.Crespi INT/GET - Institut National des T=E9l=E9communications --Boundary_(ID_B5jUP/wqi9oNSgdyFb+JOg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
-----=20 Original Message -----
From: "Noel Crespi" <noel.crespi@int-evry.fr>
To: = <sip@ietf.org>
Cc: "'chadli'" = <youssef.chadli@int-evry.fr>
Sent: Thursday,=20 September 18, 2003 2:01 PM
Subject: [Sip] Responses path in=20 SIP.


Hi,
In the RFC3261 there seems to be a contradiction = about=20 the path taken by
the responses in a SIP transaction. It is in clear = if the=20 responses MUST
or SHOULD follow the path defined by the Via header=20 field.

Different sections in RFC3261 mandate that responses MUST = be sent=20 to the
location indicated in the topmost Via header field value, = eg:
- In=20 section 8.1.1.7: "The Via header field indicates the transport = used
for the=20 transaction and identifies the location where the response is to
be = sent=20 "
- In section 16.7: "The proxy MUST pass the response to the=20 server
transaction associated with the response context. This will = result=20 in
the response being sent to the location now indicated in the = topmost=20 Via
header field value"
- In section 16.11: "If that address = matches the=20 proxy,(it equals a
value this proxy has inserted into previous = requests)the=20 proxy MUST
remove that header field value from the response and = forward the=20 result
to the location indicated in the next Via header field=20 value"

[Nataraj]  this section is dealing about = Route header not Via = .............

However=20 section 20.42 states that: "The Via header field indicates the
path = taken by=20 the request so far and indicates the path that should be
followed in = routing=20 responses"

So,  MUST or SHOULD responses in a SIP = transaction=20 follow  the path
defined by the Via header=20 field?

Regards.
Y.Chadli / N.Crespi
INT/GET - Institut = National des=20 T=E9l=E9communications

 --Boundary_(ID_B5jUP/wqi9oNSgdyFb+JOg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01141 for ; Fri, 19 Sep 2003 21:37:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBl020140 for ; Fri, 19 Sep 2003 21:36:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGN6mi025267 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0O2B-0006Z2-Vc; Fri, 19 Sep 2003 12:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nfy-0007Tm-4m for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02696 for ; Fri, 19 Sep 2003 11:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0LPT-0006dq-00 for sip@ietf.org; Fri, 19 Sep 2003 09:34:55 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1A0L9g-0004tI-00 for sip@ietf.org; Fri, 19 Sep 2003 09:18:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05723; Fri, 19 Sep 2003 09:17:44 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12476; Fri, 19 Sep 2003 09:17:44 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 09:17:43 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5EC1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: "'Francois Audet'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 09:17:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I've never seen E/F substitution for */#, and I've never seen any sip device that did it, but it's a possible way forward. I do think that some RFC would have to change the wording of 2806bis to allow dial strings. The authors seemed to explicitly declare them out of scope of the document. Generally, we don't usually claim "that which is not specifically disallowed is legal" as a way around "out of scope" wording in our documents. I remain unhappy that dial strings, untranslated phone numbers and translated phone numbers are indistinguishable. They are different, they are handled differently, and they should be distinguishable. I don't understand why some people are so adamant that they should all be represented in EXACTLY the same way (tel uri or sip uri with or without user=phone). They are not the same things, and they should have distinctive representations. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, September 18, 2003 9:17 PM > To: Rosen, Brian > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: > > Well this goes to the issue Paul and I have disagreed on. > > > > I think the wording of the tel uri RFC is quite clear that you > > can't pass a dial string in one. You certainly can't pass one with > > star and pound. Therefore, I claim, there is no way to pass > > a dial string > > Brian, What part of a dial string doesn't fit into: 1*phonedigit ? > > phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / > "8" / "9" / > "A" / "B" / "C" / "D" / "E" / "F" > > E corresponds to * and F corresponds to # > > thanks, > -rohan > > > > , unless you put it in a username on a SIP uri, > > and denote that it is a dial string, for which a phone number is > > a proper subset for most dial plans, by specifying user=phone. > > > > Paul disagrees. He thinks he can send a dial string in a tel uri. > > Without some kind of resolution of that issue, we have a problem. > > > > Brian > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortelnetworks.com] > > Sent: Monday, September 15, 2003 12:10 PM > > To: 'Paul Kyzivat' > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, September 15, 2003 06:58 > >> To: Audet, Francois [SC100:4K02:EXCH] > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > [ stuff deleted as it looks like we are in agreement ] > >> I'm not sure about the "most" part. Some do, some don't. As spec is > >> currently written, the equivalence between tel and > sip/user=phone is > >> only one way. (IF the userpart comes from a tel, then there > >> SHOULD be a > >> user=phone, but the presence of user=phone does not imply the > >> userpart > >> conforms to tel.) > >> > >> I personally am happy with the more strict interpretation. But I am > >> trying to hold out an olive branch in order to reach a level > >> of agreement. > > OK. It seems that we are in agreement. > > My suggestion is to ask the question to the group of is anybody > > objects to make it explicit that user=phones means that the > sip URI is > > derived > > from a tel URI? > > If the answer is no, then I think we can probably finally put this > > issue > > to rest. Otherwise, we need to rework the whole thing... > > So... Does anybody strongly object to explicitly making the > user=phone > > atttribute mean that the SIP URI was derived from a tel URI? > >>> Applying the rules of RFC3261/19.1.6 instead, we'd get: > >>> > >>> > >>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > >>> > >>> Which (like the tel URI) specifically identifies the > >> dialing plan and > >>> does not require one DNS entry per dialling plan. > >> > >> > >> I agree that this is also a fine usage. > >> > >> But what is benefit of this over using the tel format and > >> then passing > >> the request to sip:foo.bar? > > The tel URI format assumes that the proxy knows which proxy > is aware > > of the > > phone context > > and tel URIs (it could be itself, or it could know which > proxy to route > > sessions to). > > The sip URI format lets you route it to a specific proxy > that is aware > > of > > the phone > > context, potentially with "generic" SIP proxies in between > that have > > no idea > > how to route > > based on phone contextes (or even tel URIs). T > > > > > > They both have merits. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:25:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00573 for ; Fri, 19 Sep 2003 21:36:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAP020140 for ; Fri, 19 Sep 2003 21:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JGKc6i022787 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:20:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NzL-0005sU-IB; Fri, 19 Sep 2003 12:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NyZ-0005TK-Te for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:19:25 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09518 for ; Fri, 19 Sep 2003 12:17:04 -0400 (EDT) Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2003 09:00:00 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8JG2mxW003957; Fri, 19 Sep 2003 09:02:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALS81421; Fri, 19 Sep 2003 08:50:26 -0700 (PDT) Date: Fri, 19 Sep 2003 09:06:36 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Francois Audet'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5EC1@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <3EB51D12-EABB-11D7-A981-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian, I don't think even humans can distinguish between dial strings and phone numbers without the appropriate context. For example, the following is both a real dial string at Cisco for intersite dialing, and a local phone number in Stockholm (and probably many other places as well). 85268570 likewise, I worked at NASA in 1993 who had a 7-digit dialplan. Most dial strings there where indistinguishable from local 7-digit numbers in use North America (this was before 10-digit dialing came to Atlanta, New York, etc..). AFAIK, most users do not understand the distinction you are making. Is *69 a phone number or a dial string? How about 411 in North America? What about "0" in North America and "9" in many other parts of the world? Was that a phone number or a dial string? I have concluded that as long as the set of digits is properly labeled with the correct context it really doesn't matter, and that this type of distinction between dial strings and phone numbers is artificial and academic. If you would like to use some additional private conventions inside your domains that is fine, but I don't think we are going to get consensus on the difference between a phone number and a dial string in this forum. Finally, I think the intention of 2806bis is to ignore pauses and waits of various tones, and I think we agree that those don't need to go inside a tel URI. thanks, -rohan On Friday, September 19, 2003, at 06:17 AM, Rosen, Brian wrote: > I've never seen E/F substitution for */#, and I've never seen any > sip device that did it, but it's a possible way forward. > > I do think that some RFC would have to change the wording of > 2806bis to allow dial strings. The authors seemed to explicitly > declare them out of scope of the document. Generally, we don't > usually claim "that which is not specifically disallowed is legal" > as a way around "out of scope" wording in our documents. > > I remain unhappy that dial strings, untranslated phone numbers > and translated phone numbers are indistinguishable. They are > different, > they are handled differently, and they should be distinguishable. > I don't understand why some people are so adamant that they should all > be represented in EXACTLY the same way (tel uri or sip uri with > or without user=phone). They are not the same things, and they > should have distinctive representations. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, September 18, 2003 9:17 PM >> To: Rosen, Brian >> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >> >> >> On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: >>> Well this goes to the issue Paul and I have disagreed on. >>> >>> I think the wording of the tel uri RFC is quite clear that you >>> can't pass a dial string in one. You certainly can't pass one with >>> star and pound. Therefore, I claim, there is no way to pass >>> a dial string >> >> Brian, What part of a dial string doesn't fit into: 1*phonedigit ? >> >> phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / >> "8" / "9" / >> "A" / "B" / "C" / "D" / "E" / "F" >> >> E corresponds to * and F corresponds to # >> >> thanks, >> -rohan >> >> >>> , unless you put it in a username on a SIP uri, >>> and denote that it is a dial string, for which a phone number is >>> a proper subset for most dial plans, by specifying user=phone. >>> >>> Paul disagrees. He thinks he can send a dial string in a tel uri. >>> Without some kind of resolution of that issue, we have a problem. >>> >>> Brian >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortelnetworks.com] >>> Sent: Monday, September 15, 2003 12:10 PM >>> To: 'Paul Kyzivat' >>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, September 15, 2003 06:58 >>>> To: Audet, Francois [SC100:4K02:EXCH] >>>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >>> [ stuff deleted as it looks like we are in agreement ] >>>> I'm not sure about the "most" part. Some do, some don't. As spec is >>>> currently written, the equivalence between tel and >> sip/user=phone is >>>> only one way. (IF the userpart comes from a tel, then there >>>> SHOULD be a >>>> user=phone, but the presence of user=phone does not imply the >>>> userpart >>>> conforms to tel.) >>>> >>>> I personally am happy with the more strict interpretation. But I am >>>> trying to hold out an olive branch in order to reach a level >>>> of agreement. >>> OK. It seems that we are in agreement. >>> My suggestion is to ask the question to the group of is anybody >>> objects to make it explicit that user=phones means that the >> sip URI is >>> derived >>> from a tel URI? >>> If the answer is no, then I think we can probably finally put this >>> issue >>> to rest. Otherwise, we need to rework the whole thing... >>> So... Does anybody strongly object to explicitly making the >> user=phone >>> atttribute mean that the SIP URI was derived from a tel URI? >>>>> Applying the rules of RFC3261/19.1.6 instead, we'd get: >>>>> >>>>> >>>>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone >>>>> >>>>> Which (like the tel URI) specifically identifies the >>>> dialing plan and >>>>> does not require one DNS entry per dialling plan. >>>> >>>> >>>> I agree that this is also a fine usage. >>>> >>>> But what is benefit of this over using the tel format and >>>> then passing >>>> the request to sip:foo.bar? >>> The tel URI format assumes that the proxy knows which proxy >> is aware >>> of the >>> phone context >>> and tel URIs (it could be itself, or it could know which >> proxy to route >>> sessions to). >>> The sip URI format lets you route it to a specific proxy >> that is aware >>> of >>> the phone >>> context, potentially with "generic" SIP proxies in between >> that have >>> no idea >>> how to route >>> based on phone contextes (or even tel URIs). T >>> >>> >>> They both have merits. >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 19 22:54:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01273 for ; Fri, 19 Sep 2003 21:37:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCJ020140 for ; Fri, 19 Sep 2003 21:36:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PEdjTi008624 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 10:39:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIV1-00026E-T4; Mon, 25 Aug 2003 10:39:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIU2-0001z0-Ol for sip@optimus.ietf.org; Mon, 25 Aug 2003 10:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21484 for ; Mon, 25 Aug 2003 10:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rIU0-0001xX-00 for sip@ietf.org; Mon, 25 Aug 2003 10:38:12 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rITz-0001wU-00 for sip@ietf.org; Mon, 25 Aug 2003 10:38:11 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21334; Mon, 25 Aug 2003 10:37:37 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13173; Mon, 25 Aug 2003 10:37:39 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 10:37:38 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D26@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christer Holmberg (SE/LMF)'" , "'Henning Schulzrinne'" , "Conroy, Lawrence (SMTP)" Cc: Adam Roach , sip@ietf.org, Richard Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Mon, 25 Aug 2003 10:37:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think it can mean anything the proxy that knows how to translate a dial string to a "full" routable URI allows it to mean. So, the answer is no. it doesn't have to parse as telephone-subscriber. It has to parse as userinfo. Brian > -----Original Message----- > From: Christer Holmberg (SE/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Monday, August 25, 2003 10:18 AM > To: 'Rosen, Brian'; 'Henning Schulzrinne'; Conroy, Lawrence (SMTP) > Cc: Adam Roach; sip@ietf.org; Richard > Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] > SIPIT Inte rop problem with ;user=phone) > > > > Hi, > > Assuming that user=phone means "this is a dial string", does > it also means that the syntax has to be according to the > telephone-subscriber ABNF? Ie, do we use "+" instead of "00", > can we use visual separators without nodes treating them as > actual parts of the actual user identifier, etc etc etc? OR, > shall we define a separate syntax for "dial-string" in a > SIP-URI? I think THAT is the question that started this > discussion at the SIPit. > > Regards, > > Christer Holmberg > Ericsson Finland > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 25. elokuuta 2003 17:05 > > To: 'Henning Schulzrinne'; Conroy, Lawrence (SMTP) > > Cc: Adam Roach; sip@ietf.org; Richard > > Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] > > SIPIT Inte rop problem with ;user=phone) > > > > > > This breaks nearly every existing phone. Is that your intention? > > > > user=phone, at the moment, means "this is a dial string". > > It used to be that you could do the same in a tel uri, but we > > "fixed" that. Until we have overwhelming deployment of end devices > > that translate dial strings to tel uris (PLEASE do not say > > E.164s or global identifier, they are not all global numbers after > > translation), we need to leave user=phone as the way to send a dial > > string. > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Sunday, August 24, 2003 10:52 AM > > > To: Conroy, Lawrence (SMTP) > > > Cc: Adam Roach; sip@ietf.org; Richard > > > Subject: Re: Warning about dial plan assumptions (was RE: > AW: [Sip] > > > SIPIT Inte rop problem with ;user=phone) > > > > > > > > > In an earlier iteration of this discussion in the IPTEL WG, > > there was > > > some consensus that the appropriate way is to download a > > > dialplan into > > > the end system, which then does the translation from dialed > > > digits to a > > > global identifier. That way, it doesn't matter where the SIP > > > or tel URI > > > ends up and removes the where-was-this-number-dialed > > guessing by the > > > outbound proxy. This should be part of the general configuration > > > mechanism. I had volunteered to write up a spec for that, but I'm > > > waiting for the general shape of the configuration data > > > format to settle. > > > > > > Conroy, Lawrence (SMTP) wrote: > > > > > > > > > > *I* would love such a specification, because it's what my > > > > cellphone does. You wouldn't because you are in the NANP. > > > > > > > > Thus any spec mustn't be "over the wire" - it MUST be at > > > > most an end system issue. It's dangerous for a Proxy to > > > > interpret, as the expectations of the end user may differ. > > > > > > > > I'd be confused and miffed if I dialled 0117 and my proxy > > > > and PSTN gateway gave me a Russian number rather than the > > > > Bristol number I expected. So, no doubt, would the callee :). > > > > > > > > all the best, > > > > Lawrence > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:53:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04333 for ; Sat, 20 Sep 2003 09:53:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OzN-00041S-QD for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHODkA015402 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OzC-0003z7-Ea; Fri, 19 Sep 2003 13:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Oyo-0003vI-OK for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:23:38 -0400 Received: from quartz.mw.3com.com (quartz.mw.3com.com [192.65.73.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15848 for ; Fri, 19 Sep 2003 13:23:18 -0400 (EDT) From: Cibu.Johny@utstar.com Received: from gypsum.mw.3com.com (gypsum.mw.3com.com [149.112.20.3]) by quartz.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8JHSjfH020535 for ; Fri, 19 Sep 2003 10:28:45 -0700 (PDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8JHNtNl010818 for ; Fri, 19 Sep 2003 10:23:55 -0700 (PDT) To: sip@ietf.org Date: Fri, 19 Sep 2003 12:23:09 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 09/19/2003 12:23:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] npi=,ton= tag values for SIP to QSIG mapping Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, What are the possible values for npi= and ton= tag values in the INVITE Request-URI header in order to map QSIG NPI & TON numbers? Is there any draft available for this? I searched quite a bit, but failed to get any draft or example from the web. Help really appreciated. -thanks, Cibu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:53:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04298 for ; Sat, 20 Sep 2003 09:53:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEw-0005wd-Of for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:40:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHeIFB022726 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEo-0005tr-Ft; Fri, 19 Sep 2003 13:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEO-0005s2-Oh for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:39:45 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16696 for ; Fri, 19 Sep 2003 13:39:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15712; Fri, 19 Sep 2003 13:37:26 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23206; Fri, 19 Sep 2003 13:37:24 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 13:37:24 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5ED3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Stastny Richard'" , Rohan Mahy Cc: Francois Audet , Paul Kyzivat , Bob Penfield , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 13:37:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard My phone number within my local domain is 742-6826. I could change the convention and make it 724-742-6826 or 1-724-742-6826 if you want. My dial plan would send a call to a different phone if you dialed any of those strings. If you send an INVITE 7426826@pit.sip.marconi.com it will ring my sipphone. =20 If I dial 7426826, it won't ring my sip phone. I have to dial 6826 or 9-742-6826 or even 300-6826. Using your algorithm, I would assume 7426826 was a dial string, and that would be wrong. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, September 19, 2003 1:24 PM > To: Rosen, Brian; Rohan Mahy > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > See below >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Gesendet: Fr 19.09.2003 15:17=20 > An: 'Rohan Mahy'=20 > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield';=20 > 'sip@ietf.org'=20 > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > =09 > =09 >=20 > I've never seen E/F substitution for */#, and I've=20 > never seen any > sip device that did it, but it's a possible way forward. > =09 > I do think that some RFC would have to change the wording of > 2806bis to allow dial strings. The authors seemed to explicitly > declare them out of scope of the document. Generally, we don't > usually claim "that which is not specifically=20 > disallowed is legal" > as a way around "out of scope" wording in our documents. > =09 > I remain unhappy that dial strings, untranslated phone numbers > and translated phone numbers are indistinguishable. =20 > They are different, > they are handled differently, and they should be=20 > distinguishable. > I don't understand why some people are so adamant that=20 > they should all > be represented in EXACTLY the same way (tel uri or sip uri with > or without user=3Dphone). They are not the same things, and they > should have distinctive representations. >=20 > Richard: A string of digits is a string of digits. >=20 > The simplest way to distinguish is: >=20 > 1. If you just see a string of digits, you have to assume its=20 > a dial string >=20 > until you know better. >=20 > 2. If you analysed the digits and found out its an E.164=20 > number, normalise it >=20 > to tel:+xxxx, or sip:+xxxx@foo.bar >=20 > 3. If you analysed it and found out it is a local number, then either >=20 > use tel:xxxx; phone-context=3Dfoo.bar or sip:xxx@foo.bar;user=3Dphone >=20 > I do not understand the problem >=20 > Richard >=20 > =09 > =09 > Brian > =09 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Thursday, September 18, 2003 9:17 PM > > To: Rosen, Brian > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield';=20 > 'sip@ietf.org' > > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > On Monday, September 15, 2003, at 10:23 AM, Rosen,=20 > Brian wrote: > > > Well this goes to the issue Paul and I have disagreed on. > > > > > > I think the wording of the tel uri RFC is quite=20 > clear that you > > > can't pass a dial string in one. You certainly=20 > can't pass one with > > > star and pound. Therefore, I claim, there is no=20 > way to pass > > > a dial string > > > > Brian, What part of a dial string doesn't fit into:=20 > 1*phonedigit ? > > > > phonedigit =3D "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / > > "8" / "9" / > > "A" / "B" / "C" / "D" / "E" / "F" > > > > E corresponds to * and F corresponds to # > > > > thanks, > > -rohan > > > > > > > , unless you put it in a username on a SIP uri, > > > and denote that it is a dial string, for which a=20 > phone number is > > > a proper subset for most dial plans, by specifying=20 > user=3Dphone. > > > > > > Paul disagrees. He thinks he can send a dial=20 > string in a tel uri. > > > Without some kind of resolution of that issue, we=20 > have a problem. > > > > > > Brian > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortelnetworks.com] > > > Sent: Monday, September 15, 2003 12:10 PM > > > To: 'Paul Kyzivat' > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Monday, September 15, 2003 06:58 > > >> To: Audet, Francois [SC100:4K02:EXCH] > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > >> Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone > > > [ stuff deleted as it looks like we are in agreement ] > > >> I'm not sure about the "most" part. Some do, some=20 > don't. As spec is > > >> currently written, the equivalence between tel and > > sip/user=3Dphone is > > >> only one way. (IF the userpart comes from a tel, then there > > >> SHOULD be a > > >> user=3Dphone, but the presence of user=3Dphone does=20 > not imply the > > >> userpart > > >> conforms to tel.) > > >> > > >> I personally am happy with the more strict=20 > interpretation. But I am > > >> trying to hold out an olive branch in order to=20 > reach a level > > >> of agreement. > > > OK. It seems that we are in agreement. > > > My suggestion is to ask the question to the group=20 > of is anybody > > > objects to make it explicit that user=3Dphones means that the > > sip URI is > > > derived > > > from a tel URI? > > > If the answer is no, then I think we can probably=20 > finally put this > > > issue > > > to rest. Otherwise, we need to rework the whole thing... > > > So... Does anybody strongly object to explicitly making the > > user=3Dphone > > > atttribute mean that the SIP URI was derived from a tel URI? > > >>> Applying the rules of RFC3261/19.1.6 instead, we'd get: > > >>> > > >>> > > >>>=20 > sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone > > >>> > > >>> Which (like the tel URI) specifically identifies the > > >> dialing plan and > > >>> does not require one DNS entry per dialling plan. > > >> > > >> > > >> I agree that this is also a fine usage. > > >> > > >> But what is benefit of this over using the tel format and > > >> then passing > > >> the request to sip:foo.bar? > > > The tel URI format assumes that the proxy knows which proxy > > is aware > > > of the > > > phone context > > > and tel URIs (it could be itself, or it could know which > > proxy to route > > > sessions to). > > > The sip URI format lets you route it to a specific proxy > > that is aware > > > of > > > the phone > > > context, potentially with "generic" SIP proxies in between > > that have > > > no idea > > > how to route > > > based on phone contextes (or even tel URIs). T > > > > > > > > > They both have merits. > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions=20 > on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > > =09 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > Use sipping@ietf.org for new developments on the=20 > application of sip > =09 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:53:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04328 for ; Sat, 20 Sep 2003 09:53:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P0E-0004BC-Tw for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHP6Kq016049 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P0C-00049M-Sk; Fri, 19 Sep 2003 13:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Oyz-0003w9-3j for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15862 for ; Fri, 19 Sep 2003 13:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Oys-0006ej-00 for sip@ietf.org; Fri, 19 Sep 2003 13:23:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1A0Oyh-0006aF-00 for sip@ietf.org; Fri, 19 Sep 2003 13:23:31 -0400 Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 19:23:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233855@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN+yyu9KMZ9hJ6pTUyXdTxCDF5vNAABh9HI From: "Stastny Richard" To: "Rosen, Brian" , "Rohan Mahy" Cc: "Francois Audet" , "Paul Kyzivat" , "Bob Penfield" , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 U2VlIGJlbG93DQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog Um9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbWFyY29uaS5jb21dIA0KCUdlc2VuZGV0 OiBGciAxOS4wOS4yMDAzIDE1OjE3IA0KCUFuOiAnUm9oYW4gTWFoeScgDQoJQ2M6ICdGcmFuY29p cyBBdWRldCc7ICdQYXVsIEt5eml2YXQnOyAnQm9iIFBlbmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycg DQoJQmV0cmVmZjogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBo b25lDQoJDQoJDQoNCglJJ3ZlIG5ldmVyIHNlZW4gRS9GIHN1YnN0aXR1dGlvbiBmb3IgKi8jLCBh bmQgSSd2ZSBuZXZlciBzZWVuIGFueQ0KCXNpcCBkZXZpY2UgdGhhdCBkaWQgaXQsIGJ1dCBpdCdz IGEgcG9zc2libGUgd2F5IGZvcndhcmQuDQoJDQoJSSBkbyB0aGluayB0aGF0IHNvbWUgUkZDIHdv dWxkIGhhdmUgdG8gY2hhbmdlIHRoZSB3b3JkaW5nIG9mDQoJMjgwNmJpcyB0byBhbGxvdyBkaWFs IHN0cmluZ3MuICBUaGUgYXV0aG9ycyBzZWVtZWQgdG8gZXhwbGljaXRseQ0KCWRlY2xhcmUgdGhl bSBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRvY3VtZW50LiAgR2VuZXJhbGx5LCB3ZSBkb24ndA0KCXVz dWFsbHkgY2xhaW0gInRoYXQgd2hpY2ggaXMgbm90IHNwZWNpZmljYWxseSBkaXNhbGxvd2VkIGlz IGxlZ2FsIg0KCWFzIGEgd2F5IGFyb3VuZCAib3V0IG9mIHNjb3BlIiB3b3JkaW5nIGluIG91ciBk b2N1bWVudHMuDQoJDQoJSSByZW1haW4gdW5oYXBweSB0aGF0IGRpYWwgc3RyaW5ncywgdW50cmFu c2xhdGVkIHBob25lIG51bWJlcnMNCglhbmQgdHJhbnNsYXRlZCBwaG9uZSBudW1iZXJzIGFyZSBp bmRpc3Rpbmd1aXNoYWJsZS4gIFRoZXkgYXJlIGRpZmZlcmVudCwNCgl0aGV5IGFyZSBoYW5kbGVk IGRpZmZlcmVudGx5LCBhbmQgdGhleSBzaG91bGQgYmUgZGlzdGluZ3Vpc2hhYmxlLg0KCUkgZG9u J3QgdW5kZXJzdGFuZCB3aHkgc29tZSBwZW9wbGUgYXJlIHNvIGFkYW1hbnQgdGhhdCB0aGV5IHNo b3VsZCBhbGwNCgliZSByZXByZXNlbnRlZCBpbiBFWEFDVExZIHRoZSBzYW1lIHdheSAodGVsIHVy aSBvciBzaXAgdXJpIHdpdGgNCglvciB3aXRob3V0IHVzZXI9cGhvbmUpLiAgVGhleSBhcmUgbm90 IHRoZSBzYW1lIHRoaW5ncywgYW5kIHRoZXkNCglzaG91bGQgaGF2ZSBkaXN0aW5jdGl2ZSByZXBy ZXNlbnRhdGlvbnMuDQoNClJpY2hhcmQ6IEEgc3RyaW5nIG9mIGRpZ2l0cyBpcyBhIHN0cmluZyBv ZiBkaWdpdHMuDQoNClRoZSBzaW1wbGVzdCB3YXkgdG8gZGlzdGluZ3Vpc2ggaXM6DQoNCjEuIElm IHlvdSBqdXN0IHNlZSBhIHN0cmluZyBvZiBkaWdpdHMsIHlvdSBoYXZlIHRvIGFzc3VtZSBpdHMg YSBkaWFsIHN0cmluZw0KDQp1bnRpbCB5b3Uga25vdyBiZXR0ZXIuDQoNCjIuIElmIHlvdSBhbmFs eXNlZCB0aGUgZGlnaXRzIGFuZCBmb3VuZCBvdXQgaXRzIGFuIEUuMTY0IG51bWJlciwgbm9ybWFs aXNlIGl0DQoNCnRvIHRlbDoreHh4eCwgb3Igc2lwOit4eHh4QGZvby5iYXINCg0KMy4gSWYgeW91 IGFuYWx5c2VkIGl0IGFuZCBmb3VuZCBvdXQgaXQgaXMgYSBsb2NhbCBudW1iZXIsIHRoZW4gZWl0 aGVyDQoNCnVzZSB0ZWw6eHh4eDsgcGhvbmUtY29udGV4dD1mb28uYmFyIG9yIHNpcDp4eHhAZm9v LmJhcjt1c2VyPXBob25lDQoNCkkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHByb2JsZW0NCg0KUmlj aGFyZA0KDQoJDQoJDQoJQnJpYW4NCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJ PiBGcm9tOiBSb2hhbiBNYWh5IFttYWlsdG86cm9oYW5AY2lzY28uY29tXQ0KCT4gU2VudDogVGh1 cnNkYXksIFNlcHRlbWJlciAxOCwgMjAwMyA5OjE3IFBNDQoJPiBUbzogUm9zZW4sIEJyaWFuDQoJ PiBDYzogJ0ZyYW5jb2lzIEF1ZGV0JzsgJ1BhdWwgS3l6aXZhdCc7ICdCb2IgUGVuZmllbGQnOyAn c2lwQGlldGYub3JnJw0KCT4gU3ViamVjdDogUmU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxl bSB3aXRoIDt1c2VyPXBob25lDQoJPg0KCT4NCgk+IE9uIE1vbmRheSwgU2VwdGVtYmVyIDE1LCAy MDAzLCBhdCAxMDoyMyBBTSwgUm9zZW4sIEJyaWFuIHdyb3RlOg0KCT4gPiBXZWxsIHRoaXMgZ29l cyB0byB0aGUgaXNzdWUgUGF1bCBhbmQgSSBoYXZlIGRpc2FncmVlZCBvbi4NCgk+ID4NCgk+ID4g SSB0aGluayB0aGUgd29yZGluZyBvZiB0aGUgdGVsIHVyaSBSRkMgaXMgcXVpdGUgY2xlYXIgdGhh dCB5b3UNCgk+ID4gY2FuJ3QgcGFzcyBhIGRpYWwgc3RyaW5nIGluIG9uZS4gIFlvdSBjZXJ0YWlu bHkgY2FuJ3QgcGFzcyBvbmUgd2l0aA0KCT4gPiBzdGFyIGFuZCBwb3VuZC4gICBUaGVyZWZvcmUs IEkgY2xhaW0sIHRoZXJlIGlzIG5vIHdheSB0byBwYXNzDQoJPiA+IGEgZGlhbCBzdHJpbmcNCgk+ DQoJPiBCcmlhbiwgIFdoYXQgcGFydCBvZiBhIGRpYWwgc3RyaW5nIGRvZXNuJ3QgZml0IGludG86 IDEqcGhvbmVkaWdpdCAgID8NCgk+DQoJPiBwaG9uZWRpZ2l0ID0gIjAiIC8gIjEiIC8gIjIiIC8g IjMiIC8gIjQiIC8gIjUiIC8gIjYiIC8gIjciIC8NCgk+ICI4IiAvICI5IiAvDQoJPiAgICAgICAg ICAgICAgICJBIiAvICJCIiAvICJDIiAvICJEIiAvICJFIiAvICJGIg0KCT4NCgk+IEUgY29ycmVz cG9uZHMgdG8gKiAgYW5kIEYgY29ycmVzcG9uZHMgdG8gIw0KCT4NCgk+IHRoYW5rcywNCgk+IC1y b2hhbg0KCT4NCgk+DQoJPiA+ICwgdW5sZXNzIHlvdSBwdXQgaXQgaW4gYSB1c2VybmFtZSBvbiBh IFNJUCB1cmksDQoJPiA+IGFuZCBkZW5vdGUgdGhhdCBpdCBpcyBhIGRpYWwgc3RyaW5nLCBmb3Ig d2hpY2ggYSBwaG9uZSBudW1iZXIgaXMNCgk+ID4gYSBwcm9wZXIgc3Vic2V0IGZvciBtb3N0IGRp YWwgcGxhbnMsIGJ5IHNwZWNpZnlpbmcgdXNlcj1waG9uZS4NCgk+ID4NCgk+ID4gUGF1bCBkaXNh Z3JlZXMuICBIZSB0aGlua3MgaGUgY2FuIHNlbmQgYSBkaWFsIHN0cmluZyBpbiBhIHRlbCB1cmku DQoJPiA+IFdpdGhvdXQgc29tZSBraW5kIG9mIHJlc29sdXRpb24gb2YgdGhhdCBpc3N1ZSwgd2Ug aGF2ZSBhIHByb2JsZW0uDQoJPiA+DQoJPiA+IEJyaWFuDQoJPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQoJPiA+IEZyb206IEZyYW5jb2lzIEF1ZGV0IFttYWlsdG86YXVkZXRAbm9ydGVs bmV0d29ya3MuY29tXQ0KCT4gPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAwMyAxMjox MCBQTQ0KCT4gPiBUbzogJ1BhdWwgS3l6aXZhdCcNCgk+ID4gQ2M6ICdSb3NlbiwgQnJpYW4nOyAn Qm9iIFBlbmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycNCgk+ID4gU3ViamVjdDogUkU6IFtTaXBdIFNJ UElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiA+DQoJPiA+DQoJPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gPj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWls dG86cGt5eml2YXRAY2lzY28uY29tXQ0KCT4gPj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTUs IDIwMDMgMDY6NTgNCgk+ID4+IFRvOiBBdWRldCwgRnJhbmNvaXMgW1NDMTAwOjRLMDI6RVhDSF0N Cgk+ID4+IENjOiAnUm9zZW4sIEJyaWFuJzsgJ0JvYiBQZW5maWVsZCc7ICdzaXBAaWV0Zi5vcmcn DQoJPiA+PiBTdWJqZWN0OiBSZTogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3Vz ZXI9cGhvbmUNCgk+ID4gWyBzdHVmZiBkZWxldGVkIGFzIGl0IGxvb2tzIGxpa2Ugd2UgYXJlIGlu IGFncmVlbWVudCBdDQoJPiA+PiBJJ20gbm90IHN1cmUgYWJvdXQgdGhlICJtb3N0IiBwYXJ0LiBT b21lIGRvLCBzb21lIGRvbid0LiBBcyBzcGVjIGlzDQoJPiA+PiBjdXJyZW50bHkgd3JpdHRlbiwg dGhlIGVxdWl2YWxlbmNlIGJldHdlZW4gdGVsIGFuZA0KCT4gc2lwL3VzZXI9cGhvbmUgaXMNCgk+ ID4+IG9ubHkgb25lIHdheS4gKElGIHRoZSB1c2VycGFydCBjb21lcyBmcm9tIGEgdGVsLCB0aGVu IHRoZXJlDQoJPiA+PiBTSE9VTEQgYmUgYQ0KCT4gPj4gdXNlcj1waG9uZSwgYnV0IHRoZSBwcmVz ZW5jZSBvZiB1c2VyPXBob25lIGRvZXMgbm90IGltcGx5IHRoZQ0KCT4gPj4gdXNlcnBhcnQNCgk+ ID4+IGNvbmZvcm1zIHRvIHRlbC4pDQoJPiA+Pg0KCT4gPj4gSSBwZXJzb25hbGx5IGFtIGhhcHB5 IHdpdGggdGhlIG1vcmUgc3RyaWN0IGludGVycHJldGF0aW9uLiBCdXQgSSBhbQ0KCT4gPj4gdHJ5 aW5nIHRvIGhvbGQgb3V0IGFuIG9saXZlIGJyYW5jaCBpbiBvcmRlciB0byByZWFjaCBhIGxldmVs DQoJPiA+PiBvZiBhZ3JlZW1lbnQuDQoJPiA+IE9LLiBJdCBzZWVtcyB0aGF0IHdlIGFyZSBpbiBh Z3JlZW1lbnQuDQoJPiA+IE15IHN1Z2dlc3Rpb24gaXMgdG8gYXNrIHRoZSBxdWVzdGlvbiB0byB0 aGUgZ3JvdXAgb2YgaXMgYW55Ym9keQ0KCT4gPiBvYmplY3RzIHRvIG1ha2UgaXQgZXhwbGljaXQg dGhhdCB1c2VyPXBob25lcyBtZWFucyB0aGF0IHRoZQ0KCT4gc2lwIFVSSSBpcw0KCT4gPiBkZXJp dmVkDQoJPiA+IGZyb20gYSB0ZWwgVVJJPw0KCT4gPiBJZiB0aGUgYW5zd2VyIGlzIG5vLCB0aGVu IEkgdGhpbmsgd2UgY2FuIHByb2JhYmx5IGZpbmFsbHkgcHV0IHRoaXMNCgk+ID4gaXNzdWUNCgk+ ID4gdG8gcmVzdC4gT3RoZXJ3aXNlLCB3ZSBuZWVkIHRvIHJld29yayB0aGUgd2hvbGUgdGhpbmcu Li4NCgk+ID4gU28uLi4gRG9lcyBhbnlib2R5IHN0cm9uZ2x5IG9iamVjdCB0byBleHBsaWNpdGx5 IG1ha2luZyB0aGUNCgk+IHVzZXI9cGhvbmUNCgk+ID4gYXR0dHJpYnV0ZSBtZWFuIHRoYXQgdGhl IFNJUCBVUkkgd2FzIGRlcml2ZWQgZnJvbSBhIHRlbCBVUkk/DQoJPiA+Pj4gQXBwbHlpbmcgdGhl IHJ1bGVzIG9mIFJGQzMyNjEvMTkuMS42IGluc3RlYWQsIHdlJ2QgZ2V0Og0KCT4gPj4+DQoJPiA+ Pj4NCgk+ID4+PiBzaXA6MTIzNDtwaG9uZS1jb250ZXh0PXlvdXItZGlhbHBsYW4uZm9vLmJhckBm b28uYmFyO3VzZXI9cGhvbmUNCgk+ID4+Pg0KCT4gPj4+IFdoaWNoIChsaWtlIHRoZSB0ZWwgVVJJ KSBzcGVjaWZpY2FsbHkgaWRlbnRpZmllcyB0aGUNCgk+ID4+IGRpYWxpbmcgcGxhbiBhbmQNCgk+ ID4+PiBkb2VzIG5vdCByZXF1aXJlIG9uZSBETlMgZW50cnkgcGVyIGRpYWxsaW5nIHBsYW4uDQoJ PiA+Pg0KCT4gPj4NCgk+ID4+IEkgYWdyZWUgdGhhdCB0aGlzIGlzIGFsc28gYSBmaW5lIHVzYWdl Lg0KCT4gPj4NCgk+ID4+IEJ1dCB3aGF0IGlzIGJlbmVmaXQgb2YgdGhpcyBvdmVyIHVzaW5nIHRo ZSB0ZWwgZm9ybWF0IGFuZA0KCT4gPj4gdGhlbiBwYXNzaW5nDQoJPiA+PiB0aGUgcmVxdWVzdCB0 byBzaXA6Zm9vLmJhcj8NCgk+ID4gVGhlIHRlbCBVUkkgZm9ybWF0IGFzc3VtZXMgdGhhdCB0aGUg cHJveHkga25vd3Mgd2hpY2ggcHJveHkNCgk+IGlzIGF3YXJlDQoJPiA+IG9mIHRoZQ0KCT4gPiBw aG9uZSBjb250ZXh0DQoJPiA+IGFuZCB0ZWwgVVJJcyAoaXQgY291bGQgYmUgaXRzZWxmLCBvciBp dCBjb3VsZCBrbm93IHdoaWNoDQoJPiBwcm94eSB0byByb3V0ZQ0KCT4gPiBzZXNzaW9ucyB0byku DQoJPiA+IFRoZSBzaXAgVVJJIGZvcm1hdCBsZXRzIHlvdSByb3V0ZSBpdCB0byBhIHNwZWNpZmlj IHByb3h5DQoJPiB0aGF0IGlzIGF3YXJlDQoJPiA+IG9mDQoJPiA+IHRoZSBwaG9uZQ0KCT4gPiBj b250ZXh0LCBwb3RlbnRpYWxseSB3aXRoICJnZW5lcmljIiBTSVAgcHJveGllcyBpbiBiZXR3ZWVu DQoJPiB0aGF0IGhhdmUNCgk+ID4gbm8gaWRlYQ0KCT4gPiBob3cgdG8gcm91dGUNCgk+ID4gYmFz ZWQgb24gcGhvbmUgY29udGV4dGVzIChvciBldmVuIHRlbCBVUklzKS4gVA0KCT4gPg0KCT4gPg0K CT4gPiBUaGV5IGJvdGggaGF2ZSBtZXJpdHMuDQoJPiA+DQoJPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiA+IFNpcCBtYWlsaW5nIGxpc3QgIGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCT4gPiBUaGlzIGxpc3Qg aXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCgk+ID4gVXNl IHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVu dCBzaXANCgk+ID4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24g dGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCT4NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KCVNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVs b3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCVVzZSBzaXAtaW1wbGVtZW50b3JzQGNz LmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQoJVXNlIHNpcHBpbmdA aWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0K CQ0KDQo= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:53:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04255 for ; Sat, 20 Sep 2003 09:53:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEw-0005wc-OG for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:40:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHeIob022728 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEm-0005tE-DN; Fri, 19 Sep 2003 13:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PEE-0005rw-1X for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:39:44 -0400 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16691 for ; Fri, 19 Sep 2003 13:39:18 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JHbGj06500; Fri, 19 Sep 2003 12:37:17 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 10:37:17 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04B429@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" , "'Henning Schulzrinne'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 10:37:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37ED4.A9E72E14" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37ED4.A9E72E14 Content-Type: text/plain I really don't think our positions are that different. I think a way forward would be to alter the offending statement that dial string are "not allowed" (because it is essentially contradicted in 2806bis when it explains how to do phone-contextes). Instead of saying that dial string are not allowed, we should explicitly describe that dial string can be implemented by defining a phone-context for that purpose (i.e., for a specific dial plan). That should realign Brian's view with Paul's and mine's that dial string are implementable today with 2806-bis. On the specific issue of * and #, I had never heard either about the E/F substitution (in fact, I tought it was an ISUP thing). Regardless, I don't have any problem with adding * and # (explicitly or with E/F substitution), as long as it is done with the phone-context mechanism for a dialing plan. If we can agree to that, I guess we'll have to move this to IPTEL for 2806-bis. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, September 19, 2003 06:18 > To: 'Rohan Mahy' > Cc: Audet, Francois [SC100:4K02:EXCH]; 'Paul Kyzivat'; 'Bob > Penfield'; 'sip@ietf.org' > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > I've never seen E/F substitution for */#, and I've never seen > any sip device that did it, but it's a possible way forward. > > I do think that some RFC would have to change the wording of > 2806bis to allow dial strings. The authors seemed to > explicitly declare them out of scope of the document. > Generally, we don't usually claim "that which is not > specifically disallowed is legal" as a way around "out of > scope" wording in our documents. > > I remain unhappy that dial strings, untranslated phone > numbers and translated phone numbers are indistinguishable. > They are different, they are handled differently, and they > should be distinguishable. I don't understand why some people > are so adamant that they should all be represented in EXACTLY > the same way (tel uri or sip uri with or without user=phone). > They are not the same things, and they should have > distinctive representations. > > Brian > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Thursday, September 18, 2003 9:17 PM > > To: Rosen, Brian > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > > > On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: > > > Well this goes to the issue Paul and I have disagreed on. > > > > > > I think the wording of the tel uri RFC is quite clear > that you can't > > > pass a dial string in one. You certainly can't pass one with > > > star and pound. Therefore, I claim, there is no way to pass > > > a dial string > > > > Brian, What part of a dial string doesn't fit into: > 1*phonedigit ? > > > > phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / > > "8" / "9" / > > "A" / "B" / "C" / "D" / "E" / "F" > > > > E corresponds to * and F corresponds to # > > > > thanks, > > -rohan > > > > > > > , unless you put it in a username on a SIP uri, > > > and denote that it is a dial string, for which a phone > number is a > > > proper subset for most dial plans, by specifying user=phone. > > > > > > Paul disagrees. He thinks he can send a dial string in a > tel uri. > > > Without some kind of resolution of that issue, we have a problem. > > > > > > Brian > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortelnetworks.com] > > > Sent: Monday, September 15, 2003 12:10 PM > > > To: 'Paul Kyzivat' > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Monday, September 15, 2003 06:58 > > >> To: Audet, Francois [SC100:4K02:EXCH] > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > [ stuff deleted as it looks like we are in agreement ] > > >> I'm not sure about the "most" part. Some do, some don't. > As spec is > > >> currently written, the equivalence between tel and > > sip/user=phone is > > >> only one way. (IF the userpart comes from a tel, then > there SHOULD > > >> be a user=phone, but the presence of user=phone does not > imply the > > >> userpart > > >> conforms to tel.) > > >> > > >> I personally am happy with the more strict > interpretation. But I am > > >> trying to hold out an olive branch in order to reach a level of > > >> agreement. > > > OK. It seems that we are in agreement. > > > My suggestion is to ask the question to the group of is anybody > > > objects to make it explicit that user=phones means that the > > sip URI is > > > derived > > > from a tel URI? > > > If the answer is no, then I think we can probably finally put this > > > issue > > > to rest. Otherwise, we need to rework the whole thing... > > > So... Does anybody strongly object to explicitly making the > > user=phone > > > atttribute mean that the SIP URI was derived from a tel URI? > > >>> Applying the rules of RFC3261/19.1.6 instead, we'd get: > > >>> > > >>> > > >>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > > >>> > > >>> Which (like the tel URI) specifically identifies the > > >> dialing plan and > > >>> does not require one DNS entry per dialling plan. > > >> > > >> > > >> I agree that this is also a fine usage. > > >> > > >> But what is benefit of this over using the tel format and then > > >> passing the request to sip:foo.bar? > > > The tel URI format assumes that the proxy knows which proxy > > is aware > > > of the > > > phone context > > > and tel URIs (it could be itself, or it could know which > > proxy to route > > > sessions to). > > > The sip URI format lets you route it to a specific proxy > > that is aware > > > of > > > the phone > > > context, potentially with "generic" SIP proxies in between > > that have > > > no idea > > > how to route > > > based on phone contextes (or even tel URIs). T > > > > > > > > > They both have merits. > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > ------_=_NextPart_001_01C37ED4.A9E72E14 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

I really don't think our positions are that different.

I think a way forward would be to alter the offending statement
that dial string are "not allowed" (because it is essentially
contradicted in 2806bis when it explains how to do phone-contextes).

Instead of saying that dial string are not allowed, we should
explicitly describe that dial string can be implemented
by defining a phone-context for that purpose (i.e., for a
specific dial plan). That should realign Brian's view with Paul's and mine's
that dial string are implementable today with 2806-bis.

On the specific issue of * and #, I had never heard either about the E/F
substitution (in fact, I tought it was an ISUP thing). Regardless,
I don't have any problem with adding * and # (explicitly or with E/F
substitution), as long as it is done with the phone-context
mechanism for a dialing plan.

If we can agree to that, I guess we'll have to move this to IPTEL
for 2806-bis.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, September 19, 2003 06:18
> To: 'Rohan Mahy'
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Paul Kyzivat'; 'Bob
> Penfield'; 'sip@ietf.org'
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
>
>
> I've never seen E/F substitution for */#, and I've never seen
> any sip device that did it, but it's a possible way forward.
>
> I do think that some RFC would have to change the wording of
> 2806bis to allow dial strings.  The authors seemed to
> explicitly declare them out of scope of the document. 
> Generally, we don't usually claim "that which is not
> specifically disallowed is legal" as a way around "out of
> scope" wording in our documents.
>
> I remain unhappy that dial strings, untranslated phone
> numbers and translated phone numbers are indistinguishable. 
> They are different, they are handled differently, and they
> should be distinguishable. I don't understand why some people
> are so adamant that they should all be represented in EXACTLY
> the same way (tel uri or sip uri with or without user=phone).
>  They are not the same things, and they should have
> distinctive representations.
>
> Brian
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Thursday, September 18, 2003 9:17 PM
> > To: Rosen, Brian
> > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org'
> > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >
> >
> > On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote:
> > > Well this goes to the issue Paul and I have disagreed on.
> > >
> > > I think the wording of the tel uri RFC is quite clear
> that you can't
> > > pass a dial string in one.  You certainly can't pass one with
> > > star and pound.   Therefore, I claim, there is no way to pass
> > > a dial string
> >
> > Brian,  What part of a dial string doesn't fit into:
> 1*phonedigit   ?
> >
> > phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
> > "8" / "9" /
> >               "A" / "B" / "C" / "D" / "E" / "F"
> >
> > E corresponds to *  and F corresponds to #
> >
> > thanks,
> > -rohan
> >
> >
> > > , unless you put it in a username on a SIP uri,
> > > and denote that it is a dial string, for which a phone
> number is a
> > > proper subset for most dial plans, by specifying user=phone.
> > >
> > > Paul disagrees.  He thinks he can send a dial string in a
> tel uri.
> > > Without some kind of resolution of that issue, we have a problem.
> > >
> > > Brian
> > > -----Original Message-----
> > > From: Francois Audet [mailto:audet@nortelnetworks.com]
> > > Sent: Monday, September 15, 2003 12:10 PM
> > > To: 'Paul Kyzivat'
> > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org'
> > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > >
> > >
> > >> -----Original Message-----
> > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > >> Sent: Monday, September 15, 2003 06:58
> > >> To: Audet, Francois [SC100:4K02:EXCH]
> > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org'
> > >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> > > [ stuff deleted as it looks like we are in agreement ]
> > >> I'm not sure about the "most" part. Some do, some don't.
> As spec is
> > >> currently written, the equivalence between tel and
> > sip/user=phone is
> > >> only one way. (IF the userpart comes from a tel, then
> there SHOULD
> > >> be a user=phone, but the presence of user=phone does not
> imply the
> > >> userpart
> > >> conforms to tel.)
> > >>
> > >> I personally am happy with the more strict
> interpretation. But I am
> > >> trying to hold out an olive branch in order to reach a level of
> > >> agreement.
> > > OK. It seems that we are in agreement.
> > > My suggestion is to ask the question to the group of is anybody
> > > objects to make it explicit that user=phones means that the
> > sip URI is
> > > derived
> > > from a tel URI?
> > > If the answer is no, then I think we can probably finally put this
> > > issue
> > > to rest. Otherwise, we need to rework the whole thing...
> > > So... Does anybody strongly object to explicitly making the
> > user=phone
> > > atttribute mean that the SIP URI was derived from a tel URI?
> > >>> Applying the rules of RFC3261/19.1.6 instead, we'd get:
> > >>>
> > >>>
> > >>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone
> > >>>
> > >>> Which (like the tel URI) specifically identifies the
> > >> dialing plan and
> > >>> does not require one DNS entry per dialling plan.
> > >>
> > >>
> > >> I agree that this is also a fine usage.
> > >>
> > >> But what is benefit of this over using the tel format and then
> > >> passing the request to sip:foo.bar?
> > > The tel URI format assumes that the proxy knows which proxy
> > is aware
> > > of the
> > > phone context
> > > and tel URIs (it could be itself, or it could know which
> > proxy to route
> > > sessions to).
> > > The sip URI format lets you route it to a specific proxy
> > that is aware
> > > of
> > > the phone
> > > context, potentially with "generic" SIP proxies in between
> > that have
> > > no idea
> > > how to route
> > > based on phone contextes (or even tel URIs). T
> > >
> > >
> > > They both have merits.
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sipping@ietf.org for new developments on the application of sip
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current
> sip Use sipping@ietf.org for new developments on the
> application of sip
>

------_=_NextPart_001_01C37ED4.A9E72E14-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:54:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05052 for ; Sat, 20 Sep 2003 09:54:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nj4-00009Q-IN for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:03:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG3IKj000565 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:03:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Niz-000070-5j; Fri, 19 Sep 2003 12:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nib-0008Oo-75 for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04320 for ; Fri, 19 Sep 2003 12:02:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0IzY-0004ph-00 for sip@ietf.org; Fri, 19 Sep 2003 07:00:00 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1A0Im0-0001Tl-00 for sip@ietf.org; Fri, 19 Sep 2003 06:46:00 -0400 Received: from Natarajucl1127 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HLG00GM3J5BDI@mta0.huawei.com> for sip@ietf.org; Fri, 19 Sep 2003 18:44:01 +0800 (CST) Date: Fri, 19 Sep 2003 16:17:55 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Responses path in SIP. To: Noel Crespi , sip@ietf.org Cc: "'chadli'" Message-id: <001601c37e9b$7cdaa380$3d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <005801c37dbf$3a9f9bb0$f0649f9d@intevry.fr> Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE ----- Original Message ----- =46rom: "Noel Crespi" To: Cc: "'chadli'" Sent: Thursday, September 18, 2003 2:01 PM Subject: [Sip] Responses path in SIP. Hi, In the RFC3261 there seems to be a contradiction about the path taken= by the responses in a SIP transaction. It is in clear if the responses M= UST or SHOULD follow the path defined by the Via header field. Different sections in RFC3261 mandate that responses MUST be sent to = the location indicated in the topmost Via header field value, eg: - In section 8.1.1.7: "The Via header field indicates the transport u= sed for the transaction and identifies the location where the response is= to be sent " - In section 16.7: "The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost = Via header field value" - In section 16.11: "If that address matches the proxy,(it equals a value this proxy has inserted into previous requests)the proxy MUST remove that header field value from the response and forward the resu= lt to the location indicated in the next Via header field value" [Nataraj] this section is dealing about Route header not Via .......= ...... However section 20.42 states that: "The Via header field indicates th= e path taken by the request so far and indicates the path that should b= e followed in routing responses" So, MUST or SHOULD responses in a SIP transaction follow the path defined by the Via header field? Regards. Y.Chadli / N.Crespi INT/GET - Institut National des T=E9l=E9communications _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 09:54:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05106 for ; Sat, 20 Sep 2003 09:54:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ngk-0007kx-AT for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:00:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG0sSU029811 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 12:00:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ng7-0007WN-Tm; Fri, 19 Sep 2003 12:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nen-0007Af-UC for sip@optimus.ietf.org; Fri, 19 Sep 2003 11:59:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01923 for ; Fri, 19 Sep 2003 11:58:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0NB2-0001jC-00 for sip@ietf.org; Fri, 19 Sep 2003 11:28:08 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A0NAh-0001NB-00 for sip@ietf.org; Fri, 19 Sep 2003 11:27:47 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JFQpj08989; Fri, 19 Sep 2003 10:26:51 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 08:26:51 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04B07F@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" , "'Rosen, Brian'" Cc: "'Bob Penfield'" , "'Paul Kyzivat'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 08:26:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EC2.71CFC886" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EC2.71CFC886 Content-Type: text/plain I agree. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, September 18, 2003 18:20 > To: Rosen, Brian > Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield'; 'Paul > Kyzivat'; 'sip@ietf.org' > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > On Monday, September 15, 2003, at 11:40 AM, Rosen, Brian wrote: > > > I'm sorry, but when the draft says: > > "Dial strings are beyond the scope of this document." > > to me, means dial string is not legal in a tel uri. > > To me this statement simply means that the *internal > semantics* of dial > strings are not defined in that document. It does not say "you MUST > not put a dial string into the phone-number portion of a local-number" > > Perhaps it should say that no special considerations for dial strings > are included in the document. Specifically wait and pause > are missing, > but that is not what you are describing. > > thanks, > -rohan ------_=_NextPart_001_01C37EC2.71CFC886 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

I agree.

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Thursday, September 18, 2003 18:20
> To: Rosen, Brian
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield'; 'Paul
> Kyzivat'; 'sip@ietf.org'
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>
>
>
> On Monday, September 15, 2003, at 11:40 AM, Rosen, Brian wrote:
>
> > I'm sorry, but when the draft says:
> > "Dial strings are beyond the scope of this document."
> > to me, means dial string is not legal in a tel uri.
>
> To me this statement simply means that the *internal
> semantics* of dial
> strings are not defined in that document.  It does not say  "you MUST
> not put a dial string into the phone-number portion of a local-number"
>
> Perhaps it should say that no special considerations for dial strings
> are included in the document.  Specifically wait and pause
> are missing,
> but that is not what you are describing.
>
> thanks,
> -rohan

------_=_NextPart_001_01C37EC2.71CFC886-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 10:22:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07835 for ; Sat, 20 Sep 2003 10:22:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iY0-0006qe-C1 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 10:17:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KEHGrw026264 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 10:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iXl-0006kl-Lw; Sat, 20 Sep 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NlP-00016A-S5 for sip@optimus.ietf.org; Fri, 19 Sep 2003 12:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06219 for ; Fri, 19 Sep 2003 12:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0E5W-0005DK-00 for sip@ietf.org; Fri, 19 Sep 2003 01:45:50 -0400 Received: from [203.199.83.32] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1A0Dxs-0003nG-00 for sip@ietf.org; Fri, 19 Sep 2003 01:37:56 -0400 Received: (qmail 9492 invoked by uid 510); 19 Sep 2003 05:36:17 -0000 Date: 19 Sep 2003 05:36:17 -0000 Message-ID: <20030919053617.9491.qmail@webmail32.rediffmail.com> Received: from unknown (202.153.32.135) by rediffmail.com via HTTP; 19 sep 2003 05:36:17 -0000 MIME-Version: 1.0 From: "Karunakara Rao" Reply-To: "Karunakara Rao" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] forking proxies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi All, I am new to this group. a doubt regarding forking proxies, why would a proxy do if forked an INVITE request, it got back some reliable provisional responses that established some early dialogs at the UAC, and then one of the UAS's sends a final response 200 oK. If the other early dialogs try to send further reliable provisional responses this wont get through the proxy since a final response was already sent on the response context. Should the proxy behaviour not only forward immediately 200ok responses to INVITE, but also reliable responses ? What happened to other early dialogs? how about sending CANCEL request to them which has not received final 200 OK. how to close those dialogs any policy can be adopted. thanks Karunakar. ___________________________________________________ Art meets Anesthesia; Shefali Weds Dr. Raman. Rediff Matchmaker strikes another interesting match !! Visit http://matchmaker.rediff.com?1 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 10:42:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04331 for ; Sat, 20 Sep 2003 09:53:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P56-0004lS-54 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:30:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHU8Ol018297 for sip-archive@odin.ietf.org; Fri, 19 Sep 2003 13:30:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P51-0004kN-D2; Fri, 19 Sep 2003 13:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P4G-0004jE-F6 for sip@optimus.ietf.org; Fri, 19 Sep 2003 13:29:16 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16193 for ; Fri, 19 Sep 2003 13:29:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15163; Fri, 19 Sep 2003 13:23:39 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21135; Fri, 19 Sep 2003 13:23:40 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 13:23:40 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5ED2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: "'Francois Audet'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 13:23:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The sip entities know the difference and it matters. There is clearly a difference between a local number within a context and a dial string, which is also within a context. 7247426826 is a legal number within my local context, but I can't dial that. I can dial 6826, 300-6826, 9-724-742-6826 or 9-1-724-742-6826 to get it. On the other hand 9-724-742-6826 is not a number in my local context, it's a dial string. 300-6826 is both a dial string and a legal number. Your post has more examples of where there is confusion between dial strings and phone numbers. A UA that is not equipped to translate a dial string to a phone number sends a dial string, in a context if you would like. A proxy that translated the dial string to a phone number knows that's what it is doing. A proxy that routes phone numbers may or may not know how to translate a dial string to a phone number, those are two separate functions. We need to mark the URI with what it represents. I have never argued for adding p/w to a tel uri. I think it's usefull to have in a dial string. But then I'd never put a dial string in a tel uri. Tel URIs carry phone numbers. It says so :) Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Friday, September 19, 2003 12:07 PM > To: Rosen, Brian > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > Brian, > > I don't think even humans can distinguish between dial strings and > phone numbers without the appropriate context. For example, the > following is both a real dial string at Cisco for intersite dialing, > and a local phone number in Stockholm (and probably many other places > as well). > > 85268570 > > likewise, I worked at NASA in 1993 who had a 7-digit dialplan. Most > dial strings there where indistinguishable from local 7-digit numbers > in use North America (this was before 10-digit dialing came > to Atlanta, > New York, etc..). > > AFAIK, most users do not understand the distinction you are > making. Is > *69 a phone number or a dial string? How about 411 in North > America? > What about "0" in North America and "9" in many other parts of the > world? Was that a phone number or a dial string? I have concluded > that as long as the set of digits is properly labeled with > the correct > context it really doesn't matter, and that this type of distinction > between dial strings and phone numbers is artificial and academic. > > If you would like to use some additional private conventions inside > your domains that is fine, but I don't think we are going to get > consensus on the difference between a phone number and a dial > string in > this forum. > > Finally, I think the intention of 2806bis is to ignore pauses > and waits > of various tones, and I think we agree that those don't need to go > inside a tel URI. > > thanks, > -rohan > > > On Friday, September 19, 2003, at 06:17 AM, Rosen, Brian wrote: > > > I've never seen E/F substitution for */#, and I've never seen any > > sip device that did it, but it's a possible way forward. > > > > I do think that some RFC would have to change the wording of > > 2806bis to allow dial strings. The authors seemed to explicitly > > declare them out of scope of the document. Generally, we don't > > usually claim "that which is not specifically disallowed is legal" > > as a way around "out of scope" wording in our documents. > > > > I remain unhappy that dial strings, untranslated phone numbers > > and translated phone numbers are indistinguishable. They are > > different, > > they are handled differently, and they should be distinguishable. > > I don't understand why some people are so adamant that they > should all > > be represented in EXACTLY the same way (tel uri or sip uri with > > or without user=phone). They are not the same things, and they > > should have distinctive representations. > > > > Brian > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Thursday, September 18, 2003 9:17 PM > >> To: Rosen, Brian > >> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; > 'sip@ietf.org' > >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > >> > >> > >> On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: > >>> Well this goes to the issue Paul and I have disagreed on. > >>> > >>> I think the wording of the tel uri RFC is quite clear that you > >>> can't pass a dial string in one. You certainly can't > pass one with > >>> star and pound. Therefore, I claim, there is no way to pass > >>> a dial string > >> > >> Brian, What part of a dial string doesn't fit into: > 1*phonedigit ? > >> > >> phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / > >> "8" / "9" / > >> "A" / "B" / "C" / "D" / "E" / "F" > >> > >> E corresponds to * and F corresponds to # > >> > >> thanks, > >> -rohan > >> > >> > >>> , unless you put it in a username on a SIP uri, > >>> and denote that it is a dial string, for which a phone number is > >>> a proper subset for most dial plans, by specifying user=phone. > >>> > >>> Paul disagrees. He thinks he can send a dial string in a tel uri. > >>> Without some kind of resolution of that issue, we have a problem. > >>> > >>> Brian > >>> -----Original Message----- > >>> From: Francois Audet [mailto:audet@nortelnetworks.com] > >>> Sent: Monday, September 15, 2003 12:10 PM > >>> To: 'Paul Kyzivat' > >>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > >>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > >>> > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Monday, September 15, 2003 06:58 > >>>> To: Audet, Francois [SC100:4K02:EXCH] > >>>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > >>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > >>> [ stuff deleted as it looks like we are in agreement ] > >>>> I'm not sure about the "most" part. Some do, some don't. > As spec is > >>>> currently written, the equivalence between tel and > >> sip/user=phone is > >>>> only one way. (IF the userpart comes from a tel, then there > >>>> SHOULD be a > >>>> user=phone, but the presence of user=phone does not imply the > >>>> userpart > >>>> conforms to tel.) > >>>> > >>>> I personally am happy with the more strict > interpretation. But I am > >>>> trying to hold out an olive branch in order to reach a level > >>>> of agreement. > >>> OK. It seems that we are in agreement. > >>> My suggestion is to ask the question to the group of is anybody > >>> objects to make it explicit that user=phones means that the > >> sip URI is > >>> derived > >>> from a tel URI? > >>> If the answer is no, then I think we can probably finally put this > >>> issue > >>> to rest. Otherwise, we need to rework the whole thing... > >>> So... Does anybody strongly object to explicitly making the > >> user=phone > >>> atttribute mean that the SIP URI was derived from a tel URI? > >>>>> Applying the rules of RFC3261/19.1.6 instead, we'd get: > >>>>> > >>>>> > >>>>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone > >>>>> > >>>>> Which (like the tel URI) specifically identifies the > >>>> dialing plan and > >>>>> does not require one DNS entry per dialling plan. > >>>> > >>>> > >>>> I agree that this is also a fine usage. > >>>> > >>>> But what is benefit of this over using the tel format and > >>>> then passing > >>>> the request to sip:foo.bar? > >>> The tel URI format assumes that the proxy knows which proxy > >> is aware > >>> of the > >>> phone context > >>> and tel URIs (it could be itself, or it could know which > >> proxy to route > >>> sessions to). > >>> The sip URI format lets you route it to a specific proxy > >> that is aware > >>> of > >>> the phone > >>> context, potentially with "generic" SIP proxies in between > >> that have > >>> no idea > >>> how to route > >>> based on phone contextes (or even tel URIs). T > >>> > >>> > >>> They both have merits. > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:19:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10920 for ; Sat, 20 Sep 2003 11:19:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jW6-00039o-Bq for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:19:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFJMT8012072 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:19:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jVn-0002wW-3B; Sat, 20 Sep 2003 11:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ieI-0006f7-CQ for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:23:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23512 for ; Fri, 19 Sep 2003 18:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TNs-00027P-00 for sip@ietf.org; Fri, 19 Sep 2003 18:05:48 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A0TNh-00027M-00 for sip@ietf.org; Fri, 19 Sep 2003 18:05:37 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JM4Xk08704; Fri, 19 Sep 2003 15:04:33 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 15:04:34 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04BADD@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Stastny Richard'" , "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 15:04:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EFA.01750B7C" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EFA.01750B7C Content-Type: text/plain That's the point: you can only do that if you use a phone-context. The phone-context reflects the user's dialing plan (the user MAKING the phone call, not the destination). So you deploy a bunch of dumb phones (let's say numbering-plan unaware phones to be more accurate) in Chicago, and you make sure that they are all configured with "phone-context=chicago.proxy.com". Presumably IS would make sure that it is pre-configured somehow so that the user doesn't have to do it manually. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, September 19, 2003 15:04 > To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy > Cc: Paul Kyzivat; Bob Penfield; sip@ietf.org > Subject: AW: [Sip] SIPIT Interop problem with ;user=phone > > > I understand your example, but I thought we are talking > about dunb UA without having dialing plans built in. > > How do you tell your phone to send append in one case > santaclara.proxy.com and in the other case chicago.proxy.com > if you just dial 3756? > > Either you use an access code, but then you have > a dialing plan built in, or you sent it with the > access code to the default proxy and let it doing the work, > > or you use separate lines and swich between them. > > ------_=_NextPart_001_01C37EFA.01750B7C Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

That's the point: you can only do that if you use a phone-context.

The phone-context reflects the user's dialing plan (the user
MAKING the phone call, not the destination).

So you deploy a bunch of dumb phones (let's say numbering-plan unaware
phones to be more accurate) in Chicago, and you make sure that they
are all configured with "phone-context=chicago.proxy.com". Presumably
IS would make sure that it is pre-configured somehow so that the user
doesn't have to do it manually.

> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Friday, September 19, 2003 15:04
> To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy
> Cc: Paul Kyzivat; Bob Penfield; sip@ietf.org
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
>
>
> I understand your example, but I thought we are talking
> about dunb UA without having dialing plans built in.
> 
> How do you tell your phone to send append in one case
> santaclara.proxy.com and in the other case chicago.proxy.com
> if you just dial 3756?
> 
> Either you use an access code, but then you have
> a dialing plan built in, or you sent it with the
> access code to the default proxy and let it doing the work,
> 
> or you use separate lines and swich between them.
> 
>

------_=_NextPart_001_01C37EFA.01750B7C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11370 for ; Sat, 20 Sep 2003 11:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jYm-00049N-BL for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFM7ld015903 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:22:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jYh-00044R-Du; Sat, 20 Sep 2003 11:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ifi-0006f7-Is for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22130 for ; Fri, 19 Sep 2003 17:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SaE-0001cc-00 for sip@ietf.org; Fri, 19 Sep 2003 17:14:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0Sa4-0001cP-00 for sip@ietf.org; Fri, 19 Sep 2003 17:14:20 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2003 14:10:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8JLDdJu002097; Fri, 19 Sep 2003 14:13:41 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN89822; Fri, 19 Sep 2003 17:13:38 -0400 (EDT) Message-ID: <3F6B7182.6010403@cisco.com> Date: Fri, 19 Sep 2003 17:13:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Robert Sparks , Adam Roach , "'Rosen, Brian'" , sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think Rohan and I might be in violent agreement. The example he gives below (c) is an excellent reason why a proxy (or UAC) might want to translate a tel: url into a sip url. I would however argue that in general, and in the absence of some other motivation to the contrary, I would *start* with the tel: format, and at least put it into the To header. Then, either immediately within the UAC, or someplace further downstream in a proxy, this might get translated to a sip url, so that the routing can be more explicitly controlled, as in Rohan's example. I believe the strongest argument for bypassing the tel: format from the beginning is security - the need to use sips. Maybe we need tels: so we can have security without having to bind the semantics of the number to a particular domain. :-) Paul Rohan Mahy wrote: > > On Tuesday, September 16, 2003, at 07:01 AM, Robert Sparks wrote: > >> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote: >> >>> While I do not object to sending tel URIs to SIP proxies, I believe I >>> already articulated some reasons why you might want to use sip or sips >>> instead. >>> >>> 1) want to use SIPS >> >> >> Agreed! >> >>> 2) want to route the call to a specific domain that is not the domain >>> of your first hop proxy. >>> 3) want to invoke a loose router for services like transcoding or call >>> history logging that have different tel URI handling rules than you >>> want to use. >> >> >> Both 2 and 3 can be solved by pushing or preloading routes. > > > OK, I was being sloppy. Looking at several options. > > A. > INVITE tel:+14085264000 SIP/2.0 > Route: > > A is not so good, because you have no control over what transcoders.com > does with tel URLs (It might reject them, or send you a big bill). > > B. > > INVITE tel:+14085264000 SIP/2.0 > Route: , > > B would probably work, but seems much more cumbersome than C. In > addition, transcoders.com might forward all calls toward mci.com through > some other domain (att.com) which might just take the tel URL and > process it itself. > > C. > > INVITE sip:+14085264000@mci.com;user=phone SIP/2.0 > Route: > > C is explicit, it works, and it contains no extra info. > > thanks, > -rohan > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:31:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12671 for ; Sat, 20 Sep 2003 11:31:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jhd-00073S-PI for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:31:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFVH3w027105 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jhS-0006uH-OO; Sat, 20 Sep 2003 11:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ieC-0006f7-FB for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24728 for ; Fri, 19 Sep 2003 18:24:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Tfn-0002Ho-00 for sip@ietf.org; Fri, 19 Sep 2003 18:24:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1A0Tfc-0002He-00 for sip@ietf.org; Fri, 19 Sep 2003 18:24:08 -0400 Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Sat, 20 Sep 2003 00:28:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233859@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN++rUBCi714TI6RUyl2DHPyOkMvwAASVoC From: "Stastny Richard" To: "Francois Audet" , "Rosen, Brian" , "Rohan Mahy" Cc: "Paul Kyzivat" , "Bob Penfield" , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SSB0aGluayB3ZSBhcmUgdGFsa2luZyB0aGUgc2FtZSB0aGluZywgSSBhZ3JlZS4NCiANCkJ1dCwg SSBzdGlsbCBkbyBub3Qgc2VlIHdoeSB5b3UgbmVlZA0KIA0KMS4gO3VzZXI9cGhvbmUNCjIuIDtw aG9uZS1jb250ZXh0PWNoaWNhZ28ucHJveHkuY29tIHdpdGhpbiB0aGUgc2lwOiBVUkkNCiANClRo ZSBwaG9uZS1jb250ZXh0IGlzIG5lY2Vzc2FyeSBpbiB0aGUgdGVsOiBVUkkgYmVjYXVzZSB0aGVy ZSBpcyBubyBvdGhlciB3YXkNCnRvIGluZGljYXRlIGEgY29udGV4dCAoYmVzaWRlIG9mIHVzaW5n IGFjY2VzcyBjb2RlcyksDQpidXQgaW4gd2l0aCBzaXA6Mzc1NkBjaGljYWdvLnByb3h5LmNvbSBh bmQgc2lwOnNhbnRhY2xhcmEucHJveHkuY29tDQp5b3UgY291bGQgYWxzbyBwb2ludCB0byB0aGUg U0FNRSBwcm94eSwgc28gcGhvbmUtY29udGV4dD1jaGljYWdvLnByb3h5LmNvbQ0KaXMgcmVkdW5k YW50IChidXQgaXQgZG9lcyBub3QgaHVydCwgb24gdGhlIG90aGVyIHNpZGUgOy0pDQogDQpSaWNo YXJkDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogRnJhbmNv aXMgQXVkZXQgW21haWx0bzphdWRldEBub3J0ZWxuZXR3b3Jrcy5jb21dIA0KCUdlc2VuZGV0OiBT YSAyMC4wOS4yMDAzIDAwOjA0IA0KCUFuOiBTdGFzdG55IFJpY2hhcmQ7ICdSb3NlbiwgQnJpYW4n OyAnUm9oYW4gTWFoeScgDQoJQ2M6ICdQYXVsIEt5eml2YXQnOyAnQm9iIFBlbmZpZWxkJzsgJ3Np cEBpZXRmLm9yZycgDQoJQmV0cmVmZjogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3 aXRoIDt1c2VyPXBob25lDQoJDQoJDQoNCglUaGF0J3MgdGhlIHBvaW50OiB5b3UgY2FuIG9ubHkg ZG8gdGhhdCBpZiB5b3UgdXNlIGEgcGhvbmUtY29udGV4dC4gDQoNCglUaGUgcGhvbmUtY29udGV4 dCByZWZsZWN0cyB0aGUgdXNlcidzIGRpYWxpbmcgcGxhbiAodGhlIHVzZXIgDQoJTUFLSU5HIHRo ZSBwaG9uZSBjYWxsLCBub3QgdGhlIGRlc3RpbmF0aW9uKS4gDQoNCglTbyB5b3UgZGVwbG95IGEg YnVuY2ggb2YgZHVtYiBwaG9uZXMgKGxldCdzIHNheSBudW1iZXJpbmctcGxhbiB1bmF3YXJlIA0K CXBob25lcyB0byBiZSBtb3JlIGFjY3VyYXRlKSBpbiBDaGljYWdvLCBhbmQgeW91IG1ha2Ugc3Vy ZSB0aGF0IHRoZXkgDQoJYXJlIGFsbCBjb25maWd1cmVkIHdpdGggInBob25lLWNvbnRleHQ9Y2hp Y2Fnby5wcm94eS5jb20iLiBQcmVzdW1hYmx5IA0KCUlTIHdvdWxkIG1ha2Ugc3VyZSB0aGF0IGl0 IGlzIHByZS1jb25maWd1cmVkIHNvbWVob3cgc28gdGhhdCB0aGUgdXNlciANCglkb2Vzbid0IGhh dmUgdG8gZG8gaXQgbWFudWFsbHkuIA0KDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN Cgk+IEZyb206IFN0YXN0bnkgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5h dF0gDQoJPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxOSwgMjAwMyAxNTowNCANCgk+IFRvOiBB dWRldCwgRnJhbmNvaXMgW1NDMTAwOjRLMDI6RVhDSF07IFJvc2VuLCBCcmlhbjsgUm9oYW4gTWFo eSANCgk+IENjOiBQYXVsIEt5eml2YXQ7IEJvYiBQZW5maWVsZDsgc2lwQGlldGYub3JnIA0KCT4g U3ViamVjdDogQVc6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25l IA0KCT4gDQoJPiANCgk+IEkgdW5kZXJzdGFuZCB5b3VyIGV4YW1wbGUsIGJ1dCBJIHRob3VnaHQg d2UgYXJlIHRhbGtpbmcgDQoJPiBhYm91dCBkdW5iIFVBIHdpdGhvdXQgaGF2aW5nIGRpYWxpbmcg cGxhbnMgYnVpbHQgaW4uIA0KCT4gIA0KCT4gSG93IGRvIHlvdSB0ZWxsIHlvdXIgcGhvbmUgdG8g c2VuZCBhcHBlbmQgaW4gb25lIGNhc2UgDQoJPiBzYW50YWNsYXJhLnByb3h5LmNvbSBhbmQgaW4g dGhlIG90aGVyIGNhc2UgY2hpY2Fnby5wcm94eS5jb20gDQoJPiBpZiB5b3UganVzdCBkaWFsIDM3 NTY/IA0KCT4gIA0KCT4gRWl0aGVyIHlvdSB1c2UgYW4gYWNjZXNzIGNvZGUsIGJ1dCB0aGVuIHlv dSBoYXZlIA0KCT4gYSBkaWFsaW5nIHBsYW4gYnVpbHQgaW4sIG9yIHlvdSBzZW50IGl0IHdpdGgg dGhlIA0KCT4gYWNjZXNzIGNvZGUgdG8gdGhlIGRlZmF1bHQgcHJveHkgYW5kIGxldCBpdCBkb2lu ZyB0aGUgd29yaywgDQoJPiAgDQoJPiBvciB5b3UgdXNlIHNlcGFyYXRlIGxpbmVzIGFuZCBzd2lj aCBiZXR3ZWVuIHRoZW0uIA0KCT4gIA0KCT4gDQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:31:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12673 for ; Sat, 20 Sep 2003 11:31:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jhd-00073R-Ov for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:31:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFVHqr027106 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jhU-0006uZ-0S; Sat, 20 Sep 2003 11:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0idw-0006f7-CK for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23093 for ; Fri, 19 Sep 2003 17:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0TG6-00022u-00 for sip@ietf.org; Fri, 19 Sep 2003 17:57:46 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A0TFv-00022m-00 for sip@ietf.org; Fri, 19 Sep 2003 17:57:35 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JLuvj12069; Fri, 19 Sep 2003 16:56:57 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 14:56:58 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04BAB8@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'William Marshall'" , "'sip@ietf.org'" Cc: "'rsparks@dynamicsoft.com'" , "'hisham.khartabil@nokia.com'" , "'rohan@cisco.com'" , "'pkyzivat@cisco.com'" , "'adam@dynamicsoft.com'" , "'Brian.Rosen@marconi.com'" Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 14:56:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EF8.F18C5B44" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EF8.F18C5B44 Content-Type: text/plain > This is exactly the point that I was trying to make much > earlier in this thread. > > That if ";user=phone" means that the username came from a > tel: URL, it does NOT (repeat NOT) mean that anyone else in > the path can convert it back to a tel: URL and process it. > It will only be handled by a proxy responsible for the domain > named in the sip: URL. > > Past proposed wordings that the request would only be handled by > proxies that "understand the username part" still concern me, > because ";user=phone" (if the resolution here is that it > means exactly a tel: URL) could give anyone that > understanding. Routing still must be to the domain named in > the request-URI, whether > ";user=phone" is present or not. I'm fairly certain this > point has been agreed by all parties. Agreed. ------_=_NextPart_001_01C37EF8.F18C5B44 Content-Type: text/html RE: AW: [Sip] SIPIT Interop problem with ;user=phone

> This is exactly the point that I was trying to make much
> earlier in this thread.
>
> That if ";user=phone" means that the username came from a
> tel: URL, it does NOT (repeat NOT) mean that anyone else in
> the path can convert it back to a tel: URL and process it. 
> It will only be handled by a proxy responsible for the domain
> named in the sip: URL.
>
> Past proposed wordings that the request would only be handled by
> proxies that "understand the username part" still concern me,
> because ";user=phone" (if the resolution here is that it
> means exactly a tel: URL) could give anyone that
> understanding.  Routing still must be to the domain named in
> the request-URI, whether
> ";user=phone" is present or not.  I'm fairly certain this
> point has been agreed by all parties.

Agreed.

------_=_NextPart_001_01C37EF8.F18C5B44-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:35:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13021 for ; Sat, 20 Sep 2003 11:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jlN-0007bC-FQ for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFZ9kC029085 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jlJ-0007YE-KL; Sat, 20 Sep 2003 11:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jIL-0000sX-Lr for sip@optimus.ietf.org; Sat, 20 Sep 2003 11:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25178 for ; Fri, 19 Sep 2003 18:43:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Tyq-0002UI-00 for sip@ietf.org; Fri, 19 Sep 2003 18:44:00 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A0Tyf-0002U8-00 for sip@ietf.org; Fri, 19 Sep 2003 18:43:49 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JMgij16634; Fri, 19 Sep 2003 17:42:45 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 15:42:44 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B0B3B75@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Stastny Richard'" , "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 15:42:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EFF.5749CFE2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EFF.5749CFE2 Content-Type: text/plain > I think we are talking the same thing, I agree. > > But, I still do not see why you need > > 1. ;user=phone > 2. ;phone-context=chicago.proxy.com within the sip: URI > > The phone-context is necessary in the tel: URI because there > is no other way to indicate a context (beside of using access > codes), but in with sip:3756@chicago.proxy.com and > sip:santaclara.proxy.com you could also point to the SAME > proxy, so phone-context=chicago.proxy.com is redundant (but > it does not hurt, on the other side ;-) You could put a single proxy (proxy.com) in the headquarter in Vienna. The dialing plans could all be stored on that proxy.] The local office in Chicago wouldn't not have any proxies who understand dialing plan. Chicago makes a call to Paris. User dials 6011-33-12-14-16-18. It's phone takes the dial digits (60113312141618) and, appends its phone-context for dial digits, constructs the URI and fires it off to the proxy in Vienna. The URI will be as follows: - tel:60113312141618;phone-context=chicago.proxy.com The only thing the phone needs to understand for this is that the it needs to include the phone-context. I'm assuming a phone that does not do any digit parsing (i.e., the "dumb" phone). The Vienna proxy will figure out how to parse the digits based on the phone-contex=chicago.proxy.com (and thus figure out that 6011 means dial outside the PBX to an international number. The equivalent SIP URI would be - sip:60113312141618;phone-context=chicago.proxy.com@proxy.com;user=phone The domain name doesn't have to match the phone-context. For example, the phone service could be handled by isp.net, in which case the URI could be: - sip:60113312141618;phone-context=chicago.proxy.com@isp.net;user=phone In other words, the phone should be configurable with both the domain name (in this example isp.net) and the phone-context (in this case chicago.proxy.com). In a lot of simple cases, it is very likely that a small enterprise could just use the same value for the phone-context (mysmallbusiness.com) as the proxy (mysmallbusiness.com). ------_=_NextPart_001_01C37EFF.5749CFE2 Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

> I think we are talking the same thing, I agree.
> 
> But, I still do not see why you need
> 
> 1. ;user=phone
> 2. ;phone-context=chicago.proxy.com within the sip: URI
> 
> The phone-context is necessary in the tel: URI because there
> is no other way to indicate a context (beside of using access
> codes), but in with sip:3756@chicago.proxy.com and
> sip:santaclara.proxy.com you could also point to the SAME
> proxy, so phone-context=chicago.proxy.com is redundant (but
> it does not hurt, on the other side ;-)

You could put a single proxy (proxy.com) in the headquarter in
Vienna. The dialing plans could all be stored on that proxy.]

The local office in Chicago wouldn't not have any proxies who
understand dialing plan.

Chicago makes a call to Paris. User dials 6011-33-12-14-16-18.

It's phone takes the dial digits (60113312141618) and, appends
its phone-context for dial digits, constructs the URI and fires
it off to the proxy in Vienna. The URI will be as follows:
- tel:60113312141618;phone-context=chicago.proxy.com

The only thing the phone needs to understand for this is that
the it needs to include the phone-context. I'm assuming a phone
that does not do any digit parsing (i.e., the "dumb" phone).

The Vienna proxy will figure out how to parse the digits based
on the phone-contex=chicago.proxy.com (and thus figure out that
6011 means dial outside the PBX to an international number.


The equivalent SIP URI would be
- sip:60113312141618;phone-context=chicago.proxy.com@proxy.com;user=phone

The domain name doesn't have to match the phone-context. For example,
the phone service could be handled by isp.net, in which case the URI
could be:
- sip:60113312141618;phone-context=chicago.proxy.com@isp.net;user=phone

In other words, the phone should be configurable with both the domain name
(in this example isp.net) and the phone-context (in this case chicago.proxy.com).

In a lot of simple cases, it is very likely that a small enterprise
could just use the same value for the phone-context (mysmallbusiness.com)
as the proxy (mysmallbusiness.com).

------_=_NextPart_001_01C37EFF.5749CFE2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:38:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13499 for ; Sat, 20 Sep 2003 11:38:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jod-0000Ky-KX for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:38:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFcV9n001226 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:38:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0joO-00008l-VG; Sat, 20 Sep 2003 11:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ifh-0006f7-J8 for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:25:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22175 for ; Fri, 19 Sep 2003 17:15:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SbU-0001dS-00 for sip@ietf.org; Fri, 19 Sep 2003 17:15:48 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SbJ-0001dB-00 for sip@ietf.org; Fri, 19 Sep 2003 17:15:37 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Sep 2003 14:15:41 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8JLEiJs002857; Fri, 19 Sep 2003 14:14:44 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN89959; Fri, 19 Sep 2003 17:14:42 -0400 (EDT) Message-ID: <3F6B71C2.4010500@cisco.com> Date: Fri, 19 Sep 2003 17:14:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org, rsparks@dynamicsoft.com, hisham.khartabil@nokia.com, rohan@cisco.com, adam@dynamicsoft.com, Brian.Rosen@marconi.com Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <200309181513.LAA49295@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Amen!!! Paul William Marshall wrote: > > That if ";user=phone" means that the username came from a tel: URL, > it does NOT (repeat NOT) mean that anyone else in the path can > convert it back to a tel: URL and process it. It will only be > handled by a proxy responsible for the domain named in the sip: URL. > > Past proposed wordings that the request would only be handled by > proxies that "understand the username part" still concern me, > because ";user=phone" (if the resolution here is that it means > exactly a tel: URL) could give anyone that understanding. Routing > still must be to the domain named in the request-URI, whether > ";user=phone" is present or not. I'm fairly certain this point > has been agreed by all parties. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 11:53:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14225 for ; Sat, 20 Sep 2003 11:53:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2r-0002Ih-3u for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:53:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFrCqr008780 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2h-0002Dw-5k; Sat, 20 Sep 2003 11:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2F-0002At-VC for sip@optimus.ietf.org; Sat, 20 Sep 2003 11:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21685 for ; Fri, 19 Sep 2003 16:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SFT-0001Ps-00 for sip@ietf.org; Fri, 19 Sep 2003 16:53:03 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1A0SFI-0001OA-00 for sip@ietf.org; Fri, 19 Sep 2003 16:52:53 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h8JKojv6000480; Fri, 19 Sep 2003 16:50:53 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 15:50:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86476@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Francois Audet'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 15:50:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: > I remain unhappy that dial strings, untranslated phone numbers > and translated phone numbers are indistinguishable. Perhaps we should require them to have some method of distinguishing them. Maybe... oh, I don't know... including a "phone-context=something" as part of the dial string. Maybe we could even include "+" as the first character as a shorthand way to indicate that the digits are already translated to be fully internationalized. Which sounds to me like status quo for what's actually written down. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 12:13:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14811 for ; Sat, 20 Sep 2003 12:13:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kMJ-00048t-Ik for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGDJWM015798 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kM4-00042V-G8; Sat, 20 Sep 2003 12:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2Q-0002Ar-WD for sip@optimus.ietf.org; Sat, 20 Sep 2003 11:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21747 for ; Fri, 19 Sep 2003 16:56:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SIv-0001RB-00 for sip@ietf.org; Fri, 19 Sep 2003 16:56:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A0SIl-0001Qu-00 for sip@ietf.org; Fri, 19 Sep 2003 16:56:27 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2003 13:52:49 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8JKtXHm011671; Fri, 19 Sep 2003 13:55:34 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACN88087; Fri, 19 Sep 2003 16:55:33 -0400 (EDT) Message-ID: <3F6B6D45.9030507@cisco.com> Date: Fri, 19 Sep 2003 16:55:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Rohan Mahy'" , "'Francois Audet'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <313680C9A886D511A06000204840E1CF070B5ED2@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian, I am going to make here essentially the same point that Francois made in response to another of your messages. See below. Paul Rosen, Brian wrote: > The sip entities know the difference and it matters. > There is clearly a difference between a local number within > a context and a dial string, which is also within a context. So, what you are saying is that there are two contexts here, one for local numbers and one for dial strings. I think we are all in agreement on that. We are only disagreeing on how to identify those. > 7247426826 is a legal number within my local context, but > I can't dial that. I can dial 6826, 300-6826, 9-724-742-6826 > or 9-1-724-742-6826 to get it. On the other hand 9-724-742-6826 > is not a number in my local context, it's a dial string. > 300-6826 is both a dial string and a legal number. > Your post has more examples of where there is confusion > between dial strings and phone numbers. Using Francois's example names for contexts and your phone numbers above, I would represent all of those as: tel:7247426826;phone-context=global.marconi.com tel:6826;phone-context=dial-digit-us.marconi.com tel:3006826;phone-context=dial-digit-us.marconi.com tel:97247426826;phone-context=dial-digit-us.marconi.com tel:9-1-724-742-6826;phone-context=dial-digit-us.marconi.com tel:300-6826;phone-context=global.marconi.com sip:7247426826;phone-context=global.marconi.com@marconi.com;user=phone sip:6826;phone-context=dial-digit-us.marconi.com@marconi.com;user=phone sip:3006826;phone-context=dial-digit-us.marconi.com@marconi.com;user=phone sip:97247426826;phone-context=dial-digit-us.marconi.com@marconi.com;user=phone sip:9-1-724-742-6826;phone-context=dial-digit-us.marconi.com@marconi.com;user=phone sip:300-6826;phone-context=global.marconi.com@marconi.com;user=phone I *think* you want to use the same context for both dial strings and local numbers, and use user=foo to distinguish between them - perhaps something like sip:7247426826;phone-context=global.marconi.com@marconi.com;user=phone sip:6826;phone-context=global.marconi.com@marconi.com;user=DIALED sip:3006826;phone-context=global.marconi.com@marconi.com;user=DIALED sip:97247426826;phone-context=global.marconi.com@marconi.com;user=DIALED sip:9-1-724-742-6826;phone-context=global.marconi.com@marconi.com;user=DIALED sip:300-6826;phone-context=global.marconi.com@marconi.com;user=phone A possible disadvantage of this is that you then can't use tel: for dial strings. The other disadvantage is that its using two nails where only one is needed. Do you have some fundamental problem with having different context names for dial strings and local numbers? > > A UA that is not equipped to translate a dial string > to a phone number sends a dial string, in a context if you > would like. A proxy that translated the dial string to > a phone number knows that's what it is doing. A proxy that > routes phone numbers may or may not know how to translate > a dial string to a phone number, those are two separate > functions. > > We need to mark the URI with what it represents. No disagreement with any of the above. In the examples above, that marking would occur by virtue of the proxy translating, from: tel:6826;phone-context=dial-digit-us.marconi.com to: tel:7247426826;phone-context=global.marconi.com Of course, it would be better if the proxy translated all the way to a global number if there is one. > I have never argued for adding p/w to a tel uri. I think > it's usefull to have in a dial string. My phone doesn't have either a "," or a "w" key. AFAIK, those are rarely if ever parts of real dial strings. They are meta information sometimes encoded for various purposes. But they don't seem relevant here. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 12:14:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14912 for ; Sat, 20 Sep 2003 12:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kNG-0004Sv-VF for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:14:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGEIBA017165 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:14:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kN2-0004Pk-W0; Sat, 20 Sep 2003 12:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k39-0002Ar-7T for sip@optimus.ietf.org; Sat, 20 Sep 2003 11:53:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20275 for ; Fri, 19 Sep 2003 16:03:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0RTT-0000ng-00 for sip@ietf.org; Fri, 19 Sep 2003 16:03:27 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1A0RTJ-0000n0-00 for sip@ietf.org; Fri, 19 Sep 2003 16:03:17 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20927; Fri, 19 Sep 2003 16:02:18 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA11852; Fri, 19 Sep 2003 16:02:20 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 16:02:19 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5ED5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Stastny Richard'" , Rohan Mahy Cc: Francois Audet , Paul Kyzivat , Bob Penfield , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 16:02:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard A user at a dumb phone always enters a dial string. No argument. However, at some point, either a UA translates a dial string to a phone number, or a downstream proxy does it. At that point it isn't a dial string, it's a phone number, and it might be in a context (it could be global). What I've mentioned is a case, which I think is pretty common, where the number is not represented the same way as a dial string and a phone number, and yet is in the same domain. Let's take a practical example. Suppose I have a domain with a reasonably smart proxy server and a mix of phones. Some phones have dialstring translation, some don't. The proxy server can translate dial strings to phone numbers, and it also can route phone numbers. Obviously it can do both (ie translate then route). Now, how does the proxy know if it needs to translate? That is, how does it know that a uri passed to it is a dial string vs a phone number? If I pass it a phone number and it decides to apply it's dialstring processing, that will fail. If I pass a=20 dial string and it just routes, that will fail. It has to know what it is given. In my example it was 7246826@pit.sip.marconi.com That's a phone number, and a dial string, but it's two different destinations. In my numbering plan, it's my phone. In my dialing plan it's an extension in another office. Brian Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, September 19, 2003 3:33 PM > To: Rosen, Brian; Rohan Mahy > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Brian, > =20 > If you pick up a phone and enter digits, it ALWAYS a dialing string > and you are ALWAYS in ONE and ONLY ONE dialing plan.. > =20 > You never enter a phone number directly, you always > dial (if you dial a local number, the mapping may be 1:1) > =20 > So if you enter a dial string in a SIP phone and iu sends > it with nnnn@default.com to your defaulr sip server, this server > then evaluates the dialing plan and translates it to a numbering = plan. > =20 > Btw, thats exactly how fwd, iptel sipphone, ... are implemeted. > =20 > Richard >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Gesendet: Fr 19.09.2003 19:37=20 > An: Stastny Richard; Rohan Mahy=20 > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org=20 > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > =09 > =09 >=20 > Richard > =09 > My phone number within my local domain is 742-6826. > I could change the convention and make it 724-742-6826 or > 1-724-742-6826 if you want. > =09 > My dial plan would send a call to a different phone if you > dialed any of those strings. > =09 > If you send an INVITE 7426826@pit.sip.marconi.com it will ring > my sipphone.=20 > =09 > If I dial 7426826, it won't ring my sip phone. I have to dial > 6826 or 9-742-6826 or even 300-6826. > =09 > Using your algorithm, I would assume 7426826 was a dial string, > and that would be wrong. > =09 > Brian > =09 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, September 19, 2003 1:24 PM > > To: Rosen, Brian; Rohan Mahy > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > See below > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Gesendet: Fr 19.09.2003 15:17 > > An: 'Rohan Mahy' > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; > > 'sip@ietf.org' > > Betreff: RE: [Sip] SIPIT Interop problem with=20 > ;user=3Dphone > > =20 > > =20 > > > > I've never seen E/F substitution for */#, and I've > > never seen any > > sip device that did it, but it's a possible way forward. > > =20 > > I do think that some RFC would have to change=20 > the wording of > > 2806bis to allow dial strings. The authors=20 > seemed to explicitly > > declare them out of scope of the document. =20 > Generally, we don't > > usually claim "that which is not specifically > > disallowed is legal" > > as a way around "out of scope" wording in our documents. > > =20 > > I remain unhappy that dial strings,=20 > untranslated phone numbers > > and translated phone numbers are indistinguishable.=20 > > They are different, > > they are handled differently, and they should be > > distinguishable. > > I don't understand why some people are so adamant that > > they should all > > be represented in EXACTLY the same way (tel uri=20 > or sip uri with > > or without user=3Dphone). They are not the same=20 > things, and they > > should have distinctive representations. > > > > Richard: A string of digits is a string of digits. > > > > The simplest way to distinguish is: > > > > 1. If you just see a string of digits, you have to assume its > > a dial string > > > > until you know better. > > > > 2. If you analysed the digits and found out its an E.164 > > number, normalise it > > > > to tel:+xxxx, or sip:+xxxx@foo.bar > > > > 3. If you analysed it and found out it is a local=20 > number, then either > > > > use tel:xxxx; phone-context=3Dfoo.bar or=20 > sip:xxx@foo.bar;user=3Dphone > > > > I do not understand the problem > > > > Richard > > > > =20 > > =20 > > Brian > > =20 > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Thursday, September 18, 2003 9:17 PM > > > To: Rosen, Brian > > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; > > 'sip@ietf.org' > > > Subject: Re: [Sip] SIPIT Interop problem with=20 > ;user=3Dphone > > > > > > > > > On Monday, September 15, 2003, at 10:23 AM, Rosen, > > Brian wrote: > > > > Well this goes to the issue Paul and I have=20 > disagreed on. > > > > > > > > I think the wording of the tel uri RFC is quite > > clear that you > > > > can't pass a dial string in one. You certainly > > can't pass one with > > > > star and pound. Therefore, I claim, there is no > > way to pass > > > > a dial string > > > > > > Brian, What part of a dial string doesn't fit into: > > 1*phonedigit ? > > > > > > phonedigit =3D "0" / "1" / "2" / "3" / "4" /=20 > "5" / "6" / "7" / > > > "8" / "9" / > > > "A" / "B" / "C" / "D" / "E" / "F" > > > > > > E corresponds to * and F corresponds to # > > > > > > thanks, > > > -rohan > > > > > > > > > > , unless you put it in a username on a SIP uri, > > > > and denote that it is a dial string, for which a > > phone number is > > > > a proper subset for most dial plans, by specifying > > user=3Dphone. > > > > > > > > Paul disagrees. He thinks he can send a dial > > string in a tel uri. > > > > Without some kind of resolution of that issue, we > > have a problem. > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Francois Audet=20 > [mailto:audet@nortelnetworks.com] > > > > Sent: Monday, September 15, 2003 12:10 PM > > > > To: 'Paul Kyzivat' > > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > > Subject: RE: [Sip] SIPIT Interop problem=20 > with ;user=3Dphone > > > > > > > > > > > >> -----Original Message----- > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >> Sent: Monday, September 15, 2003 06:58 > > > >> To: Audet, Francois [SC100:4K02:EXCH] > > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > >> Subject: Re: [Sip] SIPIT Interop problem=20 > with ;user=3Dphone > > > > [ stuff deleted as it looks like we are in=20 > agreement ] > > > >> I'm not sure about the "most" part. Some do, some > > don't. As spec is > > > >> currently written, the equivalence between tel and > > > sip/user=3Dphone is > > > >> only one way. (IF the userpart comes from=20 > a tel, then there > > > >> SHOULD be a > > > >> user=3Dphone, but the presence of user=3Dphone does > > not imply the > > > >> userpart > > > >> conforms to tel.) > > > >> > > > >> I personally am happy with the more strict > > interpretation. But I am > > > >> trying to hold out an olive branch in order to > > reach a level > > > >> of agreement. > > > > OK. It seems that we are in agreement. > > > > My suggestion is to ask the question to the group > > of is anybody > > > > objects to make it explicit that=20 > user=3Dphones means that the > > > sip URI is > > > > derived > > > > from a tel URI? > > > > If the answer is no, then I think we can probably > > finally put this > > > > issue > > > > to rest. Otherwise, we need to rework the=20 > whole thing... > > > > So... Does anybody strongly object to=20 > explicitly making the > > > user=3Dphone > > > > atttribute mean that the SIP URI was=20 > derived from a tel URI? > > > >>> Applying the rules of RFC3261/19.1.6=20 > instead, we'd get: > > > >>> > > > >>> > > > >>> > >=20 > sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone > > > >>> > > > >>> Which (like the tel URI) specifically=20 > identifies the > > > >> dialing plan and > > > >>> does not require one DNS entry per dialling plan. > > > >> > > > >> > > > >> I agree that this is also a fine usage. > > > >> > > > >> But what is benefit of this over using the=20 > tel format and > > > >> then passing > > > >> the request to sip:foo.bar? > > > > The tel URI format assumes that the proxy=20 > knows which proxy > > > is aware > > > > of the > > > > phone context > > > > and tel URIs (it could be itself, or it=20 > could know which > > > proxy to route > > > > sessions to). > > > > The sip URI format lets you route it to a=20 > specific proxy > > > that is aware > > > > of > > > > the phone > > > > context, potentially with "generic" SIP=20 > proxies in between > > > that have > > > > no idea > > > > how to route > > > > based on phone contextes (or even tel URIs). T > > > > > > > > > > > > They both have merits. > > > > > > > > _______________________________________________ > > > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the=20 > core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > =20 > > _______________________________________________ > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core=20 > SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > =20 > > > > > =09 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 12:21:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13020 for ; Sat, 20 Sep 2003 11:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jlN-0007aP-Ax for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFZ93R029087 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 11:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jlH-0007X4-K7; Sat, 20 Sep 2003 11:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ii8-0006f7-UU for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19835 for ; Fri, 19 Sep 2003 15:43:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0RAV-0000YE-00 for sip@ietf.org; Fri, 19 Sep 2003 15:43:51 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1A0RAK-0000XV-00 for sip@ietf.org; Fri, 19 Sep 2003 15:43:40 -0400 Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 21:33:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233856@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN+1bzxQ9SFVc28RROlLC62Z0tVaAADgKmI From: "Stastny Richard" To: "Rosen, Brian" , "Rohan Mahy" Cc: "Francois Audet" , "Paul Kyzivat" , "Bob Penfield" , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 QnJpYW4sDQogDQpJZiB5b3UgcGljayB1cCBhIHBob25lIGFuZCBlbnRlciBkaWdpdHMsIGl0IEFM V0FZUyBhIGRpYWxpbmcgc3RyaW5nDQphbmQgeW91IGFyZSBBTFdBWVMgaW4gT05FIGFuZCBPTkxZ IE9ORSBkaWFsaW5nIHBsYW4uLg0KIA0KWW91IG5ldmVyIGVudGVyIGEgcGhvbmUgbnVtYmVyIGRp cmVjdGx5LCB5b3UgYWx3YXlzDQpkaWFsIChpZiB5b3UgZGlhbCBhIGxvY2FsIG51bWJlciwgdGhl IG1hcHBpbmcgbWF5IGJlIDE6MSkNCiANClNvIGlmIHlvdSBlbnRlciBhIGRpYWwgc3RyaW5nIGlu IGEgU0lQIHBob25lIGFuZCBpdSBzZW5kcw0KaXQgd2l0aCBubm5uQGRlZmF1bHQuY29tIHRvIHlv dXIgZGVmYXVsciBzaXAgc2VydmVyLCB0aGlzIHNlcnZlcg0KdGhlbiBldmFsdWF0ZXMgdGhlIGRp YWxpbmcgcGxhbiBhbmQgdHJhbnNsYXRlcyBpdCB0byBhIG51bWJlcmluZyBwbGFuLg0KIA0KQnR3 LCB0aGF0cyBleGFjdGx5IGhvdyBmd2QsIGlwdGVsIHNpcHBob25lLCAuLi4gYXJlIGltcGxlbWV0 ZWQuDQogDQpSaWNoYXJkDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0K CVZvbjogUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbWFyY29uaS5jb21dIA0KCUdl c2VuZGV0OiBGciAxOS4wOS4yMDAzIDE5OjM3IA0KCUFuOiBTdGFzdG55IFJpY2hhcmQ7IFJvaGFu IE1haHkgDQoJQ2M6IEZyYW5jb2lzIEF1ZGV0OyBQYXVsIEt5eml2YXQ7IEJvYiBQZW5maWVsZDsg c2lwQGlldGYub3JnIA0KCUJldHJlZmY6IFJFOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0g d2l0aCA7dXNlcj1waG9uZQ0KCQ0KCQ0KDQoJUmljaGFyZA0KCQ0KCU15IHBob25lIG51bWJlciB3 aXRoaW4gbXkgbG9jYWwgZG9tYWluIGlzIDc0Mi02ODI2Lg0KCUkgY291bGQgY2hhbmdlIHRoZSBj b252ZW50aW9uIGFuZCBtYWtlIGl0IDcyNC03NDItNjgyNiBvcg0KCTEtNzI0LTc0Mi02ODI2IGlm IHlvdSB3YW50Lg0KCQ0KCU15IGRpYWwgcGxhbiB3b3VsZCBzZW5kIGEgY2FsbCB0byBhIGRpZmZl cmVudCBwaG9uZSBpZiB5b3UNCglkaWFsZWQgYW55IG9mIHRob3NlIHN0cmluZ3MuDQoJDQoJSWYg eW91IHNlbmQgYW4gSU5WSVRFIDc0MjY4MjZAcGl0LnNpcC5tYXJjb25pLmNvbSBpdCB3aWxsIHJp bmcNCglteSBzaXBwaG9uZS4gDQoJDQoJSWYgSSBkaWFsIDc0MjY4MjYsIGl0IHdvbid0IHJpbmcg bXkgc2lwIHBob25lLiAgSSBoYXZlIHRvIGRpYWwNCgk2ODI2IG9yIDktNzQyLTY4MjYgIG9yIGV2 ZW4gMzAwLTY4MjYuDQoJDQoJVXNpbmcgeW91ciBhbGdvcml0aG0sIEkgd291bGQgYXNzdW1lIDc0 MjY4MjYgd2FzIGEgZGlhbCBzdHJpbmcsDQoJYW5kIHRoYXQgd291bGQgYmUgd3JvbmcuDQoJDQoJ QnJpYW4NCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBTdGFzdG55 IFJpY2hhcmQgW21haWx0bzpSaWNoYXJkLlN0YXN0bnlAb2VmZWcuYXRdDQoJPiBTZW50OiBGcmlk YXksIFNlcHRlbWJlciAxOSwgMjAwMyAxOjI0IFBNDQoJPiBUbzogUm9zZW4sIEJyaWFuOyBSb2hh biBNYWh5DQoJPiBDYzogRnJhbmNvaXMgQXVkZXQ7IFBhdWwgS3l6aXZhdDsgQm9iIFBlbmZpZWxk OyBzaXBAaWV0Zi5vcmcNCgk+IFN1YmplY3Q6IEFXOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2Js ZW0gd2l0aCA7dXNlcj1waG9uZQ0KCT4NCgk+DQoJPiBTZWUgYmVsb3cNCgk+DQoJPiAgICAgICAt LS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQoJPiAgICAgICBWb246IFJvc2VuLCBC cmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmkuY29tXQ0KCT4gICAgICAgR2VzZW5kZXQ6 IEZyIDE5LjA5LjIwMDMgMTU6MTcNCgk+ICAgICAgIEFuOiAnUm9oYW4gTWFoeScNCgk+ICAgICAg IENjOiAnRnJhbmNvaXMgQXVkZXQnOyAnUGF1bCBLeXppdmF0JzsgJ0JvYiBQZW5maWVsZCc7DQoJ PiAnc2lwQGlldGYub3JnJw0KCT4gICAgICAgQmV0cmVmZjogUkU6IFtTaXBdIFNJUElUIEludGVy b3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgIA0KCT4gICAgICANCgk+DQoJPiAg ICAgICBJJ3ZlIG5ldmVyIHNlZW4gRS9GIHN1YnN0aXR1dGlvbiBmb3IgKi8jLCBhbmQgSSd2ZQ0K CT4gbmV2ZXIgc2VlbiBhbnkNCgk+ICAgICAgIHNpcCBkZXZpY2UgdGhhdCBkaWQgaXQsIGJ1dCBp dCdzIGEgcG9zc2libGUgd2F5IGZvcndhcmQuDQoJPiAgICAgIA0KCT4gICAgICAgSSBkbyB0aGlu ayB0aGF0IHNvbWUgUkZDIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHRoZSB3b3JkaW5nIG9mDQoJPiAg ICAgICAyODA2YmlzIHRvIGFsbG93IGRpYWwgc3RyaW5ncy4gIFRoZSBhdXRob3JzIHNlZW1lZCB0 byBleHBsaWNpdGx5DQoJPiAgICAgICBkZWNsYXJlIHRoZW0gb3V0IG9mIHNjb3BlIG9mIHRoZSBk b2N1bWVudC4gIEdlbmVyYWxseSwgd2UgZG9uJ3QNCgk+ICAgICAgIHVzdWFsbHkgY2xhaW0gInRo YXQgd2hpY2ggaXMgbm90IHNwZWNpZmljYWxseQ0KCT4gZGlzYWxsb3dlZCBpcyBsZWdhbCINCgk+ ICAgICAgIGFzIGEgd2F5IGFyb3VuZCAib3V0IG9mIHNjb3BlIiB3b3JkaW5nIGluIG91ciBkb2N1 bWVudHMuDQoJPiAgICAgIA0KCT4gICAgICAgSSByZW1haW4gdW5oYXBweSB0aGF0IGRpYWwgc3Ry aW5ncywgdW50cmFuc2xhdGVkIHBob25lIG51bWJlcnMNCgk+ICAgICAgIGFuZCB0cmFuc2xhdGVk IHBob25lIG51bWJlcnMgYXJlIGluZGlzdGluZ3Vpc2hhYmxlLiANCgk+IFRoZXkgYXJlIGRpZmZl cmVudCwNCgk+ICAgICAgIHRoZXkgYXJlIGhhbmRsZWQgZGlmZmVyZW50bHksIGFuZCB0aGV5IHNo b3VsZCBiZQ0KCT4gZGlzdGluZ3Vpc2hhYmxlLg0KCT4gICAgICAgSSBkb24ndCB1bmRlcnN0YW5k IHdoeSBzb21lIHBlb3BsZSBhcmUgc28gYWRhbWFudCB0aGF0DQoJPiB0aGV5IHNob3VsZCBhbGwN Cgk+ICAgICAgIGJlIHJlcHJlc2VudGVkIGluIEVYQUNUTFkgdGhlIHNhbWUgd2F5ICh0ZWwgdXJp IG9yIHNpcCB1cmkgd2l0aA0KCT4gICAgICAgb3Igd2l0aG91dCB1c2VyPXBob25lKS4gIFRoZXkg YXJlIG5vdCB0aGUgc2FtZSB0aGluZ3MsIGFuZCB0aGV5DQoJPiAgICAgICBzaG91bGQgaGF2ZSBk aXN0aW5jdGl2ZSByZXByZXNlbnRhdGlvbnMuDQoJPg0KCT4gUmljaGFyZDogQSBzdHJpbmcgb2Yg ZGlnaXRzIGlzIGEgc3RyaW5nIG9mIGRpZ2l0cy4NCgk+DQoJPiBUaGUgc2ltcGxlc3Qgd2F5IHRv IGRpc3Rpbmd1aXNoIGlzOg0KCT4NCgk+IDEuIElmIHlvdSBqdXN0IHNlZSBhIHN0cmluZyBvZiBk aWdpdHMsIHlvdSBoYXZlIHRvIGFzc3VtZSBpdHMNCgk+IGEgZGlhbCBzdHJpbmcNCgk+DQoJPiB1 bnRpbCB5b3Uga25vdyBiZXR0ZXIuDQoJPg0KCT4gMi4gSWYgeW91IGFuYWx5c2VkIHRoZSBkaWdp dHMgYW5kIGZvdW5kIG91dCBpdHMgYW4gRS4xNjQNCgk+IG51bWJlciwgbm9ybWFsaXNlIGl0DQoJ Pg0KCT4gdG8gdGVsOit4eHh4LCBvciBzaXA6K3h4eHhAZm9vLmJhcg0KCT4NCgk+IDMuIElmIHlv dSBhbmFseXNlZCBpdCBhbmQgZm91bmQgb3V0IGl0IGlzIGEgbG9jYWwgbnVtYmVyLCB0aGVuIGVp dGhlcg0KCT4NCgk+IHVzZSB0ZWw6eHh4eDsgcGhvbmUtY29udGV4dD1mb28uYmFyIG9yIHNpcDp4 eHhAZm9vLmJhcjt1c2VyPXBob25lDQoJPg0KCT4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHJv YmxlbQ0KCT4NCgk+IFJpY2hhcmQNCgk+DQoJPiAgICAgIA0KCT4gICAgICANCgk+ICAgICAgIEJy aWFuDQoJPiAgICAgIA0KCT4gICAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4g ICAgICAgPiBGcm9tOiBSb2hhbiBNYWh5IFttYWlsdG86cm9oYW5AY2lzY28uY29tXQ0KCT4gICAg ICAgPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE4LCAyMDAzIDk6MTcgUE0NCgk+ICAgICAg ID4gVG86IFJvc2VuLCBCcmlhbg0KCT4gICAgICAgPiBDYzogJ0ZyYW5jb2lzIEF1ZGV0JzsgJ1Bh dWwgS3l6aXZhdCc7ICdCb2IgUGVuZmllbGQnOw0KCT4gJ3NpcEBpZXRmLm9yZycNCgk+ICAgICAg ID4gU3ViamVjdDogUmU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBo b25lDQoJPiAgICAgICA+DQoJPiAgICAgICA+DQoJPiAgICAgICA+IE9uIE1vbmRheSwgU2VwdGVt YmVyIDE1LCAyMDAzLCBhdCAxMDoyMyBBTSwgUm9zZW4sDQoJPiBCcmlhbiB3cm90ZToNCgk+ICAg ICAgID4gPiBXZWxsIHRoaXMgZ29lcyB0byB0aGUgaXNzdWUgUGF1bCBhbmQgSSBoYXZlIGRpc2Fn cmVlZCBvbi4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+IEkgdGhpbmsgdGhlIHdvcmRpbmcg b2YgdGhlIHRlbCB1cmkgUkZDIGlzIHF1aXRlDQoJPiBjbGVhciB0aGF0IHlvdQ0KCT4gICAgICAg PiA+IGNhbid0IHBhc3MgYSBkaWFsIHN0cmluZyBpbiBvbmUuICBZb3UgY2VydGFpbmx5DQoJPiBj YW4ndCBwYXNzIG9uZSB3aXRoDQoJPiAgICAgICA+ID4gc3RhciBhbmQgcG91bmQuICAgVGhlcmVm b3JlLCBJIGNsYWltLCB0aGVyZSBpcyBubw0KCT4gd2F5IHRvIHBhc3MNCgk+ICAgICAgID4gPiBh IGRpYWwgc3RyaW5nDQoJPiAgICAgICA+DQoJPiAgICAgICA+IEJyaWFuLCAgV2hhdCBwYXJ0IG9m IGEgZGlhbCBzdHJpbmcgZG9lc24ndCBmaXQgaW50bzoNCgk+IDEqcGhvbmVkaWdpdCAgID8NCgk+ ICAgICAgID4NCgk+ICAgICAgID4gcGhvbmVkaWdpdCA9ICIwIiAvICIxIiAvICIyIiAvICIzIiAv ICI0IiAvICI1IiAvICI2IiAvICI3IiAvDQoJPiAgICAgICA+ICI4IiAvICI5IiAvDQoJPiAgICAg ICA+ICAgICAgICAgICAgICAgIkEiIC8gIkIiIC8gIkMiIC8gIkQiIC8gIkUiIC8gIkYiDQoJPiAg ICAgICA+DQoJPiAgICAgICA+IEUgY29ycmVzcG9uZHMgdG8gKiAgYW5kIEYgY29ycmVzcG9uZHMg dG8gIw0KCT4gICAgICAgPg0KCT4gICAgICAgPiB0aGFua3MsDQoJPiAgICAgICA+IC1yb2hhbg0K CT4gICAgICAgPg0KCT4gICAgICAgPg0KCT4gICAgICAgPiA+ICwgdW5sZXNzIHlvdSBwdXQgaXQg aW4gYSB1c2VybmFtZSBvbiBhIFNJUCB1cmksDQoJPiAgICAgICA+ID4gYW5kIGRlbm90ZSB0aGF0 IGl0IGlzIGEgZGlhbCBzdHJpbmcsIGZvciB3aGljaCBhDQoJPiBwaG9uZSBudW1iZXIgaXMNCgk+ ICAgICAgID4gPiBhIHByb3BlciBzdWJzZXQgZm9yIG1vc3QgZGlhbCBwbGFucywgYnkgc3BlY2lm eWluZw0KCT4gdXNlcj1waG9uZS4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+IFBhdWwgZGlz YWdyZWVzLiAgSGUgdGhpbmtzIGhlIGNhbiBzZW5kIGEgZGlhbA0KCT4gc3RyaW5nIGluIGEgdGVs IHVyaS4NCgk+ICAgICAgID4gPiBXaXRob3V0IHNvbWUga2luZCBvZiByZXNvbHV0aW9uIG9mIHRo YXQgaXNzdWUsIHdlDQoJPiBoYXZlIGEgcHJvYmxlbS4NCgk+ICAgICAgID4gPg0KCT4gICAgICAg PiA+IEJyaWFuDQoJPiAgICAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ICAg ICAgID4gPiBGcm9tOiBGcmFuY29pcyBBdWRldCBbbWFpbHRvOmF1ZGV0QG5vcnRlbG5ldHdvcmtz LmNvbV0NCgk+ICAgICAgID4gPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAwMyAxMjox MCBQTQ0KCT4gICAgICAgPiA+IFRvOiAnUGF1bCBLeXppdmF0Jw0KCT4gICAgICAgPiA+IENjOiAn Um9zZW4sIEJyaWFuJzsgJ0JvYiBQZW5maWVsZCc7ICdzaXBAaWV0Zi5vcmcnDQoJPiAgICAgICA+ ID4gU3ViamVjdDogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBo b25lDQoJPiAgICAgICA+ID4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KCT4gICAgICAgPiA+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0 bzpwa3l6aXZhdEBjaXNjby5jb21dDQoJPiAgICAgICA+ID4+IFNlbnQ6IE1vbmRheSwgU2VwdGVt YmVyIDE1LCAyMDAzIDA2OjU4DQoJPiAgICAgICA+ID4+IFRvOiBBdWRldCwgRnJhbmNvaXMgW1ND MTAwOjRLMDI6RVhDSF0NCgk+ICAgICAgID4gPj4gQ2M6ICdSb3NlbiwgQnJpYW4nOyAnQm9iIFBl bmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycNCgk+ICAgICAgID4gPj4gU3ViamVjdDogUmU6IFtTaXBd IFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgICA+ID4gWyBz dHVmZiBkZWxldGVkIGFzIGl0IGxvb2tzIGxpa2Ugd2UgYXJlIGluIGFncmVlbWVudCBdDQoJPiAg ICAgICA+ID4+IEknbSBub3Qgc3VyZSBhYm91dCB0aGUgIm1vc3QiIHBhcnQuIFNvbWUgZG8sIHNv bWUNCgk+IGRvbid0LiBBcyBzcGVjIGlzDQoJPiAgICAgICA+ID4+IGN1cnJlbnRseSB3cml0dGVu LCB0aGUgZXF1aXZhbGVuY2UgYmV0d2VlbiB0ZWwgYW5kDQoJPiAgICAgICA+IHNpcC91c2VyPXBo b25lIGlzDQoJPiAgICAgICA+ID4+IG9ubHkgb25lIHdheS4gKElGIHRoZSB1c2VycGFydCBjb21l cyBmcm9tIGEgdGVsLCB0aGVuIHRoZXJlDQoJPiAgICAgICA+ID4+IFNIT1VMRCBiZSBhDQoJPiAg ICAgICA+ID4+IHVzZXI9cGhvbmUsIGJ1dCB0aGUgcHJlc2VuY2Ugb2YgdXNlcj1waG9uZSBkb2Vz DQoJPiBub3QgaW1wbHkgdGhlDQoJPiAgICAgICA+ID4+IHVzZXJwYXJ0DQoJPiAgICAgICA+ID4+ IGNvbmZvcm1zIHRvIHRlbC4pDQoJPiAgICAgICA+ID4+DQoJPiAgICAgICA+ID4+IEkgcGVyc29u YWxseSBhbSBoYXBweSB3aXRoIHRoZSBtb3JlIHN0cmljdA0KCT4gaW50ZXJwcmV0YXRpb24uIEJ1 dCBJIGFtDQoJPiAgICAgICA+ID4+IHRyeWluZyB0byBob2xkIG91dCBhbiBvbGl2ZSBicmFuY2gg aW4gb3JkZXIgdG8NCgk+IHJlYWNoIGEgbGV2ZWwNCgk+ICAgICAgID4gPj4gb2YgYWdyZWVtZW50 Lg0KCT4gICAgICAgPiA+IE9LLiBJdCBzZWVtcyB0aGF0IHdlIGFyZSBpbiBhZ3JlZW1lbnQuDQoJ PiAgICAgICA+ID4gTXkgc3VnZ2VzdGlvbiBpcyB0byBhc2sgdGhlIHF1ZXN0aW9uIHRvIHRoZSBn cm91cA0KCT4gb2YgaXMgYW55Ym9keQ0KCT4gICAgICAgPiA+IG9iamVjdHMgdG8gbWFrZSBpdCBl eHBsaWNpdCB0aGF0IHVzZXI9cGhvbmVzIG1lYW5zIHRoYXQgdGhlDQoJPiAgICAgICA+IHNpcCBV UkkgaXMNCgk+ICAgICAgID4gPiBkZXJpdmVkDQoJPiAgICAgICA+ID4gZnJvbSBhIHRlbCBVUkk/ DQoJPiAgICAgICA+ID4gSWYgdGhlIGFuc3dlciBpcyBubywgdGhlbiBJIHRoaW5rIHdlIGNhbiBw cm9iYWJseQ0KCT4gZmluYWxseSBwdXQgdGhpcw0KCT4gICAgICAgPiA+IGlzc3VlDQoJPiAgICAg ICA+ID4gdG8gcmVzdC4gT3RoZXJ3aXNlLCB3ZSBuZWVkIHRvIHJld29yayB0aGUgd2hvbGUgdGhp bmcuLi4NCgk+ICAgICAgID4gPiBTby4uLiBEb2VzIGFueWJvZHkgc3Ryb25nbHkgb2JqZWN0IHRv IGV4cGxpY2l0bHkgbWFraW5nIHRoZQ0KCT4gICAgICAgPiB1c2VyPXBob25lDQoJPiAgICAgICA+ ID4gYXR0dHJpYnV0ZSBtZWFuIHRoYXQgdGhlIFNJUCBVUkkgd2FzIGRlcml2ZWQgZnJvbSBhIHRl bCBVUkk/DQoJPiAgICAgICA+ID4+PiBBcHBseWluZyB0aGUgcnVsZXMgb2YgUkZDMzI2MS8xOS4x LjYgaW5zdGVhZCwgd2UnZCBnZXQ6DQoJPiAgICAgICA+ID4+Pg0KCT4gICAgICAgPiA+Pj4NCgk+ ICAgICAgID4gPj4+DQoJPiBzaXA6MTIzNDtwaG9uZS1jb250ZXh0PXlvdXItZGlhbHBsYW4uZm9v LmJhckBmb28uYmFyO3VzZXI9cGhvbmUNCgk+ICAgICAgID4gPj4+DQoJPiAgICAgICA+ID4+PiBX aGljaCAobGlrZSB0aGUgdGVsIFVSSSkgc3BlY2lmaWNhbGx5IGlkZW50aWZpZXMgdGhlDQoJPiAg ICAgICA+ID4+IGRpYWxpbmcgcGxhbiBhbmQNCgk+ICAgICAgID4gPj4+IGRvZXMgbm90IHJlcXVp cmUgb25lIEROUyBlbnRyeSBwZXIgZGlhbGxpbmcgcGxhbi4NCgk+ICAgICAgID4gPj4NCgk+ICAg ICAgID4gPj4NCgk+ICAgICAgID4gPj4gSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYWxzbyBhIGZpbmUg dXNhZ2UuDQoJPiAgICAgICA+ID4+DQoJPiAgICAgICA+ID4+IEJ1dCB3aGF0IGlzIGJlbmVmaXQg b2YgdGhpcyBvdmVyIHVzaW5nIHRoZSB0ZWwgZm9ybWF0IGFuZA0KCT4gICAgICAgPiA+PiB0aGVu IHBhc3NpbmcNCgk+ICAgICAgID4gPj4gdGhlIHJlcXVlc3QgdG8gc2lwOmZvby5iYXI/DQoJPiAg ICAgICA+ID4gVGhlIHRlbCBVUkkgZm9ybWF0IGFzc3VtZXMgdGhhdCB0aGUgcHJveHkga25vd3Mg d2hpY2ggcHJveHkNCgk+ICAgICAgID4gaXMgYXdhcmUNCgk+ICAgICAgID4gPiBvZiB0aGUNCgk+ ICAgICAgID4gPiBwaG9uZSBjb250ZXh0DQoJPiAgICAgICA+ID4gYW5kIHRlbCBVUklzIChpdCBj b3VsZCBiZSBpdHNlbGYsIG9yIGl0IGNvdWxkIGtub3cgd2hpY2gNCgk+ICAgICAgID4gcHJveHkg dG8gcm91dGUNCgk+ICAgICAgID4gPiBzZXNzaW9ucyB0bykuDQoJPiAgICAgICA+ID4gVGhlIHNp cCBVUkkgZm9ybWF0IGxldHMgeW91IHJvdXRlIGl0IHRvIGEgc3BlY2lmaWMgcHJveHkNCgk+ICAg ICAgID4gdGhhdCBpcyBhd2FyZQ0KCT4gICAgICAgPiA+IG9mDQoJPiAgICAgICA+ID4gdGhlIHBo b25lDQoJPiAgICAgICA+ID4gY29udGV4dCwgcG90ZW50aWFsbHkgd2l0aCAiZ2VuZXJpYyIgU0lQ IHByb3hpZXMgaW4gYmV0d2Vlbg0KCT4gICAgICAgPiB0aGF0IGhhdmUNCgk+ICAgICAgID4gPiBu byBpZGVhDQoJPiAgICAgICA+ID4gaG93IHRvIHJvdXRlDQoJPiAgICAgICA+ID4gYmFzZWQgb24g cGhvbmUgY29udGV4dGVzIChvciBldmVuIHRlbCBVUklzKS4gVA0KCT4gICAgICAgPiA+DQoJPiAg ICAgICA+ID4NCgk+ICAgICAgID4gPiBUaGV5IGJvdGggaGF2ZSBtZXJpdHMuDQoJPiAgICAgICA+ ID4NCgk+ICAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KCT4gICAgICAgPiA+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCT4gICAgICAgPiA+IFRoaXMgbGlzdCBpcyBmb3Ig TkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gICAgICAgPiA+IFVz ZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zDQoJPiBvbiBj dXJyZW50IHNpcA0KCT4gICAgICAgPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2 ZWxvcG1lbnRzIG9uIHRoZQ0KCT4gYXBwbGljYXRpb24gb2Ygc2lwDQoJPiAgICAgICA+DQoJPiAg ICAgIA0KCT4gICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCgk+ICAgICAgIFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcA0KCT4gICAgICAgVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxv cG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQoJPiAgICAgICBVc2Ugc2lwLWltcGxlbWVu dG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbg0KCT4gY3VycmVudCBzaXANCgk+ ICAgICAgIFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZQ0K CT4gYXBwbGljYXRpb24gb2Ygc2lwDQoJPiAgICAgIA0KCT4NCgk+DQoJDQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 12:52:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15968 for ; Sat, 20 Sep 2003 12:52:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kxz-00070D-A2 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:52:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGqFau026911 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:52:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kxm-0006zU-0l; Sat, 20 Sep 2003 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kx5-0006wG-MW for sip@optimus.ietf.org; Sat, 20 Sep 2003 12:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15939 for ; Sat, 20 Sep 2003 12:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0kx3-0006Vk-00 for sip@ietf.org; Sat, 20 Sep 2003 12:51:17 -0400 Received: from natsmtp01.webmailer.de ([192.67.198.81]) by ietf-mx with esmtp (Exim 4.12) id 1A0kwo-0006VM-00 for sip@ietf.org; Sat, 20 Sep 2003 12:51:02 -0400 Received: from sip (pD958766F.dip.t-dialin.net [217.88.118.111]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id h8KGnT2D028234; Sat, 20 Sep 2003 18:49:29 +0200 (MEST) From: "Christian Stredicke" To: "'Stastny Richard'" , "'Francois Audet'" , "'Rosen, Brian'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Sat, 20 Sep 2003 18:50:02 +0200 Message-ID: <01c701c37f97$3cde80b0$0a01a8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <06CF906FE3998C4E944213062009F162233857@oefeg-s02.oefeg.loc> Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable It's no rocket science. I don=E2=80=99t understand why millions of = messages are written about this. Our phones follow only a simple algorithm. When someone dials = 9721234567, the phone does the following: 1) It translates it into sip:+19721234567@proxy.com;phone=3Dyes = (according to a simple local dial plan, in this case for North America). = The dial plan is set up like the time zone or language. It is more or = less a lookup of some predefined plans for the different regions. 2) The transport layer realizes that the URL contains the magic = parameter ("phone=3Dyes") and therefore first tries to find = tel:+19721234567 using ENUM.=20 3) If it works, it internally generates a redirect response to the = resulting number. It is important to show it on the display to avoid = surprises on the telephone bill. 4) If it fails, it sends the packet according to the normal rules. The = proxy will see the phone=3Dyes parameter as well and could also try to = do ENUM. Normally, it will use a proxy dial plan to route the call. CS > -----Urspr=C3=BCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von = Stastny > Richard > Gesendet: Freitag, 19. September 2003 22:55 > An: Francois Audet; Rosen, Brian; Rohan Mahy > Cc: Paul Kyzivat; Bob Penfield; sip@ietf.org > Betreff: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 > Thats what I meant in my original example: > If you have a dumb phone, its sends everything to > sip:nnnn@default.proxy.com - which is a dialing string >=20 > If you have a smart UA, it translates the dialstring to > either a tel:nnn;phone-context=3Dcompany.com > or a tel:+nnnn - which is a E164 number > BTW: this is preferred anyway. >=20 > If you have a very clever UA, e.g. a SNOM, > it translates the dialstring into an E.164 number, > queries ENUM, returns a sip:user@host and > we do not have any problem at all ;-) >=20 > Richard > PS: note that ;user=3Dphone is not needed anywhere >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortelnetworks.com] > Gesendet: Fr 19.09.2003 22:11 > An: 'Rosen, Brian'; Stastny Richard; 'Rohan Mahy' > Cc: 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > If the proxy knows that "phone-context=3Ddial-digit-us.marconi.com" > for example > means a dial plan, then it would know it is a dial digit string > (like > from a dumb phone). If instead it says "phone- > context=3Dglobal.marconi.com" (for example), then it would know it is = a > Marconi private NUMBER (like from >=20 > a PBX gateway). >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, September 19, 2003 13:02 > > To: 'Stastny Richard'; Rohan Mahy > > Cc: Audet, Francois [SC100:4K02:EXCH]; Paul Kyzivat; Bob > > Penfield; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > Richard > > > > A user at a dumb phone always enters a dial string. > > No argument. > > > > However, at some point, either a UA translates a dial string > > to a phone number, or a downstream proxy does it. At that > > point it isn't a dial string, it's a phone number, and it > > might be in a context (it could be global). What I've > > mentioned is a case, which I think is pretty common, where > > the number is not represented the same way as a dial string > > and a phone number, and yet is in the same domain. > > > > Let's take a practical example. Suppose I have a domain with > > a reasonably smart proxy server and a mix of phones. Some > > phones have dialstring translation, some don't. The proxy > > server can translate dial strings to phone numbers, and it > > also can route phone numbers. Obviously it can do both (ie > > translate then route). > > > > Now, how does the proxy know if it needs to translate? That > > is, how does it know that a uri passed to it is a dial string > > vs a phone number? If I pass it a phone number and it > > decides to apply it's dialstring processing, that will fail. > > If I pass a > > dial string and it just routes, that will fail. It has to > > know what it is given. In my example it was > > 7246826@pit.sip.marconi.com That's a phone number, and a dial > > string, but it's two different destinations. In my numbering > > plan, it's my phone. In my dialing plan it's an extension in > > another office. > > > > Brian > > > > Brian > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, September 19, 2003 3:33 PM > > > To: Rosen, Brian; Rohan Mahy > > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > > > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > > Brian, > > > > > > If you pick up a phone and enter digits, it ALWAYS a dialing > string > > > and you are ALWAYS in ONE and ONLY ONE dialing plan.. > > > > > > You never enter a phone number directly, you always > > > dial (if you dial a local number, the mapping may be 1:1) > > > > > > So if you enter a dial string in a SIP phone and iu sends > > > it with nnnn@default.com to your defaulr sip server, this > > server then > > > evaluates the dialing plan and translates it to a numbering > plan. > > > > > > Btw, thats exactly how fwd, iptel sipphone, ... are implemeted. > > > > > > Richard > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Gesendet: Fr 19.09.2003 19:37 > > > An: Stastny Richard; Rohan Mahy > > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > > > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > > > > > Richard > > > > > > My phone number within my local domain is 742-6826. > > > I could change the convention and make it 724-742-6826 or > > > 1-724-742-6826 if you want. > > > > > > My dial plan would send a call to a different phone if you > > > dialed any of those strings. > > > > > > If you send an INVITE 7426826@pit.sip.marconi.com it will > ring > > > my sipphone. > > > > > > If I dial 7426826, it won't ring my sip phone. I have to > dial > > > 6826 or 9-742-6826 or even 300-6826. > > > > > > Using your algorithm, I would assume 7426826 was a dial > string, > > > and that would be wrong. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Friday, September 19, 2003 1:24 PM > > > > To: Rosen, Brian; Rohan Mahy > > > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; > sip@ietf.org > > > > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > > > > > See below > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Gesendet: Fr 19.09.2003 15:17 > > > > An: 'Rohan Mahy' > > > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob > Penfield'; > > > > 'sip@ietf.org' > > > > Betreff: RE: [Sip] SIPIT Interop problem with > > > ;user=3Dphone > > > > > > > > > > > > > > > > I've never seen E/F substitution for */#, and I've > > > > never seen any > > > > sip device that did it, but it's a possible way > forward. > > > > > > > > I do think that some RFC would have to change > > > the wording of > > > > 2806bis to allow dial strings. The authors > > > seemed to explicitly > > > > declare them out of scope of the document. > > > Generally, we don't > > > > usually claim "that which is not specifically > > > > disallowed is legal" > > > > as a way around "out of scope" wording in our > documents. > > > > > > > > I remain unhappy that dial strings, > > > untranslated phone numbers > > > > and translated phone numbers are indistinguishable. > > > > They are different, > > > > they are handled differently, and they should be > > > > distinguishable. > > > > I don't understand why some people are so adamant > that > > > > they should all > > > > be represented in EXACTLY the same way (tel uri > > > or sip uri with > > > > or without user=3Dphone). They are not the same > > > things, and they > > > > should have distinctive representations. > > > > > > > > Richard: A string of digits is a string of digits. > > > > > > > > The simplest way to distinguish is: > > > > > > > > 1. If you just see a string of digits, you have to assume > its > > > > a dial string > > > > > > > > until you know better. > > > > > > > > 2. If you analysed the digits and found out its an E.164 > > > > number, normalise it > > > > > > > > to tel:+xxxx, or sip:+xxxx@foo.bar > > > > > > > > 3. If you analysed it and found out it is a local > > > number, then either > > > > > > > > use tel:xxxx; phone-context=3Dfoo.bar or > > > sip:xxx@foo.bar;user=3Dphone > > > > > > > > I do not understand the problem > > > > > > > > Richard > > > > > > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > > > Sent: Thursday, September 18, 2003 9:17 PM > > > > > To: Rosen, Brian > > > > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob > Penfield'; > > > > 'sip@ietf.org' > > > > > Subject: Re: [Sip] SIPIT Interop problem with > > > ;user=3Dphone > > > > > > > > > > > > > > > On Monday, September 15, 2003, at 10:23 AM, Rosen, > > > > Brian wrote: > > > > > > Well this goes to the issue Paul and I have > > > disagreed on. > > > > > > > > > > > > I think the wording of the tel uri RFC is quite > > > > clear that you > > > > > > can't pass a dial string in one. You certainly > > > > can't pass one with > > > > > > star and pound. Therefore, I claim, there is > no > > > > way to pass > > > > > > a dial string > > > > > > > > > > Brian, What part of a dial string doesn't fit > into: > > > > 1*phonedigit ? > > > > > > > > > > phonedigit =3D "0" / "1" / "2" / "3" / "4" / > > > "5" / "6" / "7" / > > > > > "8" / "9" / > > > > > "A" / "B" / "C" / "D" / "E" / "F" > > > > > > > > > > E corresponds to * and F corresponds to # > > > > > > > > > > thanks, > > > > > -rohan > > > > > > > > > > > > > > > > , unless you put it in a username on a SIP uri, > > > > > > and denote that it is a dial string, for which a > > > > phone number is > > > > > > a proper subset for most dial plans, by > specifying > > > > user=3Dphone. > > > > > > > > > > > > Paul disagrees. He thinks he can send a dial > > > > string in a tel uri. > > > > > > Without some kind of resolution of that issue, > we > > > > have a problem. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Francois Audet > > > [mailto:audet@nortelnetworks.com] > > > > > > Sent: Monday, September 15, 2003 12:10 PM > > > > > > To: 'Paul Kyzivat' > > > > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; > 'sip@ietf.org' > > > > > > Subject: RE: [Sip] SIPIT Interop problem > > > with ;user=3Dphone > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: Monday, September 15, 2003 06:58 > > > > > >> To: Audet, Francois [SC100:4K02:EXCH] > > > > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; > 'sip@ietf.org' > > > > > >> Subject: Re: [Sip] SIPIT Interop problem > > > with ;user=3Dphone > > > > > > [ stuff deleted as it looks like we are in > > > agreement ] > > > > > >> I'm not sure about the "most" part. Some do, > some > > > > don't. As spec is > > > > > >> currently written, the equivalence between tel > and > > > > > sip/user=3Dphone is > > > > > >> only one way. (IF the userpart comes from > > > a tel, then there > > > > > >> SHOULD be a > > > > > >> user=3Dphone, but the presence of user=3Dphone = does > > > > not imply the > > > > > >> userpart > > > > > >> conforms to tel.) > > > > > >> > > > > > >> I personally am happy with the more strict > > > > interpretation. But I am > > > > > >> trying to hold out an olive branch in order to > > > > reach a level > > > > > >> of agreement. > > > > > > OK. It seems that we are in agreement. > > > > > > My suggestion is to ask the question to the > group > > > > of is anybody > > > > > > objects to make it explicit that > > > user=3Dphones means that the > > > > > sip URI is > > > > > > derived > > > > > > from a tel URI? > > > > > > If the answer is no, then I think we can > probably > > > > finally put this > > > > > > issue > > > > > > to rest. Otherwise, we need to rework the > > > whole thing... > > > > > > So... Does anybody strongly object to > > > explicitly making the > > > > > user=3Dphone > > > > > > atttribute mean that the SIP URI was > > > derived from a tel URI? > > > > > >>> Applying the rules of RFC3261/19.1.6 > > > instead, we'd get: > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > = sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone > > > > > >>> > > > > > >>> Which (like the tel URI) specifically > > > identifies the > > > > > >> dialing plan and > > > > > >>> does not require one DNS entry per dialling > plan. > > > > > >> > > > > > >> > > > > > >> I agree that this is also a fine usage. > > > > > >> > > > > > >> But what is benefit of this over using the > > > tel format and > > > > > >> then passing > > > > > >> the request to sip:foo.bar? > > > > > > The tel URI format assumes that the proxy > > > knows which proxy > > > > > is aware > > > > > > of the > > > > > > phone context > > > > > > and tel URIs (it could be itself, or it > > > could know which > > > > > proxy to route > > > > > > sessions to). > > > > > > The sip URI format lets you route it to a > > > specific proxy > > > > > that is aware > > > > > > of > > > > > > the phone > > > > > > context, potentially with "generic" SIP > > > proxies in between > > > > > that have > > > > > > no idea > > > > > > how to route > > > > > > based on phone contextes (or even tel URIs). T > > > > > > > > > > > > > > > > > > They both have merits. > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the > > > core SIP Protocol > > > > > > Use sip-implementors@cs.columbia.edu for > questions > > > > on current sip > > > > > > Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core > > > SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > on > > > > current sip > > > > Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > > > > > > > > > > > > > > > > > >=20 > XX=1Bm >=20 > 0 =0F j)fj=7F b?*S+% b+4Ez =DA=B6=17 =1C=ED=9F=80=ED=B3=A2U,z=C8=A9) = +=DA=B3, %=ED=9F=80=ED=B7=BAfk + *'=DC=BA=DE=9E"=DB=A5K=1E*ix _ ~{ ^ > hg'=CA=B6=17bqbz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Sep 20 13:00:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14810 for ; Sat, 20 Sep 2003 12:13:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kMJ-00048s-I8 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGDJft015800 for sip-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kM3-00041k-2l; Sat, 20 Sep 2003 12:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k2R-0002Ar-9l for sip@optimus.ietf.org; Sat, 20 Sep 2003 11:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21628 for ; Fri, 19 Sep 2003 16:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SE4-0001Nh-00 for sip@ietf.org; Fri, 19 Sep 2003 16:51:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 1A0SDs-0001MJ-00 for sip@ietf.org; Fri, 19 Sep 2003 16:51:25 -0400 Subject: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 22:55:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F162233857@oefeg-s02.oefeg.loc> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcN+6u74JhQ3dt0zSduz4NynWzNK/wABHb3O From: "Stastny Richard" To: "Francois Audet" , "Rosen, Brian" , "Rohan Mahy" Cc: "Paul Kyzivat" , "Bob Penfield" , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 VGhhdHMgd2hhdCBJIG1lYW50IGluIG15IG9yaWdpbmFsIGV4YW1wbGU6DQpJZiB5b3UgaGF2ZSBh IGR1bWIgcGhvbmUsIGl0cyBzZW5kcyBldmVyeXRoaW5nIHRvDQpzaXA6bm5ubkBkZWZhdWx0LnBy b3h5LmNvbSAtIHdoaWNoIGlzIGEgZGlhbGluZyBzdHJpbmcNCiANCklmIHlvdSBoYXZlIGEgc21h cnQgVUEsIGl0IHRyYW5zbGF0ZXMgdGhlIGRpYWxzdHJpbmcgdG8NCmVpdGhlciBhIHRlbDpubm47 cGhvbmUtY29udGV4dD1jb21wYW55LmNvbQ0Kb3IgYSB0ZWw6K25ubm4gLSB3aGljaCBpcyBhIEUx NjQgbnVtYmVyDQpCVFc6IHRoaXMgaXMgcHJlZmVycmVkIGFueXdheS4NCiANCklmIHlvdSBoYXZl IGEgdmVyeSBjbGV2ZXIgVUEsIGUuZy4gYSBTTk9NLA0KaXQgdHJhbnNsYXRlcyB0aGUgZGlhbHN0 cmluZyBpbnRvIGFuIEUuMTY0IG51bWJlciwNCnF1ZXJpZXMgRU5VTSwgcmV0dXJucyBhIHNpcDp1 c2VyQGhvc3QgYW5kDQp3ZSBkbyBub3QgaGF2ZSBhbnkgcHJvYmxlbSBhdCBhbGwgOy0pDQogDQpS aWNoYXJkDQpQUzogbm90ZSB0aGF0IDt1c2VyPXBob25lIGlzIG5vdCBuZWVkZWQgYW55d2hlcmUN Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBGcmFuY29pcyBB dWRldCBbbWFpbHRvOmF1ZGV0QG5vcnRlbG5ldHdvcmtzLmNvbV0gDQoJR2VzZW5kZXQ6IEZyIDE5 LjA5LjIwMDMgMjI6MTEgDQoJQW46ICdSb3NlbiwgQnJpYW4nOyBTdGFzdG55IFJpY2hhcmQ7ICdS b2hhbiBNYWh5JyANCglDYzogJ1BhdWwgS3l6aXZhdCc7ICdCb2IgUGVuZmllbGQnOyAnc2lwQGll dGYub3JnJyANCglCZXRyZWZmOiBSRTogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGgg O3VzZXI9cGhvbmUNCgkNCgkNCg0KCUlmIHRoZSBwcm94eSBrbm93cyB0aGF0ICJwaG9uZS1jb250 ZXh0PWRpYWwtZGlnaXQtdXMubWFyY29uaS5jb20iIGZvciBleGFtcGxlIA0KCW1lYW5zIGEgZGlh bCBwbGFuLCB0aGVuIGl0IHdvdWxkIGtub3cgaXQgaXMgYSBkaWFsIGRpZ2l0IHN0cmluZyAobGlr ZSANCglmcm9tIGEgZHVtYiBwaG9uZSkuIElmIGluc3RlYWQgaXQgc2F5cyAicGhvbmUtY29udGV4 dD1nbG9iYWwubWFyY29uaS5jb20iIChmb3IgZXhhbXBsZSksIHRoZW4gaXQgd291bGQga25vdyBp dCBpcyBhIE1hcmNvbmkgcHJpdmF0ZSBOVU1CRVIgKGxpa2UgZnJvbQ0KDQoJYSBQQlggZ2F0ZXdh eSkuIA0KDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+IEZyb206IFJvc2VuLCBC cmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmkuY29tXSANCgk+IFNlbnQ6IEZyaWRheSwg U2VwdGVtYmVyIDE5LCAyMDAzIDEzOjAyIA0KCT4gVG86ICdTdGFzdG55IFJpY2hhcmQnOyBSb2hh biBNYWh5IA0KCT4gQ2M6IEF1ZGV0LCBGcmFuY29pcyBbU0MxMDA6NEswMjpFWENIXTsgUGF1bCBL eXppdmF0OyBCb2IgDQoJPiBQZW5maWVsZDsgc2lwQGlldGYub3JnIA0KCT4gU3ViamVjdDogUkU6 IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lIA0KCT4gDQoJPiAN Cgk+IFJpY2hhcmQgDQoJPiANCgk+IEEgdXNlciBhdCBhIGR1bWIgcGhvbmUgYWx3YXlzIGVudGVy cyBhIGRpYWwgc3RyaW5nLiANCgk+IE5vIGFyZ3VtZW50LiANCgk+IA0KCT4gSG93ZXZlciwgYXQg c29tZSBwb2ludCwgZWl0aGVyIGEgVUEgdHJhbnNsYXRlcyBhIGRpYWwgc3RyaW5nIA0KCT4gdG8g YSBwaG9uZSBudW1iZXIsIG9yIGEgZG93bnN0cmVhbSBwcm94eSBkb2VzIGl0LiAgQXQgdGhhdCAN Cgk+IHBvaW50IGl0IGlzbid0IGEgZGlhbCBzdHJpbmcsIGl0J3MgYSBwaG9uZSBudW1iZXIsIGFu ZCBpdCANCgk+IG1pZ2h0IGJlIGluIGEgY29udGV4dCAoaXQgY291bGQgYmUgZ2xvYmFsKS4gIFdo YXQgSSd2ZSANCgk+IG1lbnRpb25lZCBpcyBhIGNhc2UsIHdoaWNoIEkgdGhpbmsgaXMgcHJldHR5 IGNvbW1vbiwgd2hlcmUgDQoJPiB0aGUgbnVtYmVyIGlzIG5vdCByZXByZXNlbnRlZCB0aGUgc2Ft ZSB3YXkgYXMgYSBkaWFsIHN0cmluZyANCgk+IGFuZCBhIHBob25lIG51bWJlciwgYW5kIHlldCBp cyBpbiB0aGUgc2FtZSBkb21haW4uIA0KCT4gDQoJPiBMZXQncyB0YWtlIGEgcHJhY3RpY2FsIGV4 YW1wbGUuICBTdXBwb3NlIEkgaGF2ZSBhIGRvbWFpbiB3aXRoIA0KCT4gYSByZWFzb25hYmx5IHNt YXJ0IHByb3h5IHNlcnZlciBhbmQgYSBtaXggb2YgcGhvbmVzLiAgU29tZSANCgk+IHBob25lcyBo YXZlIGRpYWxzdHJpbmcgdHJhbnNsYXRpb24sIHNvbWUgZG9uJ3QuICBUaGUgcHJveHkgDQoJPiBz ZXJ2ZXIgY2FuIHRyYW5zbGF0ZSBkaWFsIHN0cmluZ3MgdG8gcGhvbmUgbnVtYmVycywgYW5kIGl0 IA0KCT4gYWxzbyBjYW4gcm91dGUgcGhvbmUgbnVtYmVycy4gIE9idmlvdXNseSBpdCBjYW4gZG8g Ym90aCAoaWUgDQoJPiB0cmFuc2xhdGUgdGhlbiByb3V0ZSkuIA0KCT4gDQoJPiBOb3csIGhvdyBk b2VzIHRoZSBwcm94eSBrbm93IGlmIGl0IG5lZWRzIHRvIHRyYW5zbGF0ZT8gIFRoYXQgDQoJPiBp cywgaG93IGRvZXMgaXQga25vdyB0aGF0IGEgdXJpIHBhc3NlZCB0byBpdCBpcyBhIGRpYWwgc3Ry aW5nIA0KCT4gdnMgYSBwaG9uZSBudW1iZXI/ICBJZiBJIHBhc3MgaXQgYSBwaG9uZSBudW1iZXIg YW5kIGl0IA0KCT4gZGVjaWRlcyB0byBhcHBseSBpdCdzIGRpYWxzdHJpbmcgcHJvY2Vzc2luZywg dGhhdCB3aWxsIGZhaWwuICANCgk+IElmIEkgcGFzcyBhIA0KCT4gZGlhbCBzdHJpbmcgYW5kIGl0 IGp1c3Qgcm91dGVzLCB0aGF0IHdpbGwgZmFpbC4gIEl0IGhhcyB0byANCgk+IGtub3cgd2hhdCBp dCBpcyBnaXZlbi4gIEluIG15IGV4YW1wbGUgaXQgd2FzIA0KCT4gNzI0NjgyNkBwaXQuc2lwLm1h cmNvbmkuY29tIFRoYXQncyBhIHBob25lIG51bWJlciwgYW5kIGEgZGlhbCANCgk+IHN0cmluZywg YnV0IGl0J3MgdHdvIGRpZmZlcmVudCBkZXN0aW5hdGlvbnMuICBJbiBteSBudW1iZXJpbmcgDQoJ PiBwbGFuLCBpdCdzIG15IHBob25lLiAgSW4gbXkgZGlhbGluZyBwbGFuIGl0J3MgYW4gZXh0ZW5z aW9uIGluIA0KCT4gYW5vdGhlciBvZmZpY2UuIA0KCT4gDQoJPiBCcmlhbiANCgk+IA0KCT4gQnJp YW4gDQoJPiANCgk+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJPiA+IEZyb206IFN0 YXN0bnkgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdF0gDQoJPiA+IFNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDAzIDM6MzMgUE0gDQoJPiA+IFRvOiBSb3Nlbiwg QnJpYW47IFJvaGFuIE1haHkgDQoJPiA+IENjOiBGcmFuY29pcyBBdWRldDsgUGF1bCBLeXppdmF0 OyBCb2IgUGVuZmllbGQ7IHNpcEBpZXRmLm9yZyANCgk+ID4gU3ViamVjdDogQVc6IFtTaXBdIFNJ UElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lIA0KCT4gPiANCgk+ID4gDQoJPiA+ IEJyaWFuLCANCgk+ID4gIA0KCT4gPiBJZiB5b3UgcGljayB1cCBhIHBob25lIGFuZCBlbnRlciBk aWdpdHMsIGl0IEFMV0FZUyBhIGRpYWxpbmcgc3RyaW5nIA0KCT4gPiBhbmQgeW91IGFyZSBBTFdB WVMgaW4gT05FIGFuZCBPTkxZIE9ORSBkaWFsaW5nIHBsYW4uLiANCgk+ID4gIA0KCT4gPiBZb3Ug bmV2ZXIgZW50ZXIgYSBwaG9uZSBudW1iZXIgZGlyZWN0bHksIHlvdSBhbHdheXMgDQoJPiA+IGRp YWwgKGlmIHlvdSBkaWFsIGEgbG9jYWwgbnVtYmVyLCB0aGUgbWFwcGluZyBtYXkgYmUgMToxKSAN Cgk+ID4gIA0KCT4gPiBTbyBpZiB5b3UgZW50ZXIgYSBkaWFsIHN0cmluZyBpbiBhIFNJUCBwaG9u ZSBhbmQgaXUgc2VuZHMgDQoJPiA+IGl0IHdpdGggbm5ubkBkZWZhdWx0LmNvbSB0byB5b3VyIGRl ZmF1bHIgc2lwIHNlcnZlciwgdGhpcyANCgk+IHNlcnZlciB0aGVuIA0KCT4gPiBldmFsdWF0ZXMg dGhlIGRpYWxpbmcgcGxhbiBhbmQgdHJhbnNsYXRlcyBpdCB0byBhIG51bWJlcmluZyBwbGFuLiAN Cgk+ID4gIA0KCT4gPiBCdHcsIHRoYXRzIGV4YWN0bHkgaG93IGZ3ZCwgaXB0ZWwgc2lwcGhvbmUs IC4uLiBhcmUgaW1wbGVtZXRlZC4gDQoJPiA+ICANCgk+ID4gUmljaGFyZCANCgk+ID4gDQoJPiA+ ICAgICAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCT4gPiAgICAgVm9uOiBS b3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbV0gDQoJPiA+ICAgICBH ZXNlbmRldDogRnIgMTkuMDkuMjAwMyAxOTozNyANCgk+ID4gICAgIEFuOiBTdGFzdG55IFJpY2hh cmQ7IFJvaGFuIE1haHkgDQoJPiA+ICAgICBDYzogRnJhbmNvaXMgQXVkZXQ7IFBhdWwgS3l6aXZh dDsgQm9iIFBlbmZpZWxkOyBzaXBAaWV0Zi5vcmcgDQoJPiA+ICAgICBCZXRyZWZmOiBSRTogW1Np cF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUgDQoJPiA+ICAgICANCgk+ ID4gICAgIA0KCT4gPiANCgk+ID4gICAgIFJpY2hhcmQgDQoJPiA+ICAgICANCgk+ID4gICAgIE15 IHBob25lIG51bWJlciB3aXRoaW4gbXkgbG9jYWwgZG9tYWluIGlzIDc0Mi02ODI2LiANCgk+ID4g ICAgIEkgY291bGQgY2hhbmdlIHRoZSBjb252ZW50aW9uIGFuZCBtYWtlIGl0IDcyNC03NDItNjgy NiBvciANCgk+ID4gICAgIDEtNzI0LTc0Mi02ODI2IGlmIHlvdSB3YW50LiANCgk+ID4gICAgIA0K CT4gPiAgICAgTXkgZGlhbCBwbGFuIHdvdWxkIHNlbmQgYSBjYWxsIHRvIGEgZGlmZmVyZW50IHBo b25lIGlmIHlvdSANCgk+ID4gICAgIGRpYWxlZCBhbnkgb2YgdGhvc2Ugc3RyaW5ncy4gDQoJPiA+ ICAgICANCgk+ID4gICAgIElmIHlvdSBzZW5kIGFuIElOVklURSA3NDI2ODI2QHBpdC5zaXAubWFy Y29uaS5jb20gaXQgd2lsbCByaW5nIA0KCT4gPiAgICAgbXkgc2lwcGhvbmUuIA0KCT4gPiAgICAg DQoJPiA+ICAgICBJZiBJIGRpYWwgNzQyNjgyNiwgaXQgd29uJ3QgcmluZyBteSBzaXAgcGhvbmUu ICBJIGhhdmUgdG8gZGlhbCANCgk+ID4gICAgIDY4MjYgb3IgOS03NDItNjgyNiAgb3IgZXZlbiAz MDAtNjgyNi4gDQoJPiA+ICAgICANCgk+ID4gICAgIFVzaW5nIHlvdXIgYWxnb3JpdGhtLCBJIHdv dWxkIGFzc3VtZSA3NDI2ODI2IHdhcyBhIGRpYWwgc3RyaW5nLCANCgk+ID4gICAgIGFuZCB0aGF0 IHdvdWxkIGJlIHdyb25nLiANCgk+ID4gICAgIA0KCT4gPiAgICAgQnJpYW4gDQoJPiA+ICAgICAN Cgk+ID4gICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJPiA+ICAgICA+IEZyb206 IFN0YXN0bnkgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdF0gDQoJPiA+ ICAgICA+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDAzIDE6MjQgUE0gDQoJPiA+ICAg ICA+IFRvOiBSb3NlbiwgQnJpYW47IFJvaGFuIE1haHkgDQoJPiA+ICAgICA+IENjOiBGcmFuY29p cyBBdWRldDsgUGF1bCBLeXppdmF0OyBCb2IgUGVuZmllbGQ7IHNpcEBpZXRmLm9yZyANCgk+ID4g ICAgID4gU3ViamVjdDogQVc6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2Vy PXBob25lIA0KCT4gPiAgICAgPiANCgk+ID4gICAgID4gDQoJPiA+ICAgICA+IFNlZSBiZWxvdyAN Cgk+ID4gICAgID4gDQoJPiA+ICAgICA+ICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS0gDQoJPiA+ICAgICA+ICAgICAgIFZvbjogUm9zZW4sIEJyaWFuIFttYWlsdG86QnJp YW4uUm9zZW5AbWFyY29uaS5jb21dIA0KCT4gPiAgICAgPiAgICAgICBHZXNlbmRldDogRnIgMTku MDkuMjAwMyAxNToxNyANCgk+ID4gICAgID4gICAgICAgQW46ICdSb2hhbiBNYWh5JyANCgk+ID4g ICAgID4gICAgICAgQ2M6ICdGcmFuY29pcyBBdWRldCc7ICdQYXVsIEt5eml2YXQnOyAnQm9iIFBl bmZpZWxkJzsgDQoJPiA+ICAgICA+ICdzaXBAaWV0Zi5vcmcnIA0KCT4gPiAgICAgPiAgICAgICBC ZXRyZWZmOiBSRTogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggDQoJPiA+IDt1c2Vy PXBob25lIA0KCT4gPiAgICAgPiAgICAgIA0KCT4gPiAgICAgPiAgICAgIA0KCT4gPiAgICAgPiAN Cgk+ID4gICAgID4gICAgICAgSSd2ZSBuZXZlciBzZWVuIEUvRiBzdWJzdGl0dXRpb24gZm9yICov IywgYW5kIEkndmUgDQoJPiA+ICAgICA+IG5ldmVyIHNlZW4gYW55IA0KCT4gPiAgICAgPiAgICAg ICBzaXAgZGV2aWNlIHRoYXQgZGlkIGl0LCBidXQgaXQncyBhIHBvc3NpYmxlIHdheSBmb3J3YXJk LiANCgk+ID4gICAgID4gICAgICANCgk+ID4gICAgID4gICAgICAgSSBkbyB0aGluayB0aGF0IHNv bWUgUkZDIHdvdWxkIGhhdmUgdG8gY2hhbmdlIA0KCT4gPiB0aGUgd29yZGluZyBvZiANCgk+ID4g ICAgID4gICAgICAgMjgwNmJpcyB0byBhbGxvdyBkaWFsIHN0cmluZ3MuICBUaGUgYXV0aG9ycyAN Cgk+ID4gc2VlbWVkIHRvIGV4cGxpY2l0bHkgDQoJPiA+ICAgICA+ICAgICAgIGRlY2xhcmUgdGhl bSBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRvY3VtZW50LiAgDQoJPiA+IEdlbmVyYWxseSwgd2UgZG9u J3QgDQoJPiA+ICAgICA+ICAgICAgIHVzdWFsbHkgY2xhaW0gInRoYXQgd2hpY2ggaXMgbm90IHNw ZWNpZmljYWxseSANCgk+ID4gICAgID4gZGlzYWxsb3dlZCBpcyBsZWdhbCIgDQoJPiA+ICAgICA+ ICAgICAgIGFzIGEgd2F5IGFyb3VuZCAib3V0IG9mIHNjb3BlIiB3b3JkaW5nIGluIG91ciBkb2N1 bWVudHMuIA0KCT4gPiAgICAgPiAgICAgIA0KCT4gPiAgICAgPiAgICAgICBJIHJlbWFpbiB1bmhh cHB5IHRoYXQgZGlhbCBzdHJpbmdzLCANCgk+ID4gdW50cmFuc2xhdGVkIHBob25lIG51bWJlcnMg DQoJPiA+ICAgICA+ICAgICAgIGFuZCB0cmFuc2xhdGVkIHBob25lIG51bWJlcnMgYXJlIGluZGlz dGluZ3Vpc2hhYmxlLiANCgk+ID4gICAgID4gVGhleSBhcmUgZGlmZmVyZW50LCANCgk+ID4gICAg ID4gICAgICAgdGhleSBhcmUgaGFuZGxlZCBkaWZmZXJlbnRseSwgYW5kIHRoZXkgc2hvdWxkIGJl IA0KCT4gPiAgICAgPiBkaXN0aW5ndWlzaGFibGUuIA0KCT4gPiAgICAgPiAgICAgICBJIGRvbid0 IHVuZGVyc3RhbmQgd2h5IHNvbWUgcGVvcGxlIGFyZSBzbyBhZGFtYW50IHRoYXQgDQoJPiA+ICAg ICA+IHRoZXkgc2hvdWxkIGFsbCANCgk+ID4gICAgID4gICAgICAgYmUgcmVwcmVzZW50ZWQgaW4g RVhBQ1RMWSB0aGUgc2FtZSB3YXkgKHRlbCB1cmkgDQoJPiA+IG9yIHNpcCB1cmkgd2l0aCANCgk+ ID4gICAgID4gICAgICAgb3Igd2l0aG91dCB1c2VyPXBob25lKS4gIFRoZXkgYXJlIG5vdCB0aGUg c2FtZSANCgk+ID4gdGhpbmdzLCBhbmQgdGhleSANCgk+ID4gICAgID4gICAgICAgc2hvdWxkIGhh dmUgZGlzdGluY3RpdmUgcmVwcmVzZW50YXRpb25zLiANCgk+ID4gICAgID4gDQoJPiA+ICAgICA+ IFJpY2hhcmQ6IEEgc3RyaW5nIG9mIGRpZ2l0cyBpcyBhIHN0cmluZyBvZiBkaWdpdHMuIA0KCT4g PiAgICAgPiANCgk+ID4gICAgID4gVGhlIHNpbXBsZXN0IHdheSB0byBkaXN0aW5ndWlzaCBpczog DQoJPiA+ICAgICA+IA0KCT4gPiAgICAgPiAxLiBJZiB5b3UganVzdCBzZWUgYSBzdHJpbmcgb2Yg ZGlnaXRzLCB5b3UgaGF2ZSB0byBhc3N1bWUgaXRzIA0KCT4gPiAgICAgPiBhIGRpYWwgc3RyaW5n IA0KCT4gPiAgICAgPiANCgk+ID4gICAgID4gdW50aWwgeW91IGtub3cgYmV0dGVyLiANCgk+ID4g ICAgID4gDQoJPiA+ICAgICA+IDIuIElmIHlvdSBhbmFseXNlZCB0aGUgZGlnaXRzIGFuZCBmb3Vu ZCBvdXQgaXRzIGFuIEUuMTY0IA0KCT4gPiAgICAgPiBudW1iZXIsIG5vcm1hbGlzZSBpdCANCgk+ ID4gICAgID4gDQoJPiA+ICAgICA+IHRvIHRlbDoreHh4eCwgb3Igc2lwOit4eHh4QGZvby5iYXIg DQoJPiA+ICAgICA+IA0KCT4gPiAgICAgPiAzLiBJZiB5b3UgYW5hbHlzZWQgaXQgYW5kIGZvdW5k IG91dCBpdCBpcyBhIGxvY2FsIA0KCT4gPiBudW1iZXIsIHRoZW4gZWl0aGVyIA0KCT4gPiAgICAg PiANCgk+ID4gICAgID4gdXNlIHRlbDp4eHh4OyBwaG9uZS1jb250ZXh0PWZvby5iYXIgb3IgDQoJ PiA+IHNpcDp4eHhAZm9vLmJhcjt1c2VyPXBob25lIA0KCT4gPiAgICAgPiANCgk+ID4gICAgID4g SSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSANCgk+ID4gICAgID4gDQoJPiA+ICAgICA+ IFJpY2hhcmQgDQoJPiA+ICAgICA+IA0KCT4gPiAgICAgPiAgICAgIA0KCT4gPiAgICAgPiAgICAg IA0KCT4gPiAgICAgPiAgICAgICBCcmlhbiANCgk+ID4gICAgID4gICAgICANCgk+ID4gICAgID4g ICAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+ID4gICAgID4gICAgICAgPiBG cm9tOiBSb2hhbiBNYWh5IFttYWlsdG86cm9oYW5AY2lzY28uY29tXSANCgk+ID4gICAgID4gICAg ICAgPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE4LCAyMDAzIDk6MTcgUE0gDQoJPiA+ICAg ICA+ICAgICAgID4gVG86IFJvc2VuLCBCcmlhbiANCgk+ID4gICAgID4gICAgICAgPiBDYzogJ0Zy YW5jb2lzIEF1ZGV0JzsgJ1BhdWwgS3l6aXZhdCc7ICdCb2IgUGVuZmllbGQnOyANCgk+ID4gICAg ID4gJ3NpcEBpZXRmLm9yZycgDQoJPiA+ICAgICA+ICAgICAgID4gU3ViamVjdDogUmU6IFtTaXBd IFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIA0KCT4gPiA7dXNlcj1waG9uZSANCgk+ID4gICAg ID4gICAgICAgPiANCgk+ID4gICAgID4gICAgICAgPiANCgk+ID4gICAgID4gICAgICAgPiBPbiBN b25kYXksIFNlcHRlbWJlciAxNSwgMjAwMywgYXQgMTA6MjMgQU0sIFJvc2VuLCANCgk+ID4gICAg ID4gQnJpYW4gd3JvdGU6IA0KCT4gPiAgICAgPiAgICAgICA+ID4gV2VsbCB0aGlzIGdvZXMgdG8g dGhlIGlzc3VlIFBhdWwgYW5kIEkgaGF2ZSANCgk+ID4gZGlzYWdyZWVkIG9uLiANCgk+ID4gICAg ID4gICAgICAgPiA+IA0KCT4gPiAgICAgPiAgICAgICA+ID4gSSB0aGluayB0aGUgd29yZGluZyBv ZiB0aGUgdGVsIHVyaSBSRkMgaXMgcXVpdGUgDQoJPiA+ICAgICA+IGNsZWFyIHRoYXQgeW91IA0K CT4gPiAgICAgPiAgICAgICA+ID4gY2FuJ3QgcGFzcyBhIGRpYWwgc3RyaW5nIGluIG9uZS4gIFlv dSBjZXJ0YWlubHkgDQoJPiA+ICAgICA+IGNhbid0IHBhc3Mgb25lIHdpdGggDQoJPiA+ICAgICA+ ICAgICAgID4gPiBzdGFyIGFuZCBwb3VuZC4gICBUaGVyZWZvcmUsIEkgY2xhaW0sIHRoZXJlIGlz IG5vIA0KCT4gPiAgICAgPiB3YXkgdG8gcGFzcyANCgk+ID4gICAgID4gICAgICAgPiA+IGEgZGlh bCBzdHJpbmcgDQoJPiA+ICAgICA+ICAgICAgID4gDQoJPiA+ICAgICA+ICAgICAgID4gQnJpYW4s ICBXaGF0IHBhcnQgb2YgYSBkaWFsIHN0cmluZyBkb2Vzbid0IGZpdCBpbnRvOiANCgk+ID4gICAg ID4gMSpwaG9uZWRpZ2l0ICAgPyANCgk+ID4gICAgID4gICAgICAgPiANCgk+ID4gICAgID4gICAg ICAgPiBwaG9uZWRpZ2l0ID0gIjAiIC8gIjEiIC8gIjIiIC8gIjMiIC8gIjQiIC8gDQoJPiA+ICI1 IiAvICI2IiAvICI3IiAvIA0KCT4gPiAgICAgPiAgICAgICA+ICI4IiAvICI5IiAvIA0KCT4gPiAg ICAgPiAgICAgICA+ICAgICAgICAgICAgICAgIkEiIC8gIkIiIC8gIkMiIC8gIkQiIC8gIkUiIC8g IkYiIA0KCT4gPiAgICAgPiAgICAgICA+IA0KCT4gPiAgICAgPiAgICAgICA+IEUgY29ycmVzcG9u ZHMgdG8gKiAgYW5kIEYgY29ycmVzcG9uZHMgdG8gIyANCgk+ID4gICAgID4gICAgICAgPiANCgk+ ID4gICAgID4gICAgICAgPiB0aGFua3MsIA0KCT4gPiAgICAgPiAgICAgICA+IC1yb2hhbiANCgk+ ID4gICAgID4gICAgICAgPiANCgk+ID4gICAgID4gICAgICAgPiANCgk+ID4gICAgID4gICAgICAg PiA+ICwgdW5sZXNzIHlvdSBwdXQgaXQgaW4gYSB1c2VybmFtZSBvbiBhIFNJUCB1cmksIA0KCT4g PiAgICAgPiAgICAgICA+ID4gYW5kIGRlbm90ZSB0aGF0IGl0IGlzIGEgZGlhbCBzdHJpbmcsIGZv ciB3aGljaCBhIA0KCT4gPiAgICAgPiBwaG9uZSBudW1iZXIgaXMgDQoJPiA+ICAgICA+ICAgICAg ID4gPiBhIHByb3BlciBzdWJzZXQgZm9yIG1vc3QgZGlhbCBwbGFucywgYnkgc3BlY2lmeWluZyAN Cgk+ID4gICAgID4gdXNlcj1waG9uZS4gDQoJPiA+ICAgICA+ICAgICAgID4gPiANCgk+ID4gICAg ID4gICAgICAgPiA+IFBhdWwgZGlzYWdyZWVzLiAgSGUgdGhpbmtzIGhlIGNhbiBzZW5kIGEgZGlh bCANCgk+ID4gICAgID4gc3RyaW5nIGluIGEgdGVsIHVyaS4gDQoJPiA+ICAgICA+ICAgICAgID4g PiBXaXRob3V0IHNvbWUga2luZCBvZiByZXNvbHV0aW9uIG9mIHRoYXQgaXNzdWUsIHdlIA0KCT4g PiAgICAgPiBoYXZlIGEgcHJvYmxlbS4gDQoJPiA+ICAgICA+ICAgICAgID4gPiANCgk+ID4gICAg ID4gICAgICAgPiA+IEJyaWFuIA0KCT4gPiAgICAgPiAgICAgICA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0gDQoJPiA+ICAgICA+ICAgICAgID4gPiBGcm9tOiBGcmFuY29pcyBBdWRldCAN Cgk+ID4gW21haWx0bzphdWRldEBub3J0ZWxuZXR3b3Jrcy5jb21dIA0KCT4gPiAgICAgPiAgICAg ICA+ID4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMDMgMTI6MTAgUE0gDQoJPiA+ICAg ICA+ICAgICAgID4gPiBUbzogJ1BhdWwgS3l6aXZhdCcgDQoJPiA+ICAgICA+ICAgICAgID4gPiBD YzogJ1Jvc2VuLCBCcmlhbic7ICdCb2IgUGVuZmllbGQnOyAnc2lwQGlldGYub3JnJyANCgk+ID4g ICAgID4gICAgICAgPiA+IFN1YmplY3Q6IFJFOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0g DQoJPiA+IHdpdGggO3VzZXI9cGhvbmUgDQoJPiA+ICAgICA+ICAgICAgID4gPiANCgk+ID4gICAg ID4gICAgICAgPiA+IA0KCT4gPiAgICAgPiAgICAgICA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KCT4gPiAgICAgPiAgICAgICA+ID4+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRv OnBreXppdmF0QGNpc2NvLmNvbV0gDQoJPiA+ICAgICA+ICAgICAgID4gPj4gU2VudDogTW9uZGF5 LCBTZXB0ZW1iZXIgMTUsIDIwMDMgMDY6NTggDQoJPiA+ICAgICA+ICAgICAgID4gPj4gVG86IEF1 ZGV0LCBGcmFuY29pcyBbU0MxMDA6NEswMjpFWENIXSANCgk+ID4gICAgID4gICAgICAgPiA+PiBD YzogJ1Jvc2VuLCBCcmlhbic7ICdCb2IgUGVuZmllbGQnOyAnc2lwQGlldGYub3JnJyANCgk+ID4g ICAgID4gICAgICAgPiA+PiBTdWJqZWN0OiBSZTogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVt IA0KCT4gPiB3aXRoIDt1c2VyPXBob25lIA0KCT4gPiAgICAgPiAgICAgICA+ID4gWyBzdHVmZiBk ZWxldGVkIGFzIGl0IGxvb2tzIGxpa2Ugd2UgYXJlIGluIA0KCT4gPiBhZ3JlZW1lbnQgXSANCgk+ ID4gICAgID4gICAgICAgPiA+PiBJJ20gbm90IHN1cmUgYWJvdXQgdGhlICJtb3N0IiBwYXJ0LiBT b21lIGRvLCBzb21lIA0KCT4gPiAgICAgPiBkb24ndC4gQXMgc3BlYyBpcyANCgk+ID4gICAgID4g ICAgICAgPiA+PiBjdXJyZW50bHkgd3JpdHRlbiwgdGhlIGVxdWl2YWxlbmNlIGJldHdlZW4gdGVs IGFuZCANCgk+ID4gICAgID4gICAgICAgPiBzaXAvdXNlcj1waG9uZSBpcyANCgk+ID4gICAgID4g ICAgICAgPiA+PiBvbmx5IG9uZSB3YXkuIChJRiB0aGUgdXNlcnBhcnQgY29tZXMgZnJvbSANCgk+ ID4gYSB0ZWwsIHRoZW4gdGhlcmUgDQoJPiA+ICAgICA+ICAgICAgID4gPj4gU0hPVUxEIGJlIGEg DQoJPiA+ICAgICA+ICAgICAgID4gPj4gdXNlcj1waG9uZSwgYnV0IHRoZSBwcmVzZW5jZSBvZiB1 c2VyPXBob25lIGRvZXMgDQoJPiA+ICAgICA+IG5vdCBpbXBseSB0aGUgDQoJPiA+ICAgICA+ICAg ICAgID4gPj4gdXNlcnBhcnQgDQoJPiA+ICAgICA+ICAgICAgID4gPj4gY29uZm9ybXMgdG8gdGVs LikgDQoJPiA+ICAgICA+ICAgICAgID4gPj4gDQoJPiA+ICAgICA+ICAgICAgID4gPj4gSSBwZXJz b25hbGx5IGFtIGhhcHB5IHdpdGggdGhlIG1vcmUgc3RyaWN0IA0KCT4gPiAgICAgPiBpbnRlcnBy ZXRhdGlvbi4gQnV0IEkgYW0gDQoJPiA+ICAgICA+ICAgICAgID4gPj4gdHJ5aW5nIHRvIGhvbGQg b3V0IGFuIG9saXZlIGJyYW5jaCBpbiBvcmRlciB0byANCgk+ID4gICAgID4gcmVhY2ggYSBsZXZl bCANCgk+ID4gICAgID4gICAgICAgPiA+PiBvZiBhZ3JlZW1lbnQuIA0KCT4gPiAgICAgPiAgICAg ICA+ID4gT0suIEl0IHNlZW1zIHRoYXQgd2UgYXJlIGluIGFncmVlbWVudC4gDQoJPiA+ICAgICA+ ICAgICAgID4gPiBNeSBzdWdnZXN0aW9uIGlzIHRvIGFzayB0aGUgcXVlc3Rpb24gdG8gdGhlIGdy b3VwIA0KCT4gPiAgICAgPiBvZiBpcyBhbnlib2R5IA0KCT4gPiAgICAgPiAgICAgICA+ID4gb2Jq ZWN0cyB0byBtYWtlIGl0IGV4cGxpY2l0IHRoYXQgDQoJPiA+IHVzZXI9cGhvbmVzIG1lYW5zIHRo YXQgdGhlIA0KCT4gPiAgICAgPiAgICAgICA+IHNpcCBVUkkgaXMgDQoJPiA+ICAgICA+ICAgICAg ID4gPiBkZXJpdmVkIA0KCT4gPiAgICAgPiAgICAgICA+ID4gZnJvbSBhIHRlbCBVUkk/IA0KCT4g PiAgICAgPiAgICAgICA+ID4gSWYgdGhlIGFuc3dlciBpcyBubywgdGhlbiBJIHRoaW5rIHdlIGNh biBwcm9iYWJseSANCgk+ID4gICAgID4gZmluYWxseSBwdXQgdGhpcyANCgk+ID4gICAgID4gICAg ICAgPiA+IGlzc3VlIA0KCT4gPiAgICAgPiAgICAgICA+ID4gdG8gcmVzdC4gT3RoZXJ3aXNlLCB3 ZSBuZWVkIHRvIHJld29yayB0aGUgDQoJPiA+IHdob2xlIHRoaW5nLi4uIA0KCT4gPiAgICAgPiAg ICAgICA+ID4gU28uLi4gRG9lcyBhbnlib2R5IHN0cm9uZ2x5IG9iamVjdCB0byANCgk+ID4gZXhw bGljaXRseSBtYWtpbmcgdGhlIA0KCT4gPiAgICAgPiAgICAgICA+IHVzZXI9cGhvbmUgDQoJPiA+ ICAgICA+ICAgICAgID4gPiBhdHR0cmlidXRlIG1lYW4gdGhhdCB0aGUgU0lQIFVSSSB3YXMgDQoJ PiA+IGRlcml2ZWQgZnJvbSBhIHRlbCBVUkk/IA0KCT4gPiAgICAgPiAgICAgICA+ID4+PiBBcHBs eWluZyB0aGUgcnVsZXMgb2YgUkZDMzI2MS8xOS4xLjYgDQoJPiA+IGluc3RlYWQsIHdlJ2QgZ2V0 OiANCgk+ID4gICAgID4gICAgICAgPiA+Pj4gDQoJPiA+ICAgICA+ICAgICAgID4gPj4+IA0KCT4g PiAgICAgPiAgICAgICA+ID4+PiANCgk+ID4gICAgID4gDQoJPiA+IHNpcDoxMjM0O3Bob25lLWNv bnRleHQ9eW91ci1kaWFscGxhbi5mb28uYmFyQGZvby5iYXI7dXNlcj1waG9uZSANCgk+ID4gICAg ID4gICAgICAgPiA+Pj4gDQoJPiA+ICAgICA+ICAgICAgID4gPj4+IFdoaWNoIChsaWtlIHRoZSB0 ZWwgVVJJKSBzcGVjaWZpY2FsbHkgDQoJPiA+IGlkZW50aWZpZXMgdGhlIA0KCT4gPiAgICAgPiAg ICAgICA+ID4+IGRpYWxpbmcgcGxhbiBhbmQgDQoJPiA+ICAgICA+ICAgICAgID4gPj4+IGRvZXMg bm90IHJlcXVpcmUgb25lIEROUyBlbnRyeSBwZXIgZGlhbGxpbmcgcGxhbi4gDQoJPiA+ICAgICA+ ICAgICAgID4gPj4gDQoJPiA+ICAgICA+ICAgICAgID4gPj4gDQoJPiA+ICAgICA+ICAgICAgID4g Pj4gSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYWxzbyBhIGZpbmUgdXNhZ2UuIA0KCT4gPiAgICAgPiAg ICAgICA+ID4+IA0KCT4gPiAgICAgPiAgICAgICA+ID4+IEJ1dCB3aGF0IGlzIGJlbmVmaXQgb2Yg dGhpcyBvdmVyIHVzaW5nIHRoZSANCgk+ID4gdGVsIGZvcm1hdCBhbmQgDQoJPiA+ICAgICA+ICAg ICAgID4gPj4gdGhlbiBwYXNzaW5nIA0KCT4gPiAgICAgPiAgICAgICA+ID4+IHRoZSByZXF1ZXN0 IHRvIHNpcDpmb28uYmFyPyANCgk+ID4gICAgID4gICAgICAgPiA+IFRoZSB0ZWwgVVJJIGZvcm1h dCBhc3N1bWVzIHRoYXQgdGhlIHByb3h5IA0KCT4gPiBrbm93cyB3aGljaCBwcm94eSANCgk+ID4g ICAgID4gICAgICAgPiBpcyBhd2FyZSANCgk+ID4gICAgID4gICAgICAgPiA+IG9mIHRoZSANCgk+ ID4gICAgID4gICAgICAgPiA+IHBob25lIGNvbnRleHQgDQoJPiA+ICAgICA+ICAgICAgID4gPiBh bmQgdGVsIFVSSXMgKGl0IGNvdWxkIGJlIGl0c2VsZiwgb3IgaXQgDQoJPiA+IGNvdWxkIGtub3cg d2hpY2ggDQoJPiA+ICAgICA+ICAgICAgID4gcHJveHkgdG8gcm91dGUgDQoJPiA+ICAgICA+ICAg ICAgID4gPiBzZXNzaW9ucyB0bykuIA0KCT4gPiAgICAgPiAgICAgICA+ID4gVGhlIHNpcCBVUkkg Zm9ybWF0IGxldHMgeW91IHJvdXRlIGl0IHRvIGEgDQoJPiA+IHNwZWNpZmljIHByb3h5IA0KCT4g PiAgICAgPiAgICAgICA+IHRoYXQgaXMgYXdhcmUgDQoJPiA+ICAgICA+ICAgICAgID4gPiBvZiAN Cgk+ID4gICAgID4gICAgICAgPiA+IHRoZSBwaG9uZSANCgk+ID4gICAgID4gICAgICAgPiA+IGNv bnRleHQsIHBvdGVudGlhbGx5IHdpdGggImdlbmVyaWMiIFNJUCANCgk+ID4gcHJveGllcyBpbiBi ZXR3ZWVuIA0KCT4gPiAgICAgPiAgICAgICA+IHRoYXQgaGF2ZSANCgk+ID4gICAgID4gICAgICAg PiA+IG5vIGlkZWEgDQoJPiA+ICAgICA+ICAgICAgID4gPiBob3cgdG8gcm91dGUgDQoJPiA+ICAg ICA+ICAgICAgID4gPiBiYXNlZCBvbiBwaG9uZSBjb250ZXh0ZXMgKG9yIGV2ZW4gdGVsIFVSSXMp LiBUIA0KCT4gPiAgICAgPiAgICAgICA+ID4gDQoJPiA+ICAgICA+ICAgICAgID4gPiANCgk+ID4g ICAgID4gICAgICAgPiA+IFRoZXkgYm90aCBoYXZlIG1lcml0cy4gDQoJPiA+ICAgICA+ICAgICAg ID4gPiANCgk+ID4gICAgID4gICAgICAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIA0KCT4gPiAgICAgPiAgICAgICA+ID4gU2lwIG1haWxpbmcgbGlz dCAgDQoJPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcCANCgk+ ID4gICAgID4gICAgICAgPiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRo ZSANCgk+ID4gY29yZSBTSVAgUHJvdG9jb2wgDQoJPiA+ICAgICA+ICAgICAgID4gPiBVc2Ugc2lw LWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyANCgk+ID4gICAgID4g b24gY3VycmVudCBzaXAgDQoJPiA+ICAgICA+ICAgICAgID4gPiBVc2Ugc2lwcGluZ0BpZXRmLm9y ZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgDQoJPiA+ICAgICA+IGFwcGxpY2F0aW9uIG9m IHNpcCANCgk+ID4gICAgID4gICAgICAgPiANCgk+ID4gICAgID4gICAgICANCgk+ID4gICAgID4g ICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoJ PiA+ICAgICA+ICAgICAgIFNpcCBtYWlsaW5nIGxpc3QgIA0KCT4gPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAgDQoJPiA+ICAgICA+ICAgICAgIFRoaXMgbGlzdCBp cyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIA0KCT4gPiBTSVAgUHJvdG9jb2wgDQoJ PiA+ICAgICA+ICAgICAgIFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3Ig cXVlc3Rpb25zIG9uIA0KCT4gPiAgICAgPiBjdXJyZW50IHNpcCANCgk+ID4gICAgID4gICAgICAg VXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIA0KCT4gPiAg ICAgPiBhcHBsaWNhdGlvbiBvZiBzaXAgDQoJPiA+ICAgICA+ICAgICAgDQoJPiA+ICAgICA+IA0K CT4gPiAgICAgPiANCgk+ID4gICAgIA0KCT4gPiANCgk+ID4gDQoJPiANCg0K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Sep 21 09:36:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26139 for ; Sun, 21 Sep 2003 09:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14Ns-0007g3-65 for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 09:36:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LDaGKi029510 for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 09:36:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14Nf-0007eC-8a; Sun, 21 Sep 2003 09:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14N4-0007dC-8e for sip@optimus.ietf.org; Sun, 21 Sep 2003 09:35:31 -0400 Received: from octopussy.utanet.at (octopussy.utanet.at [213.90.36.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26080 for ; Sun, 21 Sep 2003 09:35:12 -0400 (EDT) Received: from paris.utanet.at ([213.90.36.7]) by octopussy.utanet.at with esmtp (Exim 4.12) id 1A14LD-0005H6-00; Sun, 21 Sep 2003 15:33:31 +0200 Received: from suedu1-224-8.utaonline.at ([212.152.224.8] helo=homepc) by paris.utanet.at with esmtp (Exim 4.12) id 1A14LC-0003Uo-00; Sun, 21 Sep 2003 15:33:31 +0200 Reply-To: From: "Franz Edler" To: "'Karunakara Rao'" , Subject: RE: [Sip] forking proxies Date: Sun, 21 Sep 2003 15:33:13 +0200 Organization: private MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5329 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcN/geg4Ya0doa/VRpqTCdBEH5pDKAAwuyMg In-Reply-To: <20030919053617.9491.qmail@webmail32.rediffmail.com> Message-Id: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Karunkar, let me try to answer your question, at least some aspects. If the forking proxy has already forwarded a 200 OK response, all other = 1xx responses (regardless if reliable or not) will be blocked by the forking proxy, because after a final response has been sent, the forking proxy = only forwards 2xx responses. All other responses are "worse" compared to the already existing 200 OK response. All early dialogs are terminating "silently" after 64*T1 without any = message exchange (see =A713.2.2 last but one paragraph). This is also the limit = for any other 2xx response to be forwarded. After this time, the UAC = considers the INVITE transaction to be completed. I hope this helps. Franz -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Karunakara Rao Sent: Freitag, 19. September 2003 07:36 To: sip@ietf.org Subject: [Sip] forking proxies Hi All, I am new to this group. a doubt regarding forking proxies, why would a proxy do if forked an INVITE request, it got back some=20 reliable provisional responses that established some early dialogs=20 at the UAC, and then one of the UAS's sends a final response 200=20 oK. If the other early dialogs try to send further reliable=20 provisional responses this wont get through the proxy since a=20 final response was already sent on the response context. Should=20 the proxy behaviour not only forward immediately 200ok responses=20 to INVITE, but also reliable responses ? What happened to other early dialogs? how about sending CANCEL=20 request to them which has not received final 200 OK. how to close=20 those dialogs any policy can be adopted. thanks Karunakar. ___________________________________________________ Art meets Anesthesia; Shefali Weds Dr. Raman. Rediff Matchmaker strikes another interesting match !! Visit http://matchmaker.rediff.com?1 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Sep 21 13:20:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02350 for ; Sun, 21 Sep 2003 13:20:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A17sp-0002Ab-4z for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 13:20:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LHKRse008340 for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 13:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A17sR-00029c-GS; Sun, 21 Sep 2003 13:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A17ru-00022O-3B for sip@optimus.ietf.org; Sun, 21 Sep 2003 13:19:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02302 for ; Sun, 21 Sep 2003 13:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A17rp-0004vj-00 for sip@ietf.org; Sun, 21 Sep 2003 13:19:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A17rV-0004vA-00 for sip@ietf.org; Sun, 21 Sep 2003 13:19:05 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2003 10:18:39 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8LHH7xW017644; Sun, 21 Sep 2003 10:17:08 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn4-826.cisco.com [10.21.83.57]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AII34550; Sun, 21 Sep 2003 10:17:05 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 20 Sep 2003 19:12:36 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Brian Rosen , "'Rohan Mahy'" CC: "'Francois Audet'" , Paul Kyzivat , Bob Penfield , "'sip@ietf.org'" Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5EC1@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think dial strings were left out of scope in 2806bis partially due to the lack of any consensus on them. This thread and others seem to support that conclusion. Cullen On 9/19/03 6:17, "Rosen, Brian" wrote: > I've never seen E/F substitution for */#, and I've never seen any > sip device that did it, but it's a possible way forward. > > I do think that some RFC would have to change the wording of > 2806bis to allow dial strings. The authors seemed to explicitly > declare them out of scope of the document. Generally, we don't > usually claim "that which is not specifically disallowed is legal" > as a way around "out of scope" wording in our documents. > > I remain unhappy that dial strings, untranslated phone numbers > and translated phone numbers are indistinguishable. They are different, > they are handled differently, and they should be distinguishable. > I don't understand why some people are so adamant that they should all > be represented in EXACTLY the same way (tel uri or sip uri with > or without user=phone). They are not the same things, and they > should have distinctive representations. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, September 18, 2003 9:17 PM >> To: Rosen, Brian >> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 'sip@ietf.org' >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >> >> >> On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote: >>> Well this goes to the issue Paul and I have disagreed on. >>> >>> I think the wording of the tel uri RFC is quite clear that you >>> can't pass a dial string in one. You certainly can't pass one with >>> star and pound. Therefore, I claim, there is no way to pass >>> a dial string >> >> Brian, What part of a dial string doesn't fit into: 1*phonedigit ? >> >> phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / >> "8" / "9" / >> "A" / "B" / "C" / "D" / "E" / "F" >> >> E corresponds to * and F corresponds to # >> >> thanks, >> -rohan >> >> >>> , unless you put it in a username on a SIP uri, >>> and denote that it is a dial string, for which a phone number is >>> a proper subset for most dial plans, by specifying user=phone. >>> >>> Paul disagrees. He thinks he can send a dial string in a tel uri. >>> Without some kind of resolution of that issue, we have a problem. >>> >>> Brian >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortelnetworks.com] >>> Sent: Monday, September 15, 2003 12:10 PM >>> To: 'Paul Kyzivat' >>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, September 15, 2003 06:58 >>>> To: Audet, Francois [SC100:4K02:EXCH] >>>> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone >>> [ stuff deleted as it looks like we are in agreement ] >>>> I'm not sure about the "most" part. Some do, some don't. As spec is >>>> currently written, the equivalence between tel and >> sip/user=phone is >>>> only one way. (IF the userpart comes from a tel, then there >>>> SHOULD be a >>>> user=phone, but the presence of user=phone does not imply the >>>> userpart >>>> conforms to tel.) >>>> >>>> I personally am happy with the more strict interpretation. But I am >>>> trying to hold out an olive branch in order to reach a level >>>> of agreement. >>> OK. It seems that we are in agreement. >>> My suggestion is to ask the question to the group of is anybody >>> objects to make it explicit that user=phones means that the >> sip URI is >>> derived >>> from a tel URI? >>> If the answer is no, then I think we can probably finally put this >>> issue >>> to rest. Otherwise, we need to rework the whole thing... >>> So... Does anybody strongly object to explicitly making the >> user=phone >>> atttribute mean that the SIP URI was derived from a tel URI? >>>>> Applying the rules of RFC3261/19.1.6 instead, we'd get: >>>>> >>>>> >>>>> sip:1234;phone-context=your-dialplan.foo.bar@foo.bar;user=phone >>>>> >>>>> Which (like the tel URI) specifically identifies the >>>> dialing plan and >>>>> does not require one DNS entry per dialling plan. >>>> >>>> >>>> I agree that this is also a fine usage. >>>> >>>> But what is benefit of this over using the tel format and >>>> then passing >>>> the request to sip:foo.bar? >>> The tel URI format assumes that the proxy knows which proxy >> is aware >>> of the >>> phone context >>> and tel URIs (it could be itself, or it could know which >> proxy to route >>> sessions to). >>> The sip URI format lets you route it to a specific proxy >> that is aware >>> of >>> the phone >>> context, potentially with "generic" SIP proxies in between >> that have >>> no idea >>> how to route >>> based on phone contextes (or even tel URIs). T >>> >>> >>> They both have merits. >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Sep 21 15:51:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06224 for ; Sun, 21 Sep 2003 15:51:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1AEg-00088J-3a for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 15:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LJp9RE031203 for sip-archive@odin.ietf.org; Sun, 21 Sep 2003 15:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1AEY-00086h-5b; Sun, 21 Sep 2003 15:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ADn-00085u-UE for sip@optimus.ietf.org; Sun, 21 Sep 2003 15:50:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06177 for ; Sun, 21 Sep 2003 15:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ADj-00062k-00 for sip@ietf.org; Sun, 21 Sep 2003 15:50:11 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1ADR-000625-00 for sip@ietf.org; Sun, 21 Sep 2003 15:49:53 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2003 12:50:17 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8LJmiHm003035; Sun, 21 Sep 2003 12:48:45 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn3-220.cisco.com [10.21.64.220]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AII36759; Sun, 21 Sep 2003 12:48:42 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 21 Sep 2003 12:22:24 -0700 Subject: Re: [Sip] npi=,ton= tag values for SIP to QSIG mapping From: Cullen Jennings To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There has been some work done using the tel URL for this sort of stuff in SIP. You might want to have a look at http://www.softarmor.com/iptel/drafts/draft-yu-tel-url-07.txt Cullen On 9/19/03 10:23, "Cibu.Johny@utstar.com" wrote: > > Hi, > > What are the possible values for npi= and ton= tag values in the INVITE > Request-URI header in order to map QSIG NPI & TON numbers? Is there any > draft available for this? I searched quite a bit, but failed to get any > draft or example from the web. Help really appreciated. > > -thanks, > Cibu > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 22 03:39:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04532 for ; Mon, 22 Sep 2003 03:39:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1LHz-0004On-61 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 03:39:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M7dJX8016908 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 03:39:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1LHi-0004Nw-En; Mon, 22 Sep 2003 03:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ihi-0006f7-Ha for sip@optimus.ietf.org; Sat, 20 Sep 2003 10:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20514 for ; Fri, 19 Sep 2003 16:12:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0RcL-0000u5-00 for sip@ietf.org; Fri, 19 Sep 2003 16:12:37 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A0RcA-0000tU-00 for sip@ietf.org; Fri, 19 Sep 2003 16:12:26 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JKBYk21807; Fri, 19 Sep 2003 13:11:34 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 13:11:35 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B04B841@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rosen, Brian'" , "'Stastny Richard'" , "'Rohan Mahy'" Cc: "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 19 Sep 2003 13:11:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EEA.38FC5E7A" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EEA.38FC5E7A Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable If the proxy knows that "phone-context=3Ddial-digit-us.marconi.com" for example means a dial plan, then it would know it is a dial digit string (like from a dumb phone). If instead it says = "phone-context=3Dglobal.marconi.com" (for example), then it would know it is a Marconi private NUMBER (like = from a PBX gateway). > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Sent: Friday, September 19, 2003 13:02 > To: 'Stastny Richard'; Rohan Mahy > Cc: Audet, Francois [SC100:4K02:EXCH]; Paul Kyzivat; Bob=20 > Penfield; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Richard >=20 > A user at a dumb phone always enters a dial string. > No argument. >=20 > However, at some point, either a UA translates a dial string > to a phone number, or a downstream proxy does it. At that=20 > point it isn't a dial string, it's a phone number, and it=20 > might be in a context (it could be global). What I've=20 > mentioned is a case, which I think is pretty common, where=20 > the number is not represented the same way as a dial string=20 > and a phone number, and yet is in the same domain. >=20 > Let's take a practical example. Suppose I have a domain with > a reasonably smart proxy server and a mix of phones. Some=20 > phones have dialstring translation, some don't. The proxy=20 > server can translate dial strings to phone numbers, and it=20 > also can route phone numbers. Obviously it can do both (ie=20 > translate then route). >=20 > Now, how does the proxy know if it needs to translate? That=20 > is, how does it know that a uri passed to it is a dial string=20 > vs a phone number? If I pass it a phone number and it=20 > decides to apply it's dialstring processing, that will fail. =20 > If I pass a=20 > dial string and it just routes, that will fail. It has to=20 > know what it is given. In my example it was=20 > 7246826@pit.sip.marconi.com That's a phone number, and a dial=20 > string, but it's two different destinations. In my numbering=20 > plan, it's my phone. In my dialing plan it's an extension in=20 > another office. >=20 > Brian >=20 > Brian >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, September 19, 2003 3:33 PM > > To: Rosen, Brian; Rohan Mahy > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > > Brian, > > =20 > > If you pick up a phone and enter digits, it ALWAYS a dialing string = > > and you are ALWAYS in ONE and ONLY ONE dialing plan.. > > =20 > > You never enter a phone number directly, you always > > dial (if you dial a local number, the mapping may be 1:1) > > =20 > > So if you enter a dial string in a SIP phone and iu sends > > it with nnnn@default.com to your defaulr sip server, this=20 > server then=20 > > evaluates the dialing plan and translates it to a numbering plan. > > =20 > > Btw, thats exactly how fwd, iptel sipphone, ... are implemeted. > > =20 > > Richard > >=20 > > -----Urspr=FCngliche Nachricht-----=20 > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > > Gesendet: Fr 19.09.2003 19:37=20 > > An: Stastny Richard; Rohan Mahy=20 > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org=20 > > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > =09 > > =09 > >=20 > > Richard > > =09 > > My phone number within my local domain is 742-6826. > > I could change the convention and make it 724-742-6826 or > > 1-724-742-6826 if you want. > > =09 > > My dial plan would send a call to a different phone if you > > dialed any of those strings. > > =09 > > If you send an INVITE 7426826@pit.sip.marconi.com it will ring > > my sipphone. > > =09 > > If I dial 7426826, it won't ring my sip phone. I have to dial > > 6826 or 9-742-6826 or even 300-6826. > > =09 > > Using your algorithm, I would assume 7426826 was a dial string, > > and that would be wrong. > > =09 > > Brian > > =09 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, September 19, 2003 1:24 PM > > > To: Rosen, Brian; Rohan Mahy > > > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org > > > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > > > > > > > > See below > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Gesendet: Fr 19.09.2003 15:17 > > > An: 'Rohan Mahy' > > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; > > > 'sip@ietf.org' > > > Betreff: RE: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > > =20 > > > =20 > > > > > > I've never seen E/F substitution for */#, and I've > > > never seen any > > > sip device that did it, but it's a possible way forward. > > > =20 > > > I do think that some RFC would have to change=20 > > the wording of > > > 2806bis to allow dial strings. The authors=20 > > seemed to explicitly > > > declare them out of scope of the document. =20 > > Generally, we don't > > > usually claim "that which is not specifically > > > disallowed is legal" > > > as a way around "out of scope" wording in our documents. > > > =20 > > > I remain unhappy that dial strings,=20 > > untranslated phone numbers > > > and translated phone numbers are indistinguishable.=20 > > > They are different, > > > they are handled differently, and they should be > > > distinguishable. > > > I don't understand why some people are so adamant that > > > they should all > > > be represented in EXACTLY the same way (tel uri=20 > > or sip uri with > > > or without user=3Dphone). They are not the same=20 > > things, and they > > > should have distinctive representations. > > > > > > Richard: A string of digits is a string of digits. > > > > > > The simplest way to distinguish is: > > > > > > 1. If you just see a string of digits, you have to assume its > > > a dial string > > > > > > until you know better. > > > > > > 2. If you analysed the digits and found out its an E.164 > > > number, normalise it > > > > > > to tel:+xxxx, or sip:+xxxx@foo.bar > > > > > > 3. If you analysed it and found out it is a local > > number, then either > > > > > > use tel:xxxx; phone-context=3Dfoo.bar or=20 > > sip:xxx@foo.bar;user=3Dphone > > > > > > I do not understand the problem > > > > > > Richard > > > > > > =20 > > > =20 > > > Brian > > > =20 > > > > -----Original Message----- > > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > > Sent: Thursday, September 18, 2003 9:17 PM > > > > To: Rosen, Brian > > > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; > > > 'sip@ietf.org' > > > > Subject: Re: [Sip] SIPIT Interop problem with=20 > > ;user=3Dphone > > > > > > > > > > > > On Monday, September 15, 2003, at 10:23 AM, Rosen, > > > Brian wrote: > > > > > Well this goes to the issue Paul and I have=20 > > disagreed on. > > > > > > > > > > I think the wording of the tel uri RFC is quite > > > clear that you > > > > > can't pass a dial string in one. You certainly > > > can't pass one with > > > > > star and pound. Therefore, I claim, there is no > > > way to pass > > > > > a dial string > > > > > > > > Brian, What part of a dial string doesn't fit into: > > > 1*phonedigit ? > > > > > > > > phonedigit =3D "0" / "1" / "2" / "3" / "4" /=20 > > "5" / "6" / "7" / > > > > "8" / "9" / > > > > "A" / "B" / "C" / "D" / "E" / "F" > > > > > > > > E corresponds to * and F corresponds to # > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > > , unless you put it in a username on a SIP uri, > > > > > and denote that it is a dial string, for which a > > > phone number is > > > > > a proper subset for most dial plans, by specifying > > > user=3Dphone. > > > > > > > > > > Paul disagrees. He thinks he can send a dial > > > string in a tel uri. > > > > > Without some kind of resolution of that issue, we > > > have a problem. > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Francois Audet=20 > > [mailto:audet@nortelnetworks.com] > > > > > Sent: Monday, September 15, 2003 12:10 PM > > > > > To: 'Paul Kyzivat' > > > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > > > Subject: RE: [Sip] SIPIT Interop problem=20 > > with ;user=3Dphone > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Monday, September 15, 2003 06:58 > > > > >> To: Audet, Francois [SC100:4K02:EXCH] > > > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' > > > > >> Subject: Re: [Sip] SIPIT Interop problem=20 > > with ;user=3Dphone > > > > > [ stuff deleted as it looks like we are in=20 > > agreement ] > > > > >> I'm not sure about the "most" part. Some do, some > > > don't. As spec is > > > > >> currently written, the equivalence between tel and > > > > sip/user=3Dphone is > > > > >> only one way. (IF the userpart comes from=20 > > a tel, then there > > > > >> SHOULD be a > > > > >> user=3Dphone, but the presence of user=3Dphone does > > > not imply the > > > > >> userpart > > > > >> conforms to tel.) > > > > >> > > > > >> I personally am happy with the more strict > > > interpretation. But I am > > > > >> trying to hold out an olive branch in order to > > > reach a level > > > > >> of agreement. > > > > > OK. It seems that we are in agreement. > > > > > My suggestion is to ask the question to the group > > > of is anybody > > > > > objects to make it explicit that=20 > > user=3Dphones means that the > > > > sip URI is > > > > > derived > > > > > from a tel URI? > > > > > If the answer is no, then I think we can probably > > > finally put this > > > > > issue > > > > > to rest. Otherwise, we need to rework the=20 > > whole thing... > > > > > So... Does anybody strongly object to=20 > > explicitly making the > > > > user=3Dphone > > > > > atttribute mean that the SIP URI was=20 > > derived from a tel URI? > > > > >>> Applying the rules of RFC3261/19.1.6=20 > > instead, we'd get: > > > > >>> > > > > >>> > > > > >>> > > >=20 > > sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone > > > > >>> > > > > >>> Which (like the tel URI) specifically=20 > > identifies the > > > > >> dialing plan and > > > > >>> does not require one DNS entry per dialling plan. > > > > >> > > > > >> > > > > >> I agree that this is also a fine usage. > > > > >> > > > > >> But what is benefit of this over using the=20 > > tel format and > > > > >> then passing > > > > >> the request to sip:foo.bar? > > > > > The tel URI format assumes that the proxy=20 > > knows which proxy > > > > is aware > > > > > of the > > > > > phone context > > > > > and tel URIs (it could be itself, or it=20 > > could know which > > > > proxy to route > > > > > sessions to). > > > > > The sip URI format lets you route it to a=20 > > specific proxy > > > > that is aware > > > > > of > > > > > the phone > > > > > context, potentially with "generic" SIP=20 > > proxies in between > > > > that have > > > > > no idea > > > > > how to route > > > > > based on phone contextes (or even tel URIs). T > > > > > > > > > > > > > > > They both have merits. > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list =20 > > https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the=20 > > core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > =20 > > > _______________________________________________ > > > Sip mailing list =20 > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core=20 > > SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on > > > current sip > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > =20 > > > > > > > > =09 > >=20 > >=20 >=20 ------_=_NextPart_001_01C37EEA.38FC5E7A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] SIPIT Interop problem with ;user=3Dphone

If the proxy knows that = "phone-context=3Ddial-digit-us.marconi.com" for = example
means a dial plan, then it would know it is a dial = digit string (like
from a dumb phone). If instead it says = "phone-context=3Dglobal.marconi.com" (for example), then it = would know it is a Marconi private NUMBER (like from

a PBX gateway).

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, September 19, 2003 13:02
> To: 'Stastny Richard'; Rohan Mahy
> Cc: Audet, Francois [SC100:4K02:EXCH]; Paul = Kyzivat; Bob
> Penfield; sip@ietf.org
> Subject: RE: [Sip] SIPIT Interop problem with = ;user=3Dphone
>
>
> Richard
>
> A user at a dumb phone always enters a dial = string.
> No argument.
>
> However, at some point, either a UA translates = a dial string
> to a phone number, or a downstream proxy does = it.  At that
> point it isn't a dial string, it's a phone = number, and it
> might be in a context (it could be = global).  What I've
> mentioned is a case, which I think is pretty = common, where
> the number is not represented the same way as a = dial string
> and a phone number, and yet is in the same = domain.
>
> Let's take a practical example.  Suppose I = have a domain with
> a reasonably smart proxy server and a mix of = phones.  Some
> phones have dialstring translation, some = don't.  The proxy
> server can translate dial strings to phone = numbers, and it
> also can route phone numbers.  Obviously = it can do both (ie
> translate then route).
>
> Now, how does the proxy know if it needs to = translate?  That
> is, how does it know that a uri passed to it is = a dial string
> vs a phone number?  If I pass it a phone = number and it
> decides to apply it's dialstring processing, = that will fail. 
> If I pass a
> dial string and it just routes, that will = fail.  It has to
> know what it is given.  In my example it = was
> 7246826@pit.sip.marconi.com That's a phone = number, and a dial
> string, but it's two different = destinations.  In my numbering
> plan, it's my phone.  In my dialing plan = it's an extension in
> another office.
>
> Brian
>
> Brian
>
> > -----Original Message-----
> > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at= ]
> > Sent: Friday, September 19, 2003 3:33 = PM
> > To: Rosen, Brian; Rohan Mahy
> > Cc: Francois Audet; Paul Kyzivat; Bob = Penfield; sip@ietf.org
> > Subject: AW: [Sip] SIPIT Interop problem = with ;user=3Dphone
> >
> >
> > Brian,
> > 
> > If you pick up a phone and enter digits, = it ALWAYS a dialing string
> > and you are ALWAYS in ONE and ONLY ONE = dialing plan..
> > 
> > You never enter a phone number directly, = you always
> > dial (if you dial a local number, the = mapping may be 1:1)
> > 
> > So if you enter a dial string in a SIP = phone and iu sends
> > it with nnnn@default.com to your defaulr = sip server, this
> server then
> > evaluates the dialing plan and translates = it to a numbering plan.
> > 
> > Btw, thats exactly how fwd, iptel = sipphone, ... are implemeted.
> > 
> > Richard
> >
> >     -----Urspr=FCngliche = Nachricht-----
> >     Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >     Gesendet: Fr 19.09.2003 = 19:37
> >     An: Stastny Richard; = Rohan Mahy
> >     Cc: Francois Audet; = Paul Kyzivat; Bob Penfield; sip@ietf.org
> >     Betreff: RE: [Sip] = SIPIT Interop problem with ;user=3Dphone
> >    
> >    
> >
> >     Richard
> >    
> >     My phone number within = my local domain is 742-6826.
> >     I could change the = convention and make it 724-742-6826 or
> >     1-724-742-6826 if you = want.
> >    
> >     My dial plan would send = a call to a different phone if you
> >     dialed any of those = strings.
> >    
> >     If you send an INVITE = 7426826@pit.sip.marconi.com it will ring
> >     my sipphone.
> >    
> >     If I dial 7426826, it = won't ring my sip phone.  I have to dial
> >     6826 or = 9-742-6826  or even 300-6826.
> >    
> >     Using your algorithm, I = would assume 7426826 was a dial string,
> >     and that would be = wrong.
> >    
> >     Brian
> >    
> >     > -----Original = Message-----
> >     > From: Stastny = Richard [mailto:Richard.Stastny@oefeg.at= ]
> >     > Sent: Friday, = September 19, 2003 1:24 PM
> >     > To: Rosen, Brian; = Rohan Mahy
> >     > Cc: Francois = Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org
> >     > Subject: AW: [Sip] = SIPIT Interop problem with ;user=3Dphone
> >     >
> >     >
> >     > See below
> >     >
> >     = >       -----Urspr=FCngliche = Nachricht-----
> >     = >       Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >     = >       Gesendet: Fr 19.09.2003 = 15:17
> >     = >       An: 'Rohan Mahy'
> >     = >       Cc: 'Francois Audet'; 'Paul = Kyzivat'; 'Bob Penfield';
> >     > = 'sip@ietf.org'
> >     = >       Betreff: RE: [Sip] SIPIT = Interop problem with
> > ;user=3Dphone
> >     = >     
> >     = >     
> >     >
> >     = >       I've never seen E/F = substitution for */#, and I've
> >     > never seen = any
> >     = >       sip device that did it, but = it's a possible way forward.
> >     = >     
> >     = >       I do think that some RFC would = have to change
> > the wording of
> >     = >       2806bis to allow dial = strings.  The authors
> > seemed to explicitly
> >     = >       declare them out of scope of = the document. 
> > Generally, we don't
> >     = >       usually claim "that which = is not specifically
> >     > disallowed is = legal"
> >     = >       as a way around "out of = scope" wording in our documents.
> >     = >     
> >     = >       I remain unhappy that dial = strings,
> > untranslated phone numbers
> >     = >       and translated phone numbers = are indistinguishable.
> >     > They are = different,
> >     = >       they are handled differently, = and they should be
> >     > = distinguishable.
> >     = >       I don't understand why some = people are so adamant that
> >     > they should = all
> >     = >       be represented in EXACTLY the = same way (tel uri
> > or sip uri with
> >     = >       or without = user=3Dphone).  They are not the same
> > things, and they
> >     = >       should have distinctive = representations.
> >     >
> >     > Richard: A string = of digits is a string of digits.
> >     >
> >     > The simplest way = to distinguish is:
> >     >
> >     > 1. If you just see = a string of digits, you have to assume its
> >     > a dial = string
> >     >
> >     > until you know = better.
> >     >
> >     > 2. If you analysed = the digits and found out its an E.164
> >     > number, normalise = it
> >     >
> >     > to tel:+xxxx, or = sip:+xxxx@foo.bar
> >     >
> >     > 3. If you analysed = it and found out it is a local
> > number, then either
> >     >
> >     > use tel:xxxx; = phone-context=3Dfoo.bar or
> > sip:xxx@foo.bar;user=3Dphone
> >     >
> >     > I do not = understand the problem
> >     >
> >     > Richard
> >     >
> >     = >     
> >     = >     
> >     = >       Brian
> >     = >     
> >     = >       > -----Original = Message-----
> >     = >       > From: Rohan Mahy [mailto:rohan@cisco.com]
> >     = >       > Sent: Thursday, September = 18, 2003 9:17 PM
> >     = >       > To: Rosen, Brian
> >     = >       > Cc: 'Francois Audet'; = 'Paul Kyzivat'; 'Bob Penfield';
> >     > = 'sip@ietf.org'
> >     = >       > Subject: Re: [Sip] SIPIT = Interop problem with
> > ;user=3Dphone
> >     = >       >
> >     = >       >
> >     = >       > On Monday, September 15, = 2003, at 10:23 AM, Rosen,
> >     > Brian = wrote:
> >     = >       > > Well this goes to = the issue Paul and I have
> > disagreed on.
> >     = >       > >
> >     = >       > > I think the wording = of the tel uri RFC is quite
> >     > clear that = you
> >     = >       > > can't pass a dial = string in one.  You certainly
> >     > can't pass one = with
> >     = >       > > star and = pound.   Therefore, I claim, there is no
> >     > way to pass
> >     = >       > > a dial string
> >     = >       >
> >     = >       > Brian,  What part of = a dial string doesn't fit into:
> >     > = 1*phonedigit   ?
> >     = >       >
> >     = >       > phonedigit =3D = "0" / "1" / "2" / "3" / = "4" /
> > "5" / "6" / = "7" /
> >     = >       > "8" / = "9" /
> >     = >       = >           &n= bsp;   "A" / "B" / "C" / = "D" / "E" / "F"
> >     = >       >
> >     = >       > E corresponds to *  = and F corresponds to #
> >     = >       >
> >     = >       > thanks,
> >     = >       > -rohan
> >     = >       >
> >     = >       >
> >     = >       > > , unless you put it = in a username on a SIP uri,
> >     = >       > > and denote that it = is a dial string, for which a
> >     > phone number = is
> >     = >       > > a proper subset for = most dial plans, by specifying
> >     > = user=3Dphone.
> >     = >       > >
> >     = >       > > Paul = disagrees.  He thinks he can send a dial
> >     > string in a tel = uri.
> >     = >       > > Without some kind of = resolution of that issue, we
> >     > have a = problem.
> >     = >       > >
> >     = >       > > Brian
> >     = >       > > -----Original = Message-----
> >     = >       > > From: Francois Audet =
> > [mailto:audet@nortelnetworks.com= ]
> >     = >       > > Sent: Monday, = September 15, 2003 12:10 PM
> >     = >       > > To: 'Paul = Kyzivat'
> >     = >       > > Cc: 'Rosen, Brian'; = 'Bob Penfield'; 'sip@ietf.org'
> >     = >       > > Subject: RE: [Sip] = SIPIT Interop problem
> > with ;user=3Dphone
> >     = >       > >
> >     = >       > >
> >     = >       > >> -----Original = Message-----
> >     = >       > >> From: Paul = Kyzivat [mailto:pkyzivat@cisco.com]=
> >     = >       > >> Sent: Monday, = September 15, 2003 06:58
> >     = >       > >> To: Audet, = Francois [SC100:4K02:EXCH]
> >     = >       > >> Cc: 'Rosen, = Brian'; 'Bob Penfield'; 'sip@ietf.org'
> >     = >       > >> Subject: Re: = [Sip] SIPIT Interop problem
> > with ;user=3Dphone
> >     = >       > > [ stuff deleted as = it looks like we are in
> > agreement ]
> >     = >       > >> I'm not sure = about the "most" part. Some do, some
> >     > don't. As spec = is
> >     = >       > >> currently = written, the equivalence between tel and
> >     = >       > sip/user=3Dphone = is
> >     = >       > >> only one way. = (IF the userpart comes from
> > a tel, then there
> >     = >       > >> SHOULD be = a
> >     = >       > >> user=3Dphone, = but the presence of user=3Dphone does
> >     > not imply = the
> >     = >       > >> userpart
> >     = >       > >> conforms to = tel.)
> >     = >       > >>
> >     = >       > >> I personally am = happy with the more strict
> >     > interpretation. = But I am
> >     = >       > >> trying to hold = out an olive branch in order to
> >     > reach a = level
> >     = >       > >> of = agreement.
> >     = >       > > OK. It seems that we = are in agreement.
> >     = >       > > My suggestion is to = ask the question to the group
> >     > of is = anybody
> >     = >       > > objects to make it = explicit that
> > user=3Dphones means that the
> >     = >       > sip URI is
> >     = >       > > derived
> >     = >       > > from a tel = URI?
> >     = >       > > If the answer is no, = then I think we can probably
> >     > finally put = this
> >     = >       > > issue
> >     = >       > > to rest. Otherwise, = we need to rework the
> > whole thing...
> >     = >       > > So... Does anybody = strongly object to
> > explicitly making the
> >     = >       > user=3Dphone
> >     = >       > > atttribute mean that = the SIP URI was
> > derived from a tel URI?
> >     = >       > >>> Applying the = rules of RFC3261/19.1.6
> > instead, we'd get:
> >     = >       > >>>
> >     = >       > >>>
> >     = >       > >>>
> >     >
> > = sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone
> >     = >       > >>>
> >     = >       > >>> Which (like = the tel URI) specifically
> > identifies the
> >     = >       > >> dialing plan = and
> >     = >       > >>> does not = require one DNS entry per dialling plan.
> >     = >       > >>
> >     = >       > >>
> >     = >       > >> I agree that = this is also a fine usage.
> >     = >       > >>
> >     = >       > >> But what is = benefit of this over using the
> > tel format and
> >     = >       > >> then = passing
> >     = >       > >> the request to = sip:foo.bar?
> >     = >       > > The tel URI format = assumes that the proxy
> > knows which proxy
> >     = >       > is aware
> >     = >       > > of the
> >     = >       > > phone context
> >     = >       > > and tel URIs (it = could be itself, or it
> > could know which
> >     = >       > proxy to route
> >     = >       > > sessions to).
> >     = >       > > The sip URI format = lets you route it to a
> > specific proxy
> >     = >       > that is aware
> >     = >       > > of
> >     = >       > > the phone
> >     = >       > > context, potentially = with "generic" SIP
> > proxies in between
> >     = >       > that have
> >     = >       > > no idea
> >     = >       > > how to route
> >     = >       > > based on phone = contextes (or even tel URIs). T
> >     = >       > >
> >     = >       > >
> >     = >       > > They both have = merits.
> >     = >       > >
> >     = >       > > = _______________________________________________
> >     = >       > > Sip mailing = list 
> > https://www1.ietf.org/mailman/listinfo/sip
> >     = >       > > This list is for NEW = development of the
> > core SIP Protocol
> >     = >       > > Use = sip-implementors@cs.columbia.edu for questions
> >     > on current = sip
> >     = >       > > Use sipping@ietf.org = for new developments on the
> >     > application of = sip
> >     = >       >
> >     = >     
> >     = >       = _______________________________________________
> >     = >       Sip mailing list 
> > https://www1.ietf.org/mailman/listinfo/sip
> >     = >       This list is for NEW = development of the core
> > SIP Protocol
> >     = >       Use = sip-implementors@cs.columbia.edu for questions on
> >     > current sip
> >     = >       Use sipping@ietf.org for new = developments on the
> >     > application of = sip
> >     = >     
> >     >
> >     >
> >    
> >
> >
>

------_=_NextPart_001_01C37EEA.38FC5E7A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 22 10:19:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16820 for ; Mon, 22 Sep 2003 10:19:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RXG-0005YY-Sg for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 10:19:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEJUEH021354 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 10:19:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RWo-0005XR-KP; Mon, 22 Sep 2003 10:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RWX-0005W8-8g for sip@optimus.ietf.org; Mon, 22 Sep 2003 10:18:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16762 for ; Mon, 22 Sep 2003 10:18:30 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1RWP-0007XT-00 for sip@ietf.org; Mon, 22 Sep 2003 10:18:37 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1RWE-0007Vm-00 for sip@ietf.org; Mon, 22 Sep 2003 10:18:26 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MEGV623139 for ; Mon, 22 Sep 2003 17:16:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 17:16:31 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 17:16:29 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 17:16:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Date: Mon, 22 Sep 2003 17:16:29 +0300 Message-ID: Thread-Topic: [Sip] Handling of identical Tuples by Multiple PUAs - PUBLIS H 00 Thread-Index: AcN9DpNcm0Azjl+eQUSO0l0lsEzxvQEBBPFQ To: , Cc: X-OriginalArrivalTime: 22 Sep 2003 14:16:29.0695 (UTC) FILETIME=[1DDE68F0:01C38114] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi George, I support your proposal that a new XCAP usage for presence composer = policy management would be useful. I don't think it should be part of = the authorization usage, though. Also I hope we could proceed with SIP = PUBLISH without it.=20 So maybe this could be seen as the next step in the presence publication = work, which could be done after the basic publishing is dealt with. Markus=20 > -----Original Message----- > From: ext George Foti (QC/EMC) [mailto:george.foti@ericsson.com] > Sent: 16 September, 2003 20:14 > To: Niemi Aki (NMP/Helsinki) > Cc: sip@ietf.org > Subject: RE: [Sip] Handling of identical Tuples by Multiple PUAs - > PUBLIS H 00 >=20 >=20 > Hi Aki, > Well the newest publication policy wont win in all cases.=20 > Certainly, not in my example, as the PUA on which I forgot to=20 > logoff will become the *newest* once in a while. >=20 > I was hoping, that similar to the usage of XCAP for setting=20 > authorization policies, we have a standardized procedure to=20 > control (ignore/consider) policy composers at the PUA level. > May be that should be added on to the authorization draft! > Forget about segementation, collision detection, etc > That is still an option for implementations but need not be=20 > standradized. > =20 >=20 > Thx/gf > > -----Original Message----- > > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, September 16, 2003 11:47 AM > > To: George Foti (QC/EMC) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Handling of identical Tuples by Multiple PUAs - > > PUBLIS H 00 > >=20 > >=20 > > Hi George, > >=20 > > I think the composer policy could simply be that the newest=20 > > publication=20 > > wins. That way the zombie PUA's state will not propagate to the=20 > > watchers. Maybe this is something we ought to state in the draft? > >=20 > > But I think shutting down (remotely) such a zombie publisher=20 > > is somewhat=20 > > outside the scope of PUBLISH. Personally, I think this=20 > problem may be=20 > > more appropriately solved by designing the PUA such that it doesn't=20 > > zombie out, e.g., it takes user inactivity as a hint and stops=20 > > publication refreshes. > >=20 > > Other than that, I'm open to suggestions. The main reason for not=20 > > including event segmentation and collision detection to=20 > > PUBLISH was that=20 > > it created a lot of (unnecessary) complexity. > >=20 > > Cheers, > > Aki > >=20 > > On 16.09.2003 18:01, ext George Foti (QC/EMC): > >=20 > > > Hi Aki, > > >=20 > > > I think it should better explained in the draft how will such a > > > composer policy be set. If I have a PUA that is configured to > > > automatically publish presence information when I logon and if I > > > forgot to logoff, then how can I set the composer policy to ignore > > > that PUA or not include the information from that PUA in=20 > this case. > > >=20 > > > Should this not be standradized ?? > > >=20 > > > Thx/gf > > >=20 > > >> -----Original Message----- From: Aki Niemi > > >> [mailto:aki.niemi@nokia.com] Sent: Tuesday, September 16, 2003 > > >> 10:55 AM To: George Foti (QC/EMC) Cc: sip@ietf.org Subject: Re: > > >> [Sip] Handling of identical Tuples by Multiple PUAs - PUBLISH 00 > > >>=20 > > >>=20 > > >> Hi George, > > >>=20 > > >> Inline. > > >>=20 > > >> On 15.09.2003 17:36, ext George Foti (QC/EMC): > > >>> If multiple PUAs publishes information on the same tuple, > > >> does it mean > > >>> that the ESC will have multiple entity-tags associated with > > >> that tuple, > > >>> one for each publishing PUA. > > >>=20 > > >> Each PUA publishes its own view of presence. Each view=20 > is assigned > > >> with an entity-tag, and each view can have tuples that overlap=20 > > >> across other PUAs. Resolving these "collisions" is at=20 > the hands of > > >> the composer. For example, it could automatically take preference > > >> for the "newest" view on that tuple. > > >>=20 > > >>> Also, the only means to stop a specfic PUA from updating > > >> that tuple is > > >>> through explictly disallowing that PUA from updating the > > >> state event for > > >>> that tuple, in the authorization policies in the ESC. > > >>=20 > > >> As it now stands, this requires setting the composer=20 > policy in such > > >> a way that the unwanted presence information never gets composed > > >> into the presence document. > > >>=20 > > >> Cheers, Aki > > >>=20 > > >>=20 > > >>>=20 > > >>> Thanks /gf > > >>>=20 > > >>>=20 > > >>>=20 > > >>=20 > > >>=20 > >=20 > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 22 12:03:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22421 for ; Mon, 22 Sep 2003 12:03:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T95-0003hk-TR for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 12:02:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MG2dVZ014234 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 12:02:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T8U-0003b3-Ek; Mon, 22 Sep 2003 12:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T7F-0003C4-8b for sip@optimus.ietf.org; Mon, 22 Sep 2003 12:01:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22293 for ; Mon, 22 Sep 2003 12:00:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1T78-0000ph-00 for sip@ietf.org; Mon, 22 Sep 2003 12:00:38 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 1A1T6x-0000op-00 for sip@ietf.org; Mon, 22 Sep 2003 12:00:28 -0400 Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h8MG6T3s011320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2003 11:06:29 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h8MG6Mxq011318; Mon, 22 Sep 2003 11:06:22 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: RE: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: "Rosen, Brian" Cc: "'Stastny Richard'" , Rohan Mahy , Francois Audet , Paul Kyzivat , Bob Penfield , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5ED5@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5ED5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064246781.11187.55.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 22 Sep 2003 11:06:22 -0500 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ah! I think we have something here! Brian said: > A user at a dumb phone always enters a dial string. > No argument. > > However, at some point, either a UA translates a dial string > to a phone number, or a downstream proxy does it. At that point > it isn't a dial string, it's a phone number, and it might be > in a context (it could be global). What I've mentioned is > a case, which I think is pretty common, where the number is > not represented the same way as a dial string and a phone number, > and yet is in the same domain. Actually, this isn't quite right. Proxies transform URIs. They can do all sorts of transformations -- changing the domain, the user part, parameters, etc. for any number of reasons and using any number of mechanisms to specify that transformation. It's never a dial-string when it's being processed by a proxy. It might CONTAIN information that is meant to represent a dial-string, but it's a request URI as long as we're thinking about the problem from the proxy's perspective. Eventually, that request (and its associated, potentially transformed URI) may be delivered to a telephony gateway. The gateway's job is to construct appropriate PSTN signaling based on the request-URI. By today's convention, simple gateways take the user part of the request URI and use it as the signaling input to the PSTN -- i.e., a "dial string". More sophisticated gateways verify that the host-part of the request (if any) targets the gateway. Even more sophisticated gateways perform their own transformations on the user part, perhaps applying regular expressions or similar programatic mechanisms. Oddly enough, no gateway that I'm aware of treats a request any differently if it has a user=phone parameter than it does if there is no user=phone parameter, and there's not even any way to test for this in the expression language of such gateways, as far as I know. So who does pay attention to a parameter of user=phone? Potentially, it is considered by intermediate proxies, who are trying to decide 1) What transformation to make to the request URI, if any, and 2) Where to send the request next. I believe there have been suggestions that proxies use user=phone in several distinct ways: 1) As a way to indicate that this request URI is intended for eventaul delivery (unless otherwise transformed) to a PSTN gateway. 2) As a way to indicate that the request URI MUST be delivered to a PSTN gateway, and that the user-part of the request-URI is expected to be meaningly translatable to PSTN signaling by a gateway in the domain or context of the request. 3) As a way to inidcate that the SIP or SIPS request-URI was constructed from a tel URI, which transformation may or may not be reversable. 4) As a way to indicate that some prior device in the processing chain has transformed the user-part of the request URI FROM a dial-string to some sort of unique user-part so that it can be used in routing. This might be better addressed by a "history" sort of operation. 5) As a way to indicate that some prior device in the processing chain has transformed the user part INTO a dial-string which can be correctly interpreted by a specific PSTN gateway. This might be better addressed by a "history" sort of operation. 6) As a way to indicate that the originating UA doesn't know what to do with user-input and that further transformation is required by a proxy for the request-URI to resolve to the intended target. Brian further expounds: > Let's take a practical example. Suppose I have a domain with > a reasonably smart proxy server and a mix of phones. Some phones > have dialstring translation, some don't. The proxy server > can translate dial strings to phone numbers, and it also can > route phone numbers. Obviously it can do both (ie translate then > route). > > Now, how does the proxy know if it needs to translate? That is, > how does it know that a uri passed to it is a dial string vs > a phone number? If I pass it a phone number and it decides to > apply it's dialstring processing, that will fail. If I pass a > dial string and it just routes, that will fail. It has to know > what it is given. In my example it was 7246826@pit.sip.marconi.com > That's a phone number, and a dial string, but it's two different > destinations. In my numbering plan, it's my phone. In my dialing > plan it's an extension in another office. > In this case, you appear to be using mode 6 as described above. Discussion: Some phones know how to transform a sequence of user-entered digits into a routable request. These phones, when presented a user input loooking like a string of digits, use this capability to generate a request URI targeting the (effectively) globally-routable destination. Such a request has no user=phone parameter. Other phones do NOT know how to do this translation and just paste the collected digits into the user-part of a request and add user=phone. A routing proxy, receiving a request, applies different routing and transformation logic to a request having user=phone than it does to a request not having that parameter. This may result in identical outputs for requests with/without user=phone, or it may result in divergent outputs. Conclusion: I believe that in this usage, the presence of user=phone in a request indicates something about the ORIGINATOR of the request (this request came from a stupid phone) and not something about the TARGET of the request (this request is meant to go to the PSTN). I think this distinction (Exactly WHO is a "phone" when the request says user=phone) is at the heart of the discussion we're having. And I don't believe your usage is at all consistent with what I've heard from many other people on this list, who believe that "user=phone" is a property of the request's TARGET, not a property of the request's ORIGINATOR. Admittedly, when viewed this way, it makes more sense than some suggestions. Note that modes 1 and 2 above break things, and mode 3 isn't particularly useful. I'm still not sure where this leaves us, but am beginning to hope that we understand the underlying confusion. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 22 18:35:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15529 for ; Mon, 22 Sep 2003 18:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ZH7-0007ad-N7 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 18:35:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MMZLsX029114 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 18:35:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ZGo-0007Xc-Sp; Mon, 22 Sep 2003 18:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ZGg-0007Wm-Un for sip@optimus.ietf.org; Mon, 22 Sep 2003 18:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15475 for ; Mon, 22 Sep 2003 18:34:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ZGd-0000m8-00 for sip@ietf.org; Mon, 22 Sep 2003 18:34:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1ZGd-0000jT-00 for sip@ietf.org; Mon, 22 Sep 2003 18:34:51 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2003 15:31:59 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8MMYEJs004597; Mon, 22 Sep 2003 15:34:14 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACP11549; Mon, 22 Sep 2003 18:34:12 -0400 (EDT) Message-ID: <3F6F78E4.2060307@cisco.com> Date: Mon, 22 Sep 2003 18:34:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard CC: Francois Audet , "Rosen, Brian" , Rohan Mahy , Bob Penfield , sip@ietf.org Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone References: <06CF906FE3998C4E944213062009F162233858@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stastny Richard wrote: > I understand your example, but I thought we are talking > about dunb UA without having dialing plans built in. > > How do you tell your phone to send append in one case > santaclara.proxy.com and in the other case > chicago.proxy.com if you just dial 3756? A really dumb phone won't do both. You just configure it with the one string to append. > Either you use an access code, but then you have > a dialing plan built in, or you sent it with the > access code to the default proxy and let it doing the work, As Francois has said, you may not want to have a 1:1 correlation between dial plans and proxies. You may want every single user to have his own dialplan, which is evaluated by the proxy. > > or you use separate lines and swich between them. Yes. A slightly smarter phone might have a separate context for each "line". Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 22 23:34:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06508 for ; Mon, 22 Sep 2003 23:34:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dvr-0000yW-Lf for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 23:33:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N3Xh6G003742 for sip-archive@odin.ietf.org; Mon, 22 Sep 2003 23:33:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1dvB-0000mO-AE; Mon, 22 Sep 2003 23:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1duZ-0000iH-Th for sip@optimus.ietf.org; Mon, 22 Sep 2003 23:32:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06410 for ; Mon, 22 Sep 2003 23:32:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1duY-00003S-00 for sip@ietf.org; Mon, 22 Sep 2003 23:32:22 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1A1duX-000037-00 for sip@ietf.org; Mon, 22 Sep 2003 23:32:21 -0400 Received: from Natarajucl1127 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HLN000Z5DIE0Z@mta1.huawei.com> for sip@ietf.org; Tue, 23 Sep 2003 11:25:28 +0800 (CST) Date: Tue, 23 Sep 2003 09:04:46 +0530 From: "Nataraju A.B." To: sip@ietf.org Message-id: <003a01c38183$a35d5e90$3d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: multipart/alternative; boundary="Boundary_(ID_yPo7DPXoIxoLckF9xLj4Og)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sip] Fw: [Sip-implementors] sip-session-timer-11: Problem with responses from roughe UAS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_yPo7DPXoIxoLckF9xLj4Og) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT I am raising this issue since there was no response in implementers mailing list.. ----- Original Message ----- From: Nataraju A.B. To: Mailing List SIP Sent: Monday, September 22, 2003 8:37 AM Subject: [Sip-implementors] sip-session-timer-11: Problem with responses from roughe UAS 11.2 Inside Attacks << consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer, and quickly sends a refresh. Section 7.1 requires the UAC to copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request, and provide a Min-SE with a higher minimum. The UAC will then use this higher minimum. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response, and force the UAC to continue to generate rapid requests. >> In this case the proxies or UAC does not check the SE header in the 2xx response is greater than its locally defined Min-SE value or NOT. If so it would have been better. In the current design, unnecessarily the UAC & proxy's resources will be wasted in negotiating the Min-SE in every session refresh request. Instead I propose to forward the 2xx response ONLY in case SE value in response is greater than its Min-SE(configured value) else drop the response. because there is no point in stablishing a connection with a roughe UAS. In addition I have one more query :: In most of the scenarios which I came across in the draft Min-SE and SE values in teh session refresh request will be same. I feel session refresh request could just carry the increased SE value no need for carrying the Min-SE value also. In this case Min-SE does not serve any purpose (I assume so). Am I missing anywhere ??? Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-98455-95744 ------------------------------------------- -------------------------------------------------------------------------------- _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --Boundary_(ID_yPo7DPXoIxoLckF9xLj4Og) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
I am raising this issue since there was no response in implementers mailing list..
 
----- Original Message -----
Sent: Monday, September 22, 2003 8:37 AM
Subject: [Sip-implementors] sip-session-timer-11: Problem with responses from roughe UAS

11.2 Inside Attacks
<< consider the case of a rogue UAS that wishes to force a UAC to
   generate refreshes at a rapid rate. In that case, the UAC has to
   support session timer. The initial INVITE arrives at the rogue UAS,
   which returns a 2xx with a very small session interval. The UAC uses
   this timer, and quickly sends a refresh. Section 7.1 requires the
   UAC to copy the current session interval into the Session-Expires
   header field in the request. This enables the proxies to see the
   current value. The proxies will reject this request, and provide a
   Min-SE with a higher minimum. The UAC will then use this higher
   minimum. Note, that if the proxies did not reject the request, but
   rather proxied the request with a Min-SE header field, an attack
   would still be possible. The UAS could discard this header field in
   a 2xx response, and force the UAC to continue to generate rapid
   requests.  >>
 
In this case the proxies or UAC does not check the SE header in the 2xx response is greater than its locally defined Min-SE value or NOT. If so it would have been better.
 
In the current design, unnecessarily the UAC & proxy's resources will be wasted in negotiating the Min-SE in every session refresh request.
 
Instead I propose to forward the 2xx response ONLY in case SE value in response is greater than its Min-SE(configured value) else drop the response. because there is no point in stablishing a connection with a roughe UAS.
 
In addition I have one more query :: In most of the scenarios which I came across in the draft Min-SE and SE values in teh session refresh request will be same.
I feel session refresh request could just carry the increased SE value no need for carrying the Min-SE value also. In this case Min-SE does not serve any purpose (I assume so).
 
Am I missing anywhere ???
Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-98455-95744
-------------------------------------------   

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--Boundary_(ID_yPo7DPXoIxoLckF9xLj4Og)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 23 11:10:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19159 for ; Tue, 23 Sep 2003 11:10:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oo9-0001dQ-Kh for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 11:10:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NFAT7E006225 for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 11:10:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1onj-0001ay-74; Tue, 23 Sep 2003 11:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1omv-0001Zt-Ia for sip@optimus.ietf.org; Tue, 23 Sep 2003 11:09:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19077 for ; Tue, 23 Sep 2003 11:09:04 -0400 (EDT) From: Cibu.Johny@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oms-0001PP-00 for sip@ietf.org; Tue, 23 Sep 2003 11:09:10 -0400 Received: from quartz.mw.3com.com ([192.65.73.145]) by ietf-mx with esmtp (Exim 4.12) id 1A1oms-0001PL-00 for sip@ietf.org; Tue, 23 Sep 2003 11:09:10 -0400 Received: from gypsum.mw.3com.com (gypsum.mw.3com.com [149.112.20.3]) by quartz.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8NFEcfH023304; Tue, 23 Sep 2003 08:14:38 -0700 (PDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8NF9lNl018633; Tue, 23 Sep 2003 08:09:48 -0700 (PDT) Subject: Re: [Sip] npi=,ton= tag values for SIP to QSIG mapping To: Cullen Jennings Cc: Date: Tue, 23 Sep 2003 10:09:02 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 09/23/2003 10:09:03 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Cullen, Sorry about the confusion. I was not enquiring about Local Number Portability. My question was regarding Numbering Plan Indicator(NPI) and Type Of Number/Nature of Address (TON/NoA). I am interested in knowing what are the corresponding tag values for npi= and ton=. -cibu Cullen Jennings on 09/21/2003 02:22:24 PM To: Cibu Johny/UTStarcom@UTStarcom, cc: Subject: Re: [Sip] npi=,ton= tag values for SIP to QSIG mapping There has been some work done using the tel URL for this sort of stuff in SIP. You might want to have a look at http://www.softarmor.com/iptel/drafts/draft-yu-tel-url-07.txt Cullen On 9/19/03 10:23, "Cibu.Johny@utstar.com" wrote: > > Hi, > > What are the possible values for npi= and ton= tag values in the INVITE > Request-URI header in order to map QSIG NPI & TON numbers? Is there any > draft available for this? I searched quite a bit, but failed to get any > draft or example from the web. Help really appreciated. > > -thanks, > Cibu > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 23 16:09:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04554 for ; Tue, 23 Sep 2003 16:09:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tTF-0002od-NW for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 16:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NK9DQx010764 for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 16:09:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tT3-0002mm-5t; Tue, 23 Sep 2003 16:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tSA-0002lM-5y for sip@optimus.ietf.org; Tue, 23 Sep 2003 16:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04443 for ; Tue, 23 Sep 2003 16:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1tS8-00062Q-00 for sip@ietf.org; Tue, 23 Sep 2003 16:08:04 -0400 Received: from mail0.lsil.com ([147.145.40.20]) by ietf-mx with esmtp (Exim 4.12) id 1A1tS7-00061z-00 for sip@ietf.org; Tue, 23 Sep 2003 16:08:03 -0400 Received: from mhbs.lsil.com (mhbs.lsil.com [147.145.31.100]) by mail0.lsil.com (8.12.8/8.12.8) with ESMTP id h8NK4ja8001647 for ; Tue, 23 Sep 2003 13:05:37 -0700 (PDT) Received: from mabrishami.lsil.com by mhbs.lsil.com for sip@ietf.org; Tue, 23 Sep 2003 13:07:23 -0700 Reply-To: From: "Merhdad Abrishami" To: Date: Tue, 23 Sep 2003 16:07:46 -0400 Message-Id: <004501c3820e$5bf5e320$a8949193@lsil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Subject: [Sip] looking for SIP proxy server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, my name is Mehrdad Abrishami. I am new to the SIP mailing list. I am developing SIP UA for a DSL gateway. I am looking for a very low cost/free SIP proxy server for PC/Windows or PC/Linux that I can use with a CISCO 7940 IP phone. Your help would be appreciated. And from now on I'll be quite and just listen. Thanks, Mehrdad Abrishami _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 23 17:14:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07323 for ; Tue, 23 Sep 2003 17:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uU2-0006vG-1s for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 17:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NLE6rq026585 for sip-archive@odin.ietf.org; Tue, 23 Sep 2003 17:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uTw-0006uB-OM; Tue, 23 Sep 2003 17:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1uSz-0006tK-AU for sip@optimus.ietf.org; Tue, 23 Sep 2003 17:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07268 for ; Tue, 23 Sep 2003 17:12:52 -0400 (EDT) From: madflatpicker01@rmi.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1uSw-00070S-00 for sip@ietf.org; Tue, 23 Sep 2003 17:12:58 -0400 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1A1uSw-00070P-00 for sip@ietf.org; Tue, 23 Sep 2003 17:12:58 -0400 Received: from [192.168.167.48] (helo=wamui10.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A1uSu-00050p-00; Tue, 23 Sep 2003 17:12:56 -0400 Message-ID: <26502968.1064351576156.JavaMail.root@wamui10.slb.atl.earthlink.net> Date: Tue, 23 Sep 2003 15:12:47 -0600 (GMT-06:00) Reply-To: madflatpicker01@rmi.net To: mehrdad.abrishami@lsil.com, sip@ietf.org Subject: Re: [Sip] looking for SIP proxy server Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Check the list from Columbia University web site; Henning's web site has links to different components. http://www.cs.columbia.edu/sip/ Also, Columbia has a proxy server that is free to students and low cost to others. Written in TCL/TK and C; easy to port to multiple platforms. later/m. -----Original Message----- From: Merhdad Abrishami Sent: Sep 23, 2003 2:07 PM To: sip@ietf.org Subject: [Sip] looking for SIP proxy server Hello, my name is Mehrdad Abrishami. I am new to the SIP mailing list. I am developing SIP UA for a DSL gateway. I am looking for a very low cost/free SIP proxy server for PC/Windows or PC/Linux that I can use with a CISCO 7940 IP phone. Your help would be appreciated. And from now on I'll be quite and just listen. Thanks, Mehrdad Abrishami _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 24 02:25:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21299 for ; Wed, 24 Sep 2003 02:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A235S-0004eM-2E for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 02:25:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6PHfS017874 for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 02:25:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A235E-0004c3-4b; Wed, 24 Sep 2003 02:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A234D-0004Ym-O8 for sip@optimus.ietf.org; Wed, 24 Sep 2003 02:24:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19567 for ; Wed, 24 Sep 2003 02:23:53 -0400 (EDT) From: george_r@batmbg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2349-000631-00 for sip@ietf.org; Wed, 24 Sep 2003 02:23:57 -0400 Received: from [212.91.166.210] (helo=mail.batmbg.com) by ietf-mx with smtp (Exim 4.12) id 1A2348-00062h-00 for sip@ietf.org; Wed, 24 Sep 2003 02:23:57 -0400 Received: (qmail 27365 invoked from network); 24 Sep 2003 06:39:38 -0000 Received: from dune.batmbg.com (HELO 127.0.0.1) (192.168.0.15) by mars.batmbg.com with SMTP; 24 Sep 2003 06:39:38 -0000 Date: Wed, 24 Sep 2003 09:20:33 +0200 X-Mailer: The Bat! (v1.60c) Personal Reply-To: george_r@batmbg.com Organization: BATM X-Priority: 3 (Normal) Message-ID: <5585753306.20030924092033@batmbg.com> To: sip@ietf.org CC: Merhdad Abrishami Subject: Re: [Sip] looking for SIP proxy server In-Reply-To: <004501c3820e$5bf5e320$a8949193@lsil.com> References: <004501c3820e$5bf5e320$a8949193@lsil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Also you can check: iptel.org fwd.pulver.com snom.com these are free MA> Hello, my name is Mehrdad Abrishami. I am new to the SIP mailing list. I am MA> developing SIP UA for a DSL gateway. I am looking for a very low cost/free MA> SIP proxy server for PC/Windows or PC/Linux that I can use with a CISCO 7940 MA> IP phone. Your help would be appreciated. And from now on I'll be quite and MA> just listen. MA> Thanks, MA> Mehrdad Abrishami MA> _______________________________________________ MA> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip MA> This list is for NEW development of the core SIP Protocol MA> Use sip-implementors@cs.columbia.edu for questions on current sip MA> Use sipping@ietf.org for new developments on the application of sip -- mailto:george_r@batmbg.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 24 03:15:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28123 for ; Wed, 24 Sep 2003 03:15:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23rh-0000AS-BR for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 03:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7F9rJ000600 for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 03:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23rc-000093-Jo; Wed, 24 Sep 2003 03:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23rQ-00007s-O0 for sip@optimus.ietf.org; Wed, 24 Sep 2003 03:14:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28070 for ; Wed, 24 Sep 2003 03:14:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23rO-0006mI-00 for sip@ietf.org; Wed, 24 Sep 2003 03:14:50 -0400 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1A23rK-0006m6-00 for sip@ietf.org; Wed, 24 Sep 2003 03:14:47 -0400 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id h8O7DO3e017392; Wed, 24 Sep 2003 12:43:25 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id MAA24740; Wed, 24 Sep 2003 12:52:34 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id MAA21362; Wed, 24 Sep 2003 12:23:28 -0500 Date: Wed, 24 Sep 2003 12:25:40 +0530 (IST) From: Rinchen Tundup cc: sip@ietf.org, Merhdad Abrishami Subject: Re: [Sip] looking for SIP proxy server In-Reply-To: <5585753306.20030924092033@batmbg.com> Message-ID: MIME-Version: 1.0 Received: from cdotd by vikram.eis.ernet.in; Wed, 24 Sep 2003 12:52 GMT Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Check this one too .. its free , with source code http://www.nongnu.org/partysip/partysip.html On Wed, 24 Sep 2003 uucp-relay-delhi!george_r@batmbg.com wrote: > Also you can check: > > iptel.org > fwd.pulver.com > snom.com > > these are free > > > > MA> Hello, my name is Mehrdad Abrishami. I am new to the SIP mailing list. I am > MA> developing SIP UA for a DSL gateway. I am looking for a very low cost/free > MA> SIP proxy server for PC/Windows or PC/Linux that I can use with a CISCO 7940 > MA> IP phone. Your help would be appreciated. And from now on I'll be quite and > MA> just listen. > > MA> Thanks, > > MA> Mehrdad Abrishami > > > > MA> _______________________________________________ > MA> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > MA> This list is for NEW development of the core SIP Protocol > MA> Use sip-implementors@cs.columbia.edu for questions on current sip > MA> Use sipping@ietf.org for new developments on the application of sip > > > > -- > mailto:george_r@batmbg.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 24 03:49:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29505 for ; Wed, 24 Sep 2003 03:49:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24Og-0002zA-Ce for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 03:49:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7nDh4011409 for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 03:49:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24OU-0002xJ-DG; Wed, 24 Sep 2003 03:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1R8E-0004EN-CO for sip@optimus.ietf.org; Mon, 22 Sep 2003 09:53:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14761 for ; Mon, 22 Sep 2003 09:53:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1R86-0007EH-00 for sip@ietf.org; Mon, 22 Sep 2003 09:53:30 -0400 Received: from loki.iss.org.ua ([212.109.61.227]) by ietf-mx with esmtp (Exim 4.12) id 1A1R7v-0007B8-00 for sip@ietf.org; Mon, 22 Sep 2003 09:53:19 -0400 Received: from Sasha (gizmo.iss.org.ua [212.109.61.228]) by loki.iss.org.ua (v6,CoolConfGenByDarker) with SMTP id h8MDpTW25577 for ; Mon, 22 Sep 2003 16:51:29 +0300 X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) Message-ID: <003301c38111$3481e120$0201a8c0@Sasha> From: "Oleksandr Sakada" To: Date: Mon, 22 Sep 2003 16:55:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Multicasting in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! I am confused a little bit with a multicast support in SIP. Consider, we need to establish a multiparty conference with the use of SIP. If I understand right, we need to have a central mixing unit, having it's own IP address. This address is carried in SDP encoded body of the INVITE request or 200 OK responce. If it is correct, what is the role of "maddr" parameter of the Via header field. Do we need to use this parameter as well? Does this parameter contain the same (multicast) address? Can you clarify this point, please? Thank you!!! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Sep 24 11:21:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21793 for ; Wed, 24 Sep 2003 11:21:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BSA-00020c-Va for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 11:21:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFLIbh007665 for sip-archive@odin.ietf.org; Wed, 24 Sep 2003 11:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BRv-0001yv-QE; Wed, 24 Sep 2003 11:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BR8-0001y9-Cu for sip@optimus.ietf.org; Wed, 24 Sep 2003 11:20:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21712 for ; Wed, 24 Sep 2003 11:20:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BR7-00066J-00 for sip@ietf.org; Wed, 24 Sep 2003 11:20:13 -0400 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 1A2BR6-00066F-00 for sip@ietf.org; Wed, 24 Sep 2003 11:20:12 -0400 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id SAA22506 for ; Wed, 24 Sep 2003 18:31:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Sep 2003 17:20:07 +0200 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A0D5C47@MAILSRV.uns.t-systems.tss> Thread-Topic: Question about Expires header in the INVITE request Thread-Index: AcOCr1YxtHCST8c7Q1m/H3TcWk6g3g== From: =?iso-8859-2?Q?Szel=E9nyi_Csaba?= To: Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question about Expires header in the INVITE request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, If the INVITE request contains an Expires header with a value of the = past, what answer should/must be generated? '487 Request Terminated' or = '408 Request Timeout'? RFC 3261 section 21.4.25 states, that '487 Request Terminated' response = is for BYE and CANCEL requests. The '408 Request Timeout' response = "encourages" resending the request. So, from this view I would vote for = 408. However according to RFC 3261 section 13.3.1 Item 1: 1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated. IMHO this would lead me to choose 487. And the 408 response means: = "could not process and answer the request in a certain time"; 408 does = not mean to me that an errorous request has arrived to the UAS.=20 Any oppinion, URL or reference would be highly appreciated. Thank you in advance. Regards, Szelenyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 07:03:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18430 for ; Thu, 25 Sep 2003 07:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Tty-0007Np-Tq for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 07:03:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PB3EfN028323 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 07:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ttl-0007M8-V5; Thu, 25 Sep 2003 07:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2TtP-0007Ll-OX for sip@optimus.ietf.org; Thu, 25 Sep 2003 07:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18406 for ; Thu, 25 Sep 2003 07:02:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2TtL-0004DR-00 for sip@ietf.org; Thu, 25 Sep 2003 07:02:35 -0400 Received: from [80.74.106.10] (helo=nt-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1A2TtK-0004DO-00 for sip@ietf.org; Thu, 25 Sep 2003 07:02:35 -0400 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Sep 2003 14:02:29 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E22A8A5@nt-mail.tlv.radvision.com> From: Ofra Wachsman To: "'rsparks@dynamicsoft.com'" Cc: "'sip@ietf.org'" Date: Thu, 25 Sep 2003 14:02:28 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] REFER request with method parameter != INVITE in refer-to header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi I have some questions about Refer-To header with method=SUBSCIRBE or method=REFER in it's URI. (rfc 3515) 1. When receiving REFER request with method=SUBSCIRBE, a new subscription should be created. how do I know what is the event of this subscription? same problem for method=REFER, how do I know the Refer-To header for the new REFER? Is there a draft defining such behavior? 2. If I created this subscription, what are the states of the new subscription, that we should notify the referrer of? only receiving responses? what about receiving notifications (if so, what will be the status code in the body status line?)? Ofra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 09:19:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23378 for ; Thu, 25 Sep 2003 09:19:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2W1d-0006wO-8N for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 09:19:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PDJGdg026622 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 09:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2W1P-0006q7-5u; Thu, 25 Sep 2003 09:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2W0m-0006of-PI for sip@optimus.ietf.org; Thu, 25 Sep 2003 09:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23297 for ; Thu, 25 Sep 2003 09:18:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2W0l-0005rr-00 for sip@ietf.org; Thu, 25 Sep 2003 09:18:23 -0400 Received: from [62.13.170.151] (helo=mail.h3g.it) by ietf-mx with esmtp (Exim 4.12) id 1A2W0k-0005rN-00 for sip@ietf.org; Thu, 25 Sep 2003 09:18:22 -0400 Received: from MIEXC01.h3g.it ([10.212.44.62]) by mail.h3g.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Sep 2003 15:21:52 +0200 Received: from RMEXC01.h3g.it ([10.194.4.18]) by MIEXC01.h3g.it with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Sep 2003 15:21:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38367.E96E9E60" Date: Thu, 25 Sep 2003 15:21:21 +0200 Message-ID: <047ACC5B9A00D741927A4A32E7D01B730363C760@RMEXC01.h3g.it> Thread-Topic: looking for SIP Servlet implementation Thread-Index: AcODZ+jZuBwRUtjQTO2Joyw07NVmHw== From: "Barbabella Alessio" To: X-OriginalArrivalTime: 25 Sep 2003 13:21:22.0336 (UTC) FILETIME=[E9C4BA00:01C38367] Subject: [Sip] looking for SIP Servlet implementation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C38367.E96E9E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I am working on the final project for my master thesis, and I am writing = some Java code that is using SIP Servlets (JSR 116). Can someone of you = address me to the right place (if any) where I can download some SIP = Servlet implementation able to execute my code? Thank you very much, Alessio ------_=_NextPart_001_01C38367.E96E9E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

I am working on the final project for my = master=20 thesis, and I am writing some Java code that is using SIP Servlets (JSR = 116).=20 Can someone of you address me to the right place (if any) where I can = download=20 some SIP Servlet implementation able to execute my code?

Thank you very much,

Alessio

------_=_NextPart_001_01C38367.E96E9E60-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 10:29:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27672 for ; Thu, 25 Sep 2003 10:29:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2X7Q-0003mz-Cq for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 10:29:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PETKd5014564 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 10:29:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2X78-0003l5-59; Thu, 25 Sep 2003 10:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2X6p-0003kW-Lm for sip@optimus.ietf.org; Thu, 25 Sep 2003 10:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27624 for ; Thu, 25 Sep 2003 10:28:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2X6n-0006ql-00 for sip@ietf.org; Thu, 25 Sep 2003 10:28:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2X6j-0006qR-00 for sip@ietf.org; Thu, 25 Sep 2003 10:28:37 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2003 07:26:19 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8PERx0E009243; Thu, 25 Sep 2003 07:28:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALX47408; Thu, 25 Sep 2003 07:14:46 -0700 (PDT) Date: Thu, 25 Sep 2003 07:31:12 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , Francois Audet , Paul Kyzivat , Bob Penfield , sip@ietf.org To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5ED5@whq-msgusr-02.pit.comms.marconi.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Friday, September 19, 2003, at 01:02 PM, Rosen, Brian wrote: > Richard > > A user at a dumb phone always enters a dial string. > No argument. > > However, at some point, either a UA translates a dial string > to a phone number, or a downstream proxy does it. At that point > it isn't a dial string, it's a phone number, and it might be > in a context (it could be global). What I've mentioned is > a case, which I think is pretty common, where the number is > not represented the same way as a dial string and a phone number, > and yet is in the same domain. > > Let's take a practical example. Suppose I have a domain with > a reasonably smart proxy server and a mix of phones. Some phones > have dialstring translation, some don't. The proxy server > can translate dial strings to phone numbers, and it also can > route phone numbers. Obviously it can do both (ie translate then > route). > > Now, how does the proxy know if it needs to translate? That is, > how does it know that a uri passed to it is a dial string vs > a phone number? If I pass it a phone number and it decides to > apply it's dialstring processing, that will fail. If I pass a > dial string and it just routes, that will fail. It has to know > what it is given. In my example it was 7246826@pit.sip.marconi.com > That's a phone number, and a dial string, but it's two different > destinations. In my numbering plan, it's my phone. Brian, I expect that your address should be more like this: sip:6826@pit.sip.marconi.com sip:7246826@marconi.com tel:6826;phone-context=3Dpit.marconi.com tel:7246826;phone-context=3Dmarconi.com tel:7246826;phone-context=3D+1222 tel:+12227246826 which would make the dial string for the extension in the other office =20= simply: tel:7246826;phone-context=3Dpit.marconi.com but since you haven't given me much more to go on, I will assume two =20 different contexts. One for the numbers you dial on your phone, and =20 another for your internal representation of a "phone number" whatever =20= that is. someone could express your phone number as: tel:7248626;phone-context=3Dpit.marconi.com which then gets converted to: sip:7248626;phone-context=3Dpit.marconi.com@marconi.com;user=3Dphone where a marconi.com proxy retargets to one of your AORs: sip:7248626@pit.sip.marconi.com when you dial a particular a dial string: sip:7248626;phone-context=3Dpit-dial-=20 plan.marconi.com@marconi.com;user=3Dphone the marconi.com proxy can apply the pittsburgh dial plan and generate =20= whatever target it is supposed to generate. maybe: sip:8628@lax.marconi.com or tel:+442081118626, or whatever it means. thanks, -rohan > In my dialing > plan it's an extension in another office. > > Brian > > Brian > >> -----Original Message----- >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> Sent: Friday, September 19, 2003 3:33 PM >> To: Rosen, Brian; Rohan Mahy >> Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org >> Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >> >> >> Brian, >> >> If you pick up a phone and enter digits, it ALWAYS a dialing string >> and you are ALWAYS in ONE and ONLY ONE dialing plan.. >> >> You never enter a phone number directly, you always >> dial (if you dial a local number, the mapping may be 1:1) >> >> So if you enter a dial string in a SIP phone and iu sends >> it with nnnn@default.com to your defaulr sip server, this server >> then evaluates the dialing plan and translates it to a numbering = plan. >> >> Btw, thats exactly how fwd, iptel sipphone, ... are implemeted. >> >> Richard >> >> -----Urspr=FCngliche Nachricht----- >> Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Gesendet: Fr 19.09.2003 19:37 >> An: Stastny Richard; Rohan Mahy >> Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org >> Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >> =09 >> =09 >> >> Richard >> =09 >> My phone number within my local domain is 742-6826. >> I could change the convention and make it 724-742-6826 or >> 1-724-742-6826 if you want. >> =09 >> My dial plan would send a call to a different phone if you >> dialed any of those strings. >> =09 >> If you send an INVITE 7426826@pit.sip.marconi.com it will ring >> my sipphone. >> =09 >> If I dial 7426826, it won't ring my sip phone. I have to dial >> 6826 or 9-742-6826 or even 300-6826. >> =09 >> Using your algorithm, I would assume 7426826 was a dial string, >> and that would be wrong. >> =09 >> Brian >> =09 >> > -----Original Message----- >> > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> > Sent: Friday, September 19, 2003 1:24 PM >> > To: Rosen, Brian; Rohan Mahy >> > Cc: Francois Audet; Paul Kyzivat; Bob Penfield; sip@ietf.org >> > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >> > >> > >> > See below >> > >> > -----Urspr=FCngliche Nachricht----- >> > Von: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> > Gesendet: Fr 19.09.2003 15:17 >> > An: 'Rohan Mahy' >> > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; >> > 'sip@ietf.org' >> > Betreff: RE: [Sip] SIPIT Interop problem with >> ;user=3Dphone >> > >> > >> > >> > I've never seen E/F substitution for */#, and I've >> > never seen any >> > sip device that did it, but it's a possible way forward. >> > >> > I do think that some RFC would have to change >> the wording of >> > 2806bis to allow dial strings. The authors >> seemed to explicitly >> > declare them out of scope of the document. >> Generally, we don't >> > usually claim "that which is not specifically >> > disallowed is legal" >> > as a way around "out of scope" wording in our documents. >> > >> > I remain unhappy that dial strings, >> untranslated phone numbers >> > and translated phone numbers are indistinguishable. >> > They are different, >> > they are handled differently, and they should be >> > distinguishable. >> > I don't understand why some people are so adamant that >> > they should all >> > be represented in EXACTLY the same way (tel uri >> or sip uri with >> > or without user=3Dphone). They are not the same >> things, and they >> > should have distinctive representations. >> > >> > Richard: A string of digits is a string of digits. >> > >> > The simplest way to distinguish is: >> > >> > 1. If you just see a string of digits, you have to assume its >> > a dial string >> > >> > until you know better. >> > >> > 2. If you analysed the digits and found out its an E.164 >> > number, normalise it >> > >> > to tel:+xxxx, or sip:+xxxx@foo.bar >> > >> > 3. If you analysed it and found out it is a local >> number, then either >> > >> > use tel:xxxx; phone-context=3Dfoo.bar or >> sip:xxx@foo.bar;user=3Dphone >> > >> > I do not understand the problem >> > >> > Richard >> > >> > >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: Rohan Mahy [mailto:rohan@cisco.com] >> > > Sent: Thursday, September 18, 2003 9:17 PM >> > > To: Rosen, Brian >> > > Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; >> > 'sip@ietf.org' >> > > Subject: Re: [Sip] SIPIT Interop problem with >> ;user=3Dphone >> > > >> > > >> > > On Monday, September 15, 2003, at 10:23 AM, Rosen, >> > Brian wrote: >> > > > Well this goes to the issue Paul and I have >> disagreed on. >> > > > >> > > > I think the wording of the tel uri RFC is quite >> > clear that you >> > > > can't pass a dial string in one. You certainly >> > can't pass one with >> > > > star and pound. Therefore, I claim, there is no >> > way to pass >> > > > a dial string >> > > >> > > Brian, What part of a dial string doesn't fit into: >> > 1*phonedigit ? >> > > >> > > phonedigit =3D "0" / "1" / "2" / "3" / "4" / >> "5" / "6" / "7" / >> > > "8" / "9" / >> > > "A" / "B" / "C" / "D" / "E" / "F" >> > > >> > > E corresponds to * and F corresponds to # >> > > >> > > thanks, >> > > -rohan >> > > >> > > >> > > > , unless you put it in a username on a SIP uri, >> > > > and denote that it is a dial string, for which a >> > phone number is >> > > > a proper subset for most dial plans, by specifying >> > user=3Dphone. >> > > > >> > > > Paul disagrees. He thinks he can send a dial >> > string in a tel uri. >> > > > Without some kind of resolution of that issue, we >> > have a problem. >> > > > >> > > > Brian >> > > > -----Original Message----- >> > > > From: Francois Audet >> [mailto:audet@nortelnetworks.com] >> > > > Sent: Monday, September 15, 2003 12:10 PM >> > > > To: 'Paul Kyzivat' >> > > > Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >> > > > Subject: RE: [Sip] SIPIT Interop problem >> with ;user=3Dphone >> > > > >> > > > >> > > >> -----Original Message----- >> > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> > > >> Sent: Monday, September 15, 2003 06:58 >> > > >> To: Audet, Francois [SC100:4K02:EXCH] >> > > >> Cc: 'Rosen, Brian'; 'Bob Penfield'; 'sip@ietf.org' >> > > >> Subject: Re: [Sip] SIPIT Interop problem >> with ;user=3Dphone >> > > > [ stuff deleted as it looks like we are in >> agreement ] >> > > >> I'm not sure about the "most" part. Some do, some >> > don't. As spec is >> > > >> currently written, the equivalence between tel and >> > > sip/user=3Dphone is >> > > >> only one way. (IF the userpart comes from >> a tel, then there >> > > >> SHOULD be a >> > > >> user=3Dphone, but the presence of user=3Dphone does >> > not imply the >> > > >> userpart >> > > >> conforms to tel.) >> > > >> >> > > >> I personally am happy with the more strict >> > interpretation. But I am >> > > >> trying to hold out an olive branch in order to >> > reach a level >> > > >> of agreement. >> > > > OK. It seems that we are in agreement. >> > > > My suggestion is to ask the question to the group >> > of is anybody >> > > > objects to make it explicit that >> user=3Dphones means that the >> > > sip URI is >> > > > derived >> > > > from a tel URI? >> > > > If the answer is no, then I think we can probably >> > finally put this >> > > > issue >> > > > to rest. Otherwise, we need to rework the >> whole thing... >> > > > So... Does anybody strongly object to >> explicitly making the >> > > user=3Dphone >> > > > atttribute mean that the SIP URI was >> derived from a tel URI? >> > > >>> Applying the rules of RFC3261/19.1.6 >> instead, we'd get: >> > > >>> >> > > >>> >> > > >>> >> > >> sip:1234;phone-context=3Dyour-dialplan.foo.bar@foo.bar;user=3Dphone >> > > >>> >> > > >>> Which (like the tel URI) specifically >> identifies the >> > > >> dialing plan and >> > > >>> does not require one DNS entry per dialling plan. >> > > >> >> > > >> >> > > >> I agree that this is also a fine usage. >> > > >> >> > > >> But what is benefit of this over using the >> tel format and >> > > >> then passing >> > > >> the request to sip:foo.bar? >> > > > The tel URI format assumes that the proxy >> knows which proxy >> > > is aware >> > > > of the >> > > > phone context >> > > > and tel URIs (it could be itself, or it >> could know which >> > > proxy to route >> > > > sessions to). >> > > > The sip URI format lets you route it to a >> specific proxy >> > > that is aware >> > > > of >> > > > the phone >> > > > context, potentially with "generic" SIP >> proxies in between >> > > that have >> > > > no idea >> > > > how to route >> > > > based on phone contextes (or even tel URIs). T >> > > > >> > > > >> > > > They both have merits. >> > > > >> > > > _______________________________________________ >> > > > Sip mailing list >> https://www1.ietf.org/mailman/listinfo/sip >> > > > This list is for NEW development of the >> core SIP Protocol >> > > > Use sip-implementors@cs.columbia.edu for questions >> > on current sip >> > > > Use sipping@ietf.org for new developments on the >> > application of sip >> > > >> > >> > _______________________________________________ >> > Sip mailing list >> https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core >> SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on >> > current sip >> > Use sipping@ietf.org for new developments on the >> > application of sip >> > >> > >> > >> =09 >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 13:06:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06884 for ; Thu, 25 Sep 2003 13:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZZG-0006OU-VC for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 13:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PH6EtY024572 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 13:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZZ4-0006NQ-2M; Thu, 25 Sep 2003 13:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZYS-0006MG-EV for sip@optimus.ietf.org; Thu, 25 Sep 2003 13:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06754 for ; Thu, 25 Sep 2003 13:05:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZYP-0001z5-00 for sip@ietf.org; Thu, 25 Sep 2003 13:05:21 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A2ZYF-0001xA-00 for sip@ietf.org; Thu, 25 Sep 2003 13:05:11 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8PH4I210486; Thu, 25 Sep 2003 10:04:18 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Sep 2003 10:04:19 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20B23D9CE@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" , "'Rosen, Brian'" Cc: "'Stastny Richard'" , "'Paul Kyzivat'" , "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 25 Sep 2003 10:04:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38387.0A5DF33E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38387.0A5DF33E Content-Type: text/plain I agree with Rohan. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, September 25, 2003 07:31 > To: Rosen, Brian > Cc: 'Stastny Richard'; Audet, Francois [SC100:4K02:EXCH]; > Paul Kyzivat; Bob Penfield; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > Brian, > > I expect that your address should be more like this: > > sip:6826@pit.sip.marconi.com > sip:7246826@marconi.com > tel:6826;phone-context=pit.marconi.com > tel:7246826;phone-context=marconi.com > tel:7246826;phone-context=+1222 > tel:+12227246826 > > which would make the dial string for the extension in the > other office > simply: > > tel:7246826;phone-context=pit.marconi.com > > but since you haven't given me much more to go on, I will assume two > different contexts. One for the numbers you dial on your phone, and > another for your internal representation of a "phone number" > whatever > that is. > > someone could express your phone number as: > tel:7248626;phone-context=pit.marconi.com > > which then gets converted to: > sip:7248626;phone-context=pit.marconi.com@marconi.com;user=phone > > where a marconi.com proxy retargets to one of your AORs: > sip:7248626@pit.sip.marconi.com > > > when you dial a particular a dial string: > sip:7248626;phone-context=pit-dial- > plan.marconi.com@marconi.com;user=phone > > the marconi.com proxy can apply the pittsburgh dial plan and > generate > whatever target it is supposed to generate. maybe: > sip:8628@lax.marconi.com or tel:+442081118626, or whatever it means. > > thanks, > -rohan ------_=_NextPart_001_01C38387.0A5DF33E Content-Type: text/html RE: [Sip] SIPIT Interop problem with ;user=phone

I agree with Rohan.

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Thursday, September 25, 2003 07:31
> To: Rosen, Brian
> Cc: 'Stastny Richard'; Audet, Francois [SC100:4K02:EXCH];
> Paul Kyzivat; Bob Penfield; sip@ietf.org
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
>
> Brian,
>
> I expect that your address should be more like this:
>
> sip:6826@pit.sip.marconi.com
> sip:7246826@marconi.com
> tel:6826;phone-context=pit.marconi.com
> tel:7246826;phone-context=marconi.com
> tel:7246826;phone-context=+1222
> tel:+12227246826
>
> which would make the dial string for the extension in the
> other office 
> simply:
>
> tel:7246826;phone-context=pit.marconi.com
>
> but since you haven't given me much more to go on, I will assume two 
> different contexts.  One for the numbers you dial on your phone, and 
> another for your internal representation of a "phone number" 
> whatever 
> that is.
>
> someone could express your phone number as:
> tel:7248626;phone-context=pit.marconi.com
>
> which then gets converted to:
> sip:7248626;phone-context=pit.marconi.com@marconi.com;user=phone
>
> where a marconi.com proxy retargets to one of your AORs:
> sip:7248626@pit.sip.marconi.com
>
>
> when you dial a particular a dial string:
> sip:7248626;phone-context=pit-dial-
> plan.marconi.com@marconi.com;user=phone
>
> the marconi.com proxy can apply the pittsburgh dial plan and
> generate 
> whatever target it is supposed to generate.  maybe:
> sip:8628@lax.marconi.com  or tel:+442081118626, or whatever it means.
>
> thanks,
> -rohan

------_=_NextPart_001_01C38387.0A5DF33E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 13:52:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09544 for ; Thu, 25 Sep 2003 13:52:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2aHs-00015I-Cr for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 13:52:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PHqK7t004111 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 13:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2aHZ-000109-Fk; Thu, 25 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2aHS-0000zd-4x for sip@optimus.ietf.org; Thu, 25 Sep 2003 13:51:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09466 for ; Thu, 25 Sep 2003 13:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2aHP-0002he-00 for sip@ietf.org; Thu, 25 Sep 2003 13:51:51 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1A2aHO-0002hV-00 for sip@ietf.org; Thu, 25 Sep 2003 13:51:50 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h8PHpH97009528 for ; Thu, 25 Sep 2003 12:51:17 -0500 From: Dean Willis To: sip@ietf.org Content-Type: text/plain Message-Id: <1064512277.8652.47.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 25 Sep 2003 12:51:17 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Are we ready to last-call the PUBLISH draft? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The latest revision of the PUBLISH draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-publish-00.txt has been out there for a while and discussion seems to have settled down. I'm not aware of any major open issues, so it would seem that we're ready to begin a Working Group Last Call. If anybody objects, please raise your concerns now. -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 14:31:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12726 for ; Thu, 25 Sep 2003 14:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2att-0004X3-F7 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 14:31:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PIVbtQ017363 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 14:31:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2atK-0004Ui-DS; Thu, 25 Sep 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2asL-0004Mn-RG for sip@optimus.ietf.org; Thu, 25 Sep 2003 14:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12507 for ; Thu, 25 Sep 2003 14:29:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2asI-0003ci-00 for sip@ietf.org; Thu, 25 Sep 2003 14:29:58 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1A2asH-0003bt-00 for sip@ietf.org; Thu, 25 Sep 2003 14:29:57 -0400 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id OAA13099 for ; Thu, 25 Sep 2003 14:29:20 -0400 (EDT) Message-ID: <3F7333F3.1080608@ulticom.com> Date: Thu, 25 Sep 2003 14:29:07 -0400 From: Steve Pellegrino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] RFC 3261 spec bug Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, There appears to be a mistake in the example S/MIME encrypted SDP body content in sections 23.3 and 23.4.3 of RFC 3261 (pages 206 and 212). Per section 6 of RFC 2327, the time (`t' line) must come after the connection information (`c' line). Regards, Steve _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Sep 25 22:19:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03146 for ; Thu, 25 Sep 2003 22:19:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iCS-0005rY-K3 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 22:19:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q2JGDe022479 for sip-archive@odin.ietf.org; Thu, 25 Sep 2003 22:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iCE-0005q1-8B; Thu, 25 Sep 2003 22:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iBR-0005oH-Op for sip@optimus.ietf.org; Thu, 25 Sep 2003 22:18:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03112 for ; Thu, 25 Sep 2003 22:18:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2iBO-0001uZ-00 for sip@ietf.org; Thu, 25 Sep 2003 22:18:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2iBO-0001uI-00 for sip@ietf.org; Thu, 25 Sep 2003 22:18:10 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2003 19:15:58 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8Q2HRJs009808; Thu, 25 Sep 2003 19:17:38 -0700 (PDT) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOK58801; Thu, 25 Sep 2003 19:17:26 -0700 (PDT) Message-ID: <3F73A1B6.2040804@cisco.com> Date: Thu, 25 Sep 2003 22:17:26 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes , orit1@microsoft.com, AC Mahendran CC: Cullen Jennings , Jean-Francois Mule , sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] sip-mib: removal of sipStatusCodeClassesTable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, a proposal in on the table to remove this table from the SIP-COMMON-MIB. cullen was the only one of the reviewers who raised this issue explicitly. i wanted to give others a chance to comment on it. orit, did allude to there being too many counters and suggested removal of some summary counters. he didn't mention this table by name though (i don't think). these are "summary counters", but were defined this way to give a high level (gross) indicator of problems so a manager could to and probe a system further for the details. working at a more granular level of rsp code counters would require more polling on the part of snmp managers. that was the thought behind providing these aggregate counters. http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt comments? kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 09:41:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05532 for ; Fri, 26 Sep 2003 09:41:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2sq4-0002lx-Ty for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 09:40:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QDeq8N010654 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 09:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2spI-0002gj-ET; Fri, 26 Sep 2003 09:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2soP-0002f0-TF for sip@optimus.ietf.org; Fri, 26 Sep 2003 09:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05442 for ; Fri, 26 Sep 2003 09:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2soO-0000z8-00 for sip@ietf.org; Fri, 26 Sep 2003 09:39:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2soN-0000yr-00 for sip@ietf.org; Fri, 26 Sep 2003 09:39:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2003 06:37:01 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8QDcUJw028625; Fri, 26 Sep 2003 06:38:34 -0700 (PDT) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOL89865; Fri, 26 Sep 2003 06:38:29 -0700 (PDT) Message-ID: <3F744155.2010101@cisco.com> Date: Fri, 26 Sep 2003 09:38:29 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes , orit1@microsoft.com, AC Mahendran CC: Cullen Jennings , Jean-Francois Mule , sip@ietf.org Subject: Re: [Sip] sip-mib: removal of sipStatusCodeClassesTable References: <3F73A1B6.2040804@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit additionally... recently i was cc'd on an email where one developer asked another for a list of statistics that could be used as a measure of the health/well-being of a sip proxy. the developer responded in terms of the sip stats we have in the sip-common-mib and said the following about some objects from the sipStatusCodeClassesTable: ----- Successful responses - When calls are successful, these counters should be going up. sipStatsSuccessClassIns Counter32, /* 200 OK response */ sipStatsSuccessClassOuts Counter32, Failure responses - A very high value for these counters indicates calls failing in the network. Typically, if calls are not failing, these counters should have low values and increment slowly. sipStatsReqFailClassIns Counter32, /* 4XX class errors */ sipStatsReqFailClassOuts Counter32, sipStatsServerFailClassIns Counter32, /* 5xx class errors */ sipStatsServerFailClassOuts Counter32, sipStatsGlobalFailClassIns Counter32, /* 6xx class errors */ sipStatsGlobalFailClassOuts Counter32, -------- so i chimed in saying that there was a proposal to remove this table from the mib. if that were to occur, was there a small subset of individual rsp code counters that could be polled in order to draw the same conclusion on failures. the answer i got back was that all of the individial 4xx,5xx,6xx counters. a subset of "important" counters really wasn't feasible. if that is the case, then aren't these per class stats potentially of use in quickly gauging whether a sip system may be experiencing problems that warrent further investigation? kevin Kevin Lingle wrote: > hi all, > > a proposal in on the table to remove this table from > the SIP-COMMON-MIB. cullen was the only one of the reviewers > who raised this issue explicitly. i wanted to give others a > chance to comment on it. > > orit, did allude to there being too many counters and suggested > removal of some summary counters. he didn't mention this table > by name though (i don't think). > > these are "summary counters", but were defined this way to give > a high level (gross) indicator of problems so a manager could > to and probe a system further for the details. working at a > more granular level of rsp code counters would require more polling > on the part of snmp managers. that was the thought behind providing > these aggregate counters. > > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.txt > > comments? > > kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 10:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06778 for ; Fri, 26 Sep 2003 10:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tEX-0003sd-Sn for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 10:06:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QE69NJ014881 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 10:06:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tEQ-0003pk-FG; Fri, 26 Sep 2003 10:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tDl-0003oq-BS for sip@optimus.ietf.org; Fri, 26 Sep 2003 10:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06600 for ; Fri, 26 Sep 2003 10:05:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2tDj-0001GN-00 for sip@ietf.org; Fri, 26 Sep 2003 10:05:19 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A2tDi-0001GB-00 for sip@ietf.org; Fri, 26 Sep 2003 10:05:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8QE4Ud26519; Fri, 26 Sep 2003 09:04:32 -0500 From: Robert Sparks To: Ofra Wachsman Cc: "'sip@ietf.org'" In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E22A8A5@nt-mail.tlv.radvision.com> References: <99FF181D4C99564F8D623069E1DDB25E22A8A5@nt-mail.tlv.radvision.com> Content-Type: text/plain Message-Id: <1064585068.987.15.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 26 Sep 2003 09:04:29 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: REFER request with method parameter != INVITE in refer-to header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: > Hi > I have some questions about Refer-To header with method=SUBSCIRBE or > method=REFER in it's URI. (rfc 3515) > 1. When receiving REFER request with method=SUBSCIRBE, a new subscription > should be created. how do I know what is the event of this subscription? > same problem for method=REFER, how do I know the Refer-To header for the new > REFER? > Is there a draft defining such behavior? These can be defined using the URI "?" header escaping mechanism: Some examples (which may not be completely escaped correctly, but they show the spirit of the thing:) Refer-To: sip:rjs-presence@example;method=SUBSCRIBE?Event=presence Refer-To: sip:rjs-refer@example;method=REFER?Refer-To= > > 2. If I created this subscription, what are the states of the new > subscription, that we should notify the referrer of? only receiving > responses? what about receiving notifications (if so, what will be the > status code in the body status line?)? The REFER creates an implicit subscription to the status of the referrenced request and that only. So, if the REFER is to a SUBSCRIBE, you will get notification about the success or failure of that SUBSCRIBE transaction, but not information about any future NOTIFYs due to that SUBSCRIBE. RjS > > Ofra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 10:26:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08256 for ; Fri, 26 Sep 2003 10:26:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tY4-00050T-SU for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 10:26:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QEQKYX019190 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 10:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tXm-0004yI-Q1; Fri, 26 Sep 2003 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tXd-0004xd-Dr for sip@optimus.ietf.org; Fri, 26 Sep 2003 10:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08226 for ; Fri, 26 Sep 2003 10:25:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2tXb-0001Sz-00 for sip@ietf.org; Fri, 26 Sep 2003 10:25:51 -0400 Received: from web10303.mail.yahoo.com ([216.136.130.81]) by ietf-mx with smtp (Exim 4.12) id 1A2tXa-0001Sv-00 for sip@ietf.org; Fri, 26 Sep 2003 10:25:50 -0400 Message-ID: <20030926142547.52547.qmail@web10303.mail.yahoo.com> Received: from [157.159.10.14] by web10303.mail.yahoo.com via HTTP; Fri, 26 Sep 2003 16:25:47 CEST Date: Fri, 26 Sep 2003 16:25:47 +0200 (CEST) From: =?iso-8859-1?q?=20?= To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA08227 Subject: [Sip] looking for SIP application server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello,=20 My name is Youssef CHADLI. I am working on service logics developement. I am looking for a free or a low cost SIP Application Server. =20 Your help would be appreciated.=20 Thanks, Youssef CHADLI ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! Yahoo! Mail : http://fr.mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 11:33:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10923 for ; Fri, 26 Sep 2003 11:33:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uas-0000kd-8L for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 11:33:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QFXI1Y002884 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 11:33:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uac-0000jk-EH; Fri, 26 Sep 2003 11:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uaQ-0000jV-J3 for sip@optimus.ietf.org; Fri, 26 Sep 2003 11:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10908 for ; Fri, 26 Sep 2003 11:32:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2uaP-0002HL-00 for sip@ietf.org; Fri, 26 Sep 2003 11:32:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2uaN-0002HG-00 for sip@ietf.org; Fri, 26 Sep 2003 11:32:47 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8QFWDxW023431; Fri, 26 Sep 2003 08:32:14 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACS01413; Fri, 26 Sep 2003 11:32:12 -0400 (EDT) Message-ID: <3F745BFC.1020706@cisco.com> Date: Fri, 26 Sep 2003 11:32:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Ofra Wachsman , "'sip@ietf.org'" References: <99FF181D4C99564F8D623069E1DDB25E22A8A5@nt-mail.tlv.radvision.com> <1064585068.987.15.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] What are the intended semantics of REFER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This may be a bit off-topic, so I have changed the subject. Robert Sparks wrote: > On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: > >>Hi >>I have some questions about Refer-To header with method=SUBSCIRBE or >>method=REFER in it's URI. (rfc 3515) One thing troubles me about REFER, and my degree of discomfort goes up when is is applied in these more complex ways. The issue is how the referee is able to discern the implications of what is being asked to do - what corellary actions it should perform. For instance, in this case I might be able to tell someone else to subscribe to presence. But what should it do with the information when it is received? I don't have any good way to tell it what I intend for it to do, so by implication it must be presumed to be able to figure it out on its own, either because there is one single thing it does with such information, or because it can figure it out from context, such as based on who is asking. This is potentially a problem even for referring an INVITE, but it is at least tempting to believe that a given UA has only a few alternatives for what can do, that can be figured out from context. E.g., when a refer of invite is sent in an existing dialog where an invite is active, I believe there is an assumption that the receiving UA will reassign the local media resources so that they are connected to the new call rather than the old call. Many call flows assume this, but AFAIK there is no standard that says this. For other uses of refer I find it harder to convince myself that the recipient can infer the appropriate actions to take. This seems likely to lead to proprietary systems that can't interoperate, because they depend on remote devices that make particular assumptions about this. Paul >>1. When receiving REFER request with method=SUBSCIRBE, a new subscription >>should be created. how do I know what is the event of this subscription? >>same problem for method=REFER, how do I know the Refer-To header for the new >>REFER? >>Is there a draft defining such behavior? > > These can be defined using the URI "?" header escaping mechanism: > > Some examples (which may not be completely escaped correctly, but > they show the spirit of the thing:) > > Refer-To: sip:rjs-presence@example;method=SUBSCRIBE?Event=presence > > Refer-To: > sip:rjs-refer@example;method=REFER?Refer-To= > >>2. If I created this subscription, what are the states of the new >>subscription, that we should notify the referrer of? only receiving >>responses? what about receiving notifications (if so, what will be the >>status code in the body status line?)? > > > The REFER creates an implicit subscription to the status of the > referrenced request and that only. So, if the REFER is to a > SUBSCRIBE, you will get notification about the success or > failure of that SUBSCRIBE transaction, but not information > about any future NOTIFYs due to that SUBSCRIBE. > > RjS > > >> >>Ofra > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 14:33:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17288 for ; Fri, 26 Sep 2003 14:33:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xPL-0002YB-QX for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 14:33:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QIXZqi009746 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 14:33:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xOn-0002UV-Ib; Fri, 26 Sep 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xOZ-0002UE-DZ for sip@optimus.ietf.org; Fri, 26 Sep 2003 14:32:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17165 for ; Fri, 26 Sep 2003 14:32:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xOW-00048l-00 for sip@ietf.org; Fri, 26 Sep 2003 14:32:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2xOS-00048Z-00 for sip@ietf.org; Fri, 26 Sep 2003 14:32:41 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2003 11:30:34 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8QIW64s021076 for ; Fri, 26 Sep 2003 11:32:06 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACS19062; Fri, 26 Sep 2003 14:32:05 -0400 (EDT) Message-ID: <3F748625.3030403@cisco.com> Date: Fri, 26 Sep 2003 14:32:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: <200309111850.OAA05054@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re:draft-ietf-sip-publish-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm sorry to be late with comments on this draft - it just slipped down the priority queue until I saw the proposal for last call. Below are a number of comments. Paul Section 3: Last sentence says "Both the source and the target of the publication are naturally represented as an address-of-record.") I don't think this is right. At least it is no more true than saying "Both the source and the target of an invitation are naturally represented as an address-of-record." This is especially a problem for the source of publication. Certainly the source isn't *uniquely* represented by an AOR - in typical cases there may be many sources that all share an AOR. Nor is it necessary for the source to have any AOR at all. The statement is closer to true for the target. I think we all expect the typical usage to be that PUBLISH requests are aimed at an AOR and then routed to an appropriate contact address by a proxy. But of course this usage isn't required, any more than it is with invite. And while we may understand expected typical usage with presence, different patterns may be appropriate for other event packages. I'm not convinced that it is necessary to replace this sentence with anything. If you feel a need to say something, how about: "Often, publication requests will originate from endpoints associated with an address-of-record and be directed to that address-of-record." ----- Section 5: Request-URI: The Request-URI initially contains the address-of-record whose publication is to be created, removed, or modified. The address-of-record MUST be a SIP URI or SIPS URI. Unlike the REGISTER request, the Request-URI SHOULD contain both "userinfo" and "@" components. I see no reason for this. The request-uri is all about routing, and routing is fully specified in 3261. There is no reason to muck with this here. By the time the request arrives, the request-uri won't contain an AOR. Whether it had one initially or not is of no consequence. The ESC must decide what presence document to operate on based on the content of the message received. This decision will presumably be made based on the request-uri at that time, together with the presumed association of that with a particular AOR/presence document. (Or maybe it will be made based on the content of the To field.) ----- Section 5: To: The To header field contains the address-of-record whose publication is to be created, removed, or modified. The To header field and the Request-URI field are typically the same. This address-of-record MUST be a SIP URI or SIPS URI. I think there is some question whether the To should be used to select the presence doc or whether the request uri should be used. It depends on what we expect to happen in the case of forwarding. Suppose sip:alice@atlanta.com forwards everything to sip:bob@biloxi.com. Then suppose something sends a PUBLISH to alice. This will get forwarded to the ESC registed for bob. Now, does it refuse the request because the To references alice, or does it update the presence of bob? I haven't decided what I think the right answer is. But I think it ought to be consistent with what happens to SUBSCRIBE requests addressed to alice. ----- Section 6: The Event State Compositor (ESC) is a UAS that processes and responds to PUBLISH requests, and maintains a list of publications for a given address-of-record. The ESC has to know (e.g., through configuration) the domain or set of domains for which it maintains event state. This makes an assumption that a given ESC is responsible for a domain or domains. This need not be the case. It may simply be responsible for a few specific users. Proxy routing logic can get things to the right ESC. I think this could be reworded as: "The ESC has to know (e.g., through configuration) the set of addresses for which it maintains event state." ----- Section 6: A client may probe the ESC for the support of PUBLISH using the OPTIONS request defined in SIP [2]. In the response to such an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of allowed methods in the Allow header field. Also, it SHOULD list the supported event packages in an Allow-Events header field. It may be tricky to get this to work. If the ESC is itself registered as one of the contacts of the AOR, then a straightforward OPTIONS will fork, and only the first response will get back. That might not be from the ESC. To get around that, it may be necessary to use callerprefs to direct the OPTIONS to the ESC, perhaps via something like: OPTIONS sip:user@domain To: sip:user@domain From: sip:somebody@domain Accept-Contact: *;methods="SUBSCRIBE";events="presence" Having said that, I don't know how much of it needs to be in the spec. Maybe just a warning. ------ Section 6: 1. The ESC inspects the Request-URI to determine whether this request is for a domain supported by the ESC. If not, the ESC SHOULD proxy the request to the addressed domain. The ESC is a UA. UAs are typically not required to act as proxies. In any case, this bullet is all about standard 3261 behavior. Don't think it needs to be said. ------- Section 6: 4. The ESC SHOULD determine if the authenticated user is authorized to perform event state publication for the address-of-record of the To header field. This goes to my question above about whether selection of the presentity/presence document should be based on the request uri or To-uri. Here it clearly specifys this. The problem with this is that I don't believe it is consistent with SUBSCRIBE. ------- Section 6: 5. The ESC extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the ESC MUST send a 404 (Not Found) response and skip the remaining steps. Again I think this is over specifying. There need not be any specific relationship between the domain in the request uri and the domain in the To uri, though there often will be. But it could be completely reasonable for some server at sip:presenceRus.com to act as an ESC for users in any number of domains. *If* the To address is to be used for choosing the presence document to be affected, it would be better to say: "The ESC extracts the address-of-record from the To header field of the request. If the ESC does not manage event state for this address, it MUST send a 404 (Not Found) response and skip the remaining steps." [THE END] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 20:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00157 for ; Fri, 26 Sep 2003 20:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A32gu-0001fx-O4 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 20:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8R0C4pi006432 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 20:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A32gr-0001en-Az; Fri, 26 Sep 2003 20:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A32gj-0001dn-BT for sip@optimus.ietf.org; Fri, 26 Sep 2003 20:11:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00106 for ; Fri, 26 Sep 2003 20:11:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A32gh-0007T0-00 for sip@ietf.org; Fri, 26 Sep 2003 20:11:51 -0400 Received: from web41506.mail.yahoo.com ([66.218.93.89]) by ietf-mx with smtp (Exim 4.12) id 1A32gg-0007SF-00 for sip@ietf.org; Fri, 26 Sep 2003 20:11:50 -0400 Message-ID: <20030927001120.93799.qmail@web41506.mail.yahoo.com> Received: from [12.235.146.159] by web41506.mail.yahoo.com via HTTP; Fri, 26 Sep 2003 17:11:20 PDT Date: Fri, 26 Sep 2003 17:11:20 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] What are the intended semantics of REFER To: Paul Kyzivat , Robert Sparks Cc: Ofra Wachsman , "'sip@ietf.org'" In-Reply-To: <3F745BFC.1020706@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I agree that this can become complex. I don't agree that this is an interoperability problem. The complexity comes from attempting to solve more complex scenarios. And therefore I think the complexity is justified. I certainly believe that these type of problems deserve attention and where it makes sense, standardization. --- Paul Kyzivat wrote: > This may be a bit off-topic, so I have changed the > subject. > > Robert Sparks wrote: > > On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: > > > >>Hi > >>I have some questions about Refer-To header with > method=SUBSCIRBE or > >>method=REFER in it's URI. (rfc 3515) > > One thing troubles me about REFER, and my degree of > discomfort goes up > when is is applied in these more complex ways. The > issue is how the > referee is able to discern the implications of what > is being asked to do > - what corellary actions it should perform. > > For instance, in this case I might be able to tell > someone else to > subscribe to presence. But what should it do with > the information when > it is received? I don't have any good way to tell it > what I intend for > it to do, so by implication it must be presumed to > be able to figure it > out on its own, either because there is one single > thing it does with > such information, or because it can figure it out > from context, such as > based on who is asking. > > This is potentially a problem even for referring an > INVITE, but it is at > least tempting to believe that a given UA has only a > few alternatives > for what can do, that can be figured out from > context. E.g., when a > refer of invite is sent in an existing dialog where > an invite is active, > I believe there is an assumption that the receiving > UA will reassign the > local media resources so that they are connected to > the new call rather > than the old call. Many call flows assume this, but > AFAIK there is no > standard that says this. > > For other uses of refer I find it harder to convince > myself that the > recipient can infer the appropriate actions to take. > > This seems likely to lead to proprietary systems > that can't > interoperate, because they depend on remote devices > that make particular > assumptions about this. > > > Paul > > >>1. When receiving REFER request with > method=SUBSCIRBE, a new subscription > >>should be created. how do I know what is the event > of this subscription? > >>same problem for method=REFER, how do I know the > Refer-To header for the new > >>REFER? > >>Is there a draft defining such behavior? > > > > These can be defined using the URI "?" header > escaping mechanism: > > > > Some examples (which may not be completely escaped > correctly, but > > they show the spirit of the thing:) > > > > Refer-To: > sip:rjs-presence@example;method=SUBSCRIBE?Event=presence > > > > Refer-To: > > > sip:rjs-refer@example;method=REFER?Refer-To= > > > >>2. If I created this subscription, what are the > states of the new > >>subscription, that we should notify the referrer > of? only receiving > >>responses? what about receiving notifications (if > so, what will be the > >>status code in the body status line?)? > > > > > > The REFER creates an implicit subscription to the > status of the > > referrenced request and that only. So, if the > REFER is to a > > SUBSCRIBE, you will get notification about the > success or > > failure of that SUBSCRIBE transaction, but not > information > > about any future NOTIFYs due to that SUBSCRIBE. > > > > RjS > > > > > >> > >>Ofra > > > > > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Sep 26 22:48:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03730 for ; Fri, 26 Sep 2003 22:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3584-0007A8-Kz for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 22:48:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8R2mGVB027526 for sip-archive@odin.ietf.org; Fri, 26 Sep 2003 22:48:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A357p-00079A-9U; Fri, 26 Sep 2003 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A356r-00078C-BU for sip@optimus.ietf.org; Fri, 26 Sep 2003 22:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03667 for ; Fri, 26 Sep 2003 22:46:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A356n-0000si-00 for sip@ietf.org; Fri, 26 Sep 2003 22:46:57 -0400 Received: from i3smtp.inin.com ([204.180.46.24] helo=i3smtp.i3domain.inin.com) by ietf-mx with esmtp (Exim 4.12) id 1A356n-0000sP-00 for sip@ietf.org; Fri, 26 Sep 2003 22:46:57 -0400 Received: from Unknown [172.16.1.4] by i3smtp.i3domain.inin.com - SurfControl E-mail Filter (4.6); Friday, 26 September 2003, 21:46:08 Message-ID: <58A40B582A73F54AB5D8739C0678F3A804AEA4FD@i3exchange.i3domain.inin.com> From: "Szilagyi, Mike" To: "Rinchen Tundup" Cc: , "Merhdad Abrishami" Date: Fri, 26 Sep 2003 21:46:07 -0500 Subject: RE: [Sip] looking for SIP proxy server MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Sip] looking for SIP proxy server Thread-Index: AcOCa5v4EoMhURWKTXaexE2Vgab+cQCNcYvg Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here is another, www.freesipproxy.com -----Original Message----- From: Rinchen Tundup [mailto:rinchen@cdotd.ernet.in]=20 Sent: Wednesday, September 24, 2003 1:56 AM Cc: sip@ietf.org; Merhdad Abrishami Subject: Re: [Sip] looking for SIP proxy server Check this one too .. its free , with source code=20 http://www.nongnu.org/partysip/partysip.html =20 On Wed, 24 Sep 2003 uucp-relay-delhi!george_r@batmbg.com wrote: > Also you can check: >=20 > iptel.org > fwd.pulver.com > snom.com >=20 > these are free >=20 >=20 >=20 > MA> Hello, my name is Mehrdad Abrishami. I am new to the SIP mailing list. I am > MA> developing SIP UA for a DSL gateway. I am looking for a very low cost/free > MA> SIP proxy server for PC/Windows or PC/Linux that I can use with a CISCO 7940 > MA> IP phone. Your help would be appreciated. And from now on I'll be quite and > MA> just listen. >=20 > MA> Thanks, >=20 > MA> Mehrdad Abrishami >=20 >=20 >=20 > MA> _______________________________________________ > MA> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > MA> This list is for NEW development of the core SIP Protocol > MA> Use sip-implementors@cs.columbia.edu for questions on current sip > MA> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 > --=20 > mailto:george_r@batmbg.com >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 01:37:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13612 for ; Mon, 29 Sep 2003 01:37:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qin-0004Mz-Va for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 01:37:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T5bLH0016732 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 01:37:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qiU-0004JI-CW; Mon, 29 Sep 2003 01:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qhZ-0004Hl-Hj for sip@optimus.ietf.org; Mon, 29 Sep 2003 01:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13586 for ; Mon, 29 Sep 2003 01:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3qhW-0000z7-00 for sip@ietf.org; Mon, 29 Sep 2003 01:36:02 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1A3qhV-0000z4-00 for sip@ietf.org; Mon, 29 Sep 2003 01:36:01 -0400 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Mon, 29 Sep 2003 08:35:50 +0300 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 08:35:50 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E22A8A8@nt-mail.tlv.radvision.com> From: Ofra Wachsman To: "'Robert Sparks'" , Ofra Wachsman Cc: "'sip@ietf.org'" Date: Mon, 29 Sep 2003 08:35:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , thanks for the answer. about question 2 - you said that "if the REFER is to a SUBSCRIBE, you will get notification about the success or failure of that SUBSCRIBE transaction", but the first NOTIFY request is part of the subscription establishment. the subscription is not established until this request is accepted. so, shouldn't the referee send notification about the subscription establishment, and not about the SUBSCRIBE transaction? -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, September 26, 2003 5:04 PM To: Ofra Wachsman Cc: 'sip@ietf.org' Subject: Re: REFER request with method parameter != INVITE in refer-to header On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: > Hi > I have some questions about Refer-To header with method=SUBSCIRBE or > method=REFER in it's URI. (rfc 3515) > 1. When receiving REFER request with method=SUBSCIRBE, a new subscription > should be created. how do I know what is the event of this subscription? > same problem for method=REFER, how do I know the Refer-To header for the new > REFER? > Is there a draft defining such behavior? These can be defined using the URI "?" header escaping mechanism: Some examples (which may not be completely escaped correctly, but they show the spirit of the thing:) Refer-To: sip:rjs-presence@example;method=SUBSCRIBE?Event=presence Refer-To: sip:rjs-refer@example;method=REFER?Refer-To= > > 2. If I created this subscription, what are the states of the new > subscription, that we should notify the referrer of? only receiving > responses? what about receiving notifications (if so, what will be the > status code in the body status line?)? The REFER creates an implicit subscription to the status of the referrenced request and that only. So, if the REFER is to a SUBSCRIBE, you will get notification about the success or failure of that SUBSCRIBE transaction, but not information about any future NOTIFYs due to that SUBSCRIBE. RjS > > Ofra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 06:59:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04231 for ; Mon, 29 Sep 2003 06:59:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vkN-0002F5-6p for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 06:59:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TAxJu8008615 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 06:59:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vk5-0002EK-Tw; Mon, 29 Sep 2003 06:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vjG-0002CY-7M for sip@optimus.ietf.org; Mon, 29 Sep 2003 06:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04180 for ; Mon, 29 Sep 2003 06:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3vjB-0003eK-00 for sip@ietf.org; Mon, 29 Sep 2003 06:58:06 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1A3vjB-0003eH-00 for sip@ietf.org; Mon, 29 Sep 2003 06:58:05 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 29 Sep 2003 12:00:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Date: Mon, 29 Sep 2003 11:57:26 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B0BD@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Thread-Index: AcOGS6qaIcWPNZv/QjW9RZo5JZK7sAAK7hRQ From: "Chris Boulton" To: "Ofra Wachsman" , "Robert Sparks" Cc: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable <> >-----Original Message----- >From: Ofra Wachsman [mailto:Ofra@radvision.com] >Sent: 29 September 2003 06:36 >To: 'Robert Sparks'; Ofra Wachsman >Cc: 'sip@ietf.org' >Subject: [Sip] RE: REFER request with method parameter !=3D INVITE in refer- >to he ader > >thanks for the answer. >about question 2 - you said that "if the REFER is to a >SUBSCRIBE, you will get notification about the success or >failure of that SUBSCRIBE transaction", >but the first NOTIFY request is part of the subscription establishment. the >subscription is not established until this request is accepted. so, >shouldn't the referee send notification about the subscription >establishment, and not about the SUBSCRIBE transaction? [Chris Boulton] Not really - when you generate the SUBSCRIBE - you will be notified of the success of dialog creation - not necessarily subscription creation. The 200 OK to the SUBSCRIBE provides this information. > >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: Friday, September 26, 2003 5:04 PM >To: Ofra Wachsman >Cc: 'sip@ietf.org' >Subject: Re: REFER request with method parameter !=3D INVITE in = refer-to >header > > >On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: >> Hi >> I have some questions about Refer-To header with method=3DSUBSCIRBE = or >> method=3DREFER in it's URI. (rfc 3515) >> 1. When receiving REFER request with method=3DSUBSCIRBE, a new subscription >> should be created. how do I know what is the event of this subscription? >> same problem for method=3DREFER, how do I know the Refer-To header = for the >new >> REFER? >> Is there a draft defining such behavior? >These can be defined using the URI "?" header escaping mechanism: > >Some examples (which may not be completely escaped correctly, but >they show the spirit of the thing:) > >Refer-To: sip:rjs-presence@example;method=3DSUBSCRIBE?Event=3Dpresence > >Refer-To: >sip:rjs-refer@example;method=3DREFER?Refer-To=3D > >> >> 2. If I created this subscription, what are the states of the new >> subscription, that we should notify the referrer of? only receiving >> responses? what about receiving notifications (if so, what will be the >> status code in the body status line?)? > >The REFER creates an implicit subscription to the status of the >referrenced request and that only. So, if the REFER is to a >SUBSCRIBE, you will get notification about the success or >failure of that SUBSCRIBE transaction, but not information >about any future NOTIFYs due to that SUBSCRIBE. > >RjS > >> >> Ofra > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 07:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04307 for ; Mon, 29 Sep 2003 07:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vl7-0002PP-P3 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 07:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TB05OP009225 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 07:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vl6-0002OL-2A; Mon, 29 Sep 2003 07:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3vkG-0002Em-NB for sip@optimus.ietf.org; Mon, 29 Sep 2003 06:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04201 for ; Mon, 29 Sep 2003 06:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3vkC-0003en-00 for sip@ietf.org; Mon, 29 Sep 2003 06:59:08 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 1A3vkA-0003ek-00 for sip@ietf.org; Mon, 29 Sep 2003 06:59:06 -0400 Received: from nt-mail.tlv.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Mon, 29 Sep 2003 13:58:56 +0300 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 13:58:56 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E22A8AA@nt-mail.tlv.radvision.com> From: Ofra Wachsman To: "'Robert Sparks'" Cc: "'sip@ietf.org'" Date: Mon, 29 Sep 2003 13:58:55 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , another thing - is it possible to set in the method parameter of the Refer-To URI, a method that does not create a dialog? (method different than INVITE, SUBSCRIBE or REFER)? -----Original Message----- From: Ofra Wachsman Sent: Monday, September 29, 2003 8:36 AM To: 'Robert Sparks'; Ofra Wachsman Cc: 'sip@ietf.org' Subject: RE: REFER request with method parameter != INVITE in refer-to header thanks for the answer. about question 2 - you said that "if the REFER is to a SUBSCRIBE, you will get notification about the success or failure of that SUBSCRIBE transaction", but the first NOTIFY request is part of the subscription establishment. the subscription is not established until this request is accepted. so, shouldn't the referee send notification about the subscription establishment, and not about the SUBSCRIBE transaction? -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, September 26, 2003 5:04 PM To: Ofra Wachsman Cc: 'sip@ietf.org' Subject: Re: REFER request with method parameter != INVITE in refer-to header On Thu, 2003-09-25 at 06:02, Ofra Wachsman wrote: > Hi > I have some questions about Refer-To header with method=SUBSCIRBE or > method=REFER in it's URI. (rfc 3515) > 1. When receiving REFER request with method=SUBSCIRBE, a new subscription > should be created. how do I know what is the event of this subscription? > same problem for method=REFER, how do I know the Refer-To header for the new > REFER? > Is there a draft defining such behavior? These can be defined using the URI "?" header escaping mechanism: Some examples (which may not be completely escaped correctly, but they show the spirit of the thing:) Refer-To: sip:rjs-presence@example;method=SUBSCRIBE?Event=presence Refer-To: sip:rjs-refer@example;method=REFER?Refer-To= > > 2. If I created this subscription, what are the states of the new > subscription, that we should notify the referrer of? only receiving > responses? what about receiving notifications (if so, what will be the > status code in the body status line?)? The REFER creates an implicit subscription to the status of the referrenced request and that only. So, if the REFER is to a SUBSCRIBE, you will get notification about the success or failure of that SUBSCRIBE transaction, but not information about any future NOTIFYs due to that SUBSCRIBE. RjS > > Ofra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 09:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14586 for ; Mon, 29 Sep 2003 09:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yK1-0002qr-7t for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 09:44:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDiHl6010904 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 09:44:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yJl-0002pO-Tr; Mon, 29 Sep 2003 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yJj-0002p7-Nu for sip@optimus.ietf.org; Mon, 29 Sep 2003 09:43:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14573 for ; Mon, 29 Sep 2003 09:43:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yJh-0005vO-00 for sip@ietf.org; Mon, 29 Sep 2003 09:43:57 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A3yJh-0005vE-00 for sip@ietf.org; Mon, 29 Sep 2003 09:43:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8TDhCd32494; Mon, 29 Sep 2003 08:43:12 -0500 From: Robert Sparks To: Ofra Wachsman Cc: "'sip@ietf.org'" In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E22A8AA@nt-mail.tlv.radvision.com> References: <99FF181D4C99564F8D623069E1DDB25E22A8AA@nt-mail.tlv.radvision.com> Content-Type: text/plain Message-Id: <1064842991.889.0.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 29 Sep 2003 08:43:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2003-09-29 at 05:58, Ofra Wachsman wrote: > another thing - is it possible to set in the method parameter of the > Refer-To URI, a method that does not create a dialog? (method different than > INVITE, SUBSCRIBE or REFER)? Yes. You can also set it to a non sip: URI (such as http). RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 09:52:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14925 for ; Mon, 29 Sep 2003 09:52:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yRe-0003PI-NP for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 09:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDqA8f013039 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 09:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yRV-0003K1-Qy; Mon, 29 Sep 2003 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yRG-0003Jf-S2 for sip@optimus.ietf.org; Mon, 29 Sep 2003 09:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14903 for ; Mon, 29 Sep 2003 09:51:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yRE-00062F-00 for sip@ietf.org; Mon, 29 Sep 2003 09:51:44 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A3yRE-000621-00 for sip@ietf.org; Mon, 29 Sep 2003 09:51:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8TDp8d32667; Mon, 29 Sep 2003 08:51:08 -0500 From: Robert Sparks To: Ofra Wachsman Cc: "'sip@ietf.org'" In-Reply-To: <99FF181D4C99564F8D623069E1DDB25E22A8A8@nt-mail.tlv.radvision.com> References: <99FF181D4C99564F8D623069E1DDB25E22A8A8@nt-mail.tlv.radvision.com> Content-Type: text/plain Message-Id: <1064843468.889.9.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 29 Sep 2003 08:51:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] RE: REFER request with method parameter != INVITE in refer-to he ader Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2003-09-29 at 00:35, Ofra Wachsman wrote: > thanks for the answer. > about question 2 - you said that "if the REFER is to a > SUBSCRIBE, you will get notification about the success or > failure of that SUBSCRIBE transaction", > but the first NOTIFY request is part of the subscription establishment. the > subscription is not established until this request is accepted. so, > shouldn't the referee send notification about the subscription > establishment, and not about the SUBSCRIBE transaction? > No - the implicit subscription tells you only about how the referenced request. Chris noted that you can infer whether a dialog was established by a referred SUBSCRIBE based on its final response, and that's mostly true (there's a degenerate condition where a very delayed 200 could arrive at a proxy after the proxy has sent its final response). But all you know from this is that _some_ dialog has been created. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 12:06:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26317 for ; Mon, 29 Sep 2003 12:06:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A40XV-00021h-8T for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 12:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TG6L6X007788 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 12:06:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A40XB-00020q-V4; Mon, 29 Sep 2003 12:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A40X4-00020M-ML for sip@optimus.ietf.org; Mon, 29 Sep 2003 12:05:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26243 for ; Mon, 29 Sep 2003 12:05:46 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A40X3-00013u-00 for sip@ietf.org; Mon, 29 Sep 2003 12:05:53 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A40X2-00013p-00 for sip@ietf.org; Mon, 29 Sep 2003 12:05:52 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TG5ot00561 for ; Mon, 29 Sep 2003 19:05:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Sep 2003 19:05:50 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 19:05:50 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re:draft-ietf-sip-publish-00.txt Date: Mon, 29 Sep 2003 19:05:50 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> Thread-Topic: [Sip] Re:draft-ietf-sip-publish-00.txt Thread-Index: AcOEXMi9JtwzDsEiQWK4xqkn4es/7wCBbCeg To: , X-OriginalArrivalTime: 29 Sep 2003 16:05:50.0488 (UTC) FILETIME=[8D4C3980:01C386A3] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for the comments - responses inline. > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 26 September, 2003 21:32 > To: sip@ietf.org > Subject: [Sip] Re:draft-ietf-sip-publish-00.txt >=20 >=20 > I'm sorry to be late with comments on this draft - it just=20 > slipped down=20 > the priority queue until I saw the proposal for last call. >=20 > Below are a number of comments. >=20 > Paul >=20 > Section 3: >=20 > Last sentence says "Both the source and the target of the > publication are naturally represented as an address-of-record.") >=20 > I don't think this is right. At least it is no more true than saying > "Both the source and the target of an invitation are naturally > represented as an address-of-record." >=20 > This is especially a problem for the source of publication. Certainly > the source isn't *uniquely* represented by an AOR - in typical cases > there may be many sources that all share an AOR. Nor is it=20 > necessary for > the source to have any AOR at all. I don't think the current wording suggests uniqueness - the text is = trying to state target and source as in To and From.=20 > The statement is closer to true for the target. I think we all expect > the typical usage to be that PUBLISH requests are aimed at an AOR and > then routed to an appropriate contact address by a proxy.=20 > But of course > this usage isn't required, any more than it is with invite.=20 > And while we > may understand expected typical usage with presence,=20 > different patterns > may be appropriate for other event packages. Agreed. This is analogous to REGISTER in that To is the target AoR for = the binding, and From is the creator of that address binding. >=20 > I'm not convinced that it is necessary to replace this sentence with > anything. If you feel a need to say something, how about: >=20 > "Often, publication requests will originate from endpoints associated > with an address-of-record and be directed to that address-of-record." How about: The target of the publication is naturally represented by the address = in=20 the To header field. Similarly, the address in the From header field=20 identifies the party responsible for the publication.=20 In case of presence, the To could actually contain a pres: URI and not a = (SIP or SIPS) AoR. This should probably be mentioned somewhere? >=20 > ----- >=20 > Section 5: >=20 > Request-URI: The Request-URI initially contains the=20 > address-of-record > whose publication is to be created, removed, or modified. The > address-of-record MUST be a SIP URI or SIPS URI. Unlike the > REGISTER request, the Request-URI SHOULD contain both=20 > "userinfo" > and "@" components. >=20 > I see no reason for this. The request-uri is all about routing, and=20 > routing is fully specified in 3261. There is no reason to=20 > muck with this=20 > here.=20 I agree. Will remove that. > By the time the request arrives, the request-uri won't=20 > contain an=20 > AOR. Whether it had one initially or not is of no=20 > consequence. The ESC=20 > must decide what presence document to operate on based on=20 > the content of=20 > the message received. This decision will presumably be made=20 > based on the=20 > request-uri at that time, together with the presumed=20 > association of that=20 > with a particular AOR/presence document. (Or maybe it will=20 > be made based=20 > on the content of the To field.) The intention is exactly that - the decision is based on the To field. >=20 > ----- >=20 > Section 5: >=20 > To: The To header field contains the address-of-record whose > publication is to be created, removed, or modified.=20 > The To header > field and the Request-URI field are typically the same. This > address-of-record MUST be a SIP URI or SIPS URI. >=20 > I think there is some question whether the To should be used=20 > to select=20 > the presence doc or whether the request uri should be used.=20 > It depends=20 > on what we expect to happen in the case of forwarding. >=20 > Suppose sip:alice@atlanta.com forwards everything to=20 > sip:bob@biloxi.com.=20 > Then suppose something sends a PUBLISH to alice. This will=20 > get forwarded=20 > to the ESC registed for bob. Now, does it refuse the request=20 > because the=20 > To references alice, or does it update the presence of bob?=20 > I haven't=20 > decided what I think the right answer is. But I think it ought to be=20 > consistent with what happens to SUBSCRIBE requests addressed=20 > to alice. Here I disagree. I think what happens should be consistent with what = happens to REGISTER requests addressed to alice's registrar. If the = PUBLISH lands on a UA that doesn't handle publications for the address = in the To, it should reject it. > ----- >=20 > Section 6: >=20 > The Event State Compositor (ESC) is a UAS that processes=20 > and responds > to PUBLISH requests, and maintains a list of=20 > publications for a given > address-of-record. The ESC has to know (e.g., through=20 > configuration) > the domain or set of domains for which it maintains event state. >=20 > This makes an assumption that a given ESC is responsible for=20 > a domain or=20 > domains. This need not be the case. It may simply be=20 > responsible for a=20 > few specific users. Proxy routing logic can get things to=20 > the right ESC.=20 > I think this could be reworded as: >=20 > "The ESC has to know (e.g., through configuration) the set=20 > of addresses=20 > for which it maintains event state." Agreed. I will replace the text.=20 =20 > ----- >=20 > Section 6: >=20 > A client may probe the ESC for the support of PUBLISH using the > OPTIONS request defined in SIP [2]. In the response to such an > OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of > allowed methods in the Allow header field. Also, it=20 > SHOULD list the > supported event packages in an Allow-Events header field. >=20 > It may be tricky to get this to work. If the ESC is itself=20 > registered as=20 > one of the contacts of the AOR, then a straightforward OPTIONS will=20 > fork, and only the first response will get back. That might=20 > not be from=20 > the ESC. >=20 > To get around that, it may be necessary to use callerprefs=20 > to direct the=20 > OPTIONS to the ESC, perhaps via something like: >=20 > OPTIONS sip:user@domain > To: sip:user@domain > From: sip:somebody@domain > Accept-Contact: *;methods=3D"SUBSCRIBE";events=3D"presence" >=20 > Having said that, I don't know how much of it needs to be in=20 > the spec.=20 > Maybe just a warning. Agreed. I will add a note to this effect. =20 > ------ >=20 > Section 6: >=20 > 1. The ESC inspects the Request-URI to determine whether this > request is for a domain supported by the ESC. If=20 > not, the ESC > SHOULD proxy the request to the addressed domain. >=20 > The ESC is a UA. UAs are typically not required to act as=20 > proxies. In=20 > any case, this bullet is all about standard 3261 behavior.=20 > Don't think=20 > it needs to be said. I agree. This is leftovers from reuse of the steps in 3261 describing = registrar behavior. =20 > ------- >=20 > Section 6: >=20 > 4. The ESC SHOULD determine if the authenticated user=20 > is authorized > to perform event state publication for the=20 > address-of-record of > the To header field. >=20 > This goes to my question above about whether selection of the=20 > presentity/presence document should be based on the request uri or=20 > To-uri. Here it clearly specifys this. >=20 > The problem with this is that I don't believe it is consistent with=20 > SUBSCRIBE. > > ------- >=20 > Section 6: >=20 > 5. The ESC extracts the address-of-record from the To=20 > header field > of the request. If the address-of-record is not=20 > valid for the > domain in the Request-URI, the ESC MUST send a 404=20 > (Not Found) > response and skip the remaining steps. >=20 > Again I think this is over specifying. There need not be any=20 > specific=20 > relationship between the domain in the request uri and the=20 > domain in the=20 > To uri, though there often will be. But it could be completely=20 > reasonable for some server at sip:presenceRus.com to act as=20 > an ESC for=20 > users in any number of domains. >=20 > *If* the To address is to be used for choosing the presence=20 > document to=20 > be affected, it would be better to say: >=20 > "The ESC extracts the address-of-record from the To header=20 > field of the=20 > request. If the ESC does not manage event state for this address, it=20 > MUST send a 404 (Not Found) response and skip the remaining steps." Agreed. In fact, RFC 3261 says UAS should reject with 403 if the To = isn't known and not acceptable as such. Also, this part of step 5 should = in my opinion be the very first thing the ESC does. So my proposal for = changing the text and the steps would be: 1. The ESC inspects the To header field to determine whether this request is targeted for a resource, for which the ESC is responsible=20 for maintaining event state. If not, the ESC MUST return a 403=20 (Forbidden) and skip the remaining steps. --- 5. Next, the URI in the To header field is converted to a canonical=20 form. To do that, all URI parameters MUST be removed (including the=20 user-param), and any escaped characters MUST be converted to their=20 unescaped form. The result serves as an index into the list of = resources=20 whose event state is maintained by the ESC. Cheers, Aki >=20 > [THE END] >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 13:06:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28952 for ; Mon, 29 Sep 2003 13:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41TO-0005GW-2e for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 13:06:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TH6Aix020234 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 13:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41TF-0005Fp-Fs; Mon, 29 Sep 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41Sh-0005FP-Pq for sip@optimus.ietf.org; Mon, 29 Sep 2003 13:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28916 for ; Mon, 29 Sep 2003 13:05:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41Sg-0001uB-00 for sip@ietf.org; Mon, 29 Sep 2003 13:05:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A41Sf-0001tw-00 for sip@ietf.org; Mon, 29 Sep 2003 13:05:25 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2003 10:04:10 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8TH4q5g024574; Mon, 29 Sep 2003 13:04:53 -0400 (EDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOU57273; Mon, 29 Sep 2003 10:04:51 -0700 (PDT) Message-ID: <3F786633.2010400@cisco.com> Date: Mon, 29 Sep 2003 13:04:51 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes CC: Jean-Francois Mule , "'sip@ietf.org'" , "'rohan@cisco.com'" References: <870397D7C140C84DB081B88396458DAF578BC0@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit mary, responding to the nits/general comments.... Mary Barnes wrote: > Hi all, > > Per my assignment, I've reviewed sections 7.2 and 8 through 10 of the MIB, > with the following general comments and nits. I have a few specific points > that require discussion that I'll post in separate emails to facilitate WG > discussion and hopefully to allow easier tracking of issues. I did try to > conscientiously review previous comments on the mailing list and to review > previous versions to make sure that I wasn't bringing up things for which > there had been consensus. I do apologize if I inadvertently open an issue > that was truly closed by the WG. > > - Section 7.2, page 14. The descriptions need to be updated to reflect RFC > 3261 (section 6) terminology/definitions for User Agent, Proxy Server, > Redirect Server and Registrar. done. > > - Section 7.2, page 15. Really minor nit, but I found it very difficult to > read the common MIB objects with no blank lines between the comment lines > and the object definitions. done. > > - Section 7.2, page 20. sipEntitytype. Per Cullen's comments not > separating the Proxy and Redirect Server, this would need to be reflected in > this object definition. pending resolution of cullen's comments on no seperate representation of proxy and redirect servers in the mib. > > - Section 8: My understanding is that this section should be removed by the > RFC Editor. Thus, I would suggest adding a comment as such (something like: > "This section to be removed by RFC Editor before publication." and moving > this section just prior to the Author's address to facilitate that process. done (patially). i added the line you suggested to the section, but didn't move the section. the xml2rfc tool we've started using appears rather ridge in some of the "template" sections. i'm not exactly certain on altering the order of sections that are part of the . how important is it that we move this section since it will be removed anyway? > > - Section 9, page 109. The statement "If these objects are SET maliciously, > it may result in > incorrect or unwanted protocol operation." is probably a bit of an > understatement with regards to the timer, retry and expire values being > misconfigured. Certainly, a well designed system would but reasonable > boundaries on how these things can be configured, so as to hopefully prevent > significant problems. Cullen had brought up the more general issue of > whether all the timers should be configurable in his comments. Like Cullen, > I haven't thought about this enough to decide whether all these timers > should be configurable, but at a minimum, I think the security section > needs a more robust statement. is this commented wrt the entire security section or just the area you referred to on pg 109? is it that we have not made a strong enough statement about the protocol impact to these particular timer/retry related objects being SET?? thanks! kevin > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > > > > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 14:02:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01329 for ; Mon, 29 Sep 2003 14:02:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42Lg-0000Lt-Df for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 14:02:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TI2GLk001347 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 14:02:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42LS-0000Kx-LD; Mon, 29 Sep 2003 14:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42LC-0000KY-91 for sip@optimus.ietf.org; Mon, 29 Sep 2003 14:01:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01279 for ; Mon, 29 Sep 2003 14:01:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42LA-0002Xq-00 for sip@ietf.org; Mon, 29 Sep 2003 14:01:44 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1A42L8-0002Xm-00 for sip@ietf.org; Mon, 29 Sep 2003 14:01:43 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h8TI1fWe029219 for ; Mon, 29 Sep 2003 11:01:41 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h8TI1bCi025776 for ; Mon, 29 Sep 2003 13:01:38 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Mon, 29 Sep 2003 13:01:33 -0500 Message-ID: <8F37768D4D9CD71192CF00065BF2598B931F8D@il27exm02.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: sip@ietf.org Date: Mon, 29 Sep 2003 13:01:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C386B3.B74F90BE" Subject: [Sip] A SIP grammar question. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C386B3.B74F90BE Content-Type: text/plain Hi All, I had a question about the 'From' and 'To' addresses in SIP, and while I was going through the grammar, I noticed that the grammar allows for a 'From' and 'To' address to NOT have any 'userinfo' in the name-addr spec. Is this really desired? Or was this done so as to accommodate the Request-URI in the same grammar rules? If this was desired, under what circumstances one would have a 'From' or 'To' address with no 'userinfo'. Could you have a 'From' address of 'From: Anonymous ', when the identity of the caller is to be hidden? For your convenience I am including the relevant grammar lines from the RFC below. FROM ADDRESS ============ From = ( "From" / "f" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = "tag" EQUAL token TO ADDRESS ========== To = ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param REQUEST-URI =========== Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme ":" ( hier-part / opaque-part ) NAME-ADDR ========= name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," ) hostport = host [ ":" port ] Appreciate your help Thanks and Regards - Ajay ------_=_NextPart_001_01C386B3.B74F90BE Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxucz0iaHR0 cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ Vj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0K DQoNCjxtZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9 R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIj4NCjxtZXRhIG5hbWU9T3JpZ2lu YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhy ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDMzg2ODkuQ0Y4MUQ1RTAiPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25D U1MvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0 YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpH cmFtbWFyU3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50 S2luZD4NCiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdH cmlkRXZlcnk+MDwvdzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OkRp c3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MDwvdzpEaXNwbGF5VmVydGljYWxEcmF3aW5n R3JpZEV2ZXJ5Pg0KICA8dzpVc2VNYXJnaW5zRm9yRHJhd2luZ0dyaWRPcmlnaW4vPg0KICA8dzpD b21wYXRpYmlsaXR5Pg0KICAgPHc6Rm9vdG5vdGVMYXlvdXRMaWtlV1c4Lz4NCiAgIDx3OlNoYXBl TGF5b3V0TGlrZVdXOC8+DQogICA8dzpBbGlnblRhYmxlc1Jvd0J5Um93Lz4NCiAgIDx3OkZvcmdl dExhc3RUYWJBbGlnbm1lbnQvPg0KICAgPHc6RG9Ob3RVc2VIVE1MUGFyYWdyYXBoQXV0b1NwYWNp bmcvPg0KICAgPHc6TGF5b3V0UmF3VGFibGVXaWR0aC8+DQogICA8dzpMYXlvdXRUYWJsZVJvd3NB cGFydC8+DQogICA8dzpVc2VXb3JkOTdMaW5lQnJlYWtpbmdSdWxlcy8+DQogIDwvdzpDb21wYXRp YmlsaXR5Pg0KICA8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6 QnJvd3NlckxldmVsPg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxz dHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjIgNyA0IDkgMiAyIDUgMiA0IDQ7DQoJbXNvLWZv bnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9u dC1mb3JtYXQ6b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0 dXJlOjMgMCAwIDAgMSAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRv dy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpBcmlhbDsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWhh bnNpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5TcGVsbEUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNv LXNwbC1lOnllczt9DQpzcGFuLkdyYW1FDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFt LWU6eWVzO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNv LWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rpb24x DQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4N CjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJs ZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQt c2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5 ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBp biA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxlPg0KPCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBz dHlsZT0ndGFiLWludGVydmFsOi41aW4nPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0 b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpD b3VyaWVyJz5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFj ZTpub25lJz48Zm9udA0Kc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmll cic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25l Jz48Zm9udA0Kc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+SSBo YWQgYSBxdWVzdGlvbiBhYm91dCB0aGUgJ0Zyb20nIGFuZA0KJzxzcGFuIGNsYXNzPUdyYW1FPlRv PC9zcGFuPicgYWRkcmVzc2VzIGluIFNJUCwgYW5kIHdoaWxlIEkgd2FzDQpnb2luZyB0aHJvdWdo IHRoZSBncmFtbWFyLCBJIG5vdGljZWQgdGhhdCB0aGUgZ3JhbW1hciBhbGxvd3MgZm9yIGEgJ0Zy b20nDQphbmQgJ1RvJyBhZGRyZXNzIHRvIE5PVCBoYXZlIGFueSAnPHNwYW4gY2xhc3M9U3BlbGxF PnVzZXJpbmZvPC9zcGFuPicNCmluIHRoZSBuYW1lLTxzcGFuIGNsYXNzPVNwZWxsRT5hZGRyPC9z cGFuPiBzcGVjLiBJcyB0aGlzIHJlYWxseSBkZXNpcmVkPyBPciB3YXMNCnRoaXMgZG9uZSBzbyBh cyB0byBhY2NvbW1vZGF0ZSB0aGUgUmVxdWVzdC1VUkkgaW4gdGhlIHNhbWUgZ3JhbW1hciBydWxl cz8gSWYNCnRoaXMgd2FzIGRlc2lyZWQsIHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcyBvbmUgd291 bGQgaGF2ZSBhICdGcm9tJw0Kb3IgJzxzcGFuIGNsYXNzPUdyYW1FPlRvPC9zcGFuPicgYWRkcmVz cyB3aXRoIG5vICc8c3Bhbg0KY2xhc3M9U3BlbGxFPnVzZXJpbmZvPC9zcGFuPicuIENvdWxkIHlv dSBoYXZlIGEgJ0Zyb20nDQphZGRyZXNzIG9mICdGcm9tOiBBbm9ueW1vdXMgJmx0OzxzcGFuIGNs YXNzPVNwZWxsRT5zaXA8c3BhbiBjbGFzcz1HcmFtRT46YW5vbnltb3VzLmludmFsaWQ8L3NwYW4+ PC9zcGFuPiZndDsnLA0Kd2hlbiB0aGUgaWRlbnRpdHkgb2YgdGhlIGNhbGxlciBpcyB0byBiZSBo aWRkZW4/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48 Zm9udA0Kc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udA0K c2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+Rm9yIHlvdXIgY29u dmVuaWVuY2UgSSBhbSBpbmNsdWRpbmcgdGhlIHJlbGV2YW50DQpncmFtbWFyIGxpbmVzIGZyb20g dGhlIFJGQyBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNl Om5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVy Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUn Pjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5GUk9N IEFERFJFU1M8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUn Pjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz49PT09 PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUn Pjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250 DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5Gcm9tID0gPHNw YW4gY2xhc3M9R3JhbUU+KCAmcXVvdDs8L3NwYW4+RnJvbSZxdW90Ow0KLyAmcXVvdDtmJnF1b3Q7 ICkgSENPTE9OIGZyb20tc3BlYzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRv c3BhY2U6bm9uZSc+PHNwYW4NCmNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUNvdXJpZXI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpDb3VyaWVyO21zby1i aWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPmZyb20tc3BlYzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxm b250DQpmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJp ZGktZm9udC1mYW1pbHk6Q291cmllcic+ID0NCiggbmFtZS08c3BhbiBjbGFzcz1TcGVsbEU+YWRk cjwvc3Bhbj4gLyA8c3BhbiBjbGFzcz1TcGVsbEU+YWRkcjwvc3Bhbj4tc3BlYyApPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5 b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udA0Kc2l6ZT0yIGZh Y2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3Vy aWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+KjxzcGFuIGNsYXNzPUdyYW1FPigg U0VNSTwvc3Bhbj4gZnJvbS08c3Bhbg0KY2xhc3M9U3BlbGxFPnBhcmFtPC9zcGFuPiApPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bhbg0KY2xhc3M9 R3JhbUU+PGZvbnQgc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToNCkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+ ZnJvbS08c3BhbiBjbGFzcz1TcGVsbEU+cGFyYW08L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+ PGZvbnQNCmZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz4gPQ0KdGFnLTxzcGFuIGNsYXNzPVNwZWxsRT5wYXJh bTwvc3Bhbj4gLyBnZW5lcmljLTxzcGFuIGNsYXNzPVNwZWxsRT5wYXJhbTwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1s YXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuDQpjbGFzcz1H cmFtRT48Zm9udCBzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Og0KQ291cmllcjttc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz50 YWctPHNwYW4gY2xhc3M9U3BlbGxFPnBhcmFtPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxm b250DQpmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJp ZGktZm9udC1mYW1pbHk6Q291cmllcic+ID0NCiZxdW90O3RhZyZxdW90OyBFUVVBTCB0b2tlbjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQNCnNp emU9MiBmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q291cmllcjsNCm1zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxh eW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQNCnNpemU9MiBm YWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291 cmllcjsNCm1zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPlRPIEFERFJFU1M8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFj ZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz49PT09PT09PT09PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0 LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udA0Kc2l6ZT0yIGZhY2U9 Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ow0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQt YWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udA0Kc2l6ZT0yIGZhY2U9Q291cmll cj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyOw0KbXNv LWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+VG8gPSA8c3BhbiBjbGFzcz1HcmFtRT4oICZxdW90 Ozwvc3Bhbj5UbyZxdW90OyAvDQomcXVvdDt0JnF1b3Q7ICkgSENPTE9OICggbmFtZS08c3BhbiBj bGFzcz1TcGVsbEU+YWRkcjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQt YXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWls eTpDb3VyaWVyJz4vIDxzcGFuIGNsYXNzPVNwZWxsRT5hZGRyPC9zcGFuPi08c3Bhbg0KY2xhc3M9 R3JhbUU+c3BlYyApPC9zcGFuPiAqKCBTRU1JIHRvLTxzcGFuIGNsYXNzPVNwZWxsRT5wYXJhbTwv c3Bhbj4gKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+ PHNwYW4NCmNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFt aWx5OkNvdXJpZXInPnRvLTxzcGFuIGNsYXNzPVNwZWxsRT5wYXJhbTwvc3Bhbj48L3NwYW4+PC9m b250Pjwvc3Bhbj48Zm9udA0KZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpD b3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPiA9DQp0YWctPHNwYW4gY2xhc3M9 U3BlbGxFPnBhcmFtPC9zcGFuPiAvIGdlbmVyaWMtPHNwYW4gY2xhc3M9U3BlbGxFPnBhcmFtPC9z cGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZv bnQNCnNpemU9MiBmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllcjsNCm1zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PGZvbnQNCnNp emU9MiBmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q291cmllcjsNCm1zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPlJFUVVFU1QtVVJJPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48Zm9udA0Kc2l6 ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+PT09PT09PT09PT08bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXpl PTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFj ZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5SZXF1ZXN0LVVSSSA9IFNJUC1VUkkg LyBTSVBTLVVSSSAvIDxzcGFuDQpjbGFzcz1TcGVsbEU+YWJzb2x1dGVVUkk8L3NwYW4+PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bhbg0KY2xhc3M9 U3BlbGxFPjxzcGFuIGNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUNvdXJpZXI+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJpZGktZm9u dC1mYW1pbHk6Q291cmllcic+YWJzb2x1dGVVUkk8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+ PGZvbnQNCmZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz4gPQ0Kc2NoZW1lICZxdW90OzomcXVvdDsgKCA8c3Bh biBjbGFzcz1TcGVsbEU+aGllcjwvc3Bhbj4tcGFydCAvIG9wYXF1ZS1wYXJ0ICk8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlv dXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFj ZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXI7DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3Jp ZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3Vy aWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQpt c28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5OQU1FLUFERFI8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz49PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGln bjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVyPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28tYmlk aS1mb250LWZhbWlseTpDb3VyaWVyJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25l O3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuDQpjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFj ZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQ291 cmllcjttc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5uYW1lLTxzcGFuIGNsYXNzPVNwZWxs RT5hZGRyPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxmb250DQpmYWNlPUNvdXJpZXI+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmll cic+ID0NClsgZGlzcGxheS1uYW1lIF0gTEFRVU9UIDxzcGFuIGNsYXNzPVNwZWxsRT5hZGRyPC9z cGFuPi1zcGVjIFJBUVVPVDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1hdXRvc3Bh Y2U6bm9uZSc+PHNwYW4NCmNsYXNzPVNwZWxsRT48c3BhbiBjbGFzcz1HcmFtRT48Zm9udCBzaXpl PTIgZmFjZT1Db3VyaWVyPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPmFkZHI8L3NwYW4+PC9mb250 Pjwvc3Bhbj48L3NwYW4+PHNwYW4NCmNsYXNzPUdyYW1FPjxmb250IGZhY2U9Q291cmllcj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28tYmlkaS1mb250LWZhbWlseToNCkNvdXJp ZXInPi1zcGVjPC9zcGFuPjwvZm9udD48L3NwYW4+PGZvbnQgZmFjZT1Db3VyaWVyPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToNCkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+ ID0gU0lQLVVSSSAvIFNJUFMtVVJJIC8gPHNwYW4NCmNsYXNzPVNwZWxsRT5hYnNvbHV0ZVVSSTwv c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1sYXlvdXQtZ3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxz cGFuDQpjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQ291cmllcjttc28tYmlkaS1mb250LWZhbWls eTpDb3VyaWVyJz5kaXNwbGF5LW5hbWU8L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9udA0KZmFjZT1D b3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFt aWx5OkNvdXJpZXInPiA9DQoqKHRva2VuIExXUykvIHF1b3RlZC1zdHJpbmc8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQt Z3JpZC1hbGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1D b3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQptc28tYmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5TSVAtVVJJID0gJnF1b3Q7c2lwOiZxdW90OyA8c3Bh biBjbGFzcz1HcmFtRT5bIDxzcGFuDQpjbGFzcz1TcGVsbEU+dXNlcmluZm88L3NwYW4+PC9zcGFu PiBdIDxzcGFuIGNsYXNzPVNwZWxsRT5ob3N0cG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuDQpjbGFzcz1TcGVsbEU+PHNwYW4g Y2xhc3M9R3JhbUU+PGZvbnQgc2l6ZT0yIGZhY2U9Q291cmllcj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjttc28tYmlkaS1mb250LWZhbWlseTpDb3Vy aWVyJz51cmk8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PHNwYW4NCmNsYXNzPUdyYW1FPjxm b250IGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28tYmlk aS1mb250LWZhbWlseToNCkNvdXJpZXInPi1wYXJhbWV0ZXJzPC9zcGFuPjwvZm9udD48L3NwYW4+ PGZvbnQgZmFjZT1Db3VyaWVyPjxzcGFuDQpzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz4gWyBoZWFkZXJzIF08bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1sYXlvdXQtZ3JpZC1h bGlnbjpub25lO3RleHQtYXV0b3NwYWNlOm5vbmUnPjxmb250DQpzaXplPTIgZmFjZT1Db3VyaWVy PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQptc28t YmlkaS1mb250LWZhbWlseTpDb3VyaWVyJz5TSVBTLVVSSSA9ICZxdW90O3NpcHM6JnF1b3Q7IDxz cGFuIGNsYXNzPUdyYW1FPlsgPHNwYW4NCmNsYXNzPVNwZWxsRT51c2VyaW5mbzwvc3Bhbj48L3Nw YW4+IF0gPHNwYW4gY2xhc3M9U3BlbGxFPmhvc3Rwb3J0PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlk LWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4NCmNsYXNzPVNwZWxsRT48c3Bh biBjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNv dXJpZXInPnVyaTwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48c3Bhbg0KY2xhc3M9R3JhbUU+ PGZvbnQgZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO21zby1i aWRpLWZvbnQtZmFtaWx5Og0KQ291cmllcic+LXBhcmFtZXRlcnM8L3NwYW4+PC9mb250Pjwvc3Bh bj48Zm9udCBmYWNlPUNvdXJpZXI+PHNwYW4NCnN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVyO21z by1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPiBbIGhlYWRlcnMgXTxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlk LWFsaWduOm5vbmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4NCmNsYXNzPVNwZWxsRT48c3Bh biBjbGFzcz1HcmFtRT48Zm9udCBzaXplPTIgZmFjZT1Db3VyaWVyPjxzcGFuDQpzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNv dXJpZXInPnVzZXJpbmZvPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjxmb250DQpmYWNlPUNv dXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1p bHk6Q291cmllcic+ID0NCiggdXNlciAvIHRlbGVwaG9uZS1zdWJzY3JpYmVyICkgWyAmcXVvdDs6 JnF1b3Q7IHBhc3N3b3JkIF0gJnF1b3Q7QCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5v bmU7dGV4dC1hdXRvc3BhY2U6bm9uZSc+PHNwYW4NCmNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBm YWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpD b3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPnVzZXI8L3NwYW4+PC9mb250Pjwv c3Bhbj48Zm9udA0KZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb3VyaWVy O21zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPiA9DQoxKiggdW5yZXNlcnZlZCAvIGVzY2Fw ZWQgLyB1c2VyLXVucmVzZXJ2ZWQgKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxheW91dC1ncmlkLWFsaWduOm5vbmU7dGV4dC1h dXRvc3BhY2U6bm9uZSc+PGZvbnQNCnNpemU9MiBmYWNlPUNvdXJpZXI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjsNCm1zby1iaWRpLWZvbnQtZmFtaWx5 OkNvdXJpZXInPnVzZXItdW5yZXNlcnZlZCA9ICZxdW90OyZhbXA7JnF1b3Q7IC8NCiZxdW90Oz0m cXVvdDsgLyAmcXVvdDsrJnF1b3Q7IC8gJnF1b3Q7JCZxdW90OyAvICZxdW90OywmcXVvdDsgLyAm cXVvdDs7JnF1b3Q7IC8NCiZxdW90Oz8mcXVvdDsgLyAmcXVvdDsvJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0 LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bhbg0KY2xhc3M9R3JhbUU+ PGZvbnQgc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToNCkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmllcic+cGFzc3dv cmQ8L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9udA0KZmFjZT1Db3VyaWVyPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseTpDb3VyaWVyO21zby1iaWRpLWZvbnQtZmFtaWx5OkNvdXJpZXInPiA9DQoqKCB1 bnJlc2VydmVkIC8gZXNjYXBlZCAvPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxpZ246bm9uZTt0ZXh0LWF1 dG9zcGFjZTpub25lJz48Zm9udA0Kc2l6ZT0yIGZhY2U9Q291cmllcj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyOw0KbXNvLWJpZGktZm9udC1mYW1pbHk6 Q291cmllcic+JnF1b3Q7JmFtcDsmcXVvdDsgLyAmcXVvdDs9JnF1b3Q7IC8gJnF1b3Q7KyZxdW90 Ow0KLyAmcXVvdDskJnF1b3Q7IC8gJnF1b3Q7LCZxdW90OyApPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGF5b3V0LWdyaWQtYWxp Z246bm9uZTt0ZXh0LWF1dG9zcGFjZTpub25lJz48c3Bhbg0KY2xhc3M9U3BlbGxFPjxzcGFuIGNs YXNzPUdyYW1FPjxmb250IHNpemU9MiBmYWNlPUNvdXJpZXI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7bXNvLWJpZGktZm9udC1mYW1pbHk6Q291cmll cic+aG9zdHBvcnQ8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PGZvbnQNCmZhY2U9Q291cmll cj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q291cmllcjttc28tYmlkaS1mb250LWZhbWlseTpD b3VyaWVyJz4gPQ0KaG9zdCBbICZxdW90OzomcXVvdDsgcG9ydCBdPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QXBwcmVjaWF0ZSB5b3VyIGhlbHA8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPlRoYW5rcyBhbmQgUmVnYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz4tIEFqYXk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5 Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C386B3.B74F90BE-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 15:07:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04508 for ; Mon, 29 Sep 2003 15:07:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43Mb-0004m8-Gx for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 15:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJ7HPh018333 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 15:07:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43MM-0004kT-WE; Mon, 29 Sep 2003 15:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43LW-0004jV-37 for sip@optimus.ietf.org; Mon, 29 Sep 2003 15:06:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04331 for ; Mon, 29 Sep 2003 15:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43LT-0003Gx-00 for sip@ietf.org; Mon, 29 Sep 2003 15:06:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A43LS-0003Gj-00 for sip@ietf.org; Mon, 29 Sep 2003 15:06:06 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2003 12:04:52 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8TJ5Ywn004647; Mon, 29 Sep 2003 12:05:35 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACT32883; Mon, 29 Sep 2003 15:05:33 -0400 (EDT) Message-ID: <3F78827D.2010300@cisco.com> Date: Mon, 29 Sep 2003 15:05:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Aki, I think the one major issue here is whether the presence document to be affected should be chosen by the To-uri or the Request-uri. Has this been explicitly discussed before? I think it is a big decision, and I don't think it is a clear cut one. The following things come to my mind that are factors affecting, or affected by the decision: 1) consistency with REGISTER. There are conceptual parallels between PUBLISH and REGISTER. With REGISTER it is To that determines what is updated by the request. So perhaps the same should be true for PUBLISH. But not all paralles hold. In case of REGISTER, the request uri only identifies a server. REGISTER requests can't be routed the same as other requests because of this. Either the registrar must be collocated with a proxy for the domain of the To, or else a proxy must take the To into account when routing a REGISTER. PUBLISH isn't so special - it is expected to be routed like any normal non-register request. The username part of the request uri is significant in this routing. In the case of REGISTER, the target of the request *is* the domain of the registration. It must be this way because it is responsible for defining the address-of-record for use by other messages. For this very reason it is unique and unlike other sip messages. To further consistency with REGISTER, it might make sense to have the request uri only name the domain within with the presence document is defined. But that would negate the unique value of REGISTER. 2) consistency with "normal" messages Normal requests are generally routed to a UA based on request uri, without regard for the To. AFAIK we expect the same of PUBLISH requests. Also, UAs typically accept or reject a request based on the request uri, not the To uri. For instance, if an invite is directed first to Alice, forwarded to Bob, and then to a phone registered to Bob's AoR, the phone typically decides how to process it (e.g. what "line" on the phone it relates to) based on the Request URI. (The To uri may play some more minor role, like affecting alerting.) 3) consistency with SUBSCRIBE. SUBSCRIBE and PUBLISH are in some sense two sides of the same coin. PUBLISH delivers information to an agent that compiles it for use in answering subscriptions. SUBSCRIBE is delivered to an agent that returns information compiled by publications, among other things. The agent for subscriptions needs to be associated with the agent for publications. It makes sense for them to be related by a consistent name, and to be routed in a consistent way. If I subscribe to Alice's presence, but she redirects my subscription to Bob, then what is returned to me is a report on Bob's presence. Consistency would argue that if I publish to Alice and she redirects my publication to Bob, that my publication should affect Bob's presence. 4) general utility Suppose there are two users: sip:alice@atlanta.com and sip:bob@biloxi.com. As part of getting setup, the following registrations are done: REGISTER sip:atlanta.com To: sip:alice@atlanta.com From: sip:alice@atlanta.com Contact: sip:alice@presence.atlanta.com ;methods="SUBSCRIBE,PUBLISH" ;events="presence" REGISTER sip:biloxi.com To: sip:bob@biloxi.com From: sip:bob@biloxi.com Contact: sip:bob@presence.biloxi.com ;methods="SUBSCRIBE,PUBLISH" ;events="presence" Consistent with this, alice has a phone that both registers and publishes presence: REGISTER sip:atlanta.com To: sip:alice@atlanta.com From: sip:alice@atlanta.com Contact: sip:line1@alice-phone.atlanta.com ;methods="INVITE,OPTIONS,BYE,NOTIFY" ;events="presence" PUBLISH sip:alice@atlanta.com To: sip:alice@atlanta.com From: sip:alice@atlanta.com Event: presence Then Alice goes on vacation. She configures a rule in the proxy that manages her address-of-record, causing all requests addressed to sip:alice@atlanta.com to be forwarded to Bob. So what happens to requests for Alice? According to current draft: - INVITEs go to Bob and ring one of this devices - PUBLISHs are routed to Bob's presence server. (sip:bob@presence.biloxi.com) But it looks without success for a presence document for sip:alice@atlanta.com. Without one of those, the result will be a 403 or 404 error. - SUBSCRIBEs to Alice's presence go to Bob's presence server. If permitted, they result in notification of Bob's presence. Nothing about Alice's presence is present in the result. If the request uri were to be used to select the document to update: - INVITEs go to Bob and ring one of this devices - PUBLISHs are routed to Bob's presence server. (sip:bob@presence.biloxi.com) It selects the presence document associated with the AoR that contact is registered with. (sip:bob@biloxi.com) The publish may succeed and update the document, or may fail authorization with a 401 or 403. - SUBSCRIBEs to Alice's presence go to Bob's presence server. If permitted, they result in notification of Bob's presence. Aspects of Alice's presence may be present in this, or not depending on authorization. In practice, its unlikely that Bob would want to authorize update of his presence by publications of Alice's presence. So the visible results to both publishers and subscribers will be similar regardless of which approach is taken. IMO it is preferable to go with consistency with "normal" methods - selecting the presence document to update based on the request uri rather than the To uri. More comments below. Paul aki.niemi@nokia.com wrote: > > How about: > > The target of the publication is naturally represented by the address in > the To header field. Similarly, the address in the From header field > identifies the party responsible for the publication. > Well, this depends on the decision about how the presence doc is selected. If it is from To then this is fine. If it is the request uri then this isn't fine. > In case of presence, the To could actually contain a pres: URI and not a (SIP or SIPS) AoR. This should probably be mentioned somewhere? Are you suggesting that the ESC would register to an AoR of sip:foo@bar, but that the presence document itself might be identified by pres:foo@bar? If so, that doesn't seem like a good thing to me. If there is no clear and explicit linkage between the name of the document and the address used to deliver requests referencing the document, then how do I figure out how to send a request to reference presence? This becomes an issue for every presence client. OTOH, if all resolution is done via the request uri, the client never has any confusion. It simply puts whatever url it has into the To and request uris and then follows normal rules. Any special handling that is required to associate pres: and sip: urls is strictly a problem for the server. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 16:02:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08046 for ; Mon, 29 Sep 2003 16:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Dm-0007ig-Gl for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 16:02:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TK2EO0029662 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 16:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Db-0007hQ-Om; Mon, 29 Sep 2003 16:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44DR-0007gl-Sq for sip@optimus.ietf.org; Mon, 29 Sep 2003 16:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07958 for ; Mon, 29 Sep 2003 16:01:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44DQ-0003yP-00 for sip@ietf.org; Mon, 29 Sep 2003 16:01:52 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A44DP-0003xW-00 for sip@ietf.org; Mon, 29 Sep 2003 16:01:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h8TK0ad06682; Mon, 29 Sep 2003 15:00:36 -0500 Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt From: Robert Sparks To: Paul Kyzivat Cc: Aki Niemi , sip@ietf.org In-Reply-To: <3F78827D.2010300@cisco.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> <3F78827D.2010300@cisco.com> Content-Type: text/plain Message-Id: <1064865633.897.36.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 29 Sep 2003 15:00:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote: > Aki, > > I think the one major issue here is whether the presence document to be > affected should be chosen by the To-uri or the Request-uri. Has this > been explicitly discussed before? I think it is a big decision, and I > don't think it is a clear cut one. The following things come to my mind > that are factors affecting, or affected by the decision: This was discussed in SIMPLE (several times iirc) and the outcome of the discussion was that the resource being modified was identified by the Request-URI. > > 1) consistency with REGISTER. > > There are conceptual parallels between PUBLISH and REGISTER. With > REGISTER it is To that determines what is updated by the request. So > perhaps the same should be true for PUBLISH. > > But not all paralles hold. In case of REGISTER, the request uri only > identifies a server. REGISTER requests can't be routed the same as other > requests because of this. Either the registrar must be collocated with a > proxy for the domain of the To, or else a proxy must take the To into > account when routing a REGISTER. PUBLISH isn't so special - it is > expected to be routed like any normal non-register request. The username > part of the request uri is significant in this routing. > > In the case of REGISTER, the target of the request *is* the domain of > the registration. It must be this way because it is responsible for > defining the address-of-record for use by other messages. For this very > reason it is unique and unlike other sip messages. > > To further consistency with REGISTER, it might make sense to have the > request uri only name the domain within with the presence document is > defined. But that would negate the unique value of REGISTER. > > 2) consistency with "normal" messages > > Normal requests are generally routed to a UA based on request uri, > without regard for the To. AFAIK we expect the same of PUBLISH requests. > > Also, UAs typically accept or reject a request based on the request uri, > not the To uri. For instance, if an invite is directed first to Alice, > forwarded to Bob, and then to a phone registered to Bob's AoR, the phone > typically decides how to process it (e.g. what "line" on the phone it > relates to) based on the Request URI. (The To uri may play some more > minor role, like affecting alerting.) > > 3) consistency with SUBSCRIBE. > > SUBSCRIBE and PUBLISH are in some sense two sides of the same coin. > PUBLISH delivers information to an agent that compiles it for use in > answering subscriptions. SUBSCRIBE is delivered to an agent that returns > information compiled by publications, among other things. The agent for > subscriptions needs to be associated with the agent for publications. It > makes sense for them to be related by a consistent name, and to be > routed in a consistent way. > > If I subscribe to Alice's presence, but she redirects my subscription to > Bob, then what is returned to me is a report on Bob's presence. > Consistency would argue that if I publish to Alice and she redirects my > publication to Bob, that my publication should affect Bob's presence. > > 4) general utility > > Suppose there are two users: sip:alice@atlanta.com and > sip:bob@biloxi.com. As part of getting setup, the following > registrations are done: > > REGISTER sip:atlanta.com > To: sip:alice@atlanta.com > From: sip:alice@atlanta.com > Contact: sip:alice@presence.atlanta.com > ;methods="SUBSCRIBE,PUBLISH" > ;events="presence" > > REGISTER sip:biloxi.com > To: sip:bob@biloxi.com > From: sip:bob@biloxi.com > Contact: sip:bob@presence.biloxi.com > ;methods="SUBSCRIBE,PUBLISH" > ;events="presence" > > Consistent with this, alice has a phone that both registers and > publishes presence: > > REGISTER sip:atlanta.com > To: sip:alice@atlanta.com > From: sip:alice@atlanta.com > Contact: sip:line1@alice-phone.atlanta.com > ;methods="INVITE,OPTIONS,BYE,NOTIFY" > ;events="presence" > > PUBLISH sip:alice@atlanta.com > To: sip:alice@atlanta.com > From: sip:alice@atlanta.com > Event: presence > > Then Alice goes on vacation. She configures a rule in the proxy that > manages her address-of-record, causing all requests addressed to > sip:alice@atlanta.com to be forwarded to Bob. So what happens to > requests for Alice? > > According to current draft: > > - INVITEs go to Bob and ring one of this devices > - PUBLISHs are routed to Bob's presence server. > (sip:bob@presence.biloxi.com) But it looks without success for > a presence document for sip:alice@atlanta.com. > Without one of those, the result will be a 403 or 404 error. > - SUBSCRIBEs to Alice's presence go to Bob's presence server. > If permitted, they result in notification of Bob's presence. > Nothing about Alice's presence is present in the result. > > If the request uri were to be used to select the document to update: > > - INVITEs go to Bob and ring one of this devices > - PUBLISHs are routed to Bob's presence server. > (sip:bob@presence.biloxi.com) It selects the presence document > associated with the AoR that contact is registered with. > (sip:bob@biloxi.com) > The publish may succeed and update the document, or may fail > authorization with a 401 or 403. > - SUBSCRIBEs to Alice's presence go to Bob's presence server. > If permitted, they result in notification of Bob's presence. > Aspects of Alice's presence may be present in this, or not > depending on authorization. > > In practice, its unlikely that Bob would want to authorize update of his > presence by publications of Alice's presence. So the visible results to > both publishers and subscribers will be similar regardless of which > approach is taken. > > IMO it is preferable to go with consistency with "normal" methods - > selecting the presence document to update based on the request uri > rather than the To uri. > > More comments below. > > Paul > > aki.niemi@nokia.com wrote: > > > > How about: > > > > The target of the publication is naturally represented by the address in > > the To header field. Similarly, the address in the From header field > > identifies the party responsible for the publication. > > > > Well, this depends on the decision about how the presence doc is > selected. If it is from To then this is fine. If it is the request uri > then this isn't fine. > > > In case of presence, the To could actually contain a pres: URI and not a (SIP or SIPS) AoR. This should probably be mentioned somewhere? > > Are you suggesting that the ESC would register to an AoR of sip:foo@bar, > but that the presence document itself might be identified by pres:foo@bar? > > If so, that doesn't seem like a good thing to me. If there is no clear > and explicit linkage between the name of the document and the address > used to deliver requests referencing the document, then how do I figure > out how to send a request to reference presence? This becomes an issue > for every presence client. > > OTOH, if all resolution is done via the request uri, the client never > has any confusion. It simply puts whatever url it has into the To and > request uris and then follows normal rules. Any special handling that is > required to associate pres: and sip: urls is strictly a problem for the > server. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 16:51:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08047 for ; Mon, 29 Sep 2003 16:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Dm-0007ih-H0 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 16:02:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TK2Ecn029663 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 16:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Da-0007h8-8z; Mon, 29 Sep 2003 16:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Cb-0007fg-Ux for sip@optimus.ietf.org; Mon, 29 Sep 2003 16:01:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07898 for ; Mon, 29 Sep 2003 16:00:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44Ca-0003xK-00 for sip@ietf.org; Mon, 29 Sep 2003 16:01:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A44CZ-0003wp-00 for sip@ietf.org; Mon, 29 Sep 2003 16:01:00 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8TK0Q01004637; Mon, 29 Sep 2003 16:00:26 -0400 (EDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOV04860; Mon, 29 Sep 2003 13:00:26 -0700 (PDT) Message-ID: <3F788F59.4030502@cisco.com> Date: Mon, 29 Sep 2003 16:00:25 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes CC: Jean-Francois Mule , "'sip@ietf.org'" , "'rohan@cisco.com'" References: <870397D7C140C84DB081B88396458DAF578CAB@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mary Barnes wrote: > >>- Section 9, page 109. The statement "If these objects are SET > > maliciously, > >>it may result in >>incorrect or unwanted protocol operation." is probably a bit of an >>understatement with regards to the timer, retry and expire values being >>misconfigured. Certainly, a well designed system would but reasonable >>boundaries on how these things can be configured, so as to hopefully > > prevent > >>significant problems. Cullen had brought up the more general issue of >>whether all the timers should be configurable in his comments. Like > > Cullen, > >>I haven't thought about this enough to decide whether all these timers >>should be configurable, but at a minimum, I think the security section >>needs a more robust statement. > > > is this commented wrt the entire security section or just the area > you referred to on pg 109? > > is it that we have not made a strong enough statement about the > protocol impact to these particular timer/retry related objects > being SET?? > > [MB] This comment was specific to the timer/retry and related objects being > set. My point was that it's beyond being incorrect or unwanted protocol > operation, but rather has a broader impact on the server and its ability to > process new and existing transactions and the clients making use of the > server. I think, though, that the broader question is whether all of these > should be configurable, per Cullen's comments. ok. here's where we stand with cullen's comments. we are not going to prevent configuration via the mib, but we are going to rework the complicance section of the to not require configuration to be mandatory. essentially defining the necessary optional object-groups to allow one to be compliant with the mib but not support and configurability. that said, set capability will still be allowed for the objects in question for your comment, so we need to just emphasize what you've said above. serious damage to the basic operation of the system can occur if these objects are set maliciously (or out of ignorance for that matter). we can state that set capability is not mandatory. kevin > > thanks! > kevin > > >>Regards, >>Mary H. Barnes >>mbarnes@nortelnetworks.com >> >> >> >> >> >> > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 17:03:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12038 for ; Mon, 29 Sep 2003 17:03:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45Ax-00038C-3u for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 17:03:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TL3NpG011978 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 17:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45Ac-00036V-IC; Mon, 29 Sep 2003 17:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45AN-000365-Fc for sip@optimus.ietf.org; Mon, 29 Sep 2003 17:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12020 for ; Mon, 29 Sep 2003 17:02:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A45AL-0005Ah-00 for sip@ietf.org; Mon, 29 Sep 2003 17:02:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A45AK-0005AN-00 for sip@ietf.org; Mon, 29 Sep 2003 17:02:44 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2003 14:06:48 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8TL2CJs016716; Mon, 29 Sep 2003 14:02:12 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACT44537; Mon, 29 Sep 2003 17:02:11 -0400 (EDT) Message-ID: <3F789DD3.2060102@cisco.com> Date: Mon, 29 Sep 2003 17:02:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Aki Niemi , sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> <3F78827D.2010300@cisco.com> <1064865633.897.36.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks wrote: > On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote: > >>Aki, >> >>I think the one major issue here is whether the presence document to be >>affected should be chosen by the To-uri or the Request-uri. Has this >>been explicitly discussed before? I think it is a big decision, and I >>don't think it is a clear cut one. The following things come to my mind >>that are factors affecting, or affected by the decision: > > > This was discussed in SIMPLE (several times iirc) and the outcome of the > discussion was that the resource being modified was identified by the > Request-URI. I didn't remember. If it has been decided that way, then there are a number of tweaks to the language that need to be made. Most of them were pointed out in my original reply on this subject. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 19:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17070 for ; Mon, 29 Sep 2003 19:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47GS-0000t5-Rm for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 19:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TNHCLo003352 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 19:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47GH-0000rN-GA; Mon, 29 Sep 2003 19:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47Fz-0000qs-Ad for sip@optimus.ietf.org; Mon, 29 Sep 2003 19:16:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17000 for ; Mon, 29 Sep 2003 19:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A47Fx-0006TX-00 for sip@ietf.org; Mon, 29 Sep 2003 19:16:41 -0400 Received: from [200.36.33.2] (helo=mail.kbtel.com) by ietf-mx with esmtp (Exim 4.12) id 1A47Fw-0006T8-00 for sip@ietf.org; Mon, 29 Sep 2003 19:16:41 -0400 Received: from aislas ([10.10.4.170]) (authenticated user aislas@mail.kbtel.com) by mail.kbtel.com (mail.kbtel.com [200.36.33.2]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 2-md50000000255.tmp for ; Mon, 29 Sep 2003 18:08:44 -0500 Message-ID: <001a01c386de$f4ec62a0$aa040a0a@cuicuilco.kbtel.com> Reply-To: "Alejandro Islas" From: "Alejandro Islas" To: Date: Mon, 29 Sep 2003 18:10:45 -0500 Organization: Kb/TEL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C386B5.0087ACC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authenticated-Sender: aislas@mail.kbtel.com X-Spam-Processed: mail.kbtel.com, Mon, 29 Sep 2003 18:08:44 -0500 (not processed: spam filter disabled) X-MDRemoteIP: 10.10.4.170 X-Return-Path: aislas@kbtel.com X-MDaemon-Deliver-To: sip@ietf.org Subject: [Sip] Unsuscribe Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C386B5.0087ACC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to unsuscribe my account aislas@kbtel.com from the = sip@ietf.org Alejandro Islas Kb/TEL=20 ------=_NextPart_000_0011_01C386B5.0087ACC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like to unsuscribe my account = aislas@kbtel.com from the=20 sip@ietf.org
 Alejandro Islas
 Kb/TEL=20
------=_NextPart_000_0011_01C386B5.0087ACC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 21:11:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20131 for ; Mon, 29 Sep 2003 21:11:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A492m-0006Dl-RA for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 21:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U1BCLH023855 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 21:11:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A492c-0006C6-6j; Mon, 29 Sep 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A492W-0006Bl-Er for sip@optimus.ietf.org; Mon, 29 Sep 2003 21:10:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20118 for ; Mon, 29 Sep 2003 21:10:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A492T-0007fa-00 for sip@ietf.org; Mon, 29 Sep 2003 21:10:53 -0400 Received: from mail.telverse.com ([4.43.0.5] helo=dc1.telverse.com) by ietf-mx with esmtp (Exim 4.12) id 1A492T-0007f0-00 for sip@ietf.org; Mon, 29 Sep 2003 21:10:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Sep 2003 18:10:18 -0700 Message-ID: Thread-Topic: [Sip] Re:draft-ietf-sip-publish-00.txt Thread-Index: AcOGzTGxhIrWP0UeSqmXqi3vMVRptAAH5Jcg From: "Samir Srivastava" To: "Aki Niemi" Cc: Content-Transfer-Encoding: quoted-printable Subject: [Sip] sip-publish-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, A) In Section 5, it states "EPAs MUST NOT send a new PUBLISH request (not a re-transmission) until they have received a final response from the ESC for the previous one or the previous PUBLISH request has timed out. " What's the reason for adding this exception? There may be the cases when PUBLISH request may be going through proxy which may retransmit. If it goes thru proxy callId, and Cseq comparission is needed at ESC as needed in the case of REGISTER.=20 B) Table 1 and 2 is incomplete. 1. In 200 OK, Expires header is MUST. which is not shown.=20 Separte entry needed for 2xx. =20 2. Also Min-Expires header is missing in the table. which is MUST for 423. C) In the example Messages, mandatory "Max-Forward" Header is missing from all=20 messages. Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 22:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21844 for ; Mon, 29 Sep 2003 22:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4AFG-0000nt-4x for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 22:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U2SA4X003031 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 22:28:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4AF7-0000mM-Gr; Mon, 29 Sep 2003 22:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4AEP-0000lr-QR for sip@optimus.ietf.org; Mon, 29 Sep 2003 22:27:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21828 for ; Mon, 29 Sep 2003 22:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4AEM-0000XH-00 for sip@ietf.org; Mon, 29 Sep 2003 22:27:14 -0400 Received: from mail.telverse.com ([4.43.0.5] helo=dc1.telverse.com) by ietf-mx with esmtp (Exim 4.12) id 1A4AEM-0000Wp-00 for sip@ietf.org; Mon, 29 Sep 2003 22:27:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sip-publish-00.txt Date: Mon, 29 Sep 2003 19:26:40 -0700 Message-ID: Thread-Topic: [Sip] Re:draft-ietf-sip-publish-00.txt Thread-Index: AcOGzTGxhIrWP0UeSqmXqi3vMVRptAAH5JcgAAM67fA= From: "Samir Srivastava" To: "Samir Srivastava" , "Aki Niemi" Cc: Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Samir Srivastava=20 Sent: Monday, September 29, 2003 6:10 PM To: Aki Niemi Cc: sip@ietf.org Subject: [Sip] sip-publish-00.txt Hi, A) In Section 5, it states "EPAs MUST NOT send a new PUBLISH request (not a re-transmission) until they have received a final response from the ESC for the previous one or the previous PUBLISH request has timed out. " What's the reason for adding this exception? There may be the cases when PUBLISH request may be going through proxy which may retransmit. If it goes thru proxy callId, and Cseq comparission is needed at ESC as needed in the case of REGISTER.=20 >> I take back the proxy retransmission. Is there any case due to reboot etc when out of order requests are received at the ESC ?=20 B) Table 1 and 2 is incomplete. 1. In 200 OK, Expires header is MUST. which is not shown.=20 Separte entry needed for 2xx. =20 2. Also Min-Expires header is missing in the table. which is MUST for 423. C) In the example Messages, mandatory "Max-Forward" Header is missing from all=20 messages. Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Sep 29 23:31:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23197 for ; Mon, 29 Sep 2003 23:31:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4BEM-0003P2-G5 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 23:31:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U3VI8e013022 for sip-archive@odin.ietf.org; Mon, 29 Sep 2003 23:31:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4BE5-0003NH-Pl; Mon, 29 Sep 2003 23:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4BDM-0003JS-Gc for sip@optimus.ietf.org; Mon, 29 Sep 2003 23:30:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23149 for ; Mon, 29 Sep 2003 23:30:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4BDK-00012l-00 for SIP@IETF.ORG; Mon, 29 Sep 2003 23:30:14 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 1A4BDJ-00012h-00 for SIP@IETF.ORG; Mon, 29 Sep 2003 23:30:13 -0400 Received: from mail.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h8U3UWU19699 for ; Tue, 30 Sep 2003 11:30:33 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by mail.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h8U3Xqs15975 for ; Tue, 30 Sep 2003 11:33:53 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 11:30:07 +0800 Message-ID: <105CD4E8F8C7744DABCFE234C5FC9728A7BFB7@HP5> From: "Chen Zaifeng,BISC R&D SA(BJ)" To: SIP@ietf.org Date: Tue, 30 Sep 2003 11:13:24 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Any one can confirm that "fork" only means parellel search and no t covers sequential search? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear All: In RFC3261 page 15 there is such a description "A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking." I think this is enough to say that fork only means parellel search. But some other people think that the description doesn't deny the case of sequential seach, so any one can confirm that "fork" only means parellel search and not covers sequential search? Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. R&D SA No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 E-mail: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 04:44:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12624 for ; Tue, 30 Sep 2003 04:44:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G7H-0001Yd-SQ for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 04:44:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U8iJOx005987 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 04:44:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G70-0001Y7-O1; Tue, 30 Sep 2003 04:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4G6k-0001Xr-SL for sip@optimus.ietf.org; Tue, 30 Sep 2003 04:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12609 for ; Tue, 30 Sep 2003 04:43:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4G6h-0003sG-00 for sip@ietf.org; Tue, 30 Sep 2003 04:43:43 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A4G6h-0003sD-00 for sip@ietf.org; Tue, 30 Sep 2003 04:43:43 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U8hht23435 for ; Tue, 30 Sep 2003 11:43:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 11:43:43 +0300 Received: from nokia.com ([172.21.11.136]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 11:43:43 +0300 Message-ID: <3F79423F.20509@nokia.com> Date: Tue, 30 Sep 2003 11:43:43 +0300 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> <3F78827D.2010300@cisco.com> <1064865633.897.36.camel@RjS.localdomain> <3F789DD3.2060102@cisco.com> In-Reply-To: <3F789DD3.2060102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2003 08:43:43.0130 (UTC) FILETIME=[F42C5FA0:01C3872E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, As long as I can remember, PUBLISH's use of To and From have been consistent with REGISTER all the way down to explicitly allowing for third-party publications. The use of Request-URI as identifying the target resource has admittedly been ambiguously defined. The way the draft currently reads is that they are both kind of used - which works fine if they are the same. But I think Paul brings up an important issue about forwarding PUBLISH requests. What is the use case, and the semantics we are looking for? 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects the request. -> Consequently a forwarded subscription will deliver only Bob's presence 2) Alice's PUBLISH gets forwarded to Bob, whose ESC composes the event state into Bob's presence document. -> Consequently a forwarded subscription will deliver the union or some combination of Bob's and Alice's presence 3) Alice's PUBLISH gets forwarded to Bob, whose ESC establishes event state for Alice -> Consequently a forwarded subscription will deliver Alice's presence which is now "parked" in Bob's Presence Server Out of these three, I especially like the properties of 3). It would allow one to have a static SIP address, e.g., "sip:aki.niemi@iki.fi", which would be forwarded to whatever service provider one was using at the time, e.g., "sip:aki.niemi@nokia.com", "sip:hillomunkki@foo.someisp.org". In practice, I could "park" the presence of "sip:aki.niemi@iki.fi" into nokia.com, or foo.someisp.org's presence system. The problem is that by default, a presence server does *not* look at the To-field. It only looks at the Request-URI to determine the requested resource. So a subscription to "sip:aki.niemi@iki.fi" would deliver the presence of a completely different presentity. I don't much like 2), but that's probably because I don't quite understand the use-case. What would the resulting presence document look like? Would it still have entity="pres:bob@biloxi.com", and just have alice's tuples? IMO, this sort of thing could be more easily achieved by configuring Alice's EPAs to publish presence directly to sip:bob@biloxi.com. So in my opinion, the key issue really is whether we see 3) as useful, and/or feasible. That is the only use-case I can think of right now that would strictly require using the To-field as the resource pointer. This would also require some clarification to RFC 3265 on resource identification, so it's not an entirely uncontroversial road to take either. Thoughts? Cheers, Aki On 30.09.2003 00:02, ext Paul Kyzivat: > > > Robert Sparks wrote: > >> On Mon, 2003-09-29 at 14:05, Paul Kyzivat wrote: >> >>> Aki, >>> >>> I think the one major issue here is whether the presence document to >>> be affected should be chosen by the To-uri or the Request-uri. Has >>> this been explicitly discussed before? I think it is a big decision, >>> and I don't think it is a clear cut one. The following things come to >>> my mind that are factors affecting, or affected by the decision: >> >> >> >> This was discussed in SIMPLE (several times iirc) and the outcome of the >> discussion was that the resource being modified was identified by the >> Request-URI. > > > I didn't remember. If it has been decided that way, then there are a > number of tweaks to the language that need to be made. Most of them were > pointed out in my original reply on this subject. > > Paul > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 04:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13030 for ; Tue, 30 Sep 2003 04:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4GKb-0002DA-Gx for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 04:58:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U8w53G008501 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 04:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4GKW-0002Cd-Gc; Tue, 30 Sep 2003 04:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4GJj-0002Bz-0o for sip@optimus.ietf.org; Tue, 30 Sep 2003 04:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13015 for ; Tue, 30 Sep 2003 04:57:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4GJf-000404-00 for sip@ietf.org; Tue, 30 Sep 2003 04:57:07 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4GJf-000401-00 for sip@ietf.org; Tue, 30 Sep 2003 04:57:07 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U8v7602467 for ; Tue, 30 Sep 2003 11:57:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 11:57:07 +0300 Received: from nokia.com ([172.21.11.136]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 11:57:07 +0300 Message-ID: <3F794564.8000401@nokia.com> Date: Tue, 30 Sep 2003 11:57:08 +0300 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Samir Srivastava CC: sip@ietf.org Subject: Re: [Sip] sip-publish-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2003 08:57:07.0677 (UTC) FILETIME=[D3B880D0:01C38730] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Samir, Comments inline, On 30.09.2003 05:26, ext Samir Srivastava: > > Hi, > > A) In Section 5, it states > > "EPAs MUST NOT send a new PUBLISH request (not a re-transmission) > until they have received a final response from the ESC for the > previous one or the previous PUBLISH request has timed out. " > > What's the reason for adding this exception? This restriction is mainly due to congestion concerns. The same restriction applies to MESSAGE requests. > There may be the cases > when PUBLISH request may be going through proxy which may retransmit. > If it goes thru proxy callId, and Cseq comparission is needed at ESC > as needed in the case of REGISTER. > >>> I take back the proxy retransmission. Is there any case due to reboot > etc when out of order requests are received at the ESC ? PUBLISH requests are process in the order that they arrive at the ESC. The If-Match header field is used to identify the specific state that the request is targetting. I don't quite understand the problem. Can you elaborate a bit? > > B) Table 1 and 2 is incomplete. > > 1. In 200 OK, Expires header is MUST. which is not shown. > Separte entry needed for 2xx. > > 2. Also Min-Expires header is missing in the table. which is MUST for > 423. Good catch. I will add both to the table. > > C) In the example Messages, mandatory "Max-Forward" Header is missing > from all > messages. Will add that in the next revision. Cheers, Aki > > Thx > Samir > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 08:00:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18017 for ; Tue, 30 Sep 2003 08:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4JAy-0001gk-SL for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 08:00:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UC0KMN006432 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 08:00:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4JAg-0001et-T1; Tue, 30 Sep 2003 08:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4JAK-0001e4-4J for sip@optimus.ietf.org; Tue, 30 Sep 2003 07:59:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17930 for ; Tue, 30 Sep 2003 07:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4JAJ-0005m4-00 for sip@ietf.org; Tue, 30 Sep 2003 07:59:39 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1A4JAI-0005lK-00 for sip@ietf.org; Tue, 30 Sep 2003 07:59:38 -0400 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id HAA14341; Tue, 30 Sep 2003 07:58:47 -0400 (EDT) Message-ID: <3F796FEA.4050808@ulticom.com> Date: Tue, 30 Sep 2003 07:58:34 -0400 From: Steve Pellegrino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chen Zaifeng,BISC R&D SA(BJ)" CC: sip Subject: Re: [Sip] Any one can confirm that "fork" only means parellel search and no t covers sequential search? References: <105CD4E8F8C7744DABCFE234C5FC9728A7BFB7@HP5> In-Reply-To: <105CD4E8F8C7744DABCFE234C5FC9728A7BFB7@HP5> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Refer to section 16.6 that goes on to describe that the proxy MAY choose to forward the request to targets in the set (i.e. fork the request) serially, in parallel, or using a combination of both. Regards, Steve Chen Zaifeng,BISC R&D SA(BJ) wrote: >Dear All: > >In RFC3261 page 15 there is such a description "A proxy server can also send an INVITE to a number of locations at the same time. This >type of parallel search is known as forking." I think this is enough to say that fork only means parellel search. > >But some other people think that the description doesn't deny the case of sequential seach, so any one can confirm that "fork" only means >parellel search and not covers sequential search? > >Thanks! > >Sincerely yours, >Chen Zaifeng >-------------------------------------------------------------------------- >Beijing International Switching System Corporation Ltd. >R&D SA >No. 14 Jiu Xian Qiao Road >Beijing 100016, P. R. China >Tel: +86-10-8457 1921 >Fax: +86-10-6436 7732 >E-mail: > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 09:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20879 for ; Tue, 30 Sep 2003 09:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4KkY-0006kK-JR for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 09:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UDfAVX025926 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 09:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4KkR-0006jg-KM; Tue, 30 Sep 2003 09:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Kjw-0006j8-27 for sip@optimus.ietf.org; Tue, 30 Sep 2003 09:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20859 for ; Tue, 30 Sep 2003 09:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Kju-0006jz-00 for sip@ietf.org; Tue, 30 Sep 2003 09:40:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Kjt-0006jf-00 for sip@ietf.org; Tue, 30 Sep 2003 09:40:29 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 06:44:48 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8UDduJs012700; Tue, 30 Sep 2003 06:39:57 -0700 (PDT) Received: from cisco.com (dhcp-10-86-165-187.cisco.com [10.86.165.187]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACT81994; Tue, 30 Sep 2003 09:39:55 -0400 (EDT) Message-ID: <3F7987AB.5070100@cisco.com> Date: Tue, 30 Sep 2003 09:39:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> <3F78827D.2010300@cisco.com> <1064865633.897.36.camel@RjS.localdomain> <3F789DD3.2060102@cisco.com> <3F79423F.20509@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > As long as I can remember, PUBLISH's use of To and From have been > consistent with REGISTER all the way down to explicitly allowing for > third-party publications. The use of From, and 3rd party publications isn't in question here. It is the unaffected by how the target is selected. I admit I haven't been following the development of PUBLISH closely enough to remember whether there has agreement on how the target is selected. That is why I asked. Apparently Robert thinks there was agreement that the request uri would be used, while you seem to think that To will be used. I think consistency argues for using the request uri, unless some compelling argument wins the day. But that is just my opinion. > The use of Request-URI as identifying the > target resource has admittedly been ambiguously defined. The way the > draft currently reads is that they are both kind of used - which works > fine if they are the same. :-) > But I think Paul brings up an important issue about forwarding PUBLISH > requests. What is the use case, and the semantics we are looking for? > > 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects the request. > > -> Consequently a forwarded subscription will deliver only > Bob's presence > > 2) Alice's PUBLISH gets forwarded to Bob, whose ESC composes the event > state into Bob's presence document. > > -> Consequently a forwarded subscription will deliver the union or > some combination of Bob's and Alice's presence > > 3) Alice's PUBLISH gets forwarded to Bob, whose ESC establishes event > state for Alice > > -> Consequently a forwarded subscription will deliver Alice's presence > which is now "parked" in Bob's Presence Server > > Out of these three, I especially like the properties of 3). It would > allow one to have a static SIP address, e.g., "sip:aki.niemi@iki.fi", > which would be forwarded to whatever service provider one was using at > the time, e.g., "sip:aki.niemi@nokia.com", > "sip:hillomunkki@foo.someisp.org". In practice, I could "park" the > presence of "sip:aki.niemi@iki.fi" into nokia.com, or foo.someisp.org's > presence system. > > The problem is that by default, a presence server does *not* look at the > To-field. It only looks at the Request-URI to determine the requested > resource. So a subscription to "sip:aki.niemi@iki.fi" would deliver the > presence of a completely different presentity. Yes. While (3) may be interesting in some ways, to be useful it requires a change in the way subscribe works. And I think that would have many unintended consequences. While the scenario might be useful for presence, it wouldn't be very appealing for other packages, such as "dialog". > I don't much like 2), but that's probably because I don't quite > understand the use-case. What would the resulting presence document look > like? Would it still have entity="pres:bob@biloxi.com", and just have > alice's tuples? I also can't think of a use case where this is valid. But neither can I think of a use case where (3) is valid - I can't think of a business model where the operator of the presence server for Bob would want to do this. I think (1) is the interesting use case, and it works regardless of whether the target is chosen using the request uri or the To uri. > IMO, this sort of thing could be more easily achieved by > configuring Alice's EPAs to publish presence directly to > sip:bob@biloxi.com. I think if Alice is going away and wants to forward calls to Bob, that she should do something different with her presence. Probably configure some static state indicating she is away, and listing Bob as an alternative contact. Her forwarding should not include subscriptions for presence. If she neglects to do this then all the alternatives seem to provide comparably useless results. > So in my opinion, the key issue really is whether we see 3) as useful, > and/or feasible. That is the only use-case I can think of right now that > would strictly require using the To-field as the resource pointer. This > would also require some clarification to RFC 3265 on resource > identification, so it's not an entirely uncontroversial road to take > either. Covered above. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 11:45:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27366 for ; Tue, 30 Sep 2003 11:45:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MgZ-00062D-Nf for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 11:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UFjBB9023193 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 11:45:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MgQ-00061R-Ry; Tue, 30 Sep 2003 11:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MfW-0005uR-Nm for sip@optimus.ietf.org; Tue, 30 Sep 2003 11:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27271 for ; Tue, 30 Sep 2003 11:43:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MfV-0000O9-00 for sip@ietf.org; Tue, 30 Sep 2003 11:44:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4MfU-0000O6-00 for sip@ietf.org; Tue, 30 Sep 2003 11:44:04 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8UFi3616882 for ; Tue, 30 Sep 2003 18:44:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 18:44:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 18:44:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re:draft-ietf-sip-publish-00.txt Date: Tue, 30 Sep 2003 18:44:02 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179714C@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Re:draft-ietf-sip-publish-00.txt Thread-Index: AcOHWJaWIlLBHu1BRomKRH49Bd4pVQAD36LQ To: , Cc: , X-OriginalArrivalTime: 30 Sep 2003 15:44:02.0779 (UTC) FILETIME=[AC416AB0:01C38769] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The way Alice gets her PUBLISH to be delivered to Bob is by registering = her AOR (using REGISTER) with a contact header that has Bob's URI with = parameter method=3DPUBLISH. Now, what is the use case for Alice to do = that? I don't know. About To-header vs. Request-URI: I favour request-URI for consistency. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, September 30, 2003 4:40 PM > To: Niemi Aki (NMP/Helsinki) > Cc: Robert Sparks; sip@ietf.org > Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt >=20 >=20 >=20 >=20 > Aki Niemi wrote: > > Hi, > >=20 > > As long as I can remember, PUBLISH's use of To and From have been=20 > > consistent with REGISTER all the way down to explicitly=20 > allowing for=20 > > third-party publications. >=20 > The use of From, and 3rd party publications isn't in question=20 > here. It=20 > is the unaffected by how the target is selected. >=20 > I admit I haven't been following the development of PUBLISH closely=20 > enough to remember whether there has agreement on how the target is=20 > selected. That is why I asked. Apparently Robert thinks there was=20 > agreement that the request uri would be used, while you seem to think=20 > that To will be used. >=20 > I think consistency argues for using the request uri, unless some=20 > compelling argument wins the day. But that is just my opinion. >=20 > > The use of Request-URI as identifying the > > target resource has admittedly been ambiguously defined.=20 > The way the=20 > > draft currently reads is that they are both kind of used -=20 > which works=20 > > fine if they are the same. >=20 > :-) >=20 > > But I think Paul brings up an important issue about=20 > forwarding PUBLISH=20 > > requests. What is the use case, and the semantics we are=20 > looking for? > >=20 > > 1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects=20 > the request. > >=20 > > -> Consequently a forwarded subscription will deliver only > > Bob's presence > >=20 > > 2) Alice's PUBLISH gets forwarded to Bob, whose ESC=20 > composes the event=20 > > state into Bob's presence document. > >=20 > > -> Consequently a forwarded subscription will deliver the union or > > some combination of Bob's and Alice's presence > >=20 > > 3) Alice's PUBLISH gets forwarded to Bob, whose ESC=20 > establishes event=20 > > state for Alice > >=20 > > -> Consequently a forwarded subscription will deliver=20 > Alice's presence > > which is now "parked" in Bob's Presence Server > >=20 > > Out of these three, I especially like the properties of 3).=20 > It would=20 > > allow one to have a static SIP address, e.g.,=20 > "sip:aki.niemi@iki.fi",=20 > > which would be forwarded to whatever service provider one=20 > was using at=20 > > the time, e.g., "sip:aki.niemi@nokia.com",=20 > > "sip:hillomunkki@foo.someisp.org". In practice, I could "park" the=20 > > presence of "sip:aki.niemi@iki.fi" into nokia.com, or=20 > foo.someisp.org's=20 > > presence system. > >=20 > > The problem is that by default, a presence server does=20 > *not* look at the=20 > > To-field. It only looks at the Request-URI to determine the=20 > requested=20 > > resource. So a subscription to "sip:aki.niemi@iki.fi" would=20 > deliver the=20 > > presence of a completely different presentity. >=20 > Yes. While (3) may be interesting in some ways, to be useful=20 > it requires=20 > a change in the way subscribe works. And I think that would have many=20 > unintended consequences. While the scenario might be useful for=20 > presence, it wouldn't be very appealing for other packages, such as=20 > "dialog". >=20 > > I don't much like 2), but that's probably because I don't quite=20 > > understand the use-case. What would the resulting presence=20 > document look=20 > > like? Would it still have entity=3D"pres:bob@biloxi.com", and=20 > just have=20 > > alice's tuples? >=20 > I also can't think of a use case where this is valid. But=20 > neither can I=20 > think of a use case where (3) is valid - I can't think of a business=20 > model where the operator of the presence server for Bob would=20 > want to do=20 > this. >=20 > I think (1) is the interesting use case, and it works regardless of=20 > whether the target is chosen using the request uri or the To uri. >=20 > > IMO, this sort of thing could be more easily achieved by > > configuring Alice's EPAs to publish presence directly to=20 > > sip:bob@biloxi.com. >=20 > I think if Alice is going away and wants to forward calls to=20 > Bob, that=20 > she should do something different with her presence. Probably=20 > configure=20 > some static state indicating she is away, and listing Bob as an=20 > alternative contact. Her forwarding should not include=20 > subscriptions for=20 > presence. >=20 > If she neglects to do this then all the alternatives seem to provide=20 > comparably useless results. >=20 > > So in my opinion, the key issue really is whether we see 3)=20 > as useful,=20 > > and/or feasible. That is the only use-case I can think of=20 > right now that=20 > > would strictly require using the To-field as the resource=20 > pointer. This=20 > > would also require some clarification to RFC 3265 on resource=20 > > identification, so it's not an entirely uncontroversial=20 > road to take=20 > > either. >=20 > Covered above. >=20 > Paul >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 11:52:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27854 for ; Tue, 30 Sep 2003 11:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MnF-0006fR-S4 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 11:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UFq5T3025595 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 11:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MnB-0006do-QH; Tue, 30 Sep 2003 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MmD-0006cX-LU for sip@optimus.ietf.org; Tue, 30 Sep 2003 11:51:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27769 for ; Tue, 30 Sep 2003 11:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MmC-0000Vm-00 for sip@ietf.org; Tue, 30 Sep 2003 11:51:00 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MmB-0000VD-00 for sip@ietf.org; Tue, 30 Sep 2003 11:50:59 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h8UFoE97018842; Tue, 30 Sep 2003 10:50:14 -0500 Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt From: Dean Willis To: Aki Niemi Cc: ext Paul Kyzivat , Robert Sparks , sip@ietf.org In-Reply-To: <3F79423F.20509@nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9003@esebe013.ntc.nokia.com> <3F78827D.2010300@cisco.com> <1064865633.897.36.camel@RjS.localdomain> <3F789DD3.2060102@cisco.com> <3F79423F.20509@nokia.com> Content-Type: text/plain Message-Id: <1064937014.8754.76.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 30 Sep 2003 10:50:14 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-09-30 at 03:43, Aki Niemi wrote: > Hi, > > As long as I can remember, PUBLISH's use of To and From have been > consistent with REGISTER all the way down to explicitly allowing for > third-party publications. The use of Request-URI as identifying the > target resource has admittedly been ambiguously defined. The way the > draft currently reads is that they are both kind of used - which works > fine if they are the same. As I recall, the original design team was unanimous in its decision to indicate the target of PUBLISH using the request URI. REGISTER is unfortunately somewhat broken. This is an artifact of the originally-slightly-broken source-routing model of SIP ala 2543, which is "much beter now". We wouldn't design REGISTER that way now, and I see no need to replicate REGISTER's annoying quirks going forward. I actually have some hope that PUBLISH can eventually be used to replace REGISTER -- after all, REGISTER is just the action of publishing a contact (and, with caller-pref, some capabilities). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 14:45:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06982 for ; Tue, 30 Sep 2003 14:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PUs-0002Gw-Gt for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 14:45:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIjIdW008728 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 14:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PUf-0002Fq-08; Tue, 30 Sep 2003 14:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PUR-0002EJ-E1 for sip@optimus.ietf.org; Tue, 30 Sep 2003 14:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06912 for ; Tue, 30 Sep 2003 14:44:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PUO-0002zN-00 for sip@ietf.org; Tue, 30 Sep 2003 14:44:48 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A4PUN-0002z6-00 for sip@ietf.org; Tue, 30 Sep 2003 14:44:47 -0400 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h8UIiSeY092049; Tue, 30 Sep 2003 13:44:34 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3F79CF05.9060100@dynamicsoft.com> Date: Tue, 30 Sep 2003 13:44:21 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, aki.niemi@nokia.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <2038BCC78B1AD641891A0D1AE133DBB70179714C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179714C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > The way Alice gets her PUBLISH to be delivered to Bob is by registering her AOR (using REGISTER) with a contact header that has Bob's URI with parameter method=PUBLISH. Now, what is the use case for Alice to do that? I don't know. > > About To-header vs. Request-URI: I favour request-URI for consistency. > > Regards, > Hisham I concur with Robert's and Dean's memory that discussions in the original design team and in SIMPLE involved using r-uri. It seems to me that if I register a contact that causes a PUBLISH request to be retargeted, then I mean for the request to be presented to the device specicified by the contact, for the resource specificed by the contact. If that is not what I intended, then I screwed up. > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, September 30, 2003 4:40 PM >>To: Niemi Aki (NMP/Helsinki) >>Cc: Robert Sparks; sip@ietf.org >>Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt >> >> >> >> >>Aki Niemi wrote: >> >>>Hi, >>> >>>As long as I can remember, PUBLISH's use of To and From have been >>>consistent with REGISTER all the way down to explicitly >> >>allowing for >> >>>third-party publications. >> >>The use of From, and 3rd party publications isn't in question >>here. It >>is the unaffected by how the target is selected. >> >>I admit I haven't been following the development of PUBLISH closely >>enough to remember whether there has agreement on how the target is >>selected. That is why I asked. Apparently Robert thinks there was >>agreement that the request uri would be used, while you seem to think >>that To will be used. >> >>I think consistency argues for using the request uri, unless some >>compelling argument wins the day. But that is just my opinion. >> >> > The use of Request-URI as identifying the >> >>>target resource has admittedly been ambiguously defined. >> >>The way the >> >>>draft currently reads is that they are both kind of used - >> >>which works >> >>>fine if they are the same. >> >>:-) >> >> >>>But I think Paul brings up an important issue about >> >>forwarding PUBLISH >> >>>requests. What is the use case, and the semantics we are >> >>looking for? >> >>>1) Alice's PUBLISH gets forwarded to Bob, whose ESC rejects >> >>the request. >> >>> -> Consequently a forwarded subscription will deliver only >>> Bob's presence >>> >>>2) Alice's PUBLISH gets forwarded to Bob, whose ESC >> >>composes the event >> >>>state into Bob's presence document. >>> >>> -> Consequently a forwarded subscription will deliver the union or >>> some combination of Bob's and Alice's presence >>> >>>3) Alice's PUBLISH gets forwarded to Bob, whose ESC >> >>establishes event >> >>>state for Alice >>> >>> -> Consequently a forwarded subscription will deliver >> >>Alice's presence >> >>> which is now "parked" in Bob's Presence Server >>> >>>Out of these three, I especially like the properties of 3). >> >>It would >> >>>allow one to have a static SIP address, e.g., >> >>"sip:aki.niemi@iki.fi", >> >>>which would be forwarded to whatever service provider one >> >>was using at >> >>>the time, e.g., "sip:aki.niemi@nokia.com", >>>"sip:hillomunkki@foo.someisp.org". In practice, I could "park" the >>>presence of "sip:aki.niemi@iki.fi" into nokia.com, or >> >>foo.someisp.org's >> >>>presence system. >>> >>>The problem is that by default, a presence server does >> >>*not* look at the >> >>>To-field. It only looks at the Request-URI to determine the >> >>requested >> >>>resource. So a subscription to "sip:aki.niemi@iki.fi" would >> >>deliver the >> >>>presence of a completely different presentity. >> >>Yes. While (3) may be interesting in some ways, to be useful >>it requires >>a change in the way subscribe works. And I think that would have many >>unintended consequences. While the scenario might be useful for >>presence, it wouldn't be very appealing for other packages, such as >>"dialog". >> >> >>>I don't much like 2), but that's probably because I don't quite >>>understand the use-case. What would the resulting presence >> >>document look >> >>>like? Would it still have entity="pres:bob@biloxi.com", and >> >>just have >> >>>alice's tuples? >> >>I also can't think of a use case where this is valid. But >>neither can I >>think of a use case where (3) is valid - I can't think of a business >>model where the operator of the presence server for Bob would >>want to do >>this. >> >>I think (1) is the interesting use case, and it works regardless of >>whether the target is chosen using the request uri or the To uri. >> >> > IMO, this sort of thing could be more easily achieved by >> >>>configuring Alice's EPAs to publish presence directly to >>>sip:bob@biloxi.com. >> >>I think if Alice is going away and wants to forward calls to >>Bob, that >>she should do something different with her presence. Probably >>configure >>some static state indicating she is away, and listing Bob as an >>alternative contact. Her forwarding should not include >>subscriptions for >>presence. >> >>If she neglects to do this then all the alternatives seem to provide >>comparably useless results. >> >> >>>So in my opinion, the key issue really is whether we see 3) >> >>as useful, >> >>>and/or feasible. That is the only use-case I can think of >> >>right now that >> >>>would strictly require using the To-field as the resource >> >>pointer. This >> >>>would also require some clarification to RFC 3265 on resource >>>identification, so it's not an entirely uncontroversial >> >>road to take >> >>>either. >> >>Covered above. >> >> Paul >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 15:07:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08819 for ; Tue, 30 Sep 2003 15:07:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pq9-0004c2-DF for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 15:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJ7Hq7017726 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 15:07:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ppv-0004ZN-IG; Tue, 30 Sep 2003 15:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PpJ-0004Wz-RT for sip@optimus.ietf.org; Tue, 30 Sep 2003 15:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08631 for ; Tue, 30 Sep 2003 15:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PpG-0003QQ-00 for sip@ietf.org; Tue, 30 Sep 2003 15:06:22 -0400 Received: from web41507.mail.yahoo.com ([66.218.93.90]) by ietf-mx with smtp (Exim 4.12) id 1A4PpG-0003Pl-00 for sip@ietf.org; Tue, 30 Sep 2003 15:06:22 -0400 Message-ID: <20030930190552.85025.qmail@web41507.mail.yahoo.com> Received: from [131.107.3.79] by web41507.mail.yahoo.com via HTTP; Tue, 30 Sep 2003 12:05:52 PDT Date: Tue, 30 Sep 2003 12:05:52 -0700 (PDT) From: Sean Olson Subject: RE: [Sip] Re:draft-ietf-sip-publish-00.txt To: hisham.khartabil@nokia.com, pkyzivat@cisco.com, aki.niemi@nokia.com Cc: rsparks@dynamicsoft.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179714C@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Consistency with what? PUBLISH was built as a REGISTER++. In that vein, the To: header is used to identify the resource while the Request-URI is used to identify the ESC. I don't see a point in "forwarding" of PUBLISH. Third party PUBLISHing, yes. --- hisham.khartabil@nokia.com wrote: > The way Alice gets her PUBLISH to be delivered to > Bob is by registering her AOR (using REGISTER) with > a contact header that has Bob's URI with parameter > method=PUBLISH. Now, what is the use case for Alice > to do that? I don't know. > > About To-header vs. Request-URI: I favour > request-URI for consistency. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, September 30, 2003 4:40 PM > > To: Niemi Aki (NMP/Helsinki) > > Cc: Robert Sparks; sip@ietf.org > > Subject: Re: [Sip] > Re:draft-ietf-sip-publish-00.txt > > > > > > > > > > Aki Niemi wrote: > > > Hi, > > > > > > As long as I can remember, PUBLISH's use of To > and From have been > > > consistent with REGISTER all the way down to > explicitly > > allowing for > > > third-party publications. > > > > The use of From, and 3rd party publications isn't > in question > > here. It > > is the unaffected by how the target is selected. > > > > I admit I haven't been following the development > of PUBLISH closely > > enough to remember whether there has agreement on > how the target is > > selected. That is why I asked. Apparently Robert > thinks there was > > agreement that the request uri would be used, > while you seem to think > > that To will be used. > > > > I think consistency argues for using the request > uri, unless some > > compelling argument wins the day. But that is just > my opinion. > > > > > The use of Request-URI as identifying the > > > target resource has admittedly been ambiguously > defined. > > The way the > > > draft currently reads is that they are both kind > of used - > > which works > > > fine if they are the same. > > > > :-) > > > > > But I think Paul brings up an important issue > about > > forwarding PUBLISH > > > requests. What is the use case, and the > semantics we are > > looking for? > > > > > > 1) Alice's PUBLISH gets forwarded to Bob, whose > ESC rejects > > the request. > > > > > > -> Consequently a forwarded subscription will > deliver only > > > Bob's presence > > > > > > 2) Alice's PUBLISH gets forwarded to Bob, whose > ESC > > composes the event > > > state into Bob's presence document. > > > > > > -> Consequently a forwarded subscription will > deliver the union or > > > some combination of Bob's and Alice's > presence > > > > > > 3) Alice's PUBLISH gets forwarded to Bob, whose > ESC > > establishes event > > > state for Alice > > > > > > -> Consequently a forwarded subscription will > deliver > > Alice's presence > > > which is now "parked" in Bob's Presence > Server > > > > > > Out of these three, I especially like the > properties of 3). > > It would > > > allow one to have a static SIP address, e.g., > > "sip:aki.niemi@iki.fi", > > > which would be forwarded to whatever service > provider one > > was using at > > > the time, e.g., "sip:aki.niemi@nokia.com", > > > "sip:hillomunkki@foo.someisp.org". In practice, > I could "park" the > > > presence of "sip:aki.niemi@iki.fi" into > nokia.com, or > > foo.someisp.org's > > > presence system. > > > > > > The problem is that by default, a presence > server does > > *not* look at the > > > To-field. It only looks at the Request-URI to > determine the > > requested > > > resource. So a subscription to > "sip:aki.niemi@iki.fi" would > > deliver the > > > presence of a completely different presentity. > > > > Yes. While (3) may be interesting in some ways, to > be useful > > it requires > > a change in the way subscribe works. And I think > that would have many > > unintended consequences. While the scenario might > be useful for > > presence, it wouldn't be very appealing for other > packages, such as > > "dialog". > > > > > I don't much like 2), but that's probably > because I don't quite > > > understand the use-case. What would the > resulting presence > > document look > > > like? Would it still have > entity="pres:bob@biloxi.com", and > > just have > > > alice's tuples? > > > > I also can't think of a use case where this is > valid. But > > neither can I > > think of a use case where (3) is valid - I can't > think of a business > > model where the operator of the presence server > for Bob would > > want to do > > this. > > > > I think (1) is the interesting use case, and it > works regardless of > > whether the target is chosen using the request uri > or the To uri. > > > > > IMO, this sort of thing could be more easily > achieved by > > > configuring Alice's EPAs to publish presence > directly to > > > sip:bob@biloxi.com. > > > > I think if Alice is going away and wants to > forward calls to > > Bob, that > > she should do something different with her > presence. Probably > > configure > > some static state indicating she is away, and > listing Bob as an > > alternative contact. Her forwarding should not > include > > subscriptions for > > presence. > > > > If she neglects to do this then all the > alternatives seem to provide > > comparably useless results. > > > > > So in my opinion, the key issue really is > whether we see 3) > > as useful, > > > and/or feasible. That is the only use-case I can > think of > > right now that > > > would strictly require using the To-field as the > resource > > pointer. This > > > would also require some clarification to RFC > 3265 on resource > > > identification, so it's not an entirely > uncontroversial > > road to take > > > either. > === message truncated === __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 15:27:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10618 for ; Tue, 30 Sep 2003 15:27:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q9N-0006uU-3y for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 15:27:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJR9aS026558 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 15:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q9F-0006t2-G5; Tue, 30 Sep 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A42lr-0002LY-6h for sip@optimus.ietf.org; Mon, 29 Sep 2003 14:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02248 for ; Mon, 29 Sep 2003 14:29:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A42lo-0002pq-00 for sip@ietf.org; Mon, 29 Sep 2003 14:29:16 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A42lo-0002pV-00 for sip@ietf.org; Mon, 29 Sep 2003 14:29:16 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8TISSa09796; Mon, 29 Sep 2003 11:28:28 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 13:28:29 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578CAB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Kevin Lingle'" Cc: Jean-Francois Mule , "'sip@ietf.org'" , "'rohan@cisco.com'" Date: Mon, 29 Sep 2003 13:28:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] RE: NITS/General Editorial Comments on draft-ietf-sip-mib-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I've snipped the email to just respond to 2 points [MB]: -----Original Message----- From: Kevin Lingle [mailto:klingle@cisco.com] Sent: Monday, September 29, 2003 12:05 PM To: Barnes, Mary [NGC:B602:EXCH] Cc: Jean-Francois Mule; 'sip@ietf.org'; 'rohan@cisco.com' Subject: Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07 mary, responding to the nits/general comments.... ----1st part of response snipped by Mary----------- > > - Section 8: My understanding is that this section should be removed by the > RFC Editor. Thus, I would suggest adding a comment as such (something like: > "This section to be removed by RFC Editor before publication." and moving > this section just prior to the Author's address to facilitate that process. done (patially). i added the line you suggested to the section, but didn't move the section. the xml2rfc tool we've started using appears rather ridge in some of the "template" sections. i'm not exactly certain on altering the order of sections that are part of the . how important is it that we move this section since it will be removed anyway? [MB] That's fine. This was just a suggestion to simplify the final editorial process (i.e. section numbering). > > - Section 9, page 109. The statement "If these objects are SET maliciously, > it may result in > incorrect or unwanted protocol operation." is probably a bit of an > understatement with regards to the timer, retry and expire values being > misconfigured. Certainly, a well designed system would but reasonable > boundaries on how these things can be configured, so as to hopefully prevent > significant problems. Cullen had brought up the more general issue of > whether all the timers should be configurable in his comments. Like Cullen, > I haven't thought about this enough to decide whether all these timers > should be configurable, but at a minimum, I think the security section > needs a more robust statement. is this commented wrt the entire security section or just the area you referred to on pg 109? is it that we have not made a strong enough statement about the protocol impact to these particular timer/retry related objects being SET?? [MB] This comment was specific to the timer/retry and related objects being set. My point was that it's beyond being incorrect or unwanted protocol operation, but rather has a broader impact on the server and its ability to process new and existing transactions and the clients making use of the server. I think, though, that the broader question is whether all of these should be configurable, per Cullen's comments. thanks! kevin > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > > > > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Sep 30 16:15:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14189 for ; Tue, 30 Sep 2003 16:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qtw-0003gY-BW for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 16:15:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UKFGxY014109 for sip-archive@odin.ietf.org; Tue, 30 Sep 2003 16:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qtj-0003ed-Uv; Tue, 30 Sep 2003 16:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qsx-0003cl-Ja for sip@optimus.ietf.org; Tue, 30 Sep 2003 16:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14103 for ; Tue, 30 Sep 2003 16:14:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qsv-0004m2-00 for sip@ietf.org; Tue, 30 Sep 2003 16:14:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Qsv-0004kr-00 for sip@ietf.org; Tue, 30 Sep 2003 16:14:13 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 13:18:37 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8UKDewn014720; Tue, 30 Sep 2003 13:13:40 -0700 (PDT) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACU22971; Tue, 30 Sep 2003 16:13:38 -0400 (EDT) Message-ID: <3F79E3F2.6010405@cisco.com> Date: Tue, 30 Sep 2003 16:13:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Re:draft-ietf-sip-publish-00.txt References: <20030930190552.85025.qmail@web41507.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sean Olson wrote: > Consistency with what? PUBLISH was built as a > REGISTER++. In that vein, the To: header is used to > identify the resource while the Request-URI is used to > identify the ESC. I don't see a point in "forwarding" > of PUBLISH. Third party PUBLISHing, yes. *If* this is the intent, then you should go the whole way, and specify that the request uri should identify only the domain when the request is first sent. This in turn requires the proxy for the domain to handle PUBLISH specially (as REGISTER is), either by implementing it, or by having special purpose logic to route it based on the To uri. Trying to have it both ways, by routing based on the request uri but having the recipient select the target based on the To uri, is going to cause a mess. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip