From rjsparks@nostrum.com Tue Aug 2 11:50:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76221F85E3; Tue, 2 Aug 2011 11:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yswXV2JGN1mn; Tue, 2 Aug 2011 11:50:19 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54321F85CA; Tue, 2 Aug 2011 11:50:18 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p72Imn7v097638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 13:48:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Robert Sparks In-Reply-To: Date: Tue, 2 Aug 2011 13:48:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D2BA7C8-DD7F-444B-8E4A-16D6B3C43212@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 02 Aug 2011 11:52:06 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, "sip@ietf.org List" , schulzrinne@cs.columbia.edu, "SIPCORE \(Session Initiation Protocol Core\) WG" , Keith Drage , alan.johnston@wcom.com, mjh@icir.org, Jon Peterson Subject: [sipcore] Table2/3 maintenance (was Re: [Sip] [Technical Errata Reported] RFC3261 (2910)) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "SIPCORE \(Session Initiation Protocol Core\) WG" List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:50:19 -0000 (removing the RFC Editor, and setting reply-to to the sipcore list) Some thing to think about when considering errata on the existing Tables = 2 and 3 in RFC3261: We have had many conversations about the utility of maintaining tables 2 = and 3. I think the most recent was around the Anaheim meeting - see the notes = at: We had strong support for not continuing to add information to Tables 2 = and 3, but not to remove the existing tables from the document. Maintaining the = existing table is probably a separate question, but keep the arguments noted in the = minutes above in mind when choosing to do so. RjS On Aug 2, 2011, at 1:28 PM, I=F1aki Baz Castillo wrote: > 2011/8/2 Bob Penfield : >> The entry in the table should be "c" (not "m"). A Contact is not = required in a 100 Trying response. The Contact is only required for a = 1xx that creates a dialog. >=20 > Right. >=20 > --=20 > I=F1aki Baz Castillo > From rjsparks@nostrum.com Tue Aug 2 11:58:47 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD3B21F86DD; Tue, 2 Aug 2011 11:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42ctrOzzdRJ4; Tue, 2 Aug 2011 11:58:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 00710228006; Tue, 2 Aug 2011 11:58:45 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p72IvS8i098559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 13:57:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Robert Sparks In-Reply-To: Date: Tue, 2 Aug 2011 13:57:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> To: Bob Penfield X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 02 Aug 2011 12:00:44 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, "sip@ietf.org List" , schulzrinne@cs.columbia.edu, "SIPCORE \(Session Initiation Protocol Core\) WG" , Keith Drage , alan.johnston@wcom.com, mjh@icir.org, Jon Peterson , RFC Errata System Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "SIPCORE \(Session Initiation Protocol Core\) WG" List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:58:47 -0000 (Attempting to move this to the sipcore mailing list) Further, they're only going to make sense for 1xx that is sent using = 100rel. So the errata as submitted is incorrect. We could just reject it and = move on (my preference given the way we're handling Table 2), or try to edit it to be more correct and put it in hold-for-document = update (see = ). RjS On Aug 2, 2011, at 10:58 AM, Bob Penfield wrote: > The entry in the table should be "c" (not "m"). A Contact is not = required in a 100 Trying response. The Contact is only required for a = 1xx that creates a dialog. >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = RFC Errata System > Sent: Tuesday, August 02, 2011 10:54 AM > To: jdrosen@dynamicsoft.com; schulzrinne@cs.columbia.edu; = Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; = jon.peterson@neustar.com; rsparks@dynamicsoft.com; mjh@icir.org; = schooler@research.att.com; gonzalo.camarillo@ericsson.com; = rjsparks@nostrum.com; dean.willis@softarmor.com; = drage@alcatel-lucent.com > Cc: sip@ietf.org; rfc-editor@rfc-editor.org > Subject: [Sip] [Technical Errata Reported] RFC3261 (2910) >=20 >=20 > The following errata report has been submitted for RFC3261, > "SIP: Session Initiation Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3261&eid=3D2910 >=20 > -------------------------------------- > Type: Technical > Reported by: I=F1aki Baz Castillo >=20 > Section: Table 2 >=20 > Original Text > ------------- > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Contact 1xx - - - o - - >=20 > Corrected Text > -------------- > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Contact 1xx - - - m - - >=20 > Notes > ----- > RFC 3261 says: >=20 > Section 12.1: "Dialogs are created through the generation of = non-failure responses to requests with specific methods. Within this = specification, only 2xx and 101-199 responses with a To tag, where the = request was INVITE, will establish a dialog." >=20 > Section 12.1.1: "When a UAS responds to a request with a response that = establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all = Record-Route header field values from the request into the response = [...]. The UAS MUST add a Contact header field to the response." >=20 > So it's clear that a 1xx response to an INVITE creates a dialog and = then it MUST contain a Contact header and mirrored Record-Route headers. >=20 > However Table 2 (page 162) says: >=20 > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Contact 1xx - - - o - - > Record-Route 2xx,18x mr - o o o o - >=20 > Obviously Record-Route is optional since in the absence of a proxy = doing record-routing, such header will not be present. However Contact = header should appear as mandatory (m) for 1xx responses for INVITE = rather than optional (o). >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3261 (draft-ietf-sip-rfc2543bis-09) > -------------------------------------- > Title : SIP: Session Initiation Protocol > Publication Date : June 2002 > Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. = Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From ibc@aliax.net Tue Aug 2 15:24:22 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B611E80D4; Tue, 2 Aug 2011 15:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QXwVUjx+Unh; Tue, 2 Aug 2011 15:24:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6367111E80CE; Tue, 2 Aug 2011 15:24:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so212784qwc.31 for ; Tue, 02 Aug 2011 15:24:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.80 with SMTP id jp16mr3049584qcb.25.1312323867804; Tue, 02 Aug 2011 15:24:27 -0700 (PDT) Received: by 10.229.224.212 with HTTP; Tue, 2 Aug 2011 15:24:27 -0700 (PDT) In-Reply-To: <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> Date: Wed, 3 Aug 2011 00:24:27 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 02 Aug 2011 15:25:57 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, "sip@ietf.org List" , schulzrinne@cs.columbia.edu, Keith Drage , mjh@icir.org, alan.johnston@wcom.com, Jon Peterson , RFC Errata System Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:24:22 -0000 2011/8/2 Robert Sparks : > Further, they're only going to make sense for 1xx that is sent using 100r= el. This has been discussed in sip-implementors, and that assertion seems incorrect. As I've reported in the errata: Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog." Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response." So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers, *regardless* the usage of 100rel. Am I wrong? if so, why? Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 2 15:56:09 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6BB11E80C3; Tue, 2 Aug 2011 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV7jw0lUCrWu; Tue, 2 Aug 2011 15:56:08 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B645611E8095; Tue, 2 Aug 2011 15:56:08 -0700 (PDT) Received: by qwc23 with SMTP id 23so224681qwc.31 for ; Tue, 02 Aug 2011 15:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.215.68 with SMTP id hd4mr4649534qcb.177.1312325778403; Tue, 02 Aug 2011 15:56:18 -0700 (PDT) Received: by 10.229.224.212 with HTTP; Tue, 2 Aug 2011 15:56:18 -0700 (PDT) In-Reply-To: <6D2BA7C8-DD7F-444B-8E4A-16D6B3C43212@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> <6D2BA7C8-DD7F-444B-8E4A-16D6B3C43212@nostrum.com> Date: Wed, 3 Aug 2011 00:56:18 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 03 Aug 2011 06:35:57 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, "sip@ietf.org List" , schulzrinne@cs.columbia.edu, Keith Drage , alan.johnston@wcom.com, mjh@icir.org, Jon Peterson Subject: Re: [sipcore] Table2/3 maintenance (was Re: [Sip] [Technical Errata Reported] RFC3261 (2910)) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:56:09 -0000 2011/8/2 Robert Sparks : > (removing the RFC Editor, and setting reply-to to the sipcore list) > > Some thing to think about when considering errata on the existing Tables = 2 and 3 in RFC3261: > > We have had many conversations about the utility of maintaining tables 2 = and 3. > I think the most recent was around the Anaheim meeting - see the notes at= : > > > We had strong support for not continuing to add information to Tables 2 a= nd 3, but not > to remove the existing tables from the document. =C2=A0Maintaining the ex= isting table is > probably a separate question, but keep the arguments noted in the minutes= above in > mind when choosing to do so. I also think that table 2 (at least table 2) is not useful, and just adds complexity. It's much better to explain/describe/mandate the presence of headers in the text (IMHO). Regards. --=20 I=C3=B1aki Baz Castillo From rjsparks@nostrum.com Wed Aug 3 08:46:03 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B78121F8BD7; Wed, 3 Aug 2011 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxy-HRPihiXt; Wed, 3 Aug 2011 08:46:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 354C021F8BBD; Wed, 3 Aug 2011 08:46:01 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p73Fk9Il028341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2011 10:46:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Robert Sparks In-Reply-To: Date: Wed, 3 Aug 2011 10:46:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sip@ietf.org List" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:46:03 -0000 (removing the rfc-editor and trimming the distribution to the lists) On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote: > 2011/8/2 Robert Sparks : >> Further, they're only going to make sense for 1xx that is sent using = 100rel. >=20 > This has been discussed in sip-implementors, and that assertion seems > incorrect. As I've reported in the errata: >=20 >=20 > Section 12.1: "Dialogs are created through the generation of > non-failure responses to requests with specific methods. Within this > specification, only 2xx and 101-199 responses with a To tag, where the > request was INVITE, will establish a dialog." >=20 > Section 12.1.1: "When a UAS responds to a request with a response that > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all > Record-Route header field values from the request into the response > [...]. The UAS MUST add a Contact header field to the response." >=20 > So it's clear that a 1xx response to an INVITE creates a dialog and > then it MUST contain a Contact header and mirrored Record-Route > headers, *regardless* the usage of 100rel. >=20 > Am I wrong? if so, why? Not wrong, just incomplete. This will create an (early) dialog at the = UAS. It may or may not create a dialog at the UAC without 100rel since the message may never get to the UAC. Where I said "make sense" above, it might have been better if I had said "be useful". >=20 > Regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Aug 3 10:44:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C390221F8610 for ; Wed, 3 Aug 2011 10:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGrslttNRL+m for ; Wed, 3 Aug 2011 10:44:34 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 111A521F855D for ; Wed, 3 Aug 2011 10:44:33 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id FtWj1h0041swQuc56tknNi; Wed, 03 Aug 2011 17:44:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id FtkX1h0380tdiYw3btkgsC; Wed, 03 Aug 2011 17:44:45 +0000 Message-ID: <4E3988FD.70606@alum.mit.edu> Date: Wed, 03 Aug 2011 13:44:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> In-Reply-To: <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:44:34 -0000 On 8/3/11 11:46 AM, Robert Sparks wrote: > (removing the rfc-editor and trimming the distribution to the lists) > > On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote: > >> 2011/8/2 Robert Sparks: >>> Further, they're only going to make sense for 1xx that is sent using 100rel. >> >> This has been discussed in sip-implementors, and that assertion seems >> incorrect. As I've reported in the errata: >> >> >> Section 12.1: "Dialogs are created through the generation of >> non-failure responses to requests with specific methods. Within this >> specification, only 2xx and 101-199 responses with a To tag, where the >> request was INVITE, will establish a dialog." >> >> Section 12.1.1: "When a UAS responds to a request with a response that >> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all >> Record-Route header field values from the request into the response >> [...]. The UAS MUST add a Contact header field to the response." >> >> So it's clear that a 1xx response to an INVITE creates a dialog and >> then it MUST contain a Contact header and mirrored Record-Route >> headers, *regardless* the usage of 100rel. >> >> Am I wrong? if so, why? > > Not wrong, just incomplete. This will create an (early) dialog at the UAS. > It may or may not create a dialog at the UAC without 100rel since the > message may never get to the UAC. Where I said "make sense" above, > it might have been better if I had said "be useful". I don't get your point Robert. Of course its true that this will only create an early dialog at the UAC if the UAC actually receives the (unreliable) response. If it doesn't receive it, it won't know of the dialog, and so won't try to use BYE to terminate the dialog. But if it does receive it, and does know of the dialog, it can then use BYE to terminate it. And in that case the UAS will concur that there is a dialog and so be able to properly process the BYE. Thanks, Paul >> Regards. >> >> >> -- >> Iñaki Baz Castillo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Aug 3 15:05:41 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBCE11E80B3 for ; Wed, 3 Aug 2011 15:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXX-Op3hIiQx for ; Wed, 3 Aug 2011 15:05:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AB97711E8094 for ; Wed, 3 Aug 2011 15:05:40 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-a6-4e39c63f89a9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1C.56.09774.F36C93E4; Thu, 4 Aug 2011 00:05:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 4 Aug 2011 00:05:51 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Thu, 4 Aug 2011 00:05:45 +0200 Thread-Topic: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) Thread-Index: AcxSBQurpyiL3JFdSSyrWCJFTFVaOAAIw+MQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B83@ESESSCMS0356.eemea.ericsson.se> References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> <4E3988FD.70606@alum.mit.edu> In-Reply-To: <4E3988FD.70606@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:05:41 -0000 Hi, I agree with Robert's previous comment regarding the decision we previously= made regarding maintaining the tables, but maybe something has to be done. Because, especially regarding this specific case (Contact in responses), I = have been involved in a number of discussions where some people argue that = Contact must always be included, "because the RFC says so" (there seems to = be products that will trigger an error if not always included), while other= say it only needs to be included "when it makes sense". Nothing an SBC shouldn't be able to fix, though ;) I also agree with Paul. And, the UAC can not only use the early dialog for = BYE - it can also use it for other mid-dialog requests (it can't send a new= SDP offer, though, as it hasn't received a "real" SDP answer), and once th= e UAS gets that mid-dialog request it knows that the UAC received the unrel= iable response, so now IT can start sending mid-dialog requests.=20 Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 3. elokuuta 2011 20:44 > To: sipcore@ietf.org > Subject: Re: [sipcore] [Sip] [Technical Errata Reported]=20 > RFC3261 (2910) >=20 > On 8/3/11 11:46 AM, Robert Sparks wrote: > > (removing the rfc-editor and trimming the distribution to the lists) > > > > On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote: > > > >> 2011/8/2 Robert Sparks: > >>> Further, they're only going to make sense for 1xx that is=20 > sent using 100rel. > >> > >> This has been discussed in sip-implementors, and that=20 > assertion seems=20 > >> incorrect. As I've reported in the errata: > >> > >> > >> Section 12.1: "Dialogs are created through the generation of=20 > >> non-failure responses to requests with specific methods.=20 > Within this=20 > >> specification, only 2xx and 101-199 responses with a To tag, where=20 > >> the request was INVITE, will establish a dialog." > >> > >> Section 12.1.1: "When a UAS responds to a request with a response=20 > >> that establishes a dialog (such as a 2xx to INVITE), the UAS MUST=20 > >> copy all Record-Route header field values from the request=20 > into the=20 > >> response [...]. The UAS MUST add a Contact header field to=20 > the response." > >> > >> So it's clear that a 1xx response to an INVITE creates a=20 > dialog and=20 > >> then it MUST contain a Contact header and mirrored Record-Route=20 > >> headers, *regardless* the usage of 100rel. > >> > >> Am I wrong? if so, why? > > > > Not wrong, just incomplete. This will create an (early)=20 > dialog at the UAS. > > It may or may not create a dialog at the UAC without 100rel=20 > since the=20 > > message may never get to the UAC. Where I said "make sense"=20 > above, it=20 > > might have been better if I had said "be useful". >=20 > I don't get your point Robert. >=20 > Of course its true that this will only create an early dialog=20 > at the UAC if the UAC actually receives the (unreliable)=20 > response. If it doesn't receive it, it won't know of the=20 > dialog, and so won't try to use BYE to terminate the dialog.=20 > But if it does receive it, and does know of the dialog, it=20 > can then use BYE to terminate it. And in that case the UAS=20 > will concur that there is a dialog and so be able to properly=20 > process the BYE. >=20 > Thanks, > Paul >=20 > >> Regards. > >> > >> > >> -- > >> I=F1aki Baz Castillo > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From romel.khan@idt.net Thu Aug 4 12:10:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95E21F880C; Thu, 4 Aug 2011 12:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eupV45oMZqKt; Thu, 4 Aug 2011 12:10:13 -0700 (PDT) Received: from eu1sys200aog109.obsmtp.com (eu1sys200aog109.obsmtp.com [207.126.144.127]) by ietfa.amsl.com (Postfix) with SMTP id 61F7221F87D9; Thu, 4 Aug 2011 12:09:30 -0700 (PDT) Received: from mail-gy0-f175.google.com ([209.85.160.175]) (using TLSv1) by eu1sys200aob109.postini.com ([207.126.147.11]) with SMTP ID DSNKTjrub9Rd0lkABHuyjPatu/+sGSWsf1Nl@postini.com; Thu, 04 Aug 2011 19:09:47 UTC Received: by gyg4 with SMTP id 4so1011092gyg.6 for ; Thu, 04 Aug 2011 12:09:34 -0700 (PDT) Received: by 10.42.151.131 with SMTP id e3mr1010054icw.507.1312484974233; Thu, 04 Aug 2011 12:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.44.136 with HTTP; Thu, 4 Aug 2011 12:09:14 -0700 (PDT) In-Reply-To: <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> From: Romel Khan Date: Thu, 4 Aug 2011 15:09:14 -0400 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=90e6ba6135a8a9886e04a9b2b804 X-Mailman-Approved-At: Thu, 04 Aug 2011 12:31:09 -0700 Cc: "sip@ietf.org List" , =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:10:15 -0000 --90e6ba6135a8a9886e04a9b2b804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So it is useful if one of UAS or UAC requires it, but it does not have to b= e mandatory. Some comments: -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems logical to me that it needs to be made clear in this RFC3261 that early dialog must mean Contact and Record-Route (if Record-Route was received in INVITE) headers is mandatory in 1xx without reference to 100rel. -- A UAS could always send 1xx with headers that are required for early dialog but it doesn't have to enforce 100rel (eg because the origination or UAS side itself may not support reliable provisional response handling, or reliable provisioning not really required for its operation). UAS could sen= d "support:100rel" if it supports it, or it would not send it if it doesn't support this. In my opinion, if UAC hasn't sent 100rel required, it should be up to the UAS to decide whether to enforce 100rel (with "required:100rel") if its application really requires SIP requests before call answer. If the origination side (UAC) side has a need to send early requests, like UPDATE, then the UAC should require 100rel from the termination side (UAS) by sending this in INVITE. In a VoIP service provide= r world, these kind of capabilities are configured during interconnect turn up. -- I notice that some vendors gateway implementations, even if gateway is the termination side, require 100rel for the gateway to receive pre-answer requests such as UPDATE. This really didn't have to be this way. I have always seen these gateways, when it is the termination side, respond back SIP 183 with the headers that create early dialog. So if the origination side received the SIP 183 response, then there is no reason for the origination side to now not be able to send UPDATE request. Also, no reason for the termination gateways to not accept the SIP UPDATE without requiring PRACK. Thanks. On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks wrote= : > (removing the rfc-editor and trimming the distribution to the lists) > > On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote: > > > 2011/8/2 Robert Sparks : > >> Further, they're only going to make sense for 1xx that is sent using > 100rel. > > > > This has been discussed in sip-implementors, and that assertion seems > > incorrect. As I've reported in the errata: > > > > > > Section 12.1: "Dialogs are created through the generation of > > non-failure responses to requests with specific methods. Within this > > specification, only 2xx and 101-199 responses with a To tag, where the > > request was INVITE, will establish a dialog." > > > > Section 12.1.1: "When a UAS responds to a request with a response that > > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all > > Record-Route header field values from the request into the response > > [...]. The UAS MUST add a Contact header field to the response." > > > > So it's clear that a 1xx response to an INVITE creates a dialog and > > then it MUST contain a Contact header and mirrored Record-Route > > headers, *regardless* the usage of 100rel. > > > > Am I wrong? if so, why? > > Not wrong, just incomplete. This will create an (early) dialog at the UAS= . > It may or may not create a dialog at the UAC without 100rel since the > message may never get to the UAC. Where I said "make sense" above, > it might have been better if I had said "be useful". > > > > > Regards. > > > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is essentially closed and only used for finishing old business. > Use sip-implementors@cs.columbia.edu for questions on how to develop a SI= P > implementation. > Use dispatch@ietf.org for new developments on the application of sip. > Use sipcore@ietf.org for issues related to maintenance of the core SIP > specifications. > --90e6ba6135a8a9886e04a9b2b804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So it is useful if one of UAS or UAC requires it, but it does not have to b= e mandatory. Some comments:
-- RFC3261 mentions early dialog without me= ntioning RFC3262. Then it seems logical to me that it needs to be made clea= r in this RFC3261 that early dialog must mean Contact and Record-Route (if= =A0Record-Route was received in INVITE) headers is mandatory in 1xx without= reference to 100rel.

-- A UAS could always send 1xx with headers that a= re required for early dialog but it doesn't have to enforce 100rel (eg = because the origination or UAS side itself may not support reliable provisi= onal response handling, or reliable provisioning not really required for it= s operation).=A0UAS could send "support:100rel" if it supports it= ,=A0or it would not send it if it doesn't support this.=A0In my opinion= ,=A0if UAC hasn't sent 100rel required,=A0it should be up to the UAS to= decide whether to enforce 100rel (with=A0"required:100rel")=A0if= its application really requires SIP requests before call answer. If the or= igination side (UAC) side has a need to send early requests, like UPDATE, t= hen the UAC should require 100rel from the termination side (UAS) by sendin= g this in INVITE.=A0In a VoIP service provider world,=A0these kind of capab= ilities are configured during interconnect turn up. =A0

-- I notice that some vendors gateway implementations, = even if gateway is the termination side, require 100rel for the gateway to = receive pre-answer requests such as UPDATE. This really didn't have to = be this way. I have always seen these gateways, when it is the termination = side, respond back SIP 183 with the headers that create early dialog. So if= the origination side received the SIP 183 response, then there is no reaso= n for the origination side to now not be able to send UPDATE request. Also,= =A0no reason=A0for the termination gateways to not accept the SIP UPDATE wi= thout requiring PRACK. =A0=A0

Thanks.

O= n Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <rjsparks@nostrum.com> wrote:=
(removing the rfc-editor and trimming the d= istribution to the lists)

On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote:

> 2011/8/2 Robert Sparks <rjs= parks@nostrum.com>:
>> Further, they're only going to make sense for 1xx that is sent= using 100rel.
>
> This has been discussed in sip-implementors, and that assertion seems<= br> > incorrect. As I've reported in the errata:
>
>
> Section 12.1: "Dialogs are created through the generation of
> non-failure responses to requests with specific methods. Within this > specification, only 2xx and 101-199 responses with a To tag, where the=
> request was INVITE, will establish a dialog."
>
> Section 12.1.1: "When a UAS responds to a request with a response= that
> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all<= br> > Record-Route header field values from the request into the response > [...]. The UAS MUST add a Contact header field to the response."<= br> >
> So it's clear that a 1xx response to an INVITE creates a dialog an= d
> then it MUST contain a Contact header and mirrored Record-Route
> headers, *regardless* the usage of 100rel.
>
> Am I wrong? if so, why?

Not wrong, just incomplete. This will create an (early) dialog at the= UAS.
It may or may not create a dialog at the UAC without 100rel since the
message may never get to the UAC. Where I said "make sense" above= ,
it might have been better if I had said "be useful".

>
> Regards.
>
>
> --
> I=F1aki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business. Use sip-implementors@cs= .columbia.edu for questions on how to develop a SIP implementation.
Use dispatch@ietf.org for new deve= lopments on the application of sip.
Use sipcore@ietf.org for issues rel= ated to maintenance of the core SIP specifications.

--90e6ba6135a8a9886e04a9b2b804-- From samirs.lists@gmail.com Thu Aug 4 21:15:29 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80B11E80A7; Thu, 4 Aug 2011 21:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPlTzsTrMt9B; Thu, 4 Aug 2011 21:15:28 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id B28A421F8557; Thu, 4 Aug 2011 21:15:28 -0700 (PDT) Received: by pzk33 with SMTP id 33so7509870pzk.18 for ; Thu, 04 Aug 2011 21:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bqDPNesYp8IJ1SF2K+iHxV/OUvUtKkpIA3MKeh9p8IE=; b=ITJf4z9uue90LQjw9BdCRd5PObRQyrm7bRfKy5EEPKBuSJ+zsmQSq1is0hswNuBFWS OkCehutdeboSXTeruqbhpHyd2xw0KVeku7FcbAa4xdqgODTy6TzVtnhUUMfl0ml48vI8 6sfo5F7UpXZNdvsc4X1IEYlnILdWYUrHniFjY= MIME-Version: 1.0 Received: by 10.142.48.14 with SMTP id v14mr1541153wfv.103.1312517743833; Thu, 04 Aug 2011 21:15:43 -0700 (PDT) Received: by 10.68.43.7 with HTTP; Thu, 4 Aug 2011 21:15:43 -0700 (PDT) In-Reply-To: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> Date: Thu, 4 Aug 2011 21:15:43 -0700 Message-ID: From: Samir Srivastava To: Romel Khan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org List" , =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 04:15:29 -0000 Hi, IMHO presentation of information in tabulated form helps a lot to starters. Like ABNF it helps parser developers (expert of syntax & semantic analysis) to develop it without referring each line of SIP rfc's. 3262 or 100rel should have updated table Ideally each subsequent RFC should conisder table updation. Tabulation of information will be done by vendors internally anyway. So do it in community. SIP needed hitchakers guide. Simplicity for starters please. Regards Samir On 8/4/11, Romel Khan wrote: > So it is useful if one of UAS or UAC requires it, but it does not have to= be > mandatory. Some comments: > -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seem= s > logical to me that it needs to be made clear in this RFC3261 that early > dialog must mean Contact and Record-Route (if Record-Route was received i= n > INVITE) headers is mandatory in 1xx without reference to 100rel. > > -- A UAS could always send 1xx with headers that are required for early > dialog but it doesn't have to enforce 100rel (eg because the origination = or > UAS side itself may not support reliable provisional response handling, o= r > reliable provisioning not really required for its operation). UAS could s= end > "support:100rel" if it supports it, or it would not send it if it doesn't > support this. In my opinion, if UAC hasn't sent 100rel required, it shoul= d > be up to the UAS to decide whether to enforce 100rel > (with "required:100rel") if its application really requires SIP requests > before call answer. If the origination side (UAC) side has a need to send > early requests, like UPDATE, then the UAC should require 100rel from the > termination side (UAS) by sending this in INVITE. In a VoIP service provi= der > world, these kind of capabilities are configured during interconnect turn > up. > > -- I notice that some vendors gateway implementations, even if gateway is > the termination side, require 100rel for the gateway to receive pre-answe= r > requests such as UPDATE. This really didn't have to be this way. I have > always seen these gateways, when it is the termination side, respond back > SIP 183 with the headers that create early dialog. So if the origination > side received the SIP 183 response, then there is no reason for the > origination side to now not be able to send UPDATE request. Also, no > reason for the termination gateways to not accept the SIP UPDATE without > requiring PRACK. > > Thanks. > > On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks wro= te: > >> (removing the rfc-editor and trimming the distribution to the lists) >> >> On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote: >> >> > 2011/8/2 Robert Sparks : >> >> Further, they're only going to make sense for 1xx that is sent using >> 100rel. >> > >> > This has been discussed in sip-implementors, and that assertion seems >> > incorrect. As I've reported in the errata: >> > >> > >> > Section 12.1: "Dialogs are created through the generation of >> > non-failure responses to requests with specific methods. Within this >> > specification, only 2xx and 101-199 responses with a To tag, where the >> > request was INVITE, will establish a dialog." >> > >> > Section 12.1.1: "When a UAS responds to a request with a response that >> > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all >> > Record-Route header field values from the request into the response >> > [...]. The UAS MUST add a Contact header field to the response." >> > >> > So it's clear that a 1xx response to an INVITE creates a dialog and >> > then it MUST contain a Contact header and mirrored Record-Route >> > headers, *regardless* the usage of 100rel. >> > >> > Am I wrong? if so, why? >> >> Not wrong, just incomplete. This will create an (early) dialog at the UA= S. >> It may or may not create a dialog at the UAC without 100rel since the >> message may never get to the UAC. Where I said "make sense" above, >> it might have been better if I had said "be useful". >> >> > >> > Regards. >> > >> > >> > -- >> > I=F1aki Baz Castillo >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is essentially closed and only used for finishing old business= . >> Use sip-implementors@cs.columbia.edu for questions on how to develop a S= IP >> implementation. >> Use dispatch@ietf.org for new developments on the application of sip. >> Use sipcore@ietf.org for issues related to maintenance of the core SIP >> specifications. >> > From ibc@aliax.net Sat Aug 6 05:16:32 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8C21F87BC; Sat, 6 Aug 2011 05:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juu1UiD2YVLu; Sat, 6 Aug 2011 05:16:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A021F8772; Sat, 6 Aug 2011 05:16:31 -0700 (PDT) Received: by qwc23 with SMTP id 23so243289qwc.31 for ; Sat, 06 Aug 2011 05:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.41 with SMTP id t41mr2614254qci.63.1312633011313; Sat, 06 Aug 2011 05:16:51 -0700 (PDT) Received: by 10.229.224.212 with HTTP; Sat, 6 Aug 2011 05:16:51 -0700 (PDT) Received: by 10.229.224.212 with HTTP; Sat, 6 Aug 2011 05:16:51 -0700 (PDT) In-Reply-To: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> Date: Sat, 6 Aug 2011 14:16:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Romel Khan Content-Type: multipart/alternative; boundary=0016e651395e5c1e0e04a9d53095 Cc: "sip@ietf.org List" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 12:16:32 -0000 --0016e651395e5c1e0e04a9d53095 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 04/08/2011 21:09, "Romel Khan" escribi=C3=B3: > > So it is useful if one of UAS or UAC requires it, but it does not have to be mandatory. Some comments: > -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seem= s logical to me that it needs to be made clear in this RFC3261 that early dialog must mean Contact and Record-Route (if Record-Route was received in INVITE) headers is mandatory in 1xx without reference to 100rel. > > -- A UAS could always send 1xx with headers that are required for early dialog but it doesn't have to enforce 100rel (eg because the origination or UAS side itself may not support reliable provisional response handling, or reliable provisioning not really required for its operation). UAS could sen= d "support:100rel" if it supports it, or it would not send it if it doesn't support this. In my opinion, if UAC hasn't sent 100rel required, it should be up to the UAS to decide whether to enforce 100rel (with "required:100rel") if its application really requires SIP requests before call answer. If the origination side (UAC) side has a need to send early requests, like UPDATE, then the UAC should require 100rel from the termination side (UAS) by sending this yin INVITE. In a VoIP service provider world, these kind of capabilities are configured during interconnect turn up. > > -- I notice that some vendors gateway implementations, even if gateway is the termination side, require 100rel for the gateway to receive pre-answer requests such as UPDATE. This really didn't have to be this way. I have always seen these gateways, when it is the termination side, respond back SIP 183 with the headers that create early dialog. So if the origination side received the SIP 183 response, then there is no reason for the origination side to now not be able to send UPDATE request. Also, no reason for the termination gateways to not accept the SIP UPDATE without requiring PRACK. I entirely agree with it. And I also think that the fact that a 1xx respons= e without 100rel is not reliable does not mean that it does not create a dialog so Contact and RR are required. --0016e651395e5c1e0e04a9d53095 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 04/08/2011 21:09, "Romel Khan" <romel.khan@idt.net> escribi=C3=B3:
>
> So it is useful if one of UAS or UAC requires it, but it does not have= to be mandatory. Some comments:
> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it s= eems logical to me that it needs to be made clear in this RFC3261 that earl= y dialog must mean Contact and Record-Route (if=C2=A0Record-Route was recei= ved in INVITE) headers is mandatory in 1xx without reference to 100rel.
>
> -- A UAS could always send 1xx with headers that are required for earl= y dialog but it doesn't have to enforce 100rel (eg because the originat= ion or UAS side itself may not support reliable provisional response handli= ng, or reliable provisioning not really required for its operation).=C2=A0U= AS could send "support:100rel" if it supports it,=C2=A0or it woul= d not send it if it doesn't support this.=C2=A0In my opinion,=C2=A0if U= AC hasn't sent 100rel required,=C2=A0it should be up to the UAS to deci= de whether to enforce 100rel (with=C2=A0"required:100rel")=C2=A0i= f its application really requires SIP requests before call answer. If the o= rigination side (UAC) side has a need to send early requests, like UPDATE, = then the UAC should require 100rel from the termination side (UAS) by sendi= ng this yin INVITE.=C2=A0In a VoIP service provider world,=C2=A0these kind = of capabilities are configured during interconnect turn up. =C2=A0
>
> -- I notice that some vendors gateway implementations, even if gateway= is the termination side, require 100rel for the gateway to receive pre-ans= wer requests such as UPDATE. This really didn't have to be this way. I = have always seen these gateways, when it is the termination side, respond b= ack SIP 183 with the headers that create early dialog. So if the originatio= n side received the SIP 183 response, then there is no reason for the origi= nation side to now not be able to send UPDATE request. Also,=C2=A0no reason= =C2=A0for the termination gateways to not accept the SIP UPDATE without req= uiring PRACK. =C2=A0=C2=A0

I entirely agree with it. And I also think that the fact that a 1xx resp= onse without 100rel is not reliable does not mean that it does not create a= dialog so Contact and RR are required.

--0016e651395e5c1e0e04a9d53095-- From dworley@avaya.com Sat Aug 6 18:31:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6764A21F86B9; Sat, 6 Aug 2011 18:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+FjadiTrMbX; Sat, 6 Aug 2011 18:31:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D0CB621F861A; Sat, 6 Aug 2011 18:31:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkIAADqPU6HCzI1/2dsb2JhbABCnAaLZHeBQAEBAQECAQECDygxDgULAgEIDQghECEHCiUBAQQBDQUIGodLoR4Cml+FZ18EkHSHNIRIhxY X-IronPort-AV: E=Sophos;i="4.67,330,1309752000"; d="scan'208";a="296030204" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2011 21:31:41 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Aug 2011 21:23:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Sat, 6 Aug 2011 21:31:41 -0400 From: "Worley, Dale R (Dale)" To: Samir Srivastava , Romel Khan Date: Sat, 6 Aug 2011 21:31:40 -0400 Thread-Topic: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910) Thread-Index: AcxTJnZvGdfReHLySCa4E0AQQAYa8wBembTs Message-ID: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org List" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 01:31:25 -0000 > From: Samir Srivastava [samirs.lists@gmail.com] >=20 > Hi, IMHO presentation of information in tabulated form helps a lot to > starters. Like ABNF it helps parser developers (expert of syntax & > semantic analysis) to develop it without referring each line of SIP > rfc's. The tables are a useful guide to starters. But as others have noted, it is very difficult to keep the tables up to date, and there is no format for the tables that correctly presents the conditions for all "optional" headers. Parser developers may be tempted to use the tables to determine whether a message has all the required headers, but it is nearly impossible to make that determination other than while carrying out the processing for the message. The real rule for the presence of headers is: "Perform the processing that is mandated by the SIP message. Headers whose values are required to perform this processing must be present; headers whose values are not used in the processing are ignored. If a needed header is not present, the processing of the message is aborted and it has no effect. If the message is a request, an appropriate error response is sent (if enough information is present in the request to allow doing so)." Dale From dworley@avaya.com Sat Aug 6 18:38:04 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03F21F84FD for ; Sat, 6 Aug 2011 18:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bepmko6P8GWm for ; Sat, 6 Aug 2011 18:38:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 00C7121F86A9 for ; Sat, 6 Aug 2011 18:38:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGDrPU6HCzI1/2dsb2JhbABCDqdcd4FAAQEBAQIBEihECwIBCA0BByEQMiUBAQQBEggah0uhEgKaX4VnXwSYKIsLUw X-IronPort-AV: E=Sophos;i="4.67,330,1309752000"; d="scan'208";a="296032883" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2011 21:38:25 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Aug 2011 21:30:32 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sat, 6 Aug 2011 21:38:25 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "sipcore@ietf.org" Date: Sat, 6 Aug 2011 21:38:23 -0400 Thread-Topic: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) Thread-Index: AcxSBQtCeVw1BzaTQZWm9kl58FZqPgCnOY4t Message-ID: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com>, <4E3988FD.70606@alum.mit.edu> In-Reply-To: <4E3988FD.70606@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 01:38:04 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > Of course its true that this [a 1xx response to INVITE] will only > create an early dialog at the UAC if the UAC actually receives the > (unreliable) response. If it doesn't receive it, it won't know of the > dialog, and so won't try to use BYE to terminate the dialog. But if it > does receive it, and does know of the dialog, it can then use BYE to > terminate it. And in that case the UAS will concur that there is a > dialog and so be able to properly process the BYE. I agree with Paul. Indeed, if a UAC receives a 1xx response that does *not* have a Contact header, processing of the response cannot be completed (as the dialog information cannot be constructed), and so the response must have no effect on the UAC. In regard to Record-Route, omitting them in a 1xx is even worse, as if the UAC receives the 1xx, the Record-Routes fix the route set for the dialog, and correct Record-Routes set in the 2xx response can't change the recorded route set. Dale From ibc@aliax.net Sun Aug 7 03:26:48 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E199121F8505 for ; Sun, 7 Aug 2011 03:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmGcfEgMqhwD for ; Sun, 7 Aug 2011 03:26:48 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2431921F84F0 for ; Sun, 7 Aug 2011 03:26:48 -0700 (PDT) Received: by qwc23 with SMTP id 23so562187qwc.31 for ; Sun, 07 Aug 2011 03:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.5.194 with SMTP id 2mr3108972qcw.215.1312712830485; Sun, 07 Aug 2011 03:27:10 -0700 (PDT) Received: by 10.229.79.143 with HTTP; Sun, 7 Aug 2011 03:27:10 -0700 (PDT) Received: by 10.229.79.143 with HTTP; Sun, 7 Aug 2011 03:27:10 -0700 (PDT) In-Reply-To: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> <4E3988FD.70606@alum.mit.edu> Date: Sun, 7 Aug 2011 12:27:10 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Worley, Dale R (Dale)" Content-Type: multipart/alternative; boundary=001517576bcaf406b004a9e7c542 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 10:26:49 -0000 --001517576bcaf406b004a9e7c542 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 07/08/2011 03:38, "Worley, Dale R (Dale)" escribi=C3= =B3: > In regard to Record-Route, omitting them in a 1xx is even worse, as if > the UAC receives the 1xx, the Record-Routes fix the route set for the > dialog, and correct Record-Routes set in the 2xx response can't change > the recorded route Hi. I dont agree with this last assertion. AFAIR somewhere in the rfc is stated that RR in the 2XX replaces any previous RR, even more when previous RR came in not reliable responses. However the same is not true for the sdp= . IMHO rfc3261 defined non reliable responses but later all need responses to be reliable (which would avoid all these issues). This is just a protocol core error design (obvious taking into account all these discussions so man= y years with no strong agreement). --001517576bcaf406b004a9e7c542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

El 07/08/2011 03:38, "Worley, Dale R (Dale)" <dworley@avaya.com> escribi=C3=B3:

> In regard to Record-Route, omitting them in a 1xx is even worse, as= if
> the UAC receives the 1xx, the Record-Routes fix the route set for the<= br> > dialog, and correct Record-Routes set in the 2xx response can't ch= ange
> the recorded route

Hi. I dont agree with this last assertion. AFAIR somewhere in the rfc is= stated that RR in the 2XX replaces any previous RR, even more when previou= s RR came in not reliable responses. However the same is not true for the s= dp.

IMHO rfc3261 defined non reliable responses but later all need responses= to be reliable (which would avoid all these issues). This is just a protoc= ol core error design (obvious taking into account all these discussions so = many years with no strong agreement).

--001517576bcaf406b004a9e7c542-- From dworley@avaya.com Sun Aug 7 18:29:29 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8837421F86D7 for ; Sun, 7 Aug 2011 18:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLbqvPM9E8Sw for ; Sun, 7 Aug 2011 18:29:29 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3721F86BF for ; Sun, 7 Aug 2011 18:29:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABs7P07GmAcF/2dsb2JhbABCpzV3gUABAQEBAgESZwULAgEIDQgYGTIlAQEEDgUIGodLnzACmnCDOYIuXwSHLZB7i14 X-IronPort-AV: E=Sophos;i="4.67,334,1309752000"; d="scan'208";a="200599238" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Aug 2011 21:29:52 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Aug 2011 21:26:48 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 7 Aug 2011 21:29:51 -0400 From: "Worley, Dale R (Dale)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sun, 7 Aug 2011 21:27:33 -0400 Thread-Topic: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) Thread-Index: AcxU7JKTXeWHNnmFTbmlsp6ia2f3ngAfcY4u Message-ID: References: <20110802145359.C9DEE98C50D@rfc-editor.org> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> <4E3988FD.70606@alum.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Sip] [Technical Errata Reported] RFC3261 (2910) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 01:29:29 -0000 > From: I=F1aki Baz Castillo [ibc@aliax.net] >=20 > Hi. I dont agree with this last assertion. AFAIR somewhere in the rfc > is stated that RR in the 2XX replaces any previous RR, even more when > previous RR came in not reliable responses. However the same is not > true for the sdp. Interesting! I had thought the rule that the route set is never changed was absolute. But here is RFC 3261 section 13.2.2.4: [...] If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2. Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. [...] > IMHO rfc3261 defined non reliable responses but later all need > responses to be reliable (which would avoid all these issues). This is > just a protocol core error design (obvious taking into account all > these discussions so many years with no strong agreement). True, but for backward compatibility, we have to tolerate unreliable responses. Dale From adam@nostrum.com Tue Aug 9 14:53:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0421F8AE4 for ; Tue, 9 Aug 2011 14:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DuD2d7vjia2 for ; Tue, 9 Aug 2011 14:53:24 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18921F8AD8 for ; Tue, 9 Aug 2011 14:53:19 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p79Lrmwk040767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Aug 2011 16:53:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E41AC6B.2020006@nostrum.com> Date: Tue, 09 Aug 2011 16:53:47 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Preliminary Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:53:28 -0000 [as chair] I have posted preliminary minutes for the Québec face-to-face meeting here: http://www.ietf.org/proceedings/81/minutes/sipcore.html Please review them, and submit any corrections to me and Paul and me no later than Tuesday, August 16th. Thank you. /a From brett@broadsoft.com Wed Aug 10 11:06:29 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E795021F8AFD for ; Wed, 10 Aug 2011 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzUZnCQBoM1H for ; Wed, 10 Aug 2011 11:06:29 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 69ACF21F8AF2 for ; Wed, 10 Aug 2011 11:06:29 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 10 Aug 2011 11:07:56 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 10 Aug 2011 11:07:55 -0700 From: Brett Tate To: "sipcore@ietf.org" Date: Wed, 10 Aug 2011 11:06:57 -0700 Thread-Topic: test: please ignore Thread-Index: AcxXiEtTQyIuecdQTdGOmWJ/28ccyQ== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0A023AE4F0@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] test: please ignore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:06:30 -0000 Sending another test email. If this one is actually delivered, sorry for n= oise. From dworley@avaya.com Fri Aug 12 15:24:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5F21F86B3 for ; Fri, 12 Aug 2011 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wjhGeokWA7M for ; Fri, 12 Aug 2011 15:24:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7721F86AF for ; Fri, 12 Aug 2011 15:24:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAPamRU7GmAcF/2dsb2JhbABBp3lwB4E8CxIoUQEVKUInBBsah0ebAYQDApwMhWhfBJg6i2M X-IronPort-AV: E=Sophos;i="4.67,365,1309752000"; d="scan'208";a="297305979" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Aug 2011 18:25:02 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Aug 2011 18:21:43 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 12 Aug 2011 18:25:01 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Fri, 12 Aug 2011 18:25:00 -0400 Thread-Topic: ASCII art generator? Thread-Index: AQHMWT5dS3W51P+d0EOYQ/WQadtF0A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] ASCII art generator? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:24:25 -0000 Is there a program to make the "ASCII art" diagrams of SIP message flows? Dale From adam@nostrum.com Fri Aug 12 15:28:50 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3C21F86AD for ; Fri, 12 Aug 2011 15:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8iPgSwrQCUF for ; Fri, 12 Aug 2011 15:28:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E8DCF21F874A for ; Fri, 12 Aug 2011 15:28:49 -0700 (PDT) Received: from Svantevit.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7CMTQVi048395 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 17:29:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E45A946.8020107@nostrum.com> Date: Fri, 12 Aug 2011 17:29:26 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] ASCII art generator? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:28:50 -0000 On 8/12/11 5:25 PM, Worley, Dale R (Dale) wrote: > Is there a program to make the "ASCII art" diagrams of SIP message flows? Try http://sourceforge.net/projects/callplot/ /a From petithug@acm.org Fri Aug 12 15:35:04 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFDD11E8090 for ; Fri, 12 Aug 2011 15:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p3deY+dLecJ for ; Fri, 12 Aug 2011 15:35:03 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32511E8088 for ; Fri, 12 Aug 2011 15:35:03 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 10C87202C8; Sat, 13 Aug 2011 00:32:12 +0200 (CEST) Message-ID: <4E45AABA.9070207@acm.org> Date: Fri, 12 Aug 2011 15:35:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] ASCII art generator? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:35:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2011 03:25 PM, Worley, Dale R (Dale) wrote: > Is there a program to make the "ASCII art" diagrams of SIP message flows? Wireshark. Menu Telephony|Voip Calls... - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5FqrkACgkQ9RoMZyVa61fXoQCaAq+1i4VvwdXrCpyKaoW8OM59 e1IAnRnrsFbkHCaM2yezjmgHe6tLLR4P =Y1ZO -----END PGP SIGNATURE----- From dworley@avaya.com Sun Aug 14 11:43:32 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0B21F876A for ; Sun, 14 Aug 2011 11:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.965 X-Spam-Level: X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWhsbhMyS7JM for ; Sun, 14 Aug 2011 11:43:32 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1623E21F877B for ; Sun, 14 Aug 2011 11:43:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ8WSE6HCzI1/2dsb2JhbABAp3t3gUABAQEBAgESKD8FCwIBCA0IIRAyJQEBBA4FCBqHTgSWFwKaYYVoXwSYPItn X-IronPort-AV: E=Sophos;i="4.67,370,1309752000"; d="scan'208";a="201765139" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Aug 2011 14:44:10 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Aug 2011 14:36:01 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 14 Aug 2011 14:44:10 -0400 From: "Worley, Dale R (Dale)" To: Adam Roach Date: Sun, 14 Aug 2011 14:43:20 -0400 Thread-Topic: [sipcore] ASCII art generator? Thread-Index: AcxZP0t/BB9zODbYQR6Dtd6YdoTCDABcr9Mz Message-ID: References: , <4E45A946.8020107@nostrum.com> In-Reply-To: <4E45A946.8020107@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] ASCII art generator? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 18:43:32 -0000 > From: Adam Roach [adam@nostrum.com] >=20 > > Is there a program to make the "ASCII art" diagrams of SIP message flow= s? >=20 > Try http://sourceforge.net/projects/callplot/ Wow, that's *exactly* what I need. Thanks! Dale From salinisngh1@gmail.com Wed Aug 17 02:38:38 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55621F8AF6 for ; Wed, 17 Aug 2011 02:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Typn+FoU9WN2 for ; Wed, 17 Aug 2011 02:38:37 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44A21F8AED for ; Wed, 17 Aug 2011 02:38:32 -0700 (PDT) Received: by pzk33 with SMTP id 33so1336600pzk.18 for ; Wed, 17 Aug 2011 02:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lNP5E0lr1yFlIx5wSiQ68ut1dgF7tjvV93wFTwF1aUY=; b=G2zZ5cNyuuAtWjYDVAaWqkbikXHZKjZD1ix3xxaMSBtZL8jnKHa3Fvba2VvtacQOiJ 6L1ze8EsmBOmSNCzQb+AbdmMLmsfGxe8w3oYwBgpbAwFt0sJ+/euV6rEajaOFkQO60YU UlxQnhQuwCBpX1Uq6NHJUZrGwavGUUSMO9NwU= MIME-Version: 1.0 Received: by 10.142.65.4 with SMTP id n4mr420898wfa.214.1313573963245; Wed, 17 Aug 2011 02:39:23 -0700 (PDT) Received: by 10.142.133.1 with HTTP; Wed, 17 Aug 2011 02:39:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Aug 2011 15:09:23 +0530 Message-ID: From: salini singh To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=001636e0a74d77278704aab045f9 Subject: Re: [sipcore] IETF draft submission issue - please provide support and Guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 09:38:38 -0000 --001636e0a74d77278704aab045f9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, This is Salini Singh, and I have subscribed to SIPCORE mailing list. I have a question : I want to submit a SIP-Draft -on existing SIP protocol as a independent submission, can I submit via SIPCORE , putting 2 - questio= n on this: *Question 1: =93Intended status:=94 for existing standard**.* Herein our draft which is to be submitted is about existing Internet Standards Protocol =96 SIP ( Session Initiation Protocol) suggesting a new feature and unique way to implement to avoid current unstable working technique. What should I need to write against =93Intended status:=94 withi= n my proposed draft. Should it be =93Best current practice=94 or =93Standards Tr= ack=94 . *Question 2: First line of the Internet draft*. Our draft is intended for an advancement in existing SIP based protocol, submitting for SIPCORE Working Group. Since I am submitting this proposed draft independently hence what should be the FIRST LINE OF THE DRAFT.. should it be =93SIPCORE Working Group=94or =93Network Working Group=94 or =93Independent Submission=93. What I need to do for this. Do I have to put my Draft into discussion before submitting or it need your approval for my draft name in the form - "draft-ietf-sipcore......" ? Thanks and Regards, Salini S --001636e0a74d77278704aab045f9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

This is Salini Singh, and=A0 I have subscribed to SIPCORE mailin= g list.
I have a question : I want to submit a SIP-Draft -on existing SIP=20 protocol as a independent submission, can I submit via SIPCORE , putting 2 - question on this:


Question 1: =93Intended status:=94 for existing standard<= /b>.
Herein our draft which is to be submitted is about existing Internet Standards Protocol =96 SIP ( Session Initiation Protocol) suggesting a new feature= =20 and unique way to implement to avoid current unstable working technique. What should I need to write against =93Intended status:=94 within my=20 proposed draft. Should it be =93Best current practice=94 or =93Standards=20 Track=94 .

=A0Question 2: First line of the Internet draft.
Our= =20 draft is intended for an advancement in existing SIP based protocol,=20 submitting for SIPCORE Working Group. Since I am submitting this=20 proposed draft independently =A0hence what should be the FIRST LINE OF THE DRAFT.. should it be =93SIPCORE Working Group=94or =93Network Working Grou= p=94=20 =A0or =93Independent Submission=93.


What I need to do for this.<= br>Do I have to put my Draft into discussion before submitting or it need=20 your approval for my draft name in the form - "draft-ietf-sipcore.....= ." ?

Thanks and Regards,
Salini S --001636e0a74d77278704aab045f9-- From pkyzivat@alum.mit.edu Wed Aug 17 07:47:46 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F2421F8B1C for ; Wed, 17 Aug 2011 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoMUV5m9aqVA for ; Wed, 17 Aug 2011 07:47:46 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 04D8A21F856C for ; Wed, 17 Aug 2011 07:47:45 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id MSj31h00B1YDfWL5FSodel; Wed, 17 Aug 2011 14:48:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id MSoa1h01H0tdiYw3gSoblC; Wed, 17 Aug 2011 14:48:36 +0000 Message-ID: <4E4BD4C2.2020705@alum.mit.edu> Date: Wed, 17 Aug 2011 10:48:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] IETF draft submission issue - please provide support and Guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 14:47:46 -0000 Salini, I gather you are new to the ietf process. First, it isn't clear from what you have stated below that sipcore would be the proper forum for the work you describe. We have a special work group in the RAI area that is charged with scoping out new work on SIP and determining if/how it should proceed. In my opinion, as co-chair of sipcore, that you should first present your concept to the dispatch WG. (That means you should subscribe to dispatch@ietf.org and send mail there.) Regarding Intended Status: I think it is premature to determine that. It may even be premature to write a draft. What I suggest is that you: - subscribe to the dispatch@ietf.org mailing list - send an email to that list, focusing primarily on giving a high level description of the problem you are trying to solve, preferable with some use cases. If you have some thoughts on how to solve the problem you can sketch them too, but don't invest too much effort in that, since it is likely to change significantly after the the problem is discussed by the community. - you should frame the email above so as to solicit discussion and feedback on it. Hopefully that will come. If not, then perhaps your problem isn't of general interest. Or maybe your problem will need to be further clarified so others can relate to it. - if it looks like there is interest, you can then submit a draft, with a name such as draft-singh-dispatch-xxxxx-00.txt. At this state it doesn't matter much what the intended status is, you can make it be informational, or whatever. It can be changed later. In this draft you would formalize the problem statement, use cases, and a list of requirements that any solution to the problem statement must fulfill. - then you should send an email to the dispatch list referencing this draft and asking for comments on it. - based on the comments received, you will likely want to submit one or more revisions to the draft, refining it. - somewhere along the way in this process, the dispatch WG chairs will probably get involved to guide you in how to proceed, based on the interest in the subject expressed on the list. You could skip the first few steps above, and go right to the step where you submit a draft. But if you haven't done this before it will probably be easier to start at the beginning. Good Luck, Paul Kyzivat, sipcore co-chair On 8/17/11 5:39 AM, salini singh wrote: > Hi, > > This is Salini Singh, and I have subscribed to SIPCORE mailing list. > I have a question : I want to submit a SIP-Draft -on existing SIP > protocol as a independent submission, can I submit via SIPCORE , putting > 2 - question on this: > > > *_Question 1: “Intended status:” for existing standard_*_._ > Herein our draft which is to be submitted is about existing Internet > Standards Protocol – SIP ( Session Initiation Protocol) suggesting a new > feature and unique way to implement to avoid current unstable working > technique. What should I need to write against “Intended status:” within > my proposed draft. Should it be “Best current practice” or “Standards > Track” . > > _*Question 2: First line of the Internet draft*_. > Our draft is intended for an advancement in existing SIP based protocol, > submitting for SIPCORE Working Group. Since I am submitting this > proposed draft independently hence what should be the FIRST LINE OF THE > DRAFT.. should it be “SIPCORE Working Group”or “Network Working Group” > or “Independent Submission“. > > > What I need to do for this. > Do I have to put my Draft into discussion before submitting or it need > your approval for my draft name in the form - "draft-ietf-sipcore......" ? > > Thanks and Regards, > Salini S > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Wed Aug 17 13:07:27 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9341F0C4C for ; Wed, 17 Aug 2011 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op3dbKIPy-0d for ; Wed, 17 Aug 2011 13:07:27 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE71F0C4A for ; Wed, 17 Aug 2011 13:07:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIAfTE6HCzI1/2dsb2JhbABCqHJ3gUABAQEBAgESKC0XDQEVCCFCJwQBGhqHTgSaRAKcL4VpXwSYPYtn X-IronPort-AV: E=Sophos;i="4.68,241,1312171200"; d="scan'208";a="202327713" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Aug 2011 16:08:00 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Aug 2011 15:59:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 17 Aug 2011 16:08:00 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" , "john.elwell@siemens-enterprise.com" Date: Wed, 17 Aug 2011 16:06:27 -0400 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:07:27 -0000 > From: Elwell, John [john.elwell at siemens-enterprise.com] >=20 > I haven't reviewed it in detail, but I see there is no mention of > RTCP. Perhaps it isn't really relevant, except that it provides > another reason why the media server needs to supply an IP address and > port - even though it will not receive RTP, it will receive RTCP. The > RTCP port could be implicit or explicit. I don't think I've mentioned this, but draft-worley-service-example-06 has updates to point out that allowing RTCP is useful. See http://tools.ietf.org/rfcdiff?url2=3Ddraft-worley-service-example-06 and search for "RTCP". These changes are carried forward into the current -07 draft as well. Do these changes suffice? Dale From john.elwell@siemens-enterprise.com Thu Aug 18 00:04:16 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38B11E808C for ; Thu, 18 Aug 2011 00:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqvis9DhUfFP for ; Thu, 18 Aug 2011 00:04:14 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1626D11E8083 for ; Thu, 18 Aug 2011 00:04:13 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4A5EC23F0545; Thu, 18 Aug 2011 09:05:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 18 Aug 2011 09:05:05 +0200 From: "Elwell, John" To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Thu, 18 Aug 2011 09:05:04 +0200 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:04:16 -0000 Dale, Yes, it does now make an appropriate mention of RTCP - thanks. I am also curious as to why there are a couple of mentions of using directi= onality "inactive". Why would any of the entities involved use "inactive" u= nless they don't wish to send/receive music-on-hold? In particular, why wou= ld the INVITE from the executing UA to the MOH source use "inactive" - it i= s specifically asking the MOH source to send music, so if it wants "inactiv= e", why send the INVITE? Perhaps this is to do with multiple media, where the remote UA offers sever= al media, and MOH is required only for one of these, so the other media des= criptions are set to "inactive" in the INVITE to the MOH source. Whether or= not that was the intention of "inactive", I think further discussion of mu= lti-media situations is required. For example, if the remote UA offers audi= o and video and the executing UA wants MOH only for audio, how would it beh= ave? Perhaps the example should be extended to show such a possibility. John > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Sent: 17 August 2011 21:06 > To: sipcore@ietf.org; Elwell, John > Subject: Reviewers needed for new music-on-hold technique >=20 > > From: Elwell, John [john.elwell at siemens-enterprise.com] > >=20 > > I haven't reviewed it in detail, but I see there is no mention of > > RTCP. Perhaps it isn't really relevant, except that it provides > > another reason why the media server needs to supply an IP=20 > address and > > port - even though it will not receive RTP, it will receive=20 > RTCP. The > > RTCP port could be implicit or explicit. >=20 > I don't think I've mentioned this, but draft-worley-service-example-06 > has updates to point out that allowing RTCP is useful. See > http://tools.ietf.org/rfcdiff?url2=3Ddraft-worley-service-example-06 and > search for "RTCP". These changes are carried forward into the > current -07 draft as well. >=20 > Do these changes suffice? >=20 > Dale > = From dworley@avaya.com Thu Aug 18 11:10:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A564321F8B29 for ; Thu, 18 Aug 2011 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.454 X-Spam-Level: X-Spam-Status: No, score=-103.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39UMdl7wjF8V for ; Thu, 18 Aug 2011 11:10:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E21F8B02 for ; Thu, 18 Aug 2011 11:10:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGhUTU6HCzI1/2dsb2JhbABCp3R3gUABAQEBAgESKEQLAgEIDQghEDIlAgQBEggah0+cDgKcMYVpXwSYPYtn X-IronPort-AV: E=Sophos;i="4.68,246,1312171200"; d="scan'208";a="298287533" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Aug 2011 14:11:15 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Aug 2011 14:02:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 18 Aug 2011 14:11:15 -0400 From: "Worley, Dale R (Dale)" To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 18 Aug 2011 14:11:15 -0400 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QA= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:10:28 -0000 > From: Elwell, John [john.elwell@siemens-enterprise.com] >=20 > Yes, it does now make an appropriate mention of RTCP - thanks. Good -- Thanks for checking that out. > I am also curious as to why there are a couple of mentions of using > directionality "inactive". Why would any of the entities involved use > "inactive" unless they don't wish to send/receive music-on-hold? In > particular, why would the INVITE from the executing UA to the MOH > source use "inactive" - it is specifically asking the MOH source to > send music, so if it wants "inactive", why send the INVITE? The strict answer as to why "inactive" is mentioned is that the algorithm would not be correct without it, and I hadn't considered the possible optimization of omitting the INVITE to the MOH source. The situation arises when the remote UA gives directionality "sendonly" because the remote UA has previously put the call on hold also. (The remote UA may reduce the directionality to "inactive" due to the +sip.rendering=3D"no" in the re-INVITE from the executing UA.) There probably other situations where this arises. E.g., where the remote UA has formerly used a media stream in the dialog but no longer wants to. If all of the media streams that would be in the INVITE to the MOH source have "inactive" directionality, the executing UA can omit establishing the dialog with the MOH source. The executing UA would synthesize the SDP answer itself. While the call is on hold, if the remote UA sends a re-INVITE with directionality "active"/"recvonly", then the executing UA has to start a dialog with the MOH source. I should add a note that discusses this optimization. > Perhaps this is to do with multiple media, where the remote UA offers > several media, and MOH is required only for one of these, so the other > media descriptions are set to "inactive" in the INVITE to the MOH > source. Whether or not that was the intention of "inactive", I think > further discussion of multi-media situations is required. For example, > if the remote UA offers audio and video and the executing UA wants MOH > only for audio, how would it behave? Perhaps the example should be > extended to show such a possibility. I would expect multiple media streams to work exactly as an extension of the single media stream situation. But there may be requirements that I am not considering. In the case where a call is being put on-hold and the remote UA is willing to accept two streams (e.g., audio and video), I would expect the executing UA to forward this request intact to the MOH server. The MOH server would decide what media to send to the remote UA. If the executing UA wanted to restrict the MOH media, it could do so by editing the SDP offer. But I don't see any particular reason to do so. What are the complexities you are seeing? Dale From john.elwell@siemens-enterprise.com Thu Aug 18 23:23:10 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E075E8001 for ; Thu, 18 Aug 2011 23:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKnxMHnVmURQ for ; Thu, 18 Aug 2011 23:23:09 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2721F859F for ; Thu, 18 Aug 2011 23:23:08 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E83A323F04A5; Fri, 19 Aug 2011 08:24:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Aug 2011 08:24:03 +0200 From: "Elwell, John" To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Fri, 19 Aug 2011 08:24:02 +0200 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QCAANGxwA== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 06:23:10 -0000 =20 > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Sent: 18 August 2011 19:11 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Reviewers needed for new music-on-hold technique >=20 > > From: Elwell, John [john.elwell@siemens-enterprise.com] > >=20 > > Yes, it does now make an appropriate mention of RTCP - thanks. >=20 > Good -- Thanks for checking that out. >=20 > > I am also curious as to why there are a couple of mentions of using > > directionality "inactive". Why would any of the entities=20 > involved use > > "inactive" unless they don't wish to send/receive music-on-hold? In > > particular, why would the INVITE from the executing UA to the MOH > > source use "inactive" - it is specifically asking the MOH source to > > send music, so if it wants "inactive", why send the INVITE? >=20 > The strict answer as to why "inactive" is mentioned is that the > algorithm would not be correct without it, and I hadn't considered the > possible optimization of omitting the INVITE to the MOH source. >=20 > The situation arises when the remote UA gives directionality > "sendonly" because the remote UA has previously put the call on hold > also. (The remote UA may reduce the directionality to "inactive" due > to the +sip.rendering=3D"no" in the re-INVITE from the executing UA.) >=20 > There probably other situations where this arises. E.g., where the > remote UA has formerly used a media stream in the dialog but no longer > wants to. >=20 > If all of the media streams that would be in the INVITE to the MOH > source have "inactive" directionality, the executing UA can omit > establishing the dialog with the MOH source. The executing UA would > synthesize the SDP answer itself. While the call is on hold, if the > remote UA sends a re-INVITE with directionality "active"/"recvonly", > then the executing UA has to start a dialog with the MOH source. >=20 > I should add a note that discusses this optimization. >=20 > > Perhaps this is to do with multiple media, where the remote=20 > UA offers > > several media, and MOH is required only for one of these,=20 > so the other > > media descriptions are set to "inactive" in the INVITE to the MOH > > source. Whether or not that was the intention of "inactive", I think > > further discussion of multi-media situations is required.=20 > For example, > > if the remote UA offers audio and video and the executing=20 > UA wants MOH > > only for audio, how would it behave? Perhaps the example should be > > extended to show such a possibility. >=20 > I would expect multiple media streams to work exactly as an extension > of the single media stream situation. But there may be requirements > that I am not considering. >=20 > In the case where a call is being put on-hold and the remote UA is > willing to accept two streams (e.g., audio and video), I would expect > the executing UA to forward this request intact to the MOH server. > The MOH server would decide what media to send to the remote UA. >=20 > If the executing UA wanted to restrict the MOH media, it could do so > by editing the SDP offer. But I don't see any particular reason to do > so. >=20 > What are the complexities you are seeing? [JRE] Nothing that can't be dealt with relatively easily, but perhaps some = mention is needed. Don't forget that hold (in terms of SDP directionality i= ndications) can be on a per medium basis. I guess if the remote UA offers a= udio and video and the executing UA only wants to hold audio, it would need= to manipulate the SDP such that only audio is offered to the MOH source, a= nd then when the answer is received, add in its own video description befor= e forwarding the answer to the remote UA. Or if the executing UA forwards b= oth audio and video to the MOH source and the MOH source rejects video, the= executing UA might want to send inactive to the remote UA rather than pass= ing on the rejection. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > Dale > = From dworley@avaya.com Fri Aug 19 12:48:46 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D621F8C11 for ; Fri, 19 Aug 2011 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd7R96ebdYhV for ; Fri, 19 Aug 2011 12:48:46 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3A221F8C0F for ; Fri, 19 Aug 2011 12:48:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJm8Tk6HCzI1/2dsb2JhbABBqA13gUABAQEBAxIoTwIBCA0pEDIlAgQBGhqkOQKcDIVpXwSYPYtn X-IronPort-AV: E=Sophos;i="4.68,252,1312171200"; d="scan'208";a="202772084" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Aug 2011 15:49:42 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Aug 2011 15:41:22 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 19 Aug 2011 15:49:41 -0400 From: "Worley, Dale R (Dale)" To: "Elwell, John" , "sipcore@ietf.org" Date: Fri, 19 Aug 2011 15:48:56 -0400 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QCAANGxwIAA5Gay Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:48:47 -0000 How about adding these sections to the end of section 2? When the Media Stream Directionality is "inactive" The directionality of the media stream in the SDP offer in an INVITE or re-INVITE to the music source can be "inactive" if the SDP offer from the remote UA was "sendonly" or "inactive". Generally, this happens when the remote UA also has put the call on hold and provided a directionality of "sendonly". In this situation, the executing UA can omit establishing the dialog with the music source (or can terminate the existing dialog with the music source). If the executing UA uses this optimization, it creates the SDP answer itself, with directionality "inactive" and using its own RTP/RTCP ports, and returns that answer to the remote UA. The executing UA must be prepared for the remote UA to send a re-INVITE with directionality "active" or "recvonly", in which case the executing UA must initiate a dialog with the music source, as described above. Multiple Media Streams There may be multiple media streams (multiple m=3D lines) in any of the the SDPs involved in the dialogs. As the SDPs are manipulated, each media description (each starting with an m=3D line) is manipulated as described above for a single media stream. But there are some elaborations that the executing UA may implement to achieve specific effects. If the executing UA desires to present only certain media types as on-hold media, when passing the offer SDP through, it can reject any particular media streams by setting the port number in the m=3D line to zero.[offer-answer] This ensures that the answer SDP will also have a rejection for that m=3D line. If the executing UA wishes to provide its own on-hold media for a particular m=3D line, it can do so by providing the answer information for that m=3D line. The executing UA may decide to do this when the offer SDP is received (by modifying the m=3D line to rejected state when sending it to the music source), or upon receiving the answer from the music source and discovering that the m=3D line has been rejected. The executing UA may not want to pass a rejected m=3D line from the music source to the remote UA (when the remote UA provided a non-rejected m=3D line), and instead provide an answer with directionality "inactive" (and specifying its own RTP/RTCP ports). Dale From samirs.lists@gmail.com Sun Aug 21 23:00:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60AA21F85A4; Sun, 21 Aug 2011 23:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGwiz8XtDijq; Sun, 21 Aug 2011 23:00:33 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F09521F8538; Sun, 21 Aug 2011 23:00:17 -0700 (PDT) Received: by pzk33 with SMTP id 33so15611494pzk.18 for ; Sun, 21 Aug 2011 23:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ic4niLsIaJdfu70pBr+aIqlFttAtY8FsruFTpUHBvZM=; b=Z0nb0R6UIgLQ8LtQi2dEUKd0eMfK2bDYyiMDItX50/JLuJHPM8Oco/PJuR/QmtMBtm jV0HCVASNKRFRGQsRQZ4s3iKDDSvWXKMyIL4YK7NgfZ3Mzdq2RmXAd2nenGtFWA94QUW M22cUUcCie2YItMJZQ4LXVaT78Dga5e8PX+Z0= MIME-Version: 1.0 Received: by 10.142.125.18 with SMTP id x18mr1461314wfc.412.1313992880843; Sun, 21 Aug 2011 23:01:20 -0700 (PDT) Received: by 10.68.49.106 with HTTP; Sun, 21 Aug 2011 23:01:20 -0700 (PDT) Date: Sun, 21 Aug 2011 23:01:20 -0700 Message-ID: From: Samir Srivastava To: sipcore@ietf.org, secdir@ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Volunteers please for coauthor X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:00:34 -0000 Hi, It is quite unusual to send this note on list. I approched couple of folks privately but in vain. Due to unavoidable situation, I have limited internet access with which I cannot submit draft. I am looking for coauthors for a draft covering unaddressed issues by SIPS and work on cashless economy etc at http://samirsrivastava.typepad.com . To the best of my knowledge and skills it will *AVOID* various security issues of SIP/ INTERNET. Volunteers pl. People from persmal id gmail etc can also help. BTW I have solution for overwhelmed response (which I doubt). CCing secdir for any help. Regards Samir From john.elwell@siemens-enterprise.com Sun Aug 21 23:24:52 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498CD21F86DD for ; Sun, 21 Aug 2011 23:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.289 X-Spam-Level: X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF3FB8Ohkq6Q for ; Sun, 21 Aug 2011 23:24:51 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7643D21F86B1 for ; Sun, 21 Aug 2011 23:24:51 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D1F291EB841E; Mon, 22 Aug 2011 08:25:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Aug 2011 08:25:52 +0200 From: "Elwell, John" To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Mon, 22 Aug 2011 08:25:51 +0200 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHMXRkmJGtO1i1bHkiyPkqXjzoA1pUiLNrggAC07QCAANGxwIAA5GaygAPWgdA= Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:24:52 -0000 Dale, Yes, this text addresses my concerns. John=20 > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Sent: 19 August 2011 20:49 > To: Elwell, John; sipcore@ietf.org > Subject: RE: Reviewers needed for new music-on-hold technique >=20 > How about adding these sections to the end of section 2? >=20 >=20 > When the Media Stream Directionality is "inactive" >=20 > The directionality of the media stream in the SDP offer in an INVITE > or re-INVITE to the music source can be "inactive" if the SDP offer > from the remote UA was "sendonly" or "inactive". Generally, this > happens when the remote UA also has put the call on hold and provided > a directionality of "sendonly". In this situation, the executing UA > can omit establishing the dialog with the music source (or can > terminate the existing dialog with the music source). >=20 > If the executing UA uses this optimization, it creates the SDP answer > itself, with directionality "inactive" and using its own RTP/RTCP > ports, and returns that answer to the remote UA. >=20 > The executing UA must be prepared for the remote UA to send a > re-INVITE with directionality "active" or "recvonly", in which case > the executing UA must initiate a dialog with the music source, as > described above. >=20 > Multiple Media Streams >=20 > There may be multiple media streams (multiple m=3D lines) in any of the > the SDPs involved in the dialogs. As the SDPs are manipulated, each > media description (each starting with an m=3D line) is manipulated as > described above for a single media stream. But there are some > elaborations that the executing UA may implement to achieve specific > effects. >=20 > If the executing UA desires to present only certain media types as > on-hold media, when passing the offer SDP through, it can reject any > particular media streams by setting the port number in the m=3D line to > zero.[offer-answer] This ensures that the answer SDP will also have a > rejection for that m=3D line. >=20 > If the executing UA wishes to provide its own on-hold media for a > particular m=3D line, it can do so by providing the answer information > for that m=3D line. The executing UA may decide to do this when the > offer SDP is received (by modifying the m=3D line to rejected state when > sending it to the music source), or upon receiving the answer from the > music source and discovering that the m=3D line has been rejected. >=20 > The executing UA may not want to pass a rejected m=3D line from the > music source to the remote UA (when the remote UA provided a > non-rejected m=3D line), and instead provide an answer with > directionality "inactive" (and specifying its own RTP/RTCP ports). >=20 >=20 > Dale > = From pkyzivat@alum.mit.edu Fri Aug 26 06:59:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913B21F8745 for ; Fri, 26 Aug 2011 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAiusKSNgOB5 for ; Fri, 26 Aug 2011 06:59:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id E9FA221F86EC for ; Fri, 26 Aug 2011 06:59:35 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id R1su1h0061YDfWL5820sLX; Fri, 26 Aug 2011 14:00:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id R20o1h01w0tdiYw3g20qQB; Fri, 26 Aug 2011 14:00:51 +0000 Message-ID: <4E57A714.4060107@alum.mit.edu> Date: Fri, 26 Aug 2011 10:00:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: SIPCORE , "sipcore-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary="------------080102060705060600060406" Subject: [sipcore] WGLC of draft-ietf-sipcore-rfc3265bis-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:59:36 -0000 This is a multi-part message in MIME format. --------------080102060705060600060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is an announcement of a Working Group Last Call on draft-ietf-sipcore-rfc3265bis-03.txt: http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-03.txt Please review and provide any comments you have on the document no later than Friday September 16, 2011. Comments should be sent to the document authors and the SIPCORE WG mailing list. Thanks, Paul --------------080102060705060600060406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <as co-chair>

This is an announcement of a Working Group Last Call on draft-ietf-sipcore-rfc3265bis-03.txt:

http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-03.txt

Please review and provide any comments you have on the document no later than Friday September 16, 2011.
Comments should be sent to the document authors and the SIPCORE WG mailing list.

    Thanks,
    Paul --------------080102060705060600060406-- From HKaplan@acmepacket.com Wed Aug 31 07:50:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7C21F8BB9 for ; Wed, 31 Aug 2011 07:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmMEWfEwsRqb for ; Wed, 31 Aug 2011 07:50:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4D21F8B91 for ; Wed, 31 Aug 2011 07:50:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 31 Aug 2011 10:51:48 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 31 Aug 2011 10:51:48 -0400 From: Hadriel Kaplan To: SIPCORE Date: Wed, 31 Aug 2011 10:51:49 -0400 Thread-Topic: 202 response in draft-ietf-sipcore-rfc3265bis-03 Thread-Index: Acxn7YHvHRPQyo26TveR9qiWfPJPFw== Message-ID: <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> References: <4E57A714.4060107@alum.mit.edu> In-Reply-To: <4E57A714.4060107@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Subject: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:50:20 -0000 Howdy, One of the changes made by 3265bis relative to 3265 is the deprecation of t= he 202 response. I have two questions related to this change: 1) The current text for deprecation of 202 in 3265bis not only updates 3265= but also RFC 4660, since that also uses 202. Should 3265bis also update R= FC 5839, which uses 202 in example flows and notes? 2) The current draft does not say why the 202 response was deprecated. Thr= ough some googling, I found this: http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20The= %20Fate%20of%20202 And I went and listened to the audio archive for IETF 75 SIPCORE meeting. 3265bis-03 says this in section 8.3.1: This document does not specify the use of the 202 response code in conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions of the SIP Events Framework assigned specific semantics to the 202 response code. Implementations conformant with the current specification MUST treat an incoming 202 response as identical to a 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE or NOTIFY requests. I recommend that be changed to this, assuming it's correct: This document does not specify the use of the 202 response code in conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions of the SIP Events Framework assigned specific semantics to the 202 response code. Due to response handling in forking cases, a UAC may not have received the response as a 202, and thus it could never have been guaranteed to be received. Furthermore, there was no actual use difference for the 202 compared to a 200, given a NOTIFY is sent after the subscription is processed and it conveys the correct state. Since it was found that implementations were handling 202 differently from 200= , the 202 response is being deprecated to make it clear there is no such difference and they should not be handled differently. Implementations conformant with the current specification MUST treat an incoming 202 response as identical to a 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE or NOTIFY requests. -hadriel On Aug 26, 2011, at 10:00 AM, Paul Kyzivat wrote: > >=20 > This is an announcement of a Working Group Last Call on draft-ietf-sipcor= e-rfc3265bis-03.txt: >=20 > http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-03.txt >=20 > Please review and provide any comments you have on the document no later = than Friday September 16, 2011. > Comments should be sent to the document authors and the SIPCORE WG mailin= g list. >=20 > Thanks, > Paul > From internet-drafts@ietf.org Wed Aug 31 14:18:11 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47221F8D0C; Wed, 31 Aug 2011 14:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.82 X-Spam-Level: X-Spam-Status: No, score=-98.82 tagged_above=-999 required=5 tests=[AWL=3.780, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPw0kQzDFYSz; Wed, 31 Aug 2011 14:18:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1707C21F8CD9; Wed, 31 Aug 2011 14:18:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110831211811.16760.3298.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 14:18:11 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-event-rate-control-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:18:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Ext= ension for Notification Rate Control Author(s) : Aki Niemi Krisztian Kiss Salvatore Loreto Filename : draft-ietf-sipcore-event-rate-control-09.txt Pages : 25 Date : 2011-08-31 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-0= 9.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-09= .txt