From exim@www1.ietf.org Fri Jan 2 07:03:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03090 for ; Fri, 2 Jan 2004 07:03:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcO0o-00051m-Tu for sipping-archive@odin.ietf.org; Fri, 02 Jan 2004 07:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i02C2gZi019322 for sipping-archive@odin.ietf.org; Fri, 2 Jan 2004 07:02:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcO0o-00051Z-Qd for sipping-web-archive@optimus.ietf.org; Fri, 02 Jan 2004 07:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03070 for ; Fri, 2 Jan 2004 07:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AcO0f-00025J-00 for sipping-web-archive@ietf.org; Fri, 02 Jan 2004 07:02:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AcNve-0001oL-00 for sipping-web-archive@ietf.org; Fri, 02 Jan 2004 06:57:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AcNtY-0001gt-00 for sipping-web-archive@ietf.org; Fri, 02 Jan 2004 06:55:12 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AcNog-0007wf-E1 for sipping-web-archive@ietf.org; Fri, 02 Jan 2004 06:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AcNoZ-0004bO-AM; Fri, 02 Jan 2004 06:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXItu-00044I-HF for sipping@optimus.ietf.org; Fri, 19 Dec 2003 06:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04448 for ; Fri, 19 Dec 2003 06:34:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXItg-0006kL-00 for sipping@ietf.org; Fri, 19 Dec 2003 06:34:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXItG-0006k6-00 for sipping@ietf.org; Fri, 19 Dec 2003 06:33:55 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AXItG-0006jz-00 for sipping@ietf.org; Fri, 19 Dec 2003 06:33:54 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 12:32:23 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [sipping] comment on draft-polk-sipping-location-requirements -01.txt Date: Fri, 19 Dec 2003 12:32:22 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D8701602BB7@parmhs4.rd.francetelecom.fr> Thread-Topic: [sipping] comment on draft-polk-sipping-location-requirements -01.txt thread-index: AcPFsM9u//0JqP5LSPWafP5ZbNRk8gAco20Q From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: "Rosen, Brian" , , Cc: , "Henning Schulzrinne" , "Jonathan Rosenberg" X-OriginalArrivalTime: 19 Dec 2003 11:32:23.0504 (UTC) FILETIME=[C56EE500:01C3C623] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Two points here : =20 First I doubt that there will be a single world wide set of requirements = for emergency calls. Second, a requirement listed in the original draft was for a proxy to be = able to give its idea of the terminal location (originally by asserting = the location given by the terminal). However, it may be easier for a = proxy to insert its own info about the location of the terminal rather = than to assert the info given by the terminal. It also let the = possibility to the called party to get both pieces of information which = is useful information as pointed out by Jonathan. Both pieces of = information shall be passed on. S=E9bastien Prouvost France T=E9l=E9com R&D/DAC/CAR -----Message d'origine----- De : Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 Envoy=E9 : jeudi 18 d=E9cembre 2003 22:48 =C0 : 'Mpierce1@aol.com'; mhammer@cisco.com Cc : sipping@ietf.org Objet : RE: [sipping] comment on = draft-polk-sipping-location-requirements -01.txt And NENA is working on such requirements, and is starting to engage = other=20 organizations in other parts of the world. It has not been decided = whether=20 there will be multiple, possibly conflicting requirements sent in from=20 different organizations, or whether an effort will be mounted to = negotiate=20 a single set of requirements. I favor the latter, because we don't have = the expertise in the IETF to deal with conflicts if they were to arise. = I'd ask that anyone who knows people who should be involved (NENA=20 equivalents in other parts of the world), please contact me.=20 Brian -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Thursday, December 18, 2003 3:47 PM To: mhammer@cisco.com Cc: sipping@ietf.org Subject: Re: [sipping] comment on = draft-polk-sipping-location-requirements -01.txt In a message dated 12/18/2003 3:05:36 PM Eastern Standard Time, = mhammer@cisco.com writes:=20 It doesn't say you can't provide more than one type of measurement, does = it? What liability would a carrier assume if the handset using GPS provided = a=20 location to 10 meters, and that got over-ridden by a carrier network = using=20 TOA providing an accuracy of 100 meters, and the ambulance arrives too = late? More than one type of location is not the problem. I believe all the = past discussion was that the "handset" and the "carrier" came up with = conflicting information. If they were not conflicting, then why have = two. If they are conflicting, that is a problem. If the handset gives a = physical location to 10 meters, why would the carrier network bother to = include a value of 100 meters accuracy, if the value from the end user = were within that 100 meters? If it isn't, what should the PSAP do, send = an ambulance to both?=20 If the handset gave a value within 10 meters and the carrier overwrote = it with a value accurate to only 100 meters, there would be serious = liability issues, especially if the requirement were for an accuracy of = 50 feet.=20 Like I said, NENA (or some such organization) needs to say what the = requirements are (in the US). It is silly and hopeless for the IETF to = try to agree on "requirements".=20 Mike=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use = sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jan 5 15:36:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02502 for ; Mon, 5 Jan 2004 15:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbRm-00038s-0H for sipping-archive@odin.ietf.org; Mon, 05 Jan 2004 15:35:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05KZXHV012078 for sipping-archive@odin.ietf.org; Mon, 5 Jan 2004 15:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbRl-00038j-Td for sipping-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 15:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02446 for ; Mon, 5 Jan 2004 15:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbRk-00049o-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:35:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbQB-00043y-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:33:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdbP2-0003wI-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:32:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbON-0002g2-Fi; Mon, 05 Jan 2004 15:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbOE-0002ek-Hs for sipping@optimus.ietf.org; Mon, 05 Jan 2004 15:31:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02138 for ; Mon, 5 Jan 2004 15:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbOC-0003uB-00 for sipping@ietf.org; Mon, 05 Jan 2004 15:31:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbMq-0003mY-00 for sipping@ietf.org; Mon, 05 Jan 2004 15:30:28 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AdbLE-0003cU-00; Mon, 05 Jan 2004 15:28:48 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i05KSIm11231; Mon, 5 Jan 2004 12:28:18 -0800 (PST) Message-Id: <200401052028.i05KSIm11231@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 05 Jan 2004 12:28:18 -0800 Subject: [Sipping] RFC 3665 on Session Initiation Protocol (SIP) Basic Call Flow Examples Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. BCP 75 RFC 3665 Title: Session Initiation Protocol (SIP) Basic Call Flow Examples Author(s): A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers Status: Best Current Practice Date: December 2003 Mailbox: alan.johnston@mci.com, sdonovan@dynamicsoft.com, rsparks@dynamicsoft.com, ccunningham@dynamicsoft.com, kevin.summers@sonusnet.com Pages: 94 Characters: 163159 SeeAlso: BCP 75 I-D Tag: draft-ietf-sipping-basic-call-flows-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3665.txt This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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: <040105122640.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3665 --OtherAccess Content-Type: Message/External-body; name="rfc3665.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040105122640.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jan 5 15:37:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02616 for ; Mon, 5 Jan 2004 15:37:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbTf-0003Wn-CE for sipping-archive@odin.ietf.org; Mon, 05 Jan 2004 15:37:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05KbVrW013555 for sipping-archive@odin.ietf.org; Mon, 5 Jan 2004 15:37:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbTf-0003WY-2U for sipping-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 15:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02599 for ; Mon, 5 Jan 2004 15:37:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbTd-0004HU-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:37:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbS3-0004Cb-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:35:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdbQq-000468-00 for sipping-web-archive@ietf.org; Mon, 05 Jan 2004 15:34:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbQH-0002tr-KX; Mon, 05 Jan 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbPh-0002sx-AH for sipping@optimus.ietf.org; Mon, 05 Jan 2004 15:33:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02286 for ; Mon, 5 Jan 2004 15:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdbPf-0003z0-00 for sipping@ietf.org; Mon, 05 Jan 2004 15:33:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbNq-0003qd-00 for sipping@ietf.org; Mon, 05 Jan 2004 15:31:30 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AdbMU-0003ir-00; Mon, 05 Jan 2004 15:30:06 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i05KU5m12281; Mon, 5 Jan 2004 12:30:05 -0800 (PST) Message-Id: <200401052030.i05KU5m12281@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 05 Jan 2004 12:30:05 -0800 Subject: [Sipping] BCP 76, RFC 3666 on Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. BCP 76 RFC 3666 Title: Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows Author(s): A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers Status: Best Current Practice Date: December 2003 Mailbox: alan.johnston@mci.com, sdonovan@dynamicsoft.com, rsparks@dynamicsoft.com, ccunningham@dynamicsoft.com, kevin.summers@sonusnet.com Pages: 118 Characters: 200478 SeeAlso: BCP 76 I-D Tag: draft-ietf-sipping-pstn-call-flows-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3666.txt This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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: <040105122837.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3666 --OtherAccess Content-Type: Message/External-body; name="rfc3666.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040105122837.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 7 06:08:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02913 for ; Wed, 7 Jan 2004 06:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBY0-0004k6-Lh for sipping-archive@odin.ietf.org; Wed, 07 Jan 2004 06:08:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07B8OAf018226 for sipping-archive@odin.ietf.org; Wed, 7 Jan 2004 06:08:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBY0-0004jt-Ie for sipping-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 06:08:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02867 for ; Wed, 7 Jan 2004 06:08:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeBXw-0001Za-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 06:08:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeBVy-0001Sw-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 06:06:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeBVI-0001N3-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 06:05:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBUm-0003kX-6l; Wed, 07 Jan 2004 06:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBTo-0003j8-8e for sipping@optimus.ietf.org; Wed, 07 Jan 2004 06:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02713 for ; Wed, 7 Jan 2004 06:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeBTk-0001IM-00 for sipping@ietf.org; Wed, 07 Jan 2004 06:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeBS8-0001EF-00 for sipping@ietf.org; Wed, 07 Jan 2004 06:02:20 -0500 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1AeBRV-00017n-00 for sipping@ietf.org; Wed, 07 Jan 2004 06:01:42 -0500 Received: from oleane ([194.206.151.59]) by smtp6.clb.oleane.net with SMTP id i07B1BO0028048 for ; Wed, 7 Jan 2004 12:01:11 +0100 Message-ID: <024c01c3d50e$8c067e00$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Wed, 7 Jan 2004 12:08:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0249_01C3D516.ED802160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Sipping] WiFi Voice Conference - Paris Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0249_01C3D516.ED802160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The WiFi Voice Conference will stand in Paris next May 25 to 28, 2004. QoS, security, roaming, interoperability, architectures : distinguished = experts=20 and key players in the field will address these questions with detailed = and=20 technical explanations.=20 =20 More details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm ------=_NextPart_000_0249_01C3D516.ED802160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The WiFi Voice Conference will stand in Paris next = May 25 to=20 28, 2004.
QoS, security, roaming, interoperability, architectures :=20 distinguished experts
and key players in the field will address = these=20 questions with detailed and
technical explanations. =
 
More=20 details at:
http://www.upperside.fr/wifivoice04/wifivoice04intro.htm<= /A>
------=_NextPart_000_0249_01C3D516.ED802160-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 7 09:26:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11284 for ; Wed, 7 Jan 2004 09:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEdO-00064h-56 for sipping-archive@odin.ietf.org; Wed, 07 Jan 2004 09:26:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07EQA0I023347 for sipping-archive@odin.ietf.org; Wed, 7 Jan 2004 09:26:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEdO-00064U-0s for sipping-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11245 for ; Wed, 7 Jan 2004 09:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEdM-0005E4-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEbV-00059V-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:24:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeEaV-000556-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEaL-0005lK-ES; Wed, 07 Jan 2004 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEZR-0005jI-Dq for sipping@optimus.ietf.org; Wed, 07 Jan 2004 09:22:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10995; Wed, 7 Jan 2004 09:22:01 -0500 (EST) Message-Id: <200401071422.JAA10995@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Jan 2004 09:22:01 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-3pcc-06.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Best Current Practices for Third Party Call Control in the Session Initiation Protocol Author(s) : J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sipping-3pcc-06.txt Pages : 32 Date : 2004-1-6 Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of the SIP for third party call control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-06.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-sipping-3pcc-06.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-sipping-3pcc-06.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: <2004-1-6155833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-3pcc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-3pcc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6155833.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 7 09:50:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12982 for ; Wed, 7 Jan 2004 09:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF0Y-0007D1-E8 for sipping-archive@odin.ietf.org; Wed, 07 Jan 2004 09:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Eo65i027702 for sipping-archive@odin.ietf.org; Wed, 7 Jan 2004 09:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeF0Y-0007Ci-9m for sipping-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12949 for ; Wed, 7 Jan 2004 09:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeF0W-00070M-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEyt-0006wV-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:48:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeExb-0006qm-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 09:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeExZ-0006xq-J1; Wed, 07 Jan 2004 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEwu-0006xG-7R for sipping@optimus.ietf.org; Wed, 07 Jan 2004 09:46:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12765 for ; Wed, 7 Jan 2004 09:46:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEws-0006nJ-00 for sipping@ietf.org; Wed, 07 Jan 2004 09:46:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEvQ-0006ha-00 for sipping@ietf.org; Wed, 07 Jan 2004 09:44:49 -0500 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 1AeEuS-0006YG-00 for sipping@ietf.org; Wed, 07 Jan 2004 09:43:48 -0500 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id RAA14430 for ; Wed, 7 Jan 2004 17:30:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jan 2004 15:43:44 +0100 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A0D5D52@MAILSRV.uns.t-systems.tss> Thread-Topic: Completing URIs with port Thread-Index: AcPVLKar8sGqGJigR9qH3I0AWuxTlA== From: =?iso-8859-2?Q?Szel=E9nyi_Csaba?= To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Completing URIs with port Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, According to RFC3261 chapter 19.1.4 two URIs are not the same if one of = them contains no port description and the other one does contain the = default port. E.g.: sip:bob@biloxi.com (can resolve to different ports) sip:bob@biloxi.com:5060 The CISCO 7960 completes the received URI with the ':5060' string in the = following cases: - when the Contact URI is used as Request-URI in the next request (e.g. = in case of redirection) - when the Record-Route is copied to the Route header in case of loose = routing. Is it legal? IMHO it is not, but I would like to be sure. Thank you very mush for any input in advance! Regards, Szel=E9nyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 7 13:46:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24338 for ; Wed, 7 Jan 2004 13:46:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIh7-0003JZ-4b for sipping-archive@odin.ietf.org; Wed, 07 Jan 2004 13:46:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07IkHpL012737 for sipping-archive@odin.ietf.org; Wed, 7 Jan 2004 13:46:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIh7-0003JM-1F for sipping-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 13:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24290 for ; Wed, 7 Jan 2004 13:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIh4-00050y-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 13:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIfO-0004vW-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 13:44:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeIdz-0004oq-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 13:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIdx-00036L-CJ; Wed, 07 Jan 2004 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIdO-00035N-KS for sipping@optimus.ietf.org; Wed, 07 Jan 2004 13:42:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24075 for ; Wed, 7 Jan 2004 13:42:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIdM-0004l8-00 for sipping@ietf.org; Wed, 07 Jan 2004 13:42:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIba-0004ch-00 for sipping@ietf.org; Wed, 07 Jan 2004 13:40:34 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1AeIZt-0004SX-00 for sipping@ietf.org; Wed, 07 Jan 2004 13:38:49 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4]) by broadsoft.com (8.12.10/8.12.9) with SMTP id i07IcOdD012284; Wed, 7 Jan 2004 13:38:24 -0500 (EST) Reply-To: From: "Brett Tate" To: "=?iso-8859-2?Q?'Szel=E9nyi_Csaba'?=" , Subject: RE: [Sipping] Completing URIs with port Date: Wed, 7 Jan 2004 13:40:41 -0500 Message-ID: <001401c3d54d$c13993c0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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: <29026DD9543DBF4BB2B4F9325683E47A0D5D52@MAILSRV.uns.t-systems.tss> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > According to RFC3261 chapter 19.1.4 two URIs are not the same > if one of them contains no port description and the other one > does contain the default port. E.g.: > > sip:bob@biloxi.com (can resolve to different ports) > sip:bob@biloxi.com:5060 > > The CISCO 7960 completes the received URI with the ':5060' > string in the following cases: > - when the Contact URI is used as Request-URI in the next > request (e.g. in case of redirection) > - when the Record-Route is copied to the Route header in > case of loose routing. > > Is it legal? Within rfc2543, sip:bob@biloxi.com and sip:bob@biloxi.com:5060 were considered equivalent. Within rfc3261, they are no longer considered equivalent. This is one of the various non backward compatibilities. Because the adding of an extraneous port can break rfc3263 functionality within your example, you should inquire when the product intends to become rfc3261 compliant concerning not extraneously adding port 5060. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 7 18:34:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13561 for ; Wed, 7 Jan 2004 18:34:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNBq-0000we-Eq for sipping-archive@odin.ietf.org; Wed, 07 Jan 2004 18:34:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07NYIuF003626 for sipping-archive@odin.ietf.org; Wed, 7 Jan 2004 18:34:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNBq-0000wP-BG for sipping-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 18:34:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13450 for ; Wed, 7 Jan 2004 18:34:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNBn-0000CU-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 18:34:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNAh-00003I-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 18:33:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeN7p-0007fu-00 for sipping-web-archive@ietf.org; Wed, 07 Jan 2004 18:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeN6j-0000RZ-UX; Wed, 07 Jan 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeN5n-0000MY-Qr for sipping@optimus.ietf.org; Wed, 07 Jan 2004 18:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13208 for ; Wed, 7 Jan 2004 18:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeN5f-0007cL-00 for sipping@ietf.org; Wed, 07 Jan 2004 18:27:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeN1C-0007V1-00 for sipping@ietf.org; Wed, 07 Jan 2004 18:23:18 -0500 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 1AeMx5-0007KI-00 for sipping@ietf.org; Wed, 07 Jan 2004 18:19:03 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2004 15:25:48 +0000 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 i07NI1GN004338; Wed, 7 Jan 2004 15:18:02 -0800 (PST) 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 APA93581; Wed, 7 Jan 2004 15:18:00 -0800 (PST) Date: Wed, 7 Jan 2004 15:19:28 -0800 Subject: Re: [Sipping] Completing URIs with port Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: To: =?ISO-8859-1?Q?Szel=E9nyi_Csaba?= From: Rohan Mahy In-Reply-To: <29026DD9543DBF4BB2B4F9325683E47A0D5D52@MAILSRV.uns.t-systems.tss> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The Cisco 7960 does not claim to be fully RFC-3261 compliant. thanks, -rohan On Wednesday, January 7, 2004, at 06:43 AM, Szel=E9nyi Csaba wrote: > Hi, > > According to RFC3261 chapter 19.1.4 two URIs are not the same if one=20= > of them contains no port description and the other one does contain=20 > the default port. E.g.: > > sip:bob@biloxi.com (can resolve to different=20 > ports) > sip:bob@biloxi.com:5060 > > The CISCO 7960 completes the received URI with the ':5060' string in=20= > the following cases: > - when the Contact URI is used as Request-URI in the next request=20 > (e.g. in case of redirection) > - when the Record-Route is copied to the Route header in case of=20 > loose routing. > > Is it legal? IMHO it is not, but I would like to be sure. > > Thank you very mush for any input in advance! > > Regards, > > Szel=E9nyi Csaba > T-Systems RIC > mailto:Csaba.Szelenyi@t-systems.co.hu > +36 1 456 5507 > +36 20 477 7778 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Jan 8 01:50:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26929 for ; Thu, 8 Jan 2004 01:50:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeTzx-0003Ux-Ef for sipping-archive@odin.ietf.org; Thu, 08 Jan 2004 01:50:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i086oTg4013443 for sipping-archive@odin.ietf.org; Thu, 8 Jan 2004 01:50:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeTzx-0003Ud-AI for sipping-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 01:50:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26912 for ; Thu, 8 Jan 2004 01:50:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeTzu-0005ZB-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 01:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeTxy-0005VV-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 01:48:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeTwh-0005Ri-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 01:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeTwb-0003G5-1h; Thu, 08 Jan 2004 01:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeTwF-0003Fp-N4 for sipping@optimus.ietf.org; Thu, 08 Jan 2004 01:46:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26861 for ; Thu, 8 Jan 2004 01:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeTwC-0005RD-00 for sipping@ietf.org; Thu, 08 Jan 2004 01:46:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeTu6-0005M3-00 for sipping@ietf.org; Thu, 08 Jan 2004 01:44:27 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AeTtT-0005Ij-00 for sipping@ietf.org; Thu, 08 Jan 2004 01:43:47 -0500 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel12.hp.com (Postfix) with ESMTP id CF9C01C00A19 for ; Wed, 7 Jan 2004 22:43:42 -0800 (PST) Received: from nt13192 (nt13192.india.hp.com [15.76.113.192]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id MAA15575 for ; Thu, 8 Jan 2004 12:14:19 +0530 (IST) From: "Banibrata Dutta" To: "Sipping Mailing-List" Date: Thu, 8 Jan 2004 12:13:35 +0530 Message-ID: <000701c3d5b2$bd49a100$c0714c0f@nt13192> 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.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] any info about "push-to-talk" service using SIP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, i've gone thru few old posts about the push-to-talk service that i could find via google, and it the idea that i got was it's "just another service" and need not be discussed on the mailing list!! also, another view was that, the service itself is not properly defined. wanted to know if these 2 view-points have changed since then? has there been any effort to standardize the implementation, or definition of this service w.r.t. SIP ? push-to-talk, as applicable to mobile devices (i.e. the thing i am interested in), is a half-duplex mode of communication where a mobile user can push-a-special-button (keep it pressed) and after a go-ahead signal (i.e. after seizing control of the floor) can speak out. this he does after selecting one particular individual or a group in his/her buddy-list. buddy-list is just like in case of text IM clients, which may be provisioned off-line/on-line. the addressed party, i.e. individual or group will hear what the originator said, via their spearker-phone mode enabled mobile devices, if they are available and connected, else not. i.e. a best effort delivery. this is like the walkie-talkies. only one person can have floor-control at a time. while a floor is under control of an individual, others can only listen, but cannot speak. they must wait for their turn. having given this rough description of the service, may i know, where we are ? i.e. any standardization / draft making effort underway (current or expired or planned) ?? another thing that i am interested in finding out is, what role can SIP play in this, given the fact that the target network is basically GSM/GPRS network, and not a pure SIP network? thanks & regards, Banibrata Dutta Hewlett-Packard ISO Pvt. Ltd, 29, Cunningham Road, Bangalore - 560052, India. Tel: +91-80-2051796 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Jan 8 02:10:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07789 for ; Thu, 8 Jan 2004 02:10:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeUJH-0005CC-Ty for sipping-archive@odin.ietf.org; Thu, 08 Jan 2004 02:10:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i087ARTm019969 for sipping-archive@odin.ietf.org; Thu, 8 Jan 2004 02:10:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeUJH-0005C0-7w for sipping-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 02:10:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07288 for ; Thu, 8 Jan 2004 02:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeUJD-0006NT-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 02:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeUHc-0006Ic-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 02:08:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeUG3-0006Cu-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 02:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeUFx-0004Ji-G6; Thu, 08 Jan 2004 02:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeUFH-0004Eh-9B for sipping@optimus.ietf.org; Thu, 08 Jan 2004 02:06:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03300 for ; Thu, 8 Jan 2004 02:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeUFD-000695-00 for sipping@ietf.org; Thu, 08 Jan 2004 02:06:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeUDL-000662-00 for sipping@ietf.org; Thu, 08 Jan 2004 02:04:20 -0500 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 1AeUBV-0005zN-00 for sipping@ietf.org; Thu, 08 Jan 2004 02:02:25 -0500 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id i086rgAL014075; Wed, 7 Jan 2004 22:53:42 -0800 (PST) Received: from laptop33 ([192.168.209.1]) by ladon.convedia.com (8.12.9/8.12.9) with SMTP id i0871pKw010644; Wed, 7 Jan 2004 23:01:53 -0800 (PST) From: "Garland Sharratt" To: "Banibrata Dutta" Cc: "Sipping Mailing-List" Subject: RE: [Sipping] any info about "push-to-talk" service using SIP Date: Wed, 7 Jan 2004 23:01:51 -0800 Keywords: .xbulk, .aa Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000701c3d5b2$bd49a100$c0714c0f@nt13192> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Open Mobile Alliance (www.openmobilealliance.org) has a large standardization effort underway for PTT. The project is called POC, Push-to-talk Over Cellular. They are using SIP over the data channel. Regards, Garland -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Banibrata Dutta Sent: Wednesday, January 07, 2004 22:44 To: Sipping Mailing-List Subject: [Sipping] any info about "push-to-talk" service using SIP hi, i've gone thru few old posts about the push-to-talk service that i could find via google, and it the idea that i got was it's "just another service" and need not be discussed on the mailing list!! also, another view was that, the service itself is not properly defined. wanted to know if these 2 view-points have changed since then? has there been any effort to standardize the implementation, or definition of this service w.r.t. SIP ? push-to-talk, as applicable to mobile devices (i.e. the thing i am interested in), is a half-duplex mode of communication where a mobile user can push-a-special-button (keep it pressed) and after a go-ahead signal (i.e. after seizing control of the floor) can speak out. this he does after selecting one particular individual or a group in his/her buddy-list. buddy-list is just like in case of text IM clients, which may be provisioned off-line/on-line. the addressed party, i.e. individual or group will hear what the originator said, via their spearker-phone mode enabled mobile devices, if they are available and connected, else not. i.e. a best effort delivery. this is like the walkie-talkies. only one person can have floor-control at a time. while a floor is under control of an individual, others can only listen, but cannot speak. they must wait for their turn. having given this rough description of the service, may i know, where we are ? i.e. any standardization / draft making effort underway (current or expired or planned) ?? another thing that i am interested in finding out is, what role can SIP play in this, given the fact that the target network is basically GSM/GPRS network, and not a pure SIP network? thanks & regards, Banibrata Dutta Hewlett-Packard ISO Pvt. Ltd, 29, Cunningham Road, Bangalore - 560052, India. Tel: +91-80-2051796 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Jan 8 05:27:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15687 for ; Thu, 8 Jan 2004 05:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXNP-0006sQ-Id for sipping-archive@odin.ietf.org; Thu, 08 Jan 2004 05:26:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08AQtb8026434 for sipping-archive@odin.ietf.org; Thu, 8 Jan 2004 05:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXNO-0006sH-Cr for sipping-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 05:26:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15681 for ; Thu, 8 Jan 2004 05:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeXNF-0006sE-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 05:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeXH3-0006gh-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 05:20:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeXFN-0006Xl-00 for sipping-web-archive@ietf.org; Thu, 08 Jan 2004 05:18:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXEn-0006XS-M3; Thu, 08 Jan 2004 05:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeXEI-0006Wr-2H for sipping@optimus.ietf.org; Thu, 08 Jan 2004 05:17:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15507 for ; Thu, 8 Jan 2004 05:17:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeXE7-0006Ww-00 for sipping@ietf.org; Thu, 08 Jan 2004 05:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeX9Z-0006PN-00 for sipping@ietf.org; Thu, 08 Jan 2004 05:12:38 -0500 Received: from rhenium.btinternet.com ([194.73.73.93]) by ietf-mx with esmtp (Exim 4.12) id 1AeX7z-0006Jg-00 for sipping@ietf.org; Thu, 08 Jan 2004 05:11:00 -0500 Received: from [81.135.11.49] (helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #25) id 1AeX7p-0003Bl-00; Thu, 08 Jan 2004 10:10:50 +0000 Message-ID: <001101c3d5d0$12ac4720$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , "Jonathan Rosenberg" Cc: "sipping" References: Subject: Re: [Sipping] Problem with reg-event that needs immediate fix Date: Thu, 8 Jan 2004 10:13:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan, Cullen, One concern I have about many XML schemas defined in this space is how they will be extended for subsequent versions. Has a strategy been defined? The reason I mention it is that I read an article on xml.com about versioning (http://www.xml.com/pub/a/2003/12/03/versioning.html) and it proposes adding additional syntax to a schema to allow an instance conforming to a new version of a schema to be correctly validated against a previous version of the schema. It uses (the form used in a lot of the SIP schemas) to allow for 'third party' extensions. But, to allow the schema to be extended with new elements it suggests the following format (I've tried to mark the relevant bits with ****s): **** ***** ***** ****** If an extension is added to the schema, (I think!) it would become: ***** ******* An alternative would be to define all new extensions in a separate namespace. However, this becomes a bit imprecise because its not easy to say where the new material plugs into the original schema. So my question is this an issue, or have I just not found the right document?! Happy New Year, Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com http://www.tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Cullen Jennings" To: "Jonathan Rosenberg" ; "sipping" Sent: 30 December 2003 17:34 Subject: Re: [Sipping] Problem with reg-event that needs immediate fix > > I would prefer to change the Schema to be right for this things we know are > coming even if that broke backwards compatibility. > > The more I look at the schema, I think the whole the things could be > structured a little better for extensibility. I had the same comment on some > of the other schema that have been in sipish drafts. We should probably make > this part of our NITS review. > > Cullen > > On 12/18/03 9:13 AM, "Jonathan Rosenberg" wrote: > > > While implementing the sipping reg-event draft, we ran into a serious > > technical problem. > > > > The problem is that the specification has not left sufficient room for > > extensibility within the XML schema. It allows for new information to > > be added to the element (which describes the AOR), but > > does not allow any additional information to be provided about a > > contact. We ran into this problem because we needed to add path > > information (ala rfc 3327) to the notifications, but this information > > is per contact. There is no way to do this with the current specification. > > > > The essence of the problem is that the contact element has, as > > content, the actual URI. This makes it difficult to add other > > information about the contact. A better approach would have been to > > make the contact element a complex type, which would include an > > element called that contains the uri. > > > > For example, today we have: > > > > > > > version="1" state="partial"> > > > > > duration-registered="0">sip:joe@pc34.bar.com > > > > > > > > whereas it ought to have been: > > > > > > > version="1" state="partial"> > > > > > duration-registered="0"> > > sip:joe@pc34.bar.com > > > > > > > > > > > > The schema for the contact element could then allow for other children > > in other namespaces, giving us the needed extensibility. > > > > Unfortunately, there is other per-contact data we might want to add in > > the not-too-distant future, such as callee-caps information. That kind > > of data would be very useful for presence applications, where the > > presence server could obtain it from the registrar using reg-event. > > > > I believe that this problem is significant enough that we should try > > and address it during auth48. For those of you not familiar with it, > > auth48 is a brief period just before publication of the actual RFC > > where the author can correct typos or minor other problems. It is > > possible, with AD approval, to make more substantive changes as I am > > suggesting (and indeed I already ran this by Allison and she is OK). > > Of course, I still need group consensus on any change. So, here is my > > proposal. > > > > PROPOSAL > > > > My proposal for fixing this, as outlined above, is to modify the XML > > schema. The element will instead become a complex type. It > > will have, as children, a sequence of followed by an optional > > element from any other namespace. The element will contain the > > actual contact URI. > > > > Unfortunately, this proposed solution above is not backwards > > compatible with the current draft. > > > > I considered other solutions as well: > > > > > > ALTERNATE 1 > > > > Modify the schema to allow attributes in the contact element from > > other namespaces. Adds some extensibility, but is very bad for more > > complex data, such as path or callee-cap data. Using attributes for > > that data will require us to define a lot of structure within each > > attribute. This approach is backwards compatible, but not forwards > > compatible. That is, an implementation compliant to the schema before > > this change would reject documents created by an implementation > > compliant to the schema after the change. > > > > ALTERNATE 2 > > > > Modify the schema to contain a new element, child to the > > element. This element would be called "alt-contact", > > and would be defined as I suggest above for contact. Whenever new > > information is needed about a contact, the "alt-contact" element would > > be present, and contain that extension data. The document would also > > still contain a contact element, repeating the URI and other > > attributes. This would provide forwards and backwards compatibility, > > at the expense of a horrible hack that would repeat a lot of > > information in the document. > > > > > > I found neither of the two alternatives very palatable, which is why > > my proposal is to fix this now, and do it properly, while we still can. > > > > Please provide input on the proposal ASAP. I'd like to come to > > consensus in the next week or so (before everyone disappears for > > vacations). > > > > Thanks, > > Jonathan R. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 9 02:02:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05019 for ; Fri, 9 Jan 2004 02:02:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeqeb-0004DS-VV for sipping-archive@odin.ietf.org; Fri, 09 Jan 2004 02:01:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0971vcq016205 for sipping-archive@odin.ietf.org; Fri, 9 Jan 2004 02:01:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeqeb-0004DI-LV for sipping-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 02:01:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04481 for ; Fri, 9 Jan 2004 02:01:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeqeT-0001R8-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 02:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeqct-0001K5-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 02:00:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeqWS-00019R-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 01:53:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeqVw-0003u6-VP; Fri, 09 Jan 2004 01:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeqVe-0003qK-K7 for sipping@optimus.ietf.org; Fri, 09 Jan 2004 01:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02373 for ; Fri, 9 Jan 2004 01:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeqVb-00014J-00 for sipping@ietf.org; Fri, 09 Jan 2004 01:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeqTf-0000xb-00 for sipping@ietf.org; Fri, 09 Jan 2004 01:50:40 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AeqRk-0000nM-00 for sipping@ietf.org; Fri, 09 Jan 2004 01:48:40 -0500 Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i096ltmR011501; Fri, 9 Jan 2004 01:47:59 -0500 (EST) Message-ID: <3FFE4E8F.7060803@dynamicsoft.com> Date: Fri, 09 Jan 2004 01:47:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Cullen Jennings , sipping Subject: Re: [Sipping] Problem with reg-event that needs immediate fix References: <001101c3d5d0$12ac4720$0200000a@tkw> In-Reply-To: <001101c3d5d0$12ac4720$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Pete Cordell wrote: > Jonathan, Cullen, > > One concern I have about many XML schemas defined in this space is how they > will be extended for subsequent versions. Has a strategy been defined? The general approach is to add in places where we believe more data will be needed in the future. Nothing beyond that. > > The reason I mention it is that I read an article on xml.com about > versioning (http://www.xml.com/pub/a/2003/12/03/versioning.html) and it > proposes adding additional syntax to a schema to allow an instance > conforming to a new version of a schema to be correctly validated against a > previous version of the schema. Right. > > It uses (the form used in a lot of the SIP > schemas) to allow for 'third party' extensions. > > But, to allow the schema to be extended with new elements it suggests the > following format (I've tried to mark the relevant bits with ****s): > > > > minOccurs="1" maxOccurs="1"/> > **** minOccurs="0" maxOccurs="1"/>***** > maxOccurs="unbounded" namespace="##other"/> > > > > > ***** > > > maxOccurs="unbounded" namespace="##targetnamespace"/> > > ****** > > > I'm not sure why this is a better idea. The general technique of just adding an tag directly gets you the same result. The above approach merely wraps the extension element in another element called . I dont see why thats useful. > > > If an extension is added to the schema, (I think!) it would become: > > > > > minOccurs="1" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > maxOccurs="unbounded" namespace="##other"/> > > > > > ***** > > > > minOccurs="0" maxOccurs="1"/> > > > ******* > > > > maxOccurs="unbounded" namespace="##targetnamespace"/> > > > I dont see why you simply cant define the new schema with the new element anywhere you previously, in the old schema, allowed elements from any namespace. > > An alternative would be to define all new extensions in a separate > namespace. Each extension normally has its own namespace. > However, this becomes a bit imprecise because its not easy to > say where the new material plugs into the original schema. I don't think we've planned specifically on how one might specify where to plug the new material into the existing schema. RPID, for example, which is an extension to PIDF, merely defines the new elements. Validation that they are placed in the right places is not done via the resulting schema validation, but through normative text in the doc. That may be OK. If you want to validate, via schema, that the elements are placed in the right place, you would define a new schema with the new element as optional, as above. Again, I dont see the need for wrapping it in a new element called . -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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 9 06:16:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24113 for ; Fri, 9 Jan 2004 06:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeucL-0000q8-7l for sipping-archive@odin.ietf.org; Fri, 09 Jan 2004 06:15:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09BFrpc003225 for sipping-archive@odin.ietf.org; Fri, 9 Jan 2004 06:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeucL-0000pw-2n for sipping-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 06:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24096 for ; Fri, 9 Jan 2004 06:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeucC-0000Lo-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 06:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeuWl-00007K-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 06:10:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeuTz-0007n1-00 for sipping-web-archive@ietf.org; Fri, 09 Jan 2004 06:07:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeuTm-0000IC-JV; Fri, 09 Jan 2004 06:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeuSm-0000GK-Il for sipping@optimus.ietf.org; Fri, 09 Jan 2004 06:06:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23911 for ; Fri, 9 Jan 2004 06:05:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeuSZ-0007kc-00 for sipping@ietf.org; Fri, 09 Jan 2004 06:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeuPv-0007et-00 for sipping@ietf.org; Fri, 09 Jan 2004 06:03:04 -0500 Received: from tungsten.btinternet.com ([194.73.73.81]) by ietf-mx with esmtp (Exim 4.12) id 1AeuM7-0007Uo-00 for sipping@ietf.org; Fri, 09 Jan 2004 05:59:07 -0500 Received: from [213.122.15.221] (helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #25) id 1AeuLY-0000aW-00; Fri, 09 Jan 2004 10:58:33 +0000 Message-ID: <004601c3d69f$e869d560$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Cullen Jennings" , "sipping" References: <001101c3d5d0$12ac4720$0200000a@tkw> <3FFE4E8F.7060803@dynamicsoft.com> Subject: XML schema versioning strategy (Was: Re: [Sipping] Problem with reg-event that needs immediate fix) Date: Fri, 9 Jan 2004 11:01:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA23912 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As you know, the main issue of versioning is allowing devices working to = the old version of a schema to operate successfully when they receive instanc= es conforming to a new version of a schema. (I'm assuming that we are not expecting UAs to try and locate the latest version when a received schema fails to validate.) Unfortunately the use of doesn't get you t= he same result as the article proposes. If the old version of the schema contains this fragment: An instance of a document conforming to a new version of the schema that contains the following fragment would clearly not be valid against the ol= d schema if it contained the new element "newItem": At first sight, using the ##any option to xs:any might seem the way to go= , e.g.: However, this violates the Unique Particle Attribution Constraint, the relevant bits being: - Two non-group particles overlap if ... One is a wildcard and the other = an element declaration, and the {target namespace} of the element declaratio= n, or of any member of its =B7substitution group=B7, is =B7valid=B7 with res= pect to the {namespace constraint} of the wildcard. - A content model will violate the unique attribution constraint if it contains two particles which =B7overlap=B7 and may =B7validate=B7 adjacen= t information items and ... the first has {min occurs} less than {max occurs}. The syntax in the original post was a way to get around this, allowing bo= th external additions, and new syntax in the existing schema without violati= ng this Unique Particle Attribution constraint. (e.g. any variable cardinal= ity element would conflict with the particle, but this wouldn'= t be the case if an optional element named "Extension" wrapped local extensions.) One option might appear to be to define the new element in a completely n= ew schema, in a completely new namespace. The fragment in the existing sche= ma would then be modified to include a new reference to the element of the form: Unfortunately this seems to violate the Unique Particle Attribution Constraint also; same reason, different namespace. So without doing anything we are left with defining version 2 extensions = in separate schemas with different namespaces, and specifying where they sho= uld be plugged in using narrative (or possibly some form of XPath in non-standard xs:appinfo sections). This manual process seems a major sou= rce of potential errors and defeats some of the benefit of using schemas in t= he first place. Adding in the extra syntax seems the correct way to go. Much of the burd= en of adding the syntax could potentially be saved by defining suitable grou= ps (one for sequences, one for choices). Pete. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware pete@tech-know-ware.com http://www.tech-know-ware.com http://www.xml2cpp.com +44 1473 635863 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Cullen Jennings" ; "sipping" Sent: 09 January 2004 06:47 Subject: Re: [Sipping] Problem with reg-event that needs immediate fix > inline. > > Pete Cordell wrote: > > > Jonathan, Cullen, > > > > One concern I have about many XML schemas defined in this space is ho= w they > > will be extended for subsequent versions. Has a strategy been define= d? > > The general approach is to add in places > where we believe more data will be needed in the future. Nothing > beyond that. > > > > > The reason I mention it is that I read an article on xml.com about > > versioning (http://www.xml.com/pub/a/2003/12/03/versioning.html) and = it > > proposes adding additional syntax to a schema to allow an instance > > conforming to a new version of a schema to be correctly validated against a > > previous version of the schema. > > > Right. > > > > > It uses (the form used in a lot of the= SIP > > schemas) to allow for 'third party' extensions. > > > > But, to allow the schema to be extended with new elements it suggests the > > following format (I've tried to mark the relevant bits with ****s): > > > > > > > > > minOccurs=3D"1" maxOccurs=3D"1"/> > > **** > minOccurs=3D"0" maxOccurs=3D"1"/>***** > > > maxOccurs=3D"unbounded" namespace=3D"##other"/> > > > > > > > > > > ***** > > > > > > > maxOccurs=3D"unbounded" namespace=3D"##targetnamespace"/> > > > > ****** > > > > > > > > I'm not sure why this is a better idea. The general technique of just > adding an tag directly gets you the same result. The above > approach merely wraps the extension element in another element called > . I dont see why thats useful. > > > > > > > If an extension is added to the schema, (I think!) it would become: > > > > > > > > > > > minOccurs=3D"1" maxOccurs=3D"1"/> > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > maxOccurs=3D"unbounded" namespace=3D"##other"/> > > > > > > > > > > ***** > > > > > > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > > > ******* > > > > > > > > > maxOccurs=3D"unbounded" namespace=3D"##targetnamespace"/> > > > > > > > > I dont see why you simply cant define the new schema with the new > element anywhere you previously, in the old schema, allowed elements > from any namespace. > > > > > An alternative would be to define all new extensions in a separate > > namespace. > > Each extension normally has its own namespace. > > > However, this becomes a bit imprecise because its not easy to > > say where the new material plugs into the original schema. > > I don't think we've planned specifically on how one might specify > where to plug the new material into the existing schema. RPID, for > example, which is an extension to PIDF, merely defines the new > elements. Validation that they are placed in the right places is not > done via the resulting schema validation, but through normative text > in the doc. That may be OK. > > If you want to validate, via schema, that the elements are placed in > the right place, you would define a new schema with the new element as > optional, as above. Again, I dont see the need for wrapping it in a > new element called . > > -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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 06:12:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06470 for ; Tue, 13 Jan 2004 06:12:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMT8-0000NY-1R for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 06:12:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DBCM09001452 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 06:12:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMT7-0000NL-Tl for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 06:12:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06453 for ; Tue, 13 Jan 2004 06:12:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMT4-0006zO-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMRF-0006vC-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:10:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgMQ1-0006rK-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMPt-00009p-EF; Tue, 13 Jan 2004 06:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMP7-000095-BP for sipping@optimus.ietf.org; Tue, 13 Jan 2004 06:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06338 for ; Tue, 13 Jan 2004 06:08:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMP3-0006ns-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:08:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMNG-0006id-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:06:18 -0500 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 1AgMLd-0006Yg-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:04:37 -0500 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id NAA18030 for ; Tue, 13 Jan 2004 13:53:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jan 2004 12:04:38 +0100 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A323DBA@MAILSRV.uns.t-systems.tss> Thread-Topic: Case-sensitivty of the branch parameter Thread-Index: AcPZxQiTBxQ3L2BFTGOLv2kOwfIQ+A== From: =?iso-8859-2?Q?Szel=E9nyi_Csaba?= To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Case-sensitivty of the branch parameter Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, It seems to me, that the branch parameter is case-sensitive (the magic = cookie contains upper and lower case characters). I could find only the = following paragraph regarding the case-sensitivity of the branch = parameter in rfc3261: 7.3.1 Header Field Format ... When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Neither chapter 8.1.1.7, nor chapter 20.42 states anything regarding the = case-sensitivity of branch. So, according to rfc3261, the branch is case = insensitive!=20 Is the Via branch parameter case sensitive? Thank you very much in anticipation for any input regarding this topic! Regards, Csaba Szel=E9nyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 06:24:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06898 for ; Tue, 13 Jan 2004 06:24:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMeq-0000s6-Ek for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 06:24:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DBOSqP003344 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 06:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMeq-0000rr-9W for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 06:24:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06846 for ; Tue, 13 Jan 2004 06:24:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMem-0007Sc-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:24:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMco-0007OF-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:22:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgMbX-0007KU-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 06:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMbX-0000ZJ-DM; Tue, 13 Jan 2004 06:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMam-0000XE-Eh for sipping@optimus.ietf.org; Tue, 13 Jan 2004 06:20:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06721 for ; Tue, 13 Jan 2004 06:20:12 -0500 (EST) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMai-0007IK-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMYy-0007GH-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:18:25 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AgMY8-0007Cz-00 for sipping@ietf.org; Tue, 13 Jan 2004 06:17:33 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0DBH1LH025382 for ; Tue, 13 Jan 2004 16:47:01 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 13 Jan 2004 16:48:30 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jan 2004 16:47:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D9C6.C3F91E82" Subject: RE: [Sipping] Case-sensitivty of the branch parameter Date: Tue, 13 Jan 2004 16:47:01 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADDBEDAC@blr-ec-msg04.wipro.com> Thread-Topic: [Sipping] Case-sensitivty of the branch parameter Thread-Index: AcPZxQiTBxQ3L2BFTGOLv2kOwfIQ+AAAjWSg To: , X-OriginalArrivalTime: 13 Jan 2004 11:17:01.0216 (UTC) FILETIME=[C408AA00:01C3D9C6] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D9C6.C3F91E82 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regards, Nataraju A.B.=20 -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of Szel=E9nyi Csaba Sent: Tuesday, January 13, 2004 4:35 PM To: sipping@ietf.org Subject: [Sipping] Case-sensitivty of the branch parameter Hi All, It seems to me, that the branch parameter is case-sensitive (the magic = cookie contains upper and lower case characters). I could find only the = following paragraph regarding the case-sensitivity of the branch = parameter in rfc3261: 7.3.1 Header Field Format ... When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Neither chapter 8.1.1.7, nor chapter 20.42 states anything regarding the = case-sensitivity of branch. So, according to rfc3261, the branch is case = insensitive!=20 Is the Via branch parameter case sensitive? [ABN] Yes Branch parameter MUST be case sensitive. It's not been = explicitly mentioned in any section. I guess it should have been = mentioned in some section about the case sensitiveness... Thank you very much in anticipation for any input regarding this topic! Regards, Csaba Szel=E9nyi Csaba T-Systems RIC mailto:Csaba.Szelenyi@t-systems.co.hu +36 1 456 5507 +36 20 477 7778 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C3D9C6.C3F91E82 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Case-sensitivty of the branch parameter

Regards,

Nataraju A.B.

-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On Behalf Of Szel=E9nyi Csaba
Sent: Tuesday, January 13, 2004 4:35 PM
To: sipping@ietf.org
Subject: [Sipping] Case-sensitivty of the branch = parameter

Hi All,

It seems to me, that the branch parameter is case-sensitive (the = magic cookie contains upper and lower case characters). I could find = only the following paragraph regarding the case-sensitivity of the = branch parameter in rfc3261:

7.3.1 Header Field Format

...

   When comparing header fields, field names are always = case-

   insensitive.  Unless otherwise stated in the = definition of a

   particular header field, field values, parameter = names, and parameter

   values are case-insensitive.  Tokens are always = case-insensitive.

   Unless specified otherwise, values expressed as quoted = strings are

   case-sensitive.  For example,

Neither chapter 8.1.1.7, nor chapter 20.42 states anything = regarding the case-sensitivity of branch. So, according to rfc3261, the = branch is case insensitive!

Is the Via branch parameter case sensitive?

 [ABN] Yes Branch parameter MUST be case sensitive. It's not been explicitly   mentioned in any = section. I guess it should have been mentioned in some = section about the case sensitiveness...

Thank you very much in anticipation for any input regarding this = topic!

Regards,

Csaba


Szel=E9nyi Csaba

T-Systems RIC

mailto:Csaba.Szelenyi@t-sy= stems.co.hu

+36 1 456 5507

+36 20 477 7778


_______________________________________________

Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping

This list is for NEW development of the application of = SIP

Use sip-implementors@cs.columbia.edu for questions on current = sip

Use sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C3D9C6.C3F91E82-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 08:19:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10908 for ; Tue, 13 Jan 2004 08:19:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgORv-0004qQ-8g for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 08:19:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DDJFUZ018616 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 08:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgORv-0004qB-4N for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 08:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10842 for ; Tue, 13 Jan 2004 08:19:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgORt-0005TK-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 08:19:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgOPr-0005CK-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 08:17:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AgOO8-0004yj-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 08:15:20 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AgOO8-0007DN-4P for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 08:15:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgONr-0004XX-U4; Tue, 13 Jan 2004 08:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgONQ-0004Va-DS for sipping@optimus.ietf.org; Tue, 13 Jan 2004 08:14:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10400 for ; Tue, 13 Jan 2004 08:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgONP-0004oc-00 for sipping@ietf.org; Tue, 13 Jan 2004 08:14:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgOFy-0004S5-00 for sipping@ietf.org; Tue, 13 Jan 2004 08:06:57 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1AgOAe-0004An-00 for sipping@ietf.org; Tue, 13 Jan 2004 08:01:24 -0500 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id IAA11400; Tue, 13 Jan 2004 08:00:41 -0500 (EST) Message-ID: <4003EBF9.3050808@ulticom.com> Date: Tue, 13 Jan 2004 08:00:41 -0500 From: Steve Pellegrino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nataraju.alilaghatta@wipro.com CC: Csaba.Szelenyi@t-systems.co.hu, sipping@ietf.org Subject: Re: [Sipping] Case-sensitivty of the branch parameter References: <10C4348A1BA43A4FA8D5B767E052CEADDBEDAC@blr-ec-msg04.wipro.com> In-Reply-To: <10C4348A1BA43A4FA8D5B767E052CEADDBEDAC@blr-ec-msg04.wipro.com> Content-Type: multipart/alternative; boundary="------------040202040804050904020200" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------040202040804050904020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by chuckie.dgms.com id IAA11400 Content-Transfer-Encoding: quoted-printable Actually, the branch parameter is case insensitive. This has been=20 logged as bug 661: http://www.sipwg.org/sipwg/show_bug.cgi?id=3D661 Regards, Steve nataraju.alilaghatta@wipro.com wrote: > > > Regards, > > Nataraju A.B. > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf=20 > Of Szel=E9nyi Csaba > Sent: Tuesday, January 13, 2004 4:35 PM > To: sipping@ietf.org > Subject: [Sipping] Case-sensitivty of the branch parameter > > Hi All, > > It seems to me, that the branch parameter is case-sensitive (the magic=20 > cookie contains upper and lower case characters). I could find only=20 > the following paragraph regarding the case-sensitivity of the branch=20 > parameter in rfc3261: > > 7.3.1 Header Field Format > > ... > > When comparing header fields, field names are always case- > > insensitive. Unless otherwise stated in the definition of a > > particular header field, field values, parameter names, and paramete= r > > values are case-insensitive. Tokens are always case-insensitive. > > Unless specified otherwise, values expressed as quoted strings are > > case-sensitive. For example, > > Neither chapter 8.1.1.7, nor chapter 20.42 states anything regarding=20 > the case-sensitivity of branch. So, according to rfc3261, the branch=20 > is case insensitive! > > Is the Via branch parameter case sensitive? > > [ABN] Yes Branch parameter MUST be case sensitive. It's not been=20 > explicitly mentioned in any section. I guess it should have been=20 > mentioned in some section about the case sensitiveness... > > Thank you very much in anticipation for any input regarding this topic! > > Regards, > > Csaba > > > Szel=E9nyi Csaba > > T-Systems RIC > > mailto:Csaba.Szelenyi@t-systems.co.hu > > +36 1 456 5507 > > +36 20 477 7778 > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > --------------040202040804050904020200 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Actually, the branch parameter is case insensitive.  This has been logged as bug 661:
http://www.sipwg.org/sipwg/show_bug.cgi?id=661

Regards,
Steve


nataraju.alilaghatta@wipro.com wrote:
RE: [Sipping] Case-sensitivty of the branch parameter

Regards,

Nataraju A.B.

-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Szelényi Csaba
Sent: Tuesday, January 13, 2004 4:35 PM
To: sipping@ietf.org
Subject: [Sipping] Case-sensitivty of the branch parameter

Hi All,

It seems to me, that the branch parameter is case-sensitive (the magic cookie contains upper and lower case characters). I could find only the following paragraph regarding the case-sensitivity of the branch parameter in rfc3261:

7.3.1 Header Field Format

...

   When comparing header fields, field names are always case-

   insensitive.  Unless otherwise stated in the definition of a

   particular header field, field values, parameter names, and parameter

   values are case-insensitive.  Tokens are always case-insensitive.

   Unless specified otherwise, values expressed as quoted strings are

   case-sensitive.  For example,

Neither chapter 8.1.1.7, nor chapter 20.42 states anything regarding the case-sensitivity of branch. So, according to rfc3261, the branch is case insensitive!

Is the Via branch parameter case sensitive?

 [ABN] Yes Branch parameter MUST be case sensitive. It's not been explicitly   mentioned in any section. I guess it should have been mentioned in some section about the case sensitiveness...

Thank you very much in anticipation for any input regarding this topic!

Regards,

Csaba


Szelényi Csaba

T-Systems RIC

mailto:Csaba.Szelenyi@t-systems.co.hu

+36 1 456 5507

+36 20 477 7778


_______________________________________________

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping

This list is for NEW development of the application of SIP

Use sip-implementors@cs.columbia.edu for questions on current sip

Use sip@ietf.org for new developments of core SIP

--------------040202040804050904020200-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 15:56:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12584 for ; Tue, 13 Jan 2004 15:56:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVaR-0002fE-IW for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 15:56:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKuVNp010234 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 15:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVaR-0002ez-Di for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:56:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12537 for ; Tue, 13 Jan 2004 15:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgVaP-0004Zo-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 15:56:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgVYZ-0004Wf-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 15:54:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgVXV-0004TR-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 15:53:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVX4-0002Mw-3Z; Tue, 13 Jan 2004 15:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVWA-0002JC-Ae for sipping@optimus.ietf.org; Tue, 13 Jan 2004 15:52:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12353; Tue, 13 Jan 2004 15:52:03 -0500 (EST) Message-Id: <200401132052.PAA12353@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 13 Jan 2004 15:52:03 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-reason-header-for-preemption-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Extending the Session Initiation Protocol Reason Header for Preemption Events Author(s) : J. Polk Filename : draft-ietf-sipping-reason-header-for-preemption-00.txt Pages : 15 Date : 2004-1-13 This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header [1] to include in a BYE Method Request [2] as a result of a session preemption event either at a user agent (UA), or somewhere in the network using RSVP [3]. This document does not attempt to address routers failing in the packet path; but a deliberate event of tearing down a flow between UAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-reason-header-for-preemption-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-sipping-reason-header-for-preemption-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-sipping-reason-header-for-preemption-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: <2004-1-13160111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-reason-header-for-preemption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-reason-header-for-preemption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13160111.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 21:45:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28698 for ; Tue, 13 Jan 2004 21:45:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agb1N-0001aZ-90 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 21:44:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E2ifIE006103 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 21:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agb1N-0001aM-3n for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 21:44:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28639 for ; Tue, 13 Jan 2004 21:44:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agb1K-0005EQ-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 21:44:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agazf-00058s-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 21:42:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agaxz-00052M-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 21:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agaxr-00017X-4P; Tue, 13 Jan 2004 21:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgaxM-00016b-Tq for sipping@optimus.ietf.org; Tue, 13 Jan 2004 21:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28365 for ; Tue, 13 Jan 2004 21:40:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgaxJ-0004vr-00 for sipping@ietf.org; Tue, 13 Jan 2004 21:40:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgavX-0004lk-00 for sipping@ietf.org; Tue, 13 Jan 2004 21:38:40 -0500 Received: from [61.51.70.99] (helo=mail.udtech.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1Agath-0004Mj-00; Tue, 13 Jan 2004 21:36:48 -0500 Received: from zwx ([61.194.192.236]) by mail.udtech.com.cn (8.12.2/8.11.2) with ESMTP id i0E2UuWC001025; Wed, 14 Jan 2004 10:31:08 +0800 Message-ID: <003301c3da47$753dbf60$1949a8c0@udtech.net> From: "wendy" To: Cc: Date: Wed, 14 Jan 2004 11:37:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] SIP DTMF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, Who can tell me whether there is a RFC or I-D on DTMF in SIP which is still not expired? I remember someone proposed using SIP INFO method for DTMF one or two years ago. Is the DTMF relay implemented only by RTP now? Regards, Wendy _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 13 22:59:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01265 for ; Tue, 13 Jan 2004 22:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgcBE-0004ys-6k for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 22:58:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E3wuvo019140 for sipping-archive@odin.ietf.org; Tue, 13 Jan 2004 22:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgcBE-0004yd-3Q for sipping-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 22:58:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01188 for ; Tue, 13 Jan 2004 22:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgcBA-0000LP-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 22:58:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agc9N-0000E9-00 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 22:57:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Agc8E-00007c-01 for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 22:55:50 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Agbv0-00072R-EK for sipping-web-archive@ietf.org; Tue, 13 Jan 2004 22:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agbuq-0004KA-JZ; Tue, 13 Jan 2004 22:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agbtt-0004Iu-Dh for sipping@optimus.ietf.org; Tue, 13 Jan 2004 22:41:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00727 for ; Tue, 13 Jan 2004 22:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agbtp-0007eL-00 for sipping@ietf.org; Tue, 13 Jan 2004 22:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agbt1-0007XH-00 for sipping@ietf.org; Tue, 13 Jan 2004 22:40:07 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AgboG-0007Np-00 for sipping@ietf.org; Tue, 13 Jan 2004 22:35:13 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0E3YT9W002108; Tue, 13 Jan 2004 22:34:30 -0500 (EST) Message-ID: <4004B8B8.50901@dynamicsoft.com> Date: Tue, 13 Jan 2004 22:34:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sreeram.kanumuri@wipro.com CC: xyxie@udtech.com.cn, sipping@ietf.org References: <72001BBBF6CB124BA1C40E415914E2130300BF@blr-ec-msg04.wipro.com> In-Reply-To: <72001BBBF6CB124BA1C40E415914E2130300BF@blr-ec-msg04.wipro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip] SIP DTMF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is also RFC 2833. The app interaction framework: http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-framework-00.txt describes the framework for dtmf and other stimulus signaling, and KPML, as indicated, is used in conjunction with this framework. -Jonathan R. sreeram.kanumuri@wipro.com wrote: > Wendy, > > There was a discussion in the list some time back and it was decided > that SIP-INFO method should not be used to > Send the DTMF info. > > It was proposed that it is better to you kpxml for sending DTMF tones. > > Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall > processing and all.... > > > Regards, > Sreeram > > ===================================================== > Sreeram Kanumuri Plot No 72, Keonics Electronics City > Hosur Main Road > Wipro Technologies Bangalore -29 INDIA > sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 > skanumury@yahoo.com ESN : > www.wipro.com Mobile: > ====================================================== > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy > Sent: Wednesday, January 14, 2004 8:08 AM > To: sip@ietf.org > Cc: sipping@ietf.org > Subject: [Sip] SIP DTMF > > > Hello all, > > Who can tell me whether there is a RFC or I-D on DTMF in SIP which is > still not expired? I remember someone proposed using SIP INFO method for > DTMF one or two years ago. Is the DTMF relay implemented only by RTP > now? > > > Regards, > Wendy > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 > -- 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 14 04:39:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07604 for ; Wed, 14 Jan 2004 04:39:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AghU2-0004BS-G5 for sipping-archive@odin.ietf.org; Wed, 14 Jan 2004 04:38:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E9cfEu016009 for sipping-archive@odin.ietf.org; Wed, 14 Jan 2004 04:38:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AghTs-00049R-MA for sipping-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 04:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07422 for ; Wed, 14 Jan 2004 04:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AghTp-0005Ik-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 04:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AghOf-0004hx-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 04:33:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AghFA-0004KG-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 04:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AghEr-00034q-Jg; Wed, 14 Jan 2004 04:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgbUz-0003Dt-Gl for sipping@optimus.ietf.org; Tue, 13 Jan 2004 22:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00045 for ; Tue, 13 Jan 2004 22:15:11 -0500 (EST) From: sreeram.kanumuri@wipro.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgbUp-0006jp-00 for sipping@ietf.org; Tue, 13 Jan 2004 22:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgbOi-0006et-00 for sipping@ietf.org; Tue, 13 Jan 2004 22:08:49 -0500 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1AgbMz-0006Sn-00; Tue, 13 Jan 2004 22:07:02 -0500 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i0E36TLH015527; Wed, 14 Jan 2004 08:36:29 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 14 Jan 2004 08:37:59 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 08:36:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jan 2004 08:36:28 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130300BF@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] SIP DTMF Thread-Index: AcPaR/R12+2o9NobQ+ikqwjgRuJy0QAAO8TA To: , Cc: X-OriginalArrivalTime: 14 Jan 2004 03:06:28.0772 (UTC) FILETIME=[6757DE40:01C3DA4B] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [Sip] SIP DTMF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Wendy, There was a discussion in the list some time back and it was decided that SIP-INFO method should not be used to=20 Send the DTMF info. It was proposed that it is better to you kpxml for sending DTMF tones. Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall processing and all....=20 Regards, Sreeram =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Sreeram Kanumuri Plot No 72, Keonics Electronics City Hosur Main Road Wipro Technologies Bangalore -29 INDIA sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 skanumury@yahoo.com ESN : www.wipro.com Mobile: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy Sent: Wednesday, January 14, 2004 8:08 AM To: sip@ietf.org Cc: sipping@ietf.org Subject: [Sip] SIP DTMF Hello all,=20 Who can tell me whether there is a RFC or I-D on DTMF in SIP which is still not expired? I remember someone proposed using SIP INFO method for DTMF one or two years ago. Is the DTMF relay implemented only by RTP now? Regards, Wendy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 14 15:57:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11737 for ; Wed, 14 Jan 2004 15:57:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ags4f-000876-F8 for sipping-archive@odin.ietf.org; Wed, 14 Jan 2004 15:57:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EKvDLV031182 for sipping-archive@odin.ietf.org; Wed, 14 Jan 2004 15:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ags4f-00086n-9B for sipping-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 15:57:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11647 for ; Wed, 14 Jan 2004 15:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ags4c-0000ac-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 15:57:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ags3f-0000XS-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 15:56:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ags35-0000UG-00 for sipping-web-archive@ietf.org; Wed, 14 Jan 2004 15:55:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ags2c-0007eC-FF; Wed, 14 Jan 2004 15:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ags2W-0007b7-L9 for sipping@optimus.ietf.org; Wed, 14 Jan 2004 15:55:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11357; Wed, 14 Jan 2004 15:54:58 -0500 (EST) Message-Id: <200401142054.PAA11357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 14 Jan 2004 15:54:57 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-early-disposition-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : The Early Session Disposition Type for the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sipping-early-disposition-01.txt Pages : 10 Date : 2004-1-14 This document defines a new disposition type (early-session) for the Content-Disposition header field in SIP. The treatment of 'early-session' bodies is similar to the treatment of 'session' bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is 'early-session' are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-early-disposition-01.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-sipping-early-disposition-01.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-sipping-early-disposition-01.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: <2004-1-14161618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-early-disposition-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-early-disposition-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-14161618.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Sun Jan 18 13:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27236 for ; Sun, 18 Jan 2004 13:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHca-0000Lj-B3 for sipping-archive@odin.ietf.org; Sun, 18 Jan 2004 13:26:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0IIQ4OX001339 for sipping-archive@odin.ietf.org; Sun, 18 Jan 2004 13:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHcY-0000LM-Mx for sipping-web-archive@optimus.ietf.org; Sun, 18 Jan 2004 13:26:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27211 for ; Sun, 18 Jan 2004 13:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiHcW-0001VE-00 for sipping-web-archive@ietf.org; Sun, 18 Jan 2004 13:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiHba-0001RY-00 for sipping-web-archive@ietf.org; Sun, 18 Jan 2004 13:25:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiHay-0001P3-00 for sipping-web-archive@ietf.org; Sun, 18 Jan 2004 13:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHZd-0008Ro-LO; Sun, 18 Jan 2004 13:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHYe-0008Lx-DT for sipping@optimus.ietf.org; Sun, 18 Jan 2004 13:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27088 for ; Sun, 18 Jan 2004 13:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiHYc-0001G3-00 for sipping@ietf.org; Sun, 18 Jan 2004 13:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiHXi-0001DE-00 for sipping@ietf.org; Sun, 18 Jan 2004 13:21:03 -0500 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 1AiHWy-00018N-00 for sipping@ietf.org; Sun, 18 Jan 2004 13:20:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2004 10:22:41 +0000 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 i0IIJhGN012508; Sun, 18 Jan 2004 10:19:44 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-941.cisco.com [10.21.67.173]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALN66805; Sun, 18 Jan 2004 10:19:42 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 18 Jan 2004 10:17:51 -0800 Subject: Re: [Sipping] Re: [Sip] SIP DTMF From: Cullen Jennings To: CC: , , Jonathan Rosenberg Message-ID: In-Reply-To: <4004B8B8.50901@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have talked to the authors of the various proposal for doing DTMF. For the case where it is not in the media (ie 2833), I believe the only proposal that the current authors plan to keep moving forward is the App-Interaction/KPML stuff. I don't believe there is any intention to resubmit the DTMF in INFO or DTMF over SUB/NOT proposals. Cullen On 1/13/04 7:34 PM, "Jonathan Rosenberg" wrote: > There is also RFC 2833. > > The app interaction framework: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-framewo > rk-00.txt > > describes the framework for dtmf and other stimulus signaling, and > KPML, as indicated, is used in conjunction with this framework. > > -Jonathan R. > > sreeram.kanumuri@wipro.com wrote: > >> Wendy, >> >> There was a discussion in the list some time back and it was decided >> that SIP-INFO method should not be used to >> Send the DTMF info. >> >> It was proposed that it is better to you kpxml for sending DTMF tones. >> >> Please look in to the SIP-Kpxml draft for sending DTMF tomes in-midcall >> processing and all.... >> >> >> Regards, >> Sreeram >> >> ===================================================== >> Sreeram Kanumuri Plot No 72, Keonics Electronics City >> Hosur Main Road >> Wipro Technologies Bangalore -29 INDIA >> sreeram.kanumuri@wipro.com Phone: 8520408 Ex:3208 >> skanumury@yahoo.com ESN : >> www.wipro.com Mobile: >> ====================================================== >> >> >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of wendy >> Sent: Wednesday, January 14, 2004 8:08 AM >> To: sip@ietf.org >> Cc: sipping@ietf.org >> Subject: [Sip] SIP DTMF >> >> >> Hello all, >> >> Who can tell me whether there is a RFC or I-D on DTMF in SIP which is >> still not expired? I remember someone proposed using SIP INFO method for >> DTMF one or two years ago. Is the DTMF relay implemented only by RTP >> now? >> >> >> Regards, >> Wendy >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 >> _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jan 19 10:55:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22983 for ; Mon, 19 Jan 2004 10:55:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibji-000145-90 for sipping-archive@odin.ietf.org; Mon, 19 Jan 2004 10:54:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JFskYa004084 for sipping-archive@odin.ietf.org; Mon, 19 Jan 2004 10:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibji-00013n-3u for sipping-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 10:54:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22964 for ; Mon, 19 Jan 2004 10:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aibjf-0005c2-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 10:54:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aibio-0005X3-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 10:53:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AibiF-0005TT-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 10:53:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibi1-0000vW-PU; Mon, 19 Jan 2004 10:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibhc-0000uk-Ja for sipping@optimus.ietf.org; Mon, 19 Jan 2004 10:52:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22870 for ; Mon, 19 Jan 2004 10:52:32 -0500 (EST) From: hgs@cs.columbia.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aibha-0005QX-00 for sipping@ietf.org; Mon, 19 Jan 2004 10:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aibgc-0005MM-00 for sipping@ietf.org; Mon, 19 Jan 2004 10:51:35 -0500 Received: from fw02.rockwellcollins.com ([205.175.225.45] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1Aibfl-0005Hq-00 for sipping@ietf.org; Mon, 19 Jan 2004 10:50:41 -0500 Received: by fw02.Rockwellcollins.com; id JAA20938; Mon, 19 Jan 2004 09:50:38 -0600 (CST) Received: from nodnsquery(131.198.169.132) by fw02.collins.rockwell.com via smap (V5.5) id xmavk4171; Mon, 19 Jan 04 09:45:41 -0600 Received: from smtpgw01.rockwellcollins.com (localhost [127.0.0.1]) by vs02.rockwellcollins.com (8.11.7+Sun/8.11.7) with ESMTP id i0JFaN020193 for ; Mon, 19 Jan 2004 09:36:23 -0600 (CST) Received: from barn.comsys.rockwell.com (unverified) by smtpgw01.rockwellcollins.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 19 Jan 2004 09:36:20 -0600 Received: by barn.comsys.rockwell.com; id JAA04344; Mon, 19 Jan 2004 09:36:19 -0600 (CST) Received: from dlprabloom.dallas.rockwellcollins.com(131.199.63.237) by barn.comsys.rockwell.com via smap (V4.2) id xma003841; Mon, 19 Jan 04 09:35:29 -0600 Date: Mon, 19 Jan 2004 09:35:28 -0600 To: sipping@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------354818024557883" Subject: [Sipping] Hi Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------354818024557883 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) oennlvaqajpo -- Test, yep. ----------354818024557883 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on vs02) tadxlgtfbr.exe is removed from here because it contains a virus. --------------------------------------------------------- ----------354818024557883 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on vs02) Found virus WORM_BAGLE.A in file tadxlgtfbr.exe The uncleanable file tadxlgtfbr.exe is moved to /var/log/iscan/virus/virVVFMAbyut. The Rockwell Collins virus detection network has detected a virus in a message sent to you Detail about the file and it's status are listed above this message If you received the attachment, it was repaired. If you did not receive the attachment, it was quarantined on a Rockwell Collins Server. If you are a Rockwell Collins employee, refer to the following web page for additional information: http://rwebapps.rockwellcollins.com/ebusiness/organization/e-business-operations/it-infrastructure/it-security/viruses.asp The Rockwell Collins Virus Team --------------------------------------------------------- ----------354818024557883-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jan 19 15:19:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06583 for ; Mon, 19 Jan 2004 15:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifrH-00030b-Cu for sipping-archive@odin.ietf.org; Mon, 19 Jan 2004 15:18:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JKIpLb011561 for sipping-archive@odin.ietf.org; Mon, 19 Jan 2004 15:18:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifrH-00030O-9l for sipping-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 15:18:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06537 for ; Mon, 19 Jan 2004 15:18:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifrF-0002Gl-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 15:18:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AifqM-0002DC-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 15:17:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aifpa-00029X-00 for sipping-web-archive@ietf.org; Mon, 19 Jan 2004 15:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifpV-00029n-LG; Mon, 19 Jan 2004 15:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifod-0001wk-QW for sipping@optimus.ietf.org; Mon, 19 Jan 2004 15:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06278 for ; Mon, 19 Jan 2004 15:16:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifoZ-00024d-00 for sipping@ietf.org; Mon, 19 Jan 2004 15:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aifna-0001zR-00 for sipping@ietf.org; Mon, 19 Jan 2004 15:15:03 -0500 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 1Aifmk-0001qL-00 for sipping@ietf.org; Mon, 19 Jan 2004 15:14:10 -0500 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 i0JKKJsa022561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 14:20:20 -0600 From: "Dean Willis" To: Date: Mon, 19 Jan 2004 14:13:35 -0600 Message-ID: <00c501c3dec8$b84ff860$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] FW: Protocol Action: 'Securely Available Credentials Protocol' to Proposed Standard Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is Something to Think About. What would we need to do to take advantage of the SACRED work in order to secure SIP systems? How will this relate to our identity and authentication models? -- Dean -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of The IESG Sent: Friday, January 09, 2004 10:07 AM To: IETF-Announce: Cc: Internet Architecture Board; RFC Editor; ietf-sacred@imc.org Subject: Protocol Action: 'Securely Available Credentials Protocol' to Proposed Standard The IESG has approved the following documents: - 'Securely Available Credentials Protocol ' as a Proposed Standard - 'Securely Available Credentials - Credential Server Framework ' as an Informational RFC These documents are products of the Securely Available Credentials Working Group. The IESG contact persons are Steve Bellovin and Russ Housley. Technical Summary Certificates and other cryptographic credentials are ungainly things, not suitable to human memorization. While smart cards and the like are one possible solution, they're not widely deployed or used for general-purpose computing. The SACRED protocol permits remote storage and retrieval of such credentials. Working Group Summary There was working group consensus on this document. Protocol Quality This protocol was reviewed for the IESG by Steve Bellovin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 20 10:07:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02570 for ; Tue, 20 Jan 2004 10:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixTU-0003PF-66 for sipping-archive@odin.ietf.org; Tue, 20 Jan 2004 10:07:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KF7SAM013084 for sipping-archive@odin.ietf.org; Tue, 20 Jan 2004 10:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixTT-0003Ow-UR for sipping-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 10:07:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02543 for ; Tue, 20 Jan 2004 10:07:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AixTR-0004Uj-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 10:07:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AixSW-0004SK-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 10:06:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AixSG-0004Pw-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 10:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixS8-0002mh-OL; Tue, 20 Jan 2004 10:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AixRT-0002dl-4Q for sipping@optimus.ietf.org; Tue, 20 Jan 2004 10:05:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02437; Tue, 20 Jan 2004 10:05:19 -0500 (EST) Message-Id: <200401201505.KAA02437@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 20 Jan 2004 10:05:18 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Interworking between SIP and QSIG Author(s) : J. Elwell Filename : draft-ietf-sipping-qsig2sip-04.txt Pages : 61 Date : 2004-1-19 This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-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-sipping-qsig2sip-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-sipping-qsig2sip-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: <2004-1-20102746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-qsig2sip-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20102746.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 20 15:07:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18142 for ; Tue, 20 Jan 2004 15:07:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj28x-0000CE-8i for sipping-archive@odin.ietf.org; Tue, 20 Jan 2004 15:06:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KK6ZsC000754 for sipping-archive@odin.ietf.org; Tue, 20 Jan 2004 15:06:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj28x-0000C5-4I for sipping-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 15:06:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18125 for ; Tue, 20 Jan 2004 15:06:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj28u-0006M2-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 15:06:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj27x-0006K4-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 15:05:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj27a-0006I5-00 for sipping-web-archive@ietf.org; Tue, 20 Jan 2004 15:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj27T-0007wv-Ex; Tue, 20 Jan 2004 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj277-0007gU-Q2 for sipping@optimus.ietf.org; Tue, 20 Jan 2004 15:04:41 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18075 for ; Tue, 20 Jan 2004 15:04:38 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aj26Z-0001n4-Bc; Tue, 20 Jan 2004 15:04:07 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Tue, 20 Jan 2004 15:04:07 -0500 Subject: [Sipping] Protocol Action: 'Best Current Practices for Third Party Call Control in the Session Initiation Protocol' to BCP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Best Current Practices for Third Party Call Control in the Session Initiation Protocol ' as a BCP This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. Security and identity are important issues in third party call control. The document provides recommendations for the controller to use a credentialled identity. It also provides recommendations to aid the two endpoints in the third party controlled call in gaining end-to-end secured media. Working Group Summary There was strong working group consensus to advance this document it has a significant pull from the community, including 3GPP. There were no issues raised during IETF Last Call. Protocol Quality The document was reviewed for the IESG by Eric Rescorla and Allison Mankin. Further IESG review included a community poll regarding the use of 0.0.0.0, which is divergent from other Internet usage, but was determined to be required due to SDP limitations. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 21 11:58:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29845 for ; Wed, 21 Jan 2004 11:58:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLgF-0004GA-DX for sipping-archive@odin.ietf.org; Wed, 21 Jan 2004 11:58:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LGwF6j016368 for sipping-archive@odin.ietf.org; Wed, 21 Jan 2004 11:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLgF-0004Fv-AV for sipping-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29797 for ; Wed, 21 Jan 2004 11:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLgE-0007YL-00 for sipping-web-archive@ietf.org; Wed, 21 Jan 2004 11:58:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLfE-0007U7-00 for sipping-web-archive@ietf.org; Wed, 21 Jan 2004 11:57:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjLeF-0007Qg-00 for sipping-web-archive@ietf.org; Wed, 21 Jan 2004 11:56:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLe5-0003u1-T7; Wed, 21 Jan 2004 11:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLdK-0003sc-3l for sipping@optimus.ietf.org; Wed, 21 Jan 2004 11:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29672 for ; Wed, 21 Jan 2004 11:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLdI-0007O8-00 for sipping@ietf.org; Wed, 21 Jan 2004 11:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLcR-0007M6-00 for sipping@ietf.org; Wed, 21 Jan 2004 11:54:20 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AjLbp-0007HA-00 for sipping@ietf.org; Wed, 21 Jan 2004 11:53:42 -0500 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 i0LGr8d11557 for ; Wed, 21 Jan 2004 10:53:08 -0600 From: Robert Sparks To: sipping@ietf.org Content-Type: text/plain Message-Id: <1074703987.908.82.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 21 Jan 2004 10:53:07 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Torture test revision: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've just submitted -03 of the torture test document. It's available at http://www.nostrum.com/~rjsparks/draft-ietf-sipping-torture-tests-03.html and http://www.nostrum.com/~rjsparks/draft-ietf-sipping-torture-tests-03.txt until it shows up in the repository. This version reflects the following bug fixes: - 3.1.1.1 (wsinv) had a continuation line without leading whitespace - 3.1.1.2 (intmeth) had an unknown header where the name was separated from the value with an =, not a : - 3.1.1.7 (longreq) had a several bad end tags, causing the binary form of the message to be invalid. It also had a continuation line (the last Via hfv) with no leading whitespace - 3.1.2.5 (scalarlg) SIP/2.0.TCP changed to SIP/2.0/TCP - 3.3.4 (unksm2) and 3.3.5 (bext01) Max-Forward changed to Max-Forwards. - 3.3.7 (regaut) Aligned the Authorization header's unknown scheme challenge with the syntax requirements of 3261 - The binary forms of badaspec, badvers, bext01, novelsc, and regbadct were missing the null-line. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 03:45:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19077 for ; Fri, 23 Jan 2004 03:45:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwwU-0003iX-EG for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 03:45:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N8jU8d014284 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 03:45:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwwT-0003iH-AH for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 03:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19071 for ; Fri, 23 Jan 2004 03:45:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjwwQ-0005MT-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 03:45:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjwvX-0005L3-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 03:44:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjwvC-0005Jj-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 03:44:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajwv4-0003WW-B6; Fri, 23 Jan 2004 03:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajwuc-0003Vr-6x for sipping@optimus.ietf.org; Fri, 23 Jan 2004 03:43:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19036 for ; Fri, 23 Jan 2004 03:43:31 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjwuZ-0005JG-00 for sipping@ietf.org; Fri, 23 Jan 2004 03:43:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajwth-0005HQ-00 for sipping@ietf.org; Fri, 23 Jan 2004 03:42:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ajwt9-0005F6-00 for sipping@ietf.org; Fri, 23 Jan 2004 03:42:03 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0N8g3Y00898 for ; Fri, 23 Jan 2004 10:42:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 23 Jan 2004 10:42:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 10:41:59 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jan 2004 10:41:59 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797619@esebe019.ntc.nokia.com> Thread-Topic: Conference policy URI Thread-Index: AcPhjMDPbh5RwS8nQmWV/RECzZEBKg== To: X-OriginalArrivalTime: 23 Jan 2004 08:41:59.0541 (UTC) FILETIME=[C3EF3250:01C3E18C] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Conference policy URI Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, There was consensus on the XCON mailing list that the conference state = event package needs to include in the notification the conference policy = URI. There was also consensus that some participants may not want to = subscribe to the conference package but would still like to learn the = conference policy URI. In this case, it was suggested that the Call-info = header carries such information. Perhaps the cc-conferencing draft can = include examples of that. Thanks, Hisham _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 05:35:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23409 for ; Fri, 23 Jan 2004 05:35:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajyes-00059z-En for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 05:35:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NAZQ53019833 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 05:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajyes-00059o-9j for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 05:35:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23337 for ; Fri, 23 Jan 2004 05:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajyeo-0004mG-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 05:35:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajydj-0004dK-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 05:34:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajyci-0004Te-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 05:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjycX-0004uR-Ik; Fri, 23 Jan 2004 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajyc2-0004tY-1W for sipping@optimus.ietf.org; Fri, 23 Jan 2004 05:32:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23172 for ; Fri, 23 Jan 2004 05:32:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajybt-0004Rp-00 for sipping@ietf.org; Fri, 23 Jan 2004 05:32:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjyYQ-0004Jc-00 for sipping@ietf.org; Fri, 23 Jan 2004 05:28:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AjyVe-0004Ch-00 for sipping@ietf.org; Fri, 23 Jan 2004 05:25:55 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0NAPUV15981 for ; Fri, 23 Jan 2004 12:25:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 23 Jan 2004 12:25:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 23 Jan 2004 12:25:28 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jan 2004 12:25:27 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797620@esebe019.ntc.nokia.com> Thread-Topic: isfocus in Refer-to header Thread-Index: AcPhmzVRvWB19vGiSRaAg1KAoZDaLA== To: X-OriginalArrivalTime: 23 Jan 2004 10:25:28.0297 (UTC) FILETIME=[38A42D90:01C3E19B] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] isfocus in Refer-to header Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, It is stated in the changes since section of = draft-ietf-sipping-cc-conferencing-02.txt: - Removed inclusion of "isfocus" parameter in Refer-To header field - this may be a useful extension to the REFER mechanism in the future, however. Why was that reason for such removal? Regards, Hisham _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 10:26:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05192 for ; Fri, 23 Jan 2004 10:26:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3C0-00087Q-EF for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFPupQ031201 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 10:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3C0-00087A-9a for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:25:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05129 for ; Fri, 23 Jan 2004 10:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Bx-0002qR-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:25:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3B8-0002mt-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:25:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3AR-0002is-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3AB-0007S6-Fw; Fri, 23 Jan 2004 10:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak39U-0007Ls-Ez for sipping@optimus.ietf.org; Fri, 23 Jan 2004 10:23:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04739; Fri, 23 Jan 2004 10:23:16 -0500 (EST) Message-Id: <200401231523.KAA04739@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 23 Jan 2004 10:23:16 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-torture-tests-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Torture Test Messages Author(s) : R. Sparks Filename : draft-ietf-sipping-torture-tests-03.txt Pages : 51 Date : 2004-1-22 This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and 'torture' a parser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-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-sipping-torture-tests-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-sipping-torture-tests-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: <2004-1-23104734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-torture-tests-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-torture-tests-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23104734.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 10:58:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07050 for ; Fri, 23 Jan 2004 10:58:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gk-0003Xy-Rk for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFvgb7013630 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 10:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3gk-0003Xl-Op for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:57:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06891 for ; Fri, 23 Jan 2004 10:57:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3gh-0004Rq-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:57:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3f7-0004Af-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:56:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3db-0003ow-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:54:27 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak3Nz-00079o-BU for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 10:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ni-0001kd-0b; Fri, 23 Jan 2004 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Nd-0001iw-L1 for sipping@optimus.ietf.org; Fri, 23 Jan 2004 10:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06020 for ; Fri, 23 Jan 2004 10:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3NZ-0003MO-00 for sipping@ietf.org; Fri, 23 Jan 2004 10:37:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Mk-0003KV-00 for sipping@ietf.org; Fri, 23 Jan 2004 10:37:03 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Lx-0003EY-00 for sipping@ietf.org; Fri, 23 Jan 2004 10:36:13 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HRY000R08GUZE@firewall.mci.com> for sipping@ietf.org; Fri, 23 Jan 2004 15:31:43 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HRY00M018AJP3@pmismtp01.wcomnet.com>; Fri, 23 Jan 2004 15:31:42 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.135.131]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HRY00MAG8G2P0@pmismtp01.wcomnet.com>; Fri, 23 Jan 2004 15:31:16 +0000 (GMT) Date: Fri, 23 Jan 2004 09:31:12 -0600 From: Alan Johnston Subject: Re: [Sipping] isfocus in Refer-to header In-reply-to: <2038BCC78B1AD641891A0D1AE133DBB701797620@esebe019.ntc.noki a.com> X-Sender: Alan.Johnston@pop.mcit.com To: hisham.khartabil@nokia.com, sipping@ietf.org Message-id: <5.2.1.1.0.20040123092703.02efbaf0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Hisham, The inclusion of feature tags such as "isfocus" was proposed in draft-olson-sipping-refer-extensions-00.txt, an individual I-D that has expired. Should this I-D be revised and gain support in the WG, we'd be happy to include it in cc-conferencing again as it is a very useful extension. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 12:25 PM 1/23/2004 +0200, hisham.khartabil@nokia.com wrote: >Hi, > >It is stated in the changes since section of >draft-ietf-sipping-cc-conferencing-02.txt: > >- Removed inclusion of "isfocus" parameter in Refer-To header field - > this may be a useful extension to the REFER mechanism in the future, > however. > >Why was that reason for such removal? > >Regards, >Hisham > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 12:32:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12568 for ; Fri, 23 Jan 2004 12:32:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak59m-0004Wq-Qt for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 12:31:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NHVkuV017407 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 12:31:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak59m-0004WU-M1 for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12553 for ; Fri, 23 Jan 2004 12:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak59j-000378-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 12:31:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak58o-00035v-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 12:30:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak58H-000351-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 12:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak588-0004Lz-52; Fri, 23 Jan 2004 12:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak57t-0004Ky-NU for sipping@optimus.ietf.org; Fri, 23 Jan 2004 12:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12510 for ; Fri, 23 Jan 2004 12:29:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak57s-00034Z-00 for sipping@ietf.org; Fri, 23 Jan 2004 12:29:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak56z-00033L-00 for sipping@ietf.org; Fri, 23 Jan 2004 12:28:54 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1Ak56T-00030K-00 for sipping@ietf.org; Fri, 23 Jan 2004 12:28:21 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i0NHRcEq018717; Fri, 23 Jan 2004 11:27:38 -0600 (CST) Received: from ericsson.com (rvi2-92-189.sw.ericsson.se [153.88.92.189]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR56WWBV; Fri, 23 Jan 2004 11:27:21 -0600 Message-ID: <4011598A.3070506@ericsson.com> Date: Fri, 23 Jan 2004 19:27:38 +0200 X-Sybari-Trust: 943d3379 76be5e0c 125231cb 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Dean Willis , Rohan Mahy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Active individual contributions Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have updated the supplemental web page: http://www.softarmor.com/wgdb/?wg=SIPPING If you have an *active* individual contribution that does not appear in the list above, send me a mail and I will add it to the list. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jan 23 21:49:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08707 for ; Fri, 23 Jan 2004 21:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDr5-0000P4-NA for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 21:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O2n3dB001546 for sipping-archive@odin.ietf.org; Fri, 23 Jan 2004 21:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDr5-0000Or-Gq for sipping-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 21:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08681 for ; Fri, 23 Jan 2004 21:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkDr2-0004cx-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 21:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkDq3-0004bK-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 21:48:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkDp7-0004Zi-00 for sipping-web-archive@ietf.org; Fri, 23 Jan 2004 21:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDp7-0000AC-0o; Fri, 23 Jan 2004 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkDoE-00009m-Ki for sipping@optimus.ietf.org; Fri, 23 Jan 2004 21:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08638 for ; Fri, 23 Jan 2004 21:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkDoB-0004Xx-00 for sipping@ietf.org; Fri, 23 Jan 2004 21:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkDnG-0004WM-00 for sipping@ietf.org; Fri, 23 Jan 2004 21:45:07 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AkDms-0004Uw-00 for sipping@ietf.org; Fri, 23 Jan 2004 21:44:42 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0O2iK9W008175; Fri, 23 Jan 2004 21:44:21 -0500 (EST) Message-ID: <4011DBF9.5010302@dynamicsoft.com> Date: Fri, 23 Jan 2004 21:44:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Conference policy URI References: <2038BCC78B1AD641891A0D1AE133DBB701797619@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797619@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think this is a reasonable usage of Call-Info. However, it can only be done if a "purpose" tag value is registered with IANA, as indicated by section 20.9. However, it ocurred to me, when reading this, that we never set up an IANA registry for call-info purpose tokens! Oops! Thats easily rectifiable; when the draft defining the 'policy-uri' (or whatever its called) purpose tag is written, it should also create the registry and register the other tokens defined in rfc3261. -Jonathan R. hisham.khartabil@nokia.com wrote: > Hi, > > There was consensus on the XCON mailing list that the conference > state event package needs to include in the notification the > conference policy URI. > > There was also consensus that some participants may not want to > subscribe to the conference package but would still like to learn > the conference policy URI. In this case, it was suggested that the > Call-info header carries such information. Perhaps the > cc-conferencing draft can include examples of that. > > Thanks, Hisham > > _______________________________________________ Sipping mailing > list https://www1.ietf.org/mailman/listinfo/sipping This list is > for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 06:01:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29305 for ; Tue, 27 Jan 2004 06:01:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQxb-00026S-HF for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 06:00:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RB0lnK008078 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 06:00:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQxb-00026D-2P for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 06:00:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29293 for ; Tue, 27 Jan 2004 06:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlQxX-0007Rk-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 06:00:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlQwc-0007Oa-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 05:59:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlQvv-0007LB-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 05:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQuv-0001nl-IW; Tue, 27 Jan 2004 05:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQuY-0001n5-Um for sipping@optimus.ietf.org; Tue, 27 Jan 2004 05:57:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29146 for ; Tue, 27 Jan 2004 05:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlQuV-0007GH-00 for sipping@ietf.org; Tue, 27 Jan 2004 05:57:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlQtY-0007Dd-00 for sipping@ietf.org; Tue, 27 Jan 2004 05:56:38 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AlQsg-0007Bk-00 for sipping@ietf.org; Tue, 27 Jan 2004 05:55:43 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0RAtYqZ016725; Tue, 27 Jan 2004 11:55:39 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 11:55:33 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Paul Kyzivat'" , Takuya Sawada Cc: sipping@ietf.org Date: Tue, 27 Jan 2004 11:55:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sipping] RE: Need to clarify rules for offer/answer usage in sip Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Hi, I pretty much agree on Takuya's "summary too". However, my understanding is still that you can only send an SDP in a PRACK once (either 18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by Takuya). After that, before the INVITE transactions has completed, you'll have to use UPDATE. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 26. tammikuuta 2004 18:43 > To: Takuya Sawada > Cc: Christer Holmberg (JO/LMF); sipping@ietf.org > Subject: Need to clarify rules for offer/answer usage in sip > > > Takuya, > > You make good points. I think you have convinced me of how this all > needs to work. I believe we are also both in agreement that the > necessary behavior is currently underspecified in the RFCs. > > I think a useful next step would be to hear from the authors > of the RFCs > in question, and hopefully obtain their concurrence. Then we > can discuss > the best way to formalize this. I am moving this to the > sipping list and > changing the title in order to pick up those authors, some of which > don't normally watch sip-implementors. > > Paul > > Takuya Sawada wrote: > > Hi, Paul, > > > > Let me summarize my view of "restrictions" defined in the > current SIP RFCs. > > * Probably I think I may share the same view with Christer > in most parts. > > > > Offer/Answer exchange described in RFC 3264 is independent from > > higher layer protocol. > > Higher layer protocol provides means to exchange offer/answer > > and this needs to provide means for resolving "glare" situation > > as described in the last paragraph in RFC 3264. > > > > [How to provide means to exchange offer/answer in SIP] > > > > > > RFC 3261 provides the following two ways to exchange offer/answer; > > - INVITE/2xx > > - 2xx/ACK > > See the page 80 in RFC 3261. > > > > > > RFC 3262 provides the additional three ways to exchange > offer/answer; > > Note that here "1xx" is a reliable provisional response to INVITE. > > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be > the first 1xx) > > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the > first reliable response. > > - PRACK/2xx(PRACK) ... Only after a completion of > INVITE/1xx or 1xx/PRACK. > > See chapter 5 in RFC 3262. > > > > > > RFC 3311 provides an additional way to exchange; > > - UPDATE/2xx(UPDATE) > > Only when after any offer/answer exchange defined in RFC > 3261 and RFC 3262 > > has completed and no offer/answer exchange in progress. > > See section 5.1, 5.2 in RFC 3311. > > > > Currently, as far as I understand, no other ways are not > defined in any RFCs. > > Assuming this is correct, let me clarify how to resolve > "glare" cases. > > * I can not imagine how to resolve "glare" if other > offer/answer exchanges > > are possible beyond my assumption here. > > > > [How to resolve "glare" condition] > > One reason why the usage of a SIP method to exchange offer/answer > > needs to be carefully restricted in RFCs is that UA must > detect mis-ordered > > message delivery and must avoid confusion. > > In RFC 3264, "it MUST NOT generate a new offer if it has > > received an offer which it has not yet answered or rejected. > > it MUST NOT generate a new offer if it has generated a > > prior offer for which it has not yet received an answer or > a rejection." > > So now there seems to be two possible message crossing case > > to be considered assuming that the above rules are guaranteed. > > > > Case1 > > A B > > |offer1 | > > |--------------->| > > | answer1| > > |<-----\ /-------| > > | X offer2| > > |<-----/ \-------| > > > > Case2 > > A B > > |offer1 offer2| > > |------\ /-------| > > | X | > > |<-----/ \------>| > > > > Case1: > > Assuming that offer/answer exchange follows the > restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 500 with Retry-After, when > > offer2 is UPDATE. And I assume that it can apply to reINVITE, > > which may not be stated clearly. > > I am not sure that when this happens when offer2 is in PRACK. > > But probably 500 with Retry-After will also apply, even it > results in > > delay for reliabile transfer mechanism for provisional response. > > In the case that offer2 is in the first reliable > provisional response > > or ACK, it seems to me that it never happens, if there is a > rule that > > INVITE, even w/o SDP, must not be sent if pending offer exists. > > I am not sure whether it is clearly stated. > > > > Case2: > > Assuming that offer/answer exchange follows the > restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 491, if it is UPDATE or > (re)INVITE. > > In the case that offer2 is in PRACK, it may be accepted with 200 or > > may be rejected with 491. 491 may be adequate for > offer/answer but it may > > delay the completion of a reliable response transfer > mechanism or, in > > worst case, may result in failure to complete SIP > transaction because > > there is no clear retry rule when PRACK is rejected with 491. > > When RFC 3262 was defined, there were no UPDATE, therefore > offer in PRACK > > never collides with other offers from the other side. I > guess this is why > > there is no rule in RFC 3262 when PRACK offer collides with > UPDATE offer. > > (It is safe to use UPDATE instead of PRACK when UPDATE is supported) > > Anyway, because there is no PRACK against PRACK collision > in the current > > RFCs, the other side is always expected to send 491. > > There is no possibility that offer2 is in the first > reliable response or ACK. > > Because A must not send new offer when it send INVITE w/o offer. > > > > Is this a correct summary? > > > > More comments inline with [TS]. > > > > > >>Takuya, > >> > >>RFC 3312 introduces situations in which multiple > offer/answer exchanges > >>are required before a single INVITE transaction can > complete. Of course > >>multiple transactions are involved because PRACK and/or > UPDATE are used > >>to achieve part of the exchange, but the INVITE transaction > can't finish > >>until they are done. > >> > >>This is at least one case in which offers and answers are > spread across > >>transactions in complex ways. > >> > > > > [TS] In my reading so far, there is the only one case which > offer/answer is > > across transaction, that is offer in the first reliable > provisional response > > of INVITE and answer is in PRACK. There is no other case > that an offer is in > > a transaction and an answer is in another transaction. > > I agree with that any number of offer/answer exchanges can > occur during > > one INVITE transaction. > > > > > >>There are also cases independent of 3312 where there is a > need to send a > >>subsequent offer/answer before an invite transaction completes. For > >>instance, this is one of the techniques for dealing with > port conflicts > >>introduced as a result of forking. > >> > > > > [TS] Yes. I did not disagree with that an offer in UPDATE > request can > > be used before the completion of INVITE transaction. > > > > > >>Once an invite transaction has completed, including one or more > >>offer/answer pairs, additional offer/answer cycles can be initiated > >>using either reINVITE or UPDATE. > >> > >>In the case of reINVITE, I believe there is a requirement > that one or > >>more offer/answer cycles be completed before it can > succeed. And if it > >>fails, the changed tentatively imparted by all of those > offer/answer > >>cycles are to be rolled back. > >> > >>The case of UPDATE is a little less clear. If there is no invite > >>transaction in progress, and an offer is sent in an UPDATE, and the > >>update is rejected, it must be the case that the dialog > state remains as > >>it was before the update. If there is no invite in progress and an > >>UPDATE is sent without an offer, there seems to be no prohibition > >>against sending an offer in the update response. In that case, the > >>answerer would have no way to refuse the offer and retain > the dialog as > >>it is. The only option the answerer would have is to send > another UPDATE > >>containing the answer. I doubt this is intended behavior, > but it isn't > >>prohibited. > >> > > > > [TS] This is the point I can not agree. I can not find any > description that > > UPDATE response can contain an offer in RFC 3311. IMO, this > means UPDATE response > > can not have any offer. SIP RFCs define restrictions to > utilize RFC 3264 model. > > UAs can not do any offer/answer exchange which is not > defined clearly in any RFCs. > > > > > >>More below. > >> > >>Paul > >> > >>Takuya Sawada wrote: > >> > >>>Hi, > >>> > >>>In my understanding, > >>> > >>>- Once previous offer/answer completes each side can issue > new offer. > >>>- INVITE request contains the offer, and the first > reliable 1xx response > >>> which contains answer, offer/answer for the INVITE > transaction completes. > >>>- UPDATE transaction and PRACK transaction can exchange > offer/answer. > >>>- Therefore, once the reliable 1xx response which contains > answer is received, > >>> caller can start offer/answer with PRACK or UPDATE or > any new method. > >>> And once the reliable 1xx response which contains answer is sent, > >>> callee can start offer/answer with UPDATE. > >>> > >>> > >>> > >>>>P.S. For those with the patience, below I have tried to > enumerate all > >>>>the offer/answer cases thru the 2nd offer. It is pretty painful. > >>>> > >>> > >>> > >>> > >>>>2) invite with 100rel > >>>> a) offer in invite > >>>> Possible places for answer: > >>>> i) answer in first reliable 1xx > >>>> ii) answer in subsequent reliable 1xx > >>>> iii) answer in 2xx > >>>> b) offer not in invite > >>>> offer must be in first reliable 1xx > >>>> answer must be in PRACK to 1xx w/offer > >>>> > >>>>Multiple offer/answer cycle prior to completion of invite. > >>>>Can only happen in subcases of (2) above. > >>>>It requires use of UPDATE in some cases. > >>>> > >>>>3) original offerer sends 2nd offer > >>>> a) following 2.a.i or 2.a.i.i: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in PRACK of answer1 > >>>> ii) offer2 in PRACK of some subsequent 1xx > >>>> iii) offer2 in UPDATE > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2.b: > >>>> i) offer2 in 2xx to PRACK w/answer1 > >>>> ii) offer2 in UPDATE > >>>> > >>>>4) original answerer sends 2nd offer: > >>>> Not clear if this is intended to be legal at all prior to > >>>> completion of invite. It appears existing text permits > >>>> as follows: > >>>> a) following 2.a.i or 2.a.ii: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in 2xx to prack of answer1. > >>>> ii) offer2 in subsequent reliable 1xx > >>>> following the one carrying answer1. > >>>> iii) offer2 in UPDATE following answer1. > >>>> (No reason to prefer this to other possibilities.) > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2b: > >>>> i) if another reliable 1xx is received, > >>>> could send offer2 in the PRACK. > >>>> (but can't count on this happening.) > >>>> ii) offer2 in UPDATE after sending answer1. > >>> > >>> > >>>I do not think offer/answer exchange beyond the SIP transaction > >>>is possible. I am not sure it is prohibited somewhere in RFC, but > >>>even if it is not prohibited explicitly, one should not assumed > >>>that is possible. > >> > >>Following the principle of being conservative in what you send and > >>liberal in what you receive, I want to assume that I might receive > >>anything that isn't prohibited, and do something reasonable with it. > >> > > > > [TS] I love this principle. IMO, if I receive an SDP which > I do not expect > > to receive in RFC, one possible solution is that I will > accept SIP message > > and ignore the SDP. Content-Disposition header's handling parameter > > should be checked, though. > > Anyway, here I do not know what is something reasonable to > do with it. > > > > > >>I would be willing to be conservative in initiating this stuff if I > >>could figure out what that is. Given the current state of > >>underspecification I don't know that I will draw the same > conclusion > >>than anyone else will. > >> > > > > [TS] There seems to be some uderspecification in RFCs. But > I want to > > confirm the following; > > RFCs only state where and when an offer and an answer can appear. > > If RFCs do not state "it can", then it MUST NOT contain > offer/answer. > > Because RFCs define "restrictions" where and when offer/answer > > exchange can occur. > > First I think we should reach a consensus with this point. > > > > > >> > One can achieve the same thing without such a > >> > >>>tweak. > >> > >>Not sure what you are referring to here, or whether it is > negated in > >>your subsequent posting. See above for a number of things > that must be > >>possible. > >> > >> > >>>Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. > >> > >>If we can codify a clear, and complete, set of rules for > where offers > >>and answers can appear, that provides full functionality, and it > >>excludes these cases, then fine. > >> > >>In the case of 4.a.1, removing it causes no loss of > functionality, so I > >>am inclined to agree. It might ultimately result in exchanging more > >>messages, but the number is probably insignificant. > >> > >>In the case of 3.c.1, removing it requires that both sides support > >>UPDATE. So its removal may remove functionality in the case > where one > >>side or the other doesn't support UPDATE. This may or may not be > >>significant. > >> > > > > [TS] As you said, UPDATE can solve the problem. > > You can use extensions when it wants the functionality that > the base > > specifications can not provide. This is what the extensions are. > > > > > >>>Anyway for INVITE transaction, as explained in my previous mail, > >>>it is clear in RFC 3261 to me that one INVITE transaction can > >>>include only one offer/answer exchange. > >>> > >>>Then 4.a.ii is not permitted. > >> > >>I think I identified cases above where this is needed. > >> > > > > [TS] The reason I think it is not permitted is, as Christer > pointed our, > > that RFC 3261 does not permit and any other RFCs do not override it. > > > > > >>Takuya Sawada wrote: > >> > Hi, > >> > > >> > > >> >>I do not think offer/answer exchange beyond the SIP transaction > >> >>is possible. I am not sure it is prohibited somewhere in RFC, but > >> >>even if it is not prohibited explicitly, one should not assumed > >> >>that is possible. One can achieve the same thing without such a > >> >>tweak. > >> > > >> > > >> > I am not exactly correct here. > >> > When an offer is in INVITE reliable provisonal response and > >> > an answer is in PRACK offer/answer exchange is beyond one > >> > transaction. > >> > What I want to say is that how offer/answer is used in a certain > >> > method is explicitly scoped in each RFC which defines the method. > >> > >>The trouble with these is that they were written in a > certain order. As > >>each was written, a broadening of thinking seems to have > occurred. This > >>is reflected in each, but not necessarily fully reflected > in the earlier > >>specs. > >> > > > > [TS] I may agree with this. At least this makes it > difficult to understand > > and share the same view among all. Actually, there seems to > be a little > > ambiguity with PRACK and UPDATE collision case as I pointed > > out in this mail, etc. > > > > > >> > How PRACK is used for offer/answer is defined in RFC 3262. > >> > There seems to be only two cases: > >> > - offer/answer is reliable 1xx(INVITE)/PRACK > >> > - offer/answer is PRACK/2xx(PRACK) > >> > only after INVITE's offer/answer exchange complete. > >> > >>I agree that this seems pretty well locked down as it > relates to 3261. > >>These lock downs of course do apply to the things that came > later. But > >>they seem at least awkward and arbitrary in some cases. > >> > >> > How UPDATE is used for offer/answer is defined in RFC 3311. > >> > - offer/answer is UPDATE/2xx(UPDATE) > >> > >>Here I disagree. I looked pretty closely at this, and I > don't see *any* > >>normative language for how offer/answer is used with it. There is a > >>bunch of non-normative language which appears to simply restate > >>implications of 3261 and 3264 in the presence of update. > >> > > > > [TS] Again, this is the point I can not agree. I agree with > that there is > > no normative language to prohibit offer in the response of UPDATE > > like "2xx response to UPDATE MUST NOT contain offer". > > Actually, response can have an SDP even if UPDATE does not have > > an offer SDP. But an SDP can be neither an offer nor an answer > > unless clear semantics are defined in any RFCs. I can not find > > any usage or semantics to use offer/answer exchange beyond > > one UPDATE transaction. > > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > > offer is neither an offer nor an answer like SDP in INFO is > > neither an offer nor an answer. > > > > > >> > How INVITE is used for offer/answer is defined in RFC 3261. > >> > - offer/answer is INVITE/non-failure reliable response > >> > - offer/answer is the first non-failure first > >>response/acknowlegement for the response > >> > , which is 2xx(INVITE)/ACK in RFC 3261 and > 1xx(INVITE)/PRACK in > >>RFC 3262. > >> > * Note that the second or later SDP in INVITE > non-failure response > >> > is not an offer. It is nothing. > >> > > >> > There is no other way than explicitly defined in any RFC, IMO. > >> > >>I believe you are right that nothing more is explicitly defined. > >>But 3264 is pretty general and broad. It is not prescriptive in how > >>offers and answers are transmitted. > > > > > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > > to exchange offer/answer in higher layer protocol. > > > > > >>And while the other RFCs may not > >>explicitly specify other ways, there are other ways that aren't > >>explicitly prohibited. In general with sip, things that aren't > >>explicitly prohibited are permitted. > >> > > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > > But without semantics, it is neither an offer nor an answer. > > > > > >>I just want to get this nailed down, so I know how to build > a stack that > >>can both handle every valid case thrown at it, and that can > initiate all > >>the needed functionality. > >> > >>I am thinking that maybe somebody (probably me) needs to > write a best > >>practices document that pulls this all together, specifying > all the ways > >>that offer/answer can be used. Following that, I think it will be > >>advisable to tighten up one or more of the RFCs in places > where things > >>haven't been prohibited but should be. > >> > > > > [TS] The guideline document that you are proposing can be useful. > > Collecting all the possible collision cases, recommending UPDATE > > offer rather than PRACK offer if UPDATE is supported and no need > > to reduce the number of messages, enumerating Warning header code > > examples to be included when offer is rejected with 488, etc. > > > > Regards, > > Takuya > > > > > >>Paul > >> > >>_______________________________________________ > >>Sip-implementors mailing list > >>Sip-implementors@cs.columbia.edu > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > -------- > > Takuya Sawada > > KDDI Corporation (KDDI) > > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > > Tokyo 102-8460, Japan > > Tel: +81-3-6678-2997 > > Fax: +81-3-6678-0285 > > tu-sawada@kddi.com > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 09:02:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05153 for ; Tue, 27 Jan 2004 09:02:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTmu-0000nn-VR for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 09:01:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RE1uHW003080 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 09:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTmu-0000nT-QT for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:01:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05137 for ; Tue, 27 Jan 2004 09:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTms-0003Iy-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 09:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTlv-0003Eh-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 09:00:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTlF-0003Ab-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 09:00:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTl6-0000S6-Og; Tue, 27 Jan 2004 09:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTkx-0000QY-UW for sipping@optimus.ietf.org; Tue, 27 Jan 2004 08:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05050 for ; Tue, 27 Jan 2004 08:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTkw-00039g-00 for sipping@ietf.org; Tue, 27 Jan 2004 08:59:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTk1-000363-00 for sipping@ietf.org; Tue, 27 Jan 2004 08:58:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AlTjd-00031y-00 for sipping@ietf.org; Tue, 27 Jan 2004 08:58:34 -0500 Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0RDvxIe024477 for ; Tue, 27 Jan 2004 08:58:00 -0500 (EST) Received: from ARUNVENKW2K1 (rcdn-vpn-cluster-1-5.cisco.com [10.89.16.5]) by whoami.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH54809; Tue, 27 Jan 2004 07:57:58 -0600 (CST) From: "arunvenk" To: Subject: RE: [Sipping] RE: Need to clarify rules for offer/answer usage in sip Date: Tue, 27 Jan 2004 08:03:13 -0600 Message-ID: <000201c3e4de$4e1ad5c0$0200a8c0@amer.cisco.com> 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.4024 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer You state that " you can only send an SDP in a PRACK once". If you have more than one rel prov response and the most recent one arrives without an offer and there is no incomplete offer/answer at that time, a new offer could be sent in the PRACK, I would think. Venkat -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Christer Holmberg (JO/LMF) Sent: Tuesday, January 27, 2004 4:55 AM To: 'Paul Kyzivat'; Takuya Sawada Cc: sipping@ietf.org Subject: [Sipping] RE: Need to clarify rules for offer/answer usage in sip Hi, I pretty much agree on Takuya's "summary too". However, my understanding is still that you can only send an SDP in a PRACK once (either 18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by Takuya). After that, before the INVITE transactions has completed, you'll have to use UPDATE. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 26. tammikuuta 2004 18:43 > To: Takuya Sawada > Cc: Christer Holmberg (JO/LMF); sipping@ietf.org > Subject: Need to clarify rules for offer/answer usage in sip > > > Takuya, > > You make good points. I think you have convinced me of how this all > needs to work. I believe we are also both in agreement that the > necessary behavior is currently underspecified in the RFCs. > > I think a useful next step would be to hear from the authors > of the RFCs > in question, and hopefully obtain their concurrence. Then we > can discuss > the best way to formalize this. I am moving this to the > sipping list and > changing the title in order to pick up those authors, some of which > don't normally watch sip-implementors. > > Paul > > Takuya Sawada wrote: > > Hi, Paul, > > > > Let me summarize my view of "restrictions" defined in the > current SIP RFCs. > > * Probably I think I may share the same view with Christer > in most parts. > > > > Offer/Answer exchange described in RFC 3264 is independent from > > higher layer protocol. > > Higher layer protocol provides means to exchange offer/answer > > and this needs to provide means for resolving "glare" situation > > as described in the last paragraph in RFC 3264. > > > > [How to provide means to exchange offer/answer in SIP] > > > > > > RFC 3261 provides the following two ways to exchange offer/answer; > > - INVITE/2xx > > - 2xx/ACK > > See the page 80 in RFC 3261. > > > > > > RFC 3262 provides the additional three ways to exchange > offer/answer; > > Note that here "1xx" is a reliable provisional response to INVITE. > > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be > the first 1xx) > > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the > first reliable response. > > - PRACK/2xx(PRACK) ... Only after a completion of > INVITE/1xx or 1xx/PRACK. > > See chapter 5 in RFC 3262. > > > > > > RFC 3311 provides an additional way to exchange; > > - UPDATE/2xx(UPDATE) > > Only when after any offer/answer exchange defined in RFC > 3261 and RFC 3262 > > has completed and no offer/answer exchange in progress. > > See section 5.1, 5.2 in RFC 3311. > > > > Currently, as far as I understand, no other ways are not > defined in any RFCs. > > Assuming this is correct, let me clarify how to resolve > "glare" cases. > > * I can not imagine how to resolve "glare" if other > offer/answer exchanges > > are possible beyond my assumption here. > > > > [How to resolve "glare" condition] > > One reason why the usage of a SIP method to exchange offer/answer > > needs to be carefully restricted in RFCs is that UA must > detect mis-ordered > > message delivery and must avoid confusion. > > In RFC 3264, "it MUST NOT generate a new offer if it has > > received an offer which it has not yet answered or rejected. > > it MUST NOT generate a new offer if it has generated a > > prior offer for which it has not yet received an answer or > a rejection." > > So now there seems to be two possible message crossing case > > to be considered assuming that the above rules are guaranteed. > > > > Case1 > > A B > > |offer1 | > > |--------------->| > > | answer1| > > |<-----\ /-------| > > | X offer2| > > |<-----/ \-------| > > > > Case2 > > A B > > |offer1 offer2| > > |------\ /-------| > > | X | > > |<-----/ \------>| > > > > Case1: > > Assuming that offer/answer exchange follows the > restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 500 with Retry-After, when > > offer2 is UPDATE. And I assume that it can apply to reINVITE, > > which may not be stated clearly. > > I am not sure that when this happens when offer2 is in PRACK. > > But probably 500 with Retry-After will also apply, even it > results in > > delay for reliabile transfer mechanism for provisional response. > > In the case that offer2 is in the first reliable > provisional response > > or ACK, it seems to me that it never happens, if there is a > rule that > > INVITE, even w/o SDP, must not be sent if pending offer exists. > > I am not sure whether it is clearly stated. > > > > Case2: > > Assuming that offer/answer exchange follows the > restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 491, if it is UPDATE or > (re)INVITE. > > In the case that offer2 is in PRACK, it may be accepted with 200 or > > may be rejected with 491. 491 may be adequate for > offer/answer but it may > > delay the completion of a reliable response transfer > mechanism or, in > > worst case, may result in failure to complete SIP > transaction because > > there is no clear retry rule when PRACK is rejected with 491. > > When RFC 3262 was defined, there were no UPDATE, therefore > offer in PRACK > > never collides with other offers from the other side. I > guess this is why > > there is no rule in RFC 3262 when PRACK offer collides with > UPDATE offer. > > (It is safe to use UPDATE instead of PRACK when UPDATE is supported) > > Anyway, because there is no PRACK against PRACK collision > in the current > > RFCs, the other side is always expected to send 491. > > There is no possibility that offer2 is in the first > reliable response or ACK. > > Because A must not send new offer when it send INVITE w/o offer. > > > > Is this a correct summary? > > > > More comments inline with [TS]. > > > > > >>Takuya, > >> > >>RFC 3312 introduces situations in which multiple > offer/answer exchanges > >>are required before a single INVITE transaction can > complete. Of course > >>multiple transactions are involved because PRACK and/or > UPDATE are used > >>to achieve part of the exchange, but the INVITE transaction > can't finish > >>until they are done. > >> > >>This is at least one case in which offers and answers are > spread across > >>transactions in complex ways. > >> > > > > [TS] In my reading so far, there is the only one case which > offer/answer is > > across transaction, that is offer in the first reliable > provisional response > > of INVITE and answer is in PRACK. There is no other case > that an offer is in > > a transaction and an answer is in another transaction. > > I agree with that any number of offer/answer exchanges can > occur during > > one INVITE transaction. > > > > > >>There are also cases independent of 3312 where there is a > need to send a > >>subsequent offer/answer before an invite transaction completes. For > >>instance, this is one of the techniques for dealing with > port conflicts > >>introduced as a result of forking. > >> > > > > [TS] Yes. I did not disagree with that an offer in UPDATE > request can > > be used before the completion of INVITE transaction. > > > > > >>Once an invite transaction has completed, including one or more > >>offer/answer pairs, additional offer/answer cycles can be initiated > >>using either reINVITE or UPDATE. > >> > >>In the case of reINVITE, I believe there is a requirement > that one or > >>more offer/answer cycles be completed before it can > succeed. And if it > >>fails, the changed tentatively imparted by all of those > offer/answer > >>cycles are to be rolled back. > >> > >>The case of UPDATE is a little less clear. If there is no invite > >>transaction in progress, and an offer is sent in an UPDATE, and the > >>update is rejected, it must be the case that the dialog > state remains as > >>it was before the update. If there is no invite in progress and an > >>UPDATE is sent without an offer, there seems to be no prohibition > >>against sending an offer in the update response. In that case, the > >>answerer would have no way to refuse the offer and retain > the dialog as > >>it is. The only option the answerer would have is to send > another UPDATE > >>containing the answer. I doubt this is intended behavior, > but it isn't > >>prohibited. > >> > > > > [TS] This is the point I can not agree. I can not find any > description that > > UPDATE response can contain an offer in RFC 3311. IMO, this > means UPDATE response > > can not have any offer. SIP RFCs define restrictions to > utilize RFC 3264 model. > > UAs can not do any offer/answer exchange which is not > defined clearly in any RFCs. > > > > > >>More below. > >> > >>Paul > >> > >>Takuya Sawada wrote: > >> > >>>Hi, > >>> > >>>In my understanding, > >>> > >>>- Once previous offer/answer completes each side can issue > new offer. > >>>- INVITE request contains the offer, and the first > reliable 1xx response > >>> which contains answer, offer/answer for the INVITE > transaction completes. > >>>- UPDATE transaction and PRACK transaction can exchange > offer/answer. > >>>- Therefore, once the reliable 1xx response which contains > answer is received, > >>> caller can start offer/answer with PRACK or UPDATE or > any new method. > >>> And once the reliable 1xx response which contains answer is sent, > >>> callee can start offer/answer with UPDATE. > >>> > >>> > >>> > >>>>P.S. For those with the patience, below I have tried to > enumerate all > >>>>the offer/answer cases thru the 2nd offer. It is pretty painful. > >>>> > >>> > >>> > >>> > >>>>2) invite with 100rel > >>>> a) offer in invite > >>>> Possible places for answer: > >>>> i) answer in first reliable 1xx > >>>> ii) answer in subsequent reliable 1xx > >>>> iii) answer in 2xx > >>>> b) offer not in invite > >>>> offer must be in first reliable 1xx > >>>> answer must be in PRACK to 1xx w/offer > >>>> > >>>>Multiple offer/answer cycle prior to completion of invite. > >>>>Can only happen in subcases of (2) above. > >>>>It requires use of UPDATE in some cases. > >>>> > >>>>3) original offerer sends 2nd offer > >>>> a) following 2.a.i or 2.a.i.i: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in PRACK of answer1 > >>>> ii) offer2 in PRACK of some subsequent 1xx > >>>> iii) offer2 in UPDATE > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2.b: > >>>> i) offer2 in 2xx to PRACK w/answer1 > >>>> ii) offer2 in UPDATE > >>>> > >>>>4) original answerer sends 2nd offer: > >>>> Not clear if this is intended to be legal at all prior to > >>>> completion of invite. It appears existing text permits > >>>> as follows: > >>>> a) following 2.a.i or 2.a.ii: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in 2xx to prack of answer1. > >>>> ii) offer2 in subsequent reliable 1xx > >>>> following the one carrying answer1. > >>>> iii) offer2 in UPDATE following answer1. > >>>> (No reason to prefer this to other possibilities.) > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2b: > >>>> i) if another reliable 1xx is received, > >>>> could send offer2 in the PRACK. > >>>> (but can't count on this happening.) > >>>> ii) offer2 in UPDATE after sending answer1. > >>> > >>> > >>>I do not think offer/answer exchange beyond the SIP transaction > >>>is possible. I am not sure it is prohibited somewhere in RFC, but > >>>even if it is not prohibited explicitly, one should not assumed > >>>that is possible. > >> > >>Following the principle of being conservative in what you send and > >>liberal in what you receive, I want to assume that I might receive > >>anything that isn't prohibited, and do something reasonable with it. > >> > > > > [TS] I love this principle. IMO, if I receive an SDP which > I do not expect > > to receive in RFC, one possible solution is that I will > accept SIP message > > and ignore the SDP. Content-Disposition header's handling parameter > > should be checked, though. > > Anyway, here I do not know what is something reasonable to > do with it. > > > > > >>I would be willing to be conservative in initiating this stuff if I > >>could figure out what that is. Given the current state of > >>underspecification I don't know that I will draw the same > conclusion > >>than anyone else will. > >> > > > > [TS] There seems to be some uderspecification in RFCs. But > I want to > > confirm the following; > > RFCs only state where and when an offer and an answer can appear. > > If RFCs do not state "it can", then it MUST NOT contain > offer/answer. > > Because RFCs define "restrictions" where and when offer/answer > > exchange can occur. > > First I think we should reach a consensus with this point. > > > > > >> > One can achieve the same thing without such a > >> > >>>tweak. > >> > >>Not sure what you are referring to here, or whether it is > negated in > >>your subsequent posting. See above for a number of things > that must be > >>possible. > >> > >> > >>>Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. > >> > >>If we can codify a clear, and complete, set of rules for > where offers > >>and answers can appear, that provides full functionality, and it > >>excludes these cases, then fine. > >> > >>In the case of 4.a.1, removing it causes no loss of > functionality, so I > >>am inclined to agree. It might ultimately result in exchanging more > >>messages, but the number is probably insignificant. > >> > >>In the case of 3.c.1, removing it requires that both sides support > >>UPDATE. So its removal may remove functionality in the case > where one > >>side or the other doesn't support UPDATE. This may or may not be > >>significant. > >> > > > > [TS] As you said, UPDATE can solve the problem. > > You can use extensions when it wants the functionality that > the base > > specifications can not provide. This is what the extensions are. > > > > > >>>Anyway for INVITE transaction, as explained in my previous mail, > >>>it is clear in RFC 3261 to me that one INVITE transaction can > >>>include only one offer/answer exchange. > >>> > >>>Then 4.a.ii is not permitted. > >> > >>I think I identified cases above where this is needed. > >> > > > > [TS] The reason I think it is not permitted is, as Christer > pointed our, > > that RFC 3261 does not permit and any other RFCs do not override it. > > > > > >>Takuya Sawada wrote: > >> > Hi, > >> > > >> > > >> >>I do not think offer/answer exchange beyond the SIP transaction > >> >>is possible. I am not sure it is prohibited somewhere in RFC, but > >> >>even if it is not prohibited explicitly, one should not assumed > >> >>that is possible. One can achieve the same thing without such a > >> >>tweak. > >> > > >> > > >> > I am not exactly correct here. > >> > When an offer is in INVITE reliable provisonal response and > >> > an answer is in PRACK offer/answer exchange is beyond one > >> > transaction. > >> > What I want to say is that how offer/answer is used in a certain > >> > method is explicitly scoped in each RFC which defines the method. > >> > >>The trouble with these is that they were written in a > certain order. As > >>each was written, a broadening of thinking seems to have > occurred. This > >>is reflected in each, but not necessarily fully reflected > in the earlier > >>specs. > >> > > > > [TS] I may agree with this. At least this makes it > difficult to understand > > and share the same view among all. Actually, there seems to > be a little > > ambiguity with PRACK and UPDATE collision case as I pointed > > out in this mail, etc. > > > > > >> > How PRACK is used for offer/answer is defined in RFC 3262. > >> > There seems to be only two cases: > >> > - offer/answer is reliable 1xx(INVITE)/PRACK > >> > - offer/answer is PRACK/2xx(PRACK) > >> > only after INVITE's offer/answer exchange complete. > >> > >>I agree that this seems pretty well locked down as it > relates to 3261. > >>These lock downs of course do apply to the things that came > later. But > >>they seem at least awkward and arbitrary in some cases. > >> > >> > How UPDATE is used for offer/answer is defined in RFC 3311. > >> > - offer/answer is UPDATE/2xx(UPDATE) > >> > >>Here I disagree. I looked pretty closely at this, and I > don't see *any* > >>normative language for how offer/answer is used with it. There is a > >>bunch of non-normative language which appears to simply restate > >>implications of 3261 and 3264 in the presence of update. > >> > > > > [TS] Again, this is the point I can not agree. I agree with > that there is > > no normative language to prohibit offer in the response of UPDATE > > like "2xx response to UPDATE MUST NOT contain offer". > > Actually, response can have an SDP even if UPDATE does not have > > an offer SDP. But an SDP can be neither an offer nor an answer > > unless clear semantics are defined in any RFCs. I can not find > > any usage or semantics to use offer/answer exchange beyond > > one UPDATE transaction. > > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > > offer is neither an offer nor an answer like SDP in INFO is > > neither an offer nor an answer. > > > > > >> > How INVITE is used for offer/answer is defined in RFC 3261. > >> > - offer/answer is INVITE/non-failure reliable response > >> > - offer/answer is the first non-failure first > >>response/acknowlegement for the response > >> > , which is 2xx(INVITE)/ACK in RFC 3261 and > 1xx(INVITE)/PRACK in > >>RFC 3262. > >> > * Note that the second or later SDP in INVITE > non-failure response > >> > is not an offer. It is nothing. > >> > > >> > There is no other way than explicitly defined in any RFC, IMO. > >> > >>I believe you are right that nothing more is explicitly defined. > >>But 3264 is pretty general and broad. It is not prescriptive in how > >>offers and answers are transmitted. > > > > > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > > to exchange offer/answer in higher layer protocol. > > > > > >>And while the other RFCs may not > >>explicitly specify other ways, there are other ways that aren't > >>explicitly prohibited. In general with sip, things that aren't > >>explicitly prohibited are permitted. > >> > > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > > But without semantics, it is neither an offer nor an answer. > > > > > >>I just want to get this nailed down, so I know how to build > a stack that > >>can both handle every valid case thrown at it, and that can > initiate all > >>the needed functionality. > >> > >>I am thinking that maybe somebody (probably me) needs to > write a best > >>practices document that pulls this all together, specifying > all the ways > >>that offer/answer can be used. Following that, I think it will be > >>advisable to tighten up one or more of the RFCs in places > where things > >>haven't been prohibited but should be. > >> > > > > [TS] The guideline document that you are proposing can be useful. > > Collecting all the possible collision cases, recommending UPDATE > > offer rather than PRACK offer if UPDATE is supported and no need > > to reduce the number of messages, enumerating Warning header code > > examples to be included when offer is rejected with 488, etc. > > > > Regards, > > Takuya > > > > > >>Paul > >> > >>_______________________________________________ > >>Sip-implementors mailing list > >>Sip-implementors@cs.columbia.edu > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > -------- > > Takuya Sawada > > KDDI Corporation (KDDI) > > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > > Tokyo 102-8460, Japan > > Tel: +81-3-6678-2997 > > Fax: +81-3-6678-0285 > > tu-sawada@kddi.com > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 19:23:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04200 for ; Tue, 27 Jan 2004 19:23:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldTg-0005lW-6L for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 19:22:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0Mith022156 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 19:22:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldTg-0005lH-2k for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:22:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04141 for ; Tue, 27 Jan 2004 19:22:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldTe-00006S-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldSX-0007gm-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:21:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AldRR-0007W8-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldL4-00039p-Ns; Tue, 27 Jan 2004 19:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlGNv-0005kH-Eh for sipping@optimus.ietf.org; Mon, 26 Jan 2004 18:43:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24920 for ; Mon, 26 Jan 2004 18:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlGNs-0003fi-00 for sipping@ietf.org; Mon, 26 Jan 2004 18:43:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlGMw-0003aU-00 for sipping@ietf.org; Mon, 26 Jan 2004 18:42:15 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AlGMJ-0003Vs-00 for sipping@ietf.org; Mon, 26 Jan 2004 18:41:35 -0500 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 i0QNehk01347; Mon, 26 Jan 2004 17:40:43 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 17:40:43 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753044D26C8@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Rohan Mahy Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] New Tones draft (was: "who plays the tone" or somet hing like that) Date: Mon, 26 Jan 2004 17:40:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E465.CF3CF7D8" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 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_01C3E465.CF3CF7D8 Content-Type: text/plain; charset="iso-8859-1" Rohan, Skimmed your draft and have a question... By using the content-disposition header it seems that we're requiring the request/response to contain content. In the case where a user agent receives an INVITE with no SDP in it (slow start call) it would seem that they'll use some sort of default alerting mechanism until they get the SDP setup (which may not happen until the 200 OK/ACK). In the case of your draft it would seem that this means the client may ring one way, then suddenly switch and ring a different way because it's not aware that there's going to be some alert information in the future. Am I correct, and if not, how does the draft approach this problem? Regards, Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 16, 2003 7:08 PM To: Rohan Mahy Cc: 'sipping@ietf.org' Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Rohan, I just got around to reading this draft. I think its neat. You say in your note below that its linked to app-interaction, but you don't use the app-interaction framework. I believe this is precisely the kind of thing we want to do with app-interaction - its a stimulus interface to the user. That means that you should be using app-info headers to convey the information, for example. Indeed, there are probably existing xml formats which may even do this. -Jonathan R. Rohan Mahy wrote: > Hi, > > I wrote the following draft in order to provide some discussion on > alternatives to in-band early-media ringback, and to discuss the issue > of playing tones in general which I believe is inherently linked to 3pcc > and application interaction. > > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.html > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.txt > > comments welcome. > thx, > -r > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C3E465.CF3CF7D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] New Tones draft (was: "who plays the = tone" or something like that)

Rohan,

Skimmed your draft and have a question... By using = the content-disposition header it seems that we're requiring the = request/response to contain content. In the case where a user agent = receives an INVITE with no SDP in it (slow start call) it would seem = that they'll use some sort of default alerting mechanism until they get = the SDP setup (which may not happen until the 200 OK/ACK). In the case = of your draft it would seem that this means the client may ring one = way, then suddenly switch and ring a different way because it's not = aware that there's going to be some alert information in the = future.

Am I correct, and if not, how does the draft approach = this problem?

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 16, 2003 7:08 PM
To: Rohan Mahy
Cc: 'sipping@ietf.org'
Subject: Re: [Sipping] New Tones draft (was: = "who plays the tone" or
something like that)


Rohan,

I just got around to reading this draft. I think its = neat. You say in
your note below that its linked to app-interaction, = but you don't use
the app-interaction framework. I believe this is = precisely the kind of
thing we want to do with app-interaction - its a = stimulus interface to
the user. That means that you should be using = app-info headers to
convey the information, for example.

Indeed, there are probably existing xml formats which = may even do this.

-Jonathan R.


Rohan Mahy wrote:

> Hi,
>
> I wrote the following draft in order to provide = some discussion on
> alternatives to in-band early-media ringback, = and to discuss the issue
> of playing tones in general which I believe is = inherently linked to 3pcc
> and application interaction.
>
> http://www.softarmor.com/sipping/drafts/draft-mahy-sip= ping-tones-00.html
> http://www.softarmor.com/sipping/drafts/draft-mahy-sip= ping-tones-00.txt
>
> comments welcome.
> thx,
> -r
>
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP
>

--
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza
Chief Technology = Officer           = ;         Parsippany, NJ = 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application = of SIP
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sip@ietf.org for new developments of core = SIP

------_=_NextPart_001_01C3E465.CF3CF7D8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 19:52:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06784 for ; Tue, 27 Jan 2004 19:52:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldw8-0008Jt-2D for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 19:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0q8uq031980 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 19:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldw7-0008Jj-UY for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06749 for ; Tue, 27 Jan 2004 19:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldw5-0003rw-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldv7-0003nB-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:51:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlduC-0003jf-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldu8-00081f-Ut; Tue, 27 Jan 2004 19:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldtD-00080I-9S for sipping@optimus.ietf.org; Tue, 27 Jan 2004 19:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06678 for ; Tue, 27 Jan 2004 19:49:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldtB-0003fM-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldsJ-0003cM-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:48:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Aldrz-0003Z6-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:47:52 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2004 16:47:23 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0S0l85g027176; Tue, 27 Jan 2004 19:47:08 -0500 (EST) 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 APR54065; Tue, 27 Jan 2004 16:45:26 -0800 (PST) Date: Tue, 27 Jan 2004 16:47:22 -0800 Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or somet hing like that) Content-Type: multipart/alternative; boundary=Apple-Mail-4-306878656 Mime-Version: 1.0 (Apple Message framework v553) Cc: Jonathan Rosenberg , "'sipping@ietf.org'" To: "Brian Stucker" From: Rohan Mahy In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B59753044D26C8@zrc2c012.us.nortel.com> Message-Id: <88C8487D-512B-11D8-A63C-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.553) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-4-306878656 Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Monday, January 26, 2004, at 03:40 PM, Brian Stucker wrote: > Rohan, > > Skimmed your draft and have a question... By using the =20 > content-disposition header it seems that we're requiring the =20 > request/response to contain content. In the case where a user agent =20= > receives an INVITE with no SDP in it (slow start call) it would seem =20= > that they'll use some sort of default alerting mechanism until they =20= > get the SDP setup (which may not happen until the 200 OK/ACK). In the =20= > case of your draft it would seem that this means the client may ring =20= > one way, then suddenly switch and ring a different way because it's =20= > not aware that there's going to be some alert information in the =20 > future. I'm not really sure of the scope of your question, but here goes... There is no reason you can't send ringing tones in a 18x before an =20 offer/answer exchange has completed. The two behaviors are independent. If you want to be able to control traditional early media though, you =20= really need the UAs to send early offers and answers (send an offer in =20= the INVITE and an answer in a reliable 18x, or send an offer in a =20 reliable 18x, send an answer in the PRACK). I hope this answers your question. thanks, -rohan > Am I correct, and if not, how does the draft approach this problem? > > Regards, > > Brian > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 16, 2003 7:08 PM > To: Rohan Mahy > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or > something like that) > > > Rohan, > > I just got around to reading this draft. I think its neat. You say in > your note below that its linked to app-interaction, but you don't use > the app-interaction framework. I believe this is precisely the kind of > thing we want to do with app-interaction - its a stimulus interface to > the user. That means that you should be using app-info headers to > convey the information, for example. > > Indeed, there are probably existing xml formats which may even do = this. > > -Jonathan R. > > > Rohan Mahy wrote: > > > Hi, > > > > I wrote the following draft in order to provide some discussion on > > alternatives to in-band early-media ringback, and to discuss the =20 > issue > > of playing tones in general which I believe is inherently linked to =20= > 3pcc > > and application interaction. > > > > =20 > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-=20 > 00.html > > =20 > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-> = 00.txt > > > > comments welcome. > > thx, > > -r > > > > _______________________________________________ > > Sipping mailing list=A0 = https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > -- > Jonathan D. Rosenberg, Ph.D.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= 600 Lanidex Plaza > Chief Technology Officer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 FAX:=A0=A0 (973) 952-5050 > http://www.jdrosen.net=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > --Apple-Mail-4-306878656 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Monday, January 26, 2004, at 03:40 PM, Brian Stucker wrote: Rohan, Skimmed your draft and have a question... By using the content-disposition header it seems that we're requiring the request/response to contain content. In the case where a user agent receives an INVITE with no SDP in it (slow start call) it would seem that they'll use some sort of default alerting mechanism until they get the SDP setup (which may not happen until the 200 OK/ACK). In the case of your draft it would seem that this means the client may ring one way, then suddenly switch and ring a different way because it's not aware that there's going to be some alert information in the future. I'm not really sure of the scope of your question, but here goes... There is no reason you can't send ringing tones in a 18x before an offer/answer exchange has completed. The two behaviors are independent. If you want to be able to control traditional early media though, you really need the UAs to send early offers and answers (send an offer in the INVITE and an answer in a reliable 18x, or send an offer in a reliable 18x, send an answer in the PRACK). I hope this answers your question. thanks, -rohan Am I correct, and if not, how does the draft approach this problem? Regards, Brian -----Original Message----- From: Jonathan Rosenberg = [1999,1999,FFFFmailto:jdrosen@dynamicsoft= .com] Sent: Wednesday, July 16, 2003 7:08 PM To: Rohan Mahy Cc: 'sipping@ietf.org' Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Rohan, I just got around to reading this draft. I think its neat. You say in your note below that its linked to app-interaction, but you don't use the app-interaction framework. I believe this is precisely the kind of thing we want to do with app-interaction - its a stimulus interface to the user. That means that you should be using app-info headers to convey the information, for example. Indeed, there are probably existing xml formats which may even do this. -Jonathan R. Rohan Mahy wrote: > Hi, > > I wrote the following draft in order to provide some discussion on > alternatives to in-band early-media ringback, and to discuss the issue > of playing tones in general which I believe is inherently linked to 3pcc > and application interaction. > > = 1999,1999,FFFFhttp://www.softarmor.com/si= pping/drafts/draft-mahy-sipping-tones-00.html > = 1999,1999,FFFFhttp://www.softarmor.com/si= pping/drafts/draft-mahy-sipping-tones-00.txt > > comments welcome. > thx, > -r > > _______________________________________________ > Sipping mailing list=A0 = 1999,1999,FFFFhttps://www1.ietf.org/mailm= an/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 600 Lanidex Plaza Chief Technology Officer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 FAX:=A0=A0 (973) 952-5050 = 1999,1999,FFFFhttp://www.jdrosen.net=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 PHONE: (973) 952-5000 = 1999,1999,FFFFhttp://www.dynamicsoft.com<= /color> _______________________________________________ Sipping mailing list=A0 = 1999,1999,FFFFhttps://www1.ietf.org/mailm= an/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP = --Apple-Mail-4-306878656-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 20:01:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07143 for ; Tue, 27 Jan 2004 20:01:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale4m-0000Js-Qb for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 20:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S114wP001222 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 20:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale4m-0000Jd-MU for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07120 for ; Tue, 27 Jan 2004 20:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ale4k-0004SH-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 20:01:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ale3m-0004Oo-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 20:00:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ale2p-0004LW-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 19:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale2o-0008UA-CH; Tue, 27 Jan 2004 19:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale1t-0008T0-Si for sipping@optimus.ietf.org; Tue, 27 Jan 2004 19:58:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07013 for ; Tue, 27 Jan 2004 19:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ale1s-0004IN-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:58:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ale0v-0004FF-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:57:06 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1Ale03-000497-00 for sipping@ietf.org; Tue, 27 Jan 2004 19:56:11 -0500 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 i0S0tFo03090; Tue, 27 Jan 2004 18:55:16 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jan 2004 18:55:15 -0600 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975304549C9F@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Rohan Mahy Cc: Jonathan Rosenberg , "'sipping@ietf.org'" Subject: RE: [Sipping] New Tones draft (was: "who plays the tone" or somet hing like that) Date: Tue, 27 Jan 2004 18:55:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E539.64B30018" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 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_01C3E539.64B30018 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, January 27, 2004 6:47 PM To: Stucker, Brian [NGC:B617:EXCH] Cc: Jonathan Rosenberg; 'sipping@ietf.org' Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or somet hing like that) On Monday, January 26, 2004, at 03:40 PM, Brian Stucker wrote: Rohan, Skimmed your draft and have a question... By using the content-disposition header it seems that we're requiring the request/response to contain content. In the case where a user agent receives an INVITE with no SDP in it (slow start call) it would seem that they'll use some sort of default alerting mechanism until they get the SDP setup (which may not happen until the 200 OK/ACK). In the case of your draft it would seem that this means the client may ring one way, then suddenly switch and ring a different way because it's not aware that there's going to be some alert information in the future. I'm not really sure of the scope of your question, but here goes... There is no reason you can't send ringing tones in a 18x before an offer/answer exchange has completed. The two behaviors are independent. [Stucker, Brian [NGC:B617:EXCH]] Oh, I agree that this is acceptable. What I was referring to are clients that start alerting the moment they get the INVITE (the terminator, not the originator). Basically, using your draft to ring the terminator in different ways, and not to overcome the extra early media sessions. If you want to be able to control traditional early media though, you really need the UAs to send early offers and answers (send an offer in the INVITE and an answer in a reliable 18x, or send an offer in a reliable 18x, send an answer in the PRACK). I hope this answers your question. thanks, -rohan Am I correct, and if not, how does the draft approach this problem? Regards, Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 16, 2003 7:08 PM To: Rohan Mahy Cc: 'sipping@ietf.org' Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Rohan, I just got around to reading this draft. I think its neat. You say in your note below that its linked to app-interaction, but you don't use the app-interaction framework. I believe this is precisely the kind of thing we want to do with app-interaction - its a stimulus interface to the user. That means that you should be using app-info headers to convey the information, for example. Indeed, there are probably existing xml formats which may even do this. -Jonathan R. Rohan Mahy wrote: > Hi, > > I wrote the following draft in order to provide some discussion on > alternatives to in-band early-media ringback, and to discuss the issue > of playing tones in general which I believe is inherently linked to 3pcc > and application interaction. > > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.html > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.txt > > comments welcome. > thx, > -r > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C3E539.64B30018 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Tuesday, January 27, 2004 6:47 PM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: Jonathan Rosenberg; 'sipping@ietf.org'
Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or somet hing like that)



On Monday, January 26, 2004, at 03:40 PM, Brian Stucker wrote:


Rohan,


Skimmed your draft and have a question... By using the content-disposition header it seems that we're requiring the request/response to contain content. In the case where a user agent receives an INVITE with no SDP in it (slow start call) it would seem that they'll use some sort of default alerting mechanism until they get the SDP setup (which may not happen until the 200 OK/ACK). In the case of your draft it would seem that this means the client may ring one way, then suddenly switch and ring a different way because it's not aware that there's going to be some alert information in the future.


I'm not really sure of the scope of your question, but here goes...


There is no reason you can't send ringing tones in a 18x before an offer/answer exchange has completed. The two behaviors are independent. 
[Stucker, Brian [NGC:B617:EXCH]]  Oh, I agree that this is acceptable. What I was referring to are clients that start alerting the moment they get the INVITE (the terminator, not the originator). Basically, using your draft to ring the terminator in different ways, and not to overcome the extra early media sessions. 


If you want to be able to control traditional early media though, you really need the UAs to send early offers and answers (send an offer in the INVITE and an answer in a reliable 18x, or send an offer in a reliable 18x, send an answer in the PRACK).


I hope this answers your question.


thanks,

-rohan


Am I correct, and if not, how does the draft approach this problem?


Regards,


Brian


-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Wednesday, July 16, 2003 7:08 PM

To: Rohan Mahy

Cc: 'sipping@ietf.org'

Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or

something like that)



Rohan,


I just got around to reading this draft. I think its neat. You say in

your note below that its linked to app-interaction, but you don't use

the app-interaction framework. I believe this is precisely the kind of

thing we want to do with app-interaction - its a stimulus interface to

the user. That means that you should be using app-info headers to

convey the information, for example.


Indeed, there are probably existing xml formats which may even do this.


-Jonathan R.



Rohan Mahy wrote:


> Hi,

>

> I wrote the following draft in order to provide some discussion on

> alternatives to in-band early-media ringback, and to discuss the issue

> of playing tones in general which I believe is inherently linked to 3pcc

> and application interaction.

>

> http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.html

> http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.txt

>

> comments welcome.

> thx,

> -r

>

> _______________________________________________

> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping

> This list is for NEW development of the application of SIP

> Use sip-implementors@cs.columbia.edu for questions on current sip

> Use sip@ietf.org for new developments of core 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



_______________________________________________

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping

This list is for NEW development of the application of SIP

Use sip-implementors@cs.columbia.edu for questions on current sip

Use sip@ietf.org for new developments of core SIP


------_=_NextPart_001_01C3E539.64B30018-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 21:30:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11654 for ; Tue, 27 Jan 2004 21:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfT0-0005HE-Qj for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 21:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S2UANU020280 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 21:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfT0-0005H1-Mo for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 21:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11636 for ; Tue, 27 Jan 2004 21:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfSx-00044b-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:30:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfRz-00040b-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:29:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlfR0-0003wk-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfQv-00052e-A5; Tue, 27 Jan 2004 21:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfQ4-00051M-RQ for sipping@optimus.ietf.org; Tue, 27 Jan 2004 21:27:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11604 for ; Tue, 27 Jan 2004 21:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfQ2-0003su-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfP5-0003qI-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:26:09 -0500 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1AlfOl-0003nt-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:25:48 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com (3.7W-030228132558) with ESMTP id LAA14640; Wed, 28 Jan 2004 11:25:01 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com (3.7W-040107142500) with ESMTP id LAA18688; Wed, 28 Jan 2004 11:25:01 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040128022459.SNAH5356.usjk1009.kddi.com@KDDI-0003PC0281.kddi.com>; Wed, 28 Jan 2004 11:24:59 +0900 To: christer.holmberg@ericsson.com, tu-sawada@kddi.com Cc: sipping@ietf.org Subject: Re: [Sipping] RE: Need to clarify rules for offer/answer usage in sip From: Takuya Sawada References: In-Reply-To: Message-Id: <200401281124.JGD39184.BTU-EBBXV@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Wed, 28 Jan 2004 11:24:51 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Hi, > > Hi, > > I pretty much agree on Takuya's "summary too". However, my understanding is still that you can only send an SDP in a PRACK once (either 18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by Takuya). After that, before the INVITE transactions has completed, you'll have to use UPDATE. > In my understanding, you can send PRACK(offer)/200(answer) cycles after the first offer/answer exchange completes and until INVITE transaction completes. But if both ends can support UPDATE, I recommend to use UPDATE for offer/answer cycles rather than PRACK. Drawbacks of PRACK are; - If PRACK is rejected due to the offer in PRACK, it would delay the reliable mechanism. - If it wants to send offer in PRACK, it ahs to wait for the reliable response. The advantage of PRACK over UPDATE is just saving one message cycle. But I am not sure I can say it "must" use UPDATE. Regards, Takuya > Regards, > > Christer Holmberg > Ericsson Finland > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 26. tammikuuta 2004 18:43 > > To: Takuya Sawada > > Cc: Christer Holmberg (JO/LMF); sipping@ietf.org > > Subject: Need to clarify rules for offer/answer usage in sip > > > > > > Takuya, > > > > You make good points. I think you have convinced me of how this all > > needs to work. I believe we are also both in agreement that the > > necessary behavior is currently underspecified in the RFCs. > > > > I think a useful next step would be to hear from the authors > > of the RFCs > > in question, and hopefully obtain their concurrence. Then we > > can discuss > > the best way to formalize this. I am moving this to the > > sipping list and > > changing the title in order to pick up those authors, some of which > > don't normally watch sip-implementors. > > > > Paul > > > > Takuya Sawada wrote: > > > Hi, Paul, > > > > > > Let me summarize my view of "restrictions" defined in the > > current SIP RFCs. > > > * Probably I think I may share the same view with Christer > > in most parts. > > > > > > Offer/Answer exchange described in RFC 3264 is independent from > > > higher layer protocol. > > > Higher layer protocol provides means to exchange offer/answer > > > and this needs to provide means for resolving "glare" situation > > > as described in the last paragraph in RFC 3264. > > > > > > [How to provide means to exchange offer/answer in SIP] > > > > > > > > > RFC 3261 provides the following two ways to exchange offer/answer; > > > - INVITE/2xx > > > - 2xx/ACK > > > See the page 80 in RFC 3261. > > > > > > > > > RFC 3262 provides the additional three ways to exchange > > offer/answer; > > > Note that here "1xx" is a reliable provisional response to INVITE. > > > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be > > the first 1xx) > > > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the > > first reliable response. > > > - PRACK/2xx(PRACK) ... Only after a completion of > > INVITE/1xx or 1xx/PRACK. > > > See chapter 5 in RFC 3262. > > > > > > > > > RFC 3311 provides an additional way to exchange; > > > - UPDATE/2xx(UPDATE) > > > Only when after any offer/answer exchange defined in RFC > > 3261 and RFC 3262 > > > has completed and no offer/answer exchange in progress. > > > See section 5.1, 5.2 in RFC 3311. > > > > > > Currently, as far as I understand, no other ways are not > > defined in any RFCs. > > > Assuming this is correct, let me clarify how to resolve > > "glare" cases. > > > * I can not imagine how to resolve "glare" if other > > offer/answer exchanges > > > are possible beyond my assumption here. > > > > > > [How to resolve "glare" condition] > > > One reason why the usage of a SIP method to exchange offer/answer > > > needs to be carefully restricted in RFCs is that UA must > > detect mis-ordered > > > message delivery and must avoid confusion. > > > In RFC 3264, "it MUST NOT generate a new offer if it has > > > received an offer which it has not yet answered or rejected. > > > it MUST NOT generate a new offer if it has generated a > > > prior offer for which it has not yet received an answer or > > a rejection." > > > So now there seems to be two possible message crossing case > > > to be considered assuming that the above rules are guaranteed. > > > > > > Case1 > > > A B > > > |offer1 | > > > |--------------->| > > > | answer1| > > > |<-----\ /-------| > > > | X offer2| > > > |<-----/ \-------| > > > > > > Case2 > > > A B > > > |offer1 offer2| > > > |------\ /-------| > > > | X | > > > |<-----/ \------>| > > > > > > Case1: > > > Assuming that offer/answer exchange follows the > > restrictions I described > > > above, A can know an SDP in offer2 is not an answer to offer1. > > > Then offer2 must be rejected with a 500 with Retry-After, when > > > offer2 is UPDATE. And I assume that it can apply to reINVITE, > > > which may not be stated clearly. > > > I am not sure that when this happens when offer2 is in PRACK. > > > But probably 500 with Retry-After will also apply, even it > > results in > > > delay for reliabile transfer mechanism for provisional response. > > > In the case that offer2 is in the first reliable > > provisional response > > > or ACK, it seems to me that it never happens, if there is a > > rule that > > > INVITE, even w/o SDP, must not be sent if pending offer exists. > > > I am not sure whether it is clearly stated. > > > > > > Case2: > > > Assuming that offer/answer exchange follows the > > restrictions I described > > > above, A can know an SDP in offer2 is not an answer to offer1. > > > Then offer2 must be rejected with a 491, if it is UPDATE or > > (re)INVITE. > > > In the case that offer2 is in PRACK, it may be accepted with 200 or > > > may be rejected with 491. 491 may be adequate for > > offer/answer but it may > > > delay the completion of a reliable response transfer > > mechanism or, in > > > worst case, may result in failure to complete SIP > > transaction because > > > there is no clear retry rule when PRACK is rejected with 491. > > > When RFC 3262 was defined, there were no UPDATE, therefore > > offer in PRACK > > > never collides with other offers from the other side. I > > guess this is why > > > there is no rule in RFC 3262 when PRACK offer collides with > > UPDATE offer. > > > (It is safe to use UPDATE instead of PRACK when UPDATE is supported) > > > Anyway, because there is no PRACK against PRACK collision > > in the current > > > RFCs, the other side is always expected to send 491. > > > There is no possibility that offer2 is in the first > > reliable response or ACK. > > > Because A must not send new offer when it send INVITE w/o offer. > > > > > > Is this a correct summary? > > > > > > More comments inline with [TS]. > > > > > > > > >>Takuya, > > >> > > >>RFC 3312 introduces situations in which multiple > > offer/answer exchanges > > >>are required before a single INVITE transaction can > > complete. Of course > > >>multiple transactions are involved because PRACK and/or > > UPDATE are used > > >>to achieve part of the exchange, but the INVITE transaction > > can't finish > > >>until they are done. > > >> > > >>This is at least one case in which offers and answers are > > spread across > > >>transactions in complex ways. > > >> > > > > > > [TS] In my reading so far, there is the only one case which > > offer/answer is > > > across transaction, that is offer in the first reliable > > provisional response > > > of INVITE and answer is in PRACK. There is no other case > > that an offer is in > > > a transaction and an answer is in another transaction. > > > I agree with that any number of offer/answer exchanges can > > occur during > > > one INVITE transaction. > > > > > > > > >>There are also cases independent of 3312 where there is a > > need to send a > > >>subsequent offer/answer before an invite transaction completes. For > > >>instance, this is one of the techniques for dealing with > > port conflicts > > >>introduced as a result of forking. > > >> > > > > > > [TS] Yes. I did not disagree with that an offer in UPDATE > > request can > > > be used before the completion of INVITE transaction. > > > > > > > > >>Once an invite transaction has completed, including one or more > > >>offer/answer pairs, additional offer/answer cycles can be initiated > > >>using either reINVITE or UPDATE. > > >> > > >>In the case of reINVITE, I believe there is a requirement > > that one or > > >>more offer/answer cycles be completed before it can > > succeed. And if it > > >>fails, the changed tentatively imparted by all of those > > offer/answer > > >>cycles are to be rolled back. > > >> > > >>The case of UPDATE is a little less clear. If there is no invite > > >>transaction in progress, and an offer is sent in an UPDATE, and the > > >>update is rejected, it must be the case that the dialog > > state remains as > > >>it was before the update. If there is no invite in progress and an > > >>UPDATE is sent without an offer, there seems to be no prohibition > > >>against sending an offer in the update response. In that case, the > > >>answerer would have no way to refuse the offer and retain > > the dialog as > > >>it is. The only option the answerer would have is to send > > another UPDATE > > >>containing the answer. I doubt this is intended behavior, > > but it isn't > > >>prohibited. > > >> > > > > > > [TS] This is the point I can not agree. I can not find any > > description that > > > UPDATE response can contain an offer in RFC 3311. IMO, this > > means UPDATE response > > > can not have any offer. SIP RFCs define restrictions to > > utilize RFC 3264 model. > > > UAs can not do any offer/answer exchange which is not > > defined clearly in any RFCs. > > > > > > > > >>More below. > > >> > > >>Paul > > >> > > >>Takuya Sawada wrote: > > >> > > >>>Hi, > > >>> > > >>>In my understanding, > > >>> > > >>>- Once previous offer/answer completes each side can issue > > new offer. > > >>>- INVITE request contains the offer, and the first > > reliable 1xx response > > >>> which contains answer, offer/answer for the INVITE > > transaction completes. > > >>>- UPDATE transaction and PRACK transaction can exchange > > offer/answer. > > >>>- Therefore, once the reliable 1xx response which contains > > answer is received, > > >>> caller can start offer/answer with PRACK or UPDATE or > > any new method. > > >>> And once the reliable 1xx response which contains answer is sent, > > >>> callee can start offer/answer with UPDATE. > > >>> > > >>> > > >>> > > >>>>P.S. For those with the patience, below I have tried to > > enumerate all > > >>>>the offer/answer cases thru the 2nd offer. It is pretty painful. > > >>>> > > >>> > > >>> > > >>> > > >>>>2) invite with 100rel > > >>>> a) offer in invite > > >>>> Possible places for answer: > > >>>> i) answer in first reliable 1xx > > >>>> ii) answer in subsequent reliable 1xx > > >>>> iii) answer in 2xx > > >>>> b) offer not in invite > > >>>> offer must be in first reliable 1xx > > >>>> answer must be in PRACK to 1xx w/offer > > >>>> > > >>>>Multiple offer/answer cycle prior to completion of invite. > > >>>>Can only happen in subcases of (2) above. > > >>>>It requires use of UPDATE in some cases. > > >>>> > > >>>>3) original offerer sends 2nd offer > > >>>> a) following 2.a.i or 2.a.i.i: > > >>>> Possible places for 2nd offer: > > >>>> i) offer2 in PRACK of answer1 > > >>>> ii) offer2 in PRACK of some subsequent 1xx > > >>>> iii) offer2 in UPDATE > > >>>> b) following 2.a.iii: > > >>>> No 2nd offer possible until after completion of invite. > > >>>> c) following 2.b: > > >>>> i) offer2 in 2xx to PRACK w/answer1 > > >>>> ii) offer2 in UPDATE > > >>>> > > >>>>4) original answerer sends 2nd offer: > > >>>> Not clear if this is intended to be legal at all prior to > > >>>> completion of invite. It appears existing text permits > > >>>> as follows: > > >>>> a) following 2.a.i or 2.a.ii: > > >>>> Possible places for 2nd offer: > > >>>> i) offer2 in 2xx to prack of answer1. > > >>>> ii) offer2 in subsequent reliable 1xx > > >>>> following the one carrying answer1. > > >>>> iii) offer2 in UPDATE following answer1. > > >>>> (No reason to prefer this to other possibilities.) > > >>>> b) following 2.a.iii: > > >>>> No 2nd offer possible until after completion of invite. > > >>>> c) following 2b: > > >>>> i) if another reliable 1xx is received, > > >>>> could send offer2 in the PRACK. > > >>>> (but can't count on this happening.) > > >>>> ii) offer2 in UPDATE after sending answer1. > > >>> > > >>> > > >>>I do not think offer/answer exchange beyond the SIP transaction > > >>>is possible. I am not sure it is prohibited somewhere in RFC, but > > >>>even if it is not prohibited explicitly, one should not assumed > > >>>that is possible. > > >> > > >>Following the principle of being conservative in what you send and > > >>liberal in what you receive, I want to assume that I might receive > > >>anything that isn't prohibited, and do something reasonable with it. > > >> > > > > > > [TS] I love this principle. IMO, if I receive an SDP which > > I do not expect > > > to receive in RFC, one possible solution is that I will > > accept SIP message > > > and ignore the SDP. Content-Disposition header's handling parameter > > > should be checked, though. > > > Anyway, here I do not know what is something reasonable to > > do with it. > > > > > > > > >>I would be willing to be conservative in initiating this stuff if I > > >>could figure out what that is. Given the current state of > > >>underspecification I don't know that I will draw the same > > conclusion > > >>than anyone else will. > > >> > > > > > > [TS] There seems to be some uderspecification in RFCs. But > > I want to > > > confirm the following; > > > RFCs only state where and when an offer and an answer can appear. > > > If RFCs do not state "it can", then it MUST NOT contain > > offer/answer. > > > Because RFCs define "restrictions" where and when offer/answer > > > exchange can occur. > > > First I think we should reach a consensus with this point. > > > > > > > > >> > One can achieve the same thing without such a > > >> > > >>>tweak. > > >> > > >>Not sure what you are referring to here, or whether it is > > negated in > > >>your subsequent posting. See above for a number of things > > that must be > > >>possible. > > >> > > >> > > >>>Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. > > >> > > >>If we can codify a clear, and complete, set of rules for > > where offers > > >>and answers can appear, that provides full functionality, and it > > >>excludes these cases, then fine. > > >> > > >>In the case of 4.a.1, removing it causes no loss of > > functionality, so I > > >>am inclined to agree. It might ultimately result in exchanging more > > >>messages, but the number is probably insignificant. > > >> > > >>In the case of 3.c.1, removing it requires that both sides support > > >>UPDATE. So its removal may remove functionality in the case > > where one > > >>side or the other doesn't support UPDATE. This may or may not be > > >>significant. > > >> > > > > > > [TS] As you said, UPDATE can solve the problem. > > > You can use extensions when it wants the functionality that > > the base > > > specifications can not provide. This is what the extensions are. > > > > > > > > >>>Anyway for INVITE transaction, as explained in my previous mail, > > >>>it is clear in RFC 3261 to me that one INVITE transaction can > > >>>include only one offer/answer exchange. > > >>> > > >>>Then 4.a.ii is not permitted. > > >> > > >>I think I identified cases above where this is needed. > > >> > > > > > > [TS] The reason I think it is not permitted is, as Christer > > pointed our, > > > that RFC 3261 does not permit and any other RFCs do not override it. > > > > > > > > >>Takuya Sawada wrote: > > >> > Hi, > > >> > > > >> > > > >> >>I do not think offer/answer exchange beyond the SIP transaction > > >> >>is possible. I am not sure it is prohibited somewhere in RFC, but > > >> >>even if it is not prohibited explicitly, one should not assumed > > >> >>that is possible. One can achieve the same thing without such a > > >> >>tweak. > > >> > > > >> > > > >> > I am not exactly correct here. > > >> > When an offer is in INVITE reliable provisonal response and > > >> > an answer is in PRACK offer/answer exchange is beyond one > > >> > transaction. > > >> > What I want to say is that how offer/answer is used in a certain > > >> > method is explicitly scoped in each RFC which defines the method. > > >> > > >>The trouble with these is that they were written in a > > certain order. As > > >>each was written, a broadening of thinking seems to have > > occurred. This > > >>is reflected in each, but not necessarily fully reflected > > in the earlier > > >>specs. > > >> > > > > > > [TS] I may agree with this. At least this makes it > > difficult to understand > > > and share the same view among all. Actually, there seems to > > be a little > > > ambiguity with PRACK and UPDATE collision case as I pointed > > > out in this mail, etc. > > > > > > > > >> > How PRACK is used for offer/answer is defined in RFC 3262. > > >> > There seems to be only two cases: > > >> > - offer/answer is reliable 1xx(INVITE)/PRACK > > >> > - offer/answer is PRACK/2xx(PRACK) > > >> > only after INVITE's offer/answer exchange complete. > > >> > > >>I agree that this seems pretty well locked down as it > > relates to 3261. > > >>These lock downs of course do apply to the things that came > > later. But > > >>they seem at least awkward and arbitrary in some cases. > > >> > > >> > How UPDATE is used for offer/answer is defined in RFC 3311. > > >> > - offer/answer is UPDATE/2xx(UPDATE) > > >> > > >>Here I disagree. I looked pretty closely at this, and I > > don't see *any* > > >>normative language for how offer/answer is used with it. There is a > > >>bunch of non-normative language which appears to simply restate > > >>implications of 3261 and 3264 in the presence of update. > > >> > > > > > > [TS] Again, this is the point I can not agree. I agree with > > that there is > > > no normative language to prohibit offer in the response of UPDATE > > > like "2xx response to UPDATE MUST NOT contain offer". > > > Actually, response can have an SDP even if UPDATE does not have > > > an offer SDP. But an SDP can be neither an offer nor an answer > > > unless clear semantics are defined in any RFCs. I can not find > > > any usage or semantics to use offer/answer exchange beyond > > > one UPDATE transaction. > > > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > > > offer is neither an offer nor an answer like SDP in INFO is > > > neither an offer nor an answer. > > > > > > > > >> > How INVITE is used for offer/answer is defined in RFC 3261. > > >> > - offer/answer is INVITE/non-failure reliable response > > >> > - offer/answer is the first non-failure first > > >>response/acknowlegement for the response > > >> > , which is 2xx(INVITE)/ACK in RFC 3261 and > > 1xx(INVITE)/PRACK in > > >>RFC 3262. > > >> > * Note that the second or later SDP in INVITE > > non-failure response > > >> > is not an offer. It is nothing. > > >> > > > >> > There is no other way than explicitly defined in any RFC, IMO. > > >> > > >>I believe you are right that nothing more is explicitly defined. > > >>But 3264 is pretty general and broad. It is not prescriptive in how > > >>offers and answers are transmitted. > > > > > > > > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > > > to exchange offer/answer in higher layer protocol. > > > > > > > > >>And while the other RFCs may not > > >>explicitly specify other ways, there are other ways that aren't > > >>explicitly prohibited. In general with sip, things that aren't > > >>explicitly prohibited are permitted. > > >> > > > > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > > > But without semantics, it is neither an offer nor an answer. > > > > > > > > >>I just want to get this nailed down, so I know how to build > > a stack that > > >>can both handle every valid case thrown at it, and that can > > initiate all > > >>the needed functionality. > > >> > > >>I am thinking that maybe somebody (probably me) needs to > > write a best > > >>practices document that pulls this all together, specifying > > all the ways > > >>that offer/answer can be used. Following that, I think it will be > > >>advisable to tighten up one or more of the RFCs in places > > where things > > >>haven't been prohibited but should be. > > >> > > > > > > [TS] The guideline document that you are proposing can be useful. > > > Collecting all the possible collision cases, recommending UPDATE > > > offer rather than PRACK offer if UPDATE is supported and no need > > > to reduce the number of messages, enumerating Warning header code > > > examples to be included when offer is rejected with 488, etc. > > > > > > Regards, > > > Takuya > > > > > > > > >>Paul > > >> > > >>_______________________________________________ > > >>Sip-implementors mailing list > > >>Sip-implementors@cs.columbia.edu > > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > -------- > > > Takuya Sawada > > > KDDI Corporation (KDDI) > > > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > > > Tokyo 102-8460, Japan > > > Tel: +81-3-6678-2997 > > > Fax: +81-3-6678-0285 > > > tu-sawada@kddi.com > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jan 27 21:50:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12746 for ; Tue, 27 Jan 2004 21:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfmL-0006fe-Hr for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 21:50:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S2o9ed025638 for sipping-archive@odin.ietf.org; Tue, 27 Jan 2004 21:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfmL-0006fR-Dq for sipping-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 21:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12739 for ; Tue, 27 Jan 2004 21:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfmI-0005d8-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlflJ-0005Z6-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:49:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlfkL-0005Tt-00 for sipping-web-archive@ietf.org; Tue, 27 Jan 2004 21:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfkI-0006Sd-EY; Tue, 27 Jan 2004 21:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfjX-0006SA-P6 for sipping@optimus.ietf.org; Tue, 27 Jan 2004 21:47:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12670 for ; Tue, 27 Jan 2004 21:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfjU-0005S4-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:47:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alfid-0005OT-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:46:21 -0500 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1AlfiO-0005Jr-00 for sipping@ietf.org; Tue, 27 Jan 2004 21:46:04 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com (3.7W-030228132558) with ESMTP id LAA21531; Wed, 28 Jan 2004 11:45:18 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com (3.7W-040107142500) with ESMTP id LAA28548; Wed, 28 Jan 2004 11:45:18 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040128024517.OTIK13285.usjk1010.kddi.com@KDDI-0003PC0281.kddi.com>; Wed, 28 Jan 2004 11:45:17 +0900 To: pkyzivat@cisco.com, tu-sawada@kddi.com Cc: sipping@ietf.org Subject: Re: [Sipping] Need to clarify rules for offer/answer usage in sip From: Takuya Sawada References: <4010591C.20906@cisco.com> <200401231011.FII81205.-BEUXBVBT@kddi.com> <40114D8C.8040308@cisco.com> <200401260934.IHD39627.BXBV-UTBE@kddi.com> <4015438D.2060909@cisco.com> In-Reply-To: <4015438D.2060909@cisco.com> Message-Id: <200401281145.AED01246.TUB-BEXVB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Wed, 28 Jan 2004 11:45:07 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Hi, Though, it has already pointed out and corrected in sip-implementors mailing list, I want to add one correction to my summary below here for sure. I wrote; "In the case that offer2 is in the first reliable provisional response or ACK," the correct words are "In the case that offer2 is in the first reliable provisional response or 2xx," And also I wrote; "There is no possibility that offer2 is in the first reliable response or ACK." I wanted to say "There is no possibility that offer2 is in the first reliable response or 2xx." I think we can agree on the most parts, it may need some clarifications, thogh, if we could read through the multiple documents carefully. But some may think differently and implemente their interpretation on their devices. It seems to be dangerous. Paul's proposal, I think, would be formalizing this as a document like call flow examples documents. Some people may consider this as a useful work to desrve doing this. Some may not. Regards, Takuya > Takuya, > > You make good points. I think you have convinced me of how this all > needs to work. I believe we are also both in agreement that the > necessary behavior is currently underspecified in the RFCs. > > I think a useful next step would be to hear from the authors of the RFCs > in question, and hopefully obtain their concurrence. Then we can discuss > the best way to formalize this. I am moving this to the sipping list and > changing the title in order to pick up those authors, some of which > don't normally watch sip-implementors. > > Paul > > Takuya Sawada wrote: > > Hi, Paul, > > > > Let me summarize my view of "restrictions" defined in the current SIP RFCs. > > * Probably I think I may share the same view with Christer in most parts. > > > > Offer/Answer exchange described in RFC 3264 is independent from > > higher layer protocol. > > Higher layer protocol provides means to exchange offer/answer > > and this needs to provide means for resolving "glare" situation > > as described in the last paragraph in RFC 3264. > > > > [How to provide means to exchange offer/answer in SIP] > > > > > > RFC 3261 provides the following two ways to exchange offer/answer; > > - INVITE/2xx > > - 2xx/ACK > > See the page 80 in RFC 3261. > > > > > > RFC 3262 provides the additional three ways to exchange offer/answer; > > Note that here "1xx" is a reliable provisional response to INVITE. > > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be the first 1xx) > > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the first reliable response. > > - PRACK/2xx(PRACK) ... Only after a completion of INVITE/1xx or 1xx/PRACK. > > See chapter 5 in RFC 3262. > > > > > > RFC 3311 provides an additional way to exchange; > > - UPDATE/2xx(UPDATE) > > Only when after any offer/answer exchange defined in RFC 3261 and RFC 3262 > > has completed and no offer/answer exchange in progress. > > See section 5.1, 5.2 in RFC 3311. > > > > Currently, as far as I understand, no other ways are not defined in any RFCs. > > Assuming this is correct, let me clarify how to resolve "glare" cases. > > * I can not imagine how to resolve "glare" if other offer/answer exchanges > > are possible beyond my assumption here. > > > > [How to resolve "glare" condition] > > One reason why the usage of a SIP method to exchange offer/answer > > needs to be carefully restricted in RFCs is that UA must detect mis-ordered > > message delivery and must avoid confusion. > > In RFC 3264, "it MUST NOT generate a new offer if it has > > received an offer which it has not yet answered or rejected. > > it MUST NOT generate a new offer if it has generated a > > prior offer for which it has not yet received an answer or a rejection." > > So now there seems to be two possible message crossing case > > to be considered assuming that the above rules are guaranteed. > > > > Case1 > > A B > > |offer1 | > > |--------------->| > > | answer1| > > |<-----\ /-------| > > | X offer2| > > |<-----/ \-------| > > > > Case2 > > A B > > |offer1 offer2| > > |------\ /-------| > > | X | > > |<-----/ \------>| > > > > Case1: > > Assuming that offer/answer exchange follows the restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 500 with Retry-After, when > > offer2 is UPDATE. And I assume that it can apply to reINVITE, > > which may not be stated clearly. > > I am not sure that when this happens when offer2 is in PRACK. > > But probably 500 with Retry-After will also apply, even it results in > > delay for reliabile transfer mechanism for provisional response. > > In the case that offer2 is in the first reliable provisional response > > or ACK, it seems to me that it never happens, if there is a rule that > > INVITE, even w/o SDP, must not be sent if pending offer exists. > > I am not sure whether it is clearly stated. > > > > Case2: > > Assuming that offer/answer exchange follows the restrictions I described > > above, A can know an SDP in offer2 is not an answer to offer1. > > Then offer2 must be rejected with a 491, if it is UPDATE or (re)INVITE. > > In the case that offer2 is in PRACK, it may be accepted with 200 or > > may be rejected with 491. 491 may be adequate for offer/answer but it may > > delay the completion of a reliable response transfer mechanism or, in > > worst case, may result in failure to complete SIP transaction because > > there is no clear retry rule when PRACK is rejected with 491. > > When RFC 3262 was defined, there were no UPDATE, therefore offer in PRACK > > never collides with other offers from the other side. I guess this is why > > there is no rule in RFC 3262 when PRACK offer collides with UPDATE offer. > > (It is safe to use UPDATE instead of PRACK when UPDATE is supported) > > Anyway, because there is no PRACK against PRACK collision in the current > > RFCs, the other side is always expected to send 491. > > There is no possibility that offer2 is in the first reliable response or ACK. > > Because A must not send new offer when it send INVITE w/o offer. > > > > Is this a correct summary? > > > > More comments inline with [TS]. > > > > > >>Takuya, > >> > >>RFC 3312 introduces situations in which multiple offer/answer exchanges > >>are required before a single INVITE transaction can complete. Of course > >>multiple transactions are involved because PRACK and/or UPDATE are used > >>to achieve part of the exchange, but the INVITE transaction can't finish > >>until they are done. > >> > >>This is at least one case in which offers and answers are spread across > >>transactions in complex ways. > >> > > > > [TS] In my reading so far, there is the only one case which offer/answer is > > across transaction, that is offer in the first reliable provisional response > > of INVITE and answer is in PRACK. There is no other case that an offer is in > > a transaction and an answer is in another transaction. > > I agree with that any number of offer/answer exchanges can occur during > > one INVITE transaction. > > > > > >>There are also cases independent of 3312 where there is a need to send a > >>subsequent offer/answer before an invite transaction completes. For > >>instance, this is one of the techniques for dealing with port conflicts > >>introduced as a result of forking. > >> > > > > [TS] Yes. I did not disagree with that an offer in UPDATE request can > > be used before the completion of INVITE transaction. > > > > > >>Once an invite transaction has completed, including one or more > >>offer/answer pairs, additional offer/answer cycles can be initiated > >>using either reINVITE or UPDATE. > >> > >>In the case of reINVITE, I believe there is a requirement that one or > >>more offer/answer cycles be completed before it can succeed. And if it > >>fails, the changed tentatively imparted by all of those offer/answer > >>cycles are to be rolled back. > >> > >>The case of UPDATE is a little less clear. If there is no invite > >>transaction in progress, and an offer is sent in an UPDATE, and the > >>update is rejected, it must be the case that the dialog state remains as > >>it was before the update. If there is no invite in progress and an > >>UPDATE is sent without an offer, there seems to be no prohibition > >>against sending an offer in the update response. In that case, the > >>answerer would have no way to refuse the offer and retain the dialog as > >>it is. The only option the answerer would have is to send another UPDATE > >>containing the answer. I doubt this is intended behavior, but it isn't > >>prohibited. > >> > > > > [TS] This is the point I can not agree. I can not find any description that > > UPDATE response can contain an offer in RFC 3311. IMO, this means UPDATE response > > can not have any offer. SIP RFCs define restrictions to utilize RFC 3264 model. > > UAs can not do any offer/answer exchange which is not defined clearly in any RFCs. > > > > > >>More below. > >> > >>Paul > >> > >>Takuya Sawada wrote: > >> > >>>Hi, > >>> > >>>In my understanding, > >>> > >>>- Once previous offer/answer completes each side can issue new offer. > >>>- INVITE request contains the offer, and the first reliable 1xx response > >>> which contains answer, offer/answer for the INVITE transaction completes. > >>>- UPDATE transaction and PRACK transaction can exchange offer/answer. > >>>- Therefore, once the reliable 1xx response which contains answer is received, > >>> caller can start offer/answer with PRACK or UPDATE or any new method. > >>> And once the reliable 1xx response which contains answer is sent, > >>> callee can start offer/answer with UPDATE. > >>> > >>> > >>> > >>>>P.S. For those with the patience, below I have tried to enumerate all > >>>>the offer/answer cases thru the 2nd offer. It is pretty painful. > >>>> > >>> > >>> > >>> > >>>>2) invite with 100rel > >>>> a) offer in invite > >>>> Possible places for answer: > >>>> i) answer in first reliable 1xx > >>>> ii) answer in subsequent reliable 1xx > >>>> iii) answer in 2xx > >>>> b) offer not in invite > >>>> offer must be in first reliable 1xx > >>>> answer must be in PRACK to 1xx w/offer > >>>> > >>>>Multiple offer/answer cycle prior to completion of invite. > >>>>Can only happen in subcases of (2) above. > >>>>It requires use of UPDATE in some cases. > >>>> > >>>>3) original offerer sends 2nd offer > >>>> a) following 2.a.i or 2.a.i.i: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in PRACK of answer1 > >>>> ii) offer2 in PRACK of some subsequent 1xx > >>>> iii) offer2 in UPDATE > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2.b: > >>>> i) offer2 in 2xx to PRACK w/answer1 > >>>> ii) offer2 in UPDATE > >>>> > >>>>4) original answerer sends 2nd offer: > >>>> Not clear if this is intended to be legal at all prior to > >>>> completion of invite. It appears existing text permits > >>>> as follows: > >>>> a) following 2.a.i or 2.a.ii: > >>>> Possible places for 2nd offer: > >>>> i) offer2 in 2xx to prack of answer1. > >>>> ii) offer2 in subsequent reliable 1xx > >>>> following the one carrying answer1. > >>>> iii) offer2 in UPDATE following answer1. > >>>> (No reason to prefer this to other possibilities.) > >>>> b) following 2.a.iii: > >>>> No 2nd offer possible until after completion of invite. > >>>> c) following 2b: > >>>> i) if another reliable 1xx is received, > >>>> could send offer2 in the PRACK. > >>>> (but can't count on this happening.) > >>>> ii) offer2 in UPDATE after sending answer1. > >>> > >>> > >>>I do not think offer/answer exchange beyond the SIP transaction > >>>is possible. I am not sure it is prohibited somewhere in RFC, but > >>>even if it is not prohibited explicitly, one should not assumed > >>>that is possible. > >> > >>Following the principle of being conservative in what you send and > >>liberal in what you receive, I want to assume that I might receive > >>anything that isn't prohibited, and do something reasonable with it. > >> > > > > [TS] I love this principle. IMO, if I receive an SDP which I do not expect > > to receive in RFC, one possible solution is that I will accept SIP message > > and ignore the SDP. Content-Disposition header's handling parameter > > should be checked, though. > > Anyway, here I do not know what is something reasonable to do with it. > > > > > >>I would be willing to be conservative in initiating this stuff if I > >>could figure out what that is. Given the current state of > >>underspecification I don't know that I will draw the same conclusion > >>than anyone else will. > >> > > > > [TS] There seems to be some uderspecification in RFCs. But I want to > > confirm the following; > > RFCs only state where and when an offer and an answer can appear. > > If RFCs do not state "it can", then it MUST NOT contain offer/answer. > > Because RFCs define "restrictions" where and when offer/answer > > exchange can occur. > > First I think we should reach a consensus with this point. > > > > > >> > One can achieve the same thing without such a > >> > >>>tweak. > >> > >>Not sure what you are referring to here, or whether it is negated in > >>your subsequent posting. See above for a number of things that must be > >>possible. > >> > >> > >>>Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. > >> > >>If we can codify a clear, and complete, set of rules for where offers > >>and answers can appear, that provides full functionality, and it > >>excludes these cases, then fine. > >> > >>In the case of 4.a.1, removing it causes no loss of functionality, so I > >>am inclined to agree. It might ultimately result in exchanging more > >>messages, but the number is probably insignificant. > >> > >>In the case of 3.c.1, removing it requires that both sides support > >>UPDATE. So its removal may remove functionality in the case where one > >>side or the other doesn't support UPDATE. This may or may not be > >>significant. > >> > > > > [TS] As you said, UPDATE can solve the problem. > > You can use extensions when it wants the functionality that the base > > specifications can not provide. This is what the extensions are. > > > > > >>>Anyway for INVITE transaction, as explained in my previous mail, > >>>it is clear in RFC 3261 to me that one INVITE transaction can > >>>include only one offer/answer exchange. > >>> > >>>Then 4.a.ii is not permitted. > >> > >>I think I identified cases above where this is needed. > >> > > > > [TS] The reason I think it is not permitted is, as Christer pointed our, > > that RFC 3261 does not permit and any other RFCs do not override it. > > > > > >>Takuya Sawada wrote: > >> > Hi, > >> > > >> > > >> >>I do not think offer/answer exchange beyond the SIP transaction > >> >>is possible. I am not sure it is prohibited somewhere in RFC, but > >> >>even if it is not prohibited explicitly, one should not assumed > >> >>that is possible. One can achieve the same thing without such a > >> >>tweak. > >> > > >> > > >> > I am not exactly correct here. > >> > When an offer is in INVITE reliable provisonal response and > >> > an answer is in PRACK offer/answer exchange is beyond one > >> > transaction. > >> > What I want to say is that how offer/answer is used in a certain > >> > method is explicitly scoped in each RFC which defines the method. > >> > >>The trouble with these is that they were written in a certain order. As > >>each was written, a broadening of thinking seems to have occurred. This > >>is reflected in each, but not necessarily fully reflected in the earlier > >>specs. > >> > > > > [TS] I may agree with this. At least this makes it difficult to understand > > and share the same view among all. Actually, there seems to be a little > > ambiguity with PRACK and UPDATE collision case as I pointed > > out in this mail, etc. > > > > > >> > How PRACK is used for offer/answer is defined in RFC 3262. > >> > There seems to be only two cases: > >> > - offer/answer is reliable 1xx(INVITE)/PRACK > >> > - offer/answer is PRACK/2xx(PRACK) > >> > only after INVITE's offer/answer exchange complete. > >> > >>I agree that this seems pretty well locked down as it relates to 3261. > >>These lock downs of course do apply to the things that came later. But > >>they seem at least awkward and arbitrary in some cases. > >> > >> > How UPDATE is used for offer/answer is defined in RFC 3311. > >> > - offer/answer is UPDATE/2xx(UPDATE) > >> > >>Here I disagree. I looked pretty closely at this, and I don't see *any* > >>normative language for how offer/answer is used with it. There is a > >>bunch of non-normative language which appears to simply restate > >>implications of 3261 and 3264 in the presence of update. > >> > > > > [TS] Again, this is the point I can not agree. I agree with that there is > > no normative language to prohibit offer in the response of UPDATE > > like "2xx response to UPDATE MUST NOT contain offer". > > Actually, response can have an SDP even if UPDATE does not have > > an offer SDP. But an SDP can be neither an offer nor an answer > > unless clear semantics are defined in any RFCs. I can not find > > any usage or semantics to use offer/answer exchange beyond > > one UPDATE transaction. > > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > > offer is neither an offer nor an answer like SDP in INFO is > > neither an offer nor an answer. > > > > > >> > How INVITE is used for offer/answer is defined in RFC 3261. > >> > - offer/answer is INVITE/non-failure reliable response > >> > - offer/answer is the first non-failure first > >>response/acknowlegement for the response > >> > , which is 2xx(INVITE)/ACK in RFC 3261 and 1xx(INVITE)/PRACK in > >>RFC 3262. > >> > * Note that the second or later SDP in INVITE non-failure response > >> > is not an offer. It is nothing. > >> > > >> > There is no other way than explicitly defined in any RFC, IMO. > >> > >>I believe you are right that nothing more is explicitly defined. > >>But 3264 is pretty general and broad. It is not prescriptive in how > >>offers and answers are transmitted. > > > > > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > > to exchange offer/answer in higher layer protocol. > > > > > >>And while the other RFCs may not > >>explicitly specify other ways, there are other ways that aren't > >>explicitly prohibited. In general with sip, things that aren't > >>explicitly prohibited are permitted. > >> > > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > > But without semantics, it is neither an offer nor an answer. > > > > > >>I just want to get this nailed down, so I know how to build a stack that > >>can both handle every valid case thrown at it, and that can initiate all > >>the needed functionality. > >> > >>I am thinking that maybe somebody (probably me) needs to write a best > >>practices document that pulls this all together, specifying all the ways > >>that offer/answer can be used. Following that, I think it will be > >>advisable to tighten up one or more of the RFCs in places where things > >>haven't been prohibited but should be. > >> > > > > [TS] The guideline document that you are proposing can be useful. > > Collecting all the possible collision cases, recommending UPDATE > > offer rather than PRACK offer if UPDATE is supported and no need > > to reduce the number of messages, enumerating Warning header code > > examples to be included when offer is rejected with 488, etc. > > > > Regards, > > Takuya > > > > > >>Paul > >> > >>_______________________________________________ > >>Sip-implementors mailing list > >>Sip-implementors@cs.columbia.edu > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > -------- > > Takuya Sawada > > KDDI Corporation (KDDI) > > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > > Tokyo 102-8460, Japan > > Tel: +81-3-6678-2997 > > Fax: +81-3-6678-0285 > > tu-sawada@kddi.com > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jan 28 04:23:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22041 for ; Wed, 28 Jan 2004 04:23:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alluw-0005lO-MY for sipping-archive@odin.ietf.org; Wed, 28 Jan 2004 04:23:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S9NQKS022150 for sipping-archive@odin.ietf.org; Wed, 28 Jan 2004 04:23:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alluu-0005lB-Lr for sipping-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 04:23:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22038 for ; Wed, 28 Jan 2004 04:23:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Allur-0004NR-00 for sipping-web-archive@ietf.org; Wed, 28 Jan 2004 04:23:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alltv-0004K2-00 for sipping-web-archive@ietf.org; Wed, 28 Jan 2004 04:22:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alltg-0004GO-00 for sipping-web-archive@ietf.org; Wed, 28 Jan 2004 04:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlltZ-0005XV-JY; Wed, 28 Jan 2004 04:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Allsx-0005Tt-Hp for sipping@optimus.ietf.org; Wed, 28 Jan 2004 04:21:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21998 for ; Wed, 28 Jan 2004 04:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Allsu-0004Fn-00 for sipping@ietf.org; Wed, 28 Jan 2004 04:21:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Allrz-0004CI-00 for sipping@ietf.org; Wed, 28 Jan 2004 04:20:25 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Allr4-00048I-00 for sipping@ietf.org; Wed, 28 Jan 2004 04:19:26 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0S9JQYG003832; Wed, 28 Jan 2004 10:19:26 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 10:19:29 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Takuya Sawada'" , tu-sawada@kddi.com Cc: sipping@ietf.org Subject: RE: [Sipping] RE: Need to clarify rules for offer/answer usage in sip Date: Wed, 28 Jan 2004 10:19:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Hi, >Drawbacks of PRACK are; >- If PRACK is rejected due to the offer in PRACK, it would >delay the reliable mechanism. [CHH] This has been discussed before, and my understanding is that a PRACK MUST NOT be rejected due to the offer. You MUST send a 200 OK response to PRACK (unless there is some other reason to reject it, of course), no matter if you accept the offer or not. And, that is the problem of using PRACK for sending offers: there is no way to reject them. And, that is one of the reasons why I am not a big fan of using PRACK for this purpose in the first place, but I guess that is out of the scope of this discussion :) >- If it wants to send offer in PRACK, it ahs to wait for the >reliable response. > >The advantage of PRACK over UPDATE is just saving one message cycle. > >But I am not sure I can say it "must" use UPDATE. [CHH] Again, my understanding is that you can send an offer/answer in PRACK once, and the reason for that was to save one message cycle in pre-condition (RFC3312) scenarios. Regards, Christer Holmberg Ericsson Finland > > Regards, > Takuya > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 26. tammikuuta 2004 18:43 > > > To: Takuya Sawada > > > Cc: Christer Holmberg (JO/LMF); sipping@ietf.org > > > Subject: Need to clarify rules for offer/answer usage in sip > > > > > > > > > Takuya, > > > > > > You make good points. I think you have convinced me of > how this all > > > needs to work. I believe we are also both in agreement that the > > > necessary behavior is currently underspecified in the RFCs. > > > > > > I think a useful next step would be to hear from the authors > > > of the RFCs > > > in question, and hopefully obtain their concurrence. Then we > > > can discuss > > > the best way to formalize this. I am moving this to the > > > sipping list and > > > changing the title in order to pick up those authors, > some of which > > > don't normally watch sip-implementors. > > > > > > Paul > > > > > > Takuya Sawada wrote: > > > > Hi, Paul, > > > > > > > > Let me summarize my view of "restrictions" defined in the > > > current SIP RFCs. > > > > * Probably I think I may share the same view with Christer > > > in most parts. > > > > > > > > Offer/Answer exchange described in RFC 3264 is independent from > > > > higher layer protocol. > > > > Higher layer protocol provides means to exchange offer/answer > > > > and this needs to provide means for resolving "glare" situation > > > > as described in the last paragraph in RFC 3264. > > > > > > > > [How to provide means to exchange offer/answer in SIP] > > > > > > > > > > > > RFC 3261 provides the following two ways to exchange > offer/answer; > > > > - INVITE/2xx > > > > - 2xx/ACK > > > > See the page 80 in RFC 3261. > > > > > > > > > > > > RFC 3262 provides the additional three ways to exchange > > > offer/answer; > > > > Note that here "1xx" is a reliable provisional response > to INVITE. > > > > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be > > > the first 1xx) > > > > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the > > > first reliable response. > > > > - PRACK/2xx(PRACK) ... Only after a completion of > > > INVITE/1xx or 1xx/PRACK. > > > > See chapter 5 in RFC 3262. > > > > > > > > > > > > RFC 3311 provides an additional way to exchange; > > > > - UPDATE/2xx(UPDATE) > > > > Only when after any offer/answer exchange defined in RFC > > > 3261 and RFC 3262 > > > > has completed and no offer/answer exchange in progress. > > > > See section 5.1, 5.2 in RFC 3311. > > > > > > > > Currently, as far as I understand, no other ways are not > > > defined in any RFCs. > > > > Assuming this is correct, let me clarify how to resolve > > > "glare" cases. > > > > * I can not imagine how to resolve "glare" if other > > > offer/answer exchanges > > > > are possible beyond my assumption here. > > > > > > > > [How to resolve "glare" condition] > > > > One reason why the usage of a SIP method to exchange > offer/answer > > > > needs to be carefully restricted in RFCs is that UA must > > > detect mis-ordered > > > > message delivery and must avoid confusion. > > > > In RFC 3264, "it MUST NOT generate a new offer if it has > > > > received an offer which it has not yet answered or rejected. > > > > it MUST NOT generate a new offer if it has generated a > > > > prior offer for which it has not yet received an answer or > > > a rejection." > > > > So now there seems to be two possible message crossing case > > > > to be considered assuming that the above rules are guaranteed. > > > > > > > > Case1 > > > > A B > > > > |offer1 | > > > > |--------------->| > > > > | answer1| > > > > |<-----\ /-------| > > > > | X offer2| > > > > |<-----/ \-------| > > > > > > > > Case2 > > > > A B > > > > |offer1 offer2| > > > > |------\ /-------| > > > > | X | > > > > |<-----/ \------>| > > > > > > > > Case1: > > > > Assuming that offer/answer exchange follows the > > > restrictions I described > > > > above, A can know an SDP in offer2 is not an answer to offer1. > > > > Then offer2 must be rejected with a 500 with Retry-After, when > > > > offer2 is UPDATE. And I assume that it can apply to reINVITE, > > > > which may not be stated clearly. > > > > I am not sure that when this happens when offer2 is in PRACK. > > > > But probably 500 with Retry-After will also apply, even it > > > results in > > > > delay for reliabile transfer mechanism for provisional response. > > > > In the case that offer2 is in the first reliable > > > provisional response > > > > or ACK, it seems to me that it never happens, if there is a > > > rule that > > > > INVITE, even w/o SDP, must not be sent if pending offer exists. > > > > I am not sure whether it is clearly stated. > > > > > > > > Case2: > > > > Assuming that offer/answer exchange follows the > > > restrictions I described > > > > above, A can know an SDP in offer2 is not an answer to offer1. > > > > Then offer2 must be rejected with a 491, if it is UPDATE or > > > (re)INVITE. > > > > In the case that offer2 is in PRACK, it may be accepted > with 200 or > > > > may be rejected with 491. 491 may be adequate for > > > offer/answer but it may > > > > delay the completion of a reliable response transfer > > > mechanism or, in > > > > worst case, may result in failure to complete SIP > > > transaction because > > > > there is no clear retry rule when PRACK is rejected with 491. > > > > When RFC 3262 was defined, there were no UPDATE, therefore > > > offer in PRACK > > > > never collides with other offers from the other side. I > > > guess this is why > > > > there is no rule in RFC 3262 when PRACK offer collides with > > > UPDATE offer. > > > > (It is safe to use UPDATE instead of PRACK when UPDATE > is supported) > > > > Anyway, because there is no PRACK against PRACK collision > > > in the current > > > > RFCs, the other side is always expected to send 491. > > > > There is no possibility that offer2 is in the first > > > reliable response or ACK. > > > > Because A must not send new offer when it send INVITE w/o offer. > > > > > > > > Is this a correct summary? > > > > > > > > More comments inline with [TS]. > > > > > > > > > > > >>Takuya, > > > >> > > > >>RFC 3312 introduces situations in which multiple > > > offer/answer exchanges > > > >>are required before a single INVITE transaction can > > > complete. Of course > > > >>multiple transactions are involved because PRACK and/or > > > UPDATE are used > > > >>to achieve part of the exchange, but the INVITE transaction > > > can't finish > > > >>until they are done. > > > >> > > > >>This is at least one case in which offers and answers are > > > spread across > > > >>transactions in complex ways. > > > >> > > > > > > > > [TS] In my reading so far, there is the only one case which > > > offer/answer is > > > > across transaction, that is offer in the first reliable > > > provisional response > > > > of INVITE and answer is in PRACK. There is no other case > > > that an offer is in > > > > a transaction and an answer is in another transaction. > > > > I agree with that any number of offer/answer exchanges can > > > occur during > > > > one INVITE transaction. > > > > > > > > > > > >>There are also cases independent of 3312 where there is a > > > need to send a > > > >>subsequent offer/answer before an invite transaction > completes. For > > > >>instance, this is one of the techniques for dealing with > > > port conflicts > > > >>introduced as a result of forking. > > > >> > > > > > > > > [TS] Yes. I did not disagree with that an offer in UPDATE > > > request can > > > > be used before the completion of INVITE transaction. > > > > > > > > > > > >>Once an invite transaction has completed, including one or more > > > >>offer/answer pairs, additional offer/answer cycles can > be initiated > > > >>using either reINVITE or UPDATE. > > > >> > > > >>In the case of reINVITE, I believe there is a requirement > > > that one or > > > >>more offer/answer cycles be completed before it can > > > succeed. And if it > > > >>fails, the changed tentatively imparted by all of those > > > offer/answer > > > >>cycles are to be rolled back. > > > >> > > > >>The case of UPDATE is a little less clear. If there is > no invite > > > >>transaction in progress, and an offer is sent in an > UPDATE, and the > > > >>update is rejected, it must be the case that the dialog > > > state remains as > > > >>it was before the update. If there is no invite in > progress and an > > > >>UPDATE is sent without an offer, there seems to be no > prohibition > > > >>against sending an offer in the update response. In > that case, the > > > >>answerer would have no way to refuse the offer and retain > > > the dialog as > > > >>it is. The only option the answerer would have is to send > > > another UPDATE > > > >>containing the answer. I doubt this is intended behavior, > > > but it isn't > > > >>prohibited. > > > >> > > > > > > > > [TS] This is the point I can not agree. I can not find any > > > description that > > > > UPDATE response can contain an offer in RFC 3311. IMO, this > > > means UPDATE response > > > > can not have any offer. SIP RFCs define restrictions to > > > utilize RFC 3264 model. > > > > UAs can not do any offer/answer exchange which is not > > > defined clearly in any RFCs. > > > > > > > > > > > >>More below. > > > >> > > > >>Paul > > > >> > > > >>Takuya Sawada wrote: > > > >> > > > >>>Hi, > > > >>> > > > >>>In my understanding, > > > >>> > > > >>>- Once previous offer/answer completes each side can issue > > > new offer. > > > >>>- INVITE request contains the offer, and the first > > > reliable 1xx response > > > >>> which contains answer, offer/answer for the INVITE > > > transaction completes. > > > >>>- UPDATE transaction and PRACK transaction can exchange > > > offer/answer. > > > >>>- Therefore, once the reliable 1xx response which contains > > > answer is received, > > > >>> caller can start offer/answer with PRACK or UPDATE or > > > any new method. > > > >>> And once the reliable 1xx response which contains > answer is sent, > > > >>> callee can start offer/answer with UPDATE. > > > >>> > > > >>> > > > >>> > > > >>>>P.S. For those with the patience, below I have tried to > > > enumerate all > > > >>>>the offer/answer cases thru the 2nd offer. It is > pretty painful. > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>>>2) invite with 100rel > > > >>>> a) offer in invite > > > >>>> Possible places for answer: > > > >>>> i) answer in first reliable 1xx > > > >>>> ii) answer in subsequent reliable 1xx > > > >>>> iii) answer in 2xx > > > >>>> b) offer not in invite > > > >>>> offer must be in first reliable 1xx > > > >>>> answer must be in PRACK to 1xx w/offer > > > >>>> > > > >>>>Multiple offer/answer cycle prior to completion of invite. > > > >>>>Can only happen in subcases of (2) above. > > > >>>>It requires use of UPDATE in some cases. > > > >>>> > > > >>>>3) original offerer sends 2nd offer > > > >>>> a) following 2.a.i or 2.a.i.i: > > > >>>> Possible places for 2nd offer: > > > >>>> i) offer2 in PRACK of answer1 > > > >>>> ii) offer2 in PRACK of some subsequent 1xx > > > >>>> iii) offer2 in UPDATE > > > >>>> b) following 2.a.iii: > > > >>>> No 2nd offer possible until after completion of invite. > > > >>>> c) following 2.b: > > > >>>> i) offer2 in 2xx to PRACK w/answer1 > > > >>>> ii) offer2 in UPDATE > > > >>>> > > > >>>>4) original answerer sends 2nd offer: > > > >>>> Not clear if this is intended to be legal at all prior to > > > >>>> completion of invite. It appears existing text permits > > > >>>> as follows: > > > >>>> a) following 2.a.i or 2.a.ii: > > > >>>> Possible places for 2nd offer: > > > >>>> i) offer2 in 2xx to prack of answer1. > > > >>>> ii) offer2 in subsequent reliable 1xx > > > >>>> following the one carrying answer1. > > > >>>> iii) offer2 in UPDATE following answer1. > > > >>>> (No reason to prefer this to other possibilities.) > > > >>>> b) following 2.a.iii: > > > >>>> No 2nd offer possible until after completion of invite. > > > >>>> c) following 2b: > > > >>>> i) if another reliable 1xx is received, > > > >>>> could send offer2 in the PRACK. > > > >>>> (but can't count on this happening.) > > > >>>> ii) offer2 in UPDATE after sending answer1. > > > >>> > > > >>> > > > >>>I do not think offer/answer exchange beyond the SIP transaction > > > >>>is possible. I am not sure it is prohibited somewhere > in RFC, but > > > >>>even if it is not prohibited explicitly, one should not assumed > > > >>>that is possible. > > > >> > > > >>Following the principle of being conservative in what > you send and > > > >>liberal in what you receive, I want to assume that I > might receive > > > >>anything that isn't prohibited, and do something > reasonable with it. > > > >> > > > > > > > > [TS] I love this principle. IMO, if I receive an SDP which > > > I do not expect > > > > to receive in RFC, one possible solution is that I will > > > accept SIP message > > > > and ignore the SDP. Content-Disposition header's > handling parameter > > > > should be checked, though. > > > > Anyway, here I do not know what is something reasonable to > > > do with it. > > > > > > > > > > > >>I would be willing to be conservative in initiating > this stuff if I > > > >>could figure out what that is. Given the current state of > > > >>underspecification I don't know that I will draw the same > > > conclusion > > > >>than anyone else will. > > > >> > > > > > > > > [TS] There seems to be some uderspecification in RFCs. But > > > I want to > > > > confirm the following; > > > > RFCs only state where and when an offer and an answer > can appear. > > > > If RFCs do not state "it can", then it MUST NOT contain > > > offer/answer. > > > > Because RFCs define "restrictions" where and when offer/answer > > > > exchange can occur. > > > > First I think we should reach a consensus with this point. > > > > > > > > > > > >> > One can achieve the same thing without such a > > > >> > > > >>>tweak. > > > >> > > > >>Not sure what you are referring to here, or whether it is > > > negated in > > > >>your subsequent posting. See above for a number of things > > > that must be > > > >>possible. > > > >> > > > >> > > > >>>Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST > NOT, be used. > > > >> > > > >>If we can codify a clear, and complete, set of rules for > > > where offers > > > >>and answers can appear, that provides full > functionality, and it > > > >>excludes these cases, then fine. > > > >> > > > >>In the case of 4.a.1, removing it causes no loss of > > > functionality, so I > > > >>am inclined to agree. It might ultimately result in > exchanging more > > > >>messages, but the number is probably insignificant. > > > >> > > > >>In the case of 3.c.1, removing it requires that both > sides support > > > >>UPDATE. So its removal may remove functionality in the case > > > where one > > > >>side or the other doesn't support UPDATE. This may or > may not be > > > >>significant. > > > >> > > > > > > > > [TS] As you said, UPDATE can solve the problem. > > > > You can use extensions when it wants the functionality that > > > the base > > > > specifications can not provide. This is what the extensions are. > > > > > > > > > > > >>>Anyway for INVITE transaction, as explained in my > previous mail, > > > >>>it is clear in RFC 3261 to me that one INVITE transaction can > > > >>>include only one offer/answer exchange. > > > >>> > > > >>>Then 4.a.ii is not permitted. > > > >> > > > >>I think I identified cases above where this is needed. > > > >> > > > > > > > > [TS] The reason I think it is not permitted is, as Christer > > > pointed our, > > > > that RFC 3261 does not permit and any other RFCs do not > override it. > > > > > > > > > > > >>Takuya Sawada wrote: > > > >> > Hi, > > > >> > > > > >> > > > > >> >>I do not think offer/answer exchange beyond the SIP > transaction > > > >> >>is possible. I am not sure it is prohibited > somewhere in RFC, but > > > >> >>even if it is not prohibited explicitly, one should > not assumed > > > >> >>that is possible. One can achieve the same thing > without such a > > > >> >>tweak. > > > >> > > > > >> > > > > >> > I am not exactly correct here. > > > >> > When an offer is in INVITE reliable provisonal response and > > > >> > an answer is in PRACK offer/answer exchange is beyond one > > > >> > transaction. > > > >> > What I want to say is that how offer/answer is used > in a certain > > > >> > method is explicitly scoped in each RFC which > defines the method. > > > >> > > > >>The trouble with these is that they were written in a > > > certain order. As > > > >>each was written, a broadening of thinking seems to have > > > occurred. This > > > >>is reflected in each, but not necessarily fully reflected > > > in the earlier > > > >>specs. > > > >> > > > > > > > > [TS] I may agree with this. At least this makes it > > > difficult to understand > > > > and share the same view among all. Actually, there seems to > > > be a little > > > > ambiguity with PRACK and UPDATE collision case as I pointed > > > > out in this mail, etc. > > > > > > > > > > > >> > How PRACK is used for offer/answer is defined in RFC 3262. > > > >> > There seems to be only two cases: > > > >> > - offer/answer is reliable 1xx(INVITE)/PRACK > > > >> > - offer/answer is PRACK/2xx(PRACK) > > > >> > only after INVITE's offer/answer exchange complete. > > > >> > > > >>I agree that this seems pretty well locked down as it > > > relates to 3261. > > > >>These lock downs of course do apply to the things that came > > > later. But > > > >>they seem at least awkward and arbitrary in some cases. > > > >> > > > >> > How UPDATE is used for offer/answer is defined in RFC 3311. > > > >> > - offer/answer is UPDATE/2xx(UPDATE) > > > >> > > > >>Here I disagree. I looked pretty closely at this, and I > > > don't see *any* > > > >>normative language for how offer/answer is used with > it. There is a > > > >>bunch of non-normative language which appears to simply restate > > > >>implications of 3261 and 3264 in the presence of update. > > > >> > > > > > > > > [TS] Again, this is the point I can not agree. I agree with > > > that there is > > > > no normative language to prohibit offer in the response > of UPDATE > > > > like "2xx response to UPDATE MUST NOT contain offer". > > > > Actually, response can have an SDP even if UPDATE does not have > > > > an offer SDP. But an SDP can be neither an offer nor an answer > > > > unless clear semantics are defined in any RFCs. I can not find > > > > any usage or semantics to use offer/answer exchange beyond > > > > one UPDATE transaction. > > > > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > > > > offer is neither an offer nor an answer like SDP in INFO is > > > > neither an offer nor an answer. > > > > > > > > > > > >> > How INVITE is used for offer/answer is defined in RFC 3261. > > > >> > - offer/answer is INVITE/non-failure reliable response > > > >> > - offer/answer is the first non-failure first > > > >>response/acknowlegement for the response > > > >> > , which is 2xx(INVITE)/ACK in RFC 3261 and > > > 1xx(INVITE)/PRACK in > > > >>RFC 3262. > > > >> > * Note that the second or later SDP in INVITE > > > non-failure response > > > >> > is not an offer. It is nothing. > > > >> > > > > >> > There is no other way than explicitly defined in any > RFC, IMO. > > > >> > > > >>I believe you are right that nothing more is explicitly defined. > > > >>But 3264 is pretty general and broad. It is not > prescriptive in how > > > >>offers and answers are transmitted. > > > > > > > > > > > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > > > > to exchange offer/answer in higher layer protocol. > > > > > > > > > > > >>And while the other RFCs may not > > > >>explicitly specify other ways, there are other ways that aren't > > > >>explicitly prohibited. In general with sip, things that aren't > > > >>explicitly prohibited are permitted. > > > >> > > > > > > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > > > > But without semantics, it is neither an offer nor an answer. > > > > > > > > > > > >>I just want to get this nailed down, so I know how to build > > > a stack that > > > >>can both handle every valid case thrown at it, and that can > > > initiate all > > > >>the needed functionality. > > > >> > > > >>I am thinking that maybe somebody (probably me) needs to > > > write a best > > > >>practices document that pulls this all together, specifying > > > all the ways > > > >>that offer/answer can be used. Following that, I think > it will be > > > >>advisable to tighten up one or more of the RFCs in places > > > where things > > > >>haven't been prohibited but should be. > > > >> > > > > > > > > [TS] The guideline document that you are proposing can > be useful. > > > > Collecting all the possible collision cases, > recommending UPDATE > > > > offer rather than PRACK offer if UPDATE is supported > and no need > > > > to reduce the number of messages, enumerating Warning > header code > > > > examples to be included when offer is rejected with 488, etc. > > > > > > > > Regards, > > > > Takuya > > > > > > > > > > > >>Paul > > > >> > > > >>_______________________________________________ > > > >>Sip-implementors mailing list > > > >>Sip-implementors@cs.columbia.edu > > > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > > > > -------- > > > > Takuya Sawada > > > > KDDI Corporation (KDDI) > > > > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > > > > Tokyo 102-8460, Japan > > > > Tel: +81-3-6678-2997 > > > > Fax: +81-3-6678-0285 > > > > tu-sawada@kddi.com > > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0285 > tu-sawada@kddi.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP