From adam@nostrum.com Mon Aug 3 13:59:39 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3B13A687F; Mon, 3 Aug 2009 13:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPza3yn-bgis; Mon, 3 Aug 2009 13:59:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 790CA28C282; Mon, 3 Aug 2009 13:59:23 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n73KxNSK065784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 15:59:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A774FAB.6010200@nostrum.com> Date: Mon, 03 Aug 2009 15:59:23 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: IETF RAI Dispatch , BLISS WG , HTTP working group 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) Subject: [dispatch] New SIP HTTP Subscription Package Mailing List X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIP HTTP Event Package List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:59:39 -0000 We have established a new mailing list to discuss a new SIP event package for subscribing to the state of an HTTP resource. See for a current proposal. The list is intended to focus on closing technical issues in the document. It is currently left open whether the document will be published as an individual document or become part of a working group's chartered work. If you are interested in participating, please subscribe at: https://www.ietf.org/mailman/listinfo/sip-http-events /a From christer.holmberg@ericsson.com Tue Aug 4 23:17:39 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDED3A715F for ; Tue, 4 Aug 2009 23:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HLlZg6Cw5iz for ; Tue, 4 Aug 2009 23:17:39 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9BAF528C48D for ; Tue, 4 Aug 2009 23:17:38 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-8f-4a7923fb37b9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 40.99.18827.BF3297A4; Wed, 5 Aug 2009 08:17:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 08:15:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 08:15:57 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HAC2pAeYA== References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , , "Gonzalo Camarillo" X-OriginalArrivalTime: 05 Aug 2009 06:15:59.0131 (UTC) FILETIME=[332B76B0:01CA1594] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 06:17:40 -0000 Hi Francois, As you mentioned earlier, it could make sense to allow it in 199. Regards, Christer=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Francois Audet Sent: Tuesday, July 21, 2009 8:34 PM To: R.Jesske@telekom.de; Gonzalo Camarillo Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 and explain why 3XX, 2XX and 1XX don't make sense.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, July 20, 2009 22:03 > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi Gonzalo, > Thank you for your comments. > You are correct. The used cases within the document shows where ISUP=20 > causes will be included. > I think in such cases we should clearly state that SIP Reason should=20 > be excluded within SIP responses, to avoid contradictions. >=20 > Then I will include that only within 4xx/5xx/6xx Responses the Reason=20 > header with an Q.850 Cause makes sense. >=20 > There are requirements and three used cases described within the draft = > so I hope that fits. >=20 > Best Regards >=20 > Roland > -----Urspr=FCngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Gesendet: Montag, 20. Juli 2009 11:41 > An: Francois Audet > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi, >=20 > as Francois suggests, a document specifying the use of Reason header=20 > fields in responses needs to specify those things (see Francois' list=20 > below). Additionally, you should think of whether or not Reason header = > fields in responses can carry SIP status codes and what happens if=20 > they are different to the status code of the response. >=20 > In short, the document cannot simply say that now it is OK to use=20 > Reason in responses. It needs to address the different situations a=20 > typical implementation may face. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > Francois Audet wrote: > > Again, the spec is very clear that it IS allowed. > >=20 > > I believe the wishy-washy text about "status code > explicitly allowing > > it" was meant to exclude responses that were not appropriate, and=20 > > restricing it to effectively error responses. > >=20 > > At the time this was written, I believe we were not clear on which=20 > > codes were supposed to be appropriate or not. > >=20 > > Seems to me: > > - Any Error response code should be allowed. > > - I don't think 2XX makes sense. > > - 3XX is controversial (as per the email quoted by Roland):=20 > seems to me it > > would be quite useful > > - Provisional is interesting... Sounds like 199 error > response to me... > >=20 > >> -----Original Message----- > >> From: Worley, Dale (BL60:9D30) > >> Sent: Thursday, July 16, 2009 10:09 > >> To: Audet, Francois (SC100:3055) > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >> > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > (SC100:3055) wrote: > >>> Hi Roland, > >>> > >>> You use case is very common. =20 > >>> > >>> I believe you are incorrect in saying that "reasons are > >> currently not > >>> allowed in responses. Neither conditionally nor allowed". > >>> > >>> RFC 3326 says in 1.0: > >>> "[...] it can appear in any request > >>> within a dialog, in any CANCEL request and in any > response whose > >>> status code explicitly allows the presence of this > header field." > >>> > >>> To be honest, I believe Q.850 codes are much more common in > >> Responses > >>> than in requests. > >> Googling > >> > >> "sip/2.0" reason "q.850" > >> > >> turns up numerous examples of SIP responses using the > Reason header > >> in the forbidden manner. > >> > >> I'd say that your draft formally allows what people are > already doing. > >> > >> Dale > >> > >> > >> > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From AUDET@nortel.com Wed Aug 5 08:54:54 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729943A67BE for ; Wed, 5 Aug 2009 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsZGAytx-YGO for ; Wed, 5 Aug 2009 08:54:53 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 424DE3A6950 for ; Wed, 5 Aug 2009 08:54:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n75FqpH29350; Wed, 5 Aug 2009 15:52:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 10:54:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 thread-index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HAC2pAeYAAUVgtg References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , , "Gonzalo Camarillo" Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:54:54 -0000 Yes, I think so.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, August 04, 2009 23:16 > To: Audet, Francois (SC100:3055); R.Jesske@telekom.de;=20 > Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 > Hi Francois, >=20 > As you mentioned earlier, it could make sense to allow it in 199. >=20 > Regards, >=20 > Christer=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Tuesday, July 21, 2009 8:34 PM > To: R.Jesske@telekom.de; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > and explain why 3XX, 2XX and 1XX don't make sense.=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Monday, July 20, 2009 22:03 > > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > Hi Gonzalo, > > Thank you for your comments. > > You are correct. The used cases within the document shows=20 > where ISUP=20 > > causes will be included. > > I think in such cases we should clearly state that SIP=20 > Reason should=20 > > be excluded within SIP responses, to avoid contradictions. > >=20 > > Then I will include that only within 4xx/5xx/6xx Responses=20 > the Reason=20 > > header with an Q.850 Cause makes sense. > >=20 > > There are requirements and three used cases described=20 > within the draft=20 > > so I hope that fits. > >=20 > > Best Regards > >=20 > > Roland > > -----Urspr=FCngliche Nachricht----- > > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Gesendet: Montag, 20. Juli 2009 11:41 > > An: Francois Audet > > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > Hi, > >=20 > > as Francois suggests, a document specifying the use of=20 > Reason header=20 > > fields in responses needs to specify those things (see=20 > Francois' list=20 > > below). Additionally, you should think of whether or not=20 > Reason header=20 > > fields in responses can carry SIP status codes and what happens if=20 > > they are different to the status code of the response. > >=20 > > In short, the document cannot simply say that now it is OK to use=20 > > Reason in responses. It needs to address the different situations a=20 > > typical implementation may face. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > >=20 > > Francois Audet wrote: > > > Again, the spec is very clear that it IS allowed. > > >=20 > > > I believe the wishy-washy text about "status code > > explicitly allowing > > > it" was meant to exclude responses that were not appropriate, and=20 > > > restricing it to effectively error responses. > > >=20 > > > At the time this was written, I believe we were not clear=20 > on which=20 > > > codes were supposed to be appropriate or not. > > >=20 > > > Seems to me: > > > - Any Error response code should be allowed. > > > - I don't think 2XX makes sense. > > > - 3XX is controversial (as per the email quoted by Roland):=20 > > seems to me it > > > would be quite useful > > > - Provisional is interesting... Sounds like 199 error > > response to me... > > >=20 > > >> -----Original Message----- > > >> From: Worley, Dale (BL60:9D30) > > >> Sent: Thursday, July 16, 2009 10:09 > > >> To: Audet, Francois (SC100:3055) > > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > >> > > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > > (SC100:3055) wrote: > > >>> Hi Roland, > > >>> > > >>> You use case is very common. =20 > > >>> > > >>> I believe you are incorrect in saying that "reasons are > > >> currently not > > >>> allowed in responses. Neither conditionally nor allowed". > > >>> > > >>> RFC 3326 says in 1.0: > > >>> "[...] it can appear in any request > > >>> within a dialog, in any CANCEL request and in any > > response whose > > >>> status code explicitly allows the presence of this > > header field." > > >>> > > >>> To be honest, I believe Q.850 codes are much more common in > > >> Responses > > >>> than in requests. > > >> Googling > > >> > > >> "sip/2.0" reason "q.850" > > >> > > >> turns up numerous examples of SIP responses using the > > Reason header > > >> in the forbidden manner. > > >> > > >> I'd say that your draft formally allows what people are > > already doing. > > >> > > >> Dale > > >> > > >> > > >> > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > >=20 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From R.Jesske@telekom.de Thu Aug 6 03:30:04 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E513A6D4D for ; Thu, 6 Aug 2009 03:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb-2bDTYoZph for ; Thu, 6 Aug 2009 03:30:03 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 944713A6D4F for ; Thu, 6 Aug 2009 03:28:46 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 06 Aug 2009 12:28:44 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 12:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 12:28:43 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HAC2pAeYAAUVgtgAB0UM7A= References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 06 Aug 2009 10:28:44.0438 (UTC) FILETIME=[ACCF6B60:01CA1680] Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 10:30:04 -0000 Hi Christer and Francois, I have added a sentence under section Overall Applicability: The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses.=20 Is this proper enough? Or do you have more in mind? BR, Roland -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com]=20 Gesendet: Mittwoch, 5. August 2009 17:55 An: Christer Holmberg; Jesske, Roland; Gonzalo Camarillo Cc: dispatch@ietf.org Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Yes, I think so.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, August 04, 2009 23:16 > To: Audet, Francois (SC100:3055); R.Jesske@telekom.de;=20 > Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 >=20 > Hi Francois, >=20 > As you mentioned earlier, it could make sense to allow it in 199. >=20 > Regards, >=20 > Christer=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Tuesday, July 21, 2009 8:34 PM > To: R.Jesske@telekom.de; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > and explain why 3XX, 2XX and 1XX don't make sense.=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Monday, July 20, 2009 22:03 > > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > Hi Gonzalo, > > Thank you for your comments. > > You are correct. The used cases within the document shows=20 > where ISUP=20 > > causes will be included. > > I think in such cases we should clearly state that SIP=20 > Reason should=20 > > be excluded within SIP responses, to avoid contradictions. > >=20 > > Then I will include that only within 4xx/5xx/6xx Responses=20 > the Reason=20 > > header with an Q.850 Cause makes sense. > >=20 > > There are requirements and three used cases described=20 > within the draft=20 > > so I hope that fits. > >=20 > > Best Regards > >=20 > > Roland > > -----Urspr=FCngliche Nachricht----- > > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Gesendet: Montag, 20. Juli 2009 11:41 > > An: Francois Audet > > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > >=20 > > Hi, > >=20 > > as Francois suggests, a document specifying the use of=20 > Reason header=20 > > fields in responses needs to specify those things (see=20 > Francois' list=20 > > below). Additionally, you should think of whether or not=20 > Reason header=20 > > fields in responses can carry SIP status codes and what happens if=20 > > they are different to the status code of the response. > >=20 > > In short, the document cannot simply say that now it is OK to use=20 > > Reason in responses. It needs to address the different situations a=20 > > typical implementation may face. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > >=20 > > Francois Audet wrote: > > > Again, the spec is very clear that it IS allowed. > > >=20 > > > I believe the wishy-washy text about "status code > > explicitly allowing > > > it" was meant to exclude responses that were not appropriate, and=20 > > > restricing it to effectively error responses. > > >=20 > > > At the time this was written, I believe we were not clear=20 > on which=20 > > > codes were supposed to be appropriate or not. > > >=20 > > > Seems to me: > > > - Any Error response code should be allowed. > > > - I don't think 2XX makes sense. > > > - 3XX is controversial (as per the email quoted by Roland):=20 > > seems to me it > > > would be quite useful > > > - Provisional is interesting... Sounds like 199 error > > response to me... > > >=20 > > >> -----Original Message----- > > >> From: Worley, Dale (BL60:9D30) > > >> Sent: Thursday, July 16, 2009 10:09 > > >> To: Audet, Francois (SC100:3055) > > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > >> > > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > > (SC100:3055) wrote: > > >>> Hi Roland, > > >>> > > >>> You use case is very common. =20 > > >>> > > >>> I believe you are incorrect in saying that "reasons are > > >> currently not > > >>> allowed in responses. Neither conditionally nor allowed". > > >>> > > >>> RFC 3326 says in 1.0: > > >>> "[...] it can appear in any request > > >>> within a dialog, in any CANCEL request and in any > > response whose > > >>> status code explicitly allows the presence of this > > header field." > > >>> > > >>> To be honest, I believe Q.850 codes are much more common in > > >> Responses > > >>> than in requests. > > >> Googling > > >> > > >> "sip/2.0" reason "q.850" > > >> > > >> turns up numerous examples of SIP responses using the > > Reason header > > >> in the forbidden manner. > > >> > > >> I'd say that your draft formally allows what people are > > already doing. > > >> > > >> Dale > > >> > > >> > > >> > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > >=20 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From christer.holmberg@ericsson.com Thu Aug 6 10:52:56 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A673A6B16 for ; Thu, 6 Aug 2009 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQmLhdpLndI2 for ; Thu, 6 Aug 2009 10:52:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 023DB3A697F for ; Thu, 6 Aug 2009 10:52:54 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-f3-4a7b18788079 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 47.44.20235.8781B7A4; Thu, 6 Aug 2009 19:52:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 19:52:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 19:50:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HAC2pAeYAAUVgtgAB0UM7AAGUCS2g== References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> From: "Christer Holmberg" To: , , "Gonzalo Camarillo" X-OriginalArrivalTime: 06 Aug 2009 17:52:56.0426 (UTC) FILETIME=[BAA20CA0:01CA16BE] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 17:52:56 -0000 Hi, =20 >I have added a sentence under section Overall Applicability: > >The appearance of the Reason header is applicable to final responses = 4xx, 5xx and 6xx and in addition for 199 Responses. > >Is this proper enough? Or do you have more in mind? I am ok with the proposed with the text. Maybe you should say "for = provisional 199 responses".=20 I guess it would be good to add a reference to the 199 spec also. Regards, Christer=20 -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com] Gesendet: Mittwoch, 5. August 2009 17:55 An: Christer Holmberg; Jesske, Roland; Gonzalo Camarillo Cc: dispatch@ietf.org Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Yes, I think so. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, August 04, 2009 23:16 > To: Audet, Francois (SC100:3055); R.Jesske@telekom.de; > Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > Hi Francois, > > As you mentioned earlier, it could make sense to allow it in 199. > > Regards, > > Christer > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Tuesday, July 21, 2009 8:34 PM > To: R.Jesske@telekom.de; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > and explain why 3XX, 2XX and 1XX don't make sense. > > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Monday, July 20, 2009 22:03 > > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > Hi Gonzalo, > > Thank you for your comments. > > You are correct. The used cases within the document shows > where ISUP > > causes will be included. > > I think in such cases we should clearly state that SIP > Reason should > > be excluded within SIP responses, to avoid contradictions. > > > > Then I will include that only within 4xx/5xx/6xx Responses > the Reason > > header with an Q.850 Cause makes sense. > > > > There are requirements and three used cases described > within the draft > > so I hope that fits. > > > > Best Regards > > > > Roland > > -----Urspr=FCngliche Nachricht----- > > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Gesendet: Montag, 20. Juli 2009 11:41 > > An: Francois Audet > > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > Hi, > > > > as Francois suggests, a document specifying the use of > Reason header > > fields in responses needs to specify those things (see > Francois' list > > below). Additionally, you should think of whether or not > Reason header > > fields in responses can carry SIP status codes and what happens if > > they are different to the status code of the response. > > > > In short, the document cannot simply say that now it is OK to use > > Reason in responses. It needs to address the different situations a > > typical implementation may face. > > > > Cheers, > > > > Gonzalo > > > > > > Francois Audet wrote: > > > Again, the spec is very clear that it IS allowed. > > > > > > I believe the wishy-washy text about "status code > > explicitly allowing > > > it" was meant to exclude responses that were not appropriate, and > > > restricing it to effectively error responses. > > > > > > At the time this was written, I believe we were not clear > on which > > > codes were supposed to be appropriate or not. > > > > > > Seems to me: > > > - Any Error response code should be allowed. > > > - I don't think 2XX makes sense. > > > - 3XX is controversial (as per the email quoted by Roland): > > seems to me it > > > would be quite useful > > > - Provisional is interesting... Sounds like 199 error > > response to me... > > > > > >> -----Original Message----- > > >> From: Worley, Dale (BL60:9D30) > > >> Sent: Thursday, July 16, 2009 10:09 > > >> To: Audet, Francois (SC100:3055) > > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > >> > > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > > (SC100:3055) wrote: > > >>> Hi Roland, > > >>> > > >>> You use case is very common.=20 > > >>> > > >>> I believe you are incorrect in saying that "reasons are > > >> currently not > > >>> allowed in responses. Neither conditionally nor allowed". > > >>> > > >>> RFC 3326 says in 1.0: > > >>> "[...] it can appear in any request > > >>> within a dialog, in any CANCEL request and in any > > response whose > > >>> status code explicitly allows the presence of this > > header field." > > >>> > > >>> To be honest, I believe Q.850 codes are much more common in > > >> Responses > > >>> than in requests. > > >> Googling > > >> > > >> "sip/2.0" reason "q.850" > > >> > > >> turns up numerous examples of SIP responses using the > > Reason header > > >> in the forbidden manner. > > >> > > >> I'd say that your draft formally allows what people are > > already doing. > > >> > > >> Dale > > >> > > >> > > >> > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ian.elz@ericsson.com Mon Aug 10 05:56:53 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A7E3A6C10 for ; Mon, 10 Aug 2009 05:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KQZCeXrVGUC for ; Mon, 10 Aug 2009 05:56:52 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 158F73A6A20 for ; Mon, 10 Aug 2009 05:56:51 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-14-4a8019161f6b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id FF.C9.18827.619108A4; Mon, 10 Aug 2009 14:56:54 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 14:56:54 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA19BA.08DC401E" Date: Mon, 10 Aug 2009 14:56:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-yu-tel-dai-07 Thread-Index: AcoZugjaC7keFvkoTBO9F/RSriqP1A== From: "Ian Elz" To: , , X-OriginalArrivalTime: 10 Aug 2009 12:56:54.0131 (UTC) FILETIME=[0921EC30:01CA19BA] X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org Subject: [dispatch] draft-yu-tel-dai-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 12:56:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA19BA.08DC401E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, David, Flemming, [I have copied this to the dispatch list for further comments. The iptel wg for which this draft was originally written has been closed.] We have been looking at the definition of the parameter values defined in your draft: dai =3D ";dai=3D" dai_value dai-value =3D "no-ind" / "presub" / "presub-da" / "presub-daUnkwn" / "da" / "CIC-chrgPty" / "altCIC-chrgPty" / "verbal-clgPty" / "verbal-chrgPty" / "emergency" / "presubUnkwn-da" / "operator" / pvalue We are concerned that you have specified mixed case in the values. The issues arise from the requirements for comparison on tel (RFC 3966) and sip (RFC3261). RFC 3966 states: "URI comparisons are case-insensitive" and goes on to state "All parameter names and values SHOULD use lower-case characters, as tel URIs may be used within contexts where comparisons are case sensitive." RFC 3261 states: "Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise. I would suggest that you align your dai-values with the recommendation in RFC 3966 to make all the values lower case. If there is a specific requirement to make these values mixed case then you should specify that them as being case sensitive in the draft. Unfortunately we are stuck with the wider issue that tel parameters are case insensitive when comparing tel URIs but are case sensitive if the tel URI has been converted to sip URI before the comparison. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 118 9024948 ian.elz@ericsson.com ------_=_NextPart_001_01CA19BA.08DC401E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-yu-tel-dai-07

James, David, Flemming,

[I have copied this to the dispatch = list for further comments. The iptel wg for which this draft was = originally written has been closed.]

We have been looking at the definition = of the parameter values defined in your draft:

         = dai        =3D = ";dai=3D"  dai_value
         dai-value  =3D = "no-ind"         &= nbsp; /
            &= nbsp;         = "presub"         &= nbsp; /
            &= nbsp;         = "presub-da"        /
            &= nbsp;         = "presub-daUnkwn"   /
            &= nbsp;         = "da"          = ;     /
            &= nbsp;         = "CIC-chrgPty"      /
            &= nbsp;         = "altCIC-chrgPty"   /
            &= nbsp;         = "verbal-clgPty"    /
            &= nbsp;         = "verbal-chrgPty"   /
            &= nbsp;         = "emergency"        /
            &= nbsp;         = "presubUnkwn-da"   /
            &= nbsp;         = "operator"         = /
            &= nbsp;         pvalue

We are concerned that you have = specified mixed case in the values.

The issues arise from the requirements = for comparison on tel (RFC 3966) and sip (RFC3261).

    RFC 3966 states: "URI comparisons = are case-insensitive" and goes on to state "All parameter = names and values SHOULD use lower-case characters, as tel URIs may be = used within contexts where comparisons are case = sensitive."

    RFC 3261 states: "Comparison of = the userinfo of SIP and SIPS URIs is case-sensitive. This includes = userinfo containing passwords or formatted as telephone-subscribers. = Comparison of all other components of the URI is case-insensitive unless = explicitly defined otherwise.

I would suggest that you align your = dai-values with the recommendation in RFC 3966 to make all the values = lower case. If there is a specific requirement to make these values = mixed case then you should specify that them as being case sensitive in = the draft.

Unfortunately we are stuck with the = wider issue that tel parameters are case insensitive when comparing tel = URIs but are case sensitive if the tel URI has been converted to sip URI = before the comparison.



Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 118 9024948
ian.elz@ericsson.com

------_=_NextPart_001_01CA19BA.08DC401E-- From AUDET@nortel.com Tue Aug 11 14:17:44 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147E028C117 for ; Tue, 11 Aug 2009 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYQ4860aOQXF for ; Tue, 11 Aug 2009 14:17:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B01573A68F2 for ; Tue, 11 Aug 2009 14:17:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7BLEGr04352; Tue, 11 Aug 2009 21:14:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 16:16:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F69EE25@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 Thread-Index: AcoJHi+ROLPVUN7URFqcaM3kAonJJAAoLukwABqf5HAC2pAeYAAUVgtgAB0UM7AAGUCS2gECpfIA References: <9886E5FCA6D76549A3011068483A4BD40498CFB8@S4DE8PSAAQB.mitte.t-com.de> <1246894612.3747.17.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD40498D2CA@S4DE8PSAAQB.mitte.t-com.de> <1247255492.3757.40.camel@victoria-pingtel-com.us.nortel.com> <9886E5FCA6D76549A3011068483A4BD404A14E83@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F050471@zrc2hxm0.corp.nortel.com> <1247764118.4085.24.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1F05050C@zrc2hxm0.corp.nortel.com><4A643B95.3060800@ericsson.com><9886E5FCA6D76549A3011068483A4BD404A9C2B7@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F155AC5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1F556A65@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404BFFC37@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: "Christer Holmberg" , , "Gonzalo Camarillo" Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:17:44 -0000 Yep, sounds good.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, August 06, 2009 10:50 > To: R.Jesske@telekom.de; Audet, Francois (SC100:3055);=20 > Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Hi, > =20 > >I have added a sentence under section Overall Applicability: > > > >The appearance of the Reason header is applicable to final=20 > responses 4xx, 5xx and 6xx and in addition for 199 Responses. > > > >Is this proper enough? Or do you have more in mind? >=20 > I am ok with the proposed with the text. Maybe you should say=20 > "for provisional 199 responses".=20 >=20 > I guess it would be good to add a reference to the 199 spec also. >=20 > Regards, >=20 > Christer=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com] > Gesendet: Mittwoch, 5. August 2009 17:55 > An: Christer Holmberg; Jesske, Roland; Gonzalo Camarillo > Cc: dispatch@ietf.org > Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 >=20 > Yes, I think so. >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, August 04, 2009 23:16 > > To: Audet, Francois (SC100:3055); R.Jesske@telekom.de; Gonzalo=20 > > Camarillo > > Cc: dispatch@ietf.org > > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > > > Hi Francois, > > > > As you mentioned earlier, it could make sense to allow it in 199. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > > Sent: Tuesday, July 21, 2009 8:34 PM > > To: R.Jesske@telekom.de; Gonzalo Camarillo > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > and explain why 3XX, 2XX and 1XX don't make sense. > > > > > -----Original Message----- > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > Sent: Monday, July 20, 2009 22:03 > > > To: Gonzalo.Camarillo@ericsson.com; Audet, Francois (SC100:3055) > > > Cc: Worley, Dale (BL60:9D30); dispatch@ietf.org > > > Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > > > Hi Gonzalo, > > > Thank you for your comments. > > > You are correct. The used cases within the document shows > > where ISUP > > > causes will be included. > > > I think in such cases we should clearly state that SIP > > Reason should > > > be excluded within SIP responses, to avoid contradictions. > > > > > > Then I will include that only within 4xx/5xx/6xx Responses > > the Reason > > > header with an Q.850 Cause makes sense. > > > > > > There are requirements and three used cases described > > within the draft > > > so I hope that fits. > > > > > > Best Regards > > > > > > Roland > > > -----Urspr=FCngliche Nachricht----- > > > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > Gesendet: Montag, 20. Juli 2009 11:41 > > > An: Francois Audet > > > Cc: Dale Worley; dispatch@ietf.org; Jesske, Roland > > > Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > > > > Hi, > > > > > > as Francois suggests, a document specifying the use of > > Reason header > > > fields in responses needs to specify those things (see > > Francois' list > > > below). Additionally, you should think of whether or not > > Reason header > > > fields in responses can carry SIP status codes and what=20 > happens if=20 > > > they are different to the status code of the response. > > > > > > In short, the document cannot simply say that now it is OK to use=20 > > > Reason in responses. It needs to address the different=20 > situations a=20 > > > typical implementation may face. > > > > > > Cheers, > > > > > > Gonzalo > > > > > > > > > Francois Audet wrote: > > > > Again, the spec is very clear that it IS allowed. > > > > > > > > I believe the wishy-washy text about "status code > > > explicitly allowing > > > > it" was meant to exclude responses that were not=20 > appropriate, and=20 > > > > restricing it to effectively error responses. > > > > > > > > At the time this was written, I believe we were not clear > > on which > > > > codes were supposed to be appropriate or not. > > > > > > > > Seems to me: > > > > - Any Error response code should be allowed. > > > > - I don't think 2XX makes sense. > > > > - 3XX is controversial (as per the email quoted by Roland): > > > seems to me it > > > > would be quite useful > > > > - Provisional is interesting... Sounds like 199 error > > > response to me... > > > > > > > >> -----Original Message----- > > > >> From: Worley, Dale (BL60:9D30) > > > >> Sent: Thursday, July 16, 2009 10:09 > > > >> To: Audet, Francois (SC100:3055) > > > >> Cc: R.Jesske@telekom.de; dispatch@ietf.org > > > >> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04 > > > >> > > > >> On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois > > > (SC100:3055) wrote: > > > >>> Hi Roland, > > > >>> > > > >>> You use case is very common.=20 > > > >>> > > > >>> I believe you are incorrect in saying that "reasons are > > > >> currently not > > > >>> allowed in responses. Neither conditionally nor allowed". > > > >>> > > > >>> RFC 3326 says in 1.0: > > > >>> "[...] it can appear in any request > > > >>> within a dialog, in any CANCEL request and in any > > > response whose > > > >>> status code explicitly allows the presence of this > > > header field." > > > >>> > > > >>> To be honest, I believe Q.850 codes are much more common in > > > >> Responses > > > >>> than in requests. > > > >> Googling > > > >> > > > >> "sip/2.0" reason "q.850" > > > >> > > > >> turns up numerous examples of SIP responses using the > > > Reason header > > > >> in the forbidden manner. > > > >> > > > >> I'd say that your draft formally allows what people are > > > already doing. > > > >> > > > >> Dale > > > >> > > > >> > > > >> > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 >=20 From ranjit@motorola.com Mon Aug 17 00:07:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABF63A6950; Mon, 17 Aug 2009 00:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4M0t9v4hxny; Mon, 17 Aug 2009 00:07:25 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 0884F3A684F; Mon, 17 Aug 2009 00:07:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1250492844!33537358!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 671 invoked from network); 17 Aug 2009 07:07:24 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Aug 2009 07:07:24 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7H77N93000451; Mon, 17 Aug 2009 00:07:23 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n7H77N1Y014207; Mon, 17 Aug 2009 02:07:23 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7H77M57014195; Mon, 17 Aug 2009 02:07:22 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F09.50BDCE43" Date: Mon, 17 Aug 2009 15:06:59 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6A References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Subject: [dispatch] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 07:07:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1F09.50BDCE43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All=20 We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt =20 This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604.=20 Please review and comment Regards=20 Ranjit=20 ------_=_NextPart_001_01CA1F09.50BDCE43 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of = "draft-avasasarala-dispatch-comm-diversion-info" draft submitted
Hi All=20

We have submitted an = updated version of=20 draft-avasasarala-dispatch-comm-diversion-info

It can be accessed = at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-com= m-div-notification-01.txt

This draft = proposes a SIP=20 Event package for Communication Diversions Notification Information and = conforms=20 to procedures and schema described in 3GPP TS 24.604. 

Please review and=20 comment

Regards
Ranjit

------_=_NextPart_001_01CA1F09.50BDCE43-- From gshaham@juniper.net Mon Aug 17 17:20:35 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8527B28C1B7; Mon, 17 Aug 2009 17:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9LjhfcMLBih; Mon, 17 Aug 2009 17:20:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 352B03A687B; Mon, 17 Aug 2009 17:20:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSonz0oQP8vKoZImzDWvMuoyA6gOdVEG3@postini.com; Mon, 17 Aug 2009 17:20:35 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.375.2; Mon, 17 Aug 2009 17:20:16 -0700 Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 01:20:14 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F99.A7AF652F" Date: Tue, 18 Aug 2009 01:20:10 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6AACM0FAA= References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> From: Gilad Shaham To: "Avasarala Ranjit-A20990" , , X-OriginalArrivalTime: 18 Aug 2009 00:20:14.0071 (UTC) FILETIME=[A7E48870:01CA1F99] X-Mailman-Approved-At: Mon, 17 Aug 2009 17:46:37 -0700 Subject: Re: [dispatch] [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 00:20:35 -0000 ------_=_NextPart_001_01CA1F99.A7AF652F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 See some comments =20 Page 5: "... For e.g. the subscriber wanted to diverted all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m" Some of the sentence needs restructuring and I also don't fully understand the example. Is it AM-PM or wrong field was configured? =20 Page 12: What if time-range is missing? What should be the default? Sounds to me the default should be the current time with no end date. =20 Page 14: In Comm-div-info-selection-criteria there are several disable-* subsections, yet their text describes these element gives the subscriber option of adding information. Shouldn't this be for omitting information or alternatively, call these elements "enable-*" or did I misunderstand the purpose. =20 Page 16: Boss Should be Boss It might be also useful to see an example of periodic request. =20 Page 21: 503 is there, but I don't see 500. Some implementations will avoid 503 and use 500 due to discussion related to this http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able to think of some scenario that involves 502, but I assume this is a result of the diversion implementation itself so maybe that's the context of this discussion. =20 Thanks Gilad =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, August 17, 2009 10:07 AM To: dispatch@ietf.org; sip@ietf.org Subject: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted =20 Hi All=20 We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt =20 This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604.=20 Please review and comment Regards=20 Ranjit=20 ------_=_NextPart_001_01CA1F99.A7AF652F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of "draft-avasasarala-dispatch-comm-diversion-info" draft = submitted

Hi,

 

See some = comments

 

Page = 5:

   “... For e.g. the =
subscriber wanted to diverted all incoming calls to =
voice-mail,
   between 3.00 p.m. to 4.00 =
p.m.  Yet, by mistake she configures =
the
   time-duration as 3.00 to 4.00 =
p.m”

Some of the sentence needs = restructuring and I also don’t fully understand the example. Is it AM-PM or = wrong field was configured?

 

Page = 12:

What if time-range is missing? What = should be the default? Sounds to me the default should be the current time with = no end date.

 

Page = 14:

In Comm-div-info-selection-criteria = there are several disable-* subsections, yet their text describes these = element gives the subscriber option of adding information. Shouldn’t this be for omitting information or alternatively, call these elements = “enable-*” or did I misunderstand the purpose.

 

Page = 16:

       &nbs=
p;     =
<user-name>Boss</originating-user-name>

Should = be

       &nbs=
p;     =
<user-name>Boss</user-name>

It might be also useful to see an = example of periodic request.

 

Page = 21:

503 is there, but I don’t see = 500. Some implementations will avoid 503 and use 500 due to discussion = related to this http= ://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able = to think of some scenario that involves 502, but I assume this is a result = of the diversion implementation itself so maybe that’s the context of = this discussion.

 

Thanks

Gilad

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990
Sent: Monday, August 17, = 2009 10:07 AM
To: dispatch@ietf.org; sip@ietf.org
Subject: [Sip] New = version of"draft-avasasarala-dispatch-comm-diversion-info" draft = submitted

 

Hi All =

We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info =

It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm= -div-notification-01.txt

This draft proposes a SIP Event package for = Communication Diversions Notification Information and conforms to procedures and = schema described in 3GPP TS 24.604. 

Please review and comment

Regards
Ranjit

------_=_NextPart_001_01CA1F99.A7AF652F-- From volkerh@bell-labs.com Thu Aug 20 06:52:38 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633FE3A6B78; Thu, 20 Aug 2009 06:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KwzazV5ThTn; Thu, 20 Aug 2009 06:52:37 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6D6B43A695E; Thu, 20 Aug 2009 06:52:36 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7KDqdZf009272; Thu, 20 Aug 2009 08:52:39 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n7KDqc6Y022893; Thu, 20 Aug 2009 08:52:39 -0500 (CDT) Received: from [127.0.0.1] (135.3.63.243) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 20 Aug 2009 08:52:38 -0500 Message-ID: <4A8D551B.7060308@alcatel-lucent.com> Date: Thu, 20 Aug 2009 09:52:27 -0400 From: Volker Hilt User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: DISPATCH , SIP-OVERLOAD Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [dispatch] Revised Charter Proposal for SIP Overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 13:52:38 -0000 All, below is an revised SIP Overload Control charter proposal. I have received a few comments that are reflected in the new proposal. All comments, thoughts, feedback is very welcome! Thanks, Volker SIP Overload Control WG Charter ------------------------------- As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to process all incoming SIP messages. These resources can include CPU, memory, network bandwidth, input/output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the proposed working group is to develop mechanisms for SIP overload control. Two complementary approaches exist for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. Specifically, the proposed working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. From mary.barnes@nortel.com Thu Aug 20 14:28:51 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17863A6C23 for ; Thu, 20 Aug 2009 14:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehDbMnV1BBgG for ; Thu, 20 Aug 2009 14:28:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EE9AA3A6F28 for ; Thu, 20 Aug 2009 14:28:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7KLSou26261 for ; Thu, 20 Aug 2009 21:28:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA21DD.291C82D7" Date: Thu, 20 Aug 2009 16:30:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F917A4C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-75 Meeting Minutes Thread-Index: Acoh3XzWbk6OeLpcQWiy6vmRPB0X5A== From: "Mary Barnes" To: Subject: [dispatch] IETF-75 Meeting Minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 21:28:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA21DD.291C82D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The meeting minutes for the IETF-75 DISPATCH WG session and CLF adhoc are now available in the IETF-75 Proceedings: http://www.ietf.org/proceedings/75/minutes/dispatch.html Please review and let me know no later than Sept. 10th (2 weeks time) if you see any errors or omissions. =20 Regards, Mary H. Barnes DISPATCH WG co-chair ------_=_NextPart_001_01CA21DD.291C82D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF-75 Meeting Minutes

Hi all,

The meeting minutes for the IETF-75 = DISPATCH WG session and CLF adhoc are now available in the IETF-75 = Proceedings:
http://www.ietf.org/proceedings/75/minutes/dispatch.html

Please review and let me know no later = than Sept. 10th (2 weeks time) if you see any errors or omissions.  =

Regards,
Mary H. Barnes
DISPATCH WG co-chair

------_=_NextPart_001_01CA21DD.291C82D7-- From mary.barnes@nortel.com Fri Aug 21 09:23:00 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1E83A6B9E for ; Fri, 21 Aug 2009 09:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktq6lbKRVdng for ; Fri, 21 Aug 2009 09:22:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A3C233A6999 for ; Fri, 21 Aug 2009 09:22:59 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7LGKu029173; Fri, 21 Aug 2009 16:20:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA227B.A4A94747" Date: Fri, 21 Aug 2009 11:25:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-76 DISPATCH WG deadlines Thread-Index: AcohwNkciiguS2xuQiuKUNJpbaNnbQAuvWPQ From: "Mary Barnes" To: Cc: rai-ads@tools.ietf.org Subject: [dispatch] IETF-76 DISPATCH WG deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:23:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA227B.A4A94747 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi all, >=20 > As was done for IETF-75, we are setting earlier deadlines for > discussing topics in DISPATCH prior to the WG session at IETF-76. =20 >=20 > We will again follow the deadlines for BoFs: > http://www.ietf.org/meeting/cutoff-dates.html#76 >=20 > This provides enough time to dispatch topics prior to the meeting as > appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs, > mailing lists, etc. Thus, allowing us to have more focused and > constructive discussions on a smaller set of topics prior to the WG > session.=20 >=20 > Please note that the dates are much sooner than you might expect as > the time between IETF-75 and IETF-76 is 3 weeks less than the time > between IETF-74 and IETF-75. The document deadlines are 9 and 10 weeks > away from next Monday (August 24th). =20 >=20 >=20 > Thus, the following are the proposed deadlines: >=20 > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG mailing > list of plans to submit a proposal. > ---------------------------------------------------------------------- > ----------------------------------=20 >=20 > This will help folks with similar topics to work together before the > meeting. If a preliminary charter proposal is available at this point, > please include it. >=20 >=20 > September 21st - Cutoff for charter proposals for topics.=20 > -------------------------------------------------------- >=20 > A charter proposal must consist of a minimum of a problem statement > and at least one milestone/deliverable. This deadline will allow time > for consideration of proposals that could potentially be "dispatched" > prior to the WG session. >=20 >=20 > September 28th - Topics that are to be the focus of IETF-76 are > announced.=20 > ---------------------------------------------------------------------- > -----=20 >=20 > The idea here is to focus the discussion over the weeks preceding > IETF-76 on these main topics, noting that any new or updates to any > documents are due 3-4 weeks later. This will ensure we have > constructive discussions before the meeting and are actually able to > determine consensus as to where work should be progressed (e.g., > separate BoF, a new WG, an existing WG, individual document, etc.) at > IETF-76. Note, that the exact disposition for a topic may (per the > usual process) require follow-up and confirmation by the ADS and/or > IESG (e.g., for a new WG, Bof, individually sponsored document, etc.) > or with another WG to ensure agreement with the DISPATCH WG consensus > for the topic. >=20 >=20 > As discussed previously, the intention is not necessarily to preclude > folks submitting documents on other topics, however, it is very > unlikely there would be agenda time allocated to documents/topics > submitted after the deadlines. We can include one or two slides on > these topics in the DISPATCH WG chair charts so that the authors can > gather other interested parties to contribute to the work.=20 >=20 > Regards, > Mary and Gonzalo > DISPATCH WG co-chairs=20 >=20 ------_=_NextPart_001_01CA227B.A4A94747 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF-76 DISPATCH WG deadlines

Hi all,

As was done for IETF-75, we are = setting earlier deadlines for discussing topics in DISPATCH prior to the = WG session at IETF-76. 

We will again follow the = deadlines for BoFs:
http://www.ietf.org/meeting/cutoff-dates.html#76

This provides enough time to = dispatch topics prior to the meeting as appropriate - e.g., mini-bofs, = official bofs, other WGs, new WGs,  mailing lists, etc. Thus, = allowing us to have more focused and constructive discussions on a = smaller set of topics prior to the WG session.

Please note that the dates are = much sooner than you might expect as the time between IETF-75 and = IETF-76 is 3 weeks less than the time between IETF-74 and IETF-75. The = document deadlines are 9 and 10 weeks away from next Monday (August = 24th). 


Thus, the following are the = proposed deadlines:

Sept 7th  - Cutoff date to = notify the chairs and DISPATCH WG mailing list of plans to submit a = proposal.
--------------------------------------------------------------------= ------------------------------------

This will help folks with similar = topics to work together before the meeting. If a preliminary charter = proposal is available at this point, please include it.


September 21st - Cutoff for = charter proposals for topics.
--------------------------------------------------------

A charter proposal must consist = of a minimum of a problem statement and at least one = milestone/deliverable. This deadline will allow time for consideration = of proposals that could potentially be "dispatched" prior to = the WG session.


September 28th - Topics that are = to be the focus of IETF-76 are announced.
--------------------------------------------------------------------= -------

The idea here is to focus the = discussion over the weeks preceding IETF-76 on these main topics, noting = that any new or updates to any documents are due 3-4 weeks later.  = This will ensure we have constructive discussions before the meeting and = are actually able to determine consensus as to where work should be = progressed (e.g., separate BoF, a new WG, an existing WG, individual = document, etc.) at IETF-76. Note, that the exact disposition for a topic = may (per the usual process) require follow-up and confirmation by the = ADS and/or IESG (e.g., for a new WG, Bof, individually sponsored = document, etc.) or with another WG to ensure agreement with the DISPATCH = WG consensus for the topic.


As discussed previously, the = intention is not necessarily to preclude folks submitting documents on = other topics, however, it is very unlikely there would be agenda time = allocated to documents/topics submitted after the deadlines. We can = include one or two slides on these topics in the DISPATCH WG chair = charts so that the authors can gather other interested parties to = contribute to the work.

Regards,
Mary and Gonzalo
DISPATCH WG co-chairs

------_=_NextPart_001_01CA227B.A4A94747-- From mary.barnes@nortel.com Fri Aug 21 11:43:01 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A8928C264 for ; Fri, 21 Aug 2009 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovlRgkalzXNt for ; Fri, 21 Aug 2009 11:42:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id ED41B28C257 for ; Fri, 21 Aug 2009 11:42:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7LIgoj06688 for ; Fri, 21 Aug 2009 18:42:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 13:45:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F9185A1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of DISPATCH ML topics after IETF-75 deadline Thread-Index: Acoij32v7lg8t5IoQnK7X/f5pY/j8A== From: "Mary Barnes" To: Subject: [dispatch] Summary of DISPATCH ML topics after IETF-75 deadline X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:43:01 -0000 Hi all, Here's a summary of topics for which there has been discussion on the mailing list since the IETF-75 deadline, along with an indication of the level of discussion and interest. Per the email with regards to IETF-76 deadlines, the authors/primes for these topics need to let the chairs know if you still plan on working on the topic. Any updates to proposed charters, problem statements and milestones are due no later than Sept 21st (4 weeks time).=20 1) Disaggregated media: Discussion/interest: High. Status: ML.=20 2) HTTP suscribe: draft-roach-sip-http-subscribe. Discussion/interest: medium Status: ML=20 3) Identity: draft-elwell-dispatch-identity-reqs. Discussion low. John is actively soliciting feedback=20 4) Implicit Registration: draft-kaplan-dispatch-sip-implicit-registration. Discussion: Low - some interest.=20 5) Interaction Indication: draft-shen-interaction-ind. Discussion: very low - only feedback indicates it's not needed.=20 6) Interop BCP: draft-kaplan-sipping-interop-bcp Discussion: medium=20 7) NGN reason (hdr in responses): draft-jesske-sipping-etsi-ngn-reason Discussion: High.=20 8) Overload. Discussion: low. Status: Charter proposal and ML.=20 9) Pre-conditions: draft-mdolly-dispatch-oma-push-00.txt Discussion: Low 10) Text conferencing: draft-hellstrom-text-turntaking, draft-hellstrom-textpreview, draft-hellstrom-txtgwy Discussion: None. These documents need to be carefully considered as they cover a broad range of RAI working groups.=20 11) ANAT: draft-boucadair-mmusic-ccap-00. Discussion: None.=20 Post-IETF-75 docs:=20 1) OMA push: draft-mdolly-dispatch-oma-push-00.txt Discussion/interest: None. Note: OMA liaison=20 2) V6 atypes: draft-boucadair-dispatch-ipv6-atypes Discussion/interest: None. Regards, Mary and Gonzalo DISPATCH WG co-chairs From vkg@alcatel-lucent.com Mon Aug 24 09:17:39 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5942728C28A for ; Mon, 24 Aug 2009 09:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoLsKiVDJGdb for ; Mon, 24 Aug 2009 09:17:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 4CFF328C259 for ; Mon, 24 Aug 2009 09:17:37 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n7OGHgTo012366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Aug 2009 11:17:42 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7OGHgcE020882 for ; Mon, 24 Aug 2009 11:17:42 -0500 (CDT) Message-ID: <4A92BD25.4090105@alcatel-lucent.com> Date: Mon, 24 Aug 2009 11:17:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [dispatch] IETF 75: Integrated audio, slides, minutes, and drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:17:39 -0000 Folks: The integrated audio/slides/minuets/drafts for the DISPATCH WG in Stockholm are now available at the following URL: http://www.softarmor.com/dispatch/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From JOHNAT@nortel.com Tue Aug 25 07:15:28 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388D53A6F53 for ; Tue, 25 Aug 2009 07:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.068 X-Spam-Level: X-Spam-Status: No, score=-6.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q0=0.303, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwDPH8UMqKlG for ; Tue, 25 Aug 2009 07:15:27 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C108B3A6EDA for ; Tue, 25 Aug 2009 07:15:26 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7PEDMH00269 for ; Tue, 25 Aug 2009 14:13:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA258E.7E8B7159" Date: Tue, 25 Aug 2009 10:15:25 -0400 Message-ID: <549FD0754C7E1D468D93A34B42AC5F92156BB54D@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks Thread-Index: AclOk7JwjC6CKQbIRUOsEdfs75dh2gDAuj0wAABfPZA00I4zAAAsibrQAABG87A= From: "John Atkinson" To: Subject: [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:15:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA258E.7E8B7159 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks =20 =20 ITU SG16 has developed a framework for coordination of voice quality signal processing in networks that have more than one network element capable of doing specific voice quality signal processing functions. This framework was developed to allow optimal placement of the VQSP functions within the network and avoid voice quality degradation due to undesirable side-effects of the interaction of the individual voice quality enhancement functions and to improve voice quality by only applying a given VQ function in one location in the network. =20 =20 =20 =20 The five voice quality signal processing features commonly applied are=20 =20 * Echo Control (control of echo from a hybrid) * Acoustic Echo Control * Automatic Gain Control * Feedback Gain Control * Background Noise Reduction =20 A Node can potentially be capable of applying each of the above five VQSP functions in each of the two directions of a voice path. Doing both Echo control and Acoustic echo control on the same signal is not desirable or necessary nor is applying both automatic gain control and feedback gain control on the same signal desirable or necessary. In addition, it's usually optimal to do echo control as close to the echo source as possible.=20 =20 This ITU work has not defined the actual method by which network elements can communicate which VQ functions are enabled or present in the network and in which direction they are capable of being applied. ITU has sent a Liason Statement to IETF requesting assistance defining how VoIP nodes communicate VQSP capability/state information to other nodes.=20 =20 =20 For Echo Control , VoIP implementors are currently aware of two existing methods of communicating between nodes that echo cancellation is being done. In ISUP, the Echo control device indicator in the Nature of Connection Indicators IE is used to indicate the presence of an echo control device in the forward direction and the Echo Control device Indicator in the Backwards Call Indicators IE is used to indcate the presence on an echo control device in the backwards direction. RFC 3108 defines a session description protocol attribute line for echo control.=20 =20 a=3Decan: which can be used to indicate the presence of G.165/G.168 echo cancellers in one or both directions.=20 =20 =20 In addition, RFC 3108 defines an attribute line for gain control=20 =20 a=3Dgc: =20 which can be used to indicate the presence gain control in one or both directions=20 =20 =20 It would be beneficial for the Dispatch WG to review the ITU Liason Statement (which can be viewed at https://datatracker.ietf.org/liaison/505/ ) and discuss the best method of communicating VQSP functions between nodes . Possible solutions include using SDP, SIP headers, RTP, RTCP, or some new on-path control protocol. =20 =20 John Atkinson johnat@nortel.com ------_=_NextPart_001_01CA258E.7E8B7159 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Optimal placement=20 of Voice Quality Signal Processing (VQSP) features within=20 Networks
 
 
ITU SG16 has developed a framework for = coordination=20 of voice quality signal processing in networks that have more than one = network=20 element capable of doing specific voice quality signal processing=20 functions. This framework was developed to allow optimal placement of = the VQSP=20 functions within the network and avoid voice quality degradation due to undesirable = side-effects of=20 the interaction of the individual voice quality enhancement functions = and to=20 improve voice quality by only applying a given VQ function in one = location=20 in the network.  
 
 
 
The five = voice quality signal=20 processing features commonly = applied=20 are
 
·        =20 Echo Control (control of echo from a=20 hybrid)
·        =20 Acoustic Echo Control
·        =20 Automatic Gain Control
·        =20 Feedback Gain = Control
·        =20 Background Noise = Reduction
 
A = Node can=20 potentially be capable of applying each of the above five VQSP functions in each of = the two=20 directions of a voice path. Doing = both Echo=20 control and Acoustic echo control on the same signal is not desirable or = necessary nor is applying both automatic gain control and feedback gain = control=20 on the same signal desirable or necessary. In addition, it's usually = optimal to=20 do echo control as close to the echo source as possible.=20
 
This ITU work has not defined the actual = method by=20 which network elements can communicate which VQ functions are enabled or = present=20 in the network and in which direction they are capable of being applied. = ITU has sent a=20 Liason Statement to IETF requesting assistance defining how VoIP=20 nodes communicate VQSP capability/state information to other nodes. =
 
 
For Echo Control ,  VoIP=20 implementors are currently aware of two existing = methods of=20 communicating between nodes that echo cancellation is being done. In = ISUP, the=20 Echo control device indicator in the Nature of Connection Indicators IE = is=20 used to indicate the presence of an echo control device in the = forward=20 direction and the Echo Control device Indicator in the Backwards Call = Indicators=20 IE is used to indcate the presence on an echo control device in the = backwards=20 direction. RFC 3108 defines a session description protocol attribute = line for=20 echo control.
 
a=3Decan:<directionFlag><ecanEnable><ecanType>=
which can be used to indicate the presence of G.165/G.168 echo = cancellers=20 in one or both directions.
 
 
In addition, RFC 3108 defines an attribute line for gain = control=20
 
 a=3Dgc:<directionFlag><gcEnable><gcLvl&= gt;
  
which can be used to indicate the presence gain control in one = or both=20 directions
 
 
 It = would be=20 beneficial for the Dispatch WG to review  the ITU Liason = Statement  (which can be viewed = at  https://datatracker.ie= tf.org/liaison/505/ )=20 and discuss the best method of communicating VQSP functions  between nodes .  Possible solutions = include using SDP,=20 SIP headers, RTP, RTCP, or some new on-path control=20 protocol.
 
 
John = Atkinson
johnat@nortel.com
------_=_NextPart_001_01CA258E.7E8B7159-- From Mike.Szilagyi@inin.com Wed Aug 26 14:10:59 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E353A69AA; Wed, 26 Aug 2009 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ifIo9tlESch; Wed, 26 Aug 2009 14:10:56 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id 0B6623A6781; Wed, 26 Aug 2009 14:10:55 -0700 (PDT) Received: from ININHUB1 [172.16.1.156] by smtpgw.inin.com - Websense Email Security (6.1.1); Wed, 26 Aug 2009 17:10:38 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub1.i3domain.inin.com ([172.16.1.156]) with mapi; Wed, 26 Aug 2009 17:10:38 -0400 From: "Szilagyi, Mike" To: "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Wed, 26 Aug 2009 17:10:37 -0400 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_" MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2009_08_26_17_10_38 Subject: [dispatch] Requests sent within early dialog -- CSeq mgmt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 21:10:59 -0000 --_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've not been able to find definitive text regarding this issue so I'm hopi= ng someone can provide clarification. If a request (INFO or UPDATE) is sen= t on a dialog in the early state, how are the CSeq numbers managed by the U= AS. Here's an example to demonstrate my confusion: UAC UAS INVITE CSeq 1 ---------> <----- 100 Trying Remote CSeq =3D 1 UPDATE CSeq 2 ---------> <-- 200 OK (UPDATE) Remote CSeq =3D 2 CANCEL CSeq 1 ---------> Rejected CSeq < 2 is there text that describes the handling of CSeq numbers for requests sent= within another request for the same dialog? Thanks in advance. Mike --_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve not been able to find definitive text regar= ding this issue so I’m hoping someone can provide clarification.  If = a request (INFO or UPDATE) is sent on a dialog in the early state, how are th= e CSeq numbers managed by the UAS.  Here’s an example to demonstra= te my confusion:

 

UAC  &n= bsp;          UAS

 INVITE=

 CSeq 1= --------->  

 <= /o:p>

 <--= --- 100 Trying   Remote CSeq =3D 1

 <= /o:p>

 UPDATE=

 CSeq 2 --------->  

 <= /o:p>

 <--= 200 OK (UPDATE) Remote CSeq =3D 2

 <= /o:p>

 <= /o:p>

 CANCEL=

 CSeq 1 --------->   Rejected CSeq < 2

 

 

is there text that describes the handling of CSeq numb= ers for requests sent within another request for the same dialog?

 

Thanks in advance.

 

Mike

--_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_-- From Bala_Neelakantan@Quintum.com Wed Aug 26 14:45:41 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044803A70DA; Wed, 26 Aug 2009 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKp7w75fCxSH; Wed, 26 Aug 2009 14:45:39 -0700 (PDT) Received: from mx01.net.com (mx01.net.com [134.56.3.131]) by core3.amsl.com (Postfix) with ESMTP id E23B13A6F11; Wed, 26 Aug 2009 14:45:39 -0700 (PDT) Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id n7QLjVTl020242; Wed, 26 Aug 2009 14:45:32 -0700 (PDT) Received: from fmt-ex01.net.com (fmt-exchange [134.56.112.251]) by mx01-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id n7QLa8cH029989; Wed, 26 Aug 2009 14:36:08 -0700 (PDT) Received: from fmt-ex07.net.com ([134.56.113.16]) by fmt-ex01.net.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Aug 2009 14:54:43 -0700 Received: from fmt-qex01.quintum.com (134.56.116.12) by fmt-ex07.net.com (134.56.113.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 Aug 2009 14:45:26 -0700 Received: from fmt-qex01.quintum.com ([134.56.116.12]) by fmt-qex01.quintum.com ([134.56.116.12]) with mapi; Wed, 26 Aug 2009 14:45:25 -0700 From: Neel Balasubramanian To: "Szilagyi, Mike" , "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Wed, 26 Aug 2009 14:45:22 -0700 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQABH9QA Message-ID: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.com> 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 X-OriginalArrivalTime: 26 Aug 2009 21:54:43.0013 (UTC) FILETIME=[D17E8F50:01CA2697] X-Mailman-Approved-At: Wed, 26 Aug 2009 15:47:34 -0700 Subject: Re: [dispatch] Requests sent within early dialog -- CSeq mgmt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 21:45:41 -0000 See below. Thanks, Neel. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Szilagyi, Mike > Sent: Wednesday, August 26, 2009 4:11 PM > To: dispatch@ietf.org; sipcore@ietf.org; sip- > implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Requests sent within early dialog -- CSeq > mgmt > > I've not been able to find definitive text regarding this issue so I'm > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here's an example to demonstrate my > confusion: > > UAC UAS > INVITE > CSeq 1 ---------> > > <----- 100 Trying Remote CSeq =3D 1 > > UPDATE > CSeq 2 ---------> > > <-- 200 OK (UPDATE) Remote CSeq =3D 2 > > > CANCEL > CSeq 1 ---------> Rejected CSeq < 2 > [Neel] For CANCEL processing, the CSeq should be same as that of the INVITE. See RFC 3261 section 9.1 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. So in this case, the UAS is not behaving correctly. > > is there text that describes the handling of CSeq numbers for requests > sent within another request for the same dialog? > > Thanks in advance. > > Mike > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From andersk@cisco.com Wed Aug 26 21:45:26 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793A53A694E for ; Wed, 26 Aug 2009 21:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEoAj+c2pj1a for ; Wed, 26 Aug 2009 21:45:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 501A13A6897 for ; Wed, 26 Aug 2009 21:45:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,283,1249257600"; d="scan'208";a="233702485" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Aug 2009 04:45:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7R4jW9s017163; Wed, 26 Aug 2009 21:45:32 -0700 Received: from [10.21.95.94] ([10.21.95.94]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7R4jVRU028213; Thu, 27 Aug 2009 04:45:32 GMT Message-ID: <4A960F68.6000501@cisco.com> Date: Wed, 26 Aug 2009 21:45:28 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1287; t=1251348332; x=1252212332; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20draft-ietf-sip-body-handling-06 |Sender:=20; bh=sH1kSiK6v4ZPGZF2Kj3SuO4krCcoqLZvBMWfVALmcD4=; b=PxPSAYf2861hu46zXJYZBFrXKHoEtHHMh7/MNTzLkybI2cdg06QEgjgSdE D/HNW+sZHsu2t4BpSXTQGNJXY0Bg5fDAuYl2gIM0lTaDlv9SxaoN1fLSuoPi u/0yo06RmL; Authentication-Results: sj-dkim-4; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [dispatch] draft-ietf-sip-body-handling-06 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 04:45:26 -0000 Couple of nits on draft-ietf-sip-body-handling-06... Sec 3.2: Consequently, UAs SHOULD use the binary transfer encoding for all payloads in SIP, including binary payloads. The only case where a UA MAY use a different encoding is when transferring application data between applications that only handle a different encoding (e.g., base64). The two sentences are disagreeing. Assuming the first sentence is correct (which I believe it is) then the example in the second sentence is not in fact the *only* case where a UA may use a different transfer encoding. 4.3: However, [RFC2046] states that a 'multipart' media type with a single body part is useful in some circumstances (e.g., for sending non-text media types). Why even mention this. It's irrelevant for SIP, right? 8.2: The UA SHOULD also set the 'handling' parameter of all the top-level body part within the 'multipart/alternative' to 'optional'. and then below it: The UA MUST use the same disposition type for the 'multipart/ alternative' body and all its top-level body parts. These two statements also seem to be in conflict with each other when the multipart/alternative has handling=required. Thanks, Anders From Mike.Szilagyi@inin.com Thu Aug 27 08:06:14 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E1E3A68E8; Thu, 27 Aug 2009 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHnjvvzGVl1G; Thu, 27 Aug 2009 08:06:13 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id E38663A6969; Thu, 27 Aug 2009 08:06:12 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Thu, 27 Aug 2009 11:06:19 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Thu, 27 Aug 2009 11:06:19 -0400 From: "Szilagyi, Mike" To: Neel Balasubramanian , "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Thu, 27 Aug 2009 11:06:18 -0400 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQABH9QAACRYQYA= Message-ID: References: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.com> In-Reply-To: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.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 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=353098832 X-SEF-Processed: 6_1_1_105__2009_08_27_11_06_19 Subject: Re: [dispatch] Requests sent within early dialog -- CSeq mgmt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:06:14 -0000 But, Section 12.2.2 says this: 12.2.2 UAS Behavior . . If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. . . Should the UAS ignore the CSeq number if it's a CANCEL? Is there text anyw= here, in any RFC (UPDATE/INFO/SIP) that describes this behavior? I can't f= ind it. Regards. -----Original Message----- From: Neel Balasubramanian [mailto:Bala_Neelakantan@Quintum.com]=20 Sent: Wednesday, August 26, 2009 5:45 PM To: Szilagyi, Mike; dispatch@ietf.org; sipcore@ietf.org; sip-implementors@l= ists.cs.columbia.edu Subject: RE: Requests sent within early dialog -- CSeq mgmt See below. Thanks, Neel. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Szilagyi, Mike > Sent: Wednesday, August 26, 2009 4:11 PM > To: dispatch@ietf.org; sipcore@ietf.org; sip- > implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Requests sent within early dialog -- CSeq > mgmt > > I've not been able to find definitive text regarding this issue so I'm > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here's an example to demonstrate my > confusion: > > UAC UAS > INVITE > CSeq 1 ---------> > > <----- 100 Trying Remote CSeq =3D 1 > > UPDATE > CSeq 2 ---------> > > <-- 200 OK (UPDATE) Remote CSeq =3D 2 > > > CANCEL > CSeq 1 ---------> Rejected CSeq < 2 > [Neel] For CANCEL processing, the CSeq should be same as that of the INVITE. See RFC 3261 section 9.1 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. So in this case, the UAS is not behaving correctly. > > is there text that describes the handling of CSeq numbers for requests > sent within another request for the same dialog? > > Thanks in advance. > > Mike > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From drage@alcatel-lucent.com Sun Aug 30 11:54:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1D13A67D7 for ; Sun, 30 Aug 2009 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7appFwtnAWo for ; Sun, 30 Aug 2009 11:54:21 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 6C3A128C15C for ; Sun, 30 Aug 2009 11:54:20 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7UIsJqP028167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 30 Aug 2009 20:54:19 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 30 Aug 2009 20:54:19 +0200 From: "DRAGE, Keith (Keith)" To: Anders Kristensen , "dispatch@ietf.org" Date: Sun, 30 Aug 2009 20:54:18 +0200 Thread-Topic: [dispatch] draft-ietf-sip-body-handling-06 Thread-Index: Acom0Tj3IvtJDFvOSR25jpT2sW+ZXwCrF7Bw Message-ID: References: <4A960F68.6000501@cisco.com> In-Reply-To: <4A960F68.6000501@cisco.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [dispatch] draft-ietf-sip-body-handling-06 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:54:22 -0000 This document is currently in AUTH48 in the RFC Editor Queue. Furthermore, any discussions should be on sip@ietf.org regards Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Anders Kristensen > Sent: Thursday, August 27, 2009 5:45 AM > To: dispatch@ietf.org > Subject: [dispatch] draft-ietf-sip-body-handling-06 >=20 > Couple of nits on draft-ietf-sip-body-handling-06... >=20 > Sec 3.2: >=20 > Consequently, UAs SHOULD use the binary transfer > encoding for all payloads in SIP, including binary payloads. The > only case where a UA MAY use a different encoding is when > transferring application data between applications that=20 > only handle a > different encoding (e.g., base64). >=20 > The two sentences are disagreeing. Assuming the first=20 > sentence is correct (which I believe it is) then the example=20 > in the second sentence is not in fact the *only* case where a=20 > UA may use a different transfer encoding. >=20 >=20 > 4.3: >=20 > However, [RFC2046] states that a 'multipart' media type > with a single body part is useful in some circumstances (e.g., for > sending non-text media types). >=20 > Why even mention this. It's irrelevant for SIP, right? >=20 >=20 > 8.2: >=20 > The UA > SHOULD also set the 'handling' parameter of all the top-level body > part within the 'multipart/alternative' to 'optional'. >=20 > and then below it: >=20 > The UA MUST use the same disposition type for the 'multipart/ > alternative' body and all its top-level body parts. >=20 > These two statements also seem to be in conflict with each=20 > other when the multipart/alternative has handling=3Drequired. >=20 >=20 > Thanks, > Anders > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Sun Aug 30 23:39:22 2009 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A959928C15C for ; Sun, 30 Aug 2009 23:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX5YB8PCzlF5 for ; Sun, 30 Aug 2009 23:39:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id A66BB3A6BBC for ; Sun, 30 Aug 2009 23:39:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KP800587AHT14@siemenscomms.co.uk> for dispatch@ietf.org; Mon, 31 Aug 2009 07:39:29 +0100 (BST) Date: Mon, 31 Aug 2009 07:39:20 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> To: Mary Barnes , dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0024E504F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [dispatch] IETF-76 DISPATCH WG deadlines Thread-Index: AcohwNkciiguS2xuQiuKUNJpbaNnbQAuvWPQAeJSDFA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F9182AD@zrc2hxm0.corp.nortel.com> Cc: Victor Pascual Subject: Re: [dispatch] IETF-76 DISPATCH WG deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 06:39:22 -0000 Mary, Victor and I would like to propose SIP Identity as a topic for IETF#76. We hope to update http://tools.ietf.org/id/draft-elwell-dispatch-identity-reqs-00.txt before the meeting. We don't believe we are in a position yet to propose a charter. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 21 August 2009 17:25 > To: dispatch@ietf.org > Cc: rai-ads@tools.ietf.org > Subject: [dispatch] IETF-76 DISPATCH WG deadlines >=20 > Hi all,=20 >=20 > As was done for IETF-75, we are setting earlier deadlines for=20 > discussing topics in DISPATCH prior to the WG session at IETF-76. =20 >=20 > We will again follow the deadlines for BoFs:=20 > http://www.ietf.org/meeting/cutoff-dates.html#76=20 > =20 >=20 > This provides enough time to dispatch topics prior to the=20 > meeting as appropriate - e.g., mini-bofs, official bofs,=20 > other WGs, new WGs, mailing lists, etc. Thus, allowing us to=20 > have more focused and constructive discussions on a smaller=20 > set of topics prior to the WG session.=20 >=20 > Please note that the dates are much sooner than you might=20 > expect as the time between IETF-75 and IETF-76 is 3 weeks=20 > less than the time between IETF-74 and IETF-75. The document=20 > deadlines are 9 and 10 weeks away from next Monday (August 24th). =20 >=20 >=20 > Thus, the following are the proposed deadlines:=20 >=20 > Sept 7th - Cutoff date to notify the chairs and DISPATCH WG=20 > mailing list of plans to submit a proposal.=20 > -------------------------------------------------------------- > ------------------------------------------=20 >=20 > This will help folks with similar topics to work together=20 > before the meeting. If a preliminary charter proposal is=20 > available at this point, please include it. >=20 >=20 > September 21st - Cutoff for charter proposals for topics.=20 > --------------------------------------------------------=20 >=20 > A charter proposal must consist of a minimum of a problem=20 > statement and at least one milestone/deliverable. This=20 > deadline will allow time for consideration of proposals that=20 > could potentially be "dispatched" prior to the WG session. >=20 >=20 > September 28th - Topics that are to be the focus of IETF-76=20 > are announced.=20 > -------------------------------------------------------------- > -------------=20 >=20 > The idea here is to focus the discussion over the weeks=20 > preceding IETF-76 on these main topics, noting that any new=20 > or updates to any documents are due 3-4 weeks later. This=20 > will ensure we have constructive discussions before the=20 > meeting and are actually able to determine consensus as to=20 > where work should be progressed (e.g., separate BoF, a new=20 > WG, an existing WG, individual document, etc.) at IETF-76.=20 > Note, that the exact disposition for a topic may (per the=20 > usual process) require follow-up and confirmation by the ADS=20 > and/or IESG (e.g., for a new WG, Bof, individually sponsored=20 > document, etc.) or with another WG to ensure agreement with=20 > the DISPATCH WG consensus for the topic. >=20 >=20 > As discussed previously, the intention is not necessarily to=20 > preclude folks submitting documents on other topics, however,=20 > it is very unlikely there would be agenda time allocated to=20 > documents/topics submitted after the deadlines. We can=20 > include one or two slides on these topics in the DISPATCH WG=20 > chair charts so that the authors can gather other interested=20 > parties to contribute to the work.=20 >=20 > Regards,=20 > Mary and Gonzalo=20 > DISPATCH WG co-chairs=20 >=20 >=20