From exim@www1.ietf.org Fri Aug 1 15:07: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 PAA05103 for ; Fri, 1 Aug 2003 15:07: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 19ifFF-0008Fz-1N for sip-archive@odin.ietf.org; Fri, 01 Aug 2003 15:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71J7HVf031735 for sip-archive@odin.ietf.org; Fri, 1 Aug 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 19ifE3-00087q-3X; Fri, 01 Aug 2003 15: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 19ifDV-000874-Bb for sip@optimus.ietf.org; Fri, 01 Aug 2003 15:05:29 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04799 for ; Fri, 1 Aug 2003 15:05:22 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19ifCg-0006o7-GF; Fri, 01 Aug 2003 15:04:38 -0400 From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Fri, 01 Aug 2003 15:04:38 -0400 Subject: [Sip] Protocol Action: 'Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 IESG has approved the Internet-Draft 'Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration' as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines a SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering User Agent (UA), that is, an end-user, of a service route that the UA may use to request outbound services from the registrar's domain. SIP has a Route Header which is used to loose source route messages, and this Service Route extension allows providers to offer plans in which a user can ensure that they visit a provider's proxy at which they registered. IETF protocols should neither favor nor preclude* such capabilities. Security for the user and the provider are provided by the use of the SIP sips: address of record mandating that the hops be carried over TLS, and use of S/MIME for the bodies in the messages. Working Group Summary There was active review. This document was split out from the other direction, called the PATH header and worked on until it had adequate clarity and security. Its current version has good consensus. Protocol Quality This document has been reviewed for the IESG by Rohan Mahy and and Allison Mankin. Some implementations were tested in recent interoperability events. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 1 15:30:56 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 PAA07191 for ; Fri, 1 Aug 2003 15:30: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 19ifbh-0001af-Hn for sip-archive@odin.ietf.org; Fri, 01 Aug 2003 15:30:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71JUTeB006113 for sip-archive@odin.ietf.org; Fri, 1 Aug 2003 15:30:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifbG-0001Ye-5b; Fri, 01 Aug 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifaK-00013Q-5M for sip@optimus.ietf.org; Fri, 01 Aug 2003 15:29:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06910; Fri, 1 Aug 2003 15:29:00 -0400 (EDT) Message-Id: <200308011929.PAA06910@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: Fri, 01 Aug 2003 15:29:00 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-07.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 : Management Information Base for Session Initiation Protocol (SIP) Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker Filename : draft-ietf-sip-mib-07.txt Pages : 116 Date : 2003-8-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-07.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-mib-07.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-mib-07.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-1153809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1153809.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 Mon Aug 4 13:25: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 SMTP id NAA04776 for ; Mon, 4 Aug 2003 13:25: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 19jj5I-00066b-NO for sip-archive@odin.ietf.org; Mon, 04 Aug 2003 13:25:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74HPOTH023468 for sip-archive@odin.ietf.org; Mon, 4 Aug 2003 13:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jj4w-000665-Ka; Mon, 04 Aug 2003 13: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 19jj40-00065Y-9e for sip@optimus.ietf.org; Mon, 04 Aug 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 SMTP id NAA04761 for ; Mon, 4 Aug 2003 13:23:58 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jj3y-00042v-00 for sip@ietf.org; Mon, 04 Aug 2003 13:24:02 -0400 Received: from imo-m06.mx.aol.com ([64.12.136.161]) by ietf-mx with esmtp (Exim 4.12) id 19jj3x-00042e-00 for sip@ietf.org; Mon, 04 Aug 2003 13:24:01 -0400 Received: from Mpierce1@aol.com by imo-m06.mx.aol.com (mail_out_v36_r1.1.) id 7.44.33e1505e (4222); Mon, 4 Aug 2003 13:23:24 -0400 (EDT) Message-ID: <44.33e1505e.2c5ff08b@aol.com> Date: Mon, 4 Aug 2003 13:23:23 EDT Subject: Re: [Sip] draft-ietf-resource-priority-01 draft To: hgs@cs.columbia.edu, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_44.33e1505e.2c5ff08b_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_44.33e1505e.2c5ff08b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments as follows: 1. Number of priority values There continues to be a problem with the possible number of priority values per namespace. Since the whole purpose of this header to provide priority for one call over another, there must be, at a minimum, two values registered per namespace. The IANA considerations states that: "The registration MUST indicate the default level to be assumed in the absence of the priority value or if the implementation does not understand a level from the namespace." This necessitates the registration of a "normal" level (to be the default) in order to be able to assign an "elevated" level. A namespace can not contain only one value. Section 3 states "Each namespace has at least one priority value." and "We require that even namespaces with only one priority value list that value to avoid problems ..." If the change proposed above to require multiple levels is made, the above statement ("We require...") can be deleted. Otherwise, it needs to be modified, since it isn't clear whether it is intended to refer to the IANA considerations or the contents of the Resource-Priority header. If the former, it should be moved to Section 12 and state that "Namespaces with only one priority value MUST register that value to avoid problems if additional priority values are added later". If the latter, it should state: "If a namespace only contains one priority value, that value SHOULD still be included in a Resource-Priority header to avoid problems if additional priority values are added later." 2. Number of headers There is also a confusion about the number of R-P headers which may be included. While 4.5 correctly states that "The UAC MUST only include at most one Resource-Priority header field in the request.", Section 3 includes the statement that "There may be multiple resource values or, equivalently, multiple Resource-Priority header fields." (which is followed by the example of the US Wireless Priority System). It isn't clear how to interpret this example, since it refers to possible namespaces and priorities which aren't defined in this document. I suggest that these two paragraphs be deleted. Other text already indicates that an R-P header can contain multiple namespaces but not multiple values per namespace. 3. References to ETS The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 should be changed, since the headers defined in this document apply to more than what is commonly called "ETS". The three namespaces defined in Annex B are not a part of "ETS". The first sentence further states that ETS "must be protected from intercept and alteration" (lower case "must"). It isn't clear whether this was intended as a normative "MUST", or simply a statement that confidentiality and integrity are good things to have. Since requirements for this are distinct from the requirements for the Resource-Priority header, this statement should be corrected to not imply that this is a requirement. (In some cases, a call using the R-P header is not required to have confidentiality.) I would suggest wording this first sentence as "Calls which use elevated priority levels provided by the Resource-Priority header are likely to be sensitive and often need to be protected ..." Likewise, Section 8.4 should be reworded to "As noted, systems which use the Resource-Priority header are likely to be subject ..." 4. IANA Considerations The final paragraph under IANA Consideration in Section 12 states: "Namespaces MAY also impose particular authentication or authorization consideration that are stricter than the baseline described here." This implies that this is a part of the IANA registration, that is, that it is specified when registering a namespace. Since this should be a local matter and not a part of registration, it should not be stated here but moved to the end of Section 8.1. Mike Pierce --part1_44.33e1505e.2c5ff08b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Comments as follows:

1. Number of priority values

There continues to be a problem with the possible number of priority val= ues per namespace. Since the whole purpose of this header to provide priorit= y for one call over another, there must be, at a minimum, two values registe= red per namespace.

The IANA considerations states that: "The registration MUST indicate the= default level to be assumed in the absence of the priority value or if the=20= implementation does not understand a level from the namespace." This necessi= tates the registration of a "normal" level (to be the default) in order to b= e able to assign an "elevated" level. A namespace can not contain only one v= alue.

Section 3 states "Each namespace has at least one priority value." and "= We require that even namespaces with only one priority value list that value= to avoid problems ..."

If the change proposed above to require multiple levels is made, the abo= ve statement ("We require...") can be deleted.  Otherwise, it needs to=20= be modified, since it isn't clear whether it is intended to refer to the IAN= A considerations or the contents of the Resource-Priority header. If the for= mer, it should be moved to Section 12 and state that "Namespaces with only o= ne priority value MUST register that value to avoid problems if additional p= riority values are added later". If the latter, it should state: "If a names= pace only contains one priority value, that value SHOULD still be included i= n a Resource-Priority header to avoid problems if additional priority values= are added later."

2. Number of headers

There is also a confusion about the number of R-P headers which may be i= ncluded. While 4.5 correctly states that "The UAC MUST only include at most=20= one Resource-Priority header field in the request.", Section 3 includes the=20= statement that "There may be multiple resource values or, equivalently, mult= iple Resource-Priority header fields." (which is followed by the example of=20= the US Wireless Priority System). It isn't clear how to interpret this examp= le, since it refers to possible namespaces and priorities which aren't defin= ed in this document. I suggest that these two paragraphs be deleted. Other t= ext already indicates that an R-P header can contain multiple namespaces but= not multiple values per namespace.

3. References to ETS

The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 sho= uld be changed, since the headers defined in this document apply to more tha= n what is commonly called "ETS". The three namespaces defined in Annex B are= not a part of "ETS".

The first sentence further states that ETS "must be protected from inter= cept and alteration" (lower case "must"). It isn't clear whether this was in= tended as a normative "MUST", or simply a statement that confidentiality and= integrity are good things to have. Since requirements for this are distinct= from the requirements for the Resource-Priority header, this statement shou= ld be corrected to not imply that this is a requirement. (In some cases, a c= all using the R-P header is not required to have confidentiality.) I would s= uggest wording this first sentence as "Calls which use elevated priority lev= els provided by the Resource-Priority header are likely to be sensitive and=20= often need to be protected ..."

Likewise, Section 8.4 should be reworded to "As noted, systems which use= the Resource-Priority header are likely to be subject ..."

4. IANA Considerations

The final paragraph under IANA Consideration in Section 12 states:

"Namespaces MAY also impose particular authentication or authorization c= onsideration that are stricter than the baseline described here."

This implies that this is a part of the IANA registration, that is, that= it is specified when registering a namespace. Since this should be a local=20= matter and not a part of registration, it should not be stated here but move= d to the end of Section 8.1.

Mike Pierce
--part1_44.33e1505e.2c5ff08b_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 4 17:57: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 SMTP id RAA12891 for ; Mon, 4 Aug 2003 17:57: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 19jnKR-0006jJ-M4 for sip-archive@odin.ietf.org; Mon, 04 Aug 2003 17:57:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74LvJTH025813 for sip-archive@odin.ietf.org; Mon, 4 Aug 2003 17:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnKA-0006hq-CO; Mon, 04 Aug 2003 17: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 19jnJb-0006hJ-4U for sip@optimus.ietf.org; Mon, 04 Aug 2003 17:56:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12850 for ; Mon, 4 Aug 2003 17:56:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnJY-0005rG-00 for sip@ietf.org; Mon, 04 Aug 2003 17:56:24 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19jnJX-0005rC-00 for sip@ietf.org; Mon, 04 Aug 2003 17:56:23 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <3S5QNFZZ>; Mon, 4 Aug 2003 17:54:18 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AAB7@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: hgs@cs.columbia.edu, sip@ietf.org Subject: RE: [Sip] draft-ietf-resource-priority-01 draft Date: Mon, 4 Aug 2003 17:54:14 -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 am a little confused by this paragraph in section 2 (immediately after the enumeration of the ways in which the resource priority header can be used). "This header field is related to, but differs in semantics from, the Priority header field (RFC 3261 [2], Section 20.26). The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. While it does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header to cause such influence may be defined in other documents." Does the "it" in the third and fourth refer to the "Resource Priority Header" or the "Priority Header"? Logically, it would seem to mean the RPH (in the fourth sentence, if not the third). But syntactically, it seems to mean the PH. I think it is just an editing nit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 6 08:58: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 IAA14654 for ; Wed, 6 Aug 2003 08:58: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 19kNrG-0003eo-GH for sip-archive@odin.ietf.org; Wed, 06 Aug 2003 08:57:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76CvcYt014055 for sip-archive@odin.ietf.org; Wed, 6 Aug 2003 08:57:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNqg-0003dp-Cl; Wed, 06 Aug 2003 08: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 19kNqa-0003dZ-7V for sip@optimus.ietf.org; Wed, 06 Aug 2003 08:56: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 IAA14624 for ; Wed, 6 Aug 2003 08:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kNqX-0002Yu-00 for sip@ietf.org; Wed, 06 Aug 2003 08:56:53 -0400 Received: from h35s128a211n47.user.nortelnetworks.com ([47.211.128.35] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19kNqW-0002Yf-00 for sip@ietf.org; Wed, 06 Aug 2003 08:56:52 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76Ctm219818; Wed, 6 Aug 2003 13:55:48 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 13:55:48 +0100 Message-ID: From: "Mark Watson" To: "'Henning Schulzrinne'" , "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-resource-priority-01 draft Date: Wed, 6 Aug 2003 13:55:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C1A.0D74DDF6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C35C1A.0D74DDF6 Content-Type: text/plain Henning, It may not have been intentional, but I read a slight implication in the draft that the authorisation decision (whether a method should be afforded the priority requested) was based just on the identity of the caller. I think it would be useful to clarify somewhere that other things may be taken into account as well, such as the requested destination. Regards...Mark -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: 28 July 2003 19:10 To: sip@ietf.org Subject: [Sip] draft-ietf-resource-priority-01 draft The revised version of the draft, based on discussions in Vienna, is now in the archives. I would appreciate comments http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.txt Thanks. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C35C1A.0D74DDF6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-resource-priority-01 draft

Henning,

It may not have been intentional, but I read a slight = implication in the draft that the authorisation decision (whether a = method should be afforded the priority requested) was based just on the = identity of the caller.

I think it would be useful to clarify somewhere that = other things may be taken into account as well, such as the requested = destination.

Regards...Mark

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] =
Sent: 28 July 2003 19:10
To: sip@ietf.org
Subject: [Sip] draft-ietf-resource-priority-01 = draft


The revised version of the draft, based on = discussions in Vienna, is now
in the archives. I would appreciate comments

http://www.ietf.org/internet-drafts/draft-ietf-sip-res= ource-priority-01.txt

Thanks.

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C35C1A.0D74DDF6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 6 09:29: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 JAA15774 for ; Wed, 6 Aug 2003 09:29: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 19kOLp-000591-RT for sip-archive@odin.ietf.org; Wed, 06 Aug 2003 09:29:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76DTDdn019748 for sip-archive@odin.ietf.org; Wed, 6 Aug 2003 09:29:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOLd-00054W-OQ; Wed, 06 Aug 2003 09:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOLF-00054F-RC for sip@optimus.ietf.org; Wed, 06 Aug 2003 09:28: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 JAA15747 for ; Wed, 6 Aug 2003 09:28:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOLE-0002ne-00 for sip@ietf.org; Wed, 06 Aug 2003 09:28:36 -0400 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19kOLD-0002nS-00 for sip@ietf.org; Wed, 06 Aug 2003 09:28:35 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ700A019EQ5C@mailout3.samsung.com> for sip@ietf.org; Wed, 06 Aug 2003 22:28:02 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ700FQ09EPHV@mailout3.samsung.com> for sip@ietf.org; Wed, 06 Aug 2003 22:28:01 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ7006ZZ9ENZP@mmp1.samsung.com> for sip@ietf.org; Wed, 06 Aug 2003 22:28:01 +0900 (KST) Date: Wed, 06 Aug 2003 18:51:46 +0530 From: Ranjit Avasarala In-reply-to: <3F203D8D.6070203@nortelnetworks.com> To: sip@ietf.org Cc: sip-implementors@cs.columbia.edu Reply-to: ranjitk@samsung.com Message-id: <001d01c35c1d$b07f5e10$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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Sip] Sip unicode support Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 How to support unicode in SIP? My requirement is to support Japanese / korean characters using unicode Thanks Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 6 09:35: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 JAA15943 for ; Wed, 6 Aug 2003 09:35: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 19kORY-0005SC-Df for sip-archive@odin.ietf.org; Wed, 06 Aug 2003 09:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76DZ8Zk020934 for sip-archive@odin.ietf.org; Wed, 6 Aug 2003 09:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kORS-0005M2-Mh; Wed, 06 Aug 2003 09: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 19kOQo-0005LC-Qp for sip@optimus.ietf.org; Wed, 06 Aug 2003 09:34: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 JAA15878 for ; Wed, 6 Aug 2003 09:34:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOQn-0002qY-00 for sip@ietf.org; Wed, 06 Aug 2003 09:34:21 -0400 Received: from natsmtp00.webmailer.de ([192.67.198.74] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19kOQm-0002qQ-00 for sip@ietf.org; Wed, 06 Aug 2003 09:34:20 -0400 Received: from discofox (p3E9BAA0E.dip.t-dialin.net [62.155.170.14]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h76DXejZ008725; Wed, 6 Aug 2003 15:33:46 +0200 (MEST) From: "Christian Stredicke" To: , Cc: Subject: AW: [Sip] Sip unicode support Date: Wed, 6 Aug 2003 15:33:53 +0200 Message-ID: <007001c35c1f$6b5dd940$2f00a8c0@discofox> 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 In-Reply-To: <001d01c35c1d$b07f5e10$e9076c6b@sisodomain.com> Importance: Normal 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 Just use UTF-8 for example in the display-name. The character set of URL is limited as indicated in the RFC 3261. CS > -----Urspr=FCngliche Nachricht----- > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von Ranjit > Avasarala > Gesendet: Mittwoch, 6. August 2003 15:22 > An: sip@ietf.org > Cc: sip-implementors@cs.columbia.edu > Betreff: [Sip] Sip unicode support >=20 >=20 >=20 > Hi > How to support unicode in SIP? My requirement is to support Japanese > / korean characters using unicode >=20 > Thanks > Ranjit >=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 Wed Aug 6 13:16: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 NAA25248 for ; Wed, 6 Aug 2003 13:16: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 19kRtX-0007Ga-T4 for sip-archive@odin.ietf.org; Wed, 06 Aug 2003 13:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HGFMI027921 for sip-archive@odin.ietf.org; Wed, 6 Aug 2003 13:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRtJ-0007Es-O1; Wed, 06 Aug 2003 13:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRsZ-0007CJ-Sm for sip@optimus.ietf.org; Wed, 06 Aug 2003 13:15: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 NAA25183 for ; Wed, 6 Aug 2003 13:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRsX-0004ni-00 for sip@ietf.org; Wed, 06 Aug 2003 13:15: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 19kRsX-0004nP-00 for sip@ietf.org; Wed, 06 Aug 2003 13:15:13 -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 h76HEgB17620 for ; Wed, 6 Aug 2003 12:14:42 -0500 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1060190072.932.47.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 06 Aug 2003 12:14:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC summary : Referred-by Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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've revised Referred-By based on the comments received during WGLC. I incorporated all of Mary's suggestions except for reducing the strength of rejecting requests with invalid tokens from MUST to SHOULD. She and I were the only people to comment on the issue, so I left it the way it it had been. The updated draft can be retrieved from http://www.nostrum.com/~rjsparks/draft-ietf-sip-referredby-03.txt until it appears in the repository. I believe this is ready to send to the IESG. 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 Aug 7 07:53: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 HAA08920 for ; Thu, 7 Aug 2003 07:53:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKm-0001E6-63 for sip-archive@odin.ietf.org; Thu, 07 Aug 2003 07:53:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77BrWLC004710 for sip-archive@odin.ietf.org; Thu, 7 Aug 2003 07:53:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKH-00019D-Qo; Thu, 07 Aug 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 19kjKG-00018f-7o for sip@optimus.ietf.org; Thu, 07 Aug 2003 07:53:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08846; Thu, 7 Aug 2003 07:52:55 -0400 (EDT) Message-Id: <200308071152.HAA08846@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, 07 Aug 2003 07:52:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-03.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 SIP Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-03.txt Pages : 25 Date : 2003-8-6 The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.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-referredby-03.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-referredby-03.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-6143402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6143402.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 Aug 7 12:12: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 MAA20596 for ; Thu, 7 Aug 2003 12:12: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 19knNE-0004hK-Jd for sip-archive@odin.ietf.org; Thu, 07 Aug 2003 12:12:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77GCKg1018022 for sip-archive@odin.ietf.org; Thu, 7 Aug 2003 12:12:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knMx-0004fk-9U; Thu, 07 Aug 2003 12:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCYK-0005jb-3F for sip@optimus.ietf.org; Thu, 31 Jul 2003 08:29: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 IAA22413 for ; Thu, 31 Jul 2003 08:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCYI-00031U-00 for sip@ietf.org; Thu, 31 Jul 2003 08:29:02 -0400 Received: from [207.44.196.29] (helo=bharatmail.com) by ietf-mx with esmtp (Exim 4.12) id 19iCYH-00030v-00 for sip@ietf.org; Thu, 31 Jul 2003 08:29:01 -0400 Received: from server1.bharatmart.com (ensim.rackshack.net [207.44.196.29]) by bharatmail.com (8.11.6/8.11.6) with ESMTP id h6VEx1K14908 for sip@ietf.org; Thu, 31 Jul 2003 09:59:02 -0500 Message-Id: <200307311459.h6VEx1K14908@bharatmail.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: murali To: sip@ietf.org Date: Thu Jul 31 17:57:40 2003 Content-Transfer-Encoding: binary Subject: [Sip] SIP authentication Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: binary Hi, Can someone send me an example proxy-authenticate, proxy-authorization headers and password used along with the intermidiate values i.e H(A1) and H(A2). in the process of computing the resoponse. Thanks and regards, Murali ------- _____________________________________________________________ Get Your Free ScanMail and Email At http://mail.ttkbharatplanet.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 Aug 7 12:12: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 MAA20597 for ; Thu, 7 Aug 2003 12:12: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 19knNE-0004hE-JN for sip-archive@odin.ietf.org; Thu, 07 Aug 2003 12:12:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77GCKRo018021 for sip-archive@odin.ietf.org; Thu, 7 Aug 2003 12:12:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knMw-0004fa-AJ; Thu, 07 Aug 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 19hS32-0006TP-Sy for sip@optimus.ietf.org; Tue, 29 Jul 2003 06: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 GAA18115 for ; Tue, 29 Jul 2003 06:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hS2y-0004EH-00 for sip@ietf.org; Tue, 29 Jul 2003 06:49:36 -0400 Received: from [202.56.196.162] (helo=brahma.intotoind.com) by ietf-mx with esmtp (Exim 4.12) id 19hS2w-0004ED-00 for sip@ietf.org; Tue, 29 Jul 2003 06:49:35 -0400 Received: from intoto4.intotoinc.com (1mc232.intotoind.com [172.16.1.232]) by brahma.intotoind.com (8.12.6/8.11.6) with ESMTP id h6TAm0jk006006 for ; Tue, 29 Jul 2003 16:18:01 +0530 Message-Id: <5.1.0.14.0.20030729162346.00a72dd0@172.16.1.10> X-Sender: mskanth@172.16.1.10 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jul 2003 16:25:59 +0530 To: sip@ietf.org From: sreekanth Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Subject: [Sip] information required about paid sip 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 please let me know if there are any paid sip proxies are available to test the sip useragents. regards mskanth _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 8 16:25:25 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 QAA24718 for ; Fri, 8 Aug 2003 16:25:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDnH-00061O-Gu for sip-archive@odin.ietf.org; Fri, 08 Aug 2003 16:25:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOxtR023145 for sip-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmU-0005dS-VF; Fri, 08 Aug 2003 16:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDgR-0005IV-5R for sip@optimus.ietf.org; Fri, 08 Aug 2003 16:17: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 QAA24251 for ; Fri, 8 Aug 2003 16:17:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDgP-0003fL-00 for sip@ietf.org; Fri, 08 Aug 2003 16:17:53 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19lDgN-0003fE-00 for sip@ietf.org; Fri, 08 Aug 2003 16:17:52 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h78KHojZ024291 for ; Fri, 8 Aug 2003 13:17:50 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h78KHm76022122 for ; Fri, 8 Aug 2003 15:17:49 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 8 Aug 2003 15:17:48 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F74110FF97ED@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: sip@ietf.org Date: Fri, 8 Aug 2003 15:17:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DE9.DB95E784" Subject: [Sip] SIP SUBSCRIBE 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_01C35DE9.DB95E784 Content-Type: text/plain Hi, What is the expected behavior of Notifier if it receives a SUBSCRIBE message from a UAC in the following scenario - The SUBSCRIBE is sent with a new Call-ID when there is already an existing dialog associated with the same UAC and for the same Event Package Should the Notifier overwrite the new subscription with the existing subscription (update the expire interval) or not? Best Regards - Ajay ------_=_NextPart_001_01C35DE9.DB95E784 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1s bnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxNRVRBIEhU VFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PVVTLUFT Q0lJIj4NCg0KDQo8bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdvcmQuRG9jdW1lbnQ+DQo8bWV0 YSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCI+DQo8bWV0YSBuYW1l PU9yaWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTAiPg0KPGxpbmsgcmVsPUZpbGUt TGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQzM1REMwLjM5Q0M0QzIwIj4NCjx0aXRsZT5N ZXNzYWdlPC90aXRsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOk9mZmljZURvY3Vt ZW50U2V0dGluZ3M+DQogIDxvOkRvTm90UmVseU9uQ1NTLz4NCiA8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3 OldvcmREb2N1bWVudD4NCiAgPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRl Pg0KICA8dzpHcmFtbWFyU3RhdGU+Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpEb2N1bWVu dEtpbmQ+RG9jdW1lbnRFbWFpbDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3BlVmlzLz4N CiAgPHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5PjA8L3c6RGlzcGxheUhvcml6 b250YWxEcmF3aW5nR3JpZEV2ZXJ5Pg0KICA8dzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3JpZEV2 ZXJ5PjA8L3c6RGlzcGxheVZlcnRpY2FsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6VXNlTWFyZ2lu c0ZvckRyYXdpbmdHcmlkT3JpZ2luLz4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkZvb3Ru b3RlTGF5b3V0TGlrZVdXOC8+DQogICA8dzpTaGFwZUxheW91dExpa2VXVzgvPg0KICAgPHc6QWxp Z25UYWJsZXNSb3dCeVJvdy8+DQogICA8dzpGb3JnZXRMYXN0VGFiQWxpZ25tZW50Lz4NCiAgIDx3 OkRvTm90VXNlSFRNTFBhcmFncmFwaEF1dG9TcGFjaW5nLz4NCiAgIDx3OkxheW91dFJhd1RhYmxl V2lkdGgvPg0KICAgPHc6TGF5b3V0VGFibGVSb3dzQXBhcnQvPg0KICAgPHc6VXNlV29yZDk3TGlu ZUJyZWFraW5nUnVsZXMvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVs Pk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERv Y3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xl O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJbXNvLXN0eWxl LW5vc2hvdzp5ZXM7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1hc2NpaS1mb250LWZhbWls eTpBcmlhbDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6QXJpYWw7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1o YW5zaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCglj b2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJ bXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDEw XT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxU YWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2Jh bmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0 IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxlPg0KPCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZSBzdHlsZT0ndGFiLWludGVydmFsOi41aW4nPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUn PkhpLCA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+V2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVo YXZpb3Igb2YgTm90aWZpZXINCmlmIGl0IHJlY2VpdmVzIGEgU1VCU0NSSUJFIG1lc3NhZ2UgZnJv bSBhIFVBQyBpbiB0aGUgZm9sbG93aW5nIHNjZW5hcmlvPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6 ZT0zPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OmJsdWUnPi0gVGhlIFNVQlNDUklCRSA8L3NwYW4+PC9mb250Pjxmb250DQpjb2xvcj1uYXZ5IGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPmk8L3Nw YW4+PC9mb250Pjxmb250DQpjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPnMgc2VudCB3aXRoIGENCm5ldyBDYWxsLUlEIHdoZW4g dGhlcmUgaXMgYWxyZWFkeSBhbiBleGlzdGluZyBkaWFsb2cgYXNzb2NpYXRlZCB3aXRoIHRoZSBz YW1lDQpVQUMgYW5kIGZvciB0aGUgc2FtZSBFdmVudCBQYWNrYWdlIDwvc3Bhbj48L2ZvbnQ+PGZv bnQgc2l6ZT0zPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjpibHVlJz5TaG91bGQgdGhlIE5vdGlmaWVyIG92ZXJ3cml0ZSB0aGUgbmV3DQpzdWJz Y3JpcHRpb24gd2l0aCB0aGUgZXhpc3Rpbmcgc3Vic2NyaXB0aW9uICh1cGRhdGUgdGhlIGV4cGly ZSBpbnRlcnZhbCkgb3INCm5vdD88L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5CZXN0IFJl Z2FyZHM8L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mw0KY29sb3I9bmF2eT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpuYXZ5Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OmJsdWUnPi0gQWpheTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C35DE9.DB95E784-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 9 18: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 SAA09589 for ; Sat, 9 Aug 2003 18: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 19lcBw-0002Sh-Ij for sip-archive@odin.ietf.org; Sat, 09 Aug 2003 18:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h79MS4Qd009461 for sip-archive@odin.ietf.org; Sat, 9 Aug 2003 18:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lcAv-0002S5-LY; Sat, 09 Aug 2003 18: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 19lcA4-0002Pu-EK for sip@optimus.ietf.org; Sat, 09 Aug 2003 18:26: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 SAA09547 for ; Sat, 9 Aug 2003 18:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lc9w-0003HO-00 for sip@ietf.org; Sat, 09 Aug 2003 18:26:00 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19lc9v-0003HL-00 for sip@ietf.org; Sat, 09 Aug 2003 18:26:00 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h79MPxJm007203 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Aug 2003 18:25:59 -0400 (EDT) Message-ID: <3F3574EE.2090108@cs.columbia.edu> Date: Sat, 09 Aug 2003 18:25:50 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-resource-priority-01 draft References: <44.33e1505e.2c5ff08b@aol.com> In-Reply-To: <44.33e1505e.2c5ff08b@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 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 Mike, thanks for your comments. http://www1.cs.columbia.edu/sip/drafts/draft-ietf-sip-resource-priority-02.txt reflects the resolution of these and the other recent list comments (I have not yet submitted this version). A few clarifications in-line. Mpierce1@aol.com wrote: > Comments as follows: > > 1. Number of priority values > > There continues to be a problem with the possible number of priority > values per namespace. Since the whole purpose of this header to provide > priority for one call over another, there must be, at a minimum, two > values registered per namespace. Not really. This has always been confusing, due to the definition of default values. However, with the -01 clarification, the notion of default values actually makes little sense in general. I think it would be more precise to say that some namespaces happen to have a value that is equivalent to omitting the priority value altogether, but that is not required. This is independent of the number of priority values; for example, one could imagine a namespace with the labels postal, important, house-on-fire where postal indicates that the call should wait behind all regular (non-marked calls), while important and 'house-on-fire' calls get priority treatment. If you want the regular treatment, just don't include the header. (Something similar actually happens to be the only 'QoS' measure being used in Internet2 - the scavenger service [http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt] I have hopefully removed the remnants of text referring to default priority values. > > The IANA considerations states that: "The registration MUST indicate the > default level to be assumed in the absence of the priority value or if > the implementation does not understand a level from the namespace." This > necessitates the registration of a "normal" level (to be the default) in > order to be able to assign an "elevated" level. A namespace can not > contain only one value. I removed the text. > > Section 3 states "Each namespace has at least one priority value." and > "We require that even namespaces with only one priority value list that > value to avoid problems ..." Removed. > > 2. Number of headers > > There is also a confusion about the number of R-P headers which may be > included. While 4.5 correctly states that "The UAC MUST only include at > most one Resource-Priority header field in the request.", Section 3 > includes the statement that "There may be multiple resource values or, > equivalently, multiple Resource-Priority header fields." (which is > followed by the example of the US Wireless Priority System). It isn't > clear how to interpret this example, since it refers to possible > namespaces and priorities which aren't defined in this document. I > suggest that these two paragraphs be deleted. Other text already > indicates that an R-P header can contain multiple namespaces but not > multiple values per namespace. As per the previous discussion, multiple namespace.priority values are permissible, obviously only with different namespaces. The contradictory text was yanked. > > 3. References to ETS > > The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 > should be changed, since the headers defined in this document apply to > more than what is commonly called "ETS". The three namespaces defined in > Annex B are not a part of "ETS". All references to ETS have been reworded as suggested. > 4. IANA Considerations > > The final paragraph under IANA Consideration in Section 12 states: > > "Namespaces MAY also impose particular authentication or authorization > consideration that are stricter than the baseline described here." > > This implies that this is a part of the IANA registration, that is, that > it is specified when registering a namespace. Since this should be a > local matter and not a part of registration, it should not be stated > here but moved to the end of Section 8.1. Moved. > > Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 9 23:36: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 XAA14480 for ; Sat, 9 Aug 2003 23:36: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 19lh0G-0001pn-Jj for sip-archive@odin.ietf.org; Sat, 09 Aug 2003 23:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A3aK8T007047 for sip-archive@odin.ietf.org; Sat, 9 Aug 2003 23:36:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lgzy-0001pD-Ee; Sat, 09 Aug 2003 23:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lgzD-0001or-Nt for sip@optimus.ietf.org; Sat, 09 Aug 2003 23:35: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 XAA14450 for ; Sat, 9 Aug 2003 23:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lgzB-0004XD-00 for sip@ietf.org; Sat, 09 Aug 2003 23:35:13 -0400 Received: from [202.96.122.72] (helo=mailout.ecc.eastcom.ptic) by ietf-mx with esmtp (Exim 4.12) id 19lgz6-0004Wu-00 for sip@ietf.org; Sat, 09 Aug 2003 23:35:08 -0400 Received: from zfzhao ([10.8.18.89]) by mailout.ecc.eastcom.ptic with Microsoft SMTPSVC(5.0.2195.5329); Sun, 10 Aug 2003 11:34:23 +0800 Message-ID: <015501c35ef0$120a4210$5912080a@rd.eastcom> From: "Jeff zhao" To: Date: Sun, 10 Aug 2003 11:32:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01C35F33.201A6F40" 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 X-OriginalArrivalTime: 10 Aug 2003 03:34:23.0180 (UTC) FILETIME=[4A8380C0:01C35EF0] Subject: [Sip] NAPTR look up in RFC 3262 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_0152_01C35F33.201A6F40 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: base64 SGk6DQogICBJbiBzZWN0aW9uIDggb2YgUkZDIDMyNjIsIHRoZSAiRmlyc3QgV2VsbCBLbm93biBS dWxlIiBleHRyYWN0cyB0aGUgImhvc3QiIHBvcnRpb24gb2YgdGhlIFNJUCBvciBTSVBTIFVSSS4g VGhlIGtleSB0aGVuIGlzIHRvIGJlIHVzZWQgdG8gbG9vayB1cCB0aGUgRE5TLg0KDQogICBCdXQg dG8gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxkIHVzZSB0aGUgIkRvbWFpbiIgbmFtZSB0byBsb29rIHVw IEROUyBmb3IgaXQncyBOQVBUUiBSUi4NCldoZW4gd2UgdXNlIHRoZSAiaG9zdCIgcG9ydGlvbiBv ZiBhIFVSSSB0byBsb29rIHVwIEROUywgaG93IGNhbiB3ZSBnZXQgdGhlIE5BUFRSIFJSPw0KDQoN CiAgIFdvdWxkIHNvbWVvbmUgcGxlYXN0IHRlbGwgbWUgIndoYXQiIHRoZSByZXNvbHZlciB1c2Ug dG8gbG9vayB1cCBETlMgZm9yIE5BUFRSIFJSLg0KDQpKZWZm ------=_NextPart_000_0152_01C35F33.201A6F40 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj4NCjxESVY+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7IEluIHNlY3Rpb24gOCBvZiBS RkMgMzI2MiwgdGhlICJGaXJzdCBXZWxsIA0KS25vd24gUnVsZSIgZXh0cmFjdHMgdGhlICJob3N0 IiBwb3J0aW9uIG9mIHRoZSBTSVAgb3IgU0lQUyBVUkkuIFRoZSBrZXkgdGhlbiBpcyANCnRvIGJl IHVzZWQgdG8gbG9vayB1cCB0aGUgRE5TLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7IEJ1dCB0byBteSBvcGluaW9u LCB3ZSBzaG91bGQgdXNlIHRoZSANCiJEb21haW4iIG5hbWUgdG8gbG9vayB1cCBETlMgZm9yIGl0 J3MgTkFQVFIgUlIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPldoZW4gd2UgdXNlIHRoZSAiaG9zdCIgcG9ydGlvbiBvZiBhIFVSSSB0byBsb29r IHVwIA0KRE5TLCBob3cgY2FuIHdlIGdldCB0aGUgTkFQVFIgUlI/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7 IFdvdWxkIHNvbWVvbmUgcGxlYXN0IHRlbGwgbWUgIndoYXQiIHRoZSANCnJlc29sdmVyIHVzZSZu YnNwO3RvIGxvb2sgdXAgRE5TIGZvciBOQVBUUiBSUi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkplZmY8L0ZPTlQ+PC9ESVY+PC9CT0RZ PjwvSFRNTD4NCg== ------=_NextPart_000_0152_01C35F33.201A6F40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 10 00:50: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 AAA15957 for ; Sun, 10 Aug 2003 00:50: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 19li9k-00045o-9s for sip-archive@odin.ietf.org; Sun, 10 Aug 2003 00:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A4oCJF015727 for sip-archive@odin.ietf.org; Sun, 10 Aug 2003 00:50:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19li9a-00044n-Ev; Sun, 10 Aug 2003 00:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19li8d-000441-Be for sip@optimus.ietf.org; Sun, 10 Aug 2003 00:49: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 AAA15921 for ; Sun, 10 Aug 2003 00:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19li8a-0004zX-00 for sip@ietf.org; Sun, 10 Aug 2003 00:49:00 -0400 Received: from [202.96.122.72] (helo=mailout.ecc.eastcom.ptic) by ietf-mx with esmtp (Exim 4.12) id 19li8Z-0004zT-00 for sip@ietf.org; Sun, 10 Aug 2003 00:49:00 -0400 Received: from zfzhao ([10.8.18.89]) by mailout.ecc.eastcom.ptic with Microsoft SMTPSVC(5.0.2195.5329); Sun, 10 Aug 2003 12:48:22 +0800 Message-ID: <016601c35efa$68730830$5912080a@rd.eastcom> From: "Jeff zhao" To: Date: Sun, 10 Aug 2003 12:46:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0163_01C35F3D.76833560" 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 X-OriginalArrivalTime: 10 Aug 2003 04:48:22.0816 (UTC) FILETIME=[A0BE3200:01C35EFA] Subject: [Sip] NAPTR look up in RFC 3263 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_0163_01C35F3D.76833560 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: base64 SGk6DQogICBJbiBzZWN0aW9uIDggb2YgUkZDIDMyNjMsIHRoZSAiRmlyc3QgV2VsbCBLbm93biBS dWxlIiBleHRyYWN0cyB0aGUgImhvc3QiIHBvcnRpb24gb2YgdGhlIFNJUCBvciBTSVBTIFVSSS4g VGhlIGtleSB0aGVuIGlzIHRvIGJlIHVzZWQgdG8gbG9vayB1cCB0aGUgRE5TLg0KDQogICBCdXQg dG8gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxkIHVzZSB0aGUgIkRvbWFpbiIgbmFtZSB0byBsb29rIHVw IEROUyBmb3IgaXQncyBOQVBUUiBSUi4NCldoZW4gd2UgdXNlIHRoZSAiaG9zdCIgcG9ydGlvbiBv ZiBhIFVSSSB0byBsb29rIHVwIEROUywgaG93IGNhbiB3ZSBnZXQgdGhlIE5BUFRSIFJSPw0KDQoN CiAgIFdvdWxkIHNvbWVvbmUgcGxlYXN0IHRlbGwgbWUgIndoYXQiIHRoZSByZXNvbHZlciB1c2Ug dG8gbG9vayB1cCBETlMgZm9yIE5BUFRSIFJSLg0KDQpKZWZm ------=_NextPart_000_0163_01C35F3D.76833560 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmYgYmFja2dyb3VuZD0iIj4NCjxESVY+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7IEluIHNlY3Rpb24gOCBvZiBS RkMgMzI2MywgdGhlICJGaXJzdCBXZWxsIA0KS25vd24gUnVsZSIgZXh0cmFjdHMgdGhlICJob3N0 IiBwb3J0aW9uIG9mIHRoZSBTSVAgb3IgU0lQUyBVUkkuIFRoZSBrZXkgdGhlbiBpcyANCnRvIGJl IHVzZWQgdG8gbG9vayB1cCB0aGUgRE5TLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7IEJ1dCB0byBteSBvcGluaW9u LCB3ZSBzaG91bGQgdXNlIHRoZSANCiJEb21haW4iIG5hbWUgdG8gbG9vayB1cCBETlMgZm9yIGl0 J3MgTkFQVFIgUlIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPldoZW4gd2UgdXNlIHRoZSAiaG9zdCIgcG9ydGlvbiBvZiBhIFVSSSB0byBsb29r IHVwIA0KRE5TLCBob3cgY2FuIHdlIGdldCB0aGUgTkFQVFIgUlI/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7 IFdvdWxkIHNvbWVvbmUgcGxlYXN0IHRlbGwgbWUgIndoYXQiIHRoZSANCnJlc29sdmVyIHVzZSZu YnNwO3RvIGxvb2sgdXAgRE5TIGZvciBOQVBUUiBSUi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkplZmY8L0ZPTlQ+PC9ESVY+PC9CT0RZ PjwvSFRNTD4NCg== ------=_NextPart_000_0163_01C35F3D.76833560-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 10 14:04: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 OAA12150 for ; Sun, 10 Aug 2003 14:04: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 19luYH-0001eX-9q for sip-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI4L4S006331 for sip-archive@odin.ietf.org; Sun, 10 Aug 2003 14: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 19luXy-0001N7-1d; Sun, 10 Aug 2003 14:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX7-0001MA-IS for sip@optimus.ietf.org; Sun, 10 Aug 2003 14:03: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 OAA11973 for ; Sun, 10 Aug 2003 14:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX5-0000i3-00 for sip@ietf.org; Sun, 10 Aug 2003 14:03:07 -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 19luX4-0000hm-00 for sip@ietf.org; Sun, 10 Aug 2003 14:03:06 -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 h7AI2XuI022614; Sun, 10 Aug 2003 11:02:35 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47199; Sun, 10 Aug 2003 11:02:32 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 10:46:18 -0700 Subject: Re: [Sip] WGLC summary : Referred-by From: Cullen Jennings To: Robert Sparks , Message-ID: In-Reply-To: <1060190072.932.47.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 Little nit that could be dealt with in Auth 48 Would you consider changing "Content-Transfer-Encoding: base64" to binary. Cullen On 8/6/03 10:14, "Robert Sparks" wrote: > I've revised Referred-By based on the comments received > during WGLC. > > I incorporated all of Mary's suggestions except for reducing the > strength of rejecting requests with invalid tokens from MUST to SHOULD. > She and I were the only people to comment on the issue, so I left it > the way it it had been. > > The updated draft can be retrieved from > http://www.nostrum.com/~rjsparks/draft-ietf-sip-referredby-03.txt > until it appears in the repository. > > I believe this is ready to send to the IESG. > > 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 Mon Aug 11 10:37: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 KAA18570 for ; Mon, 11 Aug 2003 10:37: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 19mDnd-0005iV-FW for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 10:37:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BEbTp6021958 for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 10:37:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDnC-0005al-JF; Mon, 11 Aug 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 19mDmg-0005Zl-Tn for sip@optimus.ietf.org; Mon, 11 Aug 2003 10:36: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 KAA18543 for ; Mon, 11 Aug 2003 10:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDme-0006Ip-00 for sip@ietf.org; Mon, 11 Aug 2003 10:36:28 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19mDmd-0006Im-00 for sip@ietf.org; Mon, 11 Aug 2003 10:36:27 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h7BEZxkK084898; Mon, 11 Aug 2003 10:36:10 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] SIP SUBSCRIBE question Date: Mon, 11 Aug 2003 10:41:50 -0400 Message-ID: <000001c36016$b3b81ac0$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) In-Reply-To: <796456A0F96AD511A0AC009027B0F74110FF97ED@IL27EXM08.cig.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > What is the expected behavior of Notifier if it > receives a SUBSCRIBE message from a UAC in the > following scenario > > - The SUBSCRIBE is sent with a new Call-ID when > there is already an existing dialog associated > with the same UAC and for the same Event Package > > Should the Notifier overwrite the new subscription > with the existing subscription (update the expire > interval) or not? From a protocol perspective, it has no relation to the prior subscription. They are separate subscriptions. From an event perspective, the notifier could decide to audit, terminate, or continue the prior subscription. If it audits the prior subscription, it would send a notify with the current state information and time remaining before expiration. The subscriber should return a 481 if the subscription/dialog no longer exists. If the notifier terminates the prior subscription, a notify should be sent. This might lead to another new subscribe if the subscriber really wanted two subscription. Such activity might lead to a continual new subscription process if the subscriber wants two subscriptions and the notifier does not allow it. If it continues the prior subscription, the notifier would continue to send notifies when needed. The subscriber will return a 481 if they are not wanted. If nothing triggers the notify and the subscriber does not refresh the subscription, it will expire naturally. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 11 11:59: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 LAA21038 for ; Mon, 11 Aug 2003 11:59: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 19mF4p-0000VS-7i for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 11:59:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFxJmk001940 for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 11: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 19mF4Y-0000Ul-Lw; Mon, 11 Aug 2003 11: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 19l8mk-0000ct-0c for sip@optimus.ietf.org; Fri, 08 Aug 2003 11:04: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 LAA14418 for ; Fri, 8 Aug 2003 11:03:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8mh-0001Mw-00 for sip@ietf.org; Fri, 08 Aug 2003 11:04:03 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 19l8mg-0001Mb-00 for sip@ietf.org; Fri, 08 Aug 2003 11:04:02 -0400 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l8mC-0002yE-Kk; Fri, 08 Aug 2003 17:03:32 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 8 Aug 2003 17:03:32 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l7mj-00066t-Kw; Fri, 08 Aug 2003 16:00:01 +0200 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h78E01C10291 for ; Fri, 8 Aug 2003 16:00:01 +0200 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 19l7mj-0003dJ-00 for ; Fri, 08 Aug 2003 16:00:01 +0200 To: sip@ietf.org Message-Id: From: Holger Karl Date: Fri, 08 Aug 2003 16:00:01 +0200 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 08 Aug 2003 17:03:28 +0200 Subject: [Sip] Call for Papers: WiOpt'04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Note: The submission deadline is 5th of November, 2003. *************************************************** ******** CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 5, 2003. Notification of acceptance: Jan. 15, 2003. Camera ready copy: Feb. 15, 2003. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, A. Chockalingam, Jon Crowcroft, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ramesh Rao, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier Local Arrangements Co-Chair: Sven Oestring and Julian Chesterfield Publicity Chair: Holger Karl Sponsors: The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * Intel * Microsoft * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 11 21:26: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 VAA12978 for ; Mon, 11 Aug 2003 21:26:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNvl-0003sv-6j for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 21:26:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C1QXoe014920 for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 21:26:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNvH-0003rx-7E; Mon, 11 Aug 2003 21: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 19mNuh-0003rT-7u for sip@optimus.ietf.org; Mon, 11 Aug 2003 21:25: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 VAA12933 for ; Mon, 11 Aug 2003 21:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNue-0003cm-00 for sip@ietf.org; Mon, 11 Aug 2003 21:25:24 -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 19mNud-0003cJ-00 for sip@ietf.org; Mon, 11 Aug 2003 21:25:23 -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 h7C1OrDr005488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 11 Aug 2003 20:24:54 -0500 From: "Dean Willis" To: Date: Mon, 11 Aug 2003 20:24:52 -0500 Message-ID: <002001c36070$88088810$ee036e3f@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 revision to drafts database Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Well, round 2 of the wholesale revision to our drafts database is = complete. The new stuff is available from: http://www.softarmor.com/sipwg/=20 Just follow the "Drafts" links like always. As a consequence, the old URLs like http://www.softarmor.com/drafts/draft-homer-sip-beer-99.txt=20 won't work anymore. The new and improved equivalent (which will = eventually include SIPPING, XCON, SIMPLE, IPTEL, and everything else we host) would = be http://www.softarmor.com/wgdb/docs/draft-homer-sip-beer-99.txt Actually, the SIPPING drafts are already there too. I just don't have = the SIPPING page relinked to point at it yet. The next step is to revise the information on this page -- it's not all current yet. But the revisions should make it MUCH more maintainable, so = the situation is looking up, especially for your lovable-but-overworked = chairs . . . Thanks, -- 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 Aug 11 21: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 VAA13594 for ; Mon, 11 Aug 2003 21:51: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 19mOJf-0004oK-6R for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 21:51:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C1pFdq018477 for sip-archive@odin.ietf.org; Mon, 11 Aug 2003 21:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOJS-0004mE-Dq; Mon, 11 Aug 2003 21: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 19mOJG-0004lu-Je for sip@optimus.ietf.org; Mon, 11 Aug 2003 21:50: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 VAA13572 for ; Mon, 11 Aug 2003 21:50:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mOJD-0003mP-00 for sip@ietf.org; Mon, 11 Aug 2003 21:50:47 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19mOJD-0003mL-00 for sip@ietf.org; Mon, 11 Aug 2003 21:50:47 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJH00MJQGMIWN@firewall.wcom.com> for sip@ietf.org; Tue, 12 Aug 2003 01:39:54 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJH00401GMIHG@pmismtp04.wcomnet.com>; Tue, 12 Aug 2003 01:39:54 +0000 (GMT) Received: from hsinnreich2 ([166.50.96.248]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJH00MFSGMHQE@pmismtp04.wcomnet.com>; Tue, 12 Aug 2003 01:39:53 +0000 (GMT) Date: Mon, 11 Aug 2003 20:39:54 -0500 From: Henry Sinnreich Subject: RE: [Sip] More revision to drafts database In-reply-to: <002001c36070$88088810$ee036e3f@txdwillis> To: "'Dean Willis'" , sip@ietf.org Message-id: <0HJH00MFTGMHQE@pmismtp04.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNgcNJ19XatX2miRwuveasJ3cfAiwAAbLGw 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 Softarmor is a priceless database and we should thank Dean for the work. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Dean > Willis > Sent: Monday, August 11, 2003 8:25 PM > To: sip@ietf.org > Subject: [Sip] More revision to drafts database > > > Well, round 2 of the wholesale revision to our drafts database is complete. > > The new stuff is available from: > http://www.softarmor.com/sipwg/ > Just follow the "Drafts" links like always. > > As a consequence, the old URLs like > > http://www.softarmor.com/drafts/draft-homer-sip-beer-99.txt > > won't work anymore. The new and improved equivalent (which will eventually > include SIPPING, XCON, SIMPLE, IPTEL, and everything else we host) would > be > > http://www.softarmor.com/wgdb/docs/draft-homer-sip-beer-99.txt > > > Actually, the SIPPING drafts are already there too. I just don't have the > SIPPING page relinked to point at it yet. > > The next step is to revise the information on this page -- it's not all > current yet. But the revisions should make it MUCH more maintainable, so > the > situation is looking up, especially for your lovable-but-overworked > chairs . > . . > > > Thanks, > > -- > 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 Aug 12 00: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 AAA16195 for ; Tue, 12 Aug 2003 00:21: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 19mQej-0000ZU-Ln for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 00:21:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C4L95p002187 for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 00: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 19mQec-0000Yl-4t; Tue, 12 Aug 2003 00: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 19mQeR-0000YP-JO for sip@optimus.ietf.org; Tue, 12 Aug 2003 00:20: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 AAA16186; Tue, 12 Aug 2003 00:20:43 -0400 (EDT) From: lkumar@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQeN-0004M0-00; Tue, 12 Aug 2003 00:20:47 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19mQeM-0004Lx-00; Tue, 12 Aug 2003 00:20:46 -0400 Received: from pragati.hss.hns.com (pragati.hss.hns.com [139.85.249.33]) by hss.hns.com (8.11.6/8.11.2) with ESMTP id h7C4KYw00927; Tue, 12 Aug 2003 09:50:37 +0530 In-Reply-To: <016601c35efa$68730830$5912080a@rd.eastcom> Subject: Re: [Sip] NAPTR look up in RFC 3263 To: "Jeff zhao" Cc: sip@ietf.org, sip-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: Date: Tue, 12 Aug 2003 09:42:36 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.0.2CF1|June 9, 2003) at 08/12/2003 09:43:00 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: , Hi Jeff, The "host" part of URI can be a domain(e.g. example.com), or a host(host1.example.com) or a numeric IP. If the "host" part is a domain NAPTR lookup will succeed and you will proceed as specified in the rfc. Otherwise, NAPTR lookup will fail (and so does SRV lookup) and the host will be resolved using A / AAAA record lookup. Hope this clarifies. Regds, Lalith sip-admin@ietf.org wrote on 08/10/2003 10:16:48 AM: > Hi: > In section 8 of RFC 3263, the "First Well Known Rule" extracts > the "host" portion of the SIP or SIPS URI. The key then is to be > used to look up the DNS. > > But to my opinion, we should use the "Domain" name to look up DNS > for it's NAPTR RR. > When we use the "host" portion of a URI to look up DNS, how can we > get the NAPTR RR? > > > Would someone pleast tell me "what" the resolver use to look up > DNS for NAPTR RR. > > Jeff _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 12 00:41: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 AAA16532 for ; Tue, 12 Aug 2003 00:41: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 19mQy8-0001H9-6l for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 00:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C4fCeF004879 for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 00:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQxx-0001GG-SN; Tue, 12 Aug 2003 00: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 19mQxE-0001Fc-Br for sip@optimus.ietf.org; Tue, 12 Aug 2003 00:40: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 AAA16504 for ; Tue, 12 Aug 2003 00:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQxB-0004QS-00 for sip@ietf.org; Tue, 12 Aug 2003 00:40: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 19mQxB-0004QP-00 for sip@ietf.org; Tue, 12 Aug 2003 00:40:13 -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 h7C4dVB30964; Mon, 11 Aug 2003 23:39:32 -0500 Subject: Re: [Sip] WGLC summary : Referred-by From: Robert Sparks To: Cullen Jennings Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1060663167.1870.0.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Aug 2003 23:39:28 -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 Ouch - I think you brought that up before, didn't you. IIRC, the group decided this was ok. I'll make that change unless somebody objects loudly. RjS On Sat, 2003-08-09 at 12:46, Cullen Jennings wrote: > Little nit that could be dealt with in Auth 48 > > Would you consider changing "Content-Transfer-Encoding: base64" to binary. > > Cullen > > > On 8/6/03 10:14, "Robert Sparks" wrote: > > > I've revised Referred-By based on the comments received > > during WGLC. > > > > I incorporated all of Mary's suggestions except for reducing the > > strength of rejecting requests with invalid tokens from MUST to SHOULD. > > She and I were the only people to comment on the issue, so I left it > > the way it it had been. > > > > The updated draft can be retrieved from > > http://www.nostrum.com/~rjsparks/draft-ietf-sip-referredby-03.txt > > until it appears in the repository. > > > > I believe this is ready to send to the IESG. > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 12 12:18: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 MAA20367 for ; Tue, 12 Aug 2003 12:18: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 19mbq4-0000tg-Js for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 12:17:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGHarm003444 for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 12:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mbpV-0000rx-B5; Tue, 12 Aug 2003 12: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 19mboi-0000qe-OS for sip@optimus.ietf.org; Tue, 12 Aug 2003 12:16: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 MAA20233 for ; Tue, 12 Aug 2003 12:16:07 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mboh-0001wz-00 for sip@ietf.org; Tue, 12 Aug 2003 12:16:11 -0400 Received: from imo-r06.mx.aol.com ([152.163.225.102]) by ietf-mx with esmtp (Exim 4.12) id 19mbof-0001ws-00 for sip@ietf.org; Tue, 12 Aug 2003 12:16:10 -0400 Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v36_r1.1.) id 7.1ec.ebf2c85 (18403); Tue, 12 Aug 2003 12:15:21 -0400 (EDT) Message-ID: <1ec.ebf2c85.2c6a6c99@aol.com> Date: Tue, 12 Aug 2003 12:15:21 EDT Subject: Re: [Sip] draft-ietf-resource-priority-01 draft To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1ec.ebf2c85.2c6a6c99_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_1ec.ebf2c85.2c6a6c99_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/9/2003 6:26:14 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > [MAP] > > > 2. Number of headers > > > > There is also a confusion about the number of R-P headers which may be > > included. While 4.5 correctly states that "The UAC MUST only include at > > most one Resource-Priority header field in the request.", Section 3 > > includes the statement that "There may be multiple resource values or, > > equivalently, multiple Resource-Priority header fields." (which is > > followed by the example of the US Wireless Priority System). It isn't > > clear how to interpret this example, since it refers to possible > > namespaces and priorities which aren't defined in this document. I > > suggest that these two paragraphs be deleted. Other text already > > indicates that an R-P header can contain multiple namespaces but not > > multiple values per namespace. > > [HGS] As per the previous discussion, multiple namespace.priority values are > permissible, obviously only with different namespaces. The contradictory > text was yanked. > Now I'm completely confused. The -01 draft, as I noted above, correctly stated in 4.5 that each request is limited to one R-P header (which may have multiple namespaces, each with one priority value specified). In the -02 version, you took out the correct statement that only one R-P header may be included in the request, and left in the confusing statement that I had pointed out. Mike Pierce --part1_1ec.ebf2c85.2c6a6c99_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 8/9/20= 03 6:26:14 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


[MAP] >=20
> 2. Number of headers
>=20
> There is also a confusion about the number of R-P headers which may= be=20
> included. While 4.5 correctly states that "The UAC MUST only includ= e at=20
> most one Resource-Priority header field in the request.", Section 3= =20
> includes the statement that "There may be multiple resource values=20= or,=20
> equivalently, multiple Resource-Priority header fields." (which is=20
> followed by the example of the US Wireless Priority System). It isn= 't=20
> clear how to interpret this example, since it refers to possible=20
> namespaces and priorities which aren't defined in this document. I=20
> suggest that these two paragraphs be deleted. Other text already=20
> indicates that an R-P header can contain multiple namespaces but no= t=20
> multiple values per namespace.

[HGS] As per the previous discussion, multiple namespace.priority values= are=20
permissible, obviously only with different namespaces. The contradictory= =20
text was yanked.

Now I'm completely confused. The -01 draft, as I noted above= , correctly stated in 4.5 that each request is limited to one R-P header (wh= ich may have multiple namespaces, each with one priority value specified).

In the -02 version, you took out the correct statement that only one R-P= header may be included in the request, and left in the confusing statement=20= that I had pointed out.

Mike Pierce


--part1_1ec.ebf2c85.2c6a6c99_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 12 12: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 MAA20545 for ; Tue, 12 Aug 2003 12:22: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 19mbuT-0001HC-PJ for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 12:22:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGM9a0004866 for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 12:22:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mbuL-0001CQ-JM; Tue, 12 Aug 2003 12:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mbts-0001Bo-97 for sip@optimus.ietf.org; Tue, 12 Aug 2003 12:21: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 MAA20478 for ; Tue, 12 Aug 2003 12:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mbtp-000218-00 for sip@ietf.org; Tue, 12 Aug 2003 12:21:29 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19mbtn-000213-00 for sip@ietf.org; Tue, 12 Aug 2003 12:21:28 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7CGLOJm006678 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Aug 2003 12:21:25 -0400 (EDT) Message-ID: <3F391404.8000709@cs.columbia.edu> Date: Tue, 12 Aug 2003 12:21:24 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-resource-priority-01 draft References: <1ec.ebf2c85.2c6a6c99@aol.com> In-Reply-To: <1ec.ebf2c85.2c6a6c99@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 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 > Now I'm completely confused. The -01 draft, as I noted above, correctly > stated in 4.5 that each request is limited to one R-P header (which may > have multiple namespaces, each with one priority value specified). Standard SIP usage is that Header: A, B, C is exactly the same as Header: A Header: B Header: C (or obviously any other ordering). See Section 7.3 in RFC 3261. > > In the -02 version, you took out the correct statement that only one R-P > header may be included in the request, and left in the confusing > statement that I had pointed out. With that clarification, does the confusion remain? > > Mike Pierce > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 12 16:15: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 QAA28114 for ; Tue, 12 Aug 2003 16:15: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 19mfY3-00017a-Pe for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 16:15:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CKFF1J004286 for sip-archive@odin.ietf.org; Tue, 12 Aug 2003 16:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfXp-00016S-PJ; Tue, 12 Aug 2003 16:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfXF-00015X-KP for sip@optimus.ietf.org; Tue, 12 Aug 2003 16:14: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 QAA28076 for ; Tue, 12 Aug 2003 16:14:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfXE-0003jG-00 for sip@ietf.org; Tue, 12 Aug 2003 16:14:24 -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 19mfXD-0003jC-00 for sip@ietf.org; Tue, 12 Aug 2003 16:14:23 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7CKDqDq012515; Tue, 12 Aug 2003 15:13:53 -0500 Subject: RE: [Sip] More revision to drafts database From: Dean Willis To: Henry Sinnreich Cc: sip@ietf.org In-Reply-To: <0HJH00MFTGMHQE@pmismtp04.wcomnet.com> References: <0HJH00MFTGMHQE@pmismtp04.wcomnet.com> Content-Type: text/plain Message-Id: <1060719232.10296.40.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 12 Aug 2003 15:13:52 -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-08-11 at 20:39, Henry Sinnreich wrote: > Softarmor is a priceless database and we should thank Dean for the work. > Thanks, Henry. -- 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 Wed Aug 13 11:48: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 LAA23892 for ; Wed, 13 Aug 2003 11:48: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 19mxrI-0004xh-2R for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 11:48:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DFmKcn019069 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 11:48:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxr0-0004wK-Ei; Wed, 13 Aug 2003 11: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 19mxqr-0004vd-En for sip@optimus.ietf.org; Wed, 13 Aug 2003 11:47: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 LAA23871 for ; Wed, 13 Aug 2003 11:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxqq-0002aG-00 for sip@ietf.org; Wed, 13 Aug 2003 11:47:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mxqp-0002ZO-00 for sip@ietf.org; Wed, 13 Aug 2003 11:47:51 -0400 Received: from dynamicsoft.com ([63.113.46.80]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DFlG3m003741; Wed, 13 Aug 2003 11:47:20 -0400 (EDT) Message-ID: <3F3A5739.40702@dynamicsoft.com> Date: Wed, 13 Aug 2003 11:20:25 -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: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question References: <000001c36016$b3b81ac0$2b01a8c0@broadsoft.com> In-Reply-To: <000001c36016$b3b81ac0$2b01a8c0@broadsoft.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 Brett Tate wrote: > >>From a protocol perspective, it has no relation to > the prior subscription. They are separate subscriptions. >>From an event perspective, the notifier could decide > to audit, terminate, or continue the prior subscription. There is no reason for it to change the existing subscription in any way. Doing so, just because of the arrival of the new subscription, is likely to lead to interop problems, some of which you point out below. The two subscriptions are totally separate, period. -Jonathan R. > > If it audits the prior subscription, it would send > a notify with the current state information and > time remaining before expiration. The subscriber > should return a 481 if the subscription/dialog no > longer exists. > > If the notifier terminates the prior subscription, a > notify should be sent. This might lead to another new > subscribe if the subscriber really wanted two subscription. > Such activity might lead to a continual new subscription > process if the subscriber wants two subscriptions and the > notifier does not allow it. > > If it continues the prior subscription, the notifier > would continue to send notifies when needed. The > subscriber will return a 481 if they are not wanted. > If nothing triggers the notify and the subscriber does > not refresh the subscription, it will expire naturally. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Wed Aug 13 12:32: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 MAA25217 for ; Wed, 13 Aug 2003 12:32: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 19myXm-0007gG-BF for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 12:32:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGWEqJ029520 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 12:32:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myXb-0007fj-58; Wed, 13 Aug 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 19myXK-0007fC-NR for sip@optimus.ietf.org; Wed, 13 Aug 2003 12:31: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 MAA25199 for ; Wed, 13 Aug 2003 12:31:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myXJ-00030Z-00 for sip@ietf.org; Wed, 13 Aug 2003 12:31:45 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19myXI-00030V-00 for sip@ietf.org; Wed, 13 Aug 2003 12:31:44 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h7DGVcMN055437; Wed, 13 Aug 2003 12:31:38 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] SIP SUBSCRIBE question Date: Wed, 13 Aug 2003 12:37:41 -0400 Message-ID: <001001c361b9$37f80130$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: <3F3A5739.40702@dynamicsoft.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 > >>From a protocol perspective, it has no relation to > > the prior subscription. They are separate subscriptions. > >>From an event perspective, the notifier could decide > > to audit, terminate, or continue the prior subscription. > > There is no reason for it to change the existing > subscription in any way. Doing so, just because of > the arrival of the new subscription, is likely to > lead to interop problems, some of which you point > out below. The two subscriptions are totally separate, > period. Unfortunately situations occur where a notifier will only allow a limited number of subscriptions from user for a user for the same event. Rejecting the new subscribe without also auditing the old subscription is likely going to lead to a loss of that service until an old subscription is removed (expires or 481). For example, a phone subscribes to message-summary. The phone restarts and loses its old message-summary subscription. It sends a new subscription for message-summary. If the notifier does not intend to allow an infinite number of message-summary subscriptions from the same user for the same user, the subscribes would start being reject once a threshold is reached. This would lead to a loss of message-summary service until a related subscription expires or triggers an update and until the phone retries a new message-summary subscription again. > > > > If it audits the prior subscription, it would send > > a notify with the current state information and > > time remaining before expiration. The subscriber > > should return a 481 if the subscription/dialog no > > longer exists. > > > > If the notifier terminates the prior subscription, a > > notify should be sent. This might lead to another new > > subscribe if the subscriber really wanted two subscription. > > Such activity might lead to a continual new subscription > > process if the subscriber wants two subscriptions and the > > notifier does not allow it. > > > > If it continues the prior subscription, the notifier > > would continue to send notifies when needed. The > > subscriber will return a 481 if they are not wanted. > > If nothing triggers the notify and the subscriber does > > not refresh the subscription, it will expire naturally. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 13 13:54: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 NAA27789 for ; Wed, 13 Aug 2003 13:54: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 19mzp7-0003ZB-DP for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 13:54:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHsD5q013703 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 13:54:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzow-0003YS-1l; Wed, 13 Aug 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 19mzol-0003Y9-La for sip@optimus.ietf.org; Wed, 13 Aug 2003 13:53: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 NAA27752 for ; Wed, 13 Aug 2003 13:53:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzoj-0003YB-00 for sip@ietf.org; Wed, 13 Aug 2003 13:53:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mzoi-0003Xy-00 for sip@ietf.org; Wed, 13 Aug 2003 13:53:48 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DHrI3m003779; Wed, 13 Aug 2003 13:53:18 -0400 (EDT) Message-ID: <3F3A7B0B.1070508@dynamicsoft.com> Date: Wed, 13 Aug 2003 13:53:15 -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: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question References: <001001c361b9$37f80130$2b01a8c0@broadsoft.com> In-Reply-To: <001001c361b9$37f80130$2b01a8c0@broadsoft.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 Brett Tate wrote: >>>>From a protocol perspective, it has no relation to >>>the prior subscription. They are separate subscriptions. >>>>From an event perspective, the notifier could decide >>>to audit, terminate, or continue the prior subscription. >> >>There is no reason for it to change the existing >>subscription in any way. Doing so, just because of >>the arrival of the new subscription, is likely to >>lead to interop problems, some of which you point >>out below. The two subscriptions are totally separate, >>period. > > > Unfortunately situations occur where a notifier will > only allow a limited number of subscriptions from user > for a user for the same event. Rejecting the new > subscribe without also auditing the old subscription > is likely going to lead to a loss of that service > until an old subscription is removed (expires or 481). > > For example, a phone subscribes to message-summary. > The phone restarts and loses its old message-summary > subscription. It sends a new subscription for > message-summary. If the notifier does not intend > to allow an infinite number of message-summary > subscriptions from the same user for the same user, > the subscribes would start being reject once a threshold > is reached. There is really no need for this. The next NOTIFY to the old subscription will time out and therefore be removed automatically. -Jonathan R. -- 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 Wed Aug 13 14:13: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 OAA28506 for ; Wed, 13 Aug 2003 14:13: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 19n07T-000552-Lk for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DIDBCS019527 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:13:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n07J-00054J-Rn; Wed, 13 Aug 2003 14:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n06q-00053r-DW for sip@optimus.ietf.org; Wed, 13 Aug 2003 14:12: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 OAA28466 for ; Wed, 13 Aug 2003 14:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n06n-0003hi-00 for sip@ietf.org; Wed, 13 Aug 2003 14:12:29 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n06n-0003hK-00 for sip@ietf.org; Wed, 13 Aug 2003 14:12:29 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DIC23m003793 for ; Wed, 13 Aug 2003 14:12:02 -0400 (EDT) Message-ID: <3F3A7F6E.6030605@dynamicsoft.com> Date: Wed, 13 Aug 2003 14:11:58 -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: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Calle capabilities device ID: take 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, I posted a note on this about a month back, with no responses. This is a big remaining open issue in callee caps and we want to resolve it. So, please take a look and respond. One of the issues I raised today during the meeting was on the utility of the uri-user and uri-domain parameters in draft-ietf-sip-callee-caps. The primary purpose that these serve is a means of identifying a UA instance. In order to accomplish applicaitons like assisted call transfer, a UA would send INVITE to the AOR of the transfer target, and include an Accept-Contact with the uri-user and uri-domain equal to those of the UA instance. Now, it turns out that uri-user and uri-domain are not very helpful when used this way. GRUU is a better approach. However, thats almost a secondary issue. The primary issue is that uri-user and uri-domain are ugly, and they repeat information already in the registration. The suggestion, made by Paul, was to instead define a device-id attribute. This ID would be long lived - burned into firmware of a device, perhaps. It would be included in a registration as a unique ID for the device or software instance, as the case may be. You could use this callee capability attribute for the assisted transfer just as you could use uri-user and uri-domain. It has the same problems that still make GRUU a better solution. However, during the meeting, folks like the idea of a device-id attribute as something useful for lots of other applications. So, I would like to invite comment and discussion on (1) whether you like the idea of replacing the uri-user and uri-domain attributes with device-id (a better name may be needed, like instance-id), (2) what kind of usages you had in mind for it, for good or for evil. Thanks, Jonathan R. -- 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 Wed Aug 13 14:31: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 OAA29593 for ; Wed, 13 Aug 2003 14:31: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 19n0Ov-0006MA-7Y for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:31:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DIVDEa024428 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Ol-0006HZ-7g; Wed, 13 Aug 2003 14:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Oh-0006GW-3S for sip@optimus.ietf.org; Wed, 13 Aug 2003 14:30: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 OAA29554 for ; Wed, 13 Aug 2003 14:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Oe-0003vA-00 for sip@ietf.org; Wed, 13 Aug 2003 14:30:56 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19n0Od-0003v6-00 for sip@ietf.org; Wed, 13 Aug 2003 14:30:55 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7DIUslk003981 for ; Wed, 13 Aug 2003 11:30:54 -0700 (MST) Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h7DIUq2X019230 for ; Wed, 13 Aug 2003 13:30:52 -0500 Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 13 Aug 2003 13:30:52 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F74110FF9807@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: "'Jonathan Rosenberg'" , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] SIP SUBSCRIBE question Date: Wed, 13 Aug 2003 13:30:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 assumption here is that the timeout is relatively small. However if we were to set the SUBSCRIBE such that the subscription never expires - something like 2^32 - 1 - then the old subscription cannot be removed automatically. The UA would need to explicitly remove the subscription as Brett stated. Regards - Ajay -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 13, 2003 12:53 PM To: brett@broadsoft.com Cc: sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question Brett Tate wrote: >>>>From a protocol perspective, it has no relation to >>>the prior subscription. They are separate subscriptions. >>>>From an event perspective, the notifier could decide >>>to audit, terminate, or continue the prior subscription. >> >>There is no reason for it to change the existing >>subscription in any way. Doing so, just because of >>the arrival of the new subscription, is likely to >>lead to interop problems, some of which you point >>out below. The two subscriptions are totally separate, >>period. > > > Unfortunately situations occur where a notifier will > only allow a limited number of subscriptions from user > for a user for the same event. Rejecting the new > subscribe without also auditing the old subscription > is likely going to lead to a loss of that service > until an old subscription is removed (expires or 481). > > For example, a phone subscribes to message-summary. > The phone restarts and loses its old message-summary > subscription. It sends a new subscription for > message-summary. If the notifier does not intend > to allow an infinite number of message-summary > subscriptions from the same user for the same user, > the subscribes would start being reject once a threshold > is reached. There is really no need for this. The next NOTIFY to the old subscription will time out and therefore be removed automatically. -Jonathan R. -- 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 13 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 OAA00161 for ; Wed, 13 Aug 2003 14: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 19n0aT-0007TJ-SW for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DIh9fg028716 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0aM-0007Sj-1b; Wed, 13 Aug 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 19n0ZQ-0007M3-9f for sip@optimus.ietf.org; Wed, 13 Aug 2003 14:42: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 OAA29925 for ; Wed, 13 Aug 2003 14:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0ZN-0003zm-00 for sip@ietf.org; Wed, 13 Aug 2003 14:42:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n0ZM-0003zL-00 for sip@ietf.org; Wed, 13 Aug 2003 14:42:00 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DIfW3m003807; Wed, 13 Aug 2003 14:41:32 -0400 (EDT) Message-ID: <3F3A8659.9040800@dynamicsoft.com> Date: Wed, 13 Aug 2003 14:41:29 -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: Idnani Ajaykumar-AIDNANI1 CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question References: <796456A0F96AD511A0AC009027B0F74110FF9807@IL27EXM08.cig.mot.com> In-Reply-To: <796456A0F96AD511A0AC009027B0F74110FF9807@IL27EXM08.cig.mot.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 No, the subscription is removed once there is a notification. The NOTIFY will fail since the UA is no longer there, and thus the subscription removed. -Jonathan R. Idnani Ajaykumar-AIDNANI1 wrote: > I think the assumption here is that the timeout is relatively small. However if we were to set the SUBSCRIBE such that the subscription never expires - something like 2^32 - 1 - then the old subscription cannot be removed automatically. The UA would need to explicitly remove the subscription as Brett stated. > > Regards > - Ajay > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 13, 2003 12:53 PM > To: brett@broadsoft.com > Cc: sip@ietf.org > Subject: Re: [Sip] SIP SUBSCRIBE question > > > > Brett Tate wrote: > > >>>>>From a protocol perspective, it has no relation to >>>>the prior subscription. They are separate subscriptions. >>>>>From an event perspective, the notifier could decide >>>>to audit, terminate, or continue the prior subscription. >>> >>>There is no reason for it to change the existing >>>subscription in any way. Doing so, just because of >>>the arrival of the new subscription, is likely to >>>lead to interop problems, some of which you point >>>out below. The two subscriptions are totally separate, >>>period. >> >> >>Unfortunately situations occur where a notifier will >>only allow a limited number of subscriptions from user >>for a user for the same event. Rejecting the new >>subscribe without also auditing the old subscription >>is likely going to lead to a loss of that service >>until an old subscription is removed (expires or 481). >> >>For example, a phone subscribes to message-summary. >>The phone restarts and loses its old message-summary >>subscription. It sends a new subscription for >>message-summary. If the notifier does not intend >>to allow an infinite number of message-summary >>subscriptions from the same user for the same user, >>the subscribes would start being reject once a threshold >>is reached. > > > There is really no need for this. The next NOTIFY to the old > subscription will time out and therefore be removed automatically. > > -Jonathan R. -- 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 Wed Aug 13 14: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 OAA00713 for ; Wed, 13 Aug 2003 14: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 19n0l8-00085B-Q8 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DIsAfW031065 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 14: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 19n0l0-00084X-3m; Wed, 13 Aug 2003 14: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 19n0kk-000842-1i for sip@optimus.ietf.org; Wed, 13 Aug 2003 14:53: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 OAA00663 for ; Wed, 13 Aug 2003 14:53:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0kh-0004Bz-00 for sip@ietf.org; Wed, 13 Aug 2003 14:53:43 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19n0kg-0004Bw-00 for sip@ietf.org; Wed, 13 Aug 2003 14:53:42 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h7DIrg64008177 for ; Wed, 13 Aug 2003 11:53:42 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7DIrdBh009567 for ; Wed, 13 Aug 2003 13:53:39 -0500 Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 13 Aug 2003 13:53:40 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F74110FF9809@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: "'Jonathan Rosenberg'" , Idnani Ajaykumar-AIDNANI1 Cc: brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] SIP SUBSCRIBE question Date: Wed, 13 Aug 2003 13:53:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , May be there is something here that I am missing, so I would appreciate if you could help me understand. Why should the UA not be there? The UA has just restarted, it is still using the same Address-of-Record and the same Contact address. So I would assume the Notify will land on the UA. Is the UA supposed to ignore a NOTIFY that is not connected to any active dialog on the UA? Or is it supposed to respond back with an error response, if so what should be the error response, and what should be the behavior of the Notifier when it receives the error response. Thanks and Regards - Ajay -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 13, 2003 1:41 PM To: Idnani Ajaykumar-AIDNANI1 Cc: brett@broadsoft.com; sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question No, the subscription is removed once there is a notification. The NOTIFY will fail since the UA is no longer there, and thus the subscription removed. -Jonathan R. Idnani Ajaykumar-AIDNANI1 wrote: > I think the assumption here is that the timeout is relatively small. However if we were to set the SUBSCRIBE such that the subscription never expires - something like 2^32 - 1 - then the old subscription cannot be removed automatically. The UA would need to explicitly remove the subscription as Brett stated. > > Regards > - Ajay > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 13, 2003 12:53 PM > To: brett@broadsoft.com > Cc: sip@ietf.org > Subject: Re: [Sip] SIP SUBSCRIBE question > > > > Brett Tate wrote: > > >>>>>From a protocol perspective, it has no relation to >>>>the prior subscription. They are separate subscriptions. >>>>>From an event perspective, the notifier could decide >>>>to audit, terminate, or continue the prior subscription. >>> >>>There is no reason for it to change the existing >>>subscription in any way. Doing so, just because of >>>the arrival of the new subscription, is likely to >>>lead to interop problems, some of which you point >>>out below. The two subscriptions are totally separate, >>>period. >> >> >>Unfortunately situations occur where a notifier will >>only allow a limited number of subscriptions from user >>for a user for the same event. Rejecting the new >>subscribe without also auditing the old subscription >>is likely going to lead to a loss of that service >>until an old subscription is removed (expires or 481). >> >>For example, a phone subscribes to message-summary. >>The phone restarts and loses its old message-summary >>subscription. It sends a new subscription for >>message-summary. If the notifier does not intend >>to allow an infinite number of message-summary >>subscriptions from the same user for the same user, >>the subscribes would start being reject once a threshold >>is reached. > > > There is really no need for this. The next NOTIFY to the old > subscription will time out and therefore be removed automatically. > > -Jonathan R. -- 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 Wed Aug 13 15:12: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 PAA02096 for ; Wed, 13 Aug 2003 15:12: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 19n12Y-000189-8Z for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 15:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DJCAlp004333 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 15: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 19n12N-00016i-Mi; Wed, 13 Aug 2003 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n11z-00011a-OK for sip@optimus.ietf.org; Wed, 13 Aug 2003 15:11: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 PAA01973 for ; Wed, 13 Aug 2003 15:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n11w-0004Ln-00 for sip@ietf.org; Wed, 13 Aug 2003 15:11:32 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19n11v-0004Lk-00 for sip@ietf.org; Wed, 13 Aug 2003 15:11:31 -0400 Received: from [172.16.1.195] (helo=ccpu00170) by smtp.ccpu.com with smtp (Exim 4.20 #1 (Debian)) id 19n11r-00024q-2p; Wed, 13 Aug 2003 12:11:27 -0700 From: "Mingcheng Zhu" To: "Idnani Ajaykumar-AIDNANI1" Cc: Subject: RE: [Sip] SIP SUBSCRIBE question Date: Wed, 13 Aug 2003 12:15:13 -0700 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.2910.0) In-Reply-To: <796456A0F96AD511A0AC009027B0F74110FF9809@IL27EXM08.cig.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Hi, I think the to tag, from tag and callID will have no match at the UA side and this will trigger the deletion of subscription at Notifier side. Regards, Mingcheng -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Idnani Ajaykumar-AIDNANI1 Sent: Wednesday, August 13, 2003 11:54 AM To: 'Jonathan Rosenberg'; Idnani Ajaykumar-AIDNANI1 Cc: brett@broadsoft.com; sip@ietf.org Subject: RE: [Sip] SIP SUBSCRIBE question May be there is something here that I am missing, so I would appreciate if you could help me understand. Why should the UA not be there? The UA has just restarted, it is still using the same Address-of-Record and the same Contact address. So I would assume the Notify will land on the UA. Is the UA supposed to ignore a NOTIFY that is not connected to any active dialog on the UA? Or is it supposed to respond back with an error response, if so what should be the error response, and what should be the behavior of the Notifier when it receives the error response. Thanks and Regards - Ajay -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 13, 2003 1:41 PM To: Idnani Ajaykumar-AIDNANI1 Cc: brett@broadsoft.com; sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question No, the subscription is removed once there is a notification. The NOTIFY will fail since the UA is no longer there, and thus the subscription removed. -Jonathan R. Idnani Ajaykumar-AIDNANI1 wrote: > I think the assumption here is that the timeout is relatively small. However if we were to set the SUBSCRIBE such that the subscription never expires - something like 2^32 - 1 - then the old subscription cannot be removed automatically. The UA would need to explicitly remove the subscription as Brett stated. > > Regards > - Ajay > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 13, 2003 12:53 PM > To: brett@broadsoft.com > Cc: sip@ietf.org > Subject: Re: [Sip] SIP SUBSCRIBE question > > > > Brett Tate wrote: > > >>>>>From a protocol perspective, it has no relation to >>>>the prior subscription. They are separate subscriptions. >>>>>From an event perspective, the notifier could decide >>>>to audit, terminate, or continue the prior subscription. >>> >>>There is no reason for it to change the existing >>>subscription in any way. Doing so, just because of >>>the arrival of the new subscription, is likely to >>>lead to interop problems, some of which you point >>>out below. The two subscriptions are totally separate, >>>period. >> >> >>Unfortunately situations occur where a notifier will >>only allow a limited number of subscriptions from user >>for a user for the same event. Rejecting the new >>subscribe without also auditing the old subscription >>is likely going to lead to a loss of that service >>until an old subscription is removed (expires or 481). >> >>For example, a phone subscribes to message-summary. >>The phone restarts and loses its old message-summary >>subscription. It sends a new subscription for >>message-summary. If the notifier does not intend >>to allow an infinite number of message-summary >>subscriptions from the same user for the same user, >>the subscribes would start being reject once a threshold >>is reached. > > > There is really no need for this. The next NOTIFY to the old > subscription will time out and therefore be removed automatically. > > -Jonathan R. -- 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 13 15: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 PAA02807 for ; Wed, 13 Aug 2003 15: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 19n1D7-0001nm-Cl for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 15:23:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DJN5ji006916 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 15:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1D3-0001n2-Qs; Wed, 13 Aug 2003 15: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 19n1Cd-0001mg-HQ for sip@optimus.ietf.org; Wed, 13 Aug 2003 15:22: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 PAA02756 for ; Wed, 13 Aug 2003 15:22:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1Cc-0004Qw-00 for sip@ietf.org; Wed, 13 Aug 2003 15:22:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n1Ca-0004Qs-00 for sip@ietf.org; Wed, 13 Aug 2003 15:22:33 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DJLu3m003830; Wed, 13 Aug 2003 15:21:58 -0400 (EDT) Message-ID: <3F3A8FCC.7010301@dynamicsoft.com> Date: Wed, 13 Aug 2003 15:21:48 -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: Idnani Ajaykumar-AIDNANI1 CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] SIP SUBSCRIBE question References: <796456A0F96AD511A0AC009027B0F74110FF9809@IL27EXM08.cig.mot.com> In-Reply-To: <796456A0F96AD511A0AC009027B0F74110FF9809@IL27EXM08.cig.mot.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 Idnani Ajaykumar-AIDNANI1 wrote: > May be there is something here that I am missing, so I would > appreciate if you could help me understand. Why should the UA not > be there? The UA has just restarted, it is still using the same > Address-of-Record and the same Contact address. So I would assume > the Notify will land on the UA. Is the UA supposed to ignore a > NOTIFY that is not connected to any active dialog on the UA? No, but the dialog identifiers don't match an existing subscription. So, the UAS generates a 481, and this causes the server to terminate the subscription. -Jonathan R. -- 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 Wed Aug 13 17:58: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 RAA07891 for ; Wed, 13 Aug 2003 17:58: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 19n3d9-0003hH-Da for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 17:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLw7Yg014205 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 17:58:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3d4-0003gh-BE; Wed, 13 Aug 2003 17: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 19n3cm-0003gJ-BH for sip@optimus.ietf.org; Wed, 13 Aug 2003 17:57: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 RAA07864 for ; Wed, 13 Aug 2003 17:57:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3cj-0005ZC-00 for sip@ietf.org; Wed, 13 Aug 2003 17:57:41 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19n3ci-0005Z3-00 for sip@ietf.org; Wed, 13 Aug 2003 17:57:41 -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 h7DLv3pp016300; Wed, 13 Aug 2003 14:57: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 AKI44562; Wed, 13 Aug 2003 14:49:57 -0700 (PDT) Date: Wed, 13 Aug 2003 14:59:49 -0700 Subject: Re: [Sip] Changes in caller prefs -09 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org, Ted Hardie To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F0A6F93.5000305@dynamicsoft.com> Message-Id: <75D0F1B8-CDD9-11D7-91B8-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, I already privately replied to Jonathan about this and spoke up at the meeting, but since there has been a significant lack of discussion... If you feel Jonathan's proposal is reasonable, please send him a private ping. If not, please raise your issues. On Tuesday, July 8, 2003, at 12:15 AM, Jonathan Rosenberg wrote: > Folks, > > You may have noticed that caller prefs -09 was posted: > > http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.txt > http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.html > http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-09.txt > > This document is substantially different from -08. > > First, the capabilities stuff has been yanked into a separate I-D > (http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps- > 00.txt). That includes REGISTER and OPTIONS processing, and all of the > media feature tag definitions and registrations. > > The reason for the split, as I indicated in another note, was that we > believed there were going to continue to be problems with the caller > preferences piece of callerprefs (i.e., the Accept-Contact and > Reject-Contact header fields). A big issue we encountered with -08 > based on excellent input from Ted Hardie, was that q-value arithmetic > is a no-no. Q-values as defined are ordinal, and you can't perform > arithmetic on them, or compare them between different sources. We had > been doing a lot of that in -08. > > So, in -09, the algorithm has changed. THe proxy computes the score > for each Accept-Contact rule against each Contact, as before. The > overall caller preference for a contact is then computed as the > average of the scores across all Accept-Contacts for that contact. > Previously, we had a really complex function instead of arithmetic > average. The reason had a lot to do with quirks that arise when you > try to do q-value arithmetic. Anyway, once the average (the caller > preference) is computed, it is used in a specific way. For those > contacts with EQUAL Q-VALUES AS SET BY THE CALLEE, the caller > preference is used to order them. We never combine the caller and > callee preferences; we merely use the caller preference to provide an > order when the callee provides none. > > This algorithm is a lot simpler, and it never tries to do arithmetic > on q-values. However, there is some loss of functionality. I tested > the algorithm on all of the use cases, and found that a few failed. > For example, Section 3.5 of > http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases- > 00.txt describes a case. There, the caller wants the call to go to a > videophone, but will take an audio-only device as a second choice. The > callee prefers the audio-only phone. Because the caller preferences > can't ever reorder callee contacts with differing q-values, there is > no way to "override" the callee preference for the audio phone, and > still fall back to it in the case where the videophone doesnt work or > can't be reached. > Section 3.12 describes a similar case, where a user wants to go right > to voicemail, but will take a call with the user if there is no > voicemail. We can't do that anymore. I'm not losing any sleep over this use case, as the user can still do this in two-steps (use Reject-Contact first, get back a 404 response and then retry). Simple things should be easy. More complicated things can be harder. thanks, -rohan > I welcome comments on whether this loss of functionality is > substantial enough that we need to investigate ways of getting it > back. I personally would prefer to just declare victory with what > works and move on. > > Some of the other changes: > > * elimination of the q-values in the Accept-Contact; they were never > needed in any of the use cases, so I removed them > > * Clarification on the purpose of Proxy-Require, based on comments by > Mary and others during wglc. > > * A lot more discussion on how to set the require and explicit > parameters. These can be confusing, and its hard to tell which of them > you need. > > * when a proxy is redirecting, it sets the q-values for the contacts > to anything which orders them based on the results of the above > algorithm > > > Comments and questions welcome. > > Thanks, > Jonathan R. > -- > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 14 01:41:56 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 BAA17837 for ; Thu, 14 Aug 2003 01:41: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 19nArZ-0006l8-8j for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 01:41:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E5fTk3025983 for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 01:41:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nAr8-0006kS-4Q; Thu, 14 Aug 2003 01:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nAqD-0006jQ-SB for sip@optimus.ietf.org; Thu, 14 Aug 2003 01:40: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 BAA17792 for ; Thu, 14 Aug 2003 01:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nAqA-0007bV-00 for sip@ietf.org; Thu, 14 Aug 2003 01:40:02 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19nAq9-0007bH-00 for sip@ietf.org; Thu, 14 Aug 2003 01:40:02 -0400 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 h7E5dIpp007860; Wed, 13 Aug 2003 22:39:19 -0700 (PDT) Date: Thu, 14 Aug 2003 01:39:16 -0400 From: "David R. Oran" To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Calle capabilities device ID: take 2 Message-ID: <152599984.1060825156@[10.32.254.186]> In-Reply-To: <3F3A7F6E.6030605@dynamicsoft.com> References: <3F3A7F6E.6030605@dynamicsoft.com> X-Mailer: Mulberry/3.0.3 (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 As I indicated at the WG meeting in Vienna, I have a fairly strong preference for pitching the current scheme in favor of having a "Device-id" or "instance-id" parameter. I have no strong preference as to the exact name, but tend to agree with Jonathan that "instance-id" is more neutral than "device-id" and less likely to be over-interpreted by implementers. I'll comment later on the exact uses I have in mind, since that requires quite a bit more effort and it's 2AM here. Dave. --On Wednesday, August 13, 2003 2:11 PM -0400 Jonathan Rosenberg wrote: > Folks, > > I posted a note on this about a month back, with no responses. This is a > big remaining open issue in callee caps and we want to resolve it. So, > please take a look and respond. > > One of the issues I raised today during the meeting was on the utility of > the uri-user and uri-domain parameters in draft-ietf-sip-callee-caps. The > primary purpose that these serve is a means of identifying a UA instance. > In order to accomplish applicaitons like assisted call transfer, a UA > would send INVITE to the AOR of the transfer target, and include an > Accept-Contact with the uri-user and uri-domain equal to those of the UA > instance. > > Now, it turns out that uri-user and uri-domain are not very helpful when > used this way. GRUU is a better approach. However, thats almost a > secondary issue. > > The primary issue is that uri-user and uri-domain are ugly, and they > repeat information already in the registration. The suggestion, made by > Paul, was to instead define a device-id attribute. This ID would be long > lived - burned into firmware of a device, perhaps. It would be included > in a registration as a unique ID for the device or software instance, as > the case may be. > > You could use this callee capability attribute for the assisted transfer > just as you could use uri-user and uri-domain. It has the same problems > that still make GRUU a better solution. However, during the meeting, > folks like the idea of a device-id attribute as something useful for lots > of other applications. > > So, I would like to invite comment and discussion on (1) whether you like > the idea of replacing the uri-user and uri-domain attributes with > device-id (a better name may be needed, like instance-id), (2) what kind > of usages you had in mind for it, for good or for evil. > > Thanks, > Jonathan R. > -- > 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 ------------------------ 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 Aug 14 02:11: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 CAA29914 for ; Thu, 14 Aug 2003 02:11: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 19nBKH-0000Qg-Sf for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 02:11:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E6B9sq001649 for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 02:11:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nBKB-0000Ph-AJ; Thu, 14 Aug 2003 02: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 19nBK5-0000PA-V8 for sip@optimus.ietf.org; Thu, 14 Aug 2003 02:10: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 CAA29340 for ; Thu, 14 Aug 2003 02:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nBK2-0007mA-00 for sip@ietf.org; Thu, 14 Aug 2003 02:10:54 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19nBK1-0007m5-00 for sip@ietf.org; Thu, 14 Aug 2003 02:10:53 -0400 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 h7E6AGpp020107; Wed, 13 Aug 2003 23:10:17 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn1-238.cisco.com [10.21.96.238]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB92402; Wed, 13 Aug 2003 23:10:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 13 Aug 2003 23:10:11 -0700 Subject: Re: [Sip] Calle capabilities device ID: take 2 From: Cullen Jennings To: Jonathan Rosenberg , Message-ID: In-Reply-To: <3F3A7F6E.6030605@dynamicsoft.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 device-id is a useful idea but we do need to have a practical way to generate this instance-id for a softphone running on a PC behind a NAT. A sufficiently large random number seems like a possibility. It does have privacy concerns that make when and where it can be removed complicated. On 8/13/03 11:11 AM, "Jonathan Rosenberg" wrote: > Folks, > > I posted a note on this about a month back, with no responses. This is > a big remaining open issue in callee caps and we want to resolve it. > So, please take a look and respond. > > One of the issues I raised today during the meeting was on the utility > of the uri-user and uri-domain parameters in > draft-ietf-sip-callee-caps. The primary purpose that these serve is a > means of identifying a UA instance. In order to accomplish > applicaitons like assisted call transfer, a UA would send INVITE to > the AOR of the transfer target, and include an Accept-Contact with the > uri-user and uri-domain equal to those of the UA instance. > > Now, it turns out that uri-user and uri-domain are not very helpful > when used this way. GRUU is a better approach. However, thats almost a > secondary issue. > > The primary issue is that uri-user and uri-domain are ugly, and they > repeat information already in the registration. The suggestion, made > by Paul, was to instead define a device-id attribute. This ID would be > long lived - burned into firmware of a device, perhaps. It would be > included in a registration as a unique ID for the device or software > instance, as the case may be. > > You could use this callee capability attribute for the assisted > transfer just as you could use uri-user and uri-domain. It has the > same problems that still make GRUU a better solution. However, during > the meeting, folks like the idea of a device-id attribute as something > useful for lots of other applications. > > So, I would like to invite comment and discussion on (1) whether you > like the idea of replacing the uri-user and uri-domain attributes with > device-id (a better name may be needed, like instance-id), (2) what > kind of usages you had in mind for it, for good or for evil. > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 14 06:37: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 GAA05698 for ; Thu, 14 Aug 2003 06:37: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 19nFTm-00030m-7O for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 06:37:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAbEck011570 for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 06:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFTa-0002zm-Vf; Thu, 14 Aug 2003 06: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 19n1e5-0004G6-E8 for sip@optimus.ietf.org; Wed, 13 Aug 2003 15:50: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 PAA04078 for ; Wed, 13 Aug 2003 15:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1e3-0004fb-00 for sip@ietf.org; Wed, 13 Aug 2003 15:50:55 -0400 Received: from web11403.mail.yahoo.com ([216.136.131.233]) by ietf-mx with smtp (Exim 4.12) id 19n1e3-0004fY-00 for sip@ietf.org; Wed, 13 Aug 2003 15:50:55 -0400 Message-ID: <20030813195054.45108.qmail@web11403.mail.yahoo.com> Received: from [208.255.120.2] by web11403.mail.yahoo.com via HTTP; Wed, 13 Aug 2003 12:50:54 PDT Date: Wed, 13 Aug 2003 12:50:54 -0700 (PDT) From: v l To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] proxy stateless Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 have a question regarding stateless proxy processing. If a UA sends an ill defined INVITE (say with Max-forwards = 0) to a stateless proxy. The proxy sends a 483 Too Many Hops response back to the UA. Now the UA sends a good ACK for this to the stateless proxy with the Request URI which is the same as the INVITE. How does the stateless proxy know that this ACK is meant for the previous INVITE and should not be forwarded ahead? __________________________________ 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 Aug 14 11:16: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 LAA14600 for ; Thu, 14 Aug 2003 11:16: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 19nJpo-0007Qc-2H for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 11:16:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFGGD8028530 for sip-archive@odin.ietf.org; Thu, 14 Aug 2003 11: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 19nJpZ-0007Pi-Pr; Thu, 14 Aug 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJok-0007P1-Ve for sip@optimus.ietf.org; Thu, 14 Aug 2003 11:15: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 LAA14531 for ; Thu, 14 Aug 2003 11:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJok-0003J1-00 for sip@ietf.org; Thu, 14 Aug 2003 11:15:10 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19nJoj-0003IV-00 for sip@ietf.org; Thu, 14 Aug 2003 11:15:09 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7EFEZi18853; Thu, 14 Aug 2003 11:14:35 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYGY01B8; Thu, 14 Aug 2003 11:14:36 -0400 Received: from nortelnetworks.com (acart1dy.ca.nortel.com [47.129.129.107]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QZHATVQA; Thu, 14 Aug 2003 11:14:35 -0400 Message-ID: <3F3BA748.7000305@nortelnetworks.com> Date: Thu, 14 Aug 2003 11:14:16 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: v l CC: sip@ietf.org Subject: Re: [Sip] proxy stateless References: <20030813195054.45108.qmail@web11403.mail.yahoo.com> In-Reply-To: <20030813195054.45108.qmail@web11403.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 If this happens, I don't see that the stateless proxy has to recognize anything. It just forwards the ACK and lets the UAS deal with the protocol violation. v l wrote: > I have a question regarding stateless proxy > processing. > > If a UA sends an ill defined INVITE (say with > Max-forwards = 0) to a stateless proxy. The > proxy sends a 483 Too Many Hops response back > to the UA. > > Now the UA sends a good ACK for this to the stateless > proxy with the Request URI which is the same as > the INVITE. > > How does the stateless proxy know that this ACK is > meant for the previous INVITE and should not be > forwarded ahead? > > __________________________________ > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 15 06:00: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 GAA22988 for ; Fri, 15 Aug 2003 06:00: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 19nbNJ-0002pr-6r for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 06:00:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FA01es010844 for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 06:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nbML-0002nr-IE; Fri, 15 Aug 2003 05: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 19nbLh-0002nQ-4N for sip@optimus.ietf.org; Fri, 15 Aug 2003 05:58: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 FAA22926 for ; Fri, 15 Aug 2003 05:58:15 -0400 (EDT) From: asamtham@npd.hcltech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nbLd-0001VY-00 for sip@ietf.org; Fri, 15 Aug 2003 05:58:17 -0400 Received: from [202.54.64.7] (helo=hclnpd.hclt.co.in) by ietf-mx with esmtp (Exim 4.12) id 19nbLc-0001VF-00 for sip@ietf.org; Fri, 15 Aug 2003 05:58:17 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 32XRWPF6; Fri, 15 Aug 2003 15:21:53 +0530 Received: by pilex.hclt-ntl.co.in with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Aug 2003 15:25:30 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD963783D@pilex.hclt-ntl.co.in> To: vlakshmi70@yahoo.com, sip@ietf.org Subject: RE: [Sip] proxy stateless Date: Fri, 15 Aug 2003 15:25:29 +0530 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: , > -----Original Message----- > From: v l [mailto:vlakshmi70@yahoo.com] > Sent: Thursday, August 14, 2003 1:21 AM > To: sip@ietf.org > Subject: [Sip] proxy stateless > > > I have a question regarding stateless proxy > processing. > > If a UA sends an ill defined INVITE (say with > Max-forwards = 0) to a stateless proxy. The > proxy sends a 483 Too Many Hops response back > to the UA. > > Now the UA sends a good ACK for this to the stateless > proxy with the Request URI which is the same as > the INVITE. > > How does the stateless proxy know that this ACK is > meant for the previous INVITE and should not be > forwarded ahead? I think when stateless proxy rejects requests it can do it statefully. So that the transaction observes the ACK and prevent forwarding of ACK. Thanks Arnald _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 15 10:30:14 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 KAA29208 for ; Fri, 15 Aug 2003 10:30:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfaP-0005J7-5y for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 10:29:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FETnZ2020400 for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 10:29:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfZd-0005I2-CC; Fri, 15 Aug 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfZ2-0005H7-P5 for sip@optimus.ietf.org; Fri, 15 Aug 2003 10:28: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 KAA29170 for ; Fri, 15 Aug 2003 10:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nfZ0-0002tE-00 for sip@ietf.org; Fri, 15 Aug 2003 10:28:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19nfYz-0002t2-00 for sip@ietf.org; Fri, 15 Aug 2003 10:28:21 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FERhUg000534; Fri, 15 Aug 2003 10:27:43 -0400 (EDT) Message-ID: <3F3CEDDD.80707@dynamicsoft.com> Date: Fri, 15 Aug 2003 10:27:41 -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: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Calle capabilities device ID: take 2 References: In-Reply-To: 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 This relates to a fundamental question we need to answer: what is the scope of uniqueness of this ID? During the meeting, I had proposed that it was very long lived. For a hard-phone, it was effectively burned into firmware, and would be consistent across any reboots of the device. Thats a little ill-defined for a piece of software. I suppose that it would need to be unique for each distinct installation of the software. A random number selected at install time, and stored on disk, would work. It wouldnt survive a reinstall or an HD crash, but I suspect thats fine. However, the question is whether this level of uniqueness is needed? Its not for the original application that drove uri-user and uri-domain. THis is why I'd like some use cases from folks to make that determination. Here is one use case to start with: 1. single login: yahoo only allows one device to be registered at a time. Feature or bug? Well, whichever it is, we'd like it to be possible to allow this. It is possible to implement this without any callee caps, but a device ID would make it easy to disambiguate a registration from a device which crashed or changed its IP for some reason, from one where a second device is registering against the same AOR. This one only requires the device ID to have a long lived duration. -Jonathan R. Cullen Jennings wrote: > I think device-id is a useful idea but we do need to have a practical way to > generate this instance-id for a softphone running on a PC behind a NAT. A > sufficiently large random number seems like a possibility. It does have > privacy concerns that make when and where it can be removed complicated. > > On 8/13/03 11:11 AM, "Jonathan Rosenberg" wrote: > > >>Folks, >> >>I posted a note on this about a month back, with no responses. This is >>a big remaining open issue in callee caps and we want to resolve it. >>So, please take a look and respond. >> >>One of the issues I raised today during the meeting was on the utility >>of the uri-user and uri-domain parameters in >>draft-ietf-sip-callee-caps. The primary purpose that these serve is a >>means of identifying a UA instance. In order to accomplish >>applicaitons like assisted call transfer, a UA would send INVITE to >>the AOR of the transfer target, and include an Accept-Contact with the >>uri-user and uri-domain equal to those of the UA instance. >> >>Now, it turns out that uri-user and uri-domain are not very helpful >>when used this way. GRUU is a better approach. However, thats almost a >>secondary issue. >> >>The primary issue is that uri-user and uri-domain are ugly, and they >>repeat information already in the registration. The suggestion, made >>by Paul, was to instead define a device-id attribute. This ID would be >>long lived - burned into firmware of a device, perhaps. It would be >>included in a registration as a unique ID for the device or software >>instance, as the case may be. >> >>You could use this callee capability attribute for the assisted >>transfer just as you could use uri-user and uri-domain. It has the >>same problems that still make GRUU a better solution. However, during >>the meeting, folks like the idea of a device-id attribute as something >>useful for lots of other applications. >> >>So, I would like to invite comment and discussion on (1) whether you >>like the idea of replacing the uri-user and uri-domain attributes with >>device-id (a better name may be needed, like instance-id), (2) what >>kind of usages you had in mind for it, for good or for evil. >> >>Thanks, >>Jonathan R. > > -- 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 Aug 15 11:45:13 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 LAA01048 for ; Fri, 15 Aug 2003 11:45:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngkx-0000gE-QA for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 11:44:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFilLn002608 for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 11:44:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngkE-0000Wx-Bp; Fri, 15 Aug 2003 11: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 19ngkA-0000WF-NL for sip@optimus.ietf.org; Fri, 15 Aug 2003 11: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 LAA01017 for ; Fri, 15 Aug 2003 11:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngk9-0003In-00 for sip@ietf.org; Fri, 15 Aug 2003 11:43:57 -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 19ngk8-0003IK-00 for sip@ietf.org; Fri, 15 Aug 2003 11:43:57 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 08:50:23 -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 h7FFhJuG019689; Fri, 15 Aug 2003 08:43:19 -0700 (PDT) Date: Fri, 15 Aug 2003 11:43:15 -0400 From: "David R. Oran" To: Jonathan Rosenberg , Cullen Jennings cc: sip@ietf.org Subject: Re: [Sip] Calle capabilities device ID: take 2 Message-ID: <275238859.1060947795@[10.32.254.186]> In-Reply-To: <3F3CEDDD.80707@dynamicsoft.com> References: <3F3CEDDD.80707@dynamicsoft.com> X-Mailer: Mulberry/3.0.3 (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 Friday, August 15, 2003 10:27 AM -0400 Jonathan Rosenberg wrote: > This relates to a fundamental question we need to answer: what is the > scope of uniqueness of this ID? During the meeting, I had proposed that > it was very long lived. For a hard-phone, it was effectively burned into > firmware, and would be consistent across any reboots of the device. > Yes. > That's a little ill-defined for a piece of software. I suppose that it > would need to be unique for each distinct installation of the software. A > random number selected at install time, and stored on disk, would work. > It wouldnt survive a reinstall or an HD crash, but I suspect thats fine. > Sounds good. > However, the question is whether this level of uniqueness is needed? Its > not for the original application that drove uri-user and uri-domain. THis > is why I'd like some use cases from folks to make that determination. > For most of the uses I have in mind, it needs persistence equal to the administrative persistence of the things which enroll devices (as opposed to users) into a domain. So, I'd advocate not changing it even after a re-install of a softphone as long as there is a residual configuration from a prior installation left on the disk (a common practice for PC software). > Here is one use case to start with: > > 1. single login: yahoo only allows one device to be registered at a time. > Feature or bug? Well, whichever it is, we'd like it to be possible to > allow this. I'd call it a misfeature, but giving people a handle for this bad policy is not an argument against having the hook. > It is possible to implement this without any callee caps, but > a device ID would make it easy to disambiguate a registration from a > device which crashed or changed its IP for some reason, from one where a > second device is registering against the same AOR. > That seems at least moderately useful. Dave. > This one only requires the device ID to have a long lived duration. > > -Jonathan R. > > > > Cullen Jennings wrote: > >> I think device-id is a useful idea but we do need to have a practical >> way to generate this instance-id for a softphone running on a PC behind >> a NAT. A sufficiently large random number seems like a possibility. It >> does have privacy concerns that make when and where it can be removed >> complicated. >> >> On 8/13/03 11:11 AM, "Jonathan Rosenberg" >> wrote: >> >> >>> Folks, >>> >>> I posted a note on this about a month back, with no responses. This is >>> a big remaining open issue in callee caps and we want to resolve it. >>> So, please take a look and respond. >>> >>> One of the issues I raised today during the meeting was on the utility >>> of the uri-user and uri-domain parameters in >>> draft-ietf-sip-callee-caps. The primary purpose that these serve is a >>> means of identifying a UA instance. In order to accomplish >>> applicaitons like assisted call transfer, a UA would send INVITE to >>> the AOR of the transfer target, and include an Accept-Contact with the >>> uri-user and uri-domain equal to those of the UA instance. >>> >>> Now, it turns out that uri-user and uri-domain are not very helpful >>> when used this way. GRUU is a better approach. However, thats almost a >>> secondary issue. >>> >>> The primary issue is that uri-user and uri-domain are ugly, and they >>> repeat information already in the registration. The suggestion, made >>> by Paul, was to instead define a device-id attribute. This ID would be >>> long lived - burned into firmware of a device, perhaps. It would be >>> included in a registration as a unique ID for the device or software >>> instance, as the case may be. >>> >>> You could use this callee capability attribute for the assisted >>> transfer just as you could use uri-user and uri-domain. It has the >>> same problems that still make GRUU a better solution. However, during >>> the meeting, folks like the idea of a device-id attribute as something >>> useful for lots of other applications. >>> >>> So, I would like to invite comment and discussion on (1) whether you >>> like the idea of replacing the uri-user and uri-domain attributes with >>> device-id (a better name may be needed, like instance-id), (2) what >>> kind of usages you had in mind for it, for good or for evil. >>> >>> Thanks, >>> Jonathan R. >> >> > > -- > 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 ------------------------ 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 Aug 15 16:06: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 QAA11569 for ; Fri, 15 Aug 2003 16:06: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 19nkq6-0007kO-DI for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 16:06:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FK6MLa029764 for sip-archive@odin.ietf.org; Fri, 15 Aug 2003 16: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 19nkpm-0007jf-P2; Fri, 15 Aug 2003 16: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 19nkpk-0007jK-O0 for sip@optimus.ietf.org; Fri, 15 Aug 2003 16:06: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 QAA11534 for ; Fri, 15 Aug 2003 16:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkpj-0005b6-00 for sip@ietf.org; Fri, 15 Aug 2003 16:05:59 -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 19nkpi-0005aQ-00 for sip@ietf.org; Fri, 15 Aug 2003 16:05:58 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 13:12:29 -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 h7FK5Q7F015653; Fri, 15 Aug 2003 13:05:26 -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 AKK71022; Fri, 15 Aug 2003 12:58:05 -0700 (PDT) Date: Fri, 15 Aug 2003 13:06:52 -0700 Subject: Re: [Sip] comments on history-info-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F14A336.7040504@dynamicsoft.com> Message-Id: <02E679A8-CF5C-11D7-A89B-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 Wednesday, July 16, 2003, at 02:58 AM, Jonathan Rosenberg wrote: [snip] > and then: >> For retargets as a result of timeouts or internal events, a Reason >> header MAY be included in the Reason header of the >> >> Targeted-to-URI. > > what are internal events? forking decisions made by the proxy (for example, cancelling a branch) > What value does the reason parameter have in the case of timeout? I would assume a 408 > In the case of internal events? depends on the event. might be a 487 many times. 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 Aug 18 11:16: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 LAA22422 for ; Mon, 18 Aug 2003 11:16: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 19oljP-0000hL-7l for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 11:15:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IFFdOe002679 for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 11:15:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19olio-0000bB-R1; Mon, 18 Aug 2003 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19olil-0000Zh-KX for sip@optimus.ietf.org; Mon, 18 Aug 2003 11:14:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22311; Mon, 18 Aug 2003 11:14:54 -0400 (EDT) Message-Id: <200308181514.LAA22311@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, 18 Aug 2003 11:14:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-04.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 Session Inititation Protocol (SIP) 'Replaces' Header Author(s) : B. Biggs, R. Dean, R. Mahy Filename : draft-ietf-sip-replaces-04.txt Pages : 18 Date : 2003-8-18 This document defines a new header for use with SIP multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Call Pickup'. Note that definition of these example features is non-normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-04.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-replaces-04.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-replaces-04.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-18112832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-replaces-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-replaces-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112832.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 Mon Aug 18 12:54: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 MAA25900 for ; Mon, 18 Aug 2003 12:54: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 19onGu-0004Pp-2M for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 12:54:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IGsK9J016915 for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 12:54:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onGb-0004OF-TC; Mon, 18 Aug 2003 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onGA-0004NB-NA for sip@optimus.ietf.org; Mon, 18 Aug 2003 12:53: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 MAA25886 for ; Mon, 18 Aug 2003 12:53:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19onG8-0000tf-00 for sip@ietf.org; Mon, 18 Aug 2003 12:53:33 -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 19onG8-0000tc-00 for sip@ietf.org; Mon, 18 Aug 2003 12:53:32 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2003 10:00: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 h7IGqv7H017333; Mon, 18 Aug 2003 09:53:00 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABP78666; Mon, 18 Aug 2003 12:52:57 -0400 (EDT) Message-ID: <3F410469.6030609@cisco.com> Date: Mon, 18 Aug 2003 12:52:57 -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: sip@ietf.org References: <200308181514.LAA22311@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-replaces-04.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 "If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged." Exactly what is the meaning of "incompatible media" in the above? In general, when an INVITE arrives containing an offer, the recipient may accept the INVITE while rejecting some or all of the media, up to and including ending up with a call containing no media. If it is ok to accept a call while rejecting all the media then there is no such thing as a call with incompatible media. I fear that we will begin to have interop problems if some UAs accept calls under this kind of situation, while others reject them. 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 Aug 18 13:25: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 NAA26578 for ; Mon, 18 Aug 2003 13:25: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 19onks-0005mJ-L8 for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 13:25:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IHPI0G022208 for sip-archive@odin.ietf.org; Mon, 18 Aug 2003 13:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onkc-0005hx-4R; Mon, 18 Aug 2003 13: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 19onkF-0005gt-VK for sip@optimus.ietf.org; Mon, 18 Aug 2003 13:24: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 NAA26546 for ; Mon, 18 Aug 2003 13:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19onkD-00013O-00 for sip@ietf.org; Mon, 18 Aug 2003 13:24: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 19onkD-00012h-00 for sip@ietf.org; Mon, 18 Aug 2003 13:24:37 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2003 10:31:37 -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 h7IHO4uG006868; Mon, 18 Aug 2003 10:24:05 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABP82075; Mon, 18 Aug 2003 13:24:03 -0400 (EDT) Message-ID: <3F410BB2.1000500@cisco.com> Date: Mon, 18 Aug 2003 13:24:02 -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: sip References: <200308181514.LAA22311@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-replaces-04.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 Here is another point that I find fuzzy, in Section 3: "If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 (Call/Transaction Does Not Exist) response to the new INVITE, and leaves the matched dialog unchanged. Note that since Replaces matches only a single dialog, the replacement dialog will not be retargeted according to the same forking logic as the original request which created the early dialog. (Currently no use cases have been identified for replacing just a single dialog in this circumstance.)" I don't know how to interpret this. Suppose X sent an invite to Y, and Y returned a 183 establishing an early dialog. I think you are saying that an INVITE/Replaces referencing this dialog should be rejected if received by one of these UAs, but which one? (X initiated the invitation which resulted in the dialog, but Y sent the response with a To-tag that actually initiated the specific dialog.) In example 7.1 Alice, who is in the role of X above, answers the invite/replaces. This implies that you intend to have the party in role Y refuse the replacement. But in Section 4 I see: For example, if Alice replaces Cathy in an early dialog with Bob, but he does not answer, Alice's replacement request will not match other dialogs to which Bob's UA redirects, nor other branches to which his proxy forwards. Although this specification takes reasonable In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must be by Alice sending an invite/replaces to Bob. You seem not to want this to fail either. So, I am confused with what you are trying to restrict. 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 Aug 19 05:10: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 FAA02356 for ; Tue, 19 Aug 2003 05:10: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 19p2VS-0004zJ-Hs for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 05:10:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J9AMkn019169 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 05:10:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2V9-0004xs-74; Tue, 19 Aug 2003 05: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 19p2Uw-0004uL-KJ for sip@optimus.ietf.org; Tue, 19 Aug 2003 05: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 FAA02308 for ; Tue, 19 Aug 2003 05:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p2Ut-00061I-00 for sip@ietf.org; Tue, 19 Aug 2003 05:09:47 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19p2Us-000611-00 for sip@ietf.org; Tue, 19 Aug 2003 05:09:46 -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 <0HJV00A0103322@mailout1.samsung.com> for sip@ietf.org; Tue, 19 Aug 2003 18:09:03 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HJV004W5033UP@mailout1.samsung.com> for sip@ietf.org; Tue, 19 Aug 2003 18:09:03 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HJV001DO02Z8V@mmp1.samsung.com> for sip@ietf.org; Tue, 19 Aug 2003 18:09:03 +0900 (KST) Date: Tue, 19 Aug 2003 14:32:22 +0530 From: Ranjit Avasarala To: sip@ietf.org Reply-to: ranjitk@samsung.com Message-id: <001001c36630$9caad2d0$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_bwHRx1/sSAvmTXtwGeJXqA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Sip] Question on starting media after sendign 200 ok Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_bwHRx1/sSAvmTXtwGeJXqA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all I have a doubt regarding starting media after signalling.. Will I be deviating from RFC compliance if I start media session soon after I send 200 OK? or should I wait for ACK and then start media? like my case as explained below: UA1 sends Invite to UA2 UA2 accepts the call and sends 200 OK and starts media session Then UA1 sends ACK and starts media session UA2 receives ACK Thanks Ranjit --Boundary_(ID_bwHRx1/sSAvmTXtwGeJXqA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Hi all
 
I have a doubt regarding starting media after signalling..
 
Will I be deviating from RFC compliance if I start media session soon after I send 200 OK? or should I wait for ACK and then start media?
 
like my case as explained below:
 
UA1 sends Invite to UA2
UA2 accepts the call and sends 200 OK and starts media session
Then UA1 sends ACK and starts media session
UA2 receives ACK
 
Thanks
Ranjit
--Boundary_(ID_bwHRx1/sSAvmTXtwGeJXqA)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 19 15:45: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 PAA04423 for ; Tue, 19 Aug 2003 15:45: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 19pCPC-0006zU-DQ for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 15:44:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJiYao026868 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 15:44:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCOf-0006yJ-Sp; Tue, 19 Aug 2003 15: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 19pCOS-0006xq-Oh for sip@optimus.ietf.org; Tue, 19 Aug 2003 15:43: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 PAA04347 for ; Tue, 19 Aug 2003 15:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCOR-0006bD-00 for sip@ietf.org; Tue, 19 Aug 2003 15:43:47 -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 19pCOQ-0006aX-00 for sip@ietf.org; Tue, 19 Aug 2003 15:43:46 -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 h7JJhFWu013796; Tue, 19 Aug 2003 12:43:15 -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 AKN84727; Tue, 19 Aug 2003 12:35:18 -0700 (PDT) Date: Tue, 19 Aug 2003 10:26:22 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F410469.6030609@cisco.com> Message-Id: <40C3D8B0-D26A-11D7-93EC-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 Paul, Thanks for bringing this up. I think the draft needs to distinguish between these cases: 1) The UA receives an offer with no compatible media and does not wish to maintain a session with no associated media. 2) The UA receives an offer but does not wish to send/receive media at the moment (possibly because it is negotiating a session using 3pcc on behalf of another UA). I think the same distinction applies to UAs that receive "ordinary" INVITEs. They can accept an offer but reject all the m-lines, or they can send a 4xx response. So... - Do you think 3261 needs any clarification to make this distinction obvious? - Can you propose some text for Replaces that makes clear my original intention (what you do in case 1), while still allowing for case 2? thanks, -rohan On Monday, August 18, 2003, at 09:52 AM, Paul Kyzivat wrote: > "If the UA cannot accept the new INVITE (for example: it cannot > establish required QoS or keying, or it has incompatible media), the > UA MUST return an appropriate error response and MUST leave the > matched dialog unchanged." > > Exactly what is the meaning of "incompatible media" in the above? > > In general, when an INVITE arrives containing an offer, the recipient > may accept the INVITE while rejecting some or all of the media, up to > and including ending up with a call containing no media. If it is ok > to accept a call while rejecting all the media then there is no such > thing as a call with incompatible media. > > I fear that we will begin to have interop problems if some UAs accept > calls under this kind of situation, while others reject them. > > 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 Aug 19 16:04: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 QAA06227 for ; Tue, 19 Aug 2003 16:04: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 19pCi8-00080Z-Um for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 16:04:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JK484w030774 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 16:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCi2-0007zU-JY; Tue, 19 Aug 2003 16:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pChI-0007x9-3o for sip@optimus.ietf.org; Tue, 19 Aug 2003 16:03: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 QAA06161 for ; Tue, 19 Aug 2003 16:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pChG-00079y-00 for sip@ietf.org; Tue, 19 Aug 2003 16:03: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 19pChF-000795-00 for sip@ietf.org; Tue, 19 Aug 2003 16:03:14 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 13:10:32 -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 h7JK2gqq026686; Tue, 19 Aug 2003 13:02: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 AKN87008; Tue, 19 Aug 2003 12:54:46 -0700 (PDT) Date: Tue, 19 Aug 2003 13:05:38 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F410BB2.1000500@cisco.com> Message-Id: <80611142-D280-11D7-B410-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 On Monday, August 18, 2003, at 10:24 AM, Paul Kyzivat wrote: > Here is another point that I find fuzzy, in Section 3: > > "If the Replaces header field matches an early dialog that was not > initiated by this UA, it returns a 481 (Call/Transaction Does Not > Exist) response to the new INVITE, and leaves the matched dialog > unchanged. Note that since Replaces matches only a single dialog, > the > replacement dialog will not be retargeted according to the same > forking logic as the original request which created the early > dialog. > (Currently no use cases have been identified for replacing just a > single dialog in this circumstance.)" > > I don't know how to interpret this. Suppose X sent an invite to Y, and > Y returned a 183 establishing an early dialog. I think you are saying > that an INVITE/Replaces referencing this dialog should be rejected if > received by one of these UAs, but which one? > > (X initiated the invitation which resulted in the dialog, but Y sent > the response with a To-tag that actually initiated the specific > dialog.) No, the spec is pretty clear on this. X initiated the dialog. Y caused the dialog to become an early dialog. If you can come up with a rewording which is more precise and still clear, I am happy to incorporate it. > In example 7.1 Alice, who is in the role of X above, answers the > invite/replaces. This implies that you intend to have the party in > role Y refuse the replacement. I don't follow you here. > But in Section 4 I see: > > For example, if Alice replaces Cathy in an early dialog with Bob, > but > he does not answer, Alice's replacement request will not match other > dialogs to which Bob's UA redirects, nor other branches to which his > proxy forwards. Although this specification takes reasonable > > In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must > be by Alice sending an invite/replaces to Bob. You seem not to want > this to fail either. I am not following X = Cathy, Y = Bob. In any case, this paragraph is motivational explaining why you shouldn't send a Replaces header for a dialog you know is still in the early state, unless you are sending the replacement request to the initiator of the request you want to replace. > So, I am confused with what you are trying to restrict. Y cannot accept an INVITE with Replaces for the early dialog between X and Y. is that clear? thanks,. -rohan > > 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 Aug 19 20:07:25 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 UAA17108 for ; Tue, 19 Aug 2003 20:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGV9-0002T0-7k for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06xeF009397 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUP-00022h-Ey; Tue, 19 Aug 2003 20:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFbJ-0000Ll-PL for sip@optimus.ietf.org; Tue, 19 Aug 2003 19:09: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 TAA14803 for ; Tue, 19 Aug 2003 19:09:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFbG-0001Lp-00 for sip@ietf.org; Tue, 19 Aug 2003 19:09: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 19pFbF-0001Lh-00 for sip@ietf.org; Tue, 19 Aug 2003 19:09:14 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 16:16:34 -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 h7JN8fuG001567; Tue, 19 Aug 2003 16:08:42 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABR02929; Tue, 19 Aug 2003 19:08:40 -0400 (EDT) Message-ID: <3F42ADF8.4010909@cisco.com> Date: Tue, 19 Aug 2003 19:08:40 -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: sip References: <80611142-D280-11D7-B410-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 Rohan Mahy wrote: > > On Monday, August 18, 2003, at 10:24 AM, Paul Kyzivat wrote: > >> Here is another point that I find fuzzy, in Section 3: >> >> "If the Replaces header field matches an early dialog that was not >> initiated by this UA, it returns a 481 (Call/Transaction Does Not >> Exist) response to the new INVITE, and leaves the matched dialog >> unchanged. Note that since Replaces matches only a single dialog, the >> replacement dialog will not be retargeted according to the same >> forking logic as the original request which created the early >> dialog. >> (Currently no use cases have been identified for replacing just a >> single dialog in this circumstance.)" >> >> I don't know how to interpret this. Suppose X sent an invite to Y, and >> Y returned a 183 establishing an early dialog. I think you are saying >> that an INVITE/Replaces referencing this dialog should be rejected if >> received by one of these UAs, but which one? >> >> (X initiated the invitation which resulted in the dialog, but Y sent >> the response with a To-tag that actually initiated the specific dialog.) > > > No, the spec is pretty clear on this. X initiated the dialog. Y caused > the dialog to become an early dialog. If you can come up with a > rewording which is more precise and still clear, I am happy to > incorporate it. Based on your clarifications below, maybe the wording is ok as long as wording elsewhere that hints at another meaning is fixed. >> In example 7.1 Alice, who is in the role of X above, answers the >> invite/replaces. This implies that you intend to have the party in >> role Y refuse the replacement. > > I don't follow you here. I'm just applying logic to the example. Alice is in role X because she sent the invite. Alice also answers the invite/replaces. According to your rule, she would have had to refuse it if she was not the initiator of the dialog. So she must be the initiator of the dialog. So in my terms role X is the dialog initiator and hence role Y is not the dialog initiator. Hence I agree that this example is consistent with what you say below, that Y cannot accept the invite/replaces. > >> But in Section 4 I see: >> >> For example, if Alice replaces Cathy in an early dialog with Bob, but >> he does not answer, Alice's replacement request will not match other >> dialogs to which Bob's UA redirects, nor other branches to which his >> proxy forwards. Although this specification takes reasonable >> >> In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must >> be by Alice sending an invite/replaces to Bob. You seem not to want >> this to fail either. > > > I am not following X = Cathy, Y = Bob. Here is logic: - "... Cathy in an early dialog with Bob" => Cathy sent INVITE to Bob, OR Bob sent INVITE to Cathy AND that INVITE hasn't completed yet - "but he does not answer" => the INVITE must have been from Cathy to Bob - "Alice replaces Cathy ..." => Alice sends INVITE/Replaces to Bob => the invite/replaces exceeds (else Alice won't replace Cathy) This means Cathy is in role X and Bob in role Y. Using either my terminology or yours, this is the case where the recipient of the invite/replaces must refuse it. So this example seems to violate your rule. > In any case, this paragraph is > motivational explaining why you shouldn't send a Replaces header for a > dialog you know is still in the early state, unless you are sending the > replacement request to the initiator of the request you want to replace. Well, it isn't motivational for me. :-) Its just confusing. I now think I understand that you intend this as a counterexample, of what bad things could happen if the restriction were not in place. But as worded it isn't clear that it is an example that isn't possible given the restriction. And I think it is nonsensical - what would lead Alice to do such a stupid thing? I'm not sure it is possible to come up with an example that makes much sense. 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 Aug 19 20:07: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 UAA17111 for ; Tue, 19 Aug 2003 20:07: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 19pGV9-0002Sv-7N for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06xgx009395 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUL-0001yk-Ju; Tue, 19 Aug 2003 20:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFL2-000875-7W for sip@optimus.ietf.org; Tue, 19 Aug 2003 18: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 SAA14347 for ; Tue, 19 Aug 2003 18:52:21 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFKz-0001EP-00 for sip@ietf.org; Tue, 19 Aug 2003 18:52:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19pFKy-0001EM-00 for sip@ietf.org; Tue, 19 Aug 2003 18:52: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 h7JMqN408364 for ; Wed, 20 Aug 2003 01:52:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Aug 2003 01:52:23 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 01:52: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Aug 2003 01:52:23 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796FCA@esebe019.ntc.nokia.com> Thread-Topic: "the scope of the Contact is global" Thread-Index: AcNmpIxjgtnk3DzuR3WfIu+cQzvmHQ== To: X-OriginalArrivalTime: 19 Aug 2003 22:52:23.0325 (UTC) FILETIME=[8DA004D0:01C366A4] Content-Transfer-Encoding: quoted-printable Subject: [Sip] "the scope of the Contact is global" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 following text appears in RFC3261 section 8.1.1.8 "The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs." So, the scenario is: - I send an INVITE with contact: sip:hisham@1.2.3.4:54321 (note the = port) - the session is now finished and I terminate the dialog The port that was used in contact was specified for that dialog only. So = the question is: must the URI in the contact header be valid for = subsequent requests even after the dialog is terminated? Which = consequently means that my SIP stack needs to accept requests on port = 54321 for ever?=20 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 Tue Aug 19 20:26: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 UAA18022 for ; Tue, 19 Aug 2003 20:26: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 19pGnm-0004CW-7P for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:26:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K0QE3G016137 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 20:26:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGnZ-0004Bi-Q2; Tue, 19 Aug 2003 20: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 19pGnU-0004BG-M9 for sip@optimus.ietf.org; Tue, 19 Aug 2003 20:25: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 UAA17987 for ; Tue, 19 Aug 2003 20:25:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGnS-00024n-00 for sip@ietf.org; Tue, 19 Aug 2003 20:25:54 -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 19pGnR-00024R-00 for sip@ietf.org; Tue, 19 Aug 2003 20:25:54 -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 h7K0PHAi019029; Tue, 19 Aug 2003 17:25: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 AKO20691; Tue, 19 Aug 2003 17:17:21 -0700 (PDT) Date: Tue, 19 Aug 2003 17:28:14 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F42ADF8.4010909@cisco.com> Message-Id: <2FA96440-D2A5-11D7-B410-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 On Tuesday, August 19, 2003, at 04:08 PM, Paul Kyzivat wrote: > > > Rohan Mahy wrote: >> On Monday, August 18, 2003, at 10:24 AM, Paul Kyzivat wrote: >>> Here is another point that I find fuzzy, in Section 3: >>> >>> "If the Replaces header field matches an early dialog that was not >>> initiated by this UA, it returns a 481 (Call/Transaction Does Not >>> Exist) response to the new INVITE, and leaves the matched dialog >>> unchanged. Note that since Replaces matches only a single dialog, >>> the >>> replacement dialog will not be retargeted according to the same >>> forking logic as the original request which created the early >>> dialog. >>> (Currently no use cases have been identified for replacing just a >>> single dialog in this circumstance.)" >>> >>> I don't know how to interpret this. Suppose X sent an invite to Y, >>> and Y returned a 183 establishing an early dialog. I think you are >>> saying that an INVITE/Replaces referencing this dialog should be >>> rejected if received by one of these UAs, but which one? >>> >>> (X initiated the invitation which resulted in the dialog, but Y sent >>> the response with a To-tag that actually initiated the specific >>> dialog.) >> No, the spec is pretty clear on this. X initiated the dialog. Y >> caused the dialog to become an early dialog. If you can come up with >> a rewording which is more precise and still clear, I am happy to >> incorporate it. > > Based on your clarifications below, maybe the wording is ok as long as > wording elsewhere that hints at another meaning is fixed. > >>> In example 7.1 Alice, who is in the role of X above, answers the >>> invite/replaces. This implies that you intend to have the party in >>> role Y refuse the replacement. >> I don't follow you here. > > I'm just applying logic to the example. Alice is in role X because she > sent the invite. Alice also answers the invite/replaces. According to > your rule, she would have had to refuse it if she was not the > initiator of the dialog. So she must be the initiator of the dialog. > So in my terms role X is the dialog initiator and hence role Y is not > the dialog initiator. > > Hence I agree that this example is consistent with what you say below, > that Y cannot accept the invite/replaces. > >>> But in Section 4 I see: >>> >>> For example, if Alice replaces Cathy in an early dialog with Bob, >>> but >>> he does not answer, Alice's replacement request will not match >>> other >>> dialogs to which Bob's UA redirects, nor other branches to which >>> his >>> proxy forwards. Although this specification takes reasonable >>> >>> In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must >>> be by Alice sending an invite/replaces to Bob. You seem not to want >>> this to fail either. >> I am not following X = Cathy, Y = Bob. > > Here is logic: > > - "... Cathy in an early dialog with Bob" > > => Cathy sent INVITE to Bob, OR Bob sent INVITE to Cathy > AND that INVITE hasn't completed yet > > - "but he does not answer" > > => the INVITE must have been from Cathy to Bob > > - "Alice replaces Cathy ..." > > => Alice sends INVITE/Replaces to Bob > => the invite/replaces exceeds (else Alice won't replace Cathy) > > This means Cathy is in role X and Bob in role Y. Using either my > terminology or yours, this is the case where the recipient of the > invite/replaces must refuse it. > > So this example seems to violate your rule. > > > In any case, this paragraph is >> motivational explaining why you shouldn't send a Replaces header for >> a dialog you know is still in the early state, unless you are sending >> the replacement request to the initiator of the request you want to >> replace. > > Well, it isn't motivational for me. :-) > > Its just confusing. I now think I understand that you intend this as a > counterexample, of what bad things could happen if the restriction > were not in place. yes > But as worded it isn't clear that it is an example that isn't possible > given the restriction. bummer. can you propose some rewording? > And I think it is nonsensical - what would lead Alice to do such a > stupid thing? I'm not sure it is possible to come up with an example > that makes much sense. you'd be *amazed*. thx, -r > 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 Aug 19 21: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 VAA19857 for ; Tue, 19 Aug 2003 21: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 19pHf2-0006oJ-Vg for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 21:21:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K1LGVe026159 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 21:21:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pHen-0006mJ-IW; Tue, 19 Aug 2003 21:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pHe6-0006le-1E for sip@optimus.ietf.org; Tue, 19 Aug 2003 21:20: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 VAA19822 for ; Tue, 19 Aug 2003 21:20:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pHe3-0002ZZ-00 for sip@ietf.org; Tue, 19 Aug 2003 21:20:15 -0400 Received: from web41503.mail.yahoo.com ([66.218.93.86]) by ietf-mx with smtp (Exim 4.12) id 19pHe2-0002ZQ-00 for sip@ietf.org; Tue, 19 Aug 2003 21:20:14 -0400 Message-ID: <20030820011944.97728.qmail@web41503.mail.yahoo.com> Received: from [131.107.3.71] by web41503.mail.yahoo.com via HTTP; Tue, 19 Aug 2003 18:19:44 PDT Date: Tue, 19 Aug 2003 18:19:44 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] "the scope of the Contact is global" To: hisham.khartabil@nokia.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796FCA@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: , Interesting. Isn't this the GRUU discussion? I may be confused here. --- hisham.khartabil@nokia.com wrote: > The following text appears in RFC3261 section > 8.1.1.8 > > "The Contact header field MUST be present and > contain exactly one SIP > or SIPS URI in any request that can result in the > establishment of a > dialog. For the methods defined in this > specification, that includes > only the INVITE request. For these requests, the > scope of the > Contact is global. That is, the Contact header > field value contains > the URI at which the UA would like to receive > requests, and this URI > MUST be valid even if used in subsequent requests > outside of any > dialogs." > > So, the scenario is: > > - I send an INVITE with contact: > sip:hisham@1.2.3.4:54321 (note the port) > - the session is now finished and I terminate the > dialog > > The port that was used in contact was specified for > that dialog only. So the question is: must the URI > in the contact header be valid for subsequent > requests even after the dialog is terminated? Which > consequently means that my SIP stack needs to accept > requests on port 54321 for ever? > > 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 __________________________________ 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 Wed Aug 20 08:34: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 IAA06427 for ; Wed, 20 Aug 2003 08:34: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 19pSAK-00021P-1A for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 08:34:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KCYG9m007767 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 08:34:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSA6-00020Z-2e; Wed, 20 Aug 2003 08: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 19pS9D-0001yE-Fc for sip@optimus.ietf.org; Wed, 20 Aug 2003 08:33: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 IAA06353 for ; Wed, 20 Aug 2003 08:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pS9C-0000FJ-00 for sip@ietf.org; Wed, 20 Aug 2003 08:33: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 19pS9B-0000Ev-00 for sip@ietf.org; Wed, 20 Aug 2003 08:33:05 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2003 05:39:28 -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 h7KCVM7b015301; Wed, 20 Aug 2003 05:31:23 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABR33500; Wed, 20 Aug 2003 08:31:21 -0400 (EDT) Message-ID: <3F436A19.6080103@cisco.com> Date: Wed, 20 Aug 2003 08:31:21 -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: sip@ietf.org References: <40C3D8B0-D26A-11D7-93EC-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 Rohan Mahy wrote: > Paul, > > Thanks for bringing this up. I think the draft needs to distinguish > between these cases: > > 1) The UA receives an offer with no compatible media and does not wish > to maintain a session with no associated media. > > 2) The UA receives an offer but does not wish to send/receive media at > the moment (possibly because it is negotiating a session using 3pcc on > behalf of another UA). > > I think the same distinction applies to UAs that receive "ordinary" > INVITEs. They can accept an offer but reject all the m-lines, or they > can send a 4xx response. So... I agree that this is a general issue for invites - or perhaps more generally for offer/answer. > - Do you think 3261 needs any clarification to make this distinction > obvious? > - Can you propose some text for Replaces that makes clear my original > intention (what you do in case 1), while still allowing for case 2? I have been thinking about this problem for some time. I have an idea, but I have been reluctant to offer it because it seems to be overly complex. Nevertheless... How about preconditions? - In the absence of preconditions to the contrary, the assumption would be that the offerer is satisfied with whatever it can get, including nothing at all. It is up to the answerer to decide what is sufficient and what is not. - some kind of new media precondition would provide the opportunity for the two sides to do an extended negotiation for mutually satisfactory media before alerting anyone. If it becomes apparent that the conditions cannot be met, then the invitation containing the offers and answers fails. I haven't thought enough about this to go further and define exactly how the precondition would be expressed. But how does the general concept sound? An advantage to this is that it doesn't change 3261, and is upward compatible with current 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 Aug 20 10:53: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 KAA12191 for ; Wed, 20 Aug 2003 10:53: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 19pUKi-0007zj-A1 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 10:53:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KEr8LI030730 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 10:53:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUKa-0007zB-Jb; Wed, 20 Aug 2003 10:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUJx-0007yo-3Z for sip@optimus.ietf.org; Wed, 20 Aug 2003 10:52: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 KAA12165 for ; Wed, 20 Aug 2003 10:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUJu-0001XE-00 for sip@ietf.org; Wed, 20 Aug 2003 10:52:18 -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 19pUJt-0001Wk-00 for sip@ietf.org; Wed, 20 Aug 2003 10:52:17 -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 h7KEp07d028504; Wed, 20 Aug 2003 07:51:03 -0700 (PDT) Received: from cisco.com ([161.44.79.70]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABR43210; Wed, 20 Aug 2003 10:50:59 -0400 (EDT) Message-ID: <3F438AD3.7070800@cisco.com> Date: Wed, 20 Aug 2003 10:50: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: Rohan Mahy CC: sip References: <2FA96440-D2A5-11D7-B410-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-replaces-04.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 Rohan Mahy wrote: > >>>> But in Section 4 I see: >>>> >>>> For example, if Alice replaces Cathy in an early dialog with Bob, >>>> but >>>> he does not answer, Alice's replacement request will not match other >>>> dialogs to which Bob's UA redirects, nor other branches to which his >>>> proxy forwards. Although this specification takes reasonable >>>> >>>> In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must >>>> be by Alice sending an invite/replaces to Bob. You seem not to want >>>> this to fail either. [snip] >> Its just confusing. I now think I understand that you intend this as a >> counterexample, of what bad things could happen if the restriction >> were not in place. > > yes > >> But as worded it isn't clear that it is an example that isn't possible >> given the restriction. > > bummer. can you propose some rewording? > >> And I think it is nonsensical - what would lead Alice to do such a >> stupid thing? I'm not sure it is possible to come up with an example >> that makes much sense. > > you'd be *amazed*. How about the following changes: - in the second to last paragraph of section 4, modify the following: "If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a CANCEL." after "replaced dialog" insert ", any other early dialogs, and any other pending forks". - in section 4, delete the following: "For example, if Alice replaces Cathy in an early dialog with Bob, but he does not answer, Alice's replacement request will not match other dialogs to which Bob's UA redirects, nor other branches to which his proxy forwards." - add a new section 4.1: 4.1 Example of Incorrect Client Behavior The following is an example of an attempt to violate the rule against sending a replacement request to the non-initiating end of an early dialog. Bob Bob Bob Bob Alice Proxy desk home lab | | | | | |--INVITE-->|--INVITE-->| | | |<----180---|<----180---| | | | |--------INVITE------->| | |<----180---|<---------180---------| | | | | Bob hears desk phone | | | | ringing from lab but | | | | isn't REGISTERed yet | | | | | | | |<--fetch dialog state --| | | |---response ----------->| | | |<--INVITE/Replaces------| | | |----------481---------->| |<----200---|<---------200---------| | |--------------ACK---------------->| | | |--CANCEL-->| | | | |<---200----| | | | |<---487----| | | | |----ACK--->| | | Were this not illegal, it could result in something like the following: Bob Bob Bob Bob Alice Proxy desk home lab | | | | | |--INVITE-->|--INVITE-->| | | |<----180---|<----180---| | | | |--------INVITE------->| | |<----180---|<---------180---------| | | | | Bob hears desk phone | | | | ringing from lab but | | | | isn't REGISTERed yet | | | | | | | |<--fetch dialog state --| | | |---response ----------->| | | |<--INVITE/Replaces------| | | |----------180---------->| | |<---4xx----| | | | |----ACK--->| | | |<----200---|<---------200---------| | |--------------ACK---------------->| | In this case, Bob at his lab computer would simply listen to his desk phone ringing. Meanwhile, Alice's call is answered by someone at Bob's home. For a working example, see section 7.1. - Note that this couterexample is still non-sensical - it is an erroneous attempt to achieve Bob's intent. I can't think of an a better case to expose the issue. 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 Aug 20 11:10: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 LAA13038 for ; Wed, 20 Aug 2003 11:10: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 19pUbD-0000VR-6q for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 11:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFAB26001903 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 11:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUb4-0000SQ-Eu; Wed, 20 Aug 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUaY-0000Qz-Ib for sip@optimus.ietf.org; Wed, 20 Aug 2003 11:09: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 LAA12970 for ; Wed, 20 Aug 2003 11:09:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUaV-0001hq-00 for sip@ietf.org; Wed, 20 Aug 2003 11:09:27 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19pUaV-0001hn-00 for sip@ietf.org; Wed, 20 Aug 2003 11:09:27 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h7KF9RXR079949; Wed, 20 Aug 2003 11:09:27 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] "the scope of the Contact is global" Date: Wed, 20 Aug 2003 11:15:40 -0400 Message-ID: <000001c3672d$eb37ae70$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) In-Reply-To: <20030820011944.97728.qmail@web41503.mail.yahoo.com> Importance: Normal 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 > Interesting. Isn't this the GRUU discussion? Yes. I was surprised to see the text in RFC3261. Because of security, privacy, mobility, proxy bypass, and private network concerns, I doubt that all product deployments would actually follow that portion of the specification. However the concept is needed for certain service implementations that involve proxies instead of a B2BUA. Thus I think that the work on draft-rosenberg-sipping-gruu-reqs should continue. > --- hisham.khartabil@nokia.com wrote: > > The following text appears in RFC3261 section > > 8.1.1.8 > > > > "The Contact header field MUST be present and > > contain exactly one SIP or SIPS URI in any > > request that can result in the establishment of > > a dialog. For the methods defined in this > > specification, that includes only the INVITE > > request. For these requests, the scope of the > > Contact is global. That is, the Contact header > > field value contains the URI at which the UA would > > like to receive requests, and this URI MUST be > > valid even if used in subsequent requests > > outside of any dialogs." > > > > So, the scenario is: > > > > - I send an INVITE with contact: > > sip:hisham@1.2.3.4:54321 (note the port) > > - the session is now finished and I terminate the > > dialog > > > > The port that was used in contact was specified for > > that dialog only. So the question is: must the URI > > in the contact header be valid for subsequent > > requests even after the dialog is terminated? Which > > consequently means that my SIP stack needs to accept > > requests on port 54321 for ever? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 20 14:10: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 OAA26405 for ; Wed, 20 Aug 2003 14:10: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 19pXPO-0002FX-Kk for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KIAAHr008624 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:10:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXPG-0002E9-9J; Wed, 20 Aug 2003 14:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXOI-0002DL-NJ for sip@optimus.ietf.org; Wed, 20 Aug 2003 14:09: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 OAA26343 for ; Wed, 20 Aug 2003 14:08:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXOG-0004lp-00 for sip@ietf.org; Wed, 20 Aug 2003 14:09:00 -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 19pXOF-0004lU-00 for sip@ietf.org; Wed, 20 Aug 2003 14:08:59 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 11:08:29 -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 h7KI8RPl027497; Wed, 20 Aug 2003 11:08:27 -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 AKO94909; Wed, 20 Aug 2003 11:00:24 -0700 (PDT) Date: Wed, 20 Aug 2003 11:11:26 -0700 Subject: Re: [Sip] draft-ietf-resource-priority-01 draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mpierce1@aol.com, sip@ietf.org To: Henning Schulzrinne From: Rohan Mahy In-Reply-To: <3F391404.8000709@cs.columbia.edu> 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, August 12, 2003, at 09:21 AM, Henning Schulzrinne wrote: >> Now I'm completely confused. The -01 draft, as I noted above, >> correctly stated in 4.5 that each request is limited to one R-P >> header (which may have multiple namespaces, each with one priority >> value specified). > > Standard SIP usage is that > > Header: A, B, C > > is exactly the same as > > Header: A > Header: B > Header: C Both of these are one Header (field) with multiple header-field-values > (or obviously any other ordering) no, any other ordering is not OK. think about Via! thanks, -rohan > . See Section 7.3 in RFC 3261. > >> In the -02 version, you took out the correct statement that only one >> R-P header may be included in the request, and left in the confusing >> statement that I had pointed out. > > With that clarification, does the confusion remain? > >> Mike Pierce > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Aug 20 14:14: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 OAA26636 for ; Wed, 20 Aug 2003 14:14: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 19pXTE-0002e1-36 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KIE84R010154 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXT8-0002ZV-Gm; Wed, 20 Aug 2003 14: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 19pXSa-0002YI-S6 for sip@optimus.ietf.org; Wed, 20 Aug 2003 14:13: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 OAA26602 for ; Wed, 20 Aug 2003 14:13:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXSY-0004pZ-00 for sip@ietf.org; Wed, 20 Aug 2003 14:13: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 19pXSX-0004p1-00 for sip@ietf.org; Wed, 20 Aug 2003 14:13:25 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 11:12:55 -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 h7KICs8s012436; Wed, 20 Aug 2003 11:12:54 -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 AKO95565; Wed, 20 Aug 2003 11:04:50 -0700 (PDT) Date: Wed, 20 Aug 2003 11:15:52 -0700 Subject: Re: [Sip] Calle capabilities device ID: take 2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F3A7F6E.6030605@dynamicsoft.com> Message-Id: <5582537E-D33A-11D7-B410-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 Wednesday, August 13, 2003, at 11:11 AM, Jonathan Rosenberg wrote: > Folks, > > I posted a note on this about a month back, with no responses. This is > a big remaining open issue in callee caps and we want to resolve it. > So, please take a look and respond. > > One of the issues I raised today during the meeting was on the utility > of the uri-user and uri-domain parameters in > draft-ietf-sip-callee-caps. The primary purpose that these serve is a > means of identifying a UA instance. In order to accomplish > applicaitons like assisted call transfer, a UA would send INVITE to > the AOR of the transfer target, and include an Accept-Contact with the > uri-user and uri-domain equal to those of the UA instance. > > Now, it turns out that uri-user and uri-domain are not very helpful > when used this way. GRUU is a better approach. However, thats almost a > secondary issue. > > The primary issue is that uri-user and uri-domain are ugly, and they > repeat information already in the registration. The suggestion, made > by Paul, was to instead define a device-id attribute. This ID would be > long lived - burned into firmware of a device, perhaps. It would be > included in a registration as a unique ID for the device or software > instance, as the case may be. > > You could use this callee capability attribute for the assisted > transfer just as you could use uri-user and uri-domain. It has the > same problems that still make GRUU a better solution. However, during > the meeting, folks like the idea of a device-id attribute as something > useful for lots of other applications. I agree that a device ID would be useful for lots of things, but not for transfer. I think you really need to use a GRUU for that. This identified for me that we may all have some very different ideas about what problems we'd like to solve with a device ID. So, lets get some requirements on the list (a few sentences each). If we come to consensus on what we need a device ID for, lets include it. Otherwise, we can add the appropriate capability or capabilities later. Lots of stuff depends on callerprefs and callee-caps. Lets finish them everyone. thanks, -rohan > So, I would like to invite comment and discussion on (1) whether you > like the idea of replacing the uri-user and uri-domain attributes with > device-id (a better name may be needed, like instance-id), (2) what > kind of usages you had in mind for it, for good or for evil. > > Thanks, > Jonathan R. > -- > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 20 14: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 OAA26850 for ; Wed, 20 Aug 2003 14: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 19pXX5-00038R-M3 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KII7bx012038 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXX0-00031x-BB; Wed, 20 Aug 2003 14:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXWv-00031O-Rr for sip@optimus.ietf.org; Wed, 20 Aug 2003 14:17: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 OAA26799 for ; Wed, 20 Aug 2003 14:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXWt-0004st-00 for sip@ietf.org; Wed, 20 Aug 2003 14:17:55 -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 19pXWs-0004sT-00 for sip@ietf.org; Wed, 20 Aug 2003 14:17:54 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2003 11:25:28 -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 h7KIHNi1013554; Wed, 20 Aug 2003 11:17:23 -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 AKO96272; Wed, 20 Aug 2003 11:09:19 -0700 (PDT) Date: Wed, 20 Aug 2003 11:20:22 -0700 Subject: Re: [Sip] "the scope of the Contact is global" Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: hisham.khartabil@nokia.com From: Rohan Mahy In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796FCA@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 Hi Hisham, This is exactly why I feel that the Contact header should contain a GRUU. thanks, -rohan On Tuesday, August 19, 2003, at 03:52 PM, hisham.khartabil@nokia.com wrote: > The following text appears in RFC3261 section 8.1.1.8 > > "The Contact header field MUST be present and contain exactly one SIP > or SIPS URI in any request that can result in the establishment of a > dialog. For the methods defined in this specification, that > includes > only the INVITE request. For these requests, the scope of the > Contact is global. That is, the Contact header field value contains > the URI at which the UA would like to receive requests, and this URI > MUST be valid even if used in subsequent requests outside of any > dialogs." > > So, the scenario is: > > - I send an INVITE with contact: sip:hisham@1.2.3.4:54321 (note the > port) > - the session is now finished and I terminate the dialog > > The port that was used in contact was specified for that dialog only. > So the question is: must the URI in the contact header be valid for > subsequent requests even after the dialog is terminated? Which > consequently means that my SIP stack needs to accept requests on port > 54321 for ever? > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 20 14:35: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 OAA28910 for ; Wed, 20 Aug 2003 14:35: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 19pXnd-00047a-KT for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:35:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KIZDPW015841 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 14:35:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXnS-00046e-2D; Wed, 20 Aug 2003 14: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 19pXmz-00045v-06 for sip@optimus.ietf.org; Wed, 20 Aug 2003 14:34: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 OAA28844 for ; Wed, 20 Aug 2003 14:34:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXmw-0005FF-00 for sip@ietf.org; Wed, 20 Aug 2003 14:34:30 -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 19pXmu-0005El-00 for sip@ietf.org; Wed, 20 Aug 2003 14:34:28 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7KIXs7b016000; Wed, 20 Aug 2003 11:33:55 -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 AKO98742; Wed, 20 Aug 2003 11:25:50 -0700 (PDT) Date: Wed, 20 Aug 2003 11:36:52 -0700 Subject: Re: [Sip] Calle capabilities device ID: take 2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Cullen Jennings , sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F3CEDDD.80707@dynamicsoft.com> Message-Id: <44633520-D33D-11D7-B410-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, A lot of the uses of a device ID that I've heard so far, I have been able to get the desired effect by giving the UA (in many cases a SIP phone) a separate AOR. Not sure which requirements of other folks this solves or not since I have not seen any requirements yet. ;-) Lets say I want to identify two otherwise identical devices so I can direct SIP messages to a specific one, even if the network topology changes. I have a phone at my desk, and one in the nearby lab. For example, I'd like to send a REFER to one of them from my PC to do click-to-dial. I suggest that in addition to my AOR which is REGISTERed on each phone (sip:rohan@example.org), that each of my phones has an AOR as well. These phones should REGISTER themselves to this AOR, they can do a third-party registration when they REGISTER with my AOR, and they can use this AOR when they SUBSCRIBE to their configuration information. By default this "device" AOR can be produced using "burned-in" information such as a serial number or a mac address, but this information can be rewritten by an administrator to be an arbitrary string (with the caveat that you can always tell a burned-in derived address from a configured one so you can't cause duplicates with someone's burned-in address). sip:com.cisco.7960.sn8923173;burnedin=yes@example.org sip:com.cisco.7960.sn9213483;burnedin=yes@example.org my administrator may decide to make AORs for my phones based on location, administrative boundary or something, so that I have: sip:bldg4-floor2-cube62@example.org sip:lab3-bench12@example.org eventually my administrator might assign my phones fixed names in DNS, then the device AORs become: sip:rmahy-office-phone.example.org sip:rmahy-lab-phone.example.org I think this allows a lot of useful and interesting behavior. Whether this covers none, some, or all of the device-id requirements I do not know. thanks, -rohan On Friday, August 15, 2003, at 07:27 AM, Jonathan Rosenberg wrote: > This relates to a fundamental question we need to answer: what is the > scope of uniqueness of this ID? During the meeting, I had proposed > that it was very long lived. For a hard-phone, it was effectively > burned into firmware, and would be consistent across any reboots of > the device. > > Thats a little ill-defined for a piece of software. I suppose that it > would need to be unique for each distinct installation of the > software. A random number selected at install time, and stored on > disk, would work. It wouldnt survive a reinstall or an HD crash, but I > suspect thats fine. > > However, the question is whether this level of uniqueness is needed? > Its not for the original application that drove uri-user and > uri-domain. THis is why I'd like some use cases from folks to make > that determination. > > Here is one use case to start with: > > 1. single login: yahoo only allows one device to be registered at a > time. Feature or bug? Well, whichever it is, we'd like it to be > possible to allow this. It is possible to implement this without any > callee caps, but a device ID would make it easy to disambiguate a > registration from a device which crashed or changed its IP for some > reason, from one where a second device is registering against the same > AOR. > > This one only requires the device ID to have a long lived duration. > > -Jonathan R. > > > > Cullen Jennings wrote: > >> I think device-id is a useful idea but we do need to have a practical >> way to >> generate this instance-id for a softphone running on a PC behind a >> NAT. A >> sufficiently large random number seems like a possibility. It does >> have >> privacy concerns that make when and where it can be removed >> complicated. >> On 8/13/03 11:11 AM, "Jonathan Rosenberg" >> wrote: >>> Folks, >>> >>> I posted a note on this about a month back, with no responses. This >>> is >>> a big remaining open issue in callee caps and we want to resolve it. >>> So, please take a look and respond. >>> >>> One of the issues I raised today during the meeting was on the >>> utility >>> of the uri-user and uri-domain parameters in >>> draft-ietf-sip-callee-caps. The primary purpose that these serve is a >>> means of identifying a UA instance. In order to accomplish >>> applicaitons like assisted call transfer, a UA would send INVITE to >>> the AOR of the transfer target, and include an Accept-Contact with >>> the >>> uri-user and uri-domain equal to those of the UA instance. >>> >>> Now, it turns out that uri-user and uri-domain are not very helpful >>> when used this way. GRUU is a better approach. However, thats almost >>> a >>> secondary issue. >>> >>> The primary issue is that uri-user and uri-domain are ugly, and they >>> repeat information already in the registration. The suggestion, made >>> by Paul, was to instead define a device-id attribute. This ID would >>> be >>> long lived - burned into firmware of a device, perhaps. It would be >>> included in a registration as a unique ID for the device or software >>> instance, as the case may be. >>> >>> You could use this callee capability attribute for the assisted >>> transfer just as you could use uri-user and uri-domain. It has the >>> same problems that still make GRUU a better solution. However, during >>> the meeting, folks like the idea of a device-id attribute as >>> something >>> useful for lots of other applications. >>> >>> So, I would like to invite comment and discussion on (1) whether you >>> like the idea of replacing the uri-user and uri-domain attributes >>> with >>> device-id (a better name may be needed, like instance-id), (2) what >>> kind of usages you had in mind for it, for good or for evil. >>> >>> Thanks, >>> Jonathan R. > > -- > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 20 16:52: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 QAA10235 for ; Wed, 20 Aug 2003 16:52: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 19pZwA-0004UP-Ga for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 16:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KKqA6f017253 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 16: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 19pZw1-0004To-Rt; Wed, 20 Aug 2003 16: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 19pZvc-0004T8-46 for sip@optimus.ietf.org; Wed, 20 Aug 2003 16:51: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 QAA10185 for ; Wed, 20 Aug 2003 16:51:29 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZva-0007kY-00 for sip@ietf.org; Wed, 20 Aug 2003 16:51:34 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19pZvZ-0007kS-00 for sip@ietf.org; Wed, 20 Aug 2003 16:51:33 -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 h7KKpWB16731 for ; Wed, 20 Aug 2003 23:51: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 ; Wed, 20 Aug 2003 23:51:31 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 23:51:32 +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] "the scope of the Contact is global" Date: Wed, 20 Aug 2003 23:51:31 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796FD6@esebe019.ntc.nokia.com> Thread-Topic: [Sip] "the scope of the Contact is global" Thread-Index: AcNnR0/FMejPzARASvSZHu4ROPYZYQAFLUMg To: Cc: X-OriginalArrivalTime: 20 Aug 2003 20:51:32.0012 (UTC) FILETIME=[D5EB36C0:01C3675C] 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, the answer to my question is pending the outcome of the gruu = discussion? mmmmhh. In the mean time, should I store that contact for ever or not (for the = purpose of accepting requests outside that dialog after that dialog = terminates)? /Hisham > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, August 20, 2003 9:20 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] "the scope of the Contact is global" >=20 >=20 > Hi Hisham, >=20 > This is exactly why I feel that the Contact header should contain a=20 > GRUU. >=20 > thanks, > -rohan >=20 >=20 > On Tuesday, August 19, 2003, at 03:52 PM, hisham.khartabil@nokia.com=20 > wrote: >=20 > > The following text appears in RFC3261 section 8.1.1.8 > > > > "The Contact header field MUST be present and contain=20 > exactly one SIP > > or SIPS URI in any request that can result in the=20 > establishment of a > > dialog. For the methods defined in this specification, that=20 > > includes > > only the INVITE request. For these requests, the scope of the > > Contact is global. That is, the Contact header field=20 > value contains > > the URI at which the UA would like to receive requests,=20 > and this URI > > MUST be valid even if used in subsequent requests outside of any > > dialogs." > > > > So, the scenario is: > > > > - I send an INVITE with contact: sip:hisham@1.2.3.4:54321 (note the=20 > > port) > > - the session is now finished and I terminate the dialog > > > > The port that was used in contact was specified for that=20 > dialog only.=20 > > So the question is: must the URI in the contact header be valid for=20 > > subsequent requests even after the dialog is terminated? Which=20 > > consequently means that my SIP stack needs to accept=20 > requests on port=20 > > 54321 for ever? > > > > 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 >=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 Aug 20 18:57: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 SAA17533 for ; Wed, 20 Aug 2003 18:57: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 19pbt6-00024T-96 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 18:57:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KMv8ut007949 for sip-archive@odin.ietf.org; Wed, 20 Aug 2003 18:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbsz-00023l-5V; Wed, 20 Aug 2003 18:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbsS-00023S-JS for sip@optimus.ietf.org; Wed, 20 Aug 2003 18:56: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 SAA17510 for ; Wed, 20 Aug 2003 18:56:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pbsP-0001Nd-00 for sip@ietf.org; Wed, 20 Aug 2003 18:56: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 19pbsO-0001NO-00 for sip@ietf.org; Wed, 20 Aug 2003 18:56:24 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 15:55:55 -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 h7KMtri1014184; Wed, 20 Aug 2003 15:55:53 -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 AKP35135; Wed, 20 Aug 2003 15:47:48 -0700 (PDT) Date: Wed, 20 Aug 2003 15:58:53 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rohan@cisco.com, Dean Willis To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] should we adopt draft-jennings-sip-app-info? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Folks, Back in Vienna, we had consensus to adopt the application interaction framework and KPML as working group items in SIPPING. Allison already agreed that we can also work on extensions for application interaction in SIP (a new milestone). One thing Dean and I forgot to do at the last meeting was to ask if we should adopt the draft-jennings-sip-app-info document as a WG item to fulfill this new milestone. Please provide comments to Dean or I (or on the list). thanks, -rohan co-chair SIP and SIPPING _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 21 17:04: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 RAA00401 for ; Thu, 21 Aug 2003 17:04: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 19pwbb-0001Y9-Ly for sip-archive@odin.ietf.org; Thu, 21 Aug 2003 17:04:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LL4RgN005890 for sip-archive@odin.ietf.org; Thu, 21 Aug 2003 17:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwbC-0001V7-85; Thu, 21 Aug 2003 17:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwaf-0001RO-B4 for sip@optimus.ietf.org; Thu, 21 Aug 2003 17:03: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 RAA00323 for ; Thu, 21 Aug 2003 17:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwZW-0001lf-00 for sip@ietf.org; Thu, 21 Aug 2003 17:02:18 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19pwZV-0001lJ-00 for sip@ietf.org; Thu, 21 Aug 2003 17:02:17 -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 h7LL1JB07079; Thu, 21 Aug 2003 16:01:19 -0500 Subject: RE: [Sip] "the scope of the Contact is global" From: Robert Sparks To: Hisham Khartabil Cc: "rohan@cisco.com" , sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796FD6@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701796FD6@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1061499658.937.29.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 Aug 2003 17:00:58 -0400 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 Not. The text in 3261 was motivated by what the flow for attended transfer looked like at the time. What was intended was that the contact be valid for INVITEs coming in that might establish a new dialog ->while the original dialog still existed<-. It has never been the intent (at least it has never been _my_ intent) to force the remote-targets of dialogs to have permanence. An application should be free to create something ephemeral, destroying it as the state it is associated with is removed. GRUUs don't make this different. Being a GRUU makes no statement about being valid forever. A GRUU need be valid only as long as the application creating it needs it to be valid. One possible use of a GRUU might be to create what is effectively an AOR for a device, and such a GRUU can be arbitrarily long lived. But that does not imply _all_ GRUUs will live forever. So, to address your original question, you can delete the contact if you've created an ephemeral one for the dialog. Just be sure you are keeping the dialog state around long enough after you have sent your BYE (or other terminating message) to capture any requests the peer might have sent before it believed the dialog was terminated. RjS On Wed, 2003-08-20 at 16:51, hisham.khartabil@nokia.com wrote: > So, the answer to my question is pending the outcome of the gruu discussion? mmmmhh. > > In the mean time, should I store that contact for ever or not (for the purpose of accepting requests outside that dialog after that dialog terminates)? > > /Hisham > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Wednesday, August 20, 2003 9:20 PM > > To: Khartabil Hisham (NMP/Helsinki) > > Cc: sip@ietf.org > > Subject: Re: [Sip] "the scope of the Contact is global" > > > > > > Hi Hisham, > > > > This is exactly why I feel that the Contact header should contain a > > GRUU. > > > > thanks, > > -rohan > > > > > > On Tuesday, August 19, 2003, at 03:52 PM, hisham.khartabil@nokia.com > > wrote: > > > > > The following text appears in RFC3261 section 8.1.1.8 > > > > > > "The Contact header field MUST be present and contain > > exactly one SIP > > > or SIPS URI in any request that can result in the > > establishment of a > > > dialog. For the methods defined in this specification, that > > > includes > > > only the INVITE request. For these requests, the scope of the > > > Contact is global. That is, the Contact header field > > value contains > > > the URI at which the UA would like to receive requests, > > and this URI > > > MUST be valid even if used in subsequent requests outside of any > > > dialogs." > > > > > > So, the scenario is: > > > > > > - I send an INVITE with contact: sip:hisham@1.2.3.4:54321 (note the > > > port) > > > - the session is now finished and I terminate the dialog > > > > > > The port that was used in contact was specified for that > > dialog only. > > > So the question is: must the URI in the contact header be valid for > > > subsequent requests even after the dialog is terminated? Which > > > consequently means that my SIP stack needs to accept > > requests on port > > > 54321 for ever? > > > > > > 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 > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Aug 21 17:05: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 RAA00441 for ; Thu, 21 Aug 2003 17:05: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 19pwbb-0001Y8-Lk for sip-archive@odin.ietf.org; Thu, 21 Aug 2003 17:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LL4R9Y005892 for sip-archive@odin.ietf.org; Thu, 21 Aug 2003 17:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwbD-0001Vj-ER; Thu, 21 Aug 2003 17:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwaf-0001RU-HE for sip@optimus.ietf.org; Thu, 21 Aug 2003 17:03: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 RAA00324 for ; Thu, 21 Aug 2003 17:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwZk-0001lm-00 for sip@ietf.org; Thu, 21 Aug 2003 17:02:32 -0400 Received: from em.njupt.edu.cn ([202.119.230.11] helo=njupt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 19pwZj-0001lj-00 for sip@ietf.org; Thu, 21 Aug 2003 17:02:31 -0400 Received: (eyou send program); Thu, 21 Aug 2003 10:40:06 +0800 Received: from unknown (HELO toto) (unknown@10.10.9.9) by 202.119.230.11 with SMTP; Thu, 21 Aug 2003 10:40:06 +0800 Date: Thu, 21 Aug 2003 10:41:36 +0800 From: FengZhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 Message-Id: Content-Transfer-Encoding: base64 Subject: [Sip] what's the usage of R-URI's header part Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 SGkgYWxsLA0KDQogIEFzIHBlciB0aGUgZGVmaW5hdGlvbiBvZiBTSVAtVVJJLCBoZXJlIEkgd3Jp dGVzIG9uZToNCg0KICBzaXA6aGVsbG9AZm9vLmJhcjo1MDYwP2E9MSZiPTImYz0zDQoNCiAgQ2Fu IGFueWJvZHkgdGVsbCBtZSBvbiB3aGF0IGNpcmN1bXN0YW5jZSBzaG91bGQgSSB1c2UgdGhpcyBo ZWFkZXIgIj9hPTEmYj0yJmM9MyI/IFdoYXQncyB0aGUgbWVhbmluZyBmb3IgU0lQLVVSST8NCkkg Y2FuIG5vdCBmaW5kIHRoZSBleHBsYW5hdGlvbiBvZiBTSVAtVVJJJ3MgaGVhZGVycyBpbiBSRkMz MjYxLg0KDQogIFRoYW5rcyBhIGxvdCENCiAJCQkJDQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh oaGhRmVuZ1poYW5nDQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGheTAxMzE3QG5qdXB0LmVk dS5jbg0KoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDMtMDgtMjENCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 08:09: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 IAA19365 for ; Fri, 22 Aug 2003 08:09: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 19qAjI-00078P-QQ for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 08:09:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MC9KpB027421 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 08:09:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qAiz-00077m-7y; Fri, 22 Aug 2003 08: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 19qAih-00077P-NQ for sip@optimus.ietf.org; Fri, 22 Aug 2003 08:08: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 IAA19328; Fri, 22 Aug 2003 08:08:39 -0400 (EDT) Message-Id: <200308221208.IAA19328@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: Fri, 22 Aug 2003 08:08:39 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sip-connect-reuse-00.txt Pages : 12 Date : 2003-8-21 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-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-22082749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22082749.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 Aug 22 08:40: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 IAA20824 for ; Fri, 22 Aug 2003 08:40: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 19qBDC-0008VC-SD for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 08:40:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MCeChV032394 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 08:40:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBD2-0008Po-Jf; Fri, 22 Aug 2003 08: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 19qBCU-0008On-4O for sip@optimus.ietf.org; Fri, 22 Aug 2003 08:39: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 IAA20775 for ; Fri, 22 Aug 2003 08:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qBCS-0003JW-00 for sip@ietf.org; Fri, 22 Aug 2003 08:39:28 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19qBCS-0003JT-00 for sip@ietf.org; Fri, 22 Aug 2003 08:39:28 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 482F420661D for ; Fri, 22 Aug 2003 08:36:34 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19qAkd-0007gD-RX for ietf-announce-list@asgard.ietf.org; Fri, 22 Aug 2003 08:10:43 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19qAih-0007eA-2f for all-ietf@asgard.ietf.org; Fri, 22 Aug 2003 08:08: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 IAA19328; Fri, 22 Aug 2003 08:08:39 -0400 (EDT) Message-Id: <200308221208.IAA19328@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 22 Aug 2003 08:08:39 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+172343_7585928474579_33257659273" Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-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+172343_7585928474579_33257659273 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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sip-connect-reuse-00.txt Pages : 12 Date : 2003-8-21 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-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+172343_7585928474579_33257659273 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+297502_37392644212499_7158772004" --MIMEStream=_1+297502_37392644212499_7158772004 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22082749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-00.txt --MIMEStream=_1+297502_37392644212499_7158772004 Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22082749.I-D@ietf.org> --MIMEStream=_1+297502_37392644212499_7158772004-- --MIMEStream=_0+172343_7585928474579_33257659273-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 10:12: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 KAA26316 for ; Fri, 22 Aug 2003 10:12: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 19qCeD-0004il-8O for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10:12:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MECDMW018087 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10:12:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qCe1-0004gk-HB; Fri, 22 Aug 2003 10: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 19qCdV-0004ft-LZ for sip@optimus.ietf.org; Fri, 22 Aug 2003 10:11: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 KAA26105 for ; Fri, 22 Aug 2003 10:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qCdT-0004P9-00 for sip@ietf.org; Fri, 22 Aug 2003 10:11:27 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19qCdS-0004Oj-00 for sip@ietf.org; Fri, 22 Aug 2003 10:11:26 -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 h7MEAuB17552 for ; Fri, 22 Aug 2003 09:10:56 -0500 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1061561455.1787.9.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Aug 2003 10:10:55 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [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: , Content-Transfer-Encoding: 7bit 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? 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? 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 Aug 22 10:31: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 KAA29167 for ; Fri, 22 Aug 2003 10:31: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 19qCwZ-0005S6-C1 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10:31:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MEVBDX020954 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10:31:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qCwQ-0005R7-5S; Fri, 22 Aug 2003 10: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 19qCvd-0005P2-RA for sip@optimus.ietf.org; Fri, 22 Aug 2003 10:30: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 KAA28979 for ; Fri, 22 Aug 2003 10:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qCvb-00053z-00 for sip@ietf.org; Fri, 22 Aug 2003 10:30:11 -0400 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 19qCva-00053V-00 for sip@ietf.org; Fri, 22 Aug 2003 10:30:10 -0400 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 10:29:39 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60130AC86@COMMSERVER> From: Gordon Ledgard To: "'Robert Sparks'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 10:29:39 -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: , Hi. Robert Sparks asked.... >> -----Original Message----- >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >> Sent: Friday, August 22, 2003 10:11 AM >> To: sip@ietf.org >> Subject: [Sip] SIPIT Interop problem with ;user=phone >> 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. My take on this would be to ask a further question.. What other semantics do people expect "user=phone" to infer? Are they making some other assumptions about the device based on this parameter? If the answer is that people are using "user=phone" simply as a shortcut to conclude that the user part is a phone number to speed up parsing and look-up, then the " ;user=phone is present in a URI then the userinfo part MUST be formatted as a telephone-subscriber. " statement can stand. Having said that, this leads to a bunch of issues with PBX sorts of applications that need to map a 10 or 11 digit telephone number into a local extension, and vicey versey. The proxies, B2BUAs or, or service platforms would need to insert and yank the ;"user=phone" parameter on and off based on when the call entered or left the local domain. On top of that, these agents would need to understand the other semantics being infered by "user=phone" in order to do this properly, which may well be impossible. In that case, the language of the spec ought to be even more strict, and say " "user=phone" means that the user part is a phone number, and no other assumtions about the device can be made.." or words to that effect. Which leads to the question... why have it? Just parse it. Thoughts? Gordon R. Ledgard Principal Engineer IPeria, Inc. -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, August 22, 2003 10:11 AM To: sip@ietf.org Subject: [Sip] SIPIT Interop problem with ;user=phone 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? 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? 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 Aug 22 10:58: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 KAA01189 for ; Fri, 22 Aug 2003 10: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 19qDMf-00073G-Nu for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MEw95G027097 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 10: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 19qDMY-00072O-HT; Fri, 22 Aug 2003 10: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 19qDM0-0006yK-Ru for sip@optimus.ietf.org; Fri, 22 Aug 2003 10:57: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 KAA01094 for ; Fri, 22 Aug 2003 10:57:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDLy-0005WF-00 for sip@ietf.org; Fri, 22 Aug 2003 10:57:26 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19qDLx-0005VV-00 for sip@ietf.org; Fri, 22 Aug 2003 10:57:25 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 15:56:50 +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 Q9Z6ZZLN; Fri, 22 Aug 2003 15:56:46 +0100 From: "Conroy, Lawrence (SMTP)" To: Gordon Ledgard , "'Robert Sparks'" Cc: "'sip@ietf.org'" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1A69639B9B6AD511812B00B0D0DE19F60130AC86@COMMSERVER> References: <1A69639B9B6AD511812B00B0D0DE19F60130AC86@COMMSERVER> Date: Fri, 22 Aug 2003 15:56:45 +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: , Hi Folks, My vote's for exactly the statement that Robert proposes; "if ';user=phone' is included, then the userpart MUST be formatted as a telephone-subscriber" Note that: At 10:10 am -0400 22/8/03, Robert Sparks wrote: >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. the quoted statement is not the same as the above proposal. This proposal does *NOT* mean that any userpart that is numerical MUST have this parameter appended - it says nothing of this. I see this parameter, where present, as an assertion that the userpart can be treated as a telephone-subscriber. Any assumptions that a PBX chooses to make on what THAT implies is it's own business. The proposal doesn't mean that a PBX needs to add the parameter if it doesn't want to do this. The quoted SHOULD strength means it can dodge that one if it has good reason. [From dim recollection, wasn't this one added originally to deal with Compuserve numerical addresses vs. phone numbers? Long ago in a land far away...] In summary, I'm happy with this proposal all the best, Lawrence At 10:29 am -0400 22/8/03, Gordon Ledgard wrote: >Hi. Robert Sparks asked.... > >> 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. > > >My take on this would be to ask a further question.. What other >semantics do people expect "user=phone" to infer? Are they >making some other assumptions about the device based on this >parameter? > >If the answer is that people are using "user=phone" simply as a >shortcut to conclude that the user part is a phone number to speed >up parsing and look-up, then the > > " ;user=phone is present in a URI then the userinfo part > MUST be formatted as a telephone-subscriber. " > >statement can stand. > >Having said that, this leads to a bunch of issues with PBX sorts of >applications that need to map a 10 or 11 digit telephone number into >a local extension, and vicey versey. The proxies, B2BUAs or, or service >platforms would need to insert and yank the ;"user=phone" parameter >on and off based on when the call entered or left the local domain. >On top of that, these agents would need to understand the other >semantics being infered by "user=phone" in order to do this properly, >which may well be impossible. > >In that case, the language of the spec ought to be even more strict, >and say " "user=phone" means that the user part is a phone number, and >no other assumtions about the device can be made.." or words to that >effect. Which leads to the question... why have it? Just parse it. -- ----------------------------------------------------------------------- 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 Fri Aug 22 13:36: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 NAA09151 for ; Fri, 22 Aug 2003 13:36: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 19qFpm-0005Vp-Rj for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHaMGJ020989 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpX-0005It-QH; Fri, 22 Aug 2003 13:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qF31-0003bF-Pe for sip@optimus.ietf.org; Fri, 22 Aug 2003 12:45: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 MAA06553 for ; Fri, 22 Aug 2003 12:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qF30-0006pl-00 for sip@ietf.org; Fri, 22 Aug 2003 12:45:58 -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 19qF2z-0006pK-00 for sip@ietf.org; Fri, 22 Aug 2003 12:45:57 -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 h7MGjHvi028789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Aug 2003 11:45:18 -0500 From: "Dean Willis" To: "'Robert Sparks'" , Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 11:45:01 -0500 Message-ID: <008301c368cc$bb1d42e0$e1036e3f@txdwillis> 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, Build 10.0.4510 In-Reply-To: <1061561455.1787.9.camel@RjS.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 > 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? The problem is that the syntax of telephone-subscriber doesn't actually allow conveying all sorts of stuff that one might actually want to use a digit strings in private dialing networks that actually talk to phones. My suggestion is to deprecate user=phone entirely. It's a silly hack that, as far as I can tell, just complicates implementations and URI comparison with little actual value in return. -- 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 Aug 22 13:37: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 NAA09289 for ; Fri, 22 Aug 2003 13:37: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 19qFpm-0005Vz-Sv for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:37:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHaMok020990 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpZ-0005JS-1S; Fri, 22 Aug 2003 13:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qF3W-0003c6-Ue for sip@optimus.ietf.org; Fri, 22 Aug 2003 12:46: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 MAA06577 for ; Fri, 22 Aug 2003 12:46:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qF3U-0006qJ-00 for sip@ietf.org; Fri, 22 Aug 2003 12:46:29 -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 19qF3U-0006pm-00 for sip@ietf.org; Fri, 22 Aug 2003 12:46:28 -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 h7MGjHvj028789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Aug 2003 11:45:18 -0500 From: "Dean Willis" To: , Subject: RE: [Sip] what's the usage of R-URI's header part Date: Fri, 22 Aug 2003 11:45:01 -0500 Message-ID: <008401c368cc$d30b5c20$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 FengZhang asked: > As per the defination of SIP-URI, here I writes one: >=20 > sip:hello@foo.bar:5060?a=3D1&b=3D2&c=3D3 >=20 > Can anybody tell me on what circumstance should I use this=20 > header "?a=3D1&b=3D2&c=3D3"? What's the meaning for SIP-URI? I can=20 > not find the explanation of SIP-URI's headers in RFC3261. That's because those things on the right hand side are analogous to CGI = Get parameters from HTTP. Really, using the ? syntax is syntactically = equivalent to shoving the a=3D1 and b=3D1 and c=3D3 text into header fields in the = SIP body. There's a separate syntax for request-URI "parameters" -- they're set = off by a semicolon ";". See section 19.1.1 of RFC 3261 Headers: Header fields to be included in a request constructed from the URI. Headers fields in the SIP request can be specified with the "?" mechanism within a URI. The header names and values are encoded in ampersand separated hname =3D hvalue pairs. The special hname "body" indicates that the associated hvalue is the message-body of the SIP request. Consider the stock trading page I was just looking at: https://investing.schwab.com/trading/center?PwdMsg=3DMsg1 Nowhere in the HTTP specification is ?PwdMsg defined. It doesn't have to = be. It's essentially a variable being passed to a subroutine. The definition = of the variable, the allowable range of values, and its functional impact = on the subroutine named by the URI are defined by the writer of the = subroutine, not by the writer of the HTTP specification. All that the HTTP specs did = was define the allowable syntax that the subroutine writer could use for = passing parameters in a Request-URI. This is similar to C. Consider: int myfunc(int anumber, int anothernumber) { return(anumber + anothernumber * 11) } The standard C specification doesn't define "anumber" and = "anothernumber". Rather, it defines mechanisms by which the writers of C programs may = define them. SIP went a little further here. According to RFC 3427 "The SIP Change Process",=20 http://www.ietf.org/rfc/rfc3427.txt?number=3D3427 each SIP header is considered "a SIP Extension" and those used outside = of a very limited scoped must be defined in an appropriate RFC and registered with IANA. 3427 defines the process for "standard" headers and for a restricted header class, called "P-headers". Some people strongly = believe that this registration requirement will increase interoperability. Remember that Request URI parameters are a little different from headers encoded into the request URI, so they're not covered by 3427. The = working group has recently come to the conclusion that some specific request URI parameters are in fact widely used and constitute "reserved" words that should not be casually reused. Work is underway to add an IANA registry = and registration process. An example would be the "lr" parameter used to indicate loose routing. You may find it helpful to look at RFC3050 "Common Gateway Interface for SIP", which provides one model for developing applications that might = use parameters. http://www.ietf.org/rfc/rfc3050.txt?number=3D3050 Gee, I wonder if the IETF bothered to register the HTTP = parameter "number"? They must have, because it works with all three of my browsers = . . . -- 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 Aug 22 13: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 NAA09804 for ; Fri, 22 Aug 2003 13: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 19qFwK-0007Dr-NT for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHh88b027746 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFwE-0007D4-Mv; Fri, 22 Aug 2003 13: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 19qFw1-0007Cb-FE for sip@optimus.ietf.org; Fri, 22 Aug 2003 13:42: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 NAA09731 for ; Fri, 22 Aug 2003 13:42:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qFvz-0007V2-00 for sip@ietf.org; Fri, 22 Aug 2003 13:42:47 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19qFvy-0007Uz-00 for sip@ietf.org; Fri, 22 Aug 2003 13:42:46 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h7MHgk1N066923; Fri, 22 Aug 2003 13:42:46 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 13:49:04 -0400 Message-ID: <003801c368d5$ae7dd230$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: <1061561455.1787.9.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 > 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? RFC 2806 has inconsistent statements concerning local phone numbers. Section 2.5.2 only uses a SHOULD strength concerning adding an area-specifier to local numbers. However section 2.2 mentions that local numbers always have an area-specifier. 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 " > Should they try to interpret this as a > "number that has meaning in their > local scope"? The user=phone only indicates how to decode the user portion of the sip-uri. It has no furthur meaning. > 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? My understanding is that the user=phone only indicates how to decode the user portion of the sip-uri. Assuming that we are not going to start rejecting messages compliant with rfc3398 and reasonably compliant with rfc2806, the right thing to do is to act based upon policies associated with calling party and the request-uri. However I agree that care should be taken to avoid having non-E164 telephone-digit usernames for a hostname which also gets populated in the request-uri host of a dialed call. > 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? Many products trying to comply with rfc3398 arbitrarily add ";user=phone". > 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? It depends upon which telephone-subscriber RFC/draft interpretation is used. The telephone-subscriber definition and its SHOULDs/MUSTs significantly changes between rfc2806 and rfc2806bis-02. If "sip:1111@outbound-proxy.example.com;user=phone" is considered invalid, I object. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 13:48: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 NAA10115 for ; Fri, 22 Aug 2003 13:48: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 19qG1C-0007hk-1a for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHm9FY029556 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:48:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qG14-0007gJ-49; Fri, 22 Aug 2003 13: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 19qG0o-0007fU-3Z for sip@optimus.ietf.org; Fri, 22 Aug 2003 13:47: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 NAA10084 for ; Fri, 22 Aug 2003 13:47:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qG0l-0007ZD-00 for sip@ietf.org; Fri, 22 Aug 2003 13:47:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19qG0k-0007Z8-00 for sip@ietf.org; Fri, 22 Aug 2003 13:47:43 -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 h7MHlc31024919; Fri, 22 Aug 2003 19:47:38 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Aug 2003 19:48:17 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Stastny Richard'" , "Conroy, Lawrence (SMTP)" , Gordon Ledgard , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 19:47:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Hi, My understanding (I think it's also written in the spec) is that = telephone-describer is defined as in RFC2806 (TEL-URL spec).=20 So, IF user=3Dphone does indicate that the userpart must be according = to the telephone-subscriber syntax (as defined in RFC2806), local = numbers would need to have the phone-context parameter etc (see = separate discussion on TEL-URL and local numbers). So: sip:123@host.com;user=3Dphone ...would not be valid, but: sip:123;phone-context=3Dwhatever@host.com;user=3Dphone ...would. The userpart would have to be a "global number" (as defined = in RFC2806) not having to include the phone-context parameter. So: sip:+35891234567@host.com;user=3Dphone ...would be valid. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 22. elokuuta 2003 19:47 > To: Conroy, Lawrence (SMTP); Gordon Ledgard; Robert Sparks > Cc: sip@ietf.org > Subject: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Hi folks, > can you explain a bit more in detail to a dumb bellhead what > you mean with "telephone subsciber"? > =20 > Do you mean a subscriber number or a dialing string? > Considering the funny dialing strings invented all over the > place with access code for cross tunks like 1010 and **747.. > =20 > I would prefer > "if ';user=3Dphone' is included, then the userpart MUST be formatted=20 > (interpreted?) as a dialing string or phone number" > =20 > Any assumptions > that a "PBX" chooses to make on what THAT implies is it's own=20 > business. >=20 > Note: it is also assumed that the "PBX" may modify the userinfo >=20 > regards > Richard >=20 >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk]=20 > Gesendet: Fr 22.08.2003 16:56=20 > An: Gordon Ledgard; 'Robert Sparks'=20 > Cc: 'sip@ietf.org'=20 > Betreff: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > =09 > =09 >=20 > Hi Folks, > My vote's for exactly the statement that Robert proposes; > "if ';user=3Dphone' is included, then the userpart MUST=20 > be formatted as > a telephone-subscriber" > =09 > Note that: > At 10:10 am -0400 22/8/03, Robert Sparks wrote: > >In fact, all the specification says is > >that if the userinfo portion is formatted as a=20 > telephone-subscriber > >then the URI SHOULD also contain ;user=3Dphone. > the quoted statement is not the same as the above proposal. > =09 > This proposal does *NOT* mean that any userpart that is=20 > numerical > MUST have this parameter appended - it says nothing of this. > =09 > I see this parameter, where present, as an assertion that the > userpart can be treated as a telephone-subscriber. Any=20 > assumptions > that a PBX chooses to make on what THAT implies is it's=20 > own business. > =09 > The proposal doesn't mean that a PBX needs to add the=20 > parameter if it > doesn't want to do this. The quoted SHOULD strength=20 > means it can dodge > that one if it has good reason. > =09 > [From dim recollection, wasn't this one added originally to deal > with Compuserve numerical addresses vs. phone=20 > numbers? Long ago > in a land far away...] > =09 > In summary, I'm happy with this proposal > =09 > all the best, > Lawrence > =09 > At 10:29 am -0400 22/8/03, Gordon Ledgard wrote: > >Hi. Robert Sparks asked.... > > >> I've seen a few interoperability failures at=20 > SIPIT 13 revolving > >>> around the use of ;user=3Dphone in sip URIs. > > > >>> We have some implementations assuming that the=20 > presence of ;user=3Dphone > >>> means that the first part of the userinfo=20 > portion of the URI MUST > >>> be formatted as a telephone-subscriber. Asking=20 > around, I've found > >>> that many people believe this is the case, but > the spec does not > >>> support this claim. In fact, all the=20 > specification says is > >>> that if the userinfo portion is formatted as a=20 > telephone-subscriber > >>> then the URI SHOULD also contain ;user=3Dphone. > > > > > >My take on this would be to ask a further question.. What other > >semantics do people expect "user=3Dphone" to infer? Are they > >making some other assumptions about the device based on this > >parameter? > > > >If the answer is that people are using "user=3Dphone" simply as a > >shortcut to conclude that the user part is a phone=20 > number to speed > >up parsing and look-up, then the > > > > " ;user=3Dphone is present in a URI then the userinfo part > > MUST be formatted as a telephone-subscriber. " > > > >statement can stand. > > > >Having said that, this leads to a bunch of issues with=20 > PBX sorts of > >applications that need to map a 10 or 11 digit=20 > telephone number into > >a local extension, and vicey versey. The proxies,=20 > B2BUAs or, or service > >platforms would need to insert and yank the=20 > ;"user=3Dphone" parameter > >on and off based on when the call entered or left the=20 > local domain. > >On top of that, these agents would need to understand the other > >semantics being infered by "user=3Dphone" in order to do=20 > this properly, > >which may well be impossible. > > > >In that case, the language of the spec ought to be=20 > even more strict, > >and say " "user=3Dphone" means that the user part is a=20 > phone number, and > >no other assumtions about the device can be made.." or=20 > words to that > >effect. Which leads to the question... why have it?=20 > Just parse it. > =09 > =09 > -- > =09 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided=20 > "as is" and is not > : intended to create any=20 > contractual or legal > : relationship. > =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 > J*fj)b bm=E1=A9=B6?=0C> 0o'~ffX)t"8bX=EB=AC=B6+=1FDY=D7=AFzZ) = ayq+y"=0F>-%R.Wz{h,r=E1=AF=89ny=DB=9Fzb=CA=A2{(=CB=AB=09 > *T"=E4=A6=98'~~=E0=A0=8A{=07^hg=E1=AF=A7'=E1=AC=B6=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 Aug 22 13:57: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 NAA10472 for ; Fri, 22 Aug 2003 13:57: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 19qG9v-00085Z-FW for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHvBLR031033 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qG9l-000844-S0; Fri, 22 Aug 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qG9O-00083V-2B for sip@optimus.ietf.org; Fri, 22 Aug 2003 13:56: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 NAA10451 for ; Fri, 22 Aug 2003 13:56:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qG9L-0007g2-00 for sip@ietf.org; Fri, 22 Aug 2003 13:56:35 -0400 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 19qG9L-0007fk-00 for sip@ietf.org; Fri, 22 Aug 2003 13:56:35 -0400 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 13:56:06 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60130AC89@COMMSERVER> From: Gordon Ledgard To: "'Dean Willis'" , "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 13:56:06 -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 rather inclined to agree with Dean. I think the parameter amounts to a cheap trick for the sake of fixing what amounts to an archaic database problem... Is the user in some IP network domain, or does this call need to be forwarded to some phone network gateway? And as he points out, it does so poorly. Gordon -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 22, 2003 12:45 PM To: 'Robert Sparks'; sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > 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? The problem is that the syntax of telephone-subscriber doesn't actually allow conveying all sorts of stuff that one might actually want to use a digit strings in private dialing networks that actually talk to phones. My suggestion is to deprecate user=phone entirely. It's a silly hack that, as far as I can tell, just complicates implementations and URI comparison with little actual value in return. -- 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 Aug 22 14:06: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 OAA11029 for ; Fri, 22 Aug 2003 14:06: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 19qGIr-0000B8-99 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14:06:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MI6PLE000623 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14: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 19qGIU-0008Tg-9n; Fri, 22 Aug 2003 14: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 19qGI9-0008SI-Mn for sip@optimus.ietf.org; Fri, 22 Aug 2003 14:05: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 OAA10914 for ; Fri, 22 Aug 2003 14:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qGI2-0007kp-00 for sip@ietf.org; Fri, 22 Aug 2003 14:05:34 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19qGI1-0007kT-00 for sip@ietf.org; Fri, 22 Aug 2003 14:05:33 -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 h7MI4xlt028331; Fri, 22 Aug 2003 14:04:59 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 13:04:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86396@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Gordon Ledgard'" , "'Dean Willis'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 13:04:53 -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 agree with Dean and Gordon. The semantics of "user=phone" have always eluded me. Unless we invest considerable effort in defining the precise meaning of this parameter, it would appear that it is doing more harm than good. /a > -----Original Message----- > From: Gordon Ledgard [mailto:gledgard@iperia.com] > Sent: Friday, August 22, 2003 12:56 > To: 'Dean Willis'; 'Robert Sparks'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > I'm rather inclined to agree with Dean. > > I think the parameter amounts to a cheap trick for the sake of > fixing what amounts to an archaic database problem... Is the > user in some > IP network domain, or does this call need to be forwarded to some > phone network gateway? And as he points out, it does so poorly. > > Gordon > > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, August 22, 2003 12:45 PM > To: 'Robert Sparks'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > 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? > > The problem is that the syntax of telephone-subscriber > doesn't actually > allow conveying all sorts of stuff that one might actually > want to use a > digit strings in private dialing networks that actually talk > to phones. > > My suggestion is to deprecate user=phone entirely. It's a > silly hack that, > as far as I can tell, just complicates implementations and > URI comparison > with little actual value in return. > > -- > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 14:17: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 OAA11453 for ; Fri, 22 Aug 2003 14:17: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 19qGTJ-0000sS-1A for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MIHCku003369 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14: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 19qGT8-0000ri-7u; Fri, 22 Aug 2003 14:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qGSp-0000qR-8I for sip@optimus.ietf.org; Fri, 22 Aug 2003 14: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 OAA11406 for ; Fri, 22 Aug 2003 14:16:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qGSm-00005i-00 for sip@ietf.org; Fri, 22 Aug 2003 14:16:40 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19qGSl-00005f-00 for sip@ietf.org; Fri, 22 Aug 2003 14:16:40 -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 h7MIGA8I002889; Fri, 22 Aug 2003 14:16:11 -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 h7MIGAG30514; Fri, 22 Aug 2003 14:16:10 -0400 Message-ID: <3F465DEA.1050503@cs.columbia.edu> Date: Fri, 22 Aug 2003 14:16:10 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gordon Ledgard CC: "'Dean Willis'" , "'Robert Sparks'" , sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=phone References: <1A69639B9B6AD511812B00B0D0DE19F60130AC89@COMMSERVER> In-Reply-To: <1A69639B9B6AD511812B00B0D0DE19F60130AC89@COMMSERVER> 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 The original idea was to deal with the (rare) problem that a number could be both a local user name and a telephone number, to be handed to a gateway. Since the demise of CompuServe addresses, all-numeric user identifiers have become rare, so this original motivation seems to have faded. However, we should not look at 2806 too closely. 2806 has a fundamental flaw in that it confuses dial strings and telephone numbers as identifiers. 2806bis is supposed to clean this up; it only supports telephone numbers as identifiers. Any user string is subject to the interpretation of the domain identified by the part after the @, so it is unclear that marking it as a phone number (or dial string) helps much, except for the unlikely case mentioned above. Therefore, I suggest that there are two possibilities: (libertarian) The ;user=phone is treated as a noise word and has no semantic significance. It is strictly up to the proxy or other recipient of a request to route certain user name strings to certain places, be those named users or gateways. Anything from dial strings to 2806bis numbers are fine and not subject to standardization, but rather only local convention. This does not allow including dialing vanity phone numbers, for example, but I doubt we want to encourage sip:1-800-flowers@example.com (conservative) The ;user=X is used to proscribe the syntax and meaning of the user part, with three possibilities: a single registered user (no parameter), a dial string (would need a new designation and reference to a standard, e.g., draft-allocchio-gstn-05.txt now in the RFC editor queue) or a 2806bis string. The recipient can do a syntax check and reject 2806bis user parts that look fishy. Since a recipient can tell, by looking at the user part, whether this is a dial string or a global telephone number (global number starts with +) and by looking at the ;phone-context whether it is a local phone number (has one) or a dial string (no +, no phone-context), it is unclear that the user designation adds much value. Henning Gordon Ledgard wrote: > I'm rather inclined to agree with Dean. > > I think the parameter amounts to a cheap trick for the sake of > fixing what amounts to an archaic database problem... Is the user in some > IP network domain, or does this call need to be forwarded to some > phone network gateway? And as he points out, it does so poorly. > > Gordon > > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, August 22, 2003 12:45 PM > To: 'Robert Sparks'; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > >>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? > > > The problem is that the syntax of telephone-subscriber doesn't actually > allow conveying all sorts of stuff that one might actually want to use a > digit strings in private dialing networks that actually talk to phones. > > My suggestion is to deprecate user=phone entirely. It's a silly hack that, > as far as I can tell, just complicates implementations and URI comparison > with little actual value in return. > > -- > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 14:24: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 OAA11953 for ; Fri, 22 Aug 2003 14:24: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 19qGa4-0001KY-4v for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14:24:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MIOCur005054 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 14:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qGZu-0001Eu-72; Fri, 22 Aug 2003 14: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 19qGZD-0001EF-3D for sip@optimus.ietf.org; Fri, 22 Aug 2003 14:23: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 OAA11886 for ; Fri, 22 Aug 2003 14:23:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qGZA-0000De-00 for sip@ietf.org; Fri, 22 Aug 2003 14:23:16 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19qGZ9-0000Db-00 for sip@ietf.org; Fri, 22 Aug 2003 14:23:15 -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 h7MINA31028021; Fri, 22 Aug 2003 20:23:14 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Aug 2003 20:23:49 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Adam Roach'" , "'Gordon Ledgard'" , "'Dean Willis'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 22 Aug 2003 20:22:55 +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, No matter if we remove it or not, I still think we should have a defined way on how to send telephone numbers in SIP-URIs, not to cause interop problems with devices using them. For example, let's say that a node maps between TEL-URL and SIP-URI. The TEL-URL may contain "visual separators", which will also be inserted in the SIP-URI. Now, the node receiving the SIP-URI should also treat those a visual separators. But, without the user=phone parameter (or any other indicator), how will the receiving node know if those visual separator characters are visual separators, or valid pieces of the userpart. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 22. elokuuta 2003 21:05 > To: 'Gordon Ledgard'; 'Dean Willis'; Robert Sparks; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > I agree with Dean and Gordon. The semantics of "user=phone" > have always eluded me. Unless we invest considerable effort > in defining the precise meaning of this parameter, it would > appear that it is doing more harm than good. > > /a > > > -----Original Message----- > > From: Gordon Ledgard [mailto:gledgard@iperia.com] > > Sent: Friday, August 22, 2003 12:56 > > To: 'Dean Willis'; 'Robert Sparks'; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > I'm rather inclined to agree with Dean. > > > > I think the parameter amounts to a cheap trick for the sake of > > fixing what amounts to an archaic database problem... Is the > > user in some > > IP network domain, or does this call need to be forwarded to some > > phone network gateway? And as he points out, it does so poorly. > > > > Gordon > > > > > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Friday, August 22, 2003 12:45 PM > > To: 'Robert Sparks'; sip@ietf.org > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone > > > > > > > > > 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? > > > > The problem is that the syntax of telephone-subscriber > > doesn't actually > > allow conveying all sorts of stuff that one might actually > > want to use a > > digit strings in private dialing networks that actually talk > > to phones. > > > > My suggestion is to deprecate user=phone entirely. It's a > > silly hack that, > > as far as I can tell, just complicates implementations and > > URI comparison > > with little actual value in return. > > > > -- > > 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Aug 22 14:26: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 NAA09153 for ; Fri, 22 Aug 2003 13:36: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 19qFpm-0005Vm-Qj for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHaM7h020992 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpV-0005Hu-Sb; Fri, 22 Aug 2003 13:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qF0L-0003Xv-4g for sip@optimus.ietf.org; Fri, 22 Aug 2003 12:43: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 MAA06369 for ; Fri, 22 Aug 2003 12:43:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qF0J-0006nu-00 for sip@ietf.org; Fri, 22 Aug 2003 12:43:11 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19qF0I-0006nc-00 for sip@ietf.org; Fri, 22 Aug 2003 12:43:10 -0400 content-class: urn:content-classes:message Subject: AW: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 22 Aug 2003 18:47:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1622337CC@oefeg-s02.oefeg.loc> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNovqAOrgKv9xYdQvil591jUp2/DQADNRdF From: "Stastny Richard" To: "Conroy, Lawrence (SMTP)" , "Gordon Ledgard" , "Robert Sparks" 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 SGkgZm9sa3MsDQpjYW4geW91IGV4cGxhaW4gYSBiaXQgbW9yZSBpbiBkZXRhaWwgdG8gYSBkdW1i IGJlbGxoZWFkIHdoYXQNCnlvdSBtZWFuIHdpdGggInRlbGVwaG9uZSBzdWJzY2liZXIiPw0KIA0K RG8geW91IG1lYW4gYSBzdWJzY3JpYmVyIG51bWJlciBvciBhIGRpYWxpbmcgc3RyaW5nPw0KQ29u c2lkZXJpbmcgdGhlIGZ1bm55IGRpYWxpbmcgc3RyaW5ncyBpbnZlbnRlZCBhbGwgb3ZlciB0aGUN CnBsYWNlIHdpdGggYWNjZXNzIGNvZGUgZm9yIGNyb3NzIHR1bmtzIGxpa2UgMTAxMCBhbmQgKio3 NDcuLg0KIA0KSSB3b3VsZCBwcmVmZXINCiJpZiAnO3VzZXI9cGhvbmUnIGlzIGluY2x1ZGVkLCB0 aGVuIHRoZSB1c2VycGFydCBNVVNUIGJlIGZvcm1hdHRlZCANCihpbnRlcnByZXRlZD8pIGFzIGEg ZGlhbGluZyBzdHJpbmcgb3IgcGhvbmUgbnVtYmVyIg0KIA0KQW55IGFzc3VtcHRpb25zDQp0aGF0 IGEgIlBCWCIgY2hvb3NlcyB0byBtYWtlIG9uIHdoYXQgVEhBVCBpbXBsaWVzIGlzIGl0J3Mgb3du IGJ1c2luZXNzLg0KDQpOb3RlOiBpdCBpcyBhbHNvIGFzc3VtZWQgdGhhdCB0aGUgIlBCWCIgbWF5 IG1vZGlmeSB0aGUgdXNlcmluZm8NCg0KcmVnYXJkcw0KUmljaGFyZA0KDQoNCgktLS0tLVVyc3By w7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogQ29ucm95LCBMYXdyZW5jZSAoU01UUCkg W21haWx0bzpsd2NAcm9rZS5jby51a10gDQoJR2VzZW5kZXQ6IEZyIDIyLjA4LjIwMDMgMTY6NTYg DQoJQW46IEdvcmRvbiBMZWRnYXJkOyAnUm9iZXJ0IFNwYXJrcycgDQoJQ2M6ICdzaXBAaWV0Zi5v cmcnIA0KCUJldHJlZmY6IFJFOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCA7dXNl cj1waG9uZQ0KCQ0KCQ0KDQoJSGkgRm9sa3MsDQoJICAgIE15IHZvdGUncyBmb3IgZXhhY3RseSB0 aGUgc3RhdGVtZW50IHRoYXQgUm9iZXJ0IHByb3Bvc2VzOw0KCSJpZiAnO3VzZXI9cGhvbmUnIGlz IGluY2x1ZGVkLCB0aGVuIHRoZSB1c2VycGFydCBNVVNUIGJlIGZvcm1hdHRlZCBhcw0KCWEgdGVs ZXBob25lLXN1YnNjcmliZXIiDQoJDQoJTm90ZSB0aGF0Og0KCUF0IDEwOjEwIGFtIC0wNDAwIDIy LzgvMDMsIFJvYmVydCBTcGFya3Mgd3JvdGU6DQoJPkluIGZhY3QsIGFsbCB0aGUgc3BlY2lmaWNh dGlvbiBzYXlzIGlzDQoJPnRoYXQgaWYgdGhlIHVzZXJpbmZvIHBvcnRpb24gaXMgZm9ybWF0dGVk IGFzIGEgdGVsZXBob25lLXN1YnNjcmliZXINCgk+dGhlbiB0aGUgVVJJIFNIT1VMRCBhbHNvIGNv bnRhaW4gO3VzZXI9cGhvbmUuDQoJdGhlIHF1b3RlZCBzdGF0ZW1lbnQgaXMgbm90IHRoZSBzYW1l IGFzIHRoZSBhYm92ZSBwcm9wb3NhbC4NCgkNCglUaGlzIHByb3Bvc2FsIGRvZXMgKk5PVCogbWVh biB0aGF0IGFueSB1c2VycGFydCB0aGF0IGlzIG51bWVyaWNhbA0KCU1VU1QgaGF2ZSB0aGlzIHBh cmFtZXRlciBhcHBlbmRlZCAtIGl0IHNheXMgbm90aGluZyBvZiB0aGlzLg0KCQ0KCUkgc2VlIHRo aXMgcGFyYW1ldGVyLCB3aGVyZSBwcmVzZW50LCBhcyBhbiBhc3NlcnRpb24gdGhhdCB0aGUNCgl1 c2VycGFydCBjYW4gYmUgdHJlYXRlZCBhcyBhIHRlbGVwaG9uZS1zdWJzY3JpYmVyLiBBbnkgYXNz dW1wdGlvbnMNCgl0aGF0IGEgUEJYIGNob29zZXMgdG8gbWFrZSBvbiB3aGF0IFRIQVQgaW1wbGll cyBpcyBpdCdzIG93biBidXNpbmVzcy4NCgkNCglUaGUgcHJvcG9zYWwgZG9lc24ndCBtZWFuIHRo YXQgYSBQQlggbmVlZHMgdG8gYWRkIHRoZSBwYXJhbWV0ZXIgaWYgaXQNCglkb2Vzbid0IHdhbnQg dG8gZG8gdGhpcy4gVGhlIHF1b3RlZCBTSE9VTEQgc3RyZW5ndGggbWVhbnMgaXQgY2FuIGRvZGdl DQoJdGhhdCBvbmUgaWYgaXQgaGFzIGdvb2QgcmVhc29uLg0KCQ0KCVtGcm9tIGRpbSByZWNvbGxl Y3Rpb24sIHdhc24ndCB0aGlzIG9uZSBhZGRlZCBvcmlnaW5hbGx5IHRvIGRlYWwNCgkgIHdpdGgg Q29tcHVzZXJ2ZSBudW1lcmljYWwgYWRkcmVzc2VzIHZzLiBwaG9uZSBudW1iZXJzPyBMb25nIGFn bw0KCSAgaW4gYSBsYW5kIGZhciBhd2F5Li4uXQ0KCQ0KCUluIHN1bW1hcnksIEknbSBoYXBweSB3 aXRoIHRoaXMgcHJvcG9zYWwNCgkNCglhbGwgdGhlIGJlc3QsDQoJICAgTGF3cmVuY2UNCgkNCglB dCAxMDoyOSBhbSAtMDQwMCAyMi84LzAzLCBHb3Jkb24gTGVkZ2FyZCB3cm90ZToNCgk+SGkuIFJv YmVydCBTcGFya3MgYXNrZWQuLi4uDQoJPiAgPj4gICAgSSd2ZSBzZWVuIGEgZmV3IGludGVyb3Bl cmFiaWxpdHkgZmFpbHVyZXMgYXQgU0lQSVQgMTMgcmV2b2x2aW5nDQoJPj4+ICAgICBhcm91bmQg dGhlIHVzZSBvZiA7dXNlcj1waG9uZSBpbiBzaXAgVVJJcy4NCgk+DQoJPj4+ICAgICBXZSBoYXZl IHNvbWUgaW1wbGVtZW50YXRpb25zIGFzc3VtaW5nIHRoYXQgdGhlIHByZXNlbmNlIG9mIDt1c2Vy PXBob25lDQoJPj4+ICAgICBtZWFucyB0aGF0IHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSB1c2VyaW5m byBwb3J0aW9uIG9mIHRoZSBVUkkgTVVTVA0KCT4+PiAgICAgYmUgZm9ybWF0dGVkIGFzIGEgdGVs ZXBob25lLXN1YnNjcmliZXIuIEFza2luZyBhcm91bmQsIEkndmUgZm91bmQNCgk+Pj4gICAgIHRo YXQgbWFueSBwZW9wbGUgYmVsaWV2ZSB0aGlzIGlzIHRoZSBjYXNlLCBidXQgdGhlIHNwZWMgZG9l cyBub3QNCgk+Pj4gICAgIHN1cHBvcnQgdGhpcyBjbGFpbS4gSW4gZmFjdCwgYWxsIHRoZSBzcGVj aWZpY2F0aW9uIHNheXMgaXMNCgk+Pj4gICAgIHRoYXQgaWYgdGhlIHVzZXJpbmZvIHBvcnRpb24g aXMgZm9ybWF0dGVkIGFzIGEgdGVsZXBob25lLXN1YnNjcmliZXINCgk+Pj4gICAgIHRoZW4gdGhl IFVSSSBTSE9VTEQgYWxzbyBjb250YWluIDt1c2VyPXBob25lLg0KCT4NCgk+DQoJPk15IHRha2Ug b24gdGhpcyB3b3VsZCBiZSB0byBhc2sgYSBmdXJ0aGVyIHF1ZXN0aW9uLi4gV2hhdCBvdGhlcg0K CT5zZW1hbnRpY3MgZG8gcGVvcGxlIGV4cGVjdCAidXNlcj1waG9uZSIgdG8gaW5mZXI/IEFyZSB0 aGV5DQoJPm1ha2luZyBzb21lIG90aGVyIGFzc3VtcHRpb25zIGFib3V0IHRoZSBkZXZpY2UgYmFz ZWQgb24gdGhpcw0KCT5wYXJhbWV0ZXI/DQoJPg0KCT5JZiB0aGUgYW5zd2VyIGlzIHRoYXQgcGVv cGxlIGFyZSB1c2luZyAidXNlcj1waG9uZSIgc2ltcGx5IGFzIGENCgk+c2hvcnRjdXQgdG8gY29u Y2x1ZGUgdGhhdCB0aGUgdXNlciBwYXJ0IGlzIGEgcGhvbmUgbnVtYmVyIHRvIHNwZWVkDQoJPnVw IHBhcnNpbmcgYW5kIGxvb2stdXAsIHRoZW4gdGhlDQoJPg0KCT4gICAgICAiIDt1c2VyPXBob25l IGlzIHByZXNlbnQgaW4gYSBVUkkgdGhlbiB0aGUgdXNlcmluZm8gcGFydA0KCT4gICAgICAgIE1V U1QgYmUgZm9ybWF0dGVkIGFzIGEgdGVsZXBob25lLXN1YnNjcmliZXIuICINCgk+DQoJPnN0YXRl bWVudCBjYW4gc3RhbmQuDQoJPg0KCT5IYXZpbmcgc2FpZCB0aGF0LCB0aGlzIGxlYWRzIHRvIGEg YnVuY2ggb2YgaXNzdWVzIHdpdGggUEJYIHNvcnRzIG9mDQoJPmFwcGxpY2F0aW9ucyB0aGF0IG5l ZWQgdG8gbWFwIGEgMTAgb3IgMTEgZGlnaXQgdGVsZXBob25lIG51bWJlciBpbnRvDQoJPmEgbG9j YWwgZXh0ZW5zaW9uLCBhbmQgdmljZXkgdmVyc2V5LiBUaGUgcHJveGllcywgQjJCVUFzIG9yLCBv ciBzZXJ2aWNlDQoJPnBsYXRmb3JtcyB3b3VsZCBuZWVkIHRvIGluc2VydCBhbmQgeWFuayB0aGUg OyJ1c2VyPXBob25lIiBwYXJhbWV0ZXINCgk+b24gYW5kIG9mZiBiYXNlZCBvbiB3aGVuIHRoZSBj YWxsIGVudGVyZWQgb3IgbGVmdCB0aGUgbG9jYWwgZG9tYWluLg0KCT5PbiB0b3Agb2YgdGhhdCwg dGhlc2UgYWdlbnRzIHdvdWxkIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgb3RoZXINCgk+c2VtYW50 aWNzIGJlaW5nIGluZmVyZWQgYnkgInVzZXI9cGhvbmUiIGluIG9yZGVyIHRvIGRvIHRoaXMgcHJv cGVybHksDQoJPndoaWNoIG1heSB3ZWxsIGJlIGltcG9zc2libGUuDQoJPg0KCT5JbiB0aGF0IGNh c2UsIHRoZSBsYW5ndWFnZSBvZiB0aGUgc3BlYyBvdWdodCB0byBiZSBldmVuIG1vcmUgc3RyaWN0 LA0KCT5hbmQgc2F5ICIgInVzZXI9cGhvbmUiIG1lYW5zIHRoYXQgdGhlIHVzZXIgcGFydCBpcyBh IHBob25lIG51bWJlciwgYW5kDQoJPm5vIG90aGVyIGFzc3VtdGlvbnMgYWJvdXQgdGhlIGRldmlj ZSBjYW4gYmUgbWFkZS4uIiBvciB3b3JkcyB0byB0aGF0DQoJPmVmZmVjdC4gV2hpY2ggbGVhZHMg dG8gdGhlIHF1ZXN0aW9uLi4uIHdoeSBoYXZlIGl0PyBKdXN0IHBhcnNlIGl0Lg0KCQ0KCQ0KCS0t DQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCglSb2tlIE1hbm9yIFJlc2VhcmNoICAgIDogVGhpcyBpbmZvcm1h dGlvbiBpcyBwcm92aWRlZCAiYXMgaXMiIGFuZCBpcyBub3QNCgk8bWFpbHRvOmx3Y0Byb2tlLmNv LnVrPjogaW50ZW5kZWQgdG8gY3JlYXRlIGFueSBjb250cmFjdHVhbCBvciBsZWdhbA0KCTx0ZWw6 KzQ0MTc5NDgzMzY2Nj4gICAgOiByZWxhdGlvbnNoaXAuDQoJDQoJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTaXAgbWFpbGluZyBsaXN0ICBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCglUaGlzIGxpc3QgaXMgZm9yIE5F VyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCglVc2Ugc2lwLWltcGxlbWVu dG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCVVzZSBz aXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBv ZiBzaXANCgkNCg0K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 22 16:11: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 QAA17184 for ; Fri, 22 Aug 2003 16:11:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qIFo-0006Ge-DP for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 16:11:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MKBOfl024088 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 16:11:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qIFR-0006Fi-Qe; Fri, 22 Aug 2003 16:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qIEx-0006EK-86 for sip@optimus.ietf.org; Fri, 22 Aug 2003 16:10: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 QAA17081 for ; Fri, 22 Aug 2003 16:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qIEv-0001EO-00 for sip@ietf.org; Fri, 22 Aug 2003 16:10:29 -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 19qIEt-0001Dw-00 for sip@ietf.org; Fri, 22 Aug 2003 16:10:27 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 22 Aug 2003 13:18:45 -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 h7MK9t7b018427; Fri, 22 Aug 2003 13:09:56 -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 AHJ45456; Fri, 22 Aug 2003 13:09:54 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Aug 2003 13:09:54 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Robert Sparks , Message-ID: In-Reply-To: <1061561455.1787.9.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 More than one person has suggested that we should use tel URL (ala 2806bis not 2806) for telephone numbers, local PBX numbers, 800 etc and we should use sip for sip AORs. This clears up an incredible amount of weirdly specified comparison issues that are poorly implemented. At first glance it looks like it would cause lots of backwards compatibility problems but it might be worth looking at how bad they would be. The current situation has a lot of problems that are somewhat swept under the rug. One comment I would like to add is that in the SIP messages that flow over the wire, we do need both telephone number and SIP AOR. We do not need dialed digits instructions - the user interfaces of UA might use these but the protocol does not need them. Cullen On 8/22/03 7:10, "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? 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? > > 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 Aug 22 16:50: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 QAA19354 for ; Fri, 22 Aug 2003 16:50: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 19qIrK-0008ID-H8 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 16:50:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MKoA2N031817 for sip-archive@odin.ietf.org; Fri, 22 Aug 2003 16:50:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qIrC-0008Gl-B9; Fri, 22 Aug 2003 16:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qIqS-0008G2-AL for sip@optimus.ietf.org; Fri, 22 Aug 2003 16:49: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 QAA19307 for ; Fri, 22 Aug 2003 16:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qIqQ-0001nI-00 for sip@ietf.org; Fri, 22 Aug 2003 16:49:14 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19qIqP-0001mK-00 for sip@ietf.org; Fri, 22 Aug 2003 16:49:13 -0400 content-class: urn:content-classes:message Subject: AW: [Sip] SIPIT Interop problem with ;user=phone MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 22 Aug 2003 22:53:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1622337CE@oefeg-s02.oefeg.loc> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNo6oE/EOHljLDITvG15xi18lkgdgAAbsCQ From: "Stastny Richard" To: "Cullen Jennings" , "Robert Sparks" , 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 V2Ugc2hvdWxkIG5vdCBjb25mdXNlIHNpcDogVVJJcyB3aXRoIHRlbDogVVJJcyAoYXMgSGVubmlu ZyBzYWlkLCBpbiAyODA2YmlzIG1vZGUpLg0KIA0KSSBkaXNhZ3JlZSB3aXRoIEN1bGxlbiB0aGF0 IGRpYWwgc3RyaW5ncyBleGlzdCBvbmx5IGF0IHRoZSB1c2VyDQppbnRlcmZhY2Ugb2YgdGhlIFVB LCB0aGV5IGV4aXN0IGJldHdlZW4gdGhlIFVBIGFuZCB0aGUgc2VydmVyIGludGVycHJldGluZw0K dGhlIHNpcCBVUkkgYWxzby4NCiANCkZpcnN0LCBhIHVzZXIgb24gYW4gVUEgbGlrZSBhbiBJUCBw aG9uZSBvciBBVEEgbWF5IGJlIGFibGUgdG8gZW50ZXINCmEgZnVsbHNpcDogVVJJIGJ5IGJyZWFr aW5nIGhpcyBmaW5nZXJzLCBub3JtYWxseSBpcyBpcyBlbnRlcmluZyBhIG51bWJlciANCmxpa2Ug NTU1NTUgYW5kIHRoZSBJUCBwaG9uZSBpcyB0cmFuc2xhdGluZyBpdCB0byA1NTU1NUBmd2QucHVs dmVyLmNvbSwNCm9yIGhlIGlzIGVudGVyaW5nIHNvbWV0aGluZyBsaWtlIDEzOTM1NTU1NSBvciAq Kjc0NzY2OTEyOTEsIHdoaWNoDQppcyBub3QgdHJhbnNsYXRlZCB0byBhIHRlbDogVVJJLCBiZWNh dXNlIHRoZSBJUCBwaG9uZSBkb2VzIG5vdCBrbm93DQp0aGUgZGlhbGluZyBwbGFuIGluIHVzZSBi eSB0aGUgc2VydmVyLCBpdCBpcyBzdWJtaXR0ZWQgYXMgMTM5MzU1NTVAc2lwcGhvbmUuY29tLg0K QSBJUCBwaG9uZSBpcyBhbHNvIG5vdCBhYmxlIHRvIGRlY2lkZSBpZiBhIHNpcDogVVJJIG9yIGEg VGVsOlVSSSBzaG91bGQgYmUgdXNlZCwgb25seSB0aGUNCnNlcnZlciBjYW4gZG8gdGhpcyAoIGEg SVAgcGhvbmUgbWF5IGV2ZW4gYmUgYXR0YWNoZWQgdG8gbW9yZSB0aGVuIG9uZSBzZXJ2ZXIgYXQg YSB0aW1lKQ0KIA0KQnV0LCB3ZSBkbyBub3QgbmVlZCB1c2VyPXBob25lLCBiZWNhdXNlIGFnYWlu IHRoZSBJUCBwaG9uZSBoYXMgbm8gaWRlYSB3aGF0cyBnb2luZyBvbi4NCml0IGlzIHRoZSBzZXJ2 ZXIgd2hpY2ggZmlyc3QgbWF5IGNoZWNrIGlmIHRoaXMgdGhpbmcgaXMgYSB1c2VyIG9yIGFuIGFs aWFzLCBhbmQgaWYgbm90LCBpZiANCml0IGlzIHNvbWV0aGluZyBmaXR0aW5nIGluIGhpcyBkaWFs aW5nIHBsYW4uIFRoaXMgaXMgZG9uZSBzaW1wbHkgZnJvbSBsZWZ0IHRvIHJpZ2h0LCBsb29raW5n DQphdCB0aGUgY2hhcmFjdGVycy4gSWYgdGhlIHNlcnZlciBpcyBhYmxlIHRvIGludGVycHJldCB0 aGlzLCBpdCBtYXkgbm9ybWFsaXplIHRoaXMgdG8gc29tZXRoaW5nDQptZWFuaW5nZnVsbCAoZS5n LiAxMzkzNTU1NTVAc2lwcGhvbmUuY29tIGlzIHRyYW5zbGF0ZWQgdG8gNTU1NTVAZndkLnB1bHZl ci5jb20pLA0KIA0KKio3NDY2NjkxMjg5MSBtYXkgZXZlbiBiZSB0cmFuc2xhdGVkIG9uZSBkYXkg dG8gdGVsOisxNzQ3NjY5MTI5MSBvcg0Kc2lwOisxNzQ3NjY5MTI5MUBzaXBwaG9uZS5jb20gOy0p DQogDQpJZiB0aGUgc2VydmVyIGNhbm5vdCBwYXJzZSB0aGlzIGl0IHRlbGxzIHRoZSB1c2VyIHVu a25vd24gbnVtYmVyIG9yIHdoYXRldmVyLg0KIA0KSSBkbyBub3QgcmVhbGx5IGtub3cgd2hlcmUg dGhlIHByb2JsZW0gaXMsIGJ1dCBJIGFsc28gYWdyZWUgdGhhdCA7dXNlcj1waG9uZSBpcw0KdXNl bGVzcy4NCiANClJpY2hhcmQNCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t LS0gDQoJVm9uOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXSANCglH ZXNlbmRldDogRnIgMjIuMDguMjAwMyAyMjowOSANCglBbjogUm9iZXJ0IFNwYXJrczsgc2lwQGll dGYub3JnIA0KCUNjOiANCglCZXRyZWZmOiBSZTogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVt IHdpdGggO3VzZXI9cGhvbmUNCgkNCgkNCg0KDQoJTW9yZSB0aGFuIG9uZSBwZXJzb24gaGFzIHN1 Z2dlc3RlZCB0aGF0IHdlIHNob3VsZCB1c2UgdGVsIFVSTCAoYWxhIDI4MDZiaXMNCglub3QgMjgw NikgZm9yIHRlbGVwaG9uZSBudW1iZXJzLCBsb2NhbCBQQlggbnVtYmVycywgODAwIGV0YyBhbmQg d2Ugc2hvdWxkDQoJdXNlIHNpcCBmb3Igc2lwIEFPUnMuIFRoaXMgY2xlYXJzIHVwIGFuIGluY3Jl ZGlibGUgYW1vdW50IG9mIHdlaXJkbHkNCglzcGVjaWZpZWQgY29tcGFyaXNvbiBpc3N1ZXMgdGhh dCBhcmUgcG9vcmx5IGltcGxlbWVudGVkLiBBdCBmaXJzdCBnbGFuY2UgaXQNCglsb29rcyBsaWtl IGl0IHdvdWxkIGNhdXNlIGxvdHMgb2YgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgcHJvYmxlbXMg YnV0IGl0DQoJbWlnaHQgYmUgd29ydGggbG9va2luZyBhdCBob3cgYmFkIHRoZXkgd291bGQgYmUu IFRoZSBjdXJyZW50IHNpdHVhdGlvbiBoYXMgYQ0KCWxvdCBvZiBwcm9ibGVtcyB0aGF0IGFyZSBz b21ld2hhdCBzd2VwdCB1bmRlciB0aGUgcnVnLg0KCQ0KCU9uZSBjb21tZW50IEkgd291bGQgbGlr ZSB0byBhZGQgaXMgdGhhdCBpbiB0aGUgU0lQIG1lc3NhZ2VzIHRoYXQgZmxvdyBvdmVyDQoJdGhl IHdpcmUsIHdlIGRvIG5lZWQgYm90aCB0ZWxlcGhvbmUgbnVtYmVyIGFuZCBTSVAgQU9SLiBXZSBk byBub3QgbmVlZA0KCWRpYWxlZCBkaWdpdHMgaW5zdHJ1Y3Rpb25zIC0gdGhlIHVzZXIgaW50ZXJm YWNlcyBvZiBVQSBtaWdodCB1c2UgdGhlc2UgYnV0DQoJdGhlIHByb3RvY29sIGRvZXMgbm90IG5l ZWQgdGhlbS4NCgkNCglDdWxsZW4NCgkNCgkNCglPbiA4LzIyLzAzIDc6MTAsICJSb2JlcnQgU3Bh cmtzIiA8cnNwYXJrc0BkeW5hbWljc29mdC5jb20+IHdyb3RlOg0KCQ0KCT4gSSd2ZSBzZWVuIGEg ZmV3IGludGVyb3BlcmFiaWxpdHkgZmFpbHVyZXMgYXQgU0lQSVQgMTMgcmV2b2x2aW5nDQoJPiBh cm91bmQgdGhlIHVzZSBvZiA7dXNlcj1waG9uZSBpbiBzaXAgVVJJcy4NCgk+DQoJPiBXZSBoYXZl IHNvbWUgaW1wbGVtZW50YXRpb25zIGFzc3VtaW5nIHRoYXQgdGhlIHByZXNlbmNlIG9mIDt1c2Vy PXBob25lDQoJPiBtZWFucyB0aGF0IHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSB1c2VyaW5mbyBwb3J0 aW9uIG9mIHRoZSBVUkkgTVVTVA0KCT4gYmUgZm9ybWF0dGVkIGFzIGEgdGVsZXBob25lLXN1YnNj cmliZXIuIEFza2luZyBhcm91bmQsIEkndmUgZm91bmQNCgk+IHRoYXQgbWFueSBwZW9wbGUgYmVs aWV2ZSB0aGlzIGlzIHRoZSBjYXNlLCBidXQgdGhlIHNwZWMgZG9lcyBub3QNCgk+IHN1cHBvcnQg dGhpcyBjbGFpbS4gSW4gZmFjdCwgYWxsIHRoZSBzcGVjaWZpY2F0aW9uIHNheXMgaXMNCgk+IHRo YXQgaWYgdGhlIHVzZXJpbmZvIHBvcnRpb24gaXMgZm9ybWF0dGVkIGFzIGEgdGVsZXBob25lLXN1 YnNjcmliZXINCgk+IHRoZW4gdGhlIFVSSSBTSE9VTEQgYWxzbyBjb250YWluIDt1c2VyPXBob25l Lg0KCT4NCgk+IFNvLCBpcyB0aGlzIGFuIG92ZXJzaWdodD8gQXJlIHdlIGFsbG93aW5nIFVSSXMg d2l0aCA7dXNlcj1waG9uZQ0KCT4gYnV0IGEgbm9uIHRlbGVwaG9uZS1zdWJzY3JpYmVyIGZvcm1h dHRlZCB1c2VyaW5mbyBwYXJ0IG9uIHB1cnBvc2U/DQoJPg0KCT4gVGhvc2Ugd2l0aCBjb2RlIG1h a2luZyB0aGUgYWJvdmUgYXNzdW1wdGlvbiBmYWlsIHRvIGludGVyb3BlcmF0ZQ0KCT4gd2l0aCBk ZXZpY2VzIHRoYXQgZ2F0aGVyIGFuIGFyYml0cmFyeSBudW1iZXIgb2YgZGlnaXRzIGFuZA0KCT4g anVzdCBzbGFwIDt1c2VyPXBob25lIGluIHRoZSBVUkkgd2hlbiBjcmVhdGluZyBhIHJlcXVlc3Qu DQoJPiBGb3IgZXhhbXBsZToNCgk+DQoJPiA8c2lwOjE1QGhvc3QxLnNvbWVib2R5LnNpcGl0Lm5l dDt1c2VyPXBob25lPg0KCT4NCgk+IFRoZXkgcmVqZWN0IHRoaXMgYXMgYSBtYWxmb3JtZWQgVVJJ IHNpbmNlIDE1IGRvZXNuJ3QgcGFyc2UgcGVyDQoJPiB0ZWxlcGhvbmUtc3Vic2NyaWJlci4gSXMg dGhpcyBiZWluZyB0b28gc3RyaWN0PyBTaG91bGQgdGhleQ0KCT4gdHJ5IHRvIGludGVycHJldCB0 aGlzIGFzIGEgIm51bWJlciB0aGF0IGhhcyBtZWFuaW5nIGluIHRoZWlyDQoJPiBsb2NhbCBzY29w ZSI/IEl0IGNlcnRhaW5seSBpc24ndCBzYWZlIHRvIHByZXRlbmQgdGhlIDt1c2VyPXBob25lDQoJ PiB3YXNuJ3QgdGhlcmUgYW5kIHRyeSB0byBpbnRlcnByZXQgIjE1IiBhcyBhIHVzZXJuYW1lLiBX aGF0J3MNCgk+IHRoZSByaWdodCB0aGluZyBmb3IgdGhlbSB0byBkbz8NCgk+DQoJPiBBIGNvbXBh bmlvbiBxdWVzdGlvbiBpcyBzaG91bGQgYSBVQSBhcmJpdHJhcmlseSBoYW5nIDt1c2VyPXBob25l DQoJPiBvZmYgYSBkaWdpdCBzdHJpbmcgaXQgY29sbGVjdHMgZnJvbSBpdHMgdXNlciwgb3Igc2hv dWxkIGl0DQoJPiB0cmFuc2Zvcm0gdGhhdCBzdHJpbmcgaW50byBhIHRlbGVwaG9uZS1zdWJzY3Jp YmVyIGZvcm1hdHRlZA0KCT4gbnVtYmVyPw0KCT4NCgk+IEJvdGggcXVlc3Rpb25zIGhhdmUgY2xl YXIgYW5zd2VycyBpZiB3ZSBleHBsaWNpdGx5IGFkZCB0aGF0DQoJPiBpZiA7dXNlcj1waG9uZSBp cyBwcmVzZW50IGluIGEgVVJJIHRoZW4gdGhlIHVzZXJpbmZvIHBhcnQNCgk+IE1VU1QgYmUgZm9y bWF0dGVkIGFzIGEgdGVsZXBob25lLXN1YnNjcmliZXIuIFdvdWxkIGFueW9uZQ0KCT4gb2JqZWN0 IHRvIGFkZGluZyB0aGlzIHJlcXVpcmVtZW50Pw0KCT4NCgk+IFJqUw0KCT4NCgk+DQoJPg0KCT4N Cgk+DQoJPg0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCgk+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcA0KCT4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNv cmUgU0lQIFByb3RvY29sDQoJPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUg Zm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCT4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9y IG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCT4NCgkNCgkNCglf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNpcCBtYWls aW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCVRo aXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0K CVVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1 cnJlbnQgc2lwDQoJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24g dGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCQ0KDQo= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 23 06:23: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 GAA01123 for ; Sat, 23 Aug 2003 06:23: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 19qVY9-0007Gp-Bf for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 06:23:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7NANDjB027944 for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 06:23:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qVWz-0007Fd-Cd; Sat, 23 Aug 2003 06:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qVWU-0007Eb-AA for sip@optimus.ietf.org; Sat, 23 Aug 2003 06:21: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 GAA01064 for ; Sat, 23 Aug 2003 06:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qVWQ-0000gq-00 for sip@ietf.org; Sat, 23 Aug 2003 06:21:26 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19qVWP-0000gR-00 for sip@ietf.org; Sat, 23 Aug 2003 06:21:25 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Aug 2003 11:20:56 +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 Q9Z6ZZWN; Sat, 23 Aug 2003 11:20:40 +0100 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard , Cullen Jennings , Robert Sparks , sip@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <06CF906FE3998C4E944213062009F1622337CE@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1622337CE@oefeg-s02.oefeg.loc> Date: Sat, 23 Aug 2003 11:20:34 +0100 Subject: Re: AW: [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: , Hi Folks, OK, we have votes for and against ';user=phone', as well as votes for Robert's original clarification on the use of ';user=phone'. Christer points out that telephone-subscriber syntax may have a "gotcha" in that visual separators may be changed. IMHO the answer to that one is "Don't do it". With that rule, will deprecating the parameter make any difference? Compuserve is no longer an issue, so unless we introduce confusion in new systems, it's redundant. However, now we drift away from syntax (the original reason we had ';user=phone') and towards interpretation. As Richard points out, most existing hard phones are a pain in the fingers to triple tap out a textual sip: URI, hence we tend to use numerical userparts. These are sent over the wire as sip: URIs, however, not as tel: URIs. They are valid SIP identities, and are processed in the "standard" way. They just happen to consist of numbers. Now...if the UAC is going to send out a tel: URI, then this is different. As Henning points out, a tel: URI is more akin to a URN, and it does not have a deterministic session and IP protocol. A recipient UAS might interpret this as specifying that the UAC wants a breakout to the GSTN, or equally that they are just using this syntax for "a system that uses E.164 numbers natively", and really wanted the SIP protocol to be used for transactions (hey, it's inside a SIP message after all). However... interpretation is internal to the recipient, so it seems to me that it's not part of the protocol over the wire, but is instead part of a device specification => not this WG's problem. Personally, I'd dearly love a specification stating that '00' as the first characters of a destination string should be converted into a '+' as that's what my body memory assumes, but that's NOT a protocol issue, IMHO. It's only a matter of interpretation within an end system. Q: Whether or not a SIP UAS can process a received sip: or tel: URI without rejecting the URI type; isn't this (at most) a SIPPING issue, and only exists at all due to the ambiguity of the protocol associated (or not) with the tel: URI? Seems to me it's not a problem for the SIP WG, in the same way that interpretation of number plans or the intent of a numerical userpart is not a problem. Am I missing something? all the best, Lawrence At 10:53 pm +0200 22/8/03, Stastny Richard wrote: >We should not confuse sip: URIs with tel: URIs (as Henning said, in >2806bis mode). > >I disagree with Cullen that dial strings exist only at the user >interface of the UA, they exist between the UA and the server interpreting >the sip URI also. > >First, a user on an UA like an IP phone or ATA may be able to enter >a fullsip: URI by breaking his fingers, normally is is entering a number >like 55555 and the IP phone is translating it to 55555@fwd.pulver.com, >or he is entering something like 139355555 or **7476691291, which >is not translated to a tel: URI, because the IP phone does not know >the dialing plan in use by the server, it is submitted as >13935555@sipphone.com. >A IP phone is also not able to decide if a sip: URI or a Tel:URI >should be used, only the >server can do this ( a IP phone may even be attached to more then >one server at a time) > >But, we do not need user=phone, because again the IP phone has no >idea whats going on. >it is the server which first may check if this thing is a user or an >alias, and if not, if >it is something fitting in his dialing plan. This is done simply >from left to right, looking >at the characters. If the server is able to interpret this, it may >normalize this to something >meaningfull (e.g. 139355555@sipphone.com is translated to >55555@fwd.pulver.com), > >**74666912891 may even be translated one day to tel:+17476691291 or >sip:+17476691291@sipphone.com ;-) > >If the server cannot parse this it tells the user unknown number or whatever. > >I do not really know where the problem is, but I also agree that >;user=phone is >useless. > > >In response to Cullen's earlier: > More than one person has suggested that we should use tel URL >(ala 2806bis > not 2806) for telephone numbers, local PBX numbers, 800 etc >and we should > use sip for sip AORs. This clears up an incredible amount of weirdly > specified comparison issues that are poorly implemented. At >first glance it > looks like it would cause lots of backwards compatibility >problems but it > might be worth looking at how bad they would be. The current >situation has a > lot of problems that are somewhat swept under the rug. > > One comment I would like to add is that in the SIP messages >that flow over > the wire, we do need both telephone number and SIP AOR. We do not need > dialed digits instructions - the user interfaces of UA might >use these but > the protocol does not need them. -- ----------------------------------------------------------------------- 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 Sat Aug 23 13:41: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 NAA18798 for ; Sat, 23 Aug 2003 13:41: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 19qcO3-0006Zi-QY for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 13:41:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7NHfFGm025214 for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 13:41:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qcNq-0006Xm-5S; Sat, 23 Aug 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qcNP-0006X6-5q for sip@optimus.ietf.org; Sat, 23 Aug 2003 13:40: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 NAA18757 for ; Sat, 23 Aug 2003 13:40:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qcNM-0004SW-00 for sip@ietf.org; Sat, 23 Aug 2003 13:40:32 -0400 Received: from [192.98.100.8] (helo=lohi.tutpro.com) by ietf-mx with esmtp (Exim 4.12) id 19qcNM-0004ST-00 for sip@ietf.org; Sat, 23 Aug 2003 13:40:32 -0400 Received: from jh by lohi.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19qcN7-0004OX-00; Sat, 23 Aug 2003 20:40:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16199.42753.788321.947881@lohi.tutpro.com> Date: Sat, 23 Aug 2003 20:40:17 +0300 To: Adam Roach Cc: "'Gordon Ledgard'" , "'Dean Willis'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86396@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E86396@dyn-tx-exch-001.dynamicsoft.com> X-Mailer: VM 7.03 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 Adam Roach writes: > I agree with Dean and Gordon. The semantics of "user=phone" > have always eluded me. Unless we invest considerable effort > in defining the precise meaning of this parameter, it would > appear that it is doing more harm than good. i too am in favor of deprecating user=phone. -- 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 Sat Aug 23 22:47:55 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 WAA06741 for ; Sat, 23 Aug 2003 22:47:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkuf-00056v-Ji for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 22:47:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7O2lThm019641 for sip-archive@odin.ietf.org; Sat, 23 Aug 2003 22:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qkuD-00056L-28; Sat, 23 Aug 2003 22:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qktP-00055l-A5 for sip@optimus.ietf.org; Sat, 23 Aug 2003 22:46: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 WAA06705 for ; Sat, 23 Aug 2003 22:46:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qktL-000120-00 for sip@ietf.org; Sat, 23 Aug 2003 22:46:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19qktL-00011E-00 for sip@ietf.org; Sat, 23 Aug 2003 22:46: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 h7O2iQd8006693; Sat, 23 Aug 2003 22:44:54 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Aug 2003 21:44:26 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8639C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Conroy, Lawrence (SMTP)'" , Stastny Richard , Cullen Jennings , Robert Sparks , sip@ietf.org Subject: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Sat, 23 Aug 2003 21:44:25 -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: , Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] writes: > Personally, I'd dearly love a specification stating > that '00' as the first characters of a destination > string should be converted into a '+' as that's what > my body memory assumes, but that's NOT a protocol > issue, IMHO. It's only a matter of interpretation > within an end system. Be careful what you assume. I would be a bit confused and miffed if I dialed "00" on my SIP phone and had it converted to "tel:+". Why, you may ask, would I dial "00"? Because I want to reach my long distance operator, of course. That's what it means in the US (and possibly all of the NANP). By contrast, the NANP prefix for making international calls is "011". This should serve as a powerful cautionary tale against making any assumptions about the dialing plan that might be expected by your users. /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 Sun Aug 24 07:46: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 HAA03390 for ; Sun, 24 Aug 2003 07:46: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 19qtK8-0006j1-So for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 07:46:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OBkKTd025791 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 07:46:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qtJp-0006hK-Sk; Sun, 24 Aug 2003 07: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 19qtJY-0006go-6q for sip@optimus.ietf.org; Sun, 24 Aug 2003 07:45: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 HAA03356 for ; Sun, 24 Aug 2003 07:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qtJX-0005Vg-00 for sip@ietf.org; Sun, 24 Aug 2003 07:45:43 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19qtJW-0005VZ-00 for sip@ietf.org; Sun, 24 Aug 2003 07:45:42 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Aug 2003 12:45:10 +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 Q9Z6ZZ0M; Sun, 24 Aug 2003 12:45:07 +0100 From: "Conroy, Lawrence (SMTP)" To: Adam Roach Cc: sip@ietf.org, Richard Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8639C@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E8639C@dyn-tx-exch-001.dynamicsoft.com> Date: Sun, 24 Aug 2003 12:45:01 +0100 Subject: Re: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop 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 9:44 pm -0500 23/8/03, Adam Roach wrote: >Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] writes: > >> Personally, I'd dearly love a specification stating >> that '00' as the first characters of a destination >> string should be converted into a '+' as that's what >> my body memory assumes, but that's NOT a protocol >> issue, IMHO. It's only a matter of interpretation >> within an end system. > >Be careful what you assume. I would be a bit confused >and miffed if I dialed "00" on my SIP phone and had it >converted to "tel:+". Hi Adam, folks, Thanks, that's exactly what I meant. *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 -- ----------------------------------------------------------------------- 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 Sun Aug 24 08:14: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 IAA04087 for ; Sun, 24 Aug 2003 08:14: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 19qtl5-0007ZN-LL for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08:14:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OCEBxh029091 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08: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 19qtkv-0007Yg-Ip; Sun, 24 Aug 2003 08:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qtkX-0007Y6-LI for sip@optimus.ietf.org; Sun, 24 Aug 2003 08:13: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 IAA04057 for ; Sun, 24 Aug 2003 08:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qtkW-0005hj-00 for sip@ietf.org; Sun, 24 Aug 2003 08:13:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19qtkV-0005hY-00 for sip@ietf.org; Sun, 24 Aug 2003 08:13:36 -0400 Subject: AW: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Sun, 24 Aug 2003 14:17:50 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337D4@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-index: AcNqNd6I0aAFhmzuTQCqDkFvqa3x4QAAjh1j From: "Stastny Richard" To: "Conroy, Lawrence (SMTP)" , "Adam Roach" content-class: urn:content-classes:message 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 SGkgZm9sa3MsDQogDQo+PiAgUGVyc29uYWxseSwgSSdkIGRlYXJseSBsb3ZlIGEgc3BlY2lmaWNh dGlvbiBzdGF0aW5nDQo+PiAgdGhhdCAnMDAnIGFzIHRoZSBmaXJzdCBjaGFyYWN0ZXJzIG9mIGEg ZGVzdGluYXRpb24NCj4+ICBzdHJpbmcgc2hvdWxkIGJlIGNvbnZlcnRlZCBpbnRvIGEgJysnIGFz IHRoYXQncyB3aGF0DQo+PiAgbXkgYm9keSBtZW1vcnkgYXNzdW1lcywgYnV0IHRoYXQncyBOT1Qg YSBwcm90b2NvbA0KPj4gIGlzc3VlLCAgSU1ITy4gSXQncyBvbmx5IGEgbWF0dGVyIG9mIGludGVy cHJldGF0aW9uDQo+PiAgd2l0aGluIGFuIGVuZCBzeXN0ZW0uDQoNCkkgdGhpbmsgeW91IGdvdCB0 aGlzIHdyb25nLCBiZWNhdXNlIGl0IGlzIHByZWNpc2VseSB0aGUgb3RoZXIgd2F5IHJvdW5kOg0K IA0KSWYgeW91IGVudGVyIGEgJysnIChlLmcuIG9uIGEgbW9iaWxlIHBob25lKSwgdGhlICcrJyBp cyB0cmFuc21pdHRlZA0KaW4gdGhlIGRpYWwgc3RpbmcgdG8gdGhlIHN5c3RlbSBhbmQgY29udmVy dGVkIHRoZXJlIGluIHRoZSBpbnRlcm5hdGlvbmFsDQphY2Nlc3MgY29kZSwgd2hhdCBldmVyIHRo aXMgaXMgaW4gdGhlIG5ldHdvcmsgaW4gcXVlc3Rpb24uDQogDQpJdCBpcyBkZWZpbmV0ZWx5IE5P VCBhbiBlbmRzeXN0ZW0gaXNzdWUsIGl0IGlzIGEgbmV0d29yayBpc3N1ZS4NCiANCklmIEkgaGF2 ZSBzdG9yZWQgYSBudW1iZXIgbGlrZSAnKzQzMTk3OTgwJyBpbiBteSBtb2JpbGUgcGhvbmUNCmFu ZCByb2FtIGludG8gYSBHZXJtYW4gbmV0d29yaywgdGhlICcrJyBpcyB0cmFuc2xhdGVkIHRvICcw MCcgbGlrZQ0KaW4gQXVzdHJpYSwgaWYgSSByb2FtIHRvIHRoZSBVUyAoeWVzLCB0aGlzIGlzIHBv c3NpYmxlKSB0aGUgJysnIGlzDQp0cmFuc2xhdGVkIHRvICcwMTEnLg0KIA0KSXQgaXMgcHJvcG9z ZWQgdG8gdXNlIHRoZSBzYW1lIHByb2NlZHVyZSBpbiBWb0lQIG5ldHdvcmtzLCBlc3BlY2lhbGx5 DQppZiB5b3UgY29uc2lkZXIgZHVhbC1tb2RlIGRldmljZXMgdXNpbmcgdGhlIHNhbWUgYWRkcmVz cyBib29rLg0KIA0KbW9zdCBwZW9wbGUgaW4gRXVyb3BlIGFyZSBhbHJlYWR5IHVzZWQgdG8gc3Rv cmUgbnVtYmVycyBpbiBtb2JpbGUgcGhvbmVzDQpvbmx5IGluIHRoZSBmdWxsIGludGVybmF0aW9u YWwgZm9ybWF0LiBTaW5jZSBtb3N0IHBlb3BsZSBpbiB0aGUgVVMgYXJlIGFsc28gdXNlZA0KdG8g c3RvcmUgbnVtYmVycyBpbiBtb2JpbGUgcGhvbmVzIGluIHRoZSBmb3JtYXQgMSsxMEQgZm9ybWF0 IChlLmcuDQoxLXh4eC14eHgteHh4eCwgaXQgd291bGQgYmUgZWFzeSB0byB0ZWxsIHRoZW0ganVz dCB0byBhZGQgYSAnKycgaW4gZnJvbnQgYW5kDQppdCB3b3VsZCBhbHNvIHdvcmsgaW50ZXJuYXRp b25hbGx5Lg0KIA0KYmVzdCByZWdhcmQNClJpY2hhcmQNCiANCg0KCS0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBDb25yb3ksIExhd3JlbmNlIChTTVRQKSBbbWFpbHRv Omx3Y0Byb2tlLmNvLnVrXSANCglHZXNlbmRldDogU28gMjQuMDguMjAwMyAxMzo0NSANCglBbjog QWRhbSBSb2FjaCANCglDYzogc2lwQGlldGYub3JnOyBTdGFzdG55IFJpY2hhcmQgDQoJQmV0cmVm ZjogUmU6IFdhcm5pbmcgYWJvdXQgZGlhbCBwbGFuIGFzc3VtcHRpb25zICh3YXMgUkU6IEFXOiBb U2lwXSBTSVBJVCBJbnRlIHJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUpDQoJDQoJDQoNCglB dCA5OjQ0IHBtIC0wNTAwIDIzLzgvMDMsIEFkYW0gUm9hY2ggd3JvdGU6DQoJPkNvbnJveSwgTGF3 cmVuY2UgKFNNVFApIFttYWlsdG86bHdjQHJva2UuY28udWtdIHdyaXRlczoNCgk+DQoJPj4gIFBl cnNvbmFsbHksIEknZCBkZWFybHkgbG92ZSBhIHNwZWNpZmljYXRpb24gc3RhdGluZw0KCT4+ICB0 aGF0ICcwMCcgYXMgdGhlIGZpcnN0IGNoYXJhY3RlcnMgb2YgYSBkZXN0aW5hdGlvbg0KCT4+ICBz dHJpbmcgc2hvdWxkIGJlIGNvbnZlcnRlZCBpbnRvIGEgJysnIGFzIHRoYXQncyB3aGF0DQoJPj4g IG15IGJvZHkgbWVtb3J5IGFzc3VtZXMsIGJ1dCB0aGF0J3MgTk9UIGEgcHJvdG9jb2wNCgk+PiAg aXNzdWUsICBJTUhPLiBJdCdzIG9ubHkgYSBtYXR0ZXIgb2YgaW50ZXJwcmV0YXRpb24NCgk+PiAg d2l0aGluIGFuIGVuZCBzeXN0ZW0uDQoJPg0KCT5CZSBjYXJlZnVsIHdoYXQgeW91IGFzc3VtZS4g SSB3b3VsZCBiZSBhIGJpdCBjb25mdXNlZA0KCT5hbmQgbWlmZmVkIGlmIEkgZGlhbGVkICIwMCIg b24gbXkgU0lQIHBob25lIGFuZCBoYWQgaXQNCgk+Y29udmVydGVkIHRvICJ0ZWw6KyIuDQoJDQoJ SGkgQWRhbSwgZm9sa3MsDQoJICAgVGhhbmtzLCB0aGF0J3MgZXhhY3RseSB3aGF0IEkgbWVhbnQu DQoJDQoJKkkqIHdvdWxkIGxvdmUgc3VjaCBhIHNwZWNpZmljYXRpb24sIGJlY2F1c2UgaXQncyB3 aGF0IG15DQoJY2VsbHBob25lIGRvZXMuIFlvdSB3b3VsZG4ndCBiZWNhdXNlIHlvdSBhcmUgaW4g dGhlIE5BTlAuDQoJDQoJVGh1cyBhbnkgc3BlYyBtdXN0bid0IGJlICJvdmVyIHRoZSB3aXJlIiAt IGl0IE1VU1QgYmUgYXQNCgltb3N0IGFuIGVuZCBzeXN0ZW0gaXNzdWUuIEl0J3MgZGFuZ2Vyb3Vz IGZvciBhIFByb3h5IHRvDQoJaW50ZXJwcmV0LCBhcyB0aGUgZXhwZWN0YXRpb25zIG9mIHRoZSBl bmQgdXNlciBtYXkgZGlmZmVyLg0KCQ0KCUknZCBiZSBjb25mdXNlZCBhbmQgbWlmZmVkIGlmIEkg ZGlhbGxlZCAwMTE3IGFuZCBteSBwcm94eQ0KCWFuZCBQU1ROIGdhdGV3YXkgZ2F2ZSBtZSBhIFJ1 c3NpYW4gbnVtYmVyIHJhdGhlciB0aGFuIHRoZQ0KCUJyaXN0b2wgbnVtYmVyIEkgZXhwZWN0ZWQu IFNvLCBubyBkb3VidCwgd291bGQgdGhlIGNhbGxlZSA6KS4NCgkNCglhbGwgdGhlIGJlc3QsDQoJ ICAgTGF3cmVuY2UNCgktLQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJUm9rZSBNYW5vciBSZXNlYXJjaCAg ICA6IFRoaXMgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgImFzIGlzIiBhbmQgaXMgbm90DQoJPG1h aWx0bzpsd2NAcm9rZS5jby51az46IGludGVuZGVkIHRvIGNyZWF0ZSBhbnkgY29udHJhY3R1YWwg b3IgbGVnYWwNCgk8dGVsOis0NDE3OTQ4MzM2NjY+ICAgIDogcmVsYXRpb25zaGlwLg0KCQ0KCS0t DQoJUmVnaXN0ZXJlZCBPZmZpY2U6IFJva2UgTWFub3IgUmVzZWFyY2ggTHRkLCBTaWVtZW5zIEhv dXNlLCBPbGRidXJ5LCBCcmFja25lbGwsDQoJQmVya3NoaXJlLiBSRzEyIDhGWg0KCQ0KCVRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBp cyBjb25maWRlbnRpYWwgdG8NCglSb2tlIE1hbm9yIFJlc2VhcmNoIEx0ZCBhbmQgbXVzdCBub3Qg YmUgcGFzc2VkIHRvIGFueSB0aGlyZCBwYXJ0eSB3aXRob3V0DQoJcGVybWlzc2lvbi4gVGhpcyBj b21tdW5pY2F0aW9uIGlzIGZvciBpbmZvcm1hdGlvbiBvbmx5IGFuZCBzaGFsbCBub3QgY3JlYXRl IG9yDQoJY2hhbmdlIGFueSBjb250cmFjdHVhbCByZWxhdGlvbnNoaXAuDQoJDQoJDQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 24 08:38: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 IAA04550 for ; Sun, 24 Aug 2003 08:38: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 19qu8F-0008Pm-Le for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OCc7sX032326 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qu89-0008Oo-8v; Sun, 24 Aug 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qu7S-0008FC-Gd for sip@optimus.ietf.org; Sun, 24 Aug 2003 08:37: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 IAA04529 for ; Sun, 24 Aug 2003 08:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qu7R-0005vF-00 for sip@ietf.org; Sun, 24 Aug 2003 08:37:17 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19qu7Q-0005uG-00 for sip@ietf.org; Sun, 24 Aug 2003 08:37:16 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Aug 2003 13:36:45 +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 Q9Z6ZZ06; Sun, 24 Aug 2003 13:36:42 +0100 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard , Adam Roach Cc: sip@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <06CF906FE3998C4E944213062009F1622337D4@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1622337D4@oefeg-s02.oefeg.loc> Date: Sun, 24 Aug 2003 13:36:36 +0100 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip] Re: AW: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop 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: , (at end) At 2:17 pm +0200 24/8/03, Stastny Richard wrote: >Hi folks, > >>> Personally, I'd dearly love a specification stating >>> that '00' as the first characters of a destination >>> string should be converted into a '+' as that's what >>> my body memory assumes, but that's NOT a protocol >>> issue, IMHO. It's only a matter of interpretation >>> within an end system. > >I think you got this wrong, because it is precisely the other way round: > >If you enter a '+' (e.g. on a mobile phone), the '+' is transmitted >in the dial sting to the system and converted there in the international >access code, what ever this is in the network in question. > >It is definetely NOT an endsystem issue, it is a network issue. > >If I have stored a number like '+43197980' in my mobile phone >and roam into a German network, the '+' is translated to '00' like >in Austria, if I roam to the US (yes, this is possible) the '+' is >translated to '011'. > >It is proposed to use the same procedure in VoIP networks, especially >if you consider dual-mode devices using the same address book. > >most people in Europe are already used to store numbers in mobile phones >only in the full international format. Since most people in the US >are also used >to store numbers in mobile phones in the format 1+10D format (e.g. >1-xxx-xxx-xxxx, it would be easy to tell them just to add a '+' in front and >it would also work internationally. > >best regard >Richard > Hi Richard, folks, now I have a problem/misunderstand... If my end system takes whatever pattern of characters I dial and converts some of these into an International prefix ('+'), then the Proxy gets (say) "sip:+15551231234", not "sip:01115551231234" or "sip:0015551231234". The issue I was raising is that it's dangerous for a proxy to assume that, IF it gets "sip:01171231234", it should treat this as (or, worse, convert this to) "sip:+71231234". Likewise, IF it gets "sip:0071231234", then treating it the same is also risky. I don't think that we don't interpret userparts for "normal" SIP AoRs, so doing so for things that are digit strings is dodgy. (I'm also uncomfortable with the "type in '**92xxxxxx' to call someone on Network 92" experiments folk are running. It may well not work if my SIP phone is connected to another provider). SIP # GSTN, and my Proxy can be anywhere in the World. Of course, with 3G networks, 3G == GSTN, but that's another tragedy... At this point, we have drifted over to a network provider number plan issue, so apologies to the sip list for this. 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 Sun Aug 24 08:48: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 IAA04797 for ; Sun, 24 Aug 2003 08:48: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 19quHy-0000Jj-Df for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OCmATn001159 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 08: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 19quHp-0000I3-GQ; Sun, 24 Aug 2003 08: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 19quGt-0000HC-Jb for sip@optimus.ietf.org; Sun, 24 Aug 2003 08:47: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 IAA04746 for ; Sun, 24 Aug 2003 08:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19quGs-00062M-00 for sip@ietf.org; Sun, 24 Aug 2003 08:47:02 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19quGr-000626-00 for sip@ietf.org; Sun, 24 Aug 2003 08:47:01 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Aug 2003 13:46:31 +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 Q9Z6ZZ09; Sun, 24 Aug 2003 13:46:28 +0100 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard , Adam Roach Cc: sip@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: <06CF906FE3998C4E944213062009F1622337D4@oefeg-s02.oefeg.loc> Date: Sun, 24 Aug 2003 13:46:23 +0100 Subject: [Sip] Re: AW: Warning about dial plan assumptions 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 1:36 pm +0100 24/8/03, Conroy, Lawrence (SMTP) wrote incorrectly: > I don't think that we don't interpret I, of course, meant that I think that we don't interpret. Duh... We now return you to your regular service atb, L _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 24 09:06: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 JAA05377 for ; Sun, 24 Aug 2003 09:06: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 19quZT-0000r5-Sa for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 09:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OD6FL9003225 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 09:06:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19quZG-0000lh-Gz; Sun, 24 Aug 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 19quZ0-0000l6-E7 for sip@optimus.ietf.org; Sun, 24 Aug 2003 09:05: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 JAA05332 for ; Sun, 24 Aug 2003 09:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19quYy-0006Cz-00 for sip@ietf.org; Sun, 24 Aug 2003 09:05:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19quYy-0006CO-00 for sip@ietf.org; Sun, 24 Aug 2003 09:05:44 -0400 Subject: AW: AW: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Sun, 24 Aug 2003 15:10:00 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337D6@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: AW: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-index: AcNqPRIgWhCt09hYTy6zgQQ/QkKRxAAAiKfh From: "Stastny Richard" To: "Conroy, Lawrence (SMTP)" , "Adam Roach" content-class: urn:content-classes:message 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 IEhpIExhd3JlbmNlLA0KIA0KIA0KICA+bm93IEkgaGF2ZSBhIHByb2JsZW0vbWlzdW5kZXJzdGFu ZC4uLg0KPklmIG15IGVuZCBzeXN0ZW0gdGFrZXMgd2hhdGV2ZXIgcGF0dGVybiBvZiBjaGFyYWN0 ZXJzIEkgZGlhbCBhbmQgY29udmVydHMNCj5zb21lIG9mIHRoZXNlIGludG8gYW4gSW50ZXJuYXRp b25hbCBwcmVmaXggKCcrJyksIHRoZW4gdGhlIFByb3h5IGdldHMgKHNheSkNCj4ic2lwOisxNTU1 MTIzMTIzNCIsIG5vdCAic2lwOjAxMTE1NTUxMjMxMjM0IiBvciAic2lwOjAwMTU1NTEyMzEyMzQi Lg0KDQpBbnkgcHJveHkgbmVlZHMgdG8gaGF2ZSBhIGRpYWxpbmcgcGxhbiBkZWZpbmVkLiBjdXJy ZW50bHkgcGVvcGxlDQoNCmFyZSB1c2VkIHRvIGhhdmUgYSBsb2NhbCBkaWFsaW5nIHBsYW4gb3Ig YSBuZXR3b3JrIHNwZWNpZmljIGNsb3NlZCBkaWFsaW5nIHBsYW4NCg0KKGUuZy4gaW4gbW9iaWxl IG5ldHdvcmtzKS4gVGhlIHByb2JsZW0gbm93IGNvbWVzIGlmIHlvdSBlaXRoZXIgd2FuZGVyDQoN Cihyb2FtKSBhcm91bmQgYW5kIHVzZSBkaWZmZXJlbnQgZGlhbGluZyBwbGFucyBvciBpZiB5b3Ug YXR0YWNoIHRvDQoNCmEgc2VydmljZSBjYWxsaW5nIGl0c2VsZiAiZ2xvYmFsIiBhbmQgYXNzdW1p bmcgYSBmcmVhayAxKzEwRCBOQU5QQSBkaWFsaW5nDQoNCnBsYW4sIGJlY2F1c2UgdGhhdHMgdGhl IENhbGlmb3JuaWFuIHZpZXcgb2YgdGhlIHdvcmxkLg0KDQo+VGhlIGlzc3VlIEkgd2FzIHJhaXNp bmcgaXMgdGhhdCBpdCdzIGRhbmdlcm91cyBmb3IgYSBwcm94eSB0byBhc3N1bWUgdGhhdCwNCj5J RiBpdCBnZXRzICJzaXA6MDExNzEyMzEyMzQiLCBpdCBzaG91bGQgdHJlYXQgdGhpcyBhcyAob3Is IHdvcnNlLCBjb252ZXJ0DQo+dGhpcyB0bykgInNpcDorNzEyMzEyMzQiLiBMaWtld2lzZSwgSUYg aXQgZ2V0cyAic2lwOjAwNzEyMzEyMzQiLCB0aGVuDQo+dHJlYXRpbmcgaXQgdGhlIHNhbWUgaXMg YWxzbyByaXNreS4gSSBkb24ndCB0aGluayB0aGF0IHdlIGRvbid0IGludGVycHJldA0KPnVzZXJw YXJ0cyBmb3IgIm5vcm1hbCIgU0lQIEFvUnMsIHNvIGRvaW5nIHNvIGZvciB0aGluZ3MgdGhhdCBh cmUgZGlnaXQgc3RyaW5ncw0KPmlzIGRvZGd5Lg0KDQpJdCBpcyBhbGwgZGVwZW5kaW5nIHdoYXQg eW91IGRlZmluZS4geW91IGNvdWxkIGV2ZW4gYWxsb3cgMDAgYW5kIDAxMSBpbg0KcGFyYWxsZWws IGlmIHlvdSBkbyBub3QgYWxsb3cgbG9jYWwgYWNjZXNzLiAgSWYgeW91IGhhdmUgbG9jYWwgYWNj ZXNzLCB5b3Ugc2hvdWxkDQpvbmx5IGFsbG93IHRoZSBpbnRlcm5hdGlvbmFsIGFjY2VzcyBjb2Rl IGZpdHRpbmcgdG8gdGhpcyBhY2Nlc3MuIFRoaXMNCmlzIHdoeSBJIHdvdWxkIHByZWZlciB0aGUg dXNhZ2Ugb2YgJysnIG9ubHksIGVzY3BlY2lhbGx5IGlmIHlvdSB1c2UgDQpzdG9yZWQgbnVtZWJy cy4NCg0KPihJJ20gYWxzbyB1bmNvbWZvcnRhYmxlIHdpdGggdGhlICJ0eXBlIGluICcqKjkyeHh4 eHh4JyB0byBjYWxsIHNvbWVvbmUNCj5vbiBOZXR3b3JrIDkyIiBleHBlcmltZW50cyBmb2xrIGFy ZSBydW5uaW5nLiBJdCBtYXkgd2VsbCBub3Qgd29yayBpZiBteQ0KPlNJUCBwaG9uZSBpcyBjb25u ZWN0ZWQgdG8gYW5vdGhlciBwcm92aWRlcikuDQogDQpSaWNoYXJkDQogDQpJIGFncmVlIHNvbWV3 aGF0LCBidXIgcGVvcGxlIHNlZW0gdG8gbGlrZSBpdC4gSU1ITyBpdCB3aWxsIGdvIGF3YXkNCmFm dGVyIHNvbWUgdGltZSBhbnl3YXkNCg0KU0lQICMgR1NUTiwgYW5kIG15IFByb3h5IGNhbiBiZSBh bnl3aGVyZSBpbiB0aGUgV29ybGQuDQpPZiBjb3Vyc2UsIHdpdGggM0cgbmV0d29ya3MsIDNHID09 IEdTVE4sIGJ1dCB0aGF0J3MgYW5vdGhlciB0cmFnZWR5Li4uDQoNCkF0IHRoaXMgcG9pbnQsIHdl IGhhdmUgZHJpZnRlZCBvdmVyIHRvIGEgbmV0d29yayBwcm92aWRlciBudW1iZXIgcGxhbiBpc3N1 ZSwNCnNvIGFwb2xvZ2llcyB0byB0aGUgc2lwIGxpc3QgZm9yIHRoaXMuDQoNCmFsbCB0aGUgYmVz dCwNCiAgIExhd3JlbmNlDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9rZSBNYW5vciBSZXNlYXJj aCAgICA6IFRoaXMgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgImFzIGlzIiBhbmQgaXMgbm90DQo8 bWFpbHRvOmx3Y0Byb2tlLmNvLnVrPjogaW50ZW5kZWQgdG8gY3JlYXRlIGFueSBjb250cmFjdHVh bCBvciBsZWdhbA0KPHRlbDorNDQxNzk0ODMzNjY2PiAgICA6IHJlbGF0aW9uc2hpcC4NCg0KLS0N ClJlZ2lzdGVyZWQgT2ZmaWNlOiBSb2tlIE1hbm9yIFJlc2VhcmNoIEx0ZCwgU2llbWVucyBIb3Vz ZSwgT2xkYnVyeSwgQnJhY2tuZWxsLA0KQmVya3NoaXJlLiBSRzEyIDhGWg0KDQpUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29u ZmlkZW50aWFsIHRvDQpSb2tlIE1hbm9yIFJlc2VhcmNoIEx0ZCBhbmQgbXVzdCBub3QgYmUgcGFz c2VkIHRvIGFueSB0aGlyZCBwYXJ0eSB3aXRob3V0DQpwZXJtaXNzaW9uLiBUaGlzIGNvbW11bmlj YXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBjcmVhdGUgb3INCmNo YW5nZSBhbnkgY29udHJhY3R1YWwgcmVsYXRpb25zaGlwLg0KDQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 24 10:53: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 KAA09017 for ; Sun, 24 Aug 2003 10:53: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 19qwF0-0003ms-Aw for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 10:53:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OErECo014500 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 10:53:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qwEo-0003ko-7V; Sun, 24 Aug 2003 10: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 19qwDv-0003kL-C0 for sip@optimus.ietf.org; Sun, 24 Aug 2003 10: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 KAA08963 for ; Sun, 24 Aug 2003 10:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qwDs-0007GN-00 for sip@ietf.org; Sun, 24 Aug 2003 10:52:04 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19qwDs-0007GJ-00 for sip@ietf.org; Sun, 24 Aug 2003 10:52:04 -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 h7OEpu8I015335; Sun, 24 Aug 2003 10:51:56 -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 h7OEpWG03499; Sun, 24 Aug 2003 10:51:32 -0400 Message-ID: <3F48D0F3.1040607@cs.columbia.edu> Date: Sun, 24 Aug 2003 10:51:31 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 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) References: <9BF66EBF6BEFD942915B4D4D45C051F3E8639C@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: 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 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 From exim@www1.ietf.org Sun Aug 24 11:20: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 LAA09775 for ; Sun, 24 Aug 2003 11:20: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 19qwf5-0004id-4G for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 11:20:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OFKA7X018091 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 11:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qwey-0004hC-Qg; Sun, 24 Aug 2003 11: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 19qwer-0004gN-SZ for sip@optimus.ietf.org; Sun, 24 Aug 2003 11:19: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 LAA09746 for ; Sun, 24 Aug 2003 11:19:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qwer-0007VC-00 for sip@ietf.org; Sun, 24 Aug 2003 11:19:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19qweq-0007V1-00 for sip@ietf.org; Sun, 24 Aug 2003 11:19:56 -0400 Subject: AW: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Date: Sun, 24 Aug 2003 17:24:12 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337D8@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Thread-index: AcNqT/RmULiBJ7zqSV2uejT+YG2wfgAAa8fq From: "Stastny Richard" content-class: urn:content-classes:message To: "Henning Schulzrinne" , "Conroy, Lawrence (SMTP)" Cc: "Adam Roach" , 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 SUYgaXQgd291bGQgYmUganVzdCB0aGUgdHJhbnNsYXRpb24gZnJvbSBhIGxvY2FsIGRpYWwgcGxh biB0bw0KYSBnbG9iYWwgaWRlbnRpZmllciAoPSBFLjE2NCBudW1iZXIpIHRoZW4gdGhpcyBpcyBq dXN0IGEgc2ltcGxlDQpzY3JpcHQgeW91IGNvdWxkIGVpdGhlciBydW4gYXQgdGhlIHNlcnZlciAo VUFTKSBvciBhdCB0aGUgY2xpZW50IChVQUMpLg0KIA0KVGhpcyB3b3VsZCByZXF1aXJlIHRoYXQg YWxsIHNlcnZlcnMgYXJlIGFibGUgdG8gaGFuZGxlIEUuMTY0LCB3aGljaA0KSSB3b3VsZCBwcmVm ZXIgYW55d2F5LiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgSSBsb29rIGF0IHRoZSBjdXJyZW50DQpp bXBsZW1lbnRhdGlvbnMgbW9zdCBvZiB0aGVtIGFyZSBub3QgY29uZmlndXJlZCBpbiB0aGlzIHdh eS4gU2luY2UNCnRoZSBzY3JpcHQgaW4gdGhlIGNsaWVudCBzaG91bGQgYmUgZ2VuZXJpYywgY29u c2lkZXJpbmcgcm9hbWluZyBhbmQNCnRoZSBwb3NzaWJpbGl0eSB0byBhdHRhY2ggdG8gbW9yZSB0 aGVuIG9uZSBzZXJ2ZXIgKGVnIGxpa2UgdGhlIENpc2NvDQpwaG9uZXMpIGl0IHNob3VsZCB0cmFu c2xhdGUgYWxzbyB0aGUgIm93biIgbG9jYWwgbnVtYmVyIHRvIEUuMTY0Lg0KIA0KSXQgd291bGQg YmUgZWFzeSBmb3Igc2VydmVycyB0byByZXRyYW5zbGF0ZSB0aGlzIHRvIGxvY2FsIG51bWJlcnMs DQpQUk9WSURFRCBBIEUuMTY0IE5VTUJFUiBmb3IgdGhlIElUQUQgRVhJU1RTLiBTaW5jZQ0KdGhp cyBpcyBOT1QgdGhlIGNhc2UgaW4gbW9zdCBpbXBsZW1lbnRhdGlvbnMgdGhlIGdlbmVyaWMgYXBw cm9hY2gNCndvdWxkIG5vdCB3b3JrICh3ZSBhcmUgd29ya2luZyBvbiB0aGlzIG9uZSB0b28gOy0p DQpCVFcsIGluIHRoaXMgY2FzZSB0aGUgY2xpZW50IGNvdWxkIGFsc28gcXVlcnkgRU5VTQ0KZGly ZWN0bHkgYW5kIHN1Ym1pdCB0aGUgc2lwOiBVUkkgZGlyZWN0bHksIHNhdmluZyB0aGUgc2VydmVy IHRoaXMgZWZmb3J0Lg0KIA0KSSBhbSBhbHNvIGN1cnJlbnRseSB3b3JraW5nIG9uIGEgcGFwZXIg b24gbnVtYmVyaW5nIGFuZCBkaWFsaW5nIHBsYW5zDQpmb3IgVm9JUCwgbWF5YmUgd2UgY291bGQg am9pbiBvciBlZmZvcnRzIDstKQ0KIA0KYmVzdCByZWdhcmRzDQpSaWNoYXJkDQoNCgktLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogSGVubmluZyBTY2h1bHpyaW5uZSBb bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHVdIA0KCUdlc2VuZGV0OiBTbyAyNC4wOC4yMDAzIDE2 OjUxIA0KCUFuOiBDb25yb3ksIExhd3JlbmNlIChTTVRQKSANCglDYzogQWRhbSBSb2FjaDsgc2lw QGlldGYub3JnOyBTdGFzdG55IFJpY2hhcmQgDQoJQmV0cmVmZjogUmU6IFdhcm5pbmcgYWJvdXQg ZGlhbCBwbGFuIGFzc3VtcHRpb25zICh3YXMgUkU6IEFXOiBbU2lwXSBTSVBJVCBJbnRlIHJvcCBw cm9ibGVtIHdpdGggO3VzZXI9cGhvbmUpDQoJDQoJDQoNCglJbiBhbiBlYXJsaWVyIGl0ZXJhdGlv biBvZiB0aGlzIGRpc2N1c3Npb24gaW4gdGhlIElQVEVMIFdHLCB0aGVyZSB3YXMNCglzb21lIGNv bnNlbnN1cyB0aGF0IHRoZSBhcHByb3ByaWF0ZSB3YXkgaXMgdG8gZG93bmxvYWQgYSBkaWFscGxh biBpbnRvDQoJdGhlIGVuZCBzeXN0ZW0sIHdoaWNoIHRoZW4gZG9lcyB0aGUgdHJhbnNsYXRpb24g ZnJvbSBkaWFsZWQgZGlnaXRzIHRvIGENCglnbG9iYWwgaWRlbnRpZmllci4gVGhhdCB3YXksIGl0 IGRvZXNuJ3QgbWF0dGVyIHdoZXJlIHRoZSBTSVAgb3IgdGVsIFVSSQ0KCWVuZHMgdXAgYW5kIHJl bW92ZXMgdGhlIHdoZXJlLXdhcy10aGlzLW51bWJlci1kaWFsZWQgZ3Vlc3NpbmcgYnkgdGhlDQoJ b3V0Ym91bmQgcHJveHkuIFRoaXMgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGdlbmVyYWwgY29uZmln dXJhdGlvbg0KCW1lY2hhbmlzbS4gSSBoYWQgdm9sdW50ZWVyZWQgdG8gd3JpdGUgdXAgYSBzcGVj IGZvciB0aGF0LCBidXQgSSdtDQoJd2FpdGluZyBmb3IgdGhlIGdlbmVyYWwgc2hhcGUgb2YgdGhl IGNvbmZpZ3VyYXRpb24gZGF0YSBmb3JtYXQgdG8gc2V0dGxlLg0KCQ0KCUNvbnJveSwgTGF3cmVu Y2UgKFNNVFApIHdyb3RlOg0KCQ0KCQ0KCT4gKkkqIHdvdWxkIGxvdmUgc3VjaCBhIHNwZWNpZmlj YXRpb24sIGJlY2F1c2UgaXQncyB3aGF0IG15DQoJPiBjZWxscGhvbmUgZG9lcy4gWW91IHdvdWxk bid0IGJlY2F1c2UgeW91IGFyZSBpbiB0aGUgTkFOUC4NCgk+DQoJPiBUaHVzIGFueSBzcGVjIG11 c3RuJ3QgYmUgIm92ZXIgdGhlIHdpcmUiIC0gaXQgTVVTVCBiZSBhdA0KCT4gbW9zdCBhbiBlbmQg c3lzdGVtIGlzc3VlLiBJdCdzIGRhbmdlcm91cyBmb3IgYSBQcm94eSB0bw0KCT4gaW50ZXJwcmV0 LCBhcyB0aGUgZXhwZWN0YXRpb25zIG9mIHRoZSBlbmQgdXNlciBtYXkgZGlmZmVyLg0KCT4NCgk+ IEknZCBiZSBjb25mdXNlZCBhbmQgbWlmZmVkIGlmIEkgZGlhbGxlZCAwMTE3IGFuZCBteSBwcm94 eQ0KCT4gYW5kIFBTVE4gZ2F0ZXdheSBnYXZlIG1lIGEgUnVzc2lhbiBudW1iZXIgcmF0aGVyIHRo YW4gdGhlDQoJPiBCcmlzdG9sIG51bWJlciBJIGV4cGVjdGVkLiBTbywgbm8gZG91YnQsIHdvdWxk IHRoZSBjYWxsZWUgOikuDQoJPg0KCT4gYWxsIHRoZSBiZXN0LA0KCT4gICBMYXdyZW5jZQ0KCQ0K 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 Sun Aug 24 11:25: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 LAA09970 for ; Sun, 24 Aug 2003 11:25: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 19qwjr-0004yt-3p for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 11:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OFP7oH019122 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 11:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qwjn-0004xy-MF; Sun, 24 Aug 2003 11: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 19qwjX-0004xR-Fi for sip@optimus.ietf.org; Sun, 24 Aug 2003 11:24: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 LAA09952 for ; Sun, 24 Aug 2003 11:24:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qwjW-0007Yy-00 for sip@ietf.org; Sun, 24 Aug 2003 11:24: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 19qwjV-0007Ys-00 for sip@ietf.org; Sun, 24 Aug 2003 11:24:45 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7OFOA7b013494; Sun, 24 Aug 2003 08:24:10 -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 AKS59207; Sun, 24 Aug 2003 08:15:33 -0700 (PDT) Date: Sun, 24 Aug 2003 08:27:15 -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: Robert Sparks , To: Cullen Jennings From: Rohan Mahy In-Reply-To: Message-Id: <70D76F06-D647-11D7-A872-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 Folks, To tie Cullen's comments more concretely to the discussion, I have always interpreted the semantics of ;user=phone to mean that the user part has been converted from a tel URL but that someone wants this tel URL to be handled in the context of a particular SIP domain. If a SIP UA just collects a string of digits "1234" (this is not a tel URL), slaps on the domain name of their proxy, and then sends these digits there without interpretation, then you just end up with an ordinary SIP URI (user=ip): sip:1234@mylocalproxy.example.com however, I think it is much more useful for the UA to generate a tel URL here instead: tel:1234;phone-context=+14085551111 Note that both of these are correctly scoped. tel:1234 is illegal, as should be sip:1234@mylocalproxy.example.com;user=phone (IMO). Why not deprecate ;user=phone entirely? Aside from backwards compatibility, there is actually a very good reason. Since tel: URIs don't have a domain portion, there is no way for me to send a tel URL through a loose-routed service and still convey which domain I would like the tel URI to be handled in. So lets say that I send this INVITE INVITE tel:+14085268570 SIP/2.0 Route: ... transcoders.org will either reject the request or send it to whatever PSTN gateway it feels like using. I would like to the INVITE to go to a specific provider out of a list of several of these, but I do not want to negotiate the specific user-part naming convention with each one: INVITE sip:+14085268570@provider1.com;user=phone SIP/2.0 Route: Likewise I can use SIPS to go to a different provider: INVITE sips:+14085268570@provider2.net;user=phone SIP/2.0 Continuing on in this vein, say I REFER Jiri (in Europe) to call Adam's cell phone (in Texas). It would be much nicer to provide this Refer-To URI: sips:+19991234567@dfw-gw.dynamicsoft.com;user=phone (a tel URL addressed to a particular SIP UA) instead of: tel:+19991234567 (since Jiri may need to discover such a gateway, or be billed for an International PSTN call when he has a perfectly good Internet he can use instead for the "expensive" part of the call). So, I think the ;user=phone is in fact very useful (even if only as a standardized convention). If it is used at all I think the user part MUST be a valid global-number or local-number with ;phone-context paramter, if user=phone is in the SIP URI. thanks, -rohan On Friday, August 22, 2003, at 01:09 PM, Cullen Jennings wrote: > > More than one person has suggested that we should use tel URL (ala > 2806bis > not 2806) for telephone numbers, local PBX numbers, 800 etc and we > should > use sip for sip AORs. This clears up an incredible amount of weirdly > specified comparison issues that are poorly implemented. At first > glance it > looks like it would cause lots of backwards compatibility problems but > it > might be worth looking at how bad they would be. The current situation > has a > lot of problems that are somewhat swept under the rug. > > One comment I would like to add is that in the SIP messages that flow > over > the wire, we do need both telephone number and SIP AOR. We do not need > dialed digits instructions - the user interfaces of UA might use these > but > the protocol does not need them. > > Cullen > > > On 8/22/03 7:10, "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? 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? >> >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 24 14:01:04 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 OAA15496 for ; Sun, 24 Aug 2003 14:01: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 19qzAN-0000e2-Gu for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 14:00:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OI0d3u002472 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 14:00:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qz9p-0000ca-AF; Sun, 24 Aug 2003 14:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qz98-0000bb-9C for sip@optimus.ietf.org; Sun, 24 Aug 2003 13:59: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 NAA15327 for ; Sun, 24 Aug 2003 13:59:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qz95-00014u-00 for sip@ietf.org; Sun, 24 Aug 2003 13:59:20 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19qz95-00014Q-00 for sip@ietf.org; Sun, 24 Aug 2003 13:59:19 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7OHmOYA027411 for ; Sun, 24 Aug 2003 13:58:49 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA004928E2; Sun, 24 Aug 2003 13:57:39 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Sun, 24 Aug 2003 13:58:47 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04B8C454@ACCLUST02EVS1.ugd.att.com> Thread-Topic: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Thread-Index: AcNqT/RmULiBJ7zqSV2uejT+YG2wfgAAa8fqAAXb6hA= From: "Roy, Radhika R, ALABS" To: "Stastny Richard" , "Henning Schulzrinne" , "Conroy, Lawrence (SMTP)" Cc: "Adam Roach" , 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 SW5saW5lIFtSUlJdDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGFzdG55 IFJpY2hhcmQgW21haWx0bzpSaWNoYXJkLlN0YXN0bnlAb2VmZWcuYXRdDQpTZW50OiBTdW5kYXks IEF1Z3VzdCAyNCwgMjAwMyAxMToyNCBBTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmU7IENvbnJv eSwgTGF3cmVuY2UgKFNNVFApDQpDYzogQWRhbSBSb2FjaDsgc2lwQGlldGYub3JnDQpTdWJqZWN0 OiBBVzogV2FybmluZyBhYm91dCBkaWFsIHBsYW4gYXNzdW1wdGlvbnMgKHdhcyBSRTogQVc6IFtT aXBdDQpTSVBJVCBJbnRlIHJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUpDQoNCi4uLi4NCg0K QlRXLCBpbiB0aGlzIGNhc2UgdGhlIGNsaWVudCBjb3VsZCBhbHNvIHF1ZXJ5IEVOVU0NCmRpcmVj dGx5IGFuZCBzdWJtaXQgdGhlIHNpcDogVVJJIGRpcmVjdGx5LCBzYXZpbmcgdGhlIHNlcnZlciB0 aGlzIGVmZm9ydC4NCg0KW1JSUl0gSSB0aGluayB0aGF0IHRoaXMgdGhlIHJpZ2h0IGFwcHJvYWNo IChJIGhhdmUgYWxzbyBiZWVuIHRoaW5raW5nIGFsb25nIHRoaXMgbGluZSkuDQogDQouLi4uDQog DQpiZXN0IHJlZ2FyZHMNClJpY2hhcmQNCg0KCQ0K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 24 14:13: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 OAA16013 for ; Sun, 24 Aug 2003 14:13: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 19qzMR-0001Mz-JU for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 14:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OID7fw005236 for sip-archive@odin.ietf.org; Sun, 24 Aug 2003 14:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qzMM-0001Lv-5J; Sun, 24 Aug 2003 14:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qzMH-0001LI-GQ for sip@optimus.ietf.org; Sun, 24 Aug 2003 14:12: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 OAA15992 for ; Sun, 24 Aug 2003 14:12:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qzMF-0001FH-00 for sip@ietf.org; Sun, 24 Aug 2003 14:12:55 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19qzME-0001Eq-00 for sip@ietf.org; Sun, 24 Aug 2003 14:12:54 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7OI3d88031521 for ; Sun, 24 Aug 2003 14:12:24 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA00492FAF; Sun, 24 Aug 2003 14:11:15 -0400 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 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Sun, 24 Aug 2003 14:12:24 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04B8C455@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNqU/hzeJq8OkdxTXiUYWRYa2pVZAAFopoA From: "Roy, Radhika R, ALABS" To: "Rohan Mahy" , "Cullen Jennings" Cc: "Robert Sparks" , 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: Rohan Mahy [mailto:rohan@cisco.com] Sent: Sunday, August 24, 2003 11:27 AM To: Cullen Jennings Cc: Robert Sparks; sip@ietf.org Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone .... 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. [RRR] One way of solving this problem is to use ENUM services to obtaining the domain name for routing over the SIP/IP network. .... 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 Aug 25 00:28: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 AAA11055 for ; Mon, 25 Aug 2003 00:28: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 19r8xp-0002Y5-Gj for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 00:28:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P4SLN5009793 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 00: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 19r8xV-0002W0-Kr; Mon, 25 Aug 2003 00: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 19r8wi-0002V3-Qa for sip@optimus.ietf.org; Mon, 25 Aug 2003 00:27: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 AAA10966 for ; Mon, 25 Aug 2003 00:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r8wg-000175-00 for sip@ietf.org; Mon, 25 Aug 2003 00:27:10 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19r8wf-00016A-00 for sip@ietf.org; Mon, 25 Aug 2003 00:27:09 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h7P4PQeO015565; Mon, 25 Aug 2003 00:25:26 -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 h7P4P8Zn011919; Mon, 25 Aug 2003 00:25:09 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id AAA99262; Mon, 25 Aug 2003 00:24:47 -0400 (EDT) Date: Mon, 25 Aug 2003 00:24:47 -0400 (EDT) Message-Id: <200308250424.AAA99262@fish.research.att.com> To: rohan@cisco.com Cc: fluffy@cisco.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [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: , Rohan, While I agree with your arguments about the distinction between tel: URIs and sip: URIs, I have to disagree with the conclusion about ";user=phone". 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. What then is the point of ";user=phone"? At bar.com, it may need the hint to tell it that "foo" is to be interpreted as a phone number, instead of an ancient Compuserve user-id. Or maybe some users like to be known by numbers. Whatever. It is up to bar.com to make the decision, not the other servers in the network. If bar.com doesn't need the hint, it should be free to ignore any ";user=XXX" parameter. I shudder to think of all the nasty surprises that would result if all the transit servers could interpret the ";user=phone" to mean they understand the semantics of the username. They don't. Only the named host can do that. As an example, a server in Europe might change a leading + to "00"; then when the request reached a server in the US the call would complete to a long-distance operator; not at all the intent of the originator. I'm not sure if private numbering plans have been brought up in this discussion or not. They can certainly be implemented by having a digit string indistinguishable from a complete E.164 number in a sip URI, addressed to a server that understands the numbering plan. Servers along the path might look at the string and claim it is illegal - like an invalid country code or area code. It would not be good to prevent this service. Should this service then disallow ";user=phone" in the URI? How is the UAC to know the difference? Only bar.com knows. So while ";user=phone" may be useful in some cases, stating that the user part MUST be a valid global-number or local-number with ;phone-context parameter, is just inviting all those other proxies to muck with things they have no business touching. In whatever wording is decided to deal with the interop issue, the intermediate servers (whether proxies or B2BUAs) MUST NOT touch or check the username of a sip URI, whether ";user=phone" is present or not. Bill Marshall wtm@research.att.com -----original message----- Date: Sun, 24 Aug 2003 08:27:15 -0700 Subject: Re: [Sip] SIPIT Interop problem with ;user=phone Cc: Robert Sparks , To: Cullen Jennings From: Rohan Mahy Hi Folks, To tie Cullen's comments more concretely to the discussion, I have always interpreted the semantics of ;user=phone to mean that the user part has been converted from a tel URL but that someone wants this tel URL to be handled in the context of a particular SIP domain. If a SIP UA just collects a string of digits "1234" (this is not a tel URL), slaps on the domain name of their proxy, and then sends these digits there without interpretation, then you just end up with an ordinary SIP URI (user=ip): sip:1234@mylocalproxy.example.com however, I think it is much more useful for the UA to generate a tel URL here instead: tel:1234;phone-context=+14085551111 Note that both of these are correctly scoped. tel:1234 is illegal, as should be sip:1234@mylocalproxy.example.com;user=phone (IMO). Why not deprecate ;user=phone entirely? Aside from backwards compatibility, there is actually a very good reason. Since tel: URIs don't have a domain portion, there is no way for me to send a tel URL through a loose-routed service and still convey which domain I would like the tel URI to be handled in. So lets say that I send this INVITE INVITE tel:+14085268570 SIP/2.0 Route: ... transcoders.org will either reject the request or send it to whatever PSTN gateway it feels like using. I would like to the INVITE to go to a specific provider out of a list of several of these, but I do not want to negotiate the specific user-part naming convention with each one: INVITE sip:+14085268570@provider1.com;user=phone SIP/2.0 Route: Likewise I can use SIPS to go to a different provider: INVITE sips:+14085268570@provider2.net;user=phone SIP/2.0 Continuing on in this vein, say I REFER Jiri (in Europe) to call Adam's cell phone (in Texas). It would be much nicer to provide this Refer-To URI: sips:+19991234567@dfw-gw.dynamicsoft.com;user=phone (a tel URL addressed to a particular SIP UA) instead of: tel:+19991234567 (since Jiri may need to discover such a gateway, or be billed for an International PSTN call when he has a perfectly good Internet he can use instead for the "expensive" part of the call). So, I think the ;user=phone is in fact very useful (even if only as a standardized convention). If it is used at all I think the user part MUST be a valid global-number or local-number with ;phone-context paramter, if user=phone is in the SIP URI. thanks, -rohan On Friday, August 22, 2003, at 01:09 PM, Cullen Jennings wrote: > > More than one person has suggested that we should use tel URL (ala > 2806bis > not 2806) for telephone numbers, local PBX numbers, 800 etc and we > should > use sip for sip AORs. This clears up an incredible amount of weirdly > specified comparison issues that are poorly implemented. At first > glance it > looks like it would cause lots of backwards compatibility problems but > it > might be worth looking at how bad they would be. The current situation > has a > lot of problems that are somewhat swept under the rug. > > One comment I would like to add is that in the SIP messages that flow > over > the wire, we do need both telephone number and SIP AOR. We do not need > dialed digits instructions - the user interfaces of UA might use these > but > the protocol does not need them. > > Cullen > > > On 8/22/03 7:10, "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? 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? >> >> 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 Aug 25 01: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 BAA13924 for ; Mon, 25 Aug 2003 01: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 19rAAK-0005BO-77 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 01:45:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P5jKci019862 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 01:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rAA2-00059U-HV; Mon, 25 Aug 2003 01: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 19rA9m-00058w-1C for sip@optimus.ietf.org; Mon, 25 Aug 2003 01:44: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 BAA13856 for ; Mon, 25 Aug 2003 01:44:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rA9i-00029R-00 for sip@ietf.org; Mon, 25 Aug 2003 01:44:42 -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 19rA9i-00028m-00 for sip@ietf.org; Mon, 25 Aug 2003 01:44:42 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Aug 2003 22:44:13 -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 h7P5iBFI006898; Sun, 24 Aug 2003 22:44:11 -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 AKS86665; Sun, 24 Aug 2003 22:35:29 -0700 (PDT) Date: Sun, 24 Aug 2003 22:46:51 -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: "Cullen Jennings" , "Robert Sparks" , To: "Roy, Radhika R, ALABS" From: Rohan Mahy In-Reply-To: <34DA635B184A644DA4588E260EC0A25A04B8C455@ACCLUST02EVS1.ugd.att.com> Message-Id: <86784CF9-D6BF-11D7-A872-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 Radhika, ENUM allows the callee to specify a SIP URI for a phone number. What I am talking about allows the caller to specify how they want to get to a telephone number (including a local number with phone context) than might not be in ENUM at all. thanks, -rohan On Sunday, August 24, 2003, at 11:12 AM, Roy, Radhika R, ALABS wrote: > Inline [RRR] > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 24, 2003 11:27 AM > To: Cullen Jennings > Cc: Robert Sparks; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > .... > > Since tel: URIs > don't have a domain portion, there is no way for me to send a tel URL > through a loose-routed service and still convey which domain I would > like the tel URI to be handled in. > > [RRR] One way of solving this problem is to use ENUM services to > obtaining the domain name for routing over the SIP/IP network. > > .... > > 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 Aug 25 03:01: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 DAA29357 for ; Mon, 25 Aug 2003 03:01: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 19rBLv-000196-9C for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 03:01:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P71Nfc004348 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 03:01:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rBLf-00017C-Pg; Mon, 25 Aug 2003 03:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rBLH-00014Q-Qd for sip@optimus.ietf.org; Mon, 25 Aug 2003 03:00: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 DAA29305 for ; Mon, 25 Aug 2003 03:00:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rBLD-0003Qw-00 for sip@ietf.org; Mon, 25 Aug 2003 03:00:39 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19rBLD-0003Q9-00 for sip@ietf.org; Mon, 25 Aug 2003 03:00:39 -0400 Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 25 Aug 2003 09:04:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <06CF906FE3998C4E944213062009F1620EA058@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNqwlOMbkjRYGYwSLO93kA3nlbv/wAE8LoA content-class: urn:content-classes:message From: "Stastny Richard" To: "William Marshall" , 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 Hi folks, just for my understanding: > There is certainly a difference between > sip:foo@bar.com;user=3Dphone > and tel:foo =09 >=20 > The first is explicitely telling all servers other than=20 > bar.com to keep their hands off the string "foo". When the=20 > string "foo" appears in a tel: URL, then all those transit=20 > servers can modify it, or route the call to their own=20 > favorite gateway server; when the string "foo" appears in a=20 > sip: URL, then the transit servers merely pass it=20 > unchanged to the explicitely named host/gateway. >=20 I thought that any server will take his hand off "foo" anyway if it is not "bar.com". Am I missing something? 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 Mon Aug 25 08:27:11 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 IAA13063 for ; Mon, 25 Aug 2003 08:27:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGQn-00056A-QV for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 08:26:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PCQjUg019540 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 08:26:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGPK-0004qt-IT; Mon, 25 Aug 2003 08:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rGOn-0004pt-6k for sip@optimus.ietf.org; Mon, 25 Aug 2003 08:24: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 IAA12929 for ; Mon, 25 Aug 2003 08:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rGOm-00009H-00 for sip@ietf.org; Mon, 25 Aug 2003 08:24:40 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19rGOl-00009E-00 for sip@ietf.org; Mon, 25 Aug 2003 08:24:39 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Mon, 25 Aug 2003 15:22:36 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 15:22:36 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E0E34B1@nt-mail.radvision.com> From: Adi Even-Tzur To: sip@ietf.org Date: Mon, 25 Aug 2003 15:22:35 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Rewriting URI in the Record-Route header by Proxy when working w ith TLS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, According to RFC3261 section 16.7.8: "If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI." consider the following scenario: A request is received by the proxy, over TLS, but with Request URI of "SIP" (and not with "SIPS", for example the request was sent over TLS due to DNS resolution). The proxy generate a request without a SIPS URI in the Request URI or topmost Route, so the proxy insert a Record-Route header that is not a SIPS URI. The response is received over UDP (or TCP) and sent over TLS. My question is: when the response is received, should the proxy rewrite the Record-Route header from SIP URI to SIPS URI ? Regards, Adi Even Tzur. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 25 10:06: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 KAA18782 for ; Mon, 25 Aug 2003 10:06: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 19rHzL-0000Es-JH for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 10:06:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PE6U50000848 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 10:06:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rHyx-0000D5-BQ; Mon, 25 Aug 2003 10:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rHyS-0000CH-14 for sip@optimus.ietf.org; Mon, 25 Aug 2003 10:05: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 KAA18594 for ; Mon, 25 Aug 2003 10:05:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rHyM-0001Ti-00 for sip@ietf.org; Mon, 25 Aug 2003 10:05:30 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rHyM-0001Ta-00 for sip@ietf.org; Mon, 25 Aug 2003 10:05: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 KAA19952; Mon, 25 Aug 2003 10:04:51 -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 KAA08094; Mon, 25 Aug 2003 10:04:48 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 10:04:47 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D24@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" 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) Date: Mon, 25 Aug 2003 10:04:47 -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: , 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 From exim@www1.ietf.org Mon Aug 25 13:59: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 NAA04807 for ; Mon, 25 Aug 2003 13:59:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLcE-0008D1-FH for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 13:58:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PHwrdv031484 for sip-archive@odin.ietf.org; Mon, 25 Aug 2003 13:58:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLbu-00089n-Qq; Mon, 25 Aug 2003 13:58:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJJ8-0004NU-9r for sip@optimus.ietf.org; Mon, 25 Aug 2003 11:31: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 LAA24208 for ; Mon, 25 Aug 2003 11:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJJ7-0002fY-00 for sip@ietf.org; Mon, 25 Aug 2003 11:31:01 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19rJJ6-0002fO-00 for sip@ietf.org; Mon, 25 Aug 2003 11:31:00 -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 h7PFUUd8012673; Mon, 25 Aug 2003 11:30:30 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 10:30:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863A8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Mon, 25 Aug 2003 10:30:29 -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: , [Changing thread back to original title] Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: > user=phone, at the moment, means "this is a dial string". I think we have strong evidence in this discussion that not everyone agrees with this statement. Why? Because "user=phone" is somewhat underspecified. That said, the current normative language in 3261 would seem to support Rohan's interpretation (albeit in a somewhat muddy way): If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. RFC 3261 then cites RFC 2806 as the source for the "telephone-subscriber" syntax. Presumably, the next RFC describing SIP will update its reference to reflect the output of 2806bis. Combined with the text in 19.1.2 and 19.1.6, RFC 3261 certainly seems to indicate that "user=phone" is intended be transformable to a tel: URI by reversing the procedures in 19.1.2. So, as you point out: > 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. > 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) I think that's what "phone-context" is supposed to convey. > we need to leave user=phone as the way to send a dial > string. 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". /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 Aug 26 14:52: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 OAA21130 for ; Tue, 26 Aug 2003 14:52: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 19rivI-0003Oc-5F for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 14:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QIq6aT012984 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 14:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riup-0003Lv-Pv; Tue, 26 Aug 2003 14:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rbva-0000Zm-PS for sip@optimus.ietf.org; Tue, 26 Aug 2003 07:23: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 HAA29170 for ; Tue, 26 Aug 2003 07:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rbva-0007UO-00 for sip@ietf.org; Tue, 26 Aug 2003 07:23:58 -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 19rbvZ-0007UH-00 for sip@ietf.org; Tue, 26 Aug 2003 07:23:57 -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 h7QBQFWC017686; Tue, 26 Aug 2003 07:26:15 -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 h7QBMLZn012111; Tue, 26 Aug 2003 07:22:21 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id HAA46142; Tue, 26 Aug 2003 07:21:33 -0400 (EDT) Date: Tue, 26 Aug 2003 07:21:33 -0400 (EDT) Message-Id: <200308261121.HAA46142@fish.research.att.com> 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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 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 Tue Aug 26 21:45: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 VAA02783 for ; Tue, 26 Aug 2003 21: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 19rotZ-0003FZ-Sp for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 21:14:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R1EjHt012489 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 21:14:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rnIj-000727-61; Tue, 26 Aug 2003 19:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rib4-0002Fc-6p for sip@optimus.ietf.org; Tue, 26 Aug 2003 14:31: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 OAA19361 for ; Tue, 26 Aug 2003 14:31:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rib1-0005G4-00 for sip@ietf.org; Tue, 26 Aug 2003 14:31:11 -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 19rib0-0005F4-00 for sip@ietf.org; Tue, 26 Aug 2003 14:31:10 -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 h7QIUeiv005556; Tue, 26 Aug 2003 11:30:40 -0700 (PDT) Received: from [10.32.138.117] ([10.32.138.117]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM06508; Tue, 26 Aug 2003 11:30:39 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 26 Aug 2003 11:30:40 -0700 From: Cullen Jennings To: CC: 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 Subject: [Sip] FW: Review 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 First I would to say thanks to the folks that put so much work into this draft. After reviewing it, I am sure it was a lot of somewhat thankless work and I like it. I'm going to split my comments up into somewhat major topics and minor things. I should probably go through stuff in more detail but here are some initial comments to get things going. Major Things - some of these are quite debatable so debate them :-) There is not enough in the MIB to configure any UA or Proxy I have seen. I don't think this is a problem but I think we should make the configuration aspect of the MIB optional but the diagnostic and reporting aspect mandatory. If we decide that configuration is part of what we are doing here, we need a bunch more stuff. I think we should make this targeted at status and debug instead of configuration - this would significantly simplify the MIB. There are mechanisms to deal with new methods - why no just use these for all the methods including known ones. It would simplify the MIB and implementations to be able to deal with things in a uniform generic way instead of having separate code for OPTION and INVITE. Why not just report stats for responses based on an array of 100 to 699. This again would allow very generic treatment. For some things, like 4xx, responses aggregating all the 4xx into one count does not provide good information because things like 401 are very normal while other 4xx correspond to problems. In all the counts, I don't think we should include retransmissions and we should have a few counters to do with the UDP transport that take care of retransmission stats. Many proxies can control more than one domain at the same time. Need to support this. The UA stuff confuses, registrars, outbound proxies and such - actually these have been confusing in various version of SIP documents so not surprising - need to clean up a bit. Need to work through what things need notification attached to them and what the filters should look like. For example, I might want to find out if my invites per second goes above or below a certain value and how often I will get notified while it out it's normal range. Minor Things Most proxies have some sort of dial plan table. Should we support reading this table as a table of strings but not specify the format for the strings? Could have flags indicating if enum was done. The term session is used a little inconsistently with 3261 - suggest that most places session occurs we replace with dialog. Proxy/Redirect server - I don't see any value in separating these. I would just make Redirect a special case of Proxy and not split it apart in the MIB at all. I'm not sure that I really see Proxy and Registrar being very different other than a Proxy that does not do Registration may have 0 values for a bunch of things. Can you find the number of bad message a proxy has received. Number of TCP or TLS session failures. Getting information about the active dialogs on a UA. Getting information about the previous call on a UA. Setting log levels. Section 5 - sipCommonStatsOther - lat word of para - replace URIs with methods Section 5 - SipProxyCfg - Canceling branches is not optional and there is no need to control it from the MIB If we go down this strange path of sip_proxy_redirect names, I think we need to provide a ordering of them so that everyone says sip_proxy_redirect and no one says sip_redirect_proxy. All the examples that have domain names like ss8.com or cisco.com need to be changed to example.com. P19 - sipOrganization - should this be in UA only mib P19 - maxSipSession - do you mean dialogs or transaction P19 - sipRequestUriHostMatching - a proxy that did not do this would be in violation of the RFC. Don't think we need this. P21-22 - sipTransportRcv and Snd. I think it is bogus to specify if you can receive or send on a given port. In things other than UDP this has no hope of working. In UDP it is of very little use given where we are going with rport. P22 sipPortStatus - making a special exception for 5060 is not right. If more than one SIP thing is running on the same host, one of them will not be on 5060. P23 sipUriSupported stuff - you have to do sip - why not just make a flag that indicates if tel is supported or not. P27 - SipCommonCfgTimerEntry - Is being able to change all the timers really a good idea - I don't have an opinion this - I'm just raising the question. P 32 - I think per method timers are a bad idea. P 34 - I think per method retry counts are a bad idea. P 37 - per method Expires seem like a dubious idea - the app should know how to set these - I don't see configuration being needed for them P38 - sipCfgExpiresInvite - proxy should not change this - seems like UA only at best P38 sipCfgExpiresRegister - this is something that the registrar does need to configure (and perhaps the UA) but not the proxy. The text that the header value wins on a registrar is wrong. P 38 - sipCfgExpiresHeaderMethod - this is a strong indication we went down the wrong path somewhere - I don't like this, not on a train, not ... P 39 - sipCommonCfgExpiresStatusCodeEntry - no no no this is not right - this cat should not be in the MIB. P 42 - sipSummaryTotalTransactions counting forked request as one transaction is wrong P 43 - SipMethodDtatsEntry - don't think these should include retransmissions P 58 - sipCurrentTransaction - the forked requests are not the same transaction P 76 - sipUACfgSipServerAddress - is this the AOR? Where to send the registration? The outbound proxy? The auth domain for digest? I think this needs to be broken into a bunch of things. What about UA that can register to multiple proxies. What does the contact get set to. P 83 - sipRequestMeaxExpires - in what context? Would need to split this up - not sure I see any value in it P 83 - sipProxyStatefulness - give the RFC forces proxies to switch mode - I am really lost at what this would report or how it be of much value. The concept of it being read-write is particularly hard for me to imagine. P 84 - sipProxySendsCancels, sipPRoxyForwardAll1xx - these just seem plain wrong P 84 - sipProxyRecurions - I like this one :-) P 85 - sipRpxyProvieAlternatives - sounds like a bad idea P 85 - sipProxyRecrodRoute - I'm very dubious on this one - a proxy would need to do this because it was doing something that required it. In this case it' can't run it off and otherwise it probably should be off. P 86 - sipProxyAuthMethod - bit 1 should probably say mutual TLS, S/MIME is not yet defined for end to middle auth. I really doubt these bits are enough to control how say mutual TLS would work SipProxyNonceLifeTime - a max of 65 seconds is too short - do we really need this in the mib P 87 sipNumProxyRequiresFailures - I like this one P 88 SipRegAllowThridParty - not sure I see the need for this P 89 sipRegmaxContactExpireyDuration - should not have a DEFVAL P 90 sipRegUserTable - I don't know enough about SNMP here - If this table had a few million entries in it would that be ok, could you systematically access a chunk of it say the 10,000 to 20,000 entry. Going through the entries one at a time will be too slow. Going through the entries all in one gulp might hang things temporarily. P 91 sipUserAtuhtneitcationFailures - does this reset after a successful authentication - would like to be able to do notification on a threshold on it P94 - sipContactRetryAfter - I did not know you could do this - in fact, I don't think you can. Any comments from others? I'm sure some of my comments are just wrong or misunderstandings. It's hard to read a MIB and easily get the big picture - perhaps as I think about it more I will be able to provide better comments. I also should probably go through the MIB review NTIS stuff that is at http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02. txt Once again, thanks to the authors - it looks like a lot for work. 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 Wed Aug 27 01:52: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 BAA25938 for ; Wed, 27 Aug 2003 01:52: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 19rrdY-0002iC-2d for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 00:10:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R4ANq2010364 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 00:10:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmoo-0005Be-Qt; Tue, 26 Aug 2003 19:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rd2F-0001zu-Ga for sip@optimus.ietf.org; Tue, 26 Aug 2003 08:34: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 IAA01457 for ; Tue, 26 Aug 2003 08:34:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rd2E-0000ED-00 for sip@ietf.org; Tue, 26 Aug 2003 08:34:54 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rd2D-0000Dy-00 for sip@ietf.org; Tue, 26 Aug 2003 08:34: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 IAA13033; Tue, 26 Aug 2003 08:34:21 -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 IAA05221; Tue, 26 Aug 2003 08:34:21 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 08:34:21 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Tue, 26 Aug 2003 08:34: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: , We might be weird, but lack of user=phone indicates to our proxy that we should look up the user part in our registered user list. Including user=phone means we pass the user string to our gateway processing section that interprets a set of rules to expand the user name into a url. We use this capability in many interesting ways. For example, you can force routing of a call to a particular gateway (if site policy permits it). Typically, to do this we put some alpha prefix on the number. Thus: sip:pitpbx4826@marconi.com;user=phone means that the call will be passed to the Pittsburgh PBX gateway calling extension 4826. You could get to the same phone by dialing sip:3004826@marconi.com;user=phone, but that may route a different way (for example, it could be routed to a local gateway, to the local PBX, and then over a tie line between the local PBX and the Pittsburgh PBX). We do this by creating rules in the ruleset that match the pitpbx prefix. We have a matching regexp and a replacement regexp, so that a general purpose substitution is possible (the actual expansion of the example would be sip:4826@pitgw1.sip.marconi.com). If you tried calling sip:pitpbx4826 without the user=phone, we would try to find a user named pitbbx4826 in our registrar's database. Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, August 25, 2003 2:49 PM > To: sip@ietf.org > 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Aug 27 02:06:24 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 CAA02744 for ; Wed, 27 Aug 2003 02:06:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rqJz-0006zP-Im for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R2k6wi026804 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22: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 19rmyh-0005yH-GH; Tue, 26 Aug 2003 19:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rfi8-0006LA-DL for sip@optimus.ietf.org; Tue, 26 Aug 2003 11:26: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 LAA11023 for ; Tue, 26 Aug 2003 11:26:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rfi7-0002YJ-00 for sip@ietf.org; Tue, 26 Aug 2003 11:26:19 -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 19rfi6-0002Xi-00 for sip@ietf.org; Tue, 26 Aug 2003 11:26:18 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7QFPi7b026211; Tue, 26 Aug 2003 08:25:44 -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 AKU38110; Tue, 26 Aug 2003 08:16:50 -0700 (PDT) Date: Tue, 26 Aug 2003 08:28:51 -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: , , To: From: Rohan Mahy In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701796FF8@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, August 26, 2003, at 04:59 AM, wrote: > Why isn't this the problem of tel: URI? I think user=phone is just a useful standardized convention to say to the SIP server in the domain part that "the user part of this SIP/SIPS URI is an encoded tel URL". > 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? I think you loose a lot of flexibility there. For example the distinction between using SIP and SIPS and all the NAPTR/SRV lookups we get with SIP. > We can then deprecate user=phone and any use of telephone-subscriber > in a sip URI. SIP URI then always carries a SIP URI. > Thanks, > Hisham > >> -----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=phone >> >> >> >> Hi Folks, >> >> To tie Cullen's comments more concretely to the discussion, I have >> always interpreted the semantics of ;user=phone to mean that the user >> part has been converted from a tel URL but that someone wants >> this tel >> URL to be handled in the context of a particular SIP domain. >> >> If a SIP UA just collects a string of digits "1234" (this is >> not a tel >> URL), slaps on the domain name of their proxy, and then sends these >> digits there without interpretation, then you just end up with an >> ordinary SIP URI (user=ip): >> >> sip:1234@mylocalproxy.example.com >> >> however, I think it is much more useful for the UA to generate a tel >> URL here instead: >> >> tel:1234;phone-context=+14085551111 >> >> Note that both of these are correctly scoped. tel:1234 is >> illegal, as >> should be sip:1234@mylocalproxy.example.com;user=phone (IMO). >> >> >> Why not deprecate ;user=phone entirely? Aside from backwards >> compatibility, there is actually a very good reason. Since tel: URIs >> don't have a domain portion, there is no way for me to send a tel URL >> through a loose-routed service and still convey which domain I would >> like the tel URI to be handled in. >> >> So lets say that I send this INVITE >> >> INVITE tel:+14085268570 SIP/2.0 >> Route: >> ... >> >> transcoders.org will either reject the request or send it to whatever >> PSTN gateway it feels like using. I would like to the INVITE >> to go to >> a specific provider out of a list of several of these, but I do not >> want to negotiate the specific user-part naming convention with each >> one: >> >> INVITE sip:+14085268570@provider1.com;user=phone SIP/2.0 >> Route: >> >> Likewise I can use SIPS to go to a different provider: >> >> INVITE sips:+14085268570@provider2.net;user=phone SIP/2.0 >> >> Continuing on in this vein, say I REFER Jiri (in Europe) to >> call Adam's >> cell phone (in Texas). It would be much nicer to provide >> this Refer-To >> URI: >> >> sips:+19991234567@dfw-gw.dynamicsoft.com;user=phone (a tel URL >> addressed to a particular SIP UA) >> >> instead of: >> >> tel:+19991234567 >> >> (since Jiri may need to discover such a gateway, or be billed for an >> International PSTN call when he has a perfectly good Internet he can >> use instead for the "expensive" part of the call). >> >> So, I think the ;user=phone is in fact very useful (even if only as a >> standardized convention). If it is used at all I think the user part >> MUST be a valid global-number or local-number with ;phone-context >> paramter, if user=phone is in the SIP URI. >> >> >> 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 Wed Aug 27 02: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 CAA02883 for ; Wed, 27 Aug 2003 02: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 19rrCd-0001YE-VK for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 23:42:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R3gZfS005902 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 23:42:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmpT-0005I6-HC; Tue, 26 Aug 2003 19:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdmB-0003FY-4R for sip@optimus.ietf.org; Tue, 26 Aug 2003 09:22: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 JAA03116 for ; Tue, 26 Aug 2003 09:22:17 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdm9-0000cE-00 for sip@ietf.org; Tue, 26 Aug 2003 09:22:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19rdm8-0000c7-00 for sip@ietf.org; Tue, 26 Aug 2003 09:22:20 -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 h7QDMFB02482 for ; Tue, 26 Aug 2003 16:22:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Aug 2003 16:22:15 +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 16:22:15 +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 16:22:14 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796FFD@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNqU/X+nVojMdtGQjmJW16vOGIbngBgRE/w To: , Cc: , X-OriginalArrivalTime: 26 Aug 2003 13:22:15.0437 (UTC) FILETIME=[1106CBD0:01C36BD5] 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 > -----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 > On Friday, August 22, 2003, at 01:09 PM, Cullen Jennings wrote: >=20 > > > > More than one person has suggested that we should use tel URL (ala=20 > > 2806bis > > not 2806) for telephone numbers, local PBX numbers, 800 etc and we=20 > > should > > use sip for sip AORs. This clears up an incredible amount of weirdly > > specified comparison issues that are poorly implemented. At first=20 > > glance it > > looks like it would cause lots of backwards compatibility=20 > problems but=20 > > it > > might be worth looking at how bad they would be. The=20 > current situation=20 > > has a > > lot of problems that are somewhat swept under the rug. > > > > One comment I would like to add is that in the SIP messages=20 > that flow=20 > > over > > the wire, we do need both telephone number and SIP AOR. We=20 > do not need > > dialed digits instructions - the user interfaces of UA=20 > might use these=20 > > but > > the protocol does not need them. > > > > Cullen > > > > > > On 8/22/03 7:10, "Robert Sparks" wrote: > > > >> I've seen a few interoperability failures at SIPIT 13 revolving > >> around the use of ;user=3Dphone in sip URIs. > >> > >> We have some implementations assuming that the presence of=20 > ;user=3Dphone > >> 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=3Dphone. > >> > >> So, is this an oversight? Are we allowing URIs with ;user=3Dphone > >> 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=3Dphone 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? 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=3Dphone > >> 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=3Dphone > >> 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=3Dphone is present in a URI then the userinfo part > >> MUST be formatted as a telephone-subscriber. Would anyone > >> object to adding this requirement? > >> > >> 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 >=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 Aug 27 02:07:10 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 CAA03423 for ; Wed, 27 Aug 2003 02:07:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rqWz-0007XR-A3 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22:59:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R2xWGB028914 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22:59:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmyJ-0005t1-LT; Tue, 26 Aug 2003 19:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rf4V-0005R5-Lr for sip@optimus.ietf.org; Tue, 26 Aug 2003 10:45: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 KAA09090 for ; Tue, 26 Aug 2003 10:45:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rf4T-0001rB-00 for sip@ietf.org; Tue, 26 Aug 2003 10:45:21 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19rf4S-0001r8-00 for sip@ietf.org; Tue, 26 Aug 2003 10:45:20 -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 h7QEjHAv015288; Tue, 26 Aug 2003 16:45:17 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 26 Aug 2003 16:46:07 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Juha Heinanen'" Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] More on dial plans and user=phones Date: Tue, 26 Aug 2003 16:44:47 +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, >>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... > >pstn gws usually assume to receive the called number in certain format >that is gw specific. it is the task of the proxy feeding the >gw to know the format and if necessary rewrite the called number. this >has nothing to do with user=phone. It is true that every gateway (maybe also other SIP nodes), based on "local policy", can define in which format it wants to receive telephone numbers. But, from an interop point of view I think it would be good to have a "standard" way of eg sending telephone numbers in a SIP-URI - no matter if we use user=phone or not, and no matter if the syntax is according to telephone-subscriber or not - if we have networks where nodes may be assigned telephone numbers. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 27 02:11: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 CAA07625 for ; Wed, 27 Aug 2003 02:11: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 19rqRv-0007JE-TP for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22:54:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R2sIch028035 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 22:54:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19roso-00039B-KB; Tue, 26 Aug 2003 21:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmar-0004P4-29 for sip@optimus.ietf.org; Tue, 26 Aug 2003 18:47: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 SAA18021; Tue, 26 Aug 2003 18:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rman-0003qk-00; Tue, 26 Aug 2003 18:47:13 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19rmam-0003qg-00; Tue, 26 Aug 2003 18:47:12 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h7QMlBN06971; Tue, 26 Aug 2003 15:47:12 -0700 (PDT) Message-Id: <200308262247.h7QMlBN06971@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 26 Aug 2003 15:47:11 -0700 Subject: [Sip] RFC 3581 on An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Request for Comments is now available in online RFC libraries. RFC 3581 Title: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing Author(s): J. Rosenberg, H. Schulzrinne Status: Standards Track Date: August 2003 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Pages: 13 Characters: 66133 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-symmetric-response-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3581.txt The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030826154448.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3581 --OtherAccess Content-Type: Message/External-body; name="rfc3581.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030826154448.RFC@RFC-EDITOR.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 Wed Aug 27 02:12: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 CAA08890 for ; Wed, 27 Aug 2003 02:12: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 19rqbZ-0007hH-IB for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 23:04:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R34GvA029525 for sip-archive@odin.ietf.org; Tue, 26 Aug 2003 23:04:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmyD-0005rp-0S; Tue, 26 Aug 2003 19:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rep9-0004uu-MU for sip@optimus.ietf.org; Tue, 26 Aug 2003 10:29: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 KAA08239 for ; Tue, 26 Aug 2003 10:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rep7-0001f3-00 for sip@ietf.org; Tue, 26 Aug 2003 10:29:29 -0400 Received: from [192.98.100.8] (helo=lohi.tutpro.com) by ietf-mx with esmtp (Exim 4.12) id 19rep6-0001f0-00 for sip@ietf.org; Tue, 26 Aug 2003 10:29:28 -0400 Received: from jh by lohi.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19reox-00051K-00; Tue, 26 Aug 2003 17:29:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16203.28351.617225.419725@lohi.tutpro.com> Date: Tue, 26 Aug 2003 17:29:19 +0300 To: "Christer Holmberg (SE/LMF)" Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] More on dial plans and user=phones In-Reply-To: References: X-Mailer: VM 7.03 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 Christer Holmberg (SE/LMF) writes: > 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... pstn gws usually assume to receive the called number in certain format that is gw specific. it is the task of the proxy feeding the gw to know the format and if necessary rewrite the called number. this has nothing to do with user=phone. -- 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 Aug 27 16:12: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 QAA04639 for ; Wed, 27 Aug 2003 16:12: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 19s5V7-0002pd-34 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 14:58:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RIwbJd010884 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 14:58:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s48V-0005rY-1y; Wed, 27 Aug 2003 13:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ruz6-0007bK-Vk for sip@optimus.ietf.org; Wed, 27 Aug 2003 03:44: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 DAA02417 for ; Wed, 27 Aug 2003 03:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ruz4-0000Er-00 for sip@ietf.org; Wed, 27 Aug 2003 03:44:50 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19ruz3-0000EH-00 for sip@ietf.org; Wed, 27 Aug 2003 03:44:50 -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: Wed, 27 Aug 2003 09:49:07 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337E8@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNqU/X+nVojMdtGQjmJW16vOGIbngBdJ9lwAClg1IA= From: "Stastny Richard" To: , , 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 To my knowledge the Tel: URI (in rfc1806bis) has the parameter ;phone-context=3D=20 Local numbers MUST have a phone context, either e.g. =3D+1800 or =3Dfoo.bar.com=20 This is explained lenghty in section 5.1.4 Richard > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Tuesday, August 26, 2003 2:00 PM > To: rohan@cisco.com; fluffy@cisco.com > Cc: rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Why isn't this the problem of tel: URI? >=20 > I dare to make the suggestion that the tel URI itself can=20 > have a parameter called "domain" or something similar to=20 > accommodate the scenario Rohan presents? >=20 > We can then deprecate user=3Dphone and any use of=20 > telephone-subscriber in a sip URI. SIP URI then always=20 > carries a SIP URI. >=20 > Thanks, > Hisham=20 >=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 > > always interpreted the semantics of ;user=3Dphone to mean=20 > 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 > > 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 > > URL here instead: > >=20 > > tel:1234;phone-context=3D+14085551111 > >=20 > > Note that both of these are correctly scoped. tel:1234 is > > illegal, as=20 > > should be sip:1234@mylocalproxy.example.com;user=3Dphone (IMO). > >=20 > >=20 > > Why not deprecate ;user=3Dphone entirely? Aside from backwards > > compatibility, there is actually a very good reason. Since=20 > tel: URIs=20 > > don't have a domain portion, there is no way for me to send=20 > a tel URL=20 > > through a loose-routed service and still convey which=20 > 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=20 > to whatever > > 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=20 > 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 > > 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 > > International PSTN call when he has a perfectly good=20 > 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=20 > only as a > > standardized convention). If it is used at all I think the=20 > 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 >=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 Wed Aug 27 18:52:24 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 SAA16063 for ; Wed, 27 Aug 2003 18:52: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 19s4Y0-0007ZR-Bw for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 13:57:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RHvV4V029042 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 13:57:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3pn-0004Hn-Cg; Wed, 27 Aug 2003 13:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Uq-00085z-11 for sip@optimus.ietf.org; Wed, 27 Aug 2003 11:46: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 LAA10611 for ; Wed, 27 Aug 2003 11:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2Uo-0001Na-00 for sip@ietf.org; Wed, 27 Aug 2003 11:46:06 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19s2Un-0001NI-00 for sip@ietf.org; Wed, 27 Aug 2003 11:46:06 -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 h7RFWcFX027591 for ; Wed, 27 Aug 2003 10:45:35 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA0057F3FC; Wed, 27 Aug 2003 11:44:24 -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: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 11:45:35 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04C19858@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNsUhmmIl3w8QURTxmo0oTQeX4NagASwveQAAA0LSAABPj8YA== From: "Roy, Radhika R, ALABS" To: "Stastny Richard" , "Rosen, Brian" , 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: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, August 27, 2003 9:28 AM To: Roy, Radhika R, ALABS; Rosen, Brian; William Marshall; sip@ietf.org Cc: fluffy@cisco.com Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone Inline [Sta] > -----Original Message----- > From: Roy, Radhika R, ALABS [mailto:rrroy@att.com]=20 > Sent: Wednesday, August 27, 2003 3:17 PM > To: Rosen, Brian; William Marshall; sip@ietf.org > Cc: fluffy@cisco.com; Stastny Richard > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Inline [RRR] >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, August 26, 2003 8:23 AM > To: 'William Marshall'; sip@ietf.org > Cc: fluffy@cisco.com; Richard.Stastny@oefeg.at > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 > .... >=20 > This means there is no global understanding of the user part. >=20 > [RRR] Yes, this is the key. So, there will not be any=20 > universal interoperability. [Sta] ??why not?? Do I need to look at the user part in e-mail? [RRR] The interpretation of the user part, I think, is a local matter, and does not need to be universal. Richard >=20 > .... >=20 > Brian >=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 Aug 27 20:37: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 UAA23082 for ; Wed, 27 Aug 2003 20:37: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 19s5pr-0003wY-Bw for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:20:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJK2vB015099 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4xF-0001IM-3G; Wed, 27 Aug 2003 14:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rvKM-00006g-PU for sip@optimus.ietf.org; Wed, 27 Aug 2003 04:06: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 EAA04266 for ; Wed, 27 Aug 2003 04:06:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rvKK-0000hZ-00 for sip@ietf.org; Wed, 27 Aug 2003 04:06:48 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19rvKJ-0000gb-00 for sip@ietf.org; Wed, 27 Aug 2003 04:06:47 -0400 content-class: urn:content-classes:message Subject: RE: 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, 27 Aug 2003 10:11:05 +0200 Message-ID: <06CF906FE3998C4E944213062009F1620EA06C@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNsVKlhIGe2xZSqRWyS6tTN42gs+wAHSeeg From: "Stastny Richard" To: "Rosen, Brian" , "William Marshall" , 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] > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Sent: Tuesday, August 26, 2003 2:23 PM > To: 'William Marshall'; sip@ietf.org > Cc: fluffy@cisco.com; Stastny Richard > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Well, in many real systems there are several proxies that=20 > understand the local domain. For example,=20 > pitt.sip.marconi.com and coventry.sip.marconi.com may=20 > understand the marconi.com dialing plan. Often, a phone is=20 > given a default domain. Any URL presented to it (such as a=20 > dial string) that does not have an explicit domain has the=20 > default domain appended to it. So, as long as the proxy that=20 > handles the expansion understands the dial plan in the=20 > specified domain, then it can process it. I think that's=20 > pretty explicit. >=20 > At the moment, we don't have any specification for a dial=20 > string, and while we might evolve one in the configuration=20 > work, I would not propose to specify how a dialstring is=20 > interpretted. This means there is no global understanding of=20 > the user part. Yes, because there is no global dialing plan, only national, local and private. Richard >=20 > Brian >=20 > > -----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=3Dphone > >=20 > >=20 > > Cullen wrote (entire message quoted below): > > > sip:1234@foo.com means send it to foo.com and foo will > > figure it out. > > >=20 > > > sip:1234@foo.com;user=3Dphone means send to to foo.com and > > foo will figure it out. > >=20 > > I think the above statement is exactly right. As Richard > > Stastny wrote > > > I thought that any server will take his hand off "foo"=20 > anyway if it=20 > > > is not "bar.com". > >=20 > > 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=3Dphone, then , > > > or at least a proxy that understands the dialing plan,=20 > > > does the translation. That may or may not be the first hop proxy. > >=20 > > ***or at least a proxy that understands the dialing plan**** > >=20 > > If the ";user=3Dphone" requires a strict format and global=20 > understanding=20 > > of the username of the sip: URI, then everyone can claim to=20 > be a proxy=20 > > that understands the dialing plan. This is wrong. > >=20 > > It should instead read: > > If you send sip:@;user=3Dphone, then > > does the translation. That may or may not be the first=20 > hop proxy. > >=20 > > Bill Marshall > > wtm@research.att.com > >=20 > > -----original messages----- > > Subject: RE: [Sip] SIPIT Interop problem with ;user=3Dphone > > Date: Mon, 25 Aug 2003 09:04:51 +0200 > > From: "Stastny Richard" > > To: "William Marshall" , > > Cc: , , > >=20 > > Hi folks, > > just for my understanding: > >=20 > > > There is certainly a difference between > > > sip:foo@bar.com;user=3Dphone > > > and tel:foo =09 > > >=20 > > > The first is explicitely telling all servers other than > > > bar.com to keep their hands off the string "foo". When the=20 > > > string "foo" appears in a tel: URL, then all those transit=20 > > > servers can modify it, or route the call to their own=20 > > > favorite gateway server; when the string "foo" appears in a=20 > > > sip: URL, then the transit servers merely pass it=20 > > > unchanged to the explicitely named host/gateway. > > >=20 > >=20 > > I thought that any server will take his hand off "foo"=20 > anyway if it is=20 > > not "bar.com". Am I missing something? > > Richard > >=20 > > ---------- > > 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=20 > > Inte rop problem with ;user=3Dphone) > > Date: Mon, 25 Aug 2003 11:10:25 -0400 > >=20 > > Someone just pointed out to me that there could be confusion on who=20 > > translates a dial string to a routable number. If you send=20 > > sip:@;user=3Dphone, then , or at=20 > least a proxy=20 > > that understands the dialing plan, does the=20 > translation. That=20 > > may or may not be the first hop proxy. > >=20 > > Most phones that I know have configured; you don't=20 > type it. If=20 > > you did, and it wasn't your local proxy, then you better understand=20 > > how whatever you typed interprets your dial string, and your local=20 > > proxy better not muck with it. > >=20 > > Brian > >=20 > > ---------- > > Date: Mon, 25 Aug 2003 11:48:36 -0700 > > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > > From: Cullen Jennings > > To: > >=20 > > sip:1234@foo.com means send it to foo.com and foo will=20 > figure it out. > >=20 > > sip:1234@foo.com;user=3Dphone means send to to foo.com and foo > > will figure it > > out.=20 > >=20 > > Right now it is totally random if the UA puts in the > > user=3Dphone or not and > > the proxies (as far as I can tell) mostly ignore it. I'm=20 > > having a hard time > > figuring out what the requirement is for this extra 1 bit of=20 > > information > > that currently has no semantic meaning. There is a certain amount of > > operational experience that indicates this flag is not needed. > >=20 > > I think the whole thing is bogus unless someone can clearly state a=20 > > requirement that says why the proxy might need to know some=20 > extra bit=20 > > of information and clearly says how the UA would set this bit of > > information > > based on something the user entered on the UA. > >=20 > > Defining something that all UAs will set to the same value or > > all proxies > > will ignore is useless. > >=20 > > Cullen > >=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 Wed Aug 27 20:41: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 UAA23463 for ; Wed, 27 Aug 2003 20:41: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 19s64R-0004NI-5I for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:35:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJZ71t016813 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4ui-0000vr-Tq; Wed, 27 Aug 2003 14:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmqf-0005P3-GM for sip@optimus.ietf.org; Tue, 26 Aug 2003 19: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 TAA19234 for ; Tue, 26 Aug 2003 19:03:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rmqc-0004DV-00 for sip@ietf.org; Tue, 26 Aug 2003 19:03:34 -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 19rmqb-0004Ch-00 for sip@ietf.org; Tue, 26 Aug 2003 19:03:33 -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 h7QN327b005671; Tue, 26 Aug 2003 16:03:02 -0700 (PDT) Received: from [10.32.138.117] ([10.32.138.117]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHM43979; Tue, 26 Aug 2003 16:02:52 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 26 Aug 2003 16:02:53 -0700 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Brian Rosen , Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D42@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 The Cisco proxy can be configured several different ways but at best the user=phone flag ends up being a hint to what to try first - in all the deployed cases I have can think of, checking the registry first then if that fails going to the dial plan seemed like it would work. The real problem is on the UAS. Does the digit map/dial plan or whatever it is called have entries in it that indicate some strings of digits dialed by users will get user=phone and other won't? Is there some other way for the human dialing the UA to indicate what should happen? Unless this gets really well specified and everyone supports it, I'm not sure any of this is going to help much. Anyway, I think the problem is that it is not clear what the requirements are for this flag. Cullen On 8/26/03 5:34, "Rosen, Brian" wrote: > We might be weird, but lack of user=phone indicates to our proxy > that we should look up the user part in our registered user list. > Including user=phone means we pass the user string to our > gateway processing section that interprets a set of rules to > expand the user name into a url. We use this capability in > many interesting ways. For example, you can force routing of a > call to a particular gateway (if site policy permits it). Typically, > to do this we put some alpha prefix on the number. Thus: > sip:pitpbx4826@marconi.com;user=phone means that the call > will be passed to the Pittsburgh PBX gateway calling extension 4826. > You could get to the same phone by dialing > sip:3004826@marconi.com;user=phone, but that may route a different > way (for example, it could be routed to a local gateway, to the > local PBX, and then over a tie line between the local PBX and the > Pittsburgh PBX). We do this by creating rules in the ruleset > that match the pitpbx prefix. We have a matching regexp and a > replacement regexp, so that a general purpose substitution is > possible (the actual expansion of the example would be > sip:4826@pitgw1.sip.marconi.com). > > If you tried calling sip:pitpbx4826 without the user=phone, we would > try to find a user named pitbbx4826 in our registrar's database. > > Brian > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Monday, August 25, 2003 2:49 PM >> To: sip@ietf.org >> 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 >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Aug 27 21:02: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 VAA25637 for ; Wed, 27 Aug 2003 21:02: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 19s6Rn-0005Yt-Oh for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJxFD1021320 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:59:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4tZ-0000l2-HY; Wed, 27 Aug 2003 14:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsqh-0006vP-3v for sip@optimus.ietf.org; Wed, 27 Aug 2003 01:28: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 BAA23804 for ; Wed, 27 Aug 2003 01:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rsqe-0005I5-00 for sip@ietf.org; Wed, 27 Aug 2003 01:28:00 -0400 Received: from [192.98.100.8] (helo=lohi.tutpro.com) by ietf-mx with esmtp (Exim 4.12) id 19rsqd-0005I1-00 for sip@ietf.org; Wed, 27 Aug 2003 01:27:59 -0400 Received: from jh by lohi.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19rsqS-0005CN-00; Wed, 27 Aug 2003 08:27:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16204.16724.685117.762569@lohi.tutpro.com> Date: Wed, 27 Aug 2003 08:27:48 +0300 To: "Rosen, Brian" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 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: > call to a particular gateway (if site policy permits it). Typically, > to do this we put some alpha prefix on the number. Thus: > sip:pitpbx4826@marconi.com;user=phone means that the call > will be passed to the Pittsburgh PBX gateway calling extension 4826. > You could get to the same phone by dialing > sip:3004826@marconi.com;user=phone, but that may route a different > way (for example, it could be routed to a local gateway, to the > local PBX, and then over a tie line between the local PBX and the > Pittsburgh PBX). why can't your proxy check if the number begins with 300 and then route the call the same way it now routes a pitpbx call? who is adding pitpbx in front of the 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 Aug 27 21:08: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 VAA26224 for ; Wed, 27 Aug 2003 21:08: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 19s6Dd-0004wU-76 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:44:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJibVS018939 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:44:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s486-0005kQ-Ao; Wed, 27 Aug 2003 13:30:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsbu-0006Ha-4y for sip@optimus.ietf.org; Wed, 27 Aug 2003 01:12: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 BAA22554 for ; Wed, 27 Aug 2003 01:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rsbr-0004xL-00 for sip@ietf.org; Wed, 27 Aug 2003 01:12:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19rsbq-0004xH-00 for sip@ietf.org; Wed, 27 Aug 2003 01:12:42 -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 h7R5Ce31020155; Wed, 27 Aug 2003 07:12:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 27 Aug 2003 07:13:35 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Jonathan Rosenberg'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] More on dial plans and user=phones Date: Wed, 27 Aug 2003 07:12:23 +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 agree (I assume) with Jonathan on the fact that the user parameter should NOT be used to make routing decissions. When I make a call with my SIP phone, I may not even know if the call is going to end up in the PSTN network, so I can't insert user=phone based on that. The proxies will make the routing decissions based on whatever other policies. I also agree that user=phone should NOT be a part of the userid itself. Ie "sip:1234@sip.com" represents exactly the same user as "sip:1234@sip.com;user=phone". There can not be two users with the same identity, I think, even if one happens to be on the PSTN side of a gateway. To me user=phone currently only indicates that the userpart syntax is as defined for telephone-subscriber - which some seem to agree on, and others don't. Now, I agree that we may not really need a parameter to indicate that, if we instead have a defined way of putting telephone numbers in a SIP-URI. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 25. elokuuta 2003 23:14 > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] More on dial plans and user=phones > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 27 21:26: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 VAA27576 for ; Wed, 27 Aug 2003 21:26: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 19s7Al-0007bB-La for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:45:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RKjhxi029200 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:45:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qr-0002au-HJ; Wed, 27 Aug 2003 14:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Mq-0007jb-BR for sip@optimus.ietf.org; Wed, 27 Aug 2003 11:37: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 LAA09963 for ; Wed, 27 Aug 2003 11:37:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2Mp-0001Er-00 for sip@ietf.org; Wed, 27 Aug 2003 11:37:51 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19s2Mo-0001EM-00 for sip@ietf.org; Wed, 27 Aug 2003 11:37:50 -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 LAA18529; Wed, 27 Aug 2003 11:37: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 LAA15918; Wed, 27 Aug 2003 11:37:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 11:37:19 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D67@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 11:37:14 -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 have gateways that do that. It works fine because a real phone number is a good dial string in most dialing plans, and we want to process that call with our dial plan rules. Sometimes it isn't, but our routing rules can take the From as part of the rule so we can fix things like having a 9 prefix in the dial plan, but the gateway just using an external E.164. Our routing rules would process such a call and rewrite the URI to not have the user=phone and forward it. Of course, if the forward was to itself it would then go through its loop again and look it up in the registration database. You are the weird one because you have both a phone and a gateway with the same AOR, unless you are relying on the gateway not registering as the phone number it has on its port. We've seen a gateway that did that. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, August 27, 2003 11:26 AM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > On Tue, 2003-08-26 at 07:34, Rosen, Brian wrote: > > We might be weird, but lack of user=phone indicates to our proxy > > that we should look up the user part in our registered user list. > > Including user=phone means we pass the user string to our > > You're weird ;-). We look up the user part first, becasue > guess what -- > SOME gateways slap a user=phone on the end of any call coming > from PSTN, > and I really want to be able to divert that to a SIP UA that isn't a > PSTN phone but registers with a user-part that looks like a phone > number. > > How would your system be able to handle that? Insert routing > table logic > in your phone number processing that diverts the call back to a non > user=phone format and reprocesses it? > > My believf: The only responsible thing to do with a > user=phone is ignore > it. > > -- > 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 Wed Aug 27 21:30: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 VAA28100 for ; Wed, 27 Aug 2003 21:30: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 19sAxj-0002ob-K0 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 20:48:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S0mVwe010803 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 20:48:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qm-0002Zl-AE; Wed, 27 Aug 2003 14:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s25k-0007EX-Bi for sip@optimus.ietf.org; Wed, 27 Aug 2003 11:20: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 LAA08015 for ; Wed, 27 Aug 2003 11:20:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s25j-0000l5-00 for sip@ietf.org; Wed, 27 Aug 2003 11:20:11 -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 19s25i-0000jm-00 for sip@ietf.org; Wed, 27 Aug 2003 11:20:10 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RFJS97007559; Wed, 27 Aug 2003 10:19:28 -0500 Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: William Marshall Cc: sip@ietf.org, fluffy@cisco.com, Brian.Rosen@marconi.com, Richard.Stastny@oefeg.at In-Reply-To: <200308261121.HAA46142@fish.research.att.com> References: <200308261121.HAA46142@fish.research.att.com> Content-Type: text/plain Message-Id: <1061997568.7417.15.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 10:19:28 -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 Bill suggested: > It should instead read: > If you send sip:@;user=phone, then > does the translation. That may or may not be the first hop proxy. I counterpropose that: "If you send sip:@;user=phone, then , meaning any proxy responsible for does the translation. That may or may not be the first hop proxy." Funny, this works exactly the same way WITHOUT the user=phone. -- 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 Wed Aug 27 21:32: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 VAA28263 for ; Wed, 27 Aug 2003 21:32: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 19s9nW-00073r-88 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 19:33:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNXsYF027142 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 19:33:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s48D-0005mL-C3; Wed, 27 Aug 2003 13:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rvI3-0008V3-CF for sip@optimus.ietf.org; Wed, 27 Aug 2003 04:04: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 EAA04081 for ; Wed, 27 Aug 2003 04:04:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rvI0-0000eY-00 for sip@ietf.org; Wed, 27 Aug 2003 04:04:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19rvI0-0000da-00 for sip@ietf.org; Wed, 27 Aug 2003 04:04:24 -0400 content-class: urn:content-classes:message Subject: RE: 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, 27 Aug 2003 10:08:42 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337E9@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNsUn60+x16XUEHS6inqlJsW6nG5wAHYP+w From: "Stastny Richard" To: "Rosen, Brian" , "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 [below] > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Sent: Tuesday, August 26, 2003 2:34 PM > To: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > We might be weird, but lack of user=3Dphone indicates to our=20 > proxy that we should look up the user part in our registered=20 > user list. Including user=3Dphone means we pass the user string=20 > to our gateway processing section that interprets a set of=20 > rules to expand the user name into a url. We use this=20 > capability in many interesting ways. For example, you can=20 > force routing of a call to a particular gateway (if site=20 > policy permits it). Typically, to do this we put some alpha=20 > prefix on the number. Thus:=20 > sip:pitpbx4826@marconi.com;user=3Dphone means that the call=20 > will be passed to the Pittsburgh PBX gateway calling extension 4826. =20 > You could get to the same phone by dialing=20 > sip:3004826@marconi.com;user=3Dphone, but that may route a different=20 > way (for example, it could be routed to a local gateway, to the=20 > local PBX, and then over a tie line between the local PBX and the=20 > Pittsburgh PBX). We do this by creating rules in the ruleset=20 > that match the pitpbx prefix. We have a matching regexp and=20 > a replacement regexp, so that a general purpose substitution=20 > is possible (the actual expansion of the example would be=20 > sip:4826@pitgw1.sip.marconi.com). >=20 > If you tried calling sip:pitpbx4826 without the user=3Dphone,=20 > we would try to find a user named pitbbx4826 in our=20 > registrar's database. And you expect a user to dial all this? This is even worse than the first Subscriber Trunk Dialing (STD) in UK in 1950 where the users had to dial origination dependent Trunk Codes before Trunk Auto and Registers where invented ;-) Back to the future ... Richard >=20 > Brian >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Monday, August 25, 2003 2:49 PM > > To: sip@ietf.org > > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone > >=20 > >=20 > >=20 > > sip:1234@foo.com means send it to foo.com and foo will=20 > figure it out. > >=20 > > sip:1234@foo.com;user=3Dphone means send to to foo.com and foo > > will figure it > > out.=20 > >=20 > > Right now it is totally random if the UA puts in the > > user=3Dphone or not and > > the proxies (as far as I can tell) mostly ignore it. I'm=20 > > having a hard time > > figuring out what the requirement is for this extra 1 bit of=20 > > information > > that currently has no semantic meaning. There is a certain amount of > > operational experience that indicates this flag is not needed. > >=20 > > I think the whole thing is bogus unless someone can clearly state a=20 > > requirement that says why the proxy might need to know some=20 > extra bit=20 > > of information and clearly says how the UA would set this bit of > > information > > based on something the user entered on the UA. > >=20 > > Defining something that all UAs will set to the same value or > > all proxies > > will ignore is useless. > >=20 > > Cullen > >=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 Wed Aug 27 21:34: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 VAA28461 for ; Wed, 27 Aug 2003 21:34: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 19sBUF-0005FD-2j for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1M7xu020141 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21: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 19s6fB-0006E2-QA; Wed, 27 Aug 2003 16:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5W8-0002ug-Cm for sip@optimus.ietf.org; Wed, 27 Aug 2003 14: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 OAA27015 for ; Wed, 27 Aug 2003 14:59:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5W5-0005kc-00 for sip@ietf.org; Wed, 27 Aug 2003 14:59:37 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19s5W4-0005jx-00 for sip@ietf.org; Wed, 27 Aug 2003 14:59: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 OAA25129; Wed, 27 Aug 2003 14:59: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 OAA12953; Wed, 27 Aug 2003 14:59:06 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 14:59:04 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D6A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 14:59:02 -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: , You are thinking about big trunk gateways. I'm talking about smaller ones. TRIP is extreme overkill for a 4 or 8 line gateway. TRIP is unnecessary if all the gateways in a system are routable by some simple ruleset. Registration by the gateway is a Good Thing. The user part of the AOR is not all that usefull, although we actually do use it, but it lets the signalling system know that the gateway is up and running, and how to contact it. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, August 27, 2003 1:33 PM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Brian said: > > You are the weird one because you have both a phone > > and a gateway with the same AOR, unless you are relying > > on the gateway not registering as the phone number it > > has on its port. We've seen a gateway that did that. > > I'm sorry somebody sent you a defective gateway. I hope you > were able to > get it fixed. > > Gateways, at least multiline gateways, should NEVER EVER register. > That's deeply evil! They get calls from PSTN, turn them into SIP > INVITES, and send them out (ostensibly, to the default > proxy). They get > SIP INVITES from their IP side, turn the user part into a > phone number, > and signal it out to PSTN. Very simple business. Having gateways > "register" leads to insanity like trying to send a regisration request > for every phone number in the NANP, or in a given area code, or the > like. That's whay we have TRIP, with its prefix-ranges and weights. > > A telephone number is not an address of record. It's the > user-part of an > address of record and must be evaluated in the context of > some domain to > be meaningful. By convention, we assume that a telephone > number having a > leading + is evaluated in the E.164 domain context. It doesn't really > have to be (not a MUST), but it's a useful convention. > Anything else, we > have to "guess at" the context, unless the context is specifically > stated in the right-hand-side production of a SIP(S) URI. > > The user=phone parameter was meant as a hint to help guess the > evaluation context. The original argumentation for it was that > user=phone would help disambiguate a case where there were cearly two > different AORs with the same "user part" in a given domain -- a case > that I don't believe we've found to exist. In some environments it is > clearly not meaningful. In other environments, it MIGHT be. > > The question: Is the utility of the parameter in those environments > sufficient to justify the complexity that it apparently creates? > > -- > 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 Wed Aug 27 21:35: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 VAA28512 for ; Wed, 27 Aug 2003 21:35: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 19sBS8-00053Z-HK for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21:19:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1Juhu019378 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21:19:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6fA-0006Dp-BB; Wed, 27 Aug 2003 16: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 19s5WJ-0002ul-Sj for sip@optimus.ietf.org; Wed, 27 Aug 2003 14:59: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 OAA27034 for ; Wed, 27 Aug 2003 14:59:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5WE-0005kq-00 for sip@ietf.org; Wed, 27 Aug 2003 14:59:46 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19s5WD-0005kB-00 for sip@ietf.org; Wed, 27 Aug 2003 14:59:45 -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 OAA25137; Wed, 27 Aug 2003 14:59:13 -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 OAA12990; Wed, 27 Aug 2003 14:59:15 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 14:59:14 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D6B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 14:59:11 -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: , Some gateways know how to convert a dial string to a phone number. Most don't. If you send a gateway that does a dial string (denoted by user=phone), then you are telling the gateway to invoke its dial string processing. Some proxies know how to convert a dial string to a phone number. Some don't If you send a proxy that does know a dial string (denoted by user=phone) then you are telling the proxy to invoke its dial string processing. If the gateway doesn't have dial string processing, and you send it user=phone, it could complain, or it could try to guess that the user part is a phone number and call it. That may or may not work. If the proxy doesn't have dial string processing, and you send it user=phone, it could complain, or it could try to guess that the user part is a phone number and route it as best it can. That may or may not work. Now we get to the part I'm not sure of. If you send a proxy a tel uri, it better be routable either globally or within the specified context and it's definately an error if it is not. It may have to translate to a SIP URI. It probably needs to mark the SIP URI that it was a translated tel uri, which might be user=phone, but I think we need something new (user=FormerlyWasATelUri). If you send a gateway a tel uri, then it better be dialable from that gateway. I don't think this will be common (that is, I think a proxy will translate a tel uri to a sip uri and route it before it arrives at a gateway). If you send a proxy a numeric username, and you don't specify user=phone, and you don't specify something new, I think correct behavior should be to try to FIRST look up the number in the registration database. If you don't get a hit, you could try to route the number using your gateway processing rules (TRIP for example). If you send a proxy a numeric username, and you specify something new (like user=FormerlyWasAtelUri), then we know that we want the proxy to route it, as translation has already been done. If you send a gateway a numeric username, and you don't specify user=phone OR you specify user=FormerlyWasAtelURI, then it should treat it as a dialable number. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, August 27, 2003 1:43 PM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > 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 Wed Aug 27 21:38: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 VAA28793 for ; Wed, 27 Aug 2003 21:38: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 19s6Nf-0005KZ-Vr for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:55:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RJsxVe020431 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 15:54:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s47k-0005ih-Pc; Wed, 27 Aug 2003 13:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0BA-00034x-Nr for sip@optimus.ietf.org; Wed, 27 Aug 2003 09:17: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 JAA24987 for ; Wed, 27 Aug 2003 09:17:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0B9-0005Q8-00 for sip@ietf.org; Wed, 27 Aug 2003 09:17:39 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19s0B8-0005P4-00 for sip@ietf.org; Wed, 27 Aug 2003 09:17:38 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7RDCp7k002671 for ; Wed, 27 Aug 2003 09:17:08 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA005734AF; Wed, 27 Aug 2003 09:15:57 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 09:17:08 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04BECFC7@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNsUhmmIl3w8QURTxmo0oTQeX4NagASwveQ From: "Roy, Radhika R, ALABS" To: "Rosen, Brian" , "William Marshall" , 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, August 26, 2003 8:23 AM To: 'William Marshall'; sip@ietf.org Cc: fluffy@cisco.com; Richard.Stastny@oefeg.at Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone .... This means there is no global understanding of the user part. [RRR] Yes, this is the key. So, there will not be any universal = interoperability. .... 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 Aug 27 22:16: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 WAA02011 for ; Wed, 27 Aug 2003 22:16: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 19s79t-0007Zp-SV for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:44:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RKinHZ029066 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:44:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4vc-00014G-8H; Wed, 27 Aug 2003 14:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rzGS-000170-I3 for sip@optimus.ietf.org; Wed, 27 Aug 2003 08:19: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 IAA20873 for ; Wed, 27 Aug 2003 08:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rzGP-0004Su-00 for sip@ietf.org; Wed, 27 Aug 2003 08:19:01 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rzGP-0004Se-00 for sip@ietf.org; Wed, 27 Aug 2003 08:19:01 -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 IAA10330; Wed, 27 Aug 2003 08:18: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 IAA15651; Wed, 27 Aug 2003 08:18:29 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 08:18:29 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D5C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Juha Heinanen'" Cc: "'Cullen Jennings'" , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 08:18:19 -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: , There is a dialing plan, that has a routing ruleset. If you send a tel uri with the local context, or a sip uri with user=phone, we will apply that ruleset to the number -- it isn't really limited to be a number. The prefix is used when someone wants to force routing to something. We have administrative controls that can limit this. It turns out to be pretty usefull in some circumstances. The only relevance to this discussion remains that we can't use a hint like "it's all digits" to decide if we are to use a dialing plan or not. We use user=phone. Brian > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Wednesday, August 27, 2003 1:28 AM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Rosen, Brian writes: > > > call to a particular gateway (if site policy permits it). > Typically, > > to do this we put some alpha prefix on the number. Thus: > > sip:pitpbx4826@marconi.com;user=phone means that the call > > will be passed to the Pittsburgh PBX gateway calling > extension 4826. > > You could get to the same phone by dialing > > sip:3004826@marconi.com;user=phone, but that may route a different > > way (for example, it could be routed to a local gateway, to the > > local PBX, and then over a tie line between the local PBX and the > > Pittsburgh PBX). > > why can't your proxy check if the number begins with 300 and > then route > the call the same way it now routes a pitpbx call? who is > adding pitpbx > in front of the 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 Aug 27 22:31: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 WAA03353 for ; Wed, 27 Aug 2003 22:31: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 19s77k-0007R4-Q6 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:42:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RKgavR028576 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:42:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4t1-0000bg-U5; Wed, 27 Aug 2003 14:19:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s08X-0002zO-Sd for sip@optimus.ietf.org; Wed, 27 Aug 2003 09:14: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 JAA24592 for ; Wed, 27 Aug 2003 09:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s08V-0005Kp-00 for sip@ietf.org; Wed, 27 Aug 2003 09:14:55 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19s08V-0005JX-00 for sip@ietf.org; Wed, 27 Aug 2003 09:14:55 -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 JAA12315; Wed, 27 Aug 2003 09:14: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 JAA23124; Wed, 27 Aug 2003 09:14:23 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 09:14:22 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D60@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" , hisham.khartabil@nokia.com Cc: fluffy@cisco.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 09:14:14 -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'd prefer that we not go around saying that user=phone means the user part is a tel uri. We need to be able to handle that circumstance for backwards compatibility, but we should be encouraging implementors to use a tel uri when they have a globally routable number, or a local number with a context. There are other uses for user=phone that have been discussed here, and I believe we need to keep it, but I would prefer that we don't encourage its use when a tel uri would work. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, August 26, 2003 11:29 AM > To: hisham.khartabil@nokia.com > Cc: fluffy@cisco.com; rsparks@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone > > > > On Tuesday, August 26, 2003, at 04:59 AM, > > wrote: > > > Why isn't this the problem of tel: URI? > > I think user=phone is just a useful standardized convention to say to > the SIP server in the domain part that "the user part of this > SIP/SIPS > URI is an encoded tel URL". > > > 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? > > I think you loose a lot of flexibility there. For example the > distinction between using SIP and SIPS and all the NAPTR/SRV > lookups we > get with SIP. > > > We can then deprecate user=phone and any use of > telephone-subscriber > > in a sip URI. SIP URI then always carries a SIP URI. > > Thanks, > > Hisham > > > >> -----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=phone > >> > >> > >> > >> Hi Folks, > >> > >> To tie Cullen's comments more concretely to the discussion, I have > >> always interpreted the semantics of ;user=phone to mean > that the user > >> part has been converted from a tel URL but that someone wants > >> this tel > >> URL to be handled in the context of a particular SIP domain. > >> > >> If a SIP UA just collects a string of digits "1234" (this is > >> not a tel > >> URL), slaps on the domain name of their proxy, and then sends these > >> digits there without interpretation, then you just end up with an > >> ordinary SIP URI (user=ip): > >> > >> sip:1234@mylocalproxy.example.com > >> > >> however, I think it is much more useful for the UA to > generate a tel > >> URL here instead: > >> > >> tel:1234;phone-context=+14085551111 > >> > >> Note that both of these are correctly scoped. tel:1234 is > >> illegal, as > >> should be sip:1234@mylocalproxy.example.com;user=phone (IMO). > >> > >> > >> Why not deprecate ;user=phone entirely? Aside from backwards > >> compatibility, there is actually a very good reason. Since > tel: URIs > >> don't have a domain portion, there is no way for me to > send a tel URL > >> through a loose-routed service and still convey which > domain I would > >> like the tel URI to be handled in. > >> > >> So lets say that I send this INVITE > >> > >> INVITE tel:+14085268570 SIP/2.0 > >> Route: > >> ... > >> > >> transcoders.org will either reject the request or send it > to whatever > >> PSTN gateway it feels like using. I would like to the INVITE > >> to go to > >> a specific provider out of a list of several of these, but I do not > >> want to negotiate the specific user-part naming convention > with each > >> one: > >> > >> INVITE sip:+14085268570@provider1.com;user=phone SIP/2.0 > >> Route: > >> > >> Likewise I can use SIPS to go to a different provider: > >> > >> INVITE sips:+14085268570@provider2.net;user=phone SIP/2.0 > >> > >> Continuing on in this vein, say I REFER Jiri (in Europe) to > >> call Adam's > >> cell phone (in Texas). It would be much nicer to provide > >> this Refer-To > >> URI: > >> > >> sips:+19991234567@dfw-gw.dynamicsoft.com;user=phone (a tel URL > >> addressed to a particular SIP UA) > >> > >> instead of: > >> > >> tel:+19991234567 > >> > >> (since Jiri may need to discover such a gateway, or be > billed for an > >> International PSTN call when he has a perfectly good > Internet he can > >> use instead for the "expensive" part of the call). > >> > >> So, I think the ;user=phone is in fact very useful (even > if only as a > >> standardized convention). If it is used at all I think > the user part > >> MUST be a valid global-number or local-number with ;phone-context > >> paramter, if user=phone is in the SIP URI. > >> > >> > >> 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 Aug 27 22:44: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 WAA04791 for ; Wed, 27 Aug 2003 22:44: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 19s803-0001sO-AK for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 17:38:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RLcgMH007153 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 17:38:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3q7-0004Qj-6I; Wed, 27 Aug 2003 13:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s33S-00014D-BQ for sip@optimus.ietf.org; Wed, 27 Aug 2003 12:21: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 MAA12941 for ; Wed, 27 Aug 2003 12:21:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s33Q-0001vH-00 for sip@ietf.org; Wed, 27 Aug 2003 12:21:53 -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 19s33Q-0001uX-00 for sip@ietf.org; Wed, 27 Aug 2003 12:21:52 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 09:31: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 h7RGLItJ021371; Wed, 27 Aug 2003 09:21:18 -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 AHN05151; Wed, 27 Aug 2003 09:21:17 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 27 Aug 2003 09:21:18 -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: <1061997942.7350.22.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 The more this conversation goes on, the more it looks like people are using this flag in an implementation specific way and it currently has no specified meaning. On 8/27/03 8:25, "Dean Willis" wrote: > On Tue, 2003-08-26 at 07:34, Rosen, Brian wrote: >> We might be weird, but lack of user=phone indicates to our proxy >> that we should look up the user part in our registered user list. >> Including user=phone means we pass the user string to our > > You're weird ;-). We look up the user part first, becasue guess what -- > SOME gateways slap a user=phone on the end of any call coming from PSTN, > and I really want to be able to divert that to a SIP UA that isn't a > PSTN phone but registers with a user-part that looks like a phone > number. > > How would your system be able to handle that? Insert routing table logic > in your phone number processing that diverts the call back to a non > user=phone format and reprocesses it? > > My believf: The only responsible thing to do with a user=phone is ignore > it. > > -- > 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 Wed Aug 27 22:45: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 WAA04875 for ; Wed, 27 Aug 2003 22:45: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 19sA5k-0008DU-L3 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 19:52:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNqiSA031558 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 19:52:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s47f-0005gY-2e; Wed, 27 Aug 2003 13:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0HH-0003Fu-4P for sip@optimus.ietf.org; Wed, 27 Aug 2003 09:23: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 JAA25416 for ; Wed, 27 Aug 2003 09:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0HF-0005ZJ-00 for sip@ietf.org; Wed, 27 Aug 2003 09:23:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19s0HE-0005Yz-00 for sip@ietf.org; Wed, 27 Aug 2003 09:23:57 -0400 content-class: urn:content-classes:message Subject: RE: 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, 27 Aug 2003 15:28:11 +0200 Message-ID: <06CF906FE3998C4E944213062009F1620EA06F@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNsUhmmIl3w8QURTxmo0oTQeX4NagASwveQAAA0LSA= From: "Stastny Richard" To: "Roy, Radhika R, ALABS" , "Rosen, Brian" , "William Marshall" , 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 [Sta] > -----Original Message----- > From: Roy, Radhika R, ALABS [mailto:rrroy@att.com]=20 > Sent: Wednesday, August 27, 2003 3:17 PM > To: Rosen, Brian; William Marshall; sip@ietf.org > Cc: fluffy@cisco.com; Stastny Richard > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Inline [RRR] >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, August 26, 2003 8:23 AM > To: 'William Marshall'; sip@ietf.org > Cc: fluffy@cisco.com; Richard.Stastny@oefeg.at > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 > .... >=20 > This means there is no global understanding of the user part. >=20 > [RRR] Yes, this is the key. So, there will not be any=20 > universal interoperability. [Sta] ??why not?? Do I need to look at the user part in e-mail? Richard >=20 > .... >=20 > Brian >=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 Aug 27 22:49:21 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 WAA05302 for ; Wed, 27 Aug 2003 22:49:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sApB-0002Hd-He for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 20:39:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S0dfkV008771 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 20:39:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4si-0000Ur-Fu; Wed, 27 Aug 2003 14:18:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0My-0003On-IA for sip@optimus.ietf.org; Wed, 27 Aug 2003 09:29: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 JAA25901 for ; Wed, 27 Aug 2003 09:29:47 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0Mw-0005h9-00 for sip@ietf.org; Wed, 27 Aug 2003 09:29:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19s0Mv-0005h3-00 for sip@ietf.org; Wed, 27 Aug 2003 09:29:49 -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 h7RDTd410448 for ; Wed, 27 Aug 2003 16:29:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Aug 2003 16:29:39 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 27 Aug 2003 16:29:39 +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: Wed, 27 Aug 2003 16:29:39 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179700A@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNsQ+DsBfhWiSgoSSy22AF3TK2NrQAWGgpA To: Cc: , , X-OriginalArrivalTime: 27 Aug 2003 13:29:39.0785 (UTC) FILETIME=[444AAB90:01C36C9F] 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: Tuesday, August 26, 2003 6:29 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: fluffy@cisco.com; rsparks@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > On Tuesday, August 26, 2003, at 04:59 AM,=20 > =20 > wrote: >=20 > > Why isn't this the problem of tel: URI? >=20 > I think user=3Dphone is just a useful standardized convention to say = to=20 > the SIP server in the domain part that "the user part of this=20 > SIP/SIPS=20 > URI is an encoded tel URL". >=20 > > I dare to make the suggestion that the tel URI itself can have a=20 > > parameter called "domain" or something similar to accommodate the=20 > > scenario Rohan presents? >=20 > I think you loose a lot of flexibility there. For example the=20 > distinction between using SIP and SIPS and all the NAPTR/SRV=20 > lookups we=20 > get with SIP. Richard pointed out that phone-context satisfies by suggestion. But to = answer Rohan: 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 (perhaps = this is a question for Henning)? Why can't this be used for your scenario of routing the sip message to = provider1.com? Regards, Hisham >=20 > > We can then deprecate user=3Dphone and any use of=20 > telephone-subscriber=20 > > in a sip URI. SIP URI then always carries a SIP URI. > > Thanks, > > Hisham > > > >> -----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 > >> > >> > >> > >> Hi Folks, > >> > >> To tie Cullen's comments more concretely to the discussion, I have > >> always interpreted the semantics of ;user=3Dphone to mean=20 > that the user > >> part has been converted from a tel URL but that someone wants > >> this tel > >> URL to be handled in the context of a particular SIP domain. > >> > >> If a SIP UA just collects a string of digits "1234" (this is > >> not a tel > >> URL), slaps on the domain name of their proxy, and then sends these > >> digits there without interpretation, then you just end up with an > >> ordinary SIP URI (user=3Dip): > >> > >> sip:1234@mylocalproxy.example.com > >> > >> however, I think it is much more useful for the UA to=20 > generate a tel > >> URL here instead: > >> > >> tel:1234;phone-context=3D+14085551111 > >> > >> Note that both of these are correctly scoped. tel:1234 is > >> illegal, as > >> should be sip:1234@mylocalproxy.example.com;user=3Dphone (IMO). > >> > >> > >> Why not deprecate ;user=3Dphone entirely? Aside from backwards > >> compatibility, there is actually a very good reason. Since=20 > tel: URIs > >> don't have a domain portion, there is no way for me to=20 > send a tel URL > >> through a loose-routed service and still convey which=20 > domain I would > >> like the tel URI to be handled in. > >> > >> So lets say that I send this INVITE > >> > >> INVITE tel:+14085268570 SIP/2.0 > >> Route: > >> ... > >> > >> transcoders.org will either reject the request or send it=20 > to whatever > >> PSTN gateway it feels like using. I would like to the INVITE > >> to go to > >> a specific provider out of a list of several of these, but I do not > >> want to negotiate the specific user-part naming convention=20 > with each > >> one: > >> > >> INVITE sip:+14085268570@provider1.com;user=3Dphone SIP/2.0 > >> Route: > >> > >> Likewise I can use SIPS to go to a different provider: > >> > >> INVITE sips:+14085268570@provider2.net;user=3Dphone SIP/2.0 > >> > >> Continuing on in this vein, say I REFER Jiri (in Europe) to > >> call Adam's > >> cell phone (in Texas). It would be much nicer to provide > >> this Refer-To > >> URI: > >> > >> sips:+19991234567@dfw-gw.dynamicsoft.com;user=3Dphone (a tel URL > >> addressed to a particular SIP UA) > >> > >> instead of: > >> > >> tel:+19991234567 > >> > >> (since Jiri may need to discover such a gateway, or be=20 > billed for an > >> International PSTN call when he has a perfectly good=20 > Internet he can > >> use instead for the "expensive" part of the call). > >> > >> So, I think the ;user=3Dphone is in fact very useful (even=20 > if only as a > >> standardized convention). If it is used at all I think=20 > the user part > >> MUST be a valid global-number or local-number with ;phone-context > >> paramter, if user=3Dphone is in the SIP URI. > >> > >> > >> 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 Aug 27 22:58:04 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 WAA06323 for ; Wed, 27 Aug 2003 22:58: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 19s7HR-0007mu-53 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:52:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RKqbEG029877 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 16:52:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s47G-0005Vk-7o; Wed, 27 Aug 2003 13:29:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rzHb-00018k-KO for sip@optimus.ietf.org; Wed, 27 Aug 2003 08:20: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 IAA20950 for ; Wed, 27 Aug 2003 08:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rzHa-0004Tq-00 for sip@ietf.org; Wed, 27 Aug 2003 08:20:14 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rzHa-0004TS-00 for sip@ietf.org; Wed, 27 Aug 2003 08:20:14 -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 IAA10377; Wed, 27 Aug 2003 08:19:42 -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 IAA15910; Wed, 27 Aug 2003 08:19:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 08:19:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D5D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Stastny Richard'" , Cullen Jennings , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 08:19:33 -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: , Actually, it's almost always in something akin to a speed dial. We use it, for example, to force routing to the home gateway to a pbx when we are roaming, and the user is trying to access his voicemail box, rather than use the visiting routing rules. Test techs also appreciate it. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, August 27, 2003 4:09 AM > To: Rosen, Brian; Cullen Jennings; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > [below] > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, August 26, 2003 2:34 PM > > To: 'Cullen Jennings'; sip@ietf.org > > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > > > We might be weird, but lack of user=phone indicates to our > > proxy that we should look up the user part in our registered > > user list. Including user=phone means we pass the user string > > to our gateway processing section that interprets a set of > > rules to expand the user name into a url. We use this > > capability in many interesting ways. For example, you can > > force routing of a call to a particular gateway (if site > > policy permits it). Typically, to do this we put some alpha > > prefix on the number. Thus: > > sip:pitpbx4826@marconi.com;user=phone means that the call > > will be passed to the Pittsburgh PBX gateway calling > extension 4826. > > You could get to the same phone by dialing > > sip:3004826@marconi.com;user=phone, but that may route a different > > way (for example, it could be routed to a local gateway, to the > > local PBX, and then over a tie line between the local PBX and the > > Pittsburgh PBX). We do this by creating rules in the ruleset > > that match the pitpbx prefix. We have a matching regexp and > > a replacement regexp, so that a general purpose substitution > > is possible (the actual expansion of the example would be > > sip:4826@pitgw1.sip.marconi.com). > > > > If you tried calling sip:pitpbx4826 without the user=phone, > > we would try to find a user named pitbbx4826 in our > > registrar's database. > > And you expect a user to dial all this? > This is even worse than the first Subscriber Trunk Dialing (STD) in UK > in 1950 where the users had to dial origination dependent Trunk Codes > before Trunk Auto and Registers where invented ;-) > > Back to the future ... > > Richard > > > > > Brian > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Monday, August 25, 2003 2:49 PM > > > To: sip@ietf.org > > > 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 > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 Aug 27 23:37: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 XAA10318 for ; Wed, 27 Aug 2003 23:37:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBAS-0003bb-W6 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21:01:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S11eKK013842 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 21:01:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s52F-0001SJ-Fx; Wed, 27 Aug 2003 14:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1pI-0006bP-DM for sip@optimus.ietf.org; Wed, 27 Aug 2003 11:03: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 LAA06052 for ; Wed, 27 Aug 2003 11:03:05 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1pF-0000F8-00 for sip@ietf.org; Wed, 27 Aug 2003 11:03:09 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19s1pE-0000F1-00 for sip@ietf.org; Wed, 27 Aug 2003 11:03:08 -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 h7RF35B08961 for ; Wed, 27 Aug 2003 18:03:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Aug 2003 18:03:04 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 27 Aug 2003 18:03:01 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 27 Aug 2003 18:03:01 +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 Date: Wed, 27 Aug 2003 18:03:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797010@esebe019.ntc.nokia.com> Thread-Topic: Compressing subsequent REGISTER requests Thread-Index: AcNsrE7rv0Sympw4QlKAoIsm29FjoQ== To: X-OriginalArrivalTime: 27 Aug 2003 15:03:01.0776 (UTC) FILETIME=[4F56A900:01C36CAC] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Compressing subsequent REGISTER 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: quoted-printable 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 Wed Aug 27 23:39: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 XAA10461 for ; Wed, 27 Aug 2003 23:39: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 19s8Xl-0003pm-Ur for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 18:13:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RMDXXW014739 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 18:13:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s52B-0001RH-Lf; Wed, 27 Aug 2003 14:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Bn-0007Qt-M7 for sip@optimus.ietf.org; Wed, 27 Aug 2003 11:26: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 LAA08775 for ; Wed, 27 Aug 2003 11:26:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2Bl-0000zq-00 for sip@ietf.org; Wed, 27 Aug 2003 11:26:25 -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 19s2Bk-0000yL-00 for sip@ietf.org; Wed, 27 Aug 2003 11:26:24 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RFPh97007585; Wed, 27 Aug 2003 10:25:43 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: "Rosen, Brian" Cc: "'Cullen Jennings'" , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1061997942.7350.22.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 10:25:43 -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-08-26 at 07:34, Rosen, Brian wrote: > We might be weird, but lack of user=phone indicates to our proxy > that we should look up the user part in our registered user list. > Including user=phone means we pass the user string to our You're weird ;-). We look up the user part first, becasue guess what -- SOME gateways slap a user=phone on the end of any call coming from PSTN, and I really want to be able to divert that to a SIP UA that isn't a PSTN phone but registers with a user-part that looks like a phone number. How would your system be able to handle that? Insert routing table logic in your phone number processing that diverts the call back to a non user=phone format and reprocesses it? My believf: The only responsible thing to do with a user=phone is ignore it. -- 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 Thu Aug 28 00:39:08 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 AAA15471 for ; Thu, 28 Aug 2003 00:39:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEEn-0001HF-7J for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 00:18:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S4ILWM004850 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 00:18:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCjd-0002wF-LR; Wed, 27 Aug 2003 22:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sA6l-0008FR-0k for sip@optimus.ietf.org; Wed, 27 Aug 2003 19:53: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 TAA20265 for ; Wed, 27 Aug 2003 19:53:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sA6j-0003SQ-00 for sip@ietf.org; Wed, 27 Aug 2003 19:53: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 19sA6i-0003Rg-00 for sip@ietf.org; Wed, 27 Aug 2003 19:53:44 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 17:03: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 h7RNr8Cb017737; Wed, 27 Aug 2003 16:53:09 -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 AKW36785; Wed, 27 Aug 2003 16:43:55 -0700 (PDT) Date: Wed, 27 Aug 2003 16:56:12 -0700 Subject: Re: Warning about dial plan assumptions (was RE: AW: [Sip] SIPIT Inte rop problem with ;user=phone) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Christer Holmberg (SE/LMF)'" , "'Henning Schulzrinne'" , "Conroy, Lawrence (SMTP)" , Adam Roach , sip@ietf.org, Richard To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D26@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <09A4A2B0-D8EA-11D7-B7EA-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, August 25, 2003, at 07:37 AM, Rosen, Brian wrote: > 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. I disagree vociferously. The only reason not to generate a string which can be parsed as a telephone-subscriber is sheer laziness. There is NO REASON why you cannot interpret a dial string as an ordinary (user=ip) SIP URI. If your proxy can't do this, then either get a new proxy that can or configure your UAs to be less lazy and write a proper telephone-subscriber (either an e164 or a localnumber with phone-context) into the userpart and set user=phone. thanks, -rohan > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 28 02:02:20 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 CAA24650 for ; Thu, 28 Aug 2003 02:02: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 19sCIZ-0000HL-9f for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 22:14:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2E7mY001014 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 22:14:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8zK-00052y-5E; Wed, 27 Aug 2003 18:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4L9-0006sk-RJ for sip@optimus.ietf.org; Wed, 27 Aug 2003 13:44: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 NAA21573 for ; Wed, 27 Aug 2003 13:44:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s4L7-0004Qd-00 for sip@ietf.org; Wed, 27 Aug 2003 13:44: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 19s4L6-0004Q4-00 for sip@ietf.org; Wed, 27 Aug 2003 13:44:12 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RHhH97008464; Wed, 27 Aug 2003 12:43:17 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: "Rosen, Brian" Cc: "'Cullen Jennings'" , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D68@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5D68@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1062006197.7417.52.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 12:43:17 -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 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 Thu Aug 28 03:24:07 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 DAA11180 for ; Thu, 28 Aug 2003 03:24:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCan-0001lG-PM for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 22:32:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2WvGi006770 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 22:32:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sA9t-0008UH-UU; Wed, 27 Aug 2003 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s56E-0001ao-JQ for sip@optimus.ietf.org; Wed, 27 Aug 2003 14:32: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 OAA24691 for ; Wed, 27 Aug 2003 14:32:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s56B-0005CS-00 for sip@ietf.org; Wed, 27 Aug 2003 14:32: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 19s567-0005Be-00 for sip@ietf.org; Wed, 27 Aug 2003 14:32:47 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 11:42:14 -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 h7RIWC7b003102; Wed, 27 Aug 2003 11:32:12 -0700 (PDT) Received: from ORANLT ([10.32.130.106]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN23742; Wed, 27 Aug 2003 11:32:11 -0700 (PDT) Date: Wed, 27 Aug 2003 08:05:37 -0400 From: "David R. Oran" To: Dean Willis , sip@ietf.org Subject: Re: [Sip] More on dial plans and user=phones Message-ID: <7658892.1061971537@localhost> In-Reply-To: <004501c36b23$cb2da720$e1036e3f@txdwillis> References: <004501c36b23$cb2da720$e1036e3f@txdwillis> X-Mailer: Mulberry/3.0.3 (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 Jumping in late - was on vacation. --On Monday, August 25, 2003 11:13 AM -0500 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. > I always thought it was simple, but this discussion obviously indicates that other people don't. It's clear that ;user=phone has been overloaded to the point that it is being treated as a substitute for much of what tel: does, but with a different set of restrictions (I assume because tel: drags in the entire worm population of the PSTN numbering can). *I* thought is was to solve the trivial problem of having a user name which just happens to collide with a legal phone number within the numbering plan of the organization which operates the containing the user@domain. Some people have called this the "compuserve" problem, but I'm not sure it's confined to that historical environment. I think the question basically boils down to the following: If you have "12345@example.com" and "12345@example.com;user=phone", would you EVER want these two uri's to address different things. If not, ;user=phone is in fact noise, or at best a hint to optimize lookup overhead in the example.com proxies. I am particularly troubled by people treating the user part as a "dial string", since it is far from clear if something like "15@example.com;user=phone" is really an AoR or not when 15 is treated as a dial string by example.com. A bit more below. > 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. > What do you do if there is a registered user 9724735455 but the "phone number" or worse "dial string" 9724735455 is supposed to reach somebody else? I can imagine declaring this illegal, but is that what we want to do? Does anybody care to cater to people with numeric email addresses (incidentally, Motorola had pure numeric email userids for many years, if I recall correctly so it may not be just historical compuserv ids that exist in the real world). > 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. > [snip] Dave. ------------------------ 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 Aug 28 03:33: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 DAA12018 for ; Thu, 28 Aug 2003 03:33: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 19sD4a-0004Vi-3j for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:03:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S33id0017337 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:03:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9wY-0007ow-41; Wed, 27 Aug 2003 19:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s42c-0004x8-37 for sip@optimus.ietf.org; Wed, 27 Aug 2003 13:25: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 NAA19706 for ; Wed, 27 Aug 2003 13:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s42Z-0003sq-00 for sip@ietf.org; Wed, 27 Aug 2003 13:25:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19s42Z-0003s3-00 for sip@ietf.org; Wed, 27 Aug 2003 13:25: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 NAA21769; Wed, 27 Aug 2003 13:24:31 -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 NAA29735; Wed, 27 Aug 2003 13:24:32 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 13:24:31 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D68@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , Dean Willis Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Wed, 27 Aug 2003 13:24:28 -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: , So the response should be? I think the basic idea on the table is to define what it does mean. It may not be possible to cover all the current uses. It may be possible to guide evolution of its use. We've seen a couple reasons why flushing it is probably not the right thing to do. I'm willing to write something that specifies what it does, if there is anything close to consensus on what that might be. Right now, I'd say: It should NOT be a duplicate of what a tel URI does, even though that's what some systems do now. It should NOT be used when you happen to have a numeric username. It might be used to indicate that it is a translated tel uri. I wonder if it wouldn't it be better to have another way to denote this condition. I think it should be used to denote that the user part is a dial string. Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, August 27, 2003 12:21 PM > To: Dean Willis; Brian Rosen > Cc: sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > The more this conversation goes on, the more it looks like > people are using > this flag in an implementation specific way and it currently has no > specified meaning. > > On 8/27/03 8:25, "Dean Willis" wrote: > > > On Tue, 2003-08-26 at 07:34, Rosen, Brian wrote: > >> We might be weird, but lack of user=phone indicates to our proxy > >> that we should look up the user part in our registered user list. > >> Including user=phone means we pass the user string to our > > > > You're weird ;-). We look up the user part first, becasue > guess what -- > > SOME gateways slap a user=phone on the end of any call > coming from PSTN, > > and I really want to be able to divert that to a SIP UA that isn't a > > PSTN phone but registers with a user-part that looks like a phone > > number. > > > > How would your system be able to handle that? Insert > routing table logic > > in your phone number processing that diverts the call back to a non > > user=phone format and reprocesses it? > > > > My believf: The only responsible thing to do with a > user=phone is ignore > > it. > > > > -- > > 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 Thu Aug 28 04:00:24 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 EAA14079 for ; Thu, 28 Aug 2003 04:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFJw-0004V4-55 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 01:27:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S5RijI017291 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 01:27:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDAl-0005Dc-A2; Wed, 27 Aug 2003 23:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8M5-00039s-0O for sip@optimus.ietf.org; Wed, 27 Aug 2003 18:01: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 SAA11968 for ; Wed, 27 Aug 2003 18:01:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8M2-0001Ta-00 for sip@ietf.org; Wed, 27 Aug 2003 18:01:26 -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 19s8M1-0001TB-00 for sip@ietf.org; Wed, 27 Aug 2003 18:01:25 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RM0h97012019; Wed, 27 Aug 2003 17:00:43 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: "Rosen, Brian" Cc: "'Cullen Jennings'" , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5D42@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1062021642.7417.88.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 17:00:43 -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 Brian said: > sip:pitpbx4826@marconi.com;user=phone means that the call > will be passed to the Pittsburgh PBX gateway calling extension 4826. > You could get to the same phone by dialing > sip:3004826@marconi.com;user=phone, but that may route a different > way (for example, it could be routed to a local gateway, to the > local PBX, and then over a tie line between the local PBX and the > Pittsburgh PBX). My goodness, that is different. While it is a very reasonable "user part", I would not have considered "pitpbx4826" a dial string, and my first hunch would be that it's simply invalid when combined with user=phone. (it probably isn't which means we DO have a spec clarity problem). I would have been much more likely to encode this as sip:4826@pitpbx.marconi.com, which means to me "whatever 4826 means to pitpbx.marconi.com", which is what I think you wanted to express. It might be reasonable for proxy "marconi.com" to route (this is expressible in TRIP) all digit sequences starting with 300 to pitpbx.marconi.com, and potentially even strip off the matched digits so there's no uncertainty at pitpbx. Going this way lets you make a dynamic route-optimization decision at the proxy as to whether it would be more efficient to route via PSTN. In any case, it lets one use 3004826@marconi.com, again with no user=phone. I think you've gone down a very different design path that requires a heck of a lot more work in setting up gateways and intelligence for string-manipulation in those gateways than might have been required by other design paths. It'll work, sort of, with the right equipment, but seems overly complex. Maybe it's time to write a book about how to build usable/useful/maintainable SIP networks for the enterprise? Remember: failures induced by convoluted implementations do not necessarily entail a design flaw in the components used in that implementation. Or, as I like to say, baroque is probably broken. -- 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 Thu Aug 28 04:33:21 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 EAA17032 for ; Thu, 28 Aug 2003 04:33:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDA2-00053i-OH for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:09:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S39Mao019445 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8UN-0003hE-GP; Wed, 27 Aug 2003 18: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 19s4Am-00063K-Df for sip@optimus.ietf.org; Wed, 27 Aug 2003 13:33: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 NAA20598 for ; Wed, 27 Aug 2003 13:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s4Ak-00048b-00 for sip@ietf.org; Wed, 27 Aug 2003 13:33:30 -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 19s4Aj-00047I-00 for sip@ietf.org; Wed, 27 Aug 2003 13:33:29 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RHWc97008404; Wed, 27 Aug 2003 12:32:38 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: "Rosen, Brian" Cc: "'Cullen Jennings'" , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D67@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5D67@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1062005557.7417.41.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 12:32:38 -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 Brian said: > You are the weird one because you have both a phone > and a gateway with the same AOR, unless you are relying > on the gateway not registering as the phone number it > has on its port. We've seen a gateway that did that. I'm sorry somebody sent you a defective gateway. I hope you were able to get it fixed. Gateways, at least multiline gateways, should NEVER EVER register. That's deeply evil! They get calls from PSTN, turn them into SIP INVITES, and send them out (ostensibly, to the default proxy). They get SIP INVITES from their IP side, turn the user part into a phone number, and signal it out to PSTN. Very simple business. Having gateways "register" leads to insanity like trying to send a regisration request for every phone number in the NANP, or in a given area code, or the like. That's whay we have TRIP, with its prefix-ranges and weights. A telephone number is not an address of record. It's the user-part of an address of record and must be evaluated in the context of some domain to be meaningful. By convention, we assume that a telephone number having a leading + is evaluated in the E.164 domain context. It doesn't really have to be (not a MUST), but it's a useful convention. Anything else, we have to "guess at" the context, unless the context is specifically stated in the right-hand-side production of a SIP(S) URI. The user=phone parameter was meant as a hint to help guess the evaluation context. The original argumentation for it was that user=phone would help disambiguate a case where there were cearly two different AORs with the same "user part" in a given domain -- a case that I don't believe we've found to exist. In some environments it is clearly not meaningful. In other environments, it MIGHT be. The question: Is the utility of the parameter in those environments sufficient to justify the complexity that it apparently creates? -- 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 Thu Aug 28 05:17: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 FAA20405 for ; Thu, 28 Aug 2003 05:17: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 19sDq2-0008OJ-7E for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:52:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3qkuq032249 for sip-archive@odin.ietf.org; Wed, 27 Aug 2003 23:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBkd-0006mF-1O; Wed, 27 Aug 2003 21: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 19sAJZ-0000Tp-KH for sip@optimus.ietf.org; Wed, 27 Aug 2003 20:07: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 UAA21161 for ; Wed, 27 Aug 2003 20:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAJX-0003hY-00 for sip@ietf.org; Wed, 27 Aug 2003 20:06:59 -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 19sAJX-0003hE-00 for sip@ietf.org; Wed, 27 Aug 2003 20:06:59 -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 h7S06RgM025078; Wed, 27 Aug 2003 17:06:28 -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 AKW38230; Wed, 27 Aug 2003 16:57:21 -0700 (PDT) Date: Wed, 27 Aug 2003 17:09:38 -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'" , sip@ietf.org To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5D2C@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, August 25, 2003, at 08:49 AM, Rosen, Brian wrote: >> 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? yes. unqualified dial strings are dangerous, and it is trivial to qualify them. Instead, the user=phone parameter should indicate a valid tel URI is in the userpart (which can *contain* a dial string). It is trivial to qualify a dial string and turn it into a tel URI. If you want to send a dial string with the user=phone parameter, then please spend the extra line of code to add the ;phone-context parameter for heaven's sake. > 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 certainly, but I don't believe there is any reason why these dial strings should be sent without a phone-context parameter. > , and I don't think there is any > other reason for user=phone. sending a fully qualified e164 address strikes me as a pretty good reason. > 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? no. a global number is not a dial string. a *dial string* has no globally scoped semantics. the tel URI does. a global number can be *converted* to a dial string in a particular context (at a specific gateway). > I'd propose to > deprecate that (use a tel uri), but allow it for backwards > compatibility i'm proposing the opposite. don't ever send unqualified dial strings with ;user=phone. always use the tel URL format instead. thanks, -rohan > > 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 Thu Aug 28 06:31:22 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 GAA26785 for ; Thu, 28 Aug 2003 06:31:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHuS-0006pR-Ek for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 04:13:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S8Daot026250 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 04:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCnV-0003Hh-BH; Wed, 27 Aug 2003 22:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s835-00022v-0V for sip@optimus.ietf.org; Wed, 27 Aug 2003 17:41: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 RAA10917 for ; Wed, 27 Aug 2003 17:41:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s832-00019t-00 for sip@ietf.org; Wed, 27 Aug 2003 17:41:48 -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 19s831-00019V-00 for sip@ietf.org; Wed, 27 Aug 2003 17:41:47 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 14:51:20 -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 h7RLfF7b012702; Wed, 27 Aug 2003 14:41:16 -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 AHN48497; Wed, 27 Aug 2003 14:41:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 27 Aug 2003 14:41:15 -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: <313680C9A886D511A06000204840E1CF070B5D6A@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'm firmly off topic here but ... I think that TRIP could be very interesting for small GWs too. At one point in time Free World Dialup had a huge number of single port GWs. The trick was knowing which ones were currently busy - they went from 0% to 100% pretty quick and often a very large percentage of them were in use. TRIP was excellent for providing the resource availability information so that you could find a GW that was not in use without probing a bunch of GWs. It also, for this case, moved the administration of what phone numbers this GW could cheaply call to the right place. Clearly in some other cases you want that sort administrative entry centralized. Anyways, I think the discussion of using SIP for registration of PSTN GWs was done to death in IPTEL. Cullen On 8/27/03 11:59, "Rosen, Brian" wrote: > You are thinking about big trunk gateways. > I'm talking about smaller ones. > TRIP is extreme overkill for a 4 or 8 line gateway. > TRIP is unnecessary if all the gateways in a system are > routable by some simple ruleset. > > Registration by the gateway is a Good Thing. > The user part of the AOR is not all that usefull, although > we actually do use it, but it lets the signalling system > know that the gateway is up and running, and how to contact it. > > Brian > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, August 27, 2003 1:33 PM >> To: Rosen, Brian >> Cc: 'Cullen Jennings'; sip@ietf.org >> Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone >> >> >> Brian said: >>> You are the weird one because you have both a phone >>> and a gateway with the same AOR, unless you are relying >>> on the gateway not registering as the phone number it >>> has on its port. We've seen a gateway that did that. >> >> I'm sorry somebody sent you a defective gateway. I hope you >> were able to >> get it fixed. >> >> Gateways, at least multiline gateways, should NEVER EVER register. >> That's deeply evil! They get calls from PSTN, turn them into SIP >> INVITES, and send them out (ostensibly, to the default >> proxy). They get >> SIP INVITES from their IP side, turn the user part into a >> phone number, >> and signal it out to PSTN. Very simple business. Having gateways >> "register" leads to insanity like trying to send a regisration request >> for every phone number in the NANP, or in a given area code, or the >> like. That's whay we have TRIP, with its prefix-ranges and weights. >> >> A telephone number is not an address of record. It's the >> user-part of an >> address of record and must be evaluated in the context of >> some domain to >> be meaningful. By convention, we assume that a telephone >> number having a >> leading + is evaluated in the E.164 domain context. It doesn't really >> have to be (not a MUST), but it's a useful convention. >> Anything else, we >> have to "guess at" the context, unless the context is specifically >> stated in the right-hand-side production of a SIP(S) URI. >> >> The user=phone parameter was meant as a hint to help guess the >> evaluation context. The original argumentation for it was that >> user=phone would help disambiguate a case where there were cearly two >> different AORs with the same "user part" in a given domain -- a case >> that I don't believe we've found to exist. In some environments it is >> clearly not meaningful. In other environments, it MIGHT be. >> >> The question: Is the utility of the parameter in those environments >> sufficient to justify the complexity that it apparently creates? >> >> -- >> 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 Thu Aug 28 07:04: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 HAA00503 for ; Thu, 28 Aug 2003 07:04: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 19sGKh-0000ku-Rw for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 02:32:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S6WZtX002904 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 02:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDjV-0007r4-LI; Wed, 27 Aug 2003 23: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 19sAZW-0001Bd-D1 for sip@optimus.ietf.org; Wed, 27 Aug 2003 20:23: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 UAA22086 for ; Wed, 27 Aug 2003 20:23:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAZU-0003uG-00 for sip@ietf.org; Wed, 27 Aug 2003 20:23:28 -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 19sAZT-0003tU-00 for sip@ietf.org; Wed, 27 Aug 2003 20:23:27 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 17:33: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 h7S0MsgO005704; Wed, 27 Aug 2003 17:22:56 -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 AKW39873; Wed, 27 Aug 2003 17:13:49 -0700 (PDT) Date: Wed, 27 Aug 2003 17:26:01 -0700 Subject: Re: [Sip] More on dial plans and user=phones Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Dean Willis" From: Rohan Mahy In-Reply-To: <004501c36b23$cb2da720$e1036e3f@txdwillis> Message-Id: <34188004-D8EE-11D7-B7EA-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, August 25, 2003, at 09:13 AM, 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. Yes, I am quite embarrassed to say that this is a bug in your (Cisco) phone. > 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. yes, this works just fine, and I have no objection to this. However, If the dynamicsoft proxy wants to be able to handle some phones for users in Europe, they either need: a) a dialplan in their phone to convert a European dial plan into a the (US-specific) dialplan used by the existing dynamicsoft proxy b) be lucky enough that the two dial plans don't have any ambiguous strings (each dial string can be identified as in exactly one dial plan). I don't think this works with existing real NANP and European dial plans c) expect the proxy to interpret the dial plan in the context of the sender of the INVITE. This is a huge pain and a kludge in my opinion considering how easy it is to do d). or d) use a *convention* called ;user=phone to convey a global-number which your proxy or gateway can manipulate appropriately, or if send your dial string as a "local-number" and then add a phone-context parameter with your own domain or global number. I think d) is a far easier, better, cleaner solution if your proxy handles UAs which use different dial plan conventions. If your proxy never handles conflicting addresses, the method which Dean has been using for 3 years also works just fine. > 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. Note, that using user=phone as a convention that an e164 global address may be forthcoming makes understanding another domain's dialing plan much easier. I think this is *a good thing*. > 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. agreed. ideally the dial plan of a SIP telephone will allow me to specify the target domain as well (so I can dial both mci.com and iptel.org directly). thanks, -rohan > -- > 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 Thu Aug 28 07: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 HAA03433 for ; Thu, 28 Aug 2003 07: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 19sJb7-0003aP-BN for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 06:01:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SA1jlJ013781 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 06:01:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGpC-0002Ww-Ef; Thu, 28 Aug 2003 03:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEjq-0002jN-Ij for sip@optimus.ietf.org; Thu, 28 Aug 2003 00: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 AAA16347 for ; Thu, 28 Aug 2003 00:50:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sEjn-0002fF-00 for sip@ietf.org; Thu, 28 Aug 2003 00:50:23 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19sEjm-0002ej-00 for sip@ietf.org; Thu, 28 Aug 2003 00:50:23 -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 h7S4q83s018951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2003 23:52:08 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h7S4q7Gg018949; Wed, 27 Aug 2003 23:52:07 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dwillis@dynamicsoft.com using -f Subject: Re: [Sip] More on dial plans and user=phones From: Dean Willis To: Rohan Mahy Cc: sip@ietf.org In-Reply-To: <34188004-D8EE-11D7-B7EA-0003938AF740@cisco.com> References: <34188004-D8EE-11D7-B7EA-0003938AF740@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1062046327.18915.15.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 23:52:07 -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 On Wed, 2003-08-27 at 19:26, Rohan Mahy wrote: > Deas said: > > > > 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. > > Yes, I am quite embarrassed to say that this is a bug in your (Cisco) > phone. Ask them to please not fix it -- I'd hate to have to throw 200 of these things away. > or d) use a *convention* called ;user=phone to convey a global-number > which your proxy or gateway can manipulate appropriately, or if send > your dial string as a "local-number" and then add a phone-context > parameter with your own domain or global number. > > I think d) is a far easier, better, cleaner solution if your proxy > handles UAs which use different dial plan conventions. If your proxy > never handles conflicting addresses, the method which Dean has been > using for 3 years also works just fine. Ok, I think you are saying that IF (there is a user=phone parameter) THEN (the user part MUST convey a global (+) number) OR (there must be a phone-context parameter specifying a non-global context) which seems reasonable. It seems to me that this is better accomplished with phone-context, where one possible context is "e.164". Howerver, I don't think this is what Brian is saying at all. Indeed, he seems to be embeddeding the phone-context into the user-part. > agreed. ideally the dial plan of a SIP telephone will allow me to > specify the target domain as well (so I can dial both mci.com and > iptel.org directly). I don't think that's a dial-plan issue -- I think it's just a user interface issue, just as my email client lets me enter addresses @cisco.com and @ietf.org on this email. The phone, like the email client, doesn't need to translate anything. -- 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 Thu Aug 28 12:00:04 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 MAA26316 for ; Thu, 28 Aug 2003 12:00: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 19sLyf-00064u-KL for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 08:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SCYDia023363 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 08:34:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sK7P-00069C-Su; Thu, 28 Aug 2003 06:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIOA-00005V-39 for sip@optimus.ietf.org; Thu, 28 Aug 2003 04:44: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 EAA17830 for ; Thu, 28 Aug 2003 04:44:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIO6-0007jC-00 for sip@ietf.org; Thu, 28 Aug 2003 04:44:14 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19sINz-0007j6-00 for sip@ietf.org; Thu, 28 Aug 2003 04:44:13 -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 h7S8ht421494 for ; Thu, 28 Aug 2003 11:44:03 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Aug 2003 11:43:54 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 28 Aug 2003 11:43:54 +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, 28 Aug 2003 11:43:53 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797014@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNtH+oubxroCx7+T0WeSmOWZa0VSwAHuQSw To: , Cc: , X-OriginalArrivalTime: 28 Aug 2003 08:43:54.0076 (UTC) FILETIME=[8310D9C0:01C36D40] 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 No one has been able to convince me why not to use a tel URI for dial = strings and sip URI for pure sip users. When a proxy receives a sip request with a sip request-uri containing a = domain it is responsible for, it looks up it s registration table and = rejects the request with 404 if not found. When a proxy receives a sip request with a tel request-uri without a = phone-context, it forwards the request to its default GW. When a proxy receives a sip request with a tel request-uri with a = phone-context, it forwards the request to the proxy/GW indicated by the = phone-context. Why does a proxy need to translate a tel URI to a sip URI before = forwarding a request? I believe tel:12345;phone-context:example.com and sip:12345@example.com = can be the same or different users. Why do we have to restrict them to = be the same user? Also, why do we need to represent tel:12345;phone-context:example.com as = sip:12345@example.com;user=3Dphone ? what is the gain in this? Regards, Hisham > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, August 28, 2003 1:01 AM > To: Rosen, Brian > Cc: 'Cullen Jennings'; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > Brian said: >=20 > > sip:pitpbx4826@marconi.com;user=3Dphone means that the call > > will be passed to the Pittsburgh PBX gateway calling=20 > extension 4826. =20 > > You could get to the same phone by dialing=20 > > sip:3004826@marconi.com;user=3Dphone, but that may route a different = > > way (for example, it could be routed to a local gateway, to the=20 > > local PBX, and then over a tie line between the local PBX and the=20 > > Pittsburgh PBX). >=20 > My goodness, that is different. While it is a very reasonable "user > part", I would not have considered "pitpbx4826" a dial string, and my > first hunch would be that it's simply invalid when combined with > user=3Dphone. (it probably isn't which means we DO have a spec clarity > problem). I would have been much more likely to encode this as > sip:4826@pitpbx.marconi.com, which means to me "whatever 4826 means to > pitpbx.marconi.com", which is what I think you wanted to express. >=20 > It might be reasonable for proxy "marconi.com" to route (this is > expressible in TRIP) all digit sequences starting with 300 to > pitpbx.marconi.com, and potentially even strip off the=20 > matched digits so > there's no uncertainty at pitpbx. Going this way lets you=20 > make a dynamic > route-optimization decision at the proxy as to whether it=20 > would be more > efficient to route via PSTN. In any case, it lets one use > 3004826@marconi.com, again with no user=3Dphone. >=20 > I think you've gone down a very different design path that requires a > heck of a lot more work in setting up gateways and intelligence for > string-manipulation in those gateways than might have been required by > other design paths. It'll work, sort of, with the right equipment, but > seems overly complex. >=20 > Maybe it's time to write a book about how to build > usable/useful/maintainable SIP networks for the enterprise? >=20 > Remember: failures induced by convoluted implementations do not > necessarily entail a design flaw in the components used in that > implementation. Or, as I like to say, baroque is probably broken. >=20 >=20 > -- > Dean >=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 Aug 28 14:06:56 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 OAA05619 for ; Thu, 28 Aug 2003 14:06: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 19sN9J-0001sJ-2c for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 09:49:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SDnHfH007204 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 09:49:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKl3-0001mN-Pu; Thu, 28 Aug 2003 07:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHVp-0005I1-9H for sip@optimus.ietf.org; Thu, 28 Aug 2003 03:48: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 DAA13027 for ; Thu, 28 Aug 2003 03:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sHVm-0006Uk-00 for sip@ietf.org; Thu, 28 Aug 2003 03:48:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19sHVl-0006Tc-00 for sip@ietf.org; Thu, 28 Aug 2003 03:48:06 -0400 content-class: urn:content-classes:message Subject: RE: 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: Thu, 28 Aug 2003 09:52:23 +0200 Message-ID: <06CF906FE3998C4E944213062009F1622337EC@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNtGaYdC83BwBXnRyidBzXhxJQLkAAG2cTA From: "Stastny Richard" To: "Rohan Mahy" , "Rosen, Brian" Cc: "Adam Roach" , 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 Folks, may I add some more clarification to what Rohan said in his responses: I consider ;user=3Dphone useless, because it does not tell you anything about the dial string or number This means it can be used feasible only at the first proxy knowing exactly what the UA context is. Since this proxy knows this anyway, it does not need ;user=3Dphone at all. Normally this is contained in a sip: URI with the hostpart addressing exactly this proxy anyway by default. If you transmit this to another proxy or gateway, the other gateway may have no idea what you mean, so you have to normalize the information anyway (e.g. by transforming the "dialstring" to an E.164 number eg sip:+xxx@gwy.foo.com or tel:+xxx. Both of them EXACTLY define what you mean. Using sip:1234@foo.com;user=3Dphone does not tell you if this is a private number, a local number or a national number=20 OR if it is a dialstring. ID it is a dalstring, it may be in ANY national or even worse local or private context. So either we add similar things like in the PSTN (e.g. Type of number (TON) or network address Indicator (NAI), but then you have to add also the=20 ;phone-context=3D+431 or vienna.at if you use a TON or NAI national or subsciber number. But for a global system this is useless, because nobody is able to deal with all contexts anyway, so the natural way is to normalize dialstrings or phone numbers at the first possible place knowing what the users context is (this is either the UA itself or the AUS where the user is sending the dialstring or phone number to) and use only fully qualified E.164 numbers everywhere else. The only possibility to keep a non-E.164 number is within a network and in this case the tel: URI using a local number with a phone-context already exists. So a UAS may translate a dialstring received from a UAC in the format sip:**7476691291@fwd.pulver.com either in sip:17476691291@sipphone.com or in a tel:17476691281;phone-context=3Dsipphone.com Remark: If by a freak event sipphone.com gets the NPA 747 really assigned as E.164 number, you may also use either sip:+17476691291 or tel:+17476691291 best regards Richard > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com]=20 > Sent: Thursday, August 28, 2003 2:10 AM > To: Rosen, Brian > Cc: 'Adam Roach'; sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 >=20 > On Monday, August 25, 2003, at 08:49 AM, Rosen, Brian wrote: >=20 > >> As I said in my original post on this topic, unless=20 > someone wants to=20 > >> invest the effort required to definite precise semantics of=20 > >> "user=3Dphone", 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=20 > >> you can put together an i-d that clarifies the precise meaning of=20 > >> "user=3Dphone". > > > > I can do that. > > > > Anyone want to argue that user=3Dphone should not be=20 > interpretted as a=20 > > dial string? >=20 > yes. unqualified dial strings are dangerous, and it is trivial to=20 > qualify them. Instead, the user=3Dphone parameter should indicate a=20 > valid tel URI is in the userpart (which can *contain* a dial string). >=20 > It is trivial to qualify a dial string and turn it into a tel=20 > URI. If=20 > you want to send a dial string with the user=3Dphone parameter, then=20 > please spend the extra line of code to add the ;phone-context=20 > parameter=20 > for heaven's sake. >=20 > > I understand why reading the tea leaves of the > > current RFCs leads to confusion, but I think there is good=20 > reason to=20 > > send dial strings sometimes >=20 > certainly, but I don't believe there is any reason why these dial=20 > strings should be sent without a phone-context parameter. >=20 > > , and I don't think there is any > > other reason for user=3Dphone. >=20 > sending a fully qualified e164 address strikes me as a pretty good=20 > reason. >=20 > > I know that some phones DO have > > internal translations, and they do send user=3Dphone with a global=20 > > number, but that's a valid dial string, no? >=20 > no. a global number is not a dial string. a *dial string* has no=20 > globally scoped semantics. the tel URI does. a global number can be=20 > *converted* to a dial string in a particular context (at a specific=20 > gateway). >=20 > > I'd propose to > > deprecate that (use a tel uri), but allow it for backwards=20 > > compatibility >=20 > i'm proposing the opposite. don't ever send unqualified dial strings=20 > with ;user=3Dphone. always use the tel URL format instead. >=20 > thanks, > -rohan >=20 > > > > 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=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 Aug 28 18:20: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 SAA25230 for ; Thu, 28 Aug 2003 18:20: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 19sQUm-0002On-CU for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 13:23:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SHNeni009162 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 13:23:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sOKe-0004pH-Um; Thu, 28 Aug 2003 11: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 19sK71-00065D-PM for sip@optimus.ietf.org; Thu, 28 Aug 2003 06:34: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 GAA27216 for ; Thu, 28 Aug 2003 06:34:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sK6x-0002Ns-00 for sip@ietf.org; Thu, 28 Aug 2003 06:34:39 -0400 Received: from [80.74.106.10] (helo=nt-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19sK6x-0002Np-00 for sip@ietf.org; Thu, 28 Aug 2003 06:34:39 -0400 Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 13:32:36 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E28A321@nt-mail.tlv.radvision.com> From: Sarit Galanos To: sip@ietf.org Date: Thu, 28 Aug 2003 13:32:35 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] The seventh INVITE transmission - isn't it a waste Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, This question was posted to the sip-implementers mailing list and no one could come up with a logical explanation so here it is again: For UDP the client transaction retransmits INVITE requests at an interval that starts at T1 seconds and doubles after every retransmission. This should continue until timer B expires - 64*T1 msec. The result is that the seventh transmission takes place after 63*T1 milliseconds: 0 Invite sent 1st retrans T1(tme interval) (T1) time since first transmission after this expiry 2nd retrans 2_T1 (T1 + 2_T1) ==>> 3T1 3rd retrans 4_T1 (T1 + 2_T1 + 4_T1) ==>> 7T1 4th retrans 8_T1 (T1 + 2_T1 + 4_T1 + 8_T1) ==>> 15T1 5th retrans 16_T1 (T1 + 2_T1 + 4_T1 + 8_T1 +16_T1) ==>> 31T1 6th retrans 32_T1 (T1 + 2_T1 + 4_T1 + 8_T1 +16_T1 + 32_T1) ==>> 63T1 Since T1 defaults to 500 msec, the transaction will terminate 500 msec after the last transmission. My question is: Isn't it a waste to retransmit the request 500 msec before the transaction terminates? Regards, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 28 21:05:11 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 VAA07436 for ; Thu, 28 Aug 2003 21:05:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTfV-0004T0-IK for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 16:46:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SKkvxF017166 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 16:46:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQoU-0003qv-Sl; Thu, 28 Aug 2003 13: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 19sN2Y-0001b5-CA for sip@optimus.ietf.org; Thu, 28 Aug 2003 09:42: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 JAA14609 for ; Thu, 28 Aug 2003 09:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sN2W-0007BF-00 for sip@ietf.org; Thu, 28 Aug 2003 09:42:16 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19sN2V-0007Ah-00 for sip@ietf.org; Thu, 28 Aug 2003 09:42:15 -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 JAA17552; Thu, 28 Aug 2003 09:41: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 JAA19573; Thu, 28 Aug 2003 09:41:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 09:41:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D7B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Stastny Richard'" , Rohan Mahy Cc: Adam Roach , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 09:41: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: , Boy, are we all over the map. I'm not sure there is any way to get consensus on this. There are a couple of things we can get done however, so lets start there. Tel URIs explicitly MAY NOT be dial strings. They can be phone numbers within a context, but not dial strings. It's certainly the case that there is overlap in many dial plans between "a phone number within a context" and a dial string, but they are not the same thing. In general, if you have a SIP phone without a dial sting expansion mechanism built in, it should not be sending tel uris. If you do have a phone with dialstring expansion, than I think you SHOULD send a tel uri, and not send a sip uri with user=phone. We know that there are phones out there that don't do this, but could we agree that the above is where we SHOULD head? For the moment, let's defer the discussion of whether a sip phone without dialstring expansion sends any parameters on the INVITE. Gateways, I believe, should be generous in what they accept. So if a gateway gets a tel uri, a sip uri with or without the user=phone parameter, and the phone number is within its area of responsibility, it should accept the INVITE and place the call. Any objections? Can we agree on what a sipphone should be prepared to accept? Surely, it should accept a sip uri with a numeric username if that is (one of) its AoR(s). Again, being generous, it should accept such an INVITE with or without a user=phone. Should a phone accept a tel uri? Is that a SHOULD or a MAY? The next thing that might be easy to agree on is what a proxy that translates a tel URI to the routed (or at least routable) sip uri does. Should it have add a parameter, and what should that parameter be? I had been thinking we should create a new parameter for this purpose. I note that we have had some discussion on another thread that talked about marking a URI that had been ENUM translated. I'll stop there. 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 Thu Aug 28 21:24: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 VAA09012 for ; Thu, 28 Aug 2003 21:24: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 19sUG9-0006GR-KU for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 17:24:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SLOn7W024072 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 17:24:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQvG-0004Vb-RS; Thu, 28 Aug 2003 13: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 19sNJ9-0002LJ-Qw for sip@optimus.ietf.org; Thu, 28 Aug 2003 09:59: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 JAA15994 for ; Thu, 28 Aug 2003 09:59:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNIv-0007W2-00 for sip@ietf.org; Thu, 28 Aug 2003 09:59:13 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19sNIu-0007VO-00 for sip@ietf.org; Thu, 28 Aug 2003 09:59:12 -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 JAA18370; Thu, 28 Aug 2003 09:58:41 -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 JAA22506; Thu, 28 Aug 2003 09:58:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 09:58:40 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D7C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 09:58: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: , > My goodness, that is different. While it is a very reasonable "user > part", I would not have considered "pitpbx4826" a dial string, and my > first hunch would be that it's simply invalid when combined with > user=phone. (it probably isn't which means we DO have a spec clarity > problem). I would have been much more likely to encode this as > sip:4826@pitpbx.marconi.com, which means to me "whatever 4826 means to > pitpbx.marconi.com", which is what I think you wanted to express. No, all the usernames within this system are within the local domain, and it's not a good idea for anyone but the routing proxy to know which host is the destination for a given username/phone number. The proxy might translate pitpbx4826@marconi.com to 4826@pitpbx.marconi.com, but we don't hand out IP addresses, or even hostnames, of specific gateways. pitpbx4826 means "extension 4826 on the gateway that supports that extension on the Pitt PBX". Today, that could be pitpbx.marconi.com, but tomorrow it might be some other host. > > It might be reasonable for proxy "marconi.com" to route (this is > expressible in TRIP) all digit sequences starting with 300 to > pitpbx.marconi.com, and potentially even strip off the > matched digits so > there's no uncertainty at pitpbx. Going this way lets you > make a dynamic > route-optimization decision at the proxy as to whether it > would be more > efficient to route via PSTN. In any case, it lets one use > 3004826@marconi.com, again with no user=phone. That's the normal routing mechanism, and indeed we could use TRIP for normal routing. However, most of these routing decisions are made on "least cost route" metrics. The problem is that sometimes, that is not the appropriate mechanism to use. > > I think you've gone down a very different design path that requires a > heck of a lot more work in setting up gateways and intelligence for > string-manipulation in those gateways than might have been required by > other design paths. It'll work, sort of, with the right equipment, but > seems overly complex. The gateways require no intelligence whatsoever. The only intelligence is expressed in a bunch of regexps on the proxy. The gateways always get a simple sip:xxxx@.marconi.com;user=phone. In the case we are discussing, the marconi.com proxy matches pitpbx4826@marconi.com and translated that to 4826@pitgw1.marconi.com > > Maybe it's time to write a book about how to build > usable/useful/maintainable SIP networks for the enterprise? I agree > > Remember: failures induced by convoluted implementations do not > necessarily entail a design flaw in the components used in that > implementation. Or, as I like to say, baroque is probably broken. I don't think what we do is complex at all (we'll, I'll confess that we have evolved our routing rule grammars quite a bit to avoid getting things too complicated). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 28 23:01: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 XAA16111 for ; Thu, 28 Aug 2003 23: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 19sWtn-0004ib-H7 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 20:13:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0DtUg018078 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 20:13:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUBY-00061v-Rx; Thu, 28 Aug 2003 17: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 19sRJD-0005yX-PW for sip@optimus.ietf.org; Thu, 28 Aug 2003 14:15: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 OAA06300 for ; Thu, 28 Aug 2003 14:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sRJB-0004OP-00 for sip@ietf.org; Thu, 28 Aug 2003 14:15:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19sRJA-0004Ny-00 for sip@ietf.org; Thu, 28 Aug 2003 14:15:44 -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 OAA27491; Thu, 28 Aug 2003 14:15:12 -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 OAA01616; Thu, 28 Aug 2003 14:15:13 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 14:15:13 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D81@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" , hisham.khartabil@nokia.com Cc: fluffy@cisco.com, sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 14:15: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: , > 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 From exim@www1.ietf.org Thu Aug 28 23:38: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 XAA19665 for ; Thu, 28 Aug 2003 23:38: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 19sXa8-0007NQ-R6 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 20:57:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0vePk028337 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 20:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUP4-0006lE-1w; Thu, 28 Aug 2003 17: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 19sR9C-00055r-4K for sip@optimus.ietf.org; Thu, 28 Aug 2003 14:05: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 OAA05553 for ; Thu, 28 Aug 2003 14:05:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sR98-0004CV-00 for sip@ietf.org; Thu, 28 Aug 2003 14:05:22 -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 19sR97-0004Bu-00 for sip@ietf.org; Thu, 28 Aug 2003 14:05:21 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7SI3c97019120; Thu, 28 Aug 2003 13:03:38 -0500 Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone From: Dean Willis To: hisham.khartabil@nokia.com Cc: Brian.Rosen@marconi.com, fluffy@cisco.com, sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797014@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB701797014@esebe019.ntc.nokia.com> Content-Type: text/plain Message-Id: <1062093817.18183.37.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 28 Aug 2003 13:03:38 -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-08-28 at 03:43, hisham.khartabil@nokia.com wrote: > No one has been able to convince me why not to use a tel URI > for dial strings and sip URI for pure sip users. > > When a proxy receives a sip request with a sip request-uri containing > a domain it is responsible for, it looks up it s registration table > and rejects the request with 404 if not found. What if the call originator didn't KNOW that the request was going to end up on a gateway? Can the proxy send the request to a gateway anyhow? Proxies can reasonably do a LOT more than just registration based routing. The proxy in my office, for example, executes a user-supplied CPL script, which allows the specification of actions to take (like forwarding the call to my mobile phone) if there is no registration. > When a proxy receives a sip request with a tel request-uri without a phone-context, it forwards the request to its default GW. or applies whatever other routing rules it would apply, for example prefix matching in TRIP. > When a proxy receives a sip request with a tel request-uri with a phone-context, it forwards the request to the proxy/GW indicated by the phone-context. Phone-context is NOT currently a globally routable thing. It provides, at best, a locally-meaningful hint about how one might proceed. 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). > Why does a proxy need to translate a tel URI to a sip URI before forwarding a request? Because its routing table might tell it that the gateway to handle that tel URI is remote, and the other SIP proxies between here and there might have different, even conflicting, routing policies for TEL URIs. > I believe tel:12345;phone-context:example.com and sip:12345@example.com can be the same or different users. Why do we have to restrict them to be the same user? > > Also, why do we need to represent tel:12345;phone-context:example.com as sip:12345@example.com;user=phone ? what is the gain in this? Because @example.com is probably globally routable (at least, we have well-documented resolution procedures), and phone-context:example.com is probably not globally routable (we do NOT have well-documented resolution procedures). -- 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 Thu Aug 28 23:40: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 XAA19928 for ; Thu, 28 Aug 2003 23:40: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 19sXf4-0007Zl-Bx for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 21:02:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T12kgY029096 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 21:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUGM-0006Hm-WF; Thu, 28 Aug 2003 17: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 19sR5N-0004lz-8s for sip@optimus.ietf.org; Thu, 28 Aug 2003 14:01: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 OAA05232 for ; Thu, 28 Aug 2003 14:01:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sR5K-00047x-00 for sip@ietf.org; Thu, 28 Aug 2003 14:01:26 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19sR5K-000477-00 for sip@ietf.org; Thu, 28 Aug 2003 14:01:26 -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 h7SI0td8028080; Thu, 28 Aug 2003 14:00:55 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 13:00:55 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863DA@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Sarit Galanos'" , sip@ietf.org Subject: RE: [Sip] The seventh INVITE transmission - isn't it a waste Date: Thu, 28 Aug 2003 13:00:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Sarit Galanos [mailto:Sarit@radvision.com] writes: > Isn't it a waste to retransmit the request 500 msec before > the transaction terminates? No. Check 3261; 500 ms is an estimate for the round trip time for a message. In theory, it is exactly long enough for a response to come back. /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 Aug 29 01:47: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 BAA00715 for ; Fri, 29 Aug 2003 01:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZv8-00060b-GY for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23:27:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3RUDr023091 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23:27:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXPq-0006h3-1f; Thu, 28 Aug 2003 20: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 19sT76-0002YP-US for sip@optimus.ietf.org; Thu, 28 Aug 2003 16:11: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 QAA14638 for ; Thu, 28 Aug 2003 16:11:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sT75-000617-00 for sip@ietf.org; Thu, 28 Aug 2003 16:11:23 -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 19sT74-00060i-00 for sip@ietf.org; Thu, 28 Aug 2003 16:11:22 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2003 13:10:53 -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 h7SKAp7b024772; Thu, 28 Aug 2003 13:10: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 AHO51157; Thu, 28 Aug 2003 13:10:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 28 Aug 2003 13:10:49 -0700 From: Cullen Jennings To: CC: Cullen Jennings Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Update of display name during a call Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 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 From exim@www1.ietf.org Fri Aug 29 02:24:15 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 CAA15633 for ; Fri, 29 Aug 2003 02:24:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19saK6-0007Yx-6e for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3rIuL029062 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23: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 19sY5W-0000yb-GZ; Thu, 28 Aug 2003 21:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUhu-0007Py-RH for sip@optimus.ietf.org; Thu, 28 Aug 2003 17:53: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 RAA22228 for ; Thu, 28 Aug 2003 17:53:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sUhs-00001S-00 for sip@ietf.org; Thu, 28 Aug 2003 17:53:28 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19sUhr-00001G-00 for sip@ietf.org; Thu, 28 Aug 2003 17:53:27 -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 RAA04192; Thu, 28 Aug 2003 17:52: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 RAA00167; Thu, 28 Aug 2003 17:52:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 17:52:56 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D91@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Adam Roach'" , "'Dean Willis'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 17:52: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: , Yeah, we could do that, although there aren't many devices out there who can handle a phone-context in a sip uri. It's not an exact match with the problem, because we're explicitly forcing a route, rather than restricting to a context, but there is no doubt we could get what we want from such a syntax. Really, the context is pitt.marconi.com. If we specified sip:4826;phone-context=pitt.marconi.com; user=phone we would expect to use the regular routing rules, which would normally be something that was least-cost. The example used 3006826, which is the 7 digit number plan version of the same thing (300 prefix is equivalent to pitt.marconi.com). Making up a new set of contexts and using that to force routing is a stretch, but it works. I think our devices would actually allow us to put such a tel uri under a softkey, so we probably could actually implement it. We'd have to change the proxy some, but not much, as it's all a string matching regexp thingy. Brian > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, August 28, 2003 5:37 PM > To: 'Rosen, Brian'; 'Dean Willis' > Cc: sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone > > > Rosen, Brian [mailto:Brian.Rosen@marconi.com] wrote: > > > No, all the usernames within this system are within the > > local domain, and it's not a good idea for anyone but the > > routing proxy to know which host is the destination for > > a given username/phone number. The proxy might translate > > pitpbx4826@marconi.com to 4826@pitpbx.marconi.com, but we > > don't hand out IP addresses, or even hostnames, of specific > > gateways. pitpbx4826 means "extension 4826 on the gateway > > that supports that extension on the Pitt PBX". Today, that > > could be pitpbx.marconi.com, but tomorrow it might be some > > other host. > > Oh! So, what you *really* mean is: > > tel:4826;phone-context=pitpbx > > Which, using the rules in 3261 today, can be transformed to: > > sip:4826;phone-context=pitpbx@marconi.com;user=phone > > /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 Aug 29 02:28: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 CAA16590 for ; Fri, 29 Aug 2003 02:28: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 19saII-0007UG-B7 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23:51:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3pQcI028723 for sip-archive@odin.ietf.org; Thu, 28 Aug 2003 23:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sY1c-0000in-JG; Thu, 28 Aug 2003 21:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUS8-0006ug-Or for sip@optimus.ietf.org; Thu, 28 Aug 2003 17:37: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 RAA21317 for ; Thu, 28 Aug 2003 17:37:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sUS6-0007cr-00 for sip@ietf.org; Thu, 28 Aug 2003 17:37:10 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19sUS5-0007cR-00 for sip@ietf.org; Thu, 28 Aug 2003 17:37:09 -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 h7SLaad8028948; Thu, 28 Aug 2003 17:36:36 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 16:36:36 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863E4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , "'Dean Willis'" Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 16:36: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] wrote: > No, all the usernames within this system are within the > local domain, and it's not a good idea for anyone but the > routing proxy to know which host is the destination for > a given username/phone number. The proxy might translate > pitpbx4826@marconi.com to 4826@pitpbx.marconi.com, but we > don't hand out IP addresses, or even hostnames, of specific > gateways. pitpbx4826 means "extension 4826 on the gateway > that supports that extension on the Pitt PBX". Today, that > could be pitpbx.marconi.com, but tomorrow it might be some > other host. Oh! So, what you *really* mean is: tel:4826;phone-context=pitpbx Which, using the rules in 3261 today, can be transformed to: sip:4826;phone-context=pitpbx@marconi.com;user=phone /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 Aug 29 02:29: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 CAA16655 for ; Fri, 29 Aug 2003 02:29: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 19sam3-0000YG-9J for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 00:22:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T4MB7d002063 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 00:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXzf-0000T7-5g; Thu, 28 Aug 2003 21:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUMI-0006d5-Pz for sip@optimus.ietf.org; Thu, 28 Aug 2003 17:31: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 RAA20814 for ; Thu, 28 Aug 2003 17:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sUMG-0007Vq-00 for sip@ietf.org; Thu, 28 Aug 2003 17:31:08 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19sUMF-0007V1-00 for sip@ietf.org; Thu, 28 Aug 2003 17:31: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 h7SLUFd8028929; Thu, 28 Aug 2003 17:30:25 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 16:30:15 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863E3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , "'Stastny Richard'" , Rohan Mahy Cc: Adam Roach , sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Thu, 28 Aug 2003 16:30: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: > Boy, are we all over the map. > > I'm not sure there is any way to get consensus on this. I don't think there's a way to get *unanimity* on this. I don't think you can even get an overwhelming majority opinion. However, if you count the number of people who have posted on this thread and compare it with the number of people on this thread who have said, "deprecate it", I think you'll find that we already have a very rough consensus. /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 Aug 29 03:27: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 DAA21510 for ; Fri, 29 Aug 2003 03:27: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 19sdVA-0003xi-9L for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 03:16:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7GuWg015173 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 03:16:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sd4E-0002dr-V7; Fri, 29 Aug 2003 02:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sbbO-0003Is-Ln for sip@optimus.ietf.org; Fri, 29 Aug 2003 01:15: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 BAA27732 for ; Fri, 29 Aug 2003 01:15:08 -0400 (EDT) From: jdrosen@dynamicsoft.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sbbL-0000Jo-00 for sip@ietf.org; Fri, 29 Aug 2003 01:15:11 -0400 Received: from 12-237-249-166.client.attbi.com ([12.237.249.166] helo=SONUS-VX6ZUTCQC) by ietf-mx with esmtp (Exim 4.12) id 19sbbA-0000Je-00 for sip@ietf.org; Fri, 29 Aug 2003 01:15:01 -0400 To: Date: Fri, 29 Aug 2003 0:09:53 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00C8E561" Message-Id: Subject: [Sip] Your details Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 multipart message in MIME format --_NextPart_000_00C8E561 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00C8E561 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: your_document.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00C8E561-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 29 08:57:10 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 IAA19928 for ; Fri, 29 Aug 2003 08:57:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shUP-0001tC-Rt for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 07:32:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TBWOlk007195 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 07:32:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgTo-0007LJ-Vq; Fri, 29 Aug 2003 06:27:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19seE8-0007EN-Kw for sip@optimus.ietf.org; Fri, 29 Aug 2003 04: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 EAA25036 for ; Fri, 29 Aug 2003 04:03: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 19seE6-0004EX-00 for sip@ietf.org; Fri, 29 Aug 2003 04:03:22 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19seE4-0004ES-00 for sip@ietf.org; Fri, 29 Aug 2003 04:03:21 -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 h7T83AB23247 for ; Fri, 29 Aug 2003 11:03:11 +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, 29 Aug 2003 11:03:10 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 11:03:10 +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 11:03:09 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797028@esebe019.ntc.nokia.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNtjwPsg/KuTTCXTJGEIAZ6/ORM0gAdN24w To: Cc: , , X-OriginalArrivalTime: 29 Aug 2003 08:03:10.0362 (UTC) FILETIME=[FCE96FA0:01C36E03] 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 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? /Hisham > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, August 28, 2003 9:04 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; fluffy@cisco.com; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 >=20 > On Thu, 2003-08-28 at 03:43, hisham.khartabil@nokia.com wrote: > > No one has been able to convince me why not to use a tel URI=20 > > for dial strings and sip URI for pure sip users. > >=20 > > When a proxy receives a sip request with a sip request-uri=20 > containing=20 > > a domain it is responsible for, it looks up it s registration table=20 > > and rejects the request with 404 if not found. >=20 > What if the call originator didn't KNOW that the request was going to > end up on a gateway? Can the proxy send the request to a=20 > gateway anyhow? >=20 > Proxies can reasonably do a LOT more than just registration based > routing. The proxy in my office, for example, executes a user-supplied > CPL script, which allows the specification of actions to take (like > forwarding the call to my mobile phone) if there is no registration. >=20 > > When a proxy receives a sip request with a tel request-uri=20 > without a phone-context, it forwards the request to its default GW. >=20 > or applies whatever other routing rules it would apply, for example > prefix matching in TRIP. >=20 > > When a proxy receives a sip request with a tel request-uri=20 > with a phone-context, it forwards the request to the proxy/GW=20 > indicated by the phone-context. >=20 > Phone-context is NOT currently a globally routable thing. It provides, > at best, a locally-meaningful hint about how one might proceed. >=20 >=20 > Citing an example inf RFC 2806: >=20 > tel:0w003585551234567;phone-context=3D+3585551234 >=20 > This URL places a voice call to the given number. The number format > is intended for local use: the first zero opens an outside=20 > line, the > "w" character waits for a second dial tone, and the number already > has the international access code appended to it ("00").=20 > 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=20 > local entity's > phone number starts with the given string (perhaps singling out a > company-wide block of telephone numbers). >=20 > > Why does a proxy need to translate a tel URI to a sip URI=20 > before forwarding a request? >=20 > Because its routing table might tell it that the gateway to=20 > handle that > tel URI is remote, and the other SIP proxies between here and there > might have different, even conflicting, routing policies for TEL URIs. >=20 > > I believe tel:12345;phone-context:example.com and=20 > sip:12345@example.com can be the same or different users. Why=20 > do we have to restrict them to be the same user? > >=20 > > Also, why do we need to represent=20 > tel:12345;phone-context:example.com as=20 > sip:12345@example.com;user=3Dphone ? what is the gain in this? >=20 > Because @example.com is probably globally routable (at least, we have > well-documented resolution procedures), and=20 > phone-context:example.com is > probably not globally routable (we do NOT have well-documented > resolution procedures). >=20 > -- > Dean >=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 Aug 29 14:20: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 OAA20650 for ; Fri, 29 Aug 2003 14:20: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 19sm16-0008W8-RQ for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 12:22:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TGMSTk032733 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 12:22:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl0S-0005Eo-G4; Fri, 29 Aug 2003 11:17:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sjRE-0008Cy-4C for sip@optimus.ietf.org; Fri, 29 Aug 2003 09:37: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 JAA23029 for ; Fri, 29 Aug 2003 09:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sjRC-00038X-00 for sip@ietf.org; Fri, 29 Aug 2003 09:37:14 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19sjRB-00037z-00 for sip@ietf.org; Fri, 29 Aug 2003 09:37:13 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HKD00A01V3TX7@siemenscomms.co.uk> for sip@ietf.org; Fri, 29 Aug 2003 14:35:53 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HKD00AFRV3TIT@siemenscomms.co.uk>; Fri, 29 Aug 2003 14:35:53 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Aug 2003 14:36:42 +0100 Content-return: allowed Date: Fri, 29 Aug 2003 14:31:40 +0100 From: "Elwell, John" Subject: RE: [Sip] Update of display name during a call To: "'Cullen Jennings'" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266761FCA2@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, 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 Aug 29 19:07:11 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 TAA16084 for ; Fri, 29 Aug 2003 19:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sq6B-0003Fw-4v for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 16:43:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TKhw8k012457 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 16:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snvj-0005Pp-6c; Fri, 29 Aug 2003 14: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 19sl0M-0005DQ-7e for sip@optimus.ietf.org; Fri, 29 Aug 2003 11:17: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 LAA01950 for ; Fri, 29 Aug 2003 11:17:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sl0L-0005OB-00 for sip@ietf.org; Fri, 29 Aug 2003 11:17:37 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19sl0K-0005Nw-00 for sip@ietf.org; Fri, 29 Aug 2003 11:17: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 LAA24870; Fri, 29 Aug 2003 11:17: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 LAA24005; Fri, 29 Aug 2003 11:17:05 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 11:17:05 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5D97@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , Dean Willis , hisham.khartabil@nokia.com Cc: sip@ietf.org Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 29 Aug 2003 11:17:03 -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's all in what you are talking about. SIP itself doesn't need such things, but we need to transport such strings as part of an INVITE to a gateway connected to the PSTN or a private DTMF based phone system. We could invent a new mechanism, or redefine an existing mechanism, or do what we do now; put it in the userpart of a sip uri. We could argue about whether such a string should or should not have user=phone :) Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, August 29, 2003 10:54 AM > To: Brian Rosen; Dean Willis; hisham.khartabil@nokia.com > Cc: sip@ietf.org > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone > > > > 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 Aug 29 19:10: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 TAA16369 for ; Fri, 29 Aug 2003 19:10: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 19sqRF-00041w-Uj for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:05:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TL5iK8015430 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 17:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19soLp-0006wj-Rf; Fri, 29 Aug 2003 14: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 19so1H-0005uL-Pi for sip@optimus.ietf.org; Fri, 29 Aug 2003 14:30: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 OAA21261 for ; Fri, 29 Aug 2003 14:30:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19so1F-00038O-00 for sip@ietf.org; Fri, 29 Aug 2003 14:30:45 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 19so1E-00036g-00 for sip@ietf.org; Fri, 29 Aug 2003 14:30:44 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h7TITcSm003999; Fri, 29 Aug 2003 14:29:38 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 14:27:34 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AAEB@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "Gunn, Janet" , "'Henning Schulzrinne'" , "'James M. Polk'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-resource-priority-02 draft Date: Fri, 29 Aug 2003 14:27: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: , I am confused by the following paragraph in section 4.4 " Following standard behavior (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with response code 420 (Bad Extension) if it does not understand the resource priority mechanism." What is a "resource priority mechanism"? Earlier, in the introduction, you say " Existing implementations of RFC 3261 that do not participate in this mechanism follow the normal rules of RFC 3261, Section 8.2.2: " If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message." Thus, the use of this mechanism is wholly invisible to existing implementations." which seems to contradict 4.4. Does the paragraph in 4.4 really mean " Following standard behavior (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with response code 420 (Bad Extension) if it does not understand the resource priority namespace."? Or is the distinction, rather , between the case in which the "Require" header is, and is not, present? In that case should, perhaps, the text in the introduction should be changed to read " Existing implementations of RFC 3261 that do not participate in this mechanism follow the normal rules of RFC 3261, Section 8.2.2: " If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message." Thus, the use of this mechanism is wholly invisible to existing implementations unless the request includes the Require header field with the Resource-Priority option flag." Janet _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 29 20:52:25 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 UAA23276 for ; Fri, 29 Aug 2003 20:52:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stvC-0004yk-D5 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 20:48:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U0mrbp019079 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 20:48:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sto6-0004nx-0S; Fri, 29 Aug 2003 20:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sq8b-0003M0-Nj for sip@optimus.ietf.org; Fri, 29 Aug 2003 16:46: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 QAA03542 for ; Fri, 29 Aug 2003 16:46:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sq8Z-0006jO-00 for sip@ietf.org; Fri, 29 Aug 2003 16:46:27 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19sq8Y-0006in-00 for sip@ietf.org; Fri, 29 Aug 2003 16:46:26 -0400 content-class: urn:content-classes:message Subject: 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: Fri, 29 Aug 2003 22:50:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1622337F6@oefeg-s02.oefeg.loc> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-index: AcNuPPLbcMlKwRMIQqKuRrlZbfZmZAABXzBAAAsFV9g= 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 PiA+IFNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhpcyBtZXNzYWdlIHRvIG11bmljaC5l eGFtcGxlLmNvbT8NCj4gPg0KPiA+IC9IaXNoYW0NCj4gPg0KPg0KPiBUaGUgc2FtZSB3YXkgaXQg cm91dGVzIHNpcDpmbHVmZnlAbXVuaWNoLmV4YW1wbGUuY29tDQoNClRlbGwgdGhhdCB0byBEZWFu IDopIEhlIHRoaW5rcyBpdCBpcyBub3Qgcm91dGFibGUgKHRoYXQncyB0aGUgcG9pbnQgSSB3YXMg dHJ5aW5nIHRvIG1ha2UpLg0KDQpXYXJuaW5nOiB0aGlzIG5lZWRzIE5PVCB0byBiZSB0cnVlIGFu ZCBJTUhPIHRoaXMgcGFydCBvZg0KdGhlIGluZm9ybWF0aW9uYWwgc2VjdGlvbiBpcyBtaXNsZWFk aW5nLiBJbiBzZWN0aW9uIDUuMS40IExvY2FsIG51bWJlcnMNCml0IGlzIGNsZWFybHkgc3RhdGVk Og0KIA0KIlRoZXJlIGFyZSB0d28gd2F5cyB0byBsYWJlbCB0aGUgY29udGV4dDogdmlhIGEgZ2xv YmFsIG51bWJlciBvciBhbnkgICAgfA0KICAgbnVtYmVyIG9mIGl0cyBsZWFkaW5nIGRpZ2l0cyAo ZS5nLiwgIiszMyIpIGFuZCB2aWEgYSBkb21haW4gbmFtZSwgICAgICB8DQogICBlLmcuLCAiaG91 c3Rvbi5leGFtcGxlLmNvbSIuIFRoZSBjaG9pY2UgYmV0d2VlbiB0aGUgdHdvIGlzIGxlZnQgdG8g ICAgIHwNCiAgIHRoZSAib3duZXIiIG9mIHRoZSBsb2NhbCBudW1iZXIgYW5kIGlzIGdvdmVybmVk IGJ5IHdoZXRoZXIgdGhlcmUgaXMgYSAgfA0KICAgZ2xvYmFsIG51bWJlciBvciBkb21haW4gbmFt ZSB0aGF0IGlzIGEgdmFsaWQgaWRlbnRpZmllciBmb3IgYSAgICAgICAgICB8DQogICBwYXJ0aWN1 bGFyIGxvY2FsIG51bWJlci4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgVGhlIGRvbWFpbiBuYW1lIGRvZXMgbm90IGhhdmUgdG8gcmVzb2x2ZSB0 byBhbnkgYWN0dWFsIGhvc3QsIGJ1dCBNVVNUICB8DQogICBiZSB1bmRlciB0aGUgYWRtaW5pc3Ry YXRpdmUgY29udHJvbCBvZiB0aGUgZW50aXR5IG1hbmFnaW5nIHRoZSBsb2NhbCAgIHwNCiAgIHBo b25lIGNvbnRleHQuICINCiANClNpbmNlIHRoZSBkb21haW4gbmFtZSBkb2VzIG5vdCBoYXZlIHRv IHJlc29sdmUgdG8gYW4gYWN0dWFsIGhvc3QsDQpvbmUgY2Fubm90IHJlbHkgb24gdGhpcywgc28g eW91ciBzdGF0ZW1lbnQgbWF5IGJlIHdyb25nLg0KIA0KUmljaGFyZA0KDQoJLS0tLS1VcnNwcsO8 bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29t IFttYWlsdG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dIA0KCUdlc2VuZGV0OiBGciAyOS4w OC4yMDAzIDE3OjMxIA0KCUFuOiBmbHVmZnlAY2lzY28uY29tOyBkZWFuLndpbGxpc0Bzb2Z0YXJt b3IuY29tIA0KCUNjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGlldGYub3JnIA0KCUJl dHJlZmY6IFJFOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhv bmUNCgkNCgkNCg0KDQoNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBl eHQgQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0NCgk+IFNlbnQ6IEZy aWRheSwgQXVndXN0IDI5LCAyMDAzIDU6NTEgUE0NCgk+IFRvOiBLaGFydGFiaWwgSGlzaGFtIChO TVAvSGVsc2lua2kpOyBEZWFuIFdpbGxpcw0KCT4gQ2M6IEJyaWFuIFJvc2VuOyBzaXBAaWV0Zi5v cmcNCgk+IFN1YmplY3Q6IFJlOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGgg O3VzZXI9cGhvbmUNCgk+DQoJPg0KCT4gT24gOC8yOS8wMyAxOjAzLCAiaGlzaGFtLmtoYXJ0YWJp bEBub2tpYS5jb20iDQoJPiA8aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20+DQoJPiB3cm90ZToN Cgk+DQoJPiA+IFVuZGVyIHRoZSBpbmZvcm1hdGl2ZSB0ZXh0IGluIDI4MDZiaXMgbGFiZWxlZCAi QSBVc2Ugb2YNCgk+ICJ0ZWwiIFVSSXMgd2l0aCBTSVANCgk+ID4gKEluZm9ybWF0aXZlKSIsIGl0 IHNheXM6DQoJPiA+DQoJPiA+ICINCgk+ID4gICAgICAgICAgICAyLiAgIFRoZSBvdXRib3VuZCBw cm94eSBkb2VzIG5vdCB1c2UgdGhlIHNhbWUgcGhvbmUNCgk+ID4gICAgICAgICAgICAgICAgIGNv bnRleHQsIGJ1dCBjYW4gcm91dGUgdG8gYSBwcm94eSB0aGF0IGhhbmRsZXMgdGhpcw0KCT4gPiAg ICAgICAgICAgICAgICAgcGhvbmUgY29udGV4dC4gVGhpcyByb3V0aW5nIGNhbiBiZSBkb25lIHZp YSBhIGxvb2t1cA0KCT4gPiAgICAgICAgICAgICAgICAgdGFibGUgb3IgdGhlIGRvbWFpbiBuYW1l IG9mIHRoZSBwaG9uZQ0KCT4gY29udGV4dCBtaWdodCBiZQ0KCT4gPiAgICAgICAgICAgICAgICAg c2V0IHVwIHRvIHJlZmxlY3QgdGhlIFNJUCBkb21haW4gbmFtZSBvZiBhIHN1aXRhYmxlDQoJPiA+ ICAgICAgICAgICAgICAgICBwcm94eS4gRm9yIGV4YW1wbGUsIGEgcHJveHkgbWF5IGFsd2F5cyBy b3V0ZSBjYWxscw0KCT4gPiAgICAgICAgICAgICAgICAgd2l0aCB0ZWwgVVJJcyBsaWtlDQoJPiA+ DQoJPiA+ICAgICAgICAgICAgICAgICB0ZWw6MTIzNDtwaG9uZS1jb250ZXh0PW11bmljaC5leGFt cGxlLmNvbQ0KCT4gPg0KCT4gPiAgICAgICAgICAgICAgICAgdG8gdGhlIFNJUCBwcm94eSBsb2Nh dGVkIGF0IG11bmljaC5leGFtcGxlLmNvbS4iDQoJPiA+DQoJPiA+DQoJPiA+IFNvLCBob3cgZG9l cyB0aGUgcHJveHkgcm91dGUgdGhpcyBtZXNzYWdlIHRvIG11bmljaC5leGFtcGxlLmNvbT8NCgk+ ID4NCgk+ID4gL0hpc2hhbQ0KCT4gPg0KCT4NCgk+IFRoZSBzYW1lIHdheSBpdCByb3V0ZXMgc2lw OmZsdWZmeUBtdW5pY2guZXhhbXBsZS5jb20NCgkNCglUZWxsIHRoYXQgdG8gRGVhbiA6KSBIZSB0 aGlua3MgaXQgaXMgbm90IHJvdXRhYmxlICh0aGF0J3MgdGhlIHBvaW50IEkgd2FzIHRyeWluZyB0 byBtYWtlKS4NCgkNCglSZWdhcmRzLA0KCUhpc2hhbQ0KCQ0KCQ0KCT4NCgk+DQoJPg0KCQ0KCV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU2lwIG1haWxp bmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQoJVGhp cyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQoJ VXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3Vy cmVudCBzaXANCglVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0 aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoJDQoNCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 29 23:42: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 XAA05896 for ; Fri, 29 Aug 2003 23:42: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 19swKN-0003sr-LQ for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 23:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U3N3tR014919 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 23:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svCP-0000mz-MQ; Fri, 29 Aug 2003 22:10:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssG2-00006b-9P for sip@optimus.ietf.org; Fri, 29 Aug 2003 19:02: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 TAA15612 for ; Fri, 29 Aug 2003 19:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ssFy-0002zA-00 for sip@ietf.org; Fri, 29 Aug 2003 19:02:15 -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 19ssFx-0002yq-00 for sip@ietf.org; Fri, 29 Aug 2003 19:02: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 h7TN1X97029337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 29 Aug 2003 18:01:33 -0500 From: "Dean Willis" To: , Cc: , Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 29 Aug 2003 18:01:27 -0500 Message-ID: <002f01c36e81$7bf29d80$fe0c0c42@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 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797032@esebe019.ntc.nokia.com> Importance: Normal 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, how does the proxy route this message to munich.example.com? > > >=20 > > > /Hisham > > > > >=20 > > The same way it routes sip:fluffy@munich.example.com >=20 > Tell that to Dean :) He thinks it is not routable (that's the > point I was trying to make). Ah, I see our disconnect. you're talking phone-context as defined in 2806bis. That's "broken", for some definition of the word, and I was phone-context as defined in 2806. The syntax of 2806 looked more like: phone-context-tag =3D "phone-context" phone-context-ident =3D network-prefix / private-prefix network-prefix =3D global-network-prefix / local-network-prefix global-network-prefix =3D "+" 1*phonedigit local-network-prefix =3D 1*(phonedigit / dtmf-digit / pause-character) private-prefix =3D (%x21-22 / %x24-27 / %x2C / %x2F / %x3A / %x3C-40 / %x45-4F / %x51-56 / %x58-60 / %x65-6F / %x71-76 / %x78-7E) *(%x21-3A / %x3C-7E) ; Characters in URLs must follow escaping rules ; as explained in [RFC2396] This lets one encode nearly anything into the phone-context and has no presumtion of global meaningfulness, at least in the private-prefix production. If I remember correctly, it was at my urging that Antti added = phone-context originally. The reason I pushed it was because, at the time, we (of that time, MCI) = were using it to encode trunk-group IDs and switch port numbers and all sorts = of other "non global" stuff. As far as I know, it still works that way = there. The bis changes are dramatically not compatible. I've been hoping Alan Johnston would raise the point, if it still applies. Maybe it doesn't = matter any more. -- 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 Sat Aug 30 01:15: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 BAA10041 for ; Sat, 30 Aug 2003 01:15: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 19sv1m-00085g-Qy for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 21:59:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U1xjbe031041 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 21:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stl5-0004MR-8i; Fri, 29 Aug 2003 20:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sq1G-0002yq-VN for sip@optimus.ietf.org; Fri, 29 Aug 2003 16:38: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 QAA02928 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-0006X2-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-0006Vx-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 h7TKc3w21049; 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: <870397D7C140C84DB081B88396458DAF578BC2@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:38:02 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] SIP MIB-07: SipFTRSupportedTable - is it just for Proxy/Proxy-Req uire? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 previous discussion on the purpose and intent of this table (defined on page 24 of the -07 version of the draft). Tom Taylor in his comments on the -03 was questioning whether this should not also handle the Allow (for methods) and Accept (for media types). This was also Dan's A5 comment from his posting on the -05 version: "A5 - sipFtrSupportedtable - I am questioning if these table design is correct. Are the features similar (identically supported) for a multiple entity (like a proxy and a registrar) which would generate just one row in this table" Right now, it's confusing because the current description only talks about the Require and Proxy-Require headers, however, section 19.2 which is the reference given to RFC 3261 also includes the Supported (and Unsupported) header. Also, it should be noted that section 19.2 discusses the change in SIP requiring IANA registration of all the option tags. Thus, my suggestion would be to change the description to be consistent with 19.2, also including the Supported option tags. And, per Dan's Comment, these headers do not apply equally to each of the entities, so one does question whether the format of this table is suitable. 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 Sat Aug 30 01:16: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 BAA10141 for ; Sat, 30 Aug 2003 01:16: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 19svie-0002QA-Ol for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 22:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U2i4Zt009247 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 22:44:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stmJ-0004an-HH; Fri, 29 Aug 2003 20:39:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sogj-0007sv-AC for sip@optimus.ietf.org; Fri, 29 Aug 2003 15:13: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 PAA25403 for ; Fri, 29 Aug 2003 15:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sogh-0004C3-00 for sip@ietf.org; Fri, 29 Aug 2003 15:13:35 -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 19sogf-0004At-00 for sip@ietf.org; Fri, 29 Aug 2003 15:13:33 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Aug 2003 12:23:37 -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 h7TJD1gM025065; Fri, 29 Aug 2003 12:13:01 -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 AKY67755; Fri, 29 Aug 2003 12:03:41 -0700 (PDT) Date: Fri, 29 Aug 2003 08:11:58 -0700 Subject: Re: [Sip] More on dial plans and user=phones Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org To: Dean Willis From: Rohan Mahy In-Reply-To: <1062046327.18915.15.camel@kevlar.softarmor.com> Message-Id: <22952E54-DA33-11D7-B7EA-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 Wednesday, August 27, 2003, at 09:52 PM, Dean Willis wrote: > On Wed, 2003-08-27 at 19:26, Rohan Mahy wrote: > >> Deas said: >>> >>> 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. >> >> Yes, I am quite embarrassed to say that this is a bug in your (Cisco) >> phone. > > Ask them to please not fix it -- I'd hate to have to throw 200 of these > things away. The proposed "fix" would make it configurable what to send, and to understand what to do if it receives it. You would lose no functionality. >> or d) use a *convention* called ;user=phone to convey a global-number >> which your proxy or gateway can manipulate appropriately, or if send >> your dial string as a "local-number" and then add a phone-context >> parameter with your own domain or global number. >> >> I think d) is a far easier, better, cleaner solution if your proxy >> handles UAs which use different dial plan conventions. If your proxy >> never handles conflicting addresses, the method which Dean has been >> using for 3 years also works just fine. > > Ok, I think you are saying that > IF (there is a user=phone parameter) > THEN > (the user part MUST convey a global (+) number) > OR > (there must be a phone-context parameter specifying a non-global > context) yes exactly. > which seems reasonable. It seems to me that this is better accomplished > with phone-context, where one possible context is "e.164". I'm not sure what you are proposing exactly. Do you want to deprecate user=phone and add a new standard URI parameter called phone-context, or just require the phone-contact user parameter when the SIP URI user parameter is set to phone, or something else? > Howerver, I don't think this is what Brian is saying at all. Indeed, he > seems to be embeddeding the phone-context into the user-part. I think he gave an example where he was not. maybe i just missed something. >> agreed. ideally the dial plan of a SIP telephone will allow me to >> specify the target domain as well (so I can dial both mci.com and >> iptel.org directly). > > I don't think that's a dial-plan issue -- I think it's just a user > interface issue, just as my email client lets me enter addresses > @cisco.com and @ietf.org on this email. The phone, like the email > client, doesn't need to translate anything. what I meant is that if I dial 01134934957777 (the Hilton Barcelona), I want the resulting INVITE to go to capcom with a URI like sip:+34-93-4957777@capcom.net;user=phone , and if I dial 12024561414 (Whitehouse switchboard), I want to the resulting INVITE to go to MCI with a URI like sip:+1-202-4561414@mci.com;user=phone. I can trivially accomplish this with a set of regular expression (for example the following example perl regular expressions). /^01134(\d+)$/sip:\+34-\$1@capcom.net;user=phone/ /^1({3}\d)({7}\d)$/sip:\+1-\$1-\$2@mci.com;user=phone/ I think this is actually a useful feature. thanks, -rohan > -- > 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 Sat Aug 30 02: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 CAA14604 for ; Sat, 30 Aug 2003 02: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 19swL2-0003vR-Pp for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 23:23:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U3NiKg015088 for sip-archive@odin.ietf.org; Fri, 29 Aug 2003 23:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svCm-0000pY-Ic; Fri, 29 Aug 2003 22:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sszD-0002Wp-0v for sip@optimus.ietf.org; Fri, 29 Aug 2003 19:48: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 TAA19331 for ; Fri, 29 Aug 2003 19:48:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sszB-0004OX-00 for sip@ietf.org; Fri, 29 Aug 2003 19:48:57 -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 19sszA-0004O7-00 for sip@ietf.org; Fri, 29 Aug 2003 19:48:56 -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 h7TNmNba005107; Fri, 29 Aug 2003 16:48:24 -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 AHP82308; Fri, 29 Aug 2003 16:48:22 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Aug 2003 16:48:23 -0700 Subject: Re: AW: AW: [Sip] SIPIT Interop problem with ;user=phone From: Cullen Jennings To: Stastny Richard , , Dean Willis CC: Brian Rosen , Message-ID: In-Reply-To: <06CF906FE3998C4E944213062009F1622337F6@oefeg-s02.oefeg.loc> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" 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 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? >>>=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 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 Local numbers > it is clearly stated: >=20 > "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. " >=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 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 >>>=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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Aug 30 02:48: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 CAA26335 for ; Sat, 30 Aug 2003 02:48: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 19sxf1-0007OH-AD for sip-archive@odin.ietf.org; Sat, 30 Aug 2003 00:48:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U4mRbm028406 for sip-archive@odin.ietf.org; Sat, 30 Aug 2003 00:48:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sv8Y-0008Pc-Ly; Fri, 29 Aug 2003 22:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skOh-0003Hq-Ip for sip@optimus.ietf.org; Fri, 29 Aug 2003 10:38: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 KAA29315 for ; Fri, 29 Aug 2003 10:38:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skOd-0004q2-00 for sip@ietf.org; Fri, 29 Aug 2003 10:38:39 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19skOX-0004pX-00 for sip@ietf.org; Fri, 29 Aug 2003 10:38:33 -0400 Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id BAAC684576; Fri, 29 Aug 2003 14:37:30 +0000 (GMT) Received: from WDC1EXC0002.corp.global.level3.com (wdc1exc0002.corp.global.level3.com [171.78.202.206]) by cc26-01.idc1.level3.com (Postfix) with SMTP id 7D30987127; Fri, 29 Aug 2003 14:37:28 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com ([10.1.7.194]) by WDC1EXC0002.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Aug 2003 10:37:28 -0400 Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 29 Aug 2003 08:37:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.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: AW: [Sip] SIPIT Interop problem with ;user=phone Date: Fri, 29 Aug 2003 08:37:26 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013A9A5@idc1exc0004.corp.global.level3.com> Thread-Topic: AW: [Sip] SIPIT Interop problem with ;user=phone Thread-Index: AcNt374zjy6Y3ZWBTq6oP6k9lbuW8gAWsAVw From: "Hearty, John" To: "Adam Roach" Cc: X-OriginalArrivalTime: 29 Aug 2003 14:37:27.0085 (UTC) FILETIME=[116AE5D0:01C36E3B] 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 it helps build consensus any, I suspect there are more folks like myself that have not spoken up yet because we don't interpret user=3Dphone, and thus don't care if it gets depreciated. John Hearty Level3 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Adam > Roach > Sent: Thursday, August 28, 2003 3:30 PM > To: 'Rosen, Brian'; 'Stastny Richard'; Rohan Mahy > Cc: Adam Roach; sip@ietf.org > Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=3Dphone >=20 > Rosen, Brian [mailto:Brian.Rosen@marconi.com] writes: >=20 > > Boy, are we all over the map. > > > > I'm not sure there is any way to get consensus on this. >=20 > I don't think there's a way to get *unanimity* on this. >=20 > I don't think you can even get an overwhelming majority > opinion. >=20 > However, if you count the number of people who have posted > on this thread and compare it with the number of people on > this thread who have said, "deprecate it", I think you'll > find that we already have a very rough consensus. >=20 > /a >=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