From gonzalo.camarillo@ericsson.com Mon Feb 1 02:56:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514D728C1B6 for ; Mon, 1 Feb 2010 02:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.962 X-Spam-Level: X-Spam-Status: No, score=-105.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 yNeUNoeRl5pp for ; Mon, 1 Feb 2010 02:56:36 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4E23E28C1B5 for ; Mon, 1 Feb 2010 02:56:36 -0800 (PST) X-AuditID: c1b4fb24-b7cfcae000005f96-cb-4b66b384028a Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BF.C5.24470.483B66B4; Mon, 1 Feb 2010 11:57:08 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:57:08 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:57:08 +0100 Message-ID: <4B66B382.6040306@ericsson.com> Date: Mon, 01 Feb 2010 12:57:06 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 10:57:08.0131 (UTC) FILETIME=[4C3B9730:01CAA32D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 10:56:37 -0000 Hi Christer, as we've said a few times before when talking about this draft, we need to fix the nits reported by the ID nits tools before requesting its publication. Could you please fix all the errors related to references under the link below and resubmit the draft so that we can request its publication? http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-sipcore-info-events-06.txt Thanks, Gonzalo Christer Holmberg wrote: > > Hi, > > I've submitted a new version of the info draft. > > I did the changes regaring the IANA review of info packages, and some > editorial fixes. > > Regards, > > Christer > From christer.holmberg@ericsson.com Mon Feb 1 03:06:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51B828C1CB for ; Mon, 1 Feb 2010 03:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 4Y0H921Yh-Ml for ; Mon, 1 Feb 2010 03:06:49 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5638228C1CC for ; Mon, 1 Feb 2010 03:04:43 -0800 (PST) X-AuditID: c1b4fb24-b7cfcae000005f96-e4-4b66b56b51a3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 7C.E7.24470.B65B66B4; Mon, 1 Feb 2010 12:05:15 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 1 Feb 2010 12:05:15 +0100 From: Christer Holmberg To: Gonzalo Camarillo Date: Mon, 1 Feb 2010 12:05:14 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-06 Thread-Index: AcqjLVJLNNyLSDxDTY2tHY2JSDTzFgAAIhXA Message-ID: References: <4B66B382.6040306@ericsson.com> In-Reply-To: <4B66B382.6040306@ericsson.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 11:06:51 -0000 Hi, There is one id nit warning which I couldn't fix. I did research on the xml= 2rfc infomation pages, discussion archieve etc, and did according to what w= as said there, but was still not able to get rid of the warning. I also asked some people about this, but have not received any reply. The warning says: "=3D=3D You're using the IETF Trust Provisions' Section 6.b License Notice = from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/)" If you know how to fix this, please let me know. Other than that, there should be no id nits fixes. Regards, Christer > -----Original Message----- > From: Gonzalo Camarillo=20 > Sent: 1. helmikuuta 2010 12:57 > To: Christer Holmberg > Cc: SIPCORE; 'Adam Roach'; hkaplan@acmepacket.com; Eric Burger > Subject: Re: Draft new version: draft-ietf-sipcore-info-events-06 >=20 > Hi Christer, >=20 > as we've said a few times before when talking about this=20 > draft, we need to fix the nits reported by the ID nits tools=20 > before requesting its publication. Could you please fix all=20 > the errors related to references under the link below and=20 > resubmit the draft so that we can request its publication? >=20 > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draf > t-ietf-sipcore-info-events-06.txt >=20 > Thanks, >=20 > Gonzalo >=20 > Christer Holmberg wrote: > > =20 > > Hi, > > =20 > > I've submitted a new version of the info draft. > > =20 > > I did the changes regaring the IANA review of info=20 > packages, and some=20 > > editorial fixes. > > =20 > > Regards, > > =20 > > Christer > > =20 >=20 > = From christer.holmberg@ericsson.com Mon Feb 1 03:11:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90483A67F0 for ; Mon, 1 Feb 2010 03:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.177, 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 w5Ty4qFVMq+q for ; Mon, 1 Feb 2010 03:11:53 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D62BC28C1C8 for ; Mon, 1 Feb 2010 03:11:51 -0800 (PST) X-AuditID: c1b4fb24-b7cfcae000005f96-d2-4b66b7181a9b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FF.C9.24470.817B66B4; Mon, 1 Feb 2010 12:12:24 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 1 Feb 2010 12:12:24 +0100 From: Christer Holmberg To: Christer Holmberg , Gonzalo Camarillo Date: Mon, 1 Feb 2010 12:12:22 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-06 Thread-Index: AcqjLVJLNNyLSDxDTY2tHY2JSDTzFgAAIhXAAABfYvA= Message-ID: References: <4B66B382.6040306@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 11:11:56 -0000 Sorry, I found the reference errors. I clicked the wrong box in the idnit t= ool. I will fix those. But, I still need to get help regarding the warning I mentioned earlier. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 1. helmikuuta 2010 13:05 > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-06 >=20 >=20 > Hi, >=20 > There is one id nit warning which I couldn't fix. I did=20 > research on the xml2rfc infomation pages, discussion archieve=20 > etc, and did according to what was said there, but was still=20 > not able to get rid of the warning. >=20 > I also asked some people about this, but have not received any reply. >=20 > The warning says: >=20 > "=3D=3D You're using the IETF Trust Provisions' Section 6.b=20 > License Notice from > 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/)" >=20 > If you know how to fix this, please let me know. >=20 > Other than that, there should be no id nits fixes. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Gonzalo Camarillo > > Sent: 1. helmikuuta 2010 12:57 > > To: Christer Holmberg > > Cc: SIPCORE; 'Adam Roach'; hkaplan@acmepacket.com; Eric Burger > > Subject: Re: Draft new version: draft-ietf-sipcore-info-events-06 > >=20 > > Hi Christer, > >=20 > > as we've said a few times before when talking about this draft, we=20 > > need to fix the nits reported by the ID nits tools before=20 > requesting=20 > > its publication. Could you please fix all the errors related to=20 > > references under the link below and resubmit the draft so=20 > that we can=20 > > request its publication? > >=20 > > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draf > > t-ietf-sipcore-info-events-06.txt > >=20 > > Thanks, > >=20 > > Gonzalo > >=20 > > Christer Holmberg wrote: > > > =20 > > > Hi, > > > =20 > > > I've submitted a new version of the info draft. > > > =20 > > > I did the changes regaring the IANA review of info > > packages, and some > > > editorial fixes. > > > =20 > > > Regards, > > > =20 > > > Christer > > > =20 > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gonzalo.camarillo@ericsson.com Mon Feb 1 03:20:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60D53A692F for ; Mon, 1 Feb 2010 03:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.993 X-Spam-Level: X-Spam-Status: No, score=-105.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1f1xvVSgcbfq for ; Mon, 1 Feb 2010 03:20:16 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4438D3A67D8 for ; Mon, 1 Feb 2010 03:20:15 -0800 (PST) X-AuditID: c1b4fb24-b7cfcae000005f96-6e-4b66b910cca8 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9C.EB.24470.019B66B4; Mon, 1 Feb 2010 12:20:48 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 12:20:48 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 12:20:48 +0100 Message-ID: <4B66B90E.2050908@ericsson.com> Date: Mon, 01 Feb 2010 13:20:46 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B66B382.6040306@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 11:20:48.0158 (UTC) FILETIME=[9AA283E0:01CAA330] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 11:20:17 -0000 Hi Christer, > Other than that, there should be no id nits fixes. if you check the link I sent in my previous email, you can find the following nits, which relate to the references of the draft. These nits should be trivial to fix: == Unused Reference: 'RFC3080' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1417, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC4028' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 1454, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Thanks, Gonzalo > > Regards, > > Christer > > > >> -----Original Message----- >> From: Gonzalo Camarillo >> Sent: 1. helmikuuta 2010 12:57 >> To: Christer Holmberg >> Cc: SIPCORE; 'Adam Roach'; hkaplan@acmepacket.com; Eric Burger >> Subject: Re: Draft new version: draft-ietf-sipcore-info-events-06 >> >> Hi Christer, >> >> as we've said a few times before when talking about this >> draft, we need to fix the nits reported by the ID nits tools >> before requesting its publication. Could you please fix all >> the errors related to references under the link below and >> resubmit the draft so that we can request its publication? >> >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draf >> t-ietf-sipcore-info-events-06.txt >> >> Thanks, >> >> Gonzalo >> >> Christer Holmberg wrote: >>> >>> Hi, >>> >>> I've submitted a new version of the info draft. >>> >>> I did the changes regaring the IANA review of info >> packages, and some >>> editorial fixes. >>> >>> Regards, >>> >>> Christer >>> From christer.holmberg@ericsson.com Mon Feb 1 05:08:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6DF28C7B3 for ; Mon, 1 Feb 2010 05:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-2.742, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 8I4qZuK1QPnW for ; Mon, 1 Feb 2010 05:08:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (unknown [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C039D28C977 for ; Mon, 1 Feb 2010 05:06:24 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-53-4b66d1f19856 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 01.AC.31641.1F1D66B4; Mon, 1 Feb 2010 14:06:57 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 1 Feb 2010 14:06:57 +0100 From: Christer Holmberg To: Gonzalo Camarillo Date: Mon, 1 Feb 2010 14:06:55 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-06 Thread-Index: AcqjMJtrr/Fqy9ihSLyMZuZqv81xFAADqpjw Message-ID: References: <4B66B382.6040306@ericsson.com> <4B66B90E.2050908@ericsson.com> In-Reply-To: <4B66B90E.2050908@ericsson.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 13:08:50 -0000 Hi, They are fixed now, and based on your input I also managed to fix the boile= rplate warnings (some manual changes to the xml2rfc output is required). Regards, Christer=20 > -----Original Message----- > From: Gonzalo Camarillo=20 > Sent: 1. helmikuuta 2010 13:21 > To: Christer Holmberg > Cc: SIPCORE; 'Adam Roach'; hkaplan@acmepacket.com; Eric Burger > Subject: Re: Draft new version: draft-ietf-sipcore-info-events-06 >=20 > Hi Christer, >=20 > > Other than that, there should be no id nits fixes. >=20 > if you check the link I sent in my previous email, you can=20 > find the following nits, which relate to the references of=20 > the draft. These nits should be trivial to fix: >=20 > =3D=3D Unused Reference: 'RFC3080' is defined on line 1406, but=20 > no explicit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC3725' is defined on line 1417, but=20 > no explicit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC3841' is defined on line 1426, but=20 > no explicit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC4028' is defined on line 1444, but=20 > no explicit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC4145' is defined on line 1447, but=20 > no explicit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC4730' is defined on line 1454, but=20 > no explicit > reference was found in the text >=20 > -- Obsolete informational reference (is this intentional?): RFC 3851 > (Obsoleted by RFC 5751) >=20 >=20 > Thanks, >=20 > Gonzalo >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Gonzalo Camarillo > >> Sent: 1. helmikuuta 2010 12:57 > >> To: Christer Holmberg > >> Cc: SIPCORE; 'Adam Roach'; hkaplan@acmepacket.com; Eric Burger > >> Subject: Re: Draft new version: draft-ietf-sipcore-info-events-06 > >> > >> Hi Christer, > >> > >> as we've said a few times before when talking about this draft, we=20 > >> need to fix the nits reported by the ID nits tools before=20 > requesting=20 > >> its publication. Could you please fix all the errors related to=20 > >> references under the link below and resubmit the draft so=20 > that we can=20 > >> request its publication? > >> > >> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draf > >> t-ietf-sipcore-info-events-06.txt > >> > >> Thanks, > >> > >> Gonzalo > >> > >> Christer Holmberg wrote: > >>> =20 > >>> Hi, > >>> =20 > >>> I've submitted a new version of the info draft. > >>> =20 > >>> I did the changes regaring the IANA review of info > >> packages, and some > >>> editorial fixes. > >>> =20 > >>> Regards, > >>> =20 > >>> Christer > >>> =20 >=20 > = From root@core3.amsl.com Mon Feb 1 05:45:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A98C3A6945; Mon, 1 Feb 2010 05:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100201134502.3A98C3A6945@core3.amsl.com> Date: Mon, 1 Feb 2010 05:45:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 13:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-07.txt Pages : 38 Date : 2010-02-01 This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-01053640.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Mon Feb 1 22:36:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7823A6A7F for ; Mon, 1 Feb 2010 22:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-2.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 ew5CYr6aYqln for ; Mon, 1 Feb 2010 22:36:10 -0800 (PST) Received: from mailgw10.se.ericsson.net (unknown [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BFF603A6A67 for ; Mon, 1 Feb 2010 22:36:09 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-13-4b67c7fd52d3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 38.C8.02429.DF7C76B4; Tue, 2 Feb 2010 07:36:45 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 2 Feb 2010 07:36:45 +0100 From: Christer Holmberg To: SIPCORE Date: Tue, 2 Feb 2010 07:36:44 +0100 Thread-Topic: 3265bis and Call-Info Thread-Index: Acqj0hYwm+UsMBOiRzyzFMQi1OtZ6A== 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_FF84A09F50A6DC48ACB6714F4666CC743C583160CFESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 06:36:11 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC743C583160CFESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, The Call-Info header field is missing from the table in section 8.1. RFC 5367 allows Call-Info in NOTIFY, so I guess we also in the 3265bis tabl= e can indicate that it is allowed for NOTIFY. I also think it should be all= owed for SUBSCRIBE, because I assume it could be used for similar purposes = as in an INVITE. In addition, I guess we should also see what other headers are not listed. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC743C583160CFESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Adam,
 
The Call-Info header field is missing from the table = in section 8.1.
 
RFC 5367 allows Call-Info in NOTIFY, so I guess we al= so in the 3265bis table can indicate that it is allowed for NOTIFY. I also = think it should be allowed for SUBSCRIBE, because I assume it could be used= for similar purposes as in an INVITE.
 
In addition, I guess we should also see what other he= aders are not listed.
 
Regards,
 
Christer
 
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC743C583160CFESESSCMS0354e_-- From brian@estacado.net Tue Feb 2 14:32:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857A228C115 for ; Tue, 2 Feb 2010 14:32:56 -0800 (PST) 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=[AWL=0.000, 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 NJjiFXNA7zc3 for ; Tue, 2 Feb 2010 14:32:55 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id A9C0C28C0E7 for ; Tue, 2 Feb 2010 14:32:54 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o12MXG2h059370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Feb 2010 16:33:21 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: Date: Tue, 2 Feb 2010 16:33:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <08B937FE-77A0-4F99-AC7D-DD9AC72F42FB@estacado.net> References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 22:32:56 -0000 My guess is that there are three categories of normative-sounding = statements in the document. =20 1) statements that are repeating or paraphrasing actual normative = statements from authoritative documents,=20 2) statements that are normal english usage of the words "should" and = "must", but don't (and mustn't) actually claim any normative authority 3) statements that really NEED to be normative, but simply aren't. I haven't yet taken an inventory of which statements we have and which = categories to which they belong to yet, but what sounds right to me is: 1) For category 1 statements we use normative-like conventions of RFC = 2119 AND specifically reference the RFC that has the authority. I am = advocating that we NOT add an RFC 2119 convention section. Since we are = not actually making authoritative statements, I would think that SHOULD = be fine. 2) Category 2 statements remain as they are, which is to say they do = not adopt RFC 2119 convention, and are only intended to recommend and = suggest. Use of the word "must" should therefore be avoided in this = class of statement. 3) Category 3 statements should probably be specifically identified = in the body of the document as statements that we think should be made = normative somewhere else but ARE NOT. I think these would be worthwhile = information and fair game for this document, if we have any. =20 My belief is that this will help clarify our intentions and our = recommendations, while helping us avoid the confusion implementers may = have as to whether this document is actually a normative source. Does this sound agreeable? If so, I can go find the relevant statements = and we can start nailing down which camp they belong to, and if they are = category 1, which documents authorize them.=20 -b On Jan 28, 2010, at 6:11 AM, DRAGE, Keith (Keith) wrote: > The key thing here is whether any of those normative like statements = need to appear at standards track level.=20 >=20 > If they do, they belong in another document, as this document is = definitely informative. >=20 > If they don't belong in another document they still need careful = consideration as to whether they appear as=20 >=20 > XXX MUST do this,=20 >=20 > as opposed to a commentary on what appears elsewhere: >=20 > Based on the requirements in document zzz, the correct usage of those = requirements results in XXX doing this. >=20 > There is certainly no point in circulating normative statements in a = document just because that is the way they were first formulated. We = need to consider if that is the best way of presenting that particular = item of information. >=20 > regards >=20 > Keith >=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com]=20 >> Sent: Wednesday, January 27, 2010 6:07 PM >> To: Brian Hibbard >> Cc: DRAGE, Keith (Keith); SIPCORE; Kumiko Ono >> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 >> document scope and intent >>=20 >>=20 >> On Jan 7, 2010, at 3:08 PM, Brian Hibbard wrote: >>=20 >>> OK, it seems there is heavy agreement that this SHOULD be=20 >> informational and not standards track. Do we have agreement on that? >>>=20 >>> Specifically, Cullen, are you OK with that? >>=20 >> No problem - this is a chair issue/AD (Robert) issue and glad=20 >> to do whatever they want.=20 >>=20 >>> Do you want to weigh in on the rationale for=20 >> normative-strength statements? >>>=20 >>> If there are no remaining objections, I can go ahead and=20 >> make the draft informational and remove section 2 and=20 >> references to RFC 2119. I'll make sure we have no =20 >> normative-sounding SHOULDs, MUSTs, et al. >>=20 >> Uh, we have all kinds of normative language in RAI =20 >> Information RFC so don't water things down such that=20 >> implementers don't know what to do. The point of this doc is=20 >> to help implementers get it right so as long as the language=20 >> changes are consistent with helping implementors get it=20 >> right. I'm fine with them.=20 >>=20 >>>=20 >>> -b >>> On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: >>>=20 >>>> If so, you arbitrarily decided to change it because as far=20 >> as I know it was informational during its complete lifetime=20 >> in the SIP group, and I remember no discussion in the=20 >> transfer to SIPCORE that made it standards track. Certainly=20 >> my final SIP status slides (and the ones before and the ones=20 >> before that ...) also say "Candidate: Informational". The=20 >> first version that carries an "intended status" line is the=20 >> 1st sipcore version, and this is at variance with the charter pages. >>>>=20 >>>> The last SIP charter pages clearly say: >>>> Mar 2009 Example security flows to WGLC (Informational) >>>> Jul 2009 Example security flows to IESG (Informational) >>>>=20 >>>> And the SIPCORE charter pages state: >>>>=20 >>>> Oct 2009 Example security flows to IESG (Informational) >>>>=20 >>>> And from my own perspective this should still be=20 >> informational. If you feel there is standards track=20 >> information in here, then pull it out and submit it as a=20 >> separate draft, and then the WG can decide whether they want=20 >> to proceed with such a standards track document. >>>>=20 >>>> I'd also note to all authors that if you receive private=20 >> messages of interest, then at least please let the WG chairs=20 >> know that you have had those expressions of interest. If you=20 >> received any of those messages on sec-flows during its SIP=20 >> lifetime, the ex SIP WG chairs certainly have no evidence of=20 >> them ever having been received - and that is essential=20 >> information to the PROTO writeups. I assume the SIPCORE=20 >> chairs are now in the same boat, having no email evidence=20 >> because a small set of exchanges in the past on SIP and=20 >> SIPCORE that anyone is even interested in this document. >>>>=20 >>>> regards >>>>=20 >>>> Keith >>>>=20 >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings >>>>> Sent: Thursday, December 10, 2009 6:14 AM >>>>> To: Brian Hibbard >>>>> Cc: SIPCORE; Kumiko Ono >>>>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: >>>>> document scope and intent >>>>>=20 >>>>>=20 >>>>> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: >>>>>=20 >>>>>> The draft states in the first line of the introduction that >>>>> it is not normative for SIP. That raises the question as=20 >> to whether=20 >>>>> this should be on the standards track. Should this be=20 >> informational=20 >>>>> or BCP? >>>>>=20 >>>>> I think we decided it need to be standards track when we=20 >> added the=20 >>>>> normative statements about binary a long time ago. >>>>> (I note that the "should" should be a "SHOULD". >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >>=20 From drage@alcatel-lucent.com Tue Feb 2 15:22:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF9C28C12D for ; Tue, 2 Feb 2010 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=1.143, 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 Ihy2qcD0IUlq for ; Tue, 2 Feb 2010 15:22:55 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id E4A343A69D1 for ; Tue, 2 Feb 2010 15:22:54 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o12NN2kC006812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 00:23:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 3 Feb 2010 00:23:02 +0100 From: "DRAGE, Keith (Keith)" To: Brian Hibbard Date: Wed, 3 Feb 2010 00:23:00 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent Thread-Index: AcqkV72DXRbd4jWNQPqQCTsnc/jguAABd5Hg Message-ID: References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> <08B937FE-77A0-4F99-AC7D-DD9AC72F42FB@estacado.net> In-Reply-To: <08B937FE-77A0-4F99-AC7D-DD9AC72F42FB@estacado.net> 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.64 on 155.132.188.83 Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 23:22:56 -0000 Thanks for thinking about this. For 1) I recommend we do what we did in draft-ietf-sip-sips which was to qu= ote at least the line containing the RFC 2119 word from the original RFC, a= nd use quotation marks to emphasise it was a quote.=20 For 2) there are no rules defining this, but I personally think it is best = to try and reword to avoid lower case "may" and "should" as well as lower c= ase "must". It only takes a slip of the keyboard for it to become upper cas= e in a future edit. What words get used depends on context, but "can" or "m= ight" usually work instead of "may", and "is expected to" in many cases wor= ks for "should". The must one is usually easiest of the lot. In many cases = thinking about what was really meant in terms of trying to do this does als= o make the text clearer. And every RFC writer should be thinking through there RFC 2119 language in = terms of these three categories. Many people use RFC 2119 language because = it is the first form that comes from brain to keyboard. It needs to be rese= rved for conformable requirements. regards Keith > -----Original Message----- > From: Brian Hibbard [mailto:brian@estacado.net]=20 > Sent: Tuesday, February 02, 2010 10:33 PM > To: DRAGE, Keith (Keith) > Cc: Cullen Jennings; SIPCORE; Kumiko Ono > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 > document scope and intent >=20 > My guess is that there are three categories of=20 > normative-sounding statements in the document. > =20 > 1) statements that are repeating or paraphrasing actual=20 > normative statements from authoritative documents,=20 >=20 > 2) statements that are normal english usage of the words=20 > "should" and "must", but don't (and mustn't) actually claim=20 > any normative authority >=20 > 3) statements that really NEED to be normative, but simply aren't. >=20 > I haven't yet taken an inventory of which statements we have=20 > and which categories to which they belong to yet, but what=20 > sounds right to me is: >=20 > 1) For category 1 statements we use normative-like=20 > conventions of RFC 2119 AND specifically reference the RFC=20 > that has the authority. I am advocating that we NOT add an=20 > RFC 2119 convention section. Since we are not actually=20 > making authoritative statements, I would think that SHOULD be fine. >=20 > 2) Category 2 statements remain as they are, which is to=20 > say they do not adopt RFC 2119 convention, and are only=20 > intended to recommend and suggest. Use of the word "must"=20 > should therefore be avoided in this class of statement. >=20 > 3) Category 3 statements should probably be specifically=20 > identified in the body of the document as statements that we=20 > think should be made normative somewhere else but ARE NOT. I=20 > think these would be worthwhile information and fair game for=20 > this document, if we have any. =20 >=20 > My belief is that this will help clarify our intentions and=20 > our recommendations, while helping us avoid the confusion=20 > implementers may have as to whether this document is actually=20 > a normative source. >=20 > Does this sound agreeable? If so, I can go find the relevant=20 > statements and we can start nailing down which camp they=20 > belong to, and if they are category 1, which documents=20 > authorize them.=20 >=20 > -b >=20 >=20 > On Jan 28, 2010, at 6:11 AM, DRAGE, Keith (Keith) wrote: >=20 > > The key thing here is whether any of those normative like=20 > statements need to appear at standards track level.=20 > >=20 > > If they do, they belong in another document, as this=20 > document is definitely informative. > >=20 > > If they don't belong in another document they still need careful=20 > > consideration as to whether they appear as > >=20 > > XXX MUST do this, > >=20 > > as opposed to a commentary on what appears elsewhere: > >=20 > > Based on the requirements in document zzz, the correct=20 > usage of those requirements results in XXX doing this. > >=20 > > There is certainly no point in circulating normative=20 > statements in a document just because that is the way they=20 > were first formulated. We need to consider if that is the=20 > best way of presenting that particular item of information. > >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Wednesday, January 27, 2010 6:07 PM > >> To: Brian Hibbard > >> Cc: DRAGE, Keith (Keith); SIPCORE; Kumiko Ono > >> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 > >> document scope and intent > >>=20 > >>=20 > >> On Jan 7, 2010, at 3:08 PM, Brian Hibbard wrote: > >>=20 > >>> OK, it seems there is heavy agreement that this SHOULD be > >> informational and not standards track. Do we have=20 > agreement on that? > >>>=20 > >>> Specifically, Cullen, are you OK with that? > >>=20 > >> No problem - this is a chair issue/AD (Robert) issue and=20 > glad to do=20 > >> whatever they want. > >>=20 > >>> Do you want to weigh in on the rationale for > >> normative-strength statements? > >>>=20 > >>> If there are no remaining objections, I can go ahead and > >> make the draft informational and remove section 2 and=20 > references to=20 > >> RFC 2119. I'll make sure we have no normative-sounding SHOULDs,=20 > >> MUSTs, et al. > >>=20 > >> Uh, we have all kinds of normative language in RAI=20 > Information RFC so=20 > >> don't water things down such that implementers don't know=20 > what to do.=20 > >> The point of this doc is to help implementers get it right=20 > so as long=20 > >> as the language changes are consistent with helping=20 > implementors get=20 > >> it right. I'm fine with them. > >>=20 > >>>=20 > >>> -b > >>> On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: > >>>=20 > >>>> If so, you arbitrarily decided to change it because as far > >> as I know it was informational during its complete lifetime in the=20 > >> SIP group, and I remember no discussion in the transfer to SIPCORE=20 > >> that made it standards track. Certainly my final SIP status slides=20 > >> (and the ones before and the ones before that ...) also say=20 > >> "Candidate: Informational". The first version that carries an=20 > >> "intended status" line is the 1st sipcore version, and this is at=20 > >> variance with the charter pages. > >>>>=20 > >>>> The last SIP charter pages clearly say: > >>>> Mar 2009 Example security flows to WGLC (Informational) > >>>> Jul 2009 Example security flows to IESG (Informational) > >>>>=20 > >>>> And the SIPCORE charter pages state: > >>>>=20 > >>>> Oct 2009 Example security flows to IESG (Informational) > >>>>=20 > >>>> And from my own perspective this should still be > >> informational. If you feel there is standards track information in=20 > >> here, then pull it out and submit it as a separate draft, and then=20 > >> the WG can decide whether they want to proceed with such a=20 > standards=20 > >> track document. > >>>>=20 > >>>> I'd also note to all authors that if you receive private > >> messages of interest, then at least please let the WG chairs know=20 > >> that you have had those expressions of interest. If you=20 > received any=20 > >> of those messages on sec-flows during its SIP lifetime,=20 > the ex SIP WG=20 > >> chairs certainly have no evidence of them ever having been=20 > received -=20 > >> and that is essential information to the PROTO writeups. I=20 > assume the=20 > >> SIPCORE chairs are now in the same boat, having no email evidence=20 > >> because a small set of exchanges in the past on SIP and=20 > SIPCORE that=20 > >> anyone is even interested in this document. > >>>>=20 > >>>> regards > >>>>=20 > >>>> Keith > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: sipcore-bounces@ietf.org > >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings > >>>>> Sent: Thursday, December 10, 2009 6:14 AM > >>>>> To: Brian Hibbard > >>>>> Cc: SIPCORE; Kumiko Ono > >>>>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: > >>>>> document scope and intent > >>>>>=20 > >>>>>=20 > >>>>> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: > >>>>>=20 > >>>>>> The draft states in the first line of the introduction that > >>>>> it is not normative for SIP. That raises the question as > >> to whether > >>>>> this should be on the standards track. Should this be > >> informational > >>>>> or BCP? > >>>>>=20 > >>>>> I think we decided it need to be standards track when we > >> added the > >>>>> normative statements about binary a long time ago. > >>>>> (I note that the "should" should be a "SHOULD". > >>>>>=20 > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>=20 > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>=20 > >>=20 > >>=20 >=20 > = From gonzalo.camarillo@ericsson.com Thu Feb 4 02:44:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFA33A69DB for ; Thu, 4 Feb 2010 02:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.838 X-Spam-Level: X-Spam-Status: No, score=-103.838 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oz4u42vGxk7F for ; Thu, 4 Feb 2010 02:44:43 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4E3EB3A69C8 for ; Thu, 4 Feb 2010 02:44:43 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-89-4b6aa5479bf0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8D.8D.02429.745AA6B4; Thu, 4 Feb 2010 11:45:27 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 11:45:27 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 11:45:27 +0100 Message-ID: <4B6AA547.1020603@ericsson.com> Date: Thu, 04 Feb 2010 12:45:27 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4B4F011E.5060304@ericsson.com> In-Reply-To: <4B4F011E.5060304@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 10:45:27.0615 (UTC) FILETIME=[29EE94F0:01CAA587] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC of draft-ietf-sipcore-invfix-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 10:44:44 -0000 Hi, the WGLC has ended and we did not receive any additional comments. We would like to ask the authors to perform a few minor changes to the draft and resubmit it so that we can request its publication. All the requested changes below are minor but we prefer them to be fixed before the draft's IETF LC. The draft needs to be consistent in how it refers to 2xx responses. The draft sometimes uses 200-class responses, sometimes simply 200 responses, and sometimes 2xx responses. Choose one option and use it throughout the draft. I personally like 2xx responses, but you may prefer a different one. Note that the change above may affect the title of the draft as well. Also, make sure you introduce the acronym SIP in the title: OLD: ... Session Initiation Protocol INVITE... NEW: ... Session Initiation Protocol (SIP) INVITE... We are not using the essential corrections process any longer. Therefore, please remove the following from Section 2: ", using the process defined in [I-D.drage-sip-essential-correction]" When following the essential corrections process, Section 5 was intended for the WG to make a decision about whether or not a particular correction was essential. Since this is going to be published as a stand-along RFC, its intended audience is implementors, not the WG. Therefore, I would change the heading of Section 5: OLD: Consequences if Not Approved NEW: Consequences if Not Implemented Throughout the text, reason phrases are usually written in brackets. For example, 200 (OK) or 486 (Busy Here). Acronyms (e.g., UA and TU) should be expanded on their first use. Alternatively, you may want to add them to the Terminology Section. The draft sometimes talks about RFCs by simply providing their number, such as in RFC 3261, and sometimes by using a reference, such as in [RFC3261]. It would be nice if the draft could be consistent. References: Remove the reference to the essential corrections process and add a reference to RFC 2543, which, at present, is referred to in the text without using a reference. Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > we would like to WGLC the following draft: > > http://tools.ietf.org/id/draft-ietf-sipcore-invfix-00.txt > > This WGLC will end on January 31st. Please, send your comments to this list. > > Thanks, > > Gonzalo > SIPCORE co-chair > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Thu Feb 4 03:11:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C323A6D76 for ; Thu, 4 Feb 2010 03:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.743 X-Spam-Level: X-Spam-Status: No, score=-103.743 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OTDgosk8xlZG for ; Thu, 4 Feb 2010 03:11:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 490B43A6D72 for ; Thu, 4 Feb 2010 03:11:05 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-a9-4b6aab75c7ef Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id FC.51.02429.57BAA6B4; Thu, 4 Feb 2010 12:11:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 12:11:49 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 12:11:49 +0100 Message-ID: <4B6AAB75.1080504@ericsson.com> Date: Thu, 04 Feb 2010 13:11:49 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B4F022F.30502@ericsson.com> In-Reply-To: <4B4F022F.30502@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 11:11:49.0714 (UTC) FILETIME=[D8EFBB20:01CAA58A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 11:11:14 -0000 Hi, per my email below, I am going to go ahead start this draft's WGLC. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > >> The authors think this version is ready for WGLC. > > you have received a few comments on this list. Additionally, we have > requested feedback from the Geopriv WG: > > http://www.ietf.org/mail-archive/web/geopriv/current/msg08252.html > > Regarding the WGLC, we will be able to start it when the WGLC on the > invfix draft is over. We are talking about February. > > Cheers, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Thu Feb 4 03:13:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8383A6D77 for ; Thu, 4 Feb 2010 03:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.661 X-Spam-Level: X-Spam-Status: No, score=-103.661 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WBzSy1Klzbf8 for ; Thu, 4 Feb 2010 03:13:20 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4AEE63A6D75 for ; Thu, 4 Feb 2010 03:13:20 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-64-4b6aabfc2cbd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6A.A1.02429.CFBAA6B4; Thu, 4 Feb 2010 12:14:05 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 12:13:18 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 12:13:18 +0100 Message-ID: <4B6AABCD.1060600@ericsson.com> Date: Thu, 04 Feb 2010 13:13:17 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2010 11:13:18.0026 (UTC) FILETIME=[0D9312A0:01CAA58B] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 11:13:22 -0000 Folks, we would like to WGLC the following draft: http://tools.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-02.txt This WGLC will end on February 21st. Authors, please treat the list comments you have previously received on this version of the draft (on January 11th and 13rd) as WGLC comments. Thanks, Gonzalo SIPCORE co-chair From salvatore.loreto@ericsson.com Wed Feb 10 02:51:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1160228C1EA for ; Wed, 10 Feb 2010 02:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, 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 fmhsj2W4-h3d for ; Wed, 10 Feb 2010 02:51:12 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 47FC228C1D0 for ; Wed, 10 Feb 2010 02:51:09 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-39-4b728fe205b1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 49.17.31641.2EF827B4; Wed, 10 Feb 2010 11:52:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 11:52:18 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 11:52:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F158D24C5; Wed, 10 Feb 2010 12:52:17 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BCEDE21A41; Wed, 10 Feb 2010 12:52:17 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 28806219D2; Wed, 10 Feb 2010 12:52:16 +0200 (EET) Message-ID: <4B728FE0.9020009@ericsson.com> Date: Wed, 10 Feb 2010 12:52:16 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Michael Procter References: <20100108210001.E16FD3A686B@core3.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000010808000007080708" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 10 Feb 2010 10:52:18.0225 (UTC) FILETIME=[1D273210:01CAAA3F] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:51:14 -0000 This is a multi-part message in MIME format. --------------050000010808000007080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, while I agree with the fact that the formula can not be particularly good for various scenarios and the notifier should have the freedom to achieve an average rate in the way it considers most effective, I also believe that it is better have one defined formula in the draft that can be used as reference. If people agree we can insert in the draft at the end of Section 6.3 some text like the following: In some situation it may be beneficial for the Notifier to achieve an average rate in a different way than the algorithm detailed in this document allows. However, the Notifier MUST NOT be more aggressive that the "min-interval" parameter allows. Cheers /Sal On 01/11/2010 12:46 PM, Michael Procter wrote: > I have one comment left on this draft, which Sal asked me to raise on-list. > > Section 6.3 defines how a notifier will pace notifications to ensure > they meet with the 'average-interval' specified by the subscriber. I > have two problems with defining this. Firstly I don't think we need > to define exactly how the average interval must be achieved, and > secondly even if I did, I don't think the formula specified is > particularly good for various scenarios. > > If a subscriber has specific timing requirements that it wishes to be > met, it can advertise them with min-interval and max-interval. The > average-interval should be viewed as no more than a hint for the > notifier. > > Consequently, the notifier should have freedom to achieve an average > rate in the way it considers most effective, provided it meets the > constraints of min-interval and max-interval. > > I would prefer that the mechanism for achieving a particular average > interval was left to the notifier's discretion and not specified in > this document. I would be content if the given formula was described > as one way to achieve this and that an implementation may choose a > different approach if preferred. > > Best regards, > > Michael > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------050000010808000007080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Michael,

while I agree with the fact that the formula can not be particularly good for various scenarios and
the notifier should have the freedom to achieve an average rate in the way it considers most effective,
I also believe that it is better have one defined formula in the draft that can be used as reference.

If people agree we can insert in the draft at the end of Section 6.3 some text like the following:

In some situation it may be beneficial for the Notifier to achieve an average rate
in a different way than the algorithm detailed in this document allows.
However, the Notifier MUST NOT be more aggressive that the "min-interval"
parameter allows.

Cheers
/Sal


On 01/11/2010 12:46 PM, Michael Procter wrote: 
I have one comment left on this draft, which Sal asked me to raise on-list.

Section 6.3 defines how a notifier will pace notifications to ensure
they meet with the 'average-interval' specified by the subscriber.  I
have two problems with defining this.  Firstly I don't think we need
to define exactly how the average interval must be achieved, and
secondly even if I did, I don't think the formula specified is
particularly good for various scenarios.

If a subscriber has specific timing requirements that it wishes to be
met, it can advertise them with min-interval and max-interval.  The
average-interval should be viewed as no more than a hint for the
notifier.

Consequently, the notifier should have freedom to achieve an average
rate in the way it considers most effective, provided it meets the
constraints of min-interval and max-interval.

I would prefer that the mechanism for achieving a particular average
interval was left to the notifier's discretion and not specified in
this document.  I would be content if the given formula was described
as one way to achieve this and that an implementation may choose a
different approach if preferred.

Best regards,

Michael
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------050000010808000007080708-- From salvatore.loreto@ericsson.com Wed Feb 10 02:51:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEAA28C1D0 for ; Wed, 10 Feb 2010 02:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=-0.646, 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 htPHpsAmdS1Y for ; Wed, 10 Feb 2010 02:51:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DA11B28C1E7 for ; Wed, 10 Feb 2010 02:51:13 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-11-4b728fe67711 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 24.77.02429.6EF827B4; Wed, 10 Feb 2010 11:52:22 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 11:52:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 11:52:22 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E6B7624C5; Wed, 10 Feb 2010 12:52:21 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B390A21A41; Wed, 10 Feb 2010 12:52:21 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 096D6219D2; Wed, 10 Feb 2010 12:52:20 +0200 (EET) Message-ID: <4B728FE4.7070204@ericsson.com> Date: Wed, 10 Feb 2010 12:52:20 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Thomson, Martin" References: <20100108210001.E16FD3A686B@core3.amsl.com> <8B0A9FCBB9832F43971E38010638454F032E44CB7B@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F032E44CB7B@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 10 Feb 2010 10:52:22.0173 (UTC) FILETIME=[1F819CD0:01CAAA3F] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:51:15 -0000 Hi Martin, see my answers are included below cheers /sal On 01/13/2010 12:59 AM, Thomson, Martin wrote: > The document is fit to go to the IESG, with two minor exceptions. > > Section 6.3: > [OPEN ISSUE] Is the period value something we should be able to > tune, or we can simply specify a reasonable period? > > Should this issue be removed now? > [Sal] yes, we will remove in the next version. > Section 8.3: OLD: > response to a NOTIFY request. Implementations supporting the > functionality to update the previously agreed minimum, maximum or > average rate of notifications in a 200-class response to the NOTIFY > request MUST support the inclusion of the Event header field. > NEW: > response to a NOTIFY request. A UA that wishes to update the value > for minimum, maximum or average rate of notifications can do so by > including all desired values for the rate control parameters in an > Event header in the 200-class response to a NOTIFY request. > > The changed text didn't include the most important aspect of this text - which is that the _parameters_ are included. Note that there is no normative requirement in my replacement - interoperability is not harmed by the omission of the header, or even the parameters. > [Sal] I also think it is better to be explicit about the parameters inclusion. From adam@nostrum.com Wed Feb 10 06:02:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3513A3A75C6 for ; Wed, 10 Feb 2010 06:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4OKCOEtz1QHd for ; Wed, 10 Feb 2010 06:02:19 -0800 (PST) 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 F11B73A7579 for ; Wed, 10 Feb 2010 06:02:18 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1AE3Obt075103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 08:03:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B72BCAD.5020002@nostrum.com> Date: Wed, 10 Feb 2010 08:03:25 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Salvatore Loreto References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B728FE0.9020009@ericsson.com> In-Reply-To: <4B728FE0.9020009@ericsson.com> Content-Type: multipart/alternative; boundary="------------080408090802090109090201" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 14:02:20 -0000 This is a multi-part message in MIME format. --------------080408090802090109090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as participant] On 2/10/10 04:52, Feb 10, Salvatore Loreto wrote: > Hi Michael, > > while I agree with the fact that the formula can not be particularly > good for various scenarios and > the notifier should have the freedom to achieve an average rate in the > way it considers most effective, > I also believe that it is better have one defined formula in the draft > that can be used as reference. > > If people agree we can insert in the draft at the end of Section 6.3 > some text like the following: > > In some situation it may be beneficial for the Notifier to achieve > an average rate > in a different way than the algorithm detailed in this document > allows. > However, the Notifier MUST NOT be more aggressive that the > "min-interval" > parameter allows. > Sounds good to me. /a --------------080408090802090109090201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as participant]

On 2/10/10 04:52, Feb 10, Salvatore Loreto wrote:
Hi Michael,

while I agree with the fact that the formula can not be particularly good for various scenarios and
the notifier should have the freedom to achieve an average rate in the way it considers most effective,
I also believe that it is better have one defined formula in the draft that can be used as reference.

If people agree we can insert in the draft at the end of Section 6.3 some text like the following:

In some situation it may be beneficial for the Notifier to achieve an average rate
in a different way than the algorithm detailed in this document allows.
However, the Notifier MUST NOT be more aggressive that the "min-interval"
parameter allows.

Sounds good to me.

/a
--------------080408090802090109090201-- From michael@voip.co.uk Wed Feb 10 07:00:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F31E3A71FA for ; Wed, 10 Feb 2010 07:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 XKN8k774TDF8 for ; Wed, 10 Feb 2010 07:00:36 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 459AB28C214 for ; Wed, 10 Feb 2010 07:00:36 -0800 (PST) Received: from source ([209.85.220.215]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKS3LKWlYBigdym0PB9ZOdU3QnazKbttdf@postini.com; Wed, 10 Feb 2010 07:01:47 PST Received: by mail-fx0-f215.google.com with SMTP id 7so88562fxm.28 for ; Wed, 10 Feb 2010 07:01:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.58.198 with SMTP id i6mr461240fah.28.1265814105080; Wed, 10 Feb 2010 07:01:45 -0800 (PST) In-Reply-To: <4B728FE0.9020009@ericsson.com> References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B728FE0.9020009@ericsson.com> Date: Wed, 10 Feb 2010 15:01:45 +0000 Message-ID: From: Michael Procter To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:00:37 -0000 On 10 February 2010 10:52, Salvatore Loreto wrote: > If people agree we can insert in the draft at the end of Section 6.3 some > text like the following: > > In some situation it may be beneficial for the Notifier to achieve an > average rate > in a different way than the algorithm detailed in this document allows. > However, the Notifier MUST NOT be more aggressive that the "min-interval" > parameter allows. > I'm happy in principle, but I'll suggest the following wording instead: In some situations it may be beneficial for the Notifier to use a different approach to achieve the average interval. However, the Notifier MUST comply with any "min-interval" or "max-interval" parameters that have been negotiated. Section 6.2 contains this text, which seems to mandate use of the formula as an effective upper bound: A compliant notifier MUST generate notifications whenever the time since the most recent notification exceeds the value calculated using the formula defined in Section 6.3. I'm not sure what this paragraph adds over the rest of the text in 6.2 and 6.3, so I think you can simply remove it. > Cheers > /Sal Best regards, Michael From dwing@cisco.com Wed Feb 10 11:33:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDA53A75AB for ; Wed, 10 Feb 2010 11:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pFF1mJZExzNo for ; Wed, 10 Feb 2010 11:33:49 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2A6423A6F03 for ; Wed, 10 Feb 2010 11:33:49 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAPeYckurRN+J/2dsb2JhbACHUoESkgF0pwWXaoJEghEE X-IronPort-AV: E=Sophos;i="4.49,446,1262563200"; d="scan'208";a="239189329" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2010 19:35:00 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1AJZ0OB024043 for ; Wed, 10 Feb 2010 19:35:00 GMT From: "Dan Wing" To: Date: Wed, 10 Feb 2010 11:35:00 -0800 Message-ID: <0ae401caaa88$229ed830$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcqqiCJezJQYaPmpS22iu7f78nrbLQ== Subject: [sipcore] continued need for SIP identity X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:33:50 -0000 Two issues this month demonstrate SIP would still benefit from identity: 1. SIP attacks on the Internet are causing a lot of RTP traffic to 1.1.1.1, see [1] and [2]. This is a real-life "voice hammer" attack, as described in [3]. ICE, implemented on the victim endpoint, would help reduce the amount of traffic but would not block the attack itself. A whitelist could block the attack but only until attackers guess common entries on the whitelist. SIP identity prevents identity spoofing, so attackers receive no value by attempting to spoof caller identities. 2. SIP identity allows better-than-PSTN caller identity, allowing a SIP network to better protect itself from caller ID fraud occuring on the PSTN [4], [5]. Thus, SIP could be "better than the PSTN" -- which has always been SIP's goal. -d [1] http://blog.sipvicious.org/2010/02/rtp-traffic-to-1111.html [2] http://www.usken.no/2010/02/sip-scanning-causes-ddos-on-ip-1-1-1-1/ [3] http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-18.5.1 [4] http://blogs.wsj.com/digits/2010/02/05/the-rise-of-caller-id-spoofing/ [5] http://voipsa.org/pipermail/voipsec_voipsa.org/2010-February/003113.html From dwing@cisco.com Wed Feb 10 11:42:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DBE3A7465 for ; Wed, 10 Feb 2010 11:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7veh1jlbGA3W for ; Wed, 10 Feb 2010 11:42:33 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 851D83A6F19 for ; Wed, 10 Feb 2010 11:42:33 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,446,1262563200"; d="scan'208";a="481214083" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2010 19:43:45 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1AJhimi002565; Wed, 10 Feb 2010 19:43:44 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Olle E. Johansson'" References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net><7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com><4B210DA9.90501@alcatel-lucent.com><01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> Date: Wed, 10 Feb 2010 11:43:44 -0800 Message-ID: <0af801caaa89$5b3f3170$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> Thread-Index: AcqferjgNLEQtF7QQHanw5Un1/FlOALDnp2Q Cc: 'SIPCORE' Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:42:34 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Wednesday, January 27, 2010 10:01 AM > To: Olle E. Johansson > Cc: SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: > technical issues > > > On Jan 8, 2010, at 5:36 AM, Olle E. Johansson wrote: > > > > > During the tests we had at SIPit in New Hampshire we > discovered that without an IP address in the certificate, > most TLS scenarious with record-route/route headers pointing > to IP addresses would fail. Either avoiding IP addresses in > record-route/route or having IP address for the server in the > cert are working solutions to this issue. > > > > IP in SAN certs is propably the fast way forward, but also > gives a headache in solutions where you have multiple IP > addresses in a "clustered" environment. It just feels wrong > to me to have non-DNS data like IP address within the cert. > > You are complete right that what goes in the record route > needs to match what is in the cert. However, it is difficult > to get cert signed by a well known CA that has an IP address > in it so the obvious solution is don't put IP addresses in > your record-route. If a particular proxy, say with a host > name of say proxy22, in the example.com domain wants to > record route, the easiest thing to deploy in my opinion is > putting proxy22.example.com in the record route. Or if you > are a domain with only one proxy, you could just put > example.com in the record route. In the simple one proxy > case, then all you need is a cert with example.com and in the > more complex case you might want a cert with both example.com > and proxy22.example.com. Hope that makes sense. The other > problem with IPs in certs is when you want to renumber the > network or move a machine, you might need new certs. Or an IPv6/IPv4 translator is between the SIP client and its server. http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 talks a bit about the problem, but doesn't bring TLS into the picture. Let's _please_ not use IPv4 address literals, except where we already have to use them (SDP). -d > There is > likely some cases where IP in certs make sense but my opinion > is that in most case, using DNS names is eas > ier. > > Cullen > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Thu Feb 11 08:21:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045373A7207 for ; Thu, 11 Feb 2010 08:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 ow4Ty-2GBl6Q for ; Thu, 11 Feb 2010 08:21:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ACF2F28C1CA for ; Thu, 11 Feb 2010 08:21:35 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1BGMmAw025665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2010 10:22:49 -0600 Message-Id: From: Dean Willis To: Dan Wing In-Reply-To: <0ae401caaa88$229ed830$c4f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 10:22:42 -0600 References: <0ae401caaa88$229ed830$c4f0200a@cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] continued need for SIP identity X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:21:38 -0000 On Feb 10, 2010, at 1:35 PM, Dan Wing wrote: > Two issues this month demonstrate SIP would still benefit from > identity: > > 1. SIP attacks on the Internet are causing a lot of RTP traffic to > 1.1.1.1, > see [1] and [2]. This is a real-life "voice hammer" attack, as > described in > [3]. ICE, implemented on the victim endpoint, would help reduce the > amount of > traffic but would not block the attack itself. A whitelist could > block the > attack but only until attackers guess common entries on the > whitelist. SIP > identity prevents identity spoofing, so attackers receive no value by > attempting to spoof caller identities. > > 2. SIP identity allows better-than-PSTN caller identity, allowing a > SIP > network to better protect itself from caller ID fraud occuring on > the PSTN > [4], [5]. Thus, SIP could be "better than the PSTN" -- which has > always been > SIP's goal. Dan, you're preaching to a whole bunch of people who just want to blindly re-create the PSTN. There's no point in trying to convince them to do something better. They can't envision it, don't want to understand it, and their employers and governments are actively trying to block it. Give up and let Facebook and Google take over the world's communications infrastructure and let the dinosaurs go extinct in their own good time. On the other hand, we do have this going on: http://www.aolnews.com/nation/article/congress-takes-aim-at-fake-caller-ids/19282650 -- Dean From henry.sinnreich@gmail.com Thu Feb 11 09:08:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C79F3A7375 for ; Thu, 11 Feb 2010 09:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 T0V+rfivMrU0 for ; Thu, 11 Feb 2010 09:08:42 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 42CBA3A7772 for ; Thu, 11 Feb 2010 09:08:42 -0800 (PST) Received: by gxk28 with SMTP id 28so1202143gxk.9 for ; Thu, 11 Feb 2010 09:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=hPVZvLuvlpkhhk3ZVT/jhkz19yaDiYvzyB9YyDgfyPs=; b=AJfhzw4pq8HyrZsB6KS5LzZGfAlZlEQUnDwvUc9tlLsiDCQBGblmKXdnvCpavA5tj2 QvPqMOAZ7jDuGeBS6DiuVM9gXdAfUXh5y74XgQYTlQnTOdKHAlG2YX90V9YgDwzyB9ac Ex4af8vfO++g6A61fBg+Fpd96qReBOaYWjg1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=hBvkYyLiwXzsv0aCYqe5auFWWovCdqR27A4bLCR+a6w9aj+A19FyZ9Ufwk1EPNYXfn BmXUejFff0P355ywpYElY0Z3mT6TuWZ9xo1rmc4c5DwXd+/6obYTGQInFzbu5jXvPlma xARdlnsu+/DKizSd7PjKeI4S5TPIC7UUTL6aA= Received: by 10.91.53.11 with SMTP id f11mr339196agk.100.1265908189716; Thu, 11 Feb 2010 09:09:49 -0800 (PST) Received: from ?192.168.0.31? (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 15sm1781413gxk.0.2010.02.11.09.09.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Feb 2010 09:09:48 -0800 (PST) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 11 Feb 2010 11:09:43 -0600 From: Henry Sinnreich To: Dean Willis , Dan Wing Message-ID: Thread-Topic: [sipcore] continued need for SIP identity Thread-Index: AcqrPQDn4zO5lTEIYE2rAxtY5RSdeg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] continued need for SIP identity X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:08:43 -0000 Fully concur. Henry On 2/11/10 10:22 AM, "Dean Willis" wrote: > > On Feb 10, 2010, at 1:35 PM, Dan Wing wrote: > >> Two issues this month demonstrate SIP would still benefit from >> identity: >> >> 1. SIP attacks on the Internet are causing a lot of RTP traffic to >> 1.1.1.1, >> see [1] and [2]. This is a real-life "voice hammer" attack, as >> described in >> [3]. ICE, implemented on the victim endpoint, would help reduce the >> amount of >> traffic but would not block the attack itself. A whitelist could >> block the >> attack but only until attackers guess common entries on the >> whitelist. SIP >> identity prevents identity spoofing, so attackers receive no value by >> attempting to spoof caller identities. >> >> 2. SIP identity allows better-than-PSTN caller identity, allowing a >> SIP >> network to better protect itself from caller ID fraud occuring on >> the PSTN >> [4], [5]. Thus, SIP could be "better than the PSTN" -- which has >> always been >> SIP's goal. > > Dan, you're preaching to a whole bunch of people who just want to > blindly re-create the PSTN. There's no point in trying to convince > them to do something better. They can't envision it, don't want to > understand it, and their employers and governments are actively trying > to block it. Give up and let Facebook and Google take over the world's > communications infrastructure and let the dinosaurs go extinct in > their own good time. > > On the other hand, we do have this going on: > > http://www.aolnews.com/nation/article/congress-takes-aim-at-fake-caller-ids/19 > 282650 > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From salvatore.loreto@ericsson.com Thu Feb 11 10:43:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B464C3A7662 for ; Thu, 11 Feb 2010 10:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.566, 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 NgkdK-FiaC5m for ; Thu, 11 Feb 2010 10:43:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9483B28C1C6 for ; Thu, 11 Feb 2010 10:43:08 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-01-4b745005b529 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1C.02.02429.500547B4; Thu, 11 Feb 2010 19:44:22 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 19:44:21 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 19:44:21 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5F00B25D4; Thu, 11 Feb 2010 20:44:21 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 17ACD21A41; Thu, 11 Feb 2010 20:44:21 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7AA91219D2; Thu, 11 Feb 2010 20:44:20 +0200 (EET) Message-ID: <4B745004.6070202@ericsson.com> Date: Thu, 11 Feb 2010 20:44:20 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Michael Procter References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B728FE0.9020009@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 11 Feb 2010 18:44:21.0296 (UTC) FILETIME=[396E9B00:01CAAB4A] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:43:09 -0000 Hi Michael, see my answers in line. Cheers Sal On 02/10/2010 05:01 PM, Michael Procter wrote: > On 10 February 2010 10:52, Salvatore Loreto > wrote: > >> If people agree we can insert in the draft at the end of Section 6.3 some >> text like the following: >> >> In some situation it may be beneficial for the Notifier to achieve an >> average rate >> in a different way than the algorithm detailed in this document allows. >> However, the Notifier MUST NOT be more aggressive that the "min-interval" >> parameter allows. >> >> > I'm happy in principle, but I'll suggest the following wording instead: > > In some situations it may be beneficial for the Notifier to use a > different approach > to achieve the average interval. However, the Notifier MUST comply with any > "min-interval" or "max-interval" parameters that have been negotiated. > I have been thinking for a while about the "max-interval", and I tend to agree about the need to specify also it in the text so to avoid different possible interpretations. So I propose the following text In some situation it may be beneficial for the Notifier to achieve an average rate in a different way than the algorithm detailed in this document allows. However, the Notifier MUST comply with any "min-interval" or "max-interval" parameters that have been negotiated. > > > Section 6.2 contains this text, which seems to mandate use of the > formula as an effective upper bound: > > A compliant notifier MUST generate notifications whenever the time > since the most recent notification exceeds the value calculated using > the formula defined in Section 6.3. > > I'm not sure what this paragraph adds over the rest of the text in 6.2 > and 6.3, so I think you can simply remove it. > I am to let the paragraph stay there, however to allow a divergence in particular circumstances we will change the MUST in SHOULD A compliant notifier SHOULD generate notifications whenever the time since the most recent notification exceeds the value calculated using the formula defined in Section 6.3. > >> Cheers >> /Sal >> > Best regards, > > Michael > From root@core3.amsl.com Sat Feb 13 10:30:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 56BF13A7372; Sat, 13 Feb 2010 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100213183002.56BF13A7372@core3.amsl.com> Date: Sat, 13 Feb 2010 10:30:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 18:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al. Filename : draft-ietf-sipcore-rfc4244bis-00.txt Pages : 61 Date : 2010-02-13 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. A SIP/SIPS URI parameter is defined to tag information necessary to populate the History-Info header. In addition, this document defines a value for the Privacy header specific to the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc4244bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-13101958.I-D@ietf.org> --NextPart-- From mary.ietf.barnes@gmail.com Sat Feb 13 11:06:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793B53A7851 for ; Sat, 13 Feb 2010 11:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 oX-bXxxP3Z4d for ; Sat, 13 Feb 2010 11:06:02 -0800 (PST) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id 9000A3A709E for ; Sat, 13 Feb 2010 11:06:02 -0800 (PST) Received: by iwn10 with SMTP id 10so570883iwn.13 for ; Sat, 13 Feb 2010 11:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TfxD/p6BIDTiR31+xUoZrRskMCmSGSDzPI+zQFbZ5YA=; b=jIIlOWviY8wL81ap3flSis02q3jhPqgFQB8G5xeKkwDRXUWSmdwJnerbPI6cl9Ia8Q uWggHPabkkr/jw4/CDfugIAUo02vUHF597ZqaShTdgThoA6Au5LjD8tlf9L/KERtcjes /fH9/h+7g5gbsD5aBDz2rQvgCfLcqbAkILzDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=gnhzvtthvzMKP/fawH9rLOEf39ck0WdspZ4GFHGZ1a+o1wrmetu0iuva1x4DJ2+0ho 0Ql7lGw8Xde4Ln5NX2gVPuIDgkIymQ25wgtx/4uX1Djao/Et9FWPufy5b2i05CllZefU ugcaLDVmW+fTfI6suSpGBuJMzXqI0+P2rQc/E= MIME-Version: 1.0 Received: by 10.231.154.207 with SMTP id p15mr2267935ibw.71.1266088043072; Sat, 13 Feb 2010 11:07:23 -0800 (PST) In-Reply-To: <20100213183002.56BF13A7372@core3.amsl.com> References: <20100213183002.56BF13A7372@core3.amsl.com> Date: Sat, 13 Feb 2010 13:07:23 -0600 Message-ID: <184b5e71002131107h6aad1ddcla87d3b316d04bbec@mail.gmail.com> From: Mary Barnes To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] Fwd: I-D Action:draft-ietf-sipcore-rfc4244bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 19:06:03 -0000 Hi all, We have updated the 4244bis document and submitted as a WG document per the IETF-76 discussions. The following summarizes the changes from draft-barnes-sipcore-rfc4244bis-03.txt: 1) Added a new SIP/SIPS URI parameter to tag the URIs as they are added to the target list and those returned in the contact header in a 3xx response. This new parameter is added for the registered contact and mapping scenarios. Thus, we made the following two changes: a) Updated description of "target" parameter to use the new URI parameter value in setting the value for the parameter. b) Changed handling at redirect server to include the use of the new URI parameter and to remove the functionality of adding the History-Info entries (basically reverting to core 4244 processing). 2) Reverted UAC processing to be optional in terms of maintaining previous HI entries in cases of redirection (i.e., it's back to the way it was in RFC 4244). 3) Clarified privacy. 4) Additional text added to scenarios to clarify some services (such as voicemail) can be done in multiple ways. Updated scenarios to match protocol changes. 5) Editorial changes including removal of some vestiges of tagging all entries (including the "aor" tag). The solution is now much simpler than previous versions of the document - the normative protocol aspects are covered in around 10 pages. Feedback would be appreciated. The diff is fairly useful in pinpointing the changes from the previous version. Thanks, Mary et al ---------- Forwarded message ---------- From: Date: Sat, Feb 13, 2010 at 12:30 PM Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-00.txt To: i-d-announce@ietf.org Cc: sipcore@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Init= iation Protocol (SIP) for Request History Information =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al. =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-00.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 61 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-02-13 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. =A0This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. =A0This document defines an optional SIP header, History-Info, for capturing the history information in requests. =A0A SIP/SIPS URI parameter is defined to tag information necessary to populate the History-Info header. =A0In addition, this document defines a value for the Privacy header specific to the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From michael@voip.co.uk Tue Feb 16 01:20:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1F73A7C75 for ; Tue, 16 Feb 2010 01:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TnKWsD9zienP for ; Tue, 16 Feb 2010 01:20:39 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 222DB3A7C51 for ; Tue, 16 Feb 2010 01:20:38 -0800 (PST) Received: from source ([209.85.220.215]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKS3pjxCjk07Jzockd6GMOWEM6SfOjusI0@postini.com; Tue, 16 Feb 2010 01:22:13 PST Received: by mail-fx0-f215.google.com with SMTP id 7so6046781fxm.8 for ; Tue, 16 Feb 2010 01:22:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.102.216.24 with SMTP id o24mr4650090mug.13.1266312132104; Tue, 16 Feb 2010 01:22:12 -0800 (PST) In-Reply-To: <4B745004.6070202@ericsson.com> References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B728FE0.9020009@ericsson.com> <4B745004.6070202@ericsson.com> Date: Tue, 16 Feb 2010 09:22:12 +0000 Message-ID: From: Michael Procter To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 09:20:41 -0000 Hi Sal, My overarching concern is to ensure that notifiers are not compelled to use the formula described in 6.3. I think this set of changes just about permits that. I think that your 'SHOULD' is still too strong, but if that is as far as you are able to go, then so be it. Regards, Michael On 11 February 2010 18:44, Salvatore Loreto wrote: > Hi Michael, > > see my answers in line. > > Cheers > Sal > > On 02/10/2010 05:01 PM, Michael Procter wrote: >> >> On 10 February 2010 10:52, Salvatore Loreto >> =A0wrote: >> >>> >>> If people agree we can insert in the draft at the end of Section 6.3 so= me >>> text like the following: >>> >>> =A0 In some situation it may be beneficial for the Notifier to achieve = an >>> =A0 average rate >>> =A0 in a different way than the algorithm detailed in this document all= ows. >>> =A0 However, the Notifier MUST NOT be more aggressive that the >>> "min-interval" >>> =A0 parameter allows. >>> >>> >> >> I'm happy in principle, but I'll suggest the following wording instead: >> >> =A0 In some situations it may be beneficial for the Notifier to use a >> different approach >> =A0 to achieve the average interval. =A0However, the Notifier MUST compl= y with >> any >> =A0 "min-interval" or "max-interval" parameters that have been negotiate= d. >> > > I have been thinking for a while about the "max-interval", > and I tend to agree about the need to specify also it in the text so > to avoid different possible interpretations. > So I propose the following text > > =A0In some situation it may be beneficial for the Notifier to achieve an > =A0average rate =A0 in a different way than the algorithm detailed in thi= s > =A0document allows. However, the Notifier MUST comply with any > =A0"min-interval" or "max-interval" parameters that have been negotiated. > >> >> >> Section 6.2 contains this text, which seems to mandate use of the >> formula as an effective upper bound: >> >> =A0 =A0A compliant notifier MUST generate notifications whenever the tim= e >> =A0 =A0since the most recent notification exceeds the value calculated u= sing >> =A0 =A0the formula defined in Section 6.3. >> =A0 I'm not sure what this paragraph adds over the rest of the text in 6= .2 >> and 6.3, so I think you can simply remove it. >> > > I am to let the paragraph stay there, however to allow a divergence in > particular circumstances we will change the MUST in SHOULD > > =A0 A compliant notifier SHOULD generate notifications whenever the time > =A0 since the most recent notification exceeds the value calculated using > =A0 the formula defined in Section 6.3. > >> >>> >>> Cheers >>> /Sal >>> >> >> Best regards, >> >> Michael >> > > From root@core3.amsl.com Tue Feb 16 09:15:03 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E250C3A7D6E; Tue, 16 Feb 2010 09:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100216171501.E250C3A7D6E@core3.amsl.com> Date: Tue, 16 Feb 2010 09:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sipcore-location-conveyance-02.txt Pages : 52 Date : 2010-2-12 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end-to-end conveyance as well as location-based routing, where SIP servers make routing decisions based upon the location of the user agent client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-location-conveyance-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-2-16090256.I-D@ietf.org> --NextPart-- From brett@broadsoft.com Wed Feb 17 05:50:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD0D3A7530 for ; Wed, 17 Feb 2010 05:50:51 -0800 (PST) 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 mf8MqvqXwK73 for ; Wed, 17 Feb 2010 05:50:50 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id C04EB3A711D for ; Wed, 17 Feb 2010 05:50:50 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 17 Feb 2010 05:52:26 -0800 From: Brett Tate To: SIPCORE Date: Wed, 17 Feb 2010 05:51:50 -0800 Thread-Topic: RFC 4028 Errata ID 1681: From tag not changing Thread-Index: Acqv2Fru32z5R/9eTOW99NKpImiwzQ== Message-ID: <747A6506A991724FB09B129B79D5FEB61460173AD4@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] RFC 4028 Errata ID 1681: From tag not changing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 13:50:51 -0000 Concerning RFC 4028 Errata ID 1681, I disagree with the suggested resolutio= n. The following is the link to the errata: http://www.rfc-editor.org/errata_search.php?eid=3D1681 =20 http://www.nostrum.com/~rjsparks/rai-errata-batch1.html suggests to approve= the 1681 errata. However RFC 3261 section 8.1.3.5 conflicts with the erra= ta since it indicates that the From SHOULD be the same. Thanks, Brett From gonzalo.camarillo@ericsson.com Thu Feb 18 05:05:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A89E28C1CF for ; Thu, 18 Feb 2010 05:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.056 X-Spam-Level: X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 obp+ZTkIoooJ for ; Thu, 18 Feb 2010 05:05:17 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 41C6A3A7C20 for ; Thu, 18 Feb 2010 05:05:17 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-cf-4b7d3b71d8ac Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F6.00.31641.17B3D7B4; Thu, 18 Feb 2010 14:06:58 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 14:07:05 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 14:07:05 +0100 Message-ID: <4B7D3B71.3030805@ericsson.com> Date: Thu, 18 Feb 2010 15:06:57 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Procter References: <20100108210001.E16FD3A686B@core3.amsl.com> <4B728FE0.9020009@ericsson.com> <4B745004.6070202@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2010 13:07:05.0765 (UTC) FILETIME=[4501DD50:01CAB09B] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 13:05:18 -0000 Hi, this WGLC will end in a few days. I would like to ask the authors to revise the draft addressing all the comments received as soon as the WGLC is over so that we can move it forward. Thanks, Gonzalo Michael Procter wrote: > Hi Sal, > > My overarching concern is to ensure that notifiers are not compelled > to use the formula described in 6.3. I think this set of changes just > about permits that. I think that your 'SHOULD' is still too strong, > but if that is as far as you are able to go, then so be it. > > Regards, > > Michael > > On 11 February 2010 18:44, Salvatore Loreto > wrote: >> Hi Michael, >> >> see my answers in line. >> >> Cheers >> Sal >> >> On 02/10/2010 05:01 PM, Michael Procter wrote: >>> On 10 February 2010 10:52, Salvatore Loreto >>> wrote: >>> >>>> If people agree we can insert in the draft at the end of Section 6.3 some >>>> text like the following: >>>> >>>> In some situation it may be beneficial for the Notifier to achieve an >>>> average rate >>>> in a different way than the algorithm detailed in this document allows. >>>> However, the Notifier MUST NOT be more aggressive that the >>>> "min-interval" >>>> parameter allows. >>>> >>>> >>> I'm happy in principle, but I'll suggest the following wording instead: >>> >>> In some situations it may be beneficial for the Notifier to use a >>> different approach >>> to achieve the average interval. However, the Notifier MUST comply with >>> any >>> "min-interval" or "max-interval" parameters that have been negotiated. >>> >> I have been thinking for a while about the "max-interval", >> and I tend to agree about the need to specify also it in the text so >> to avoid different possible interpretations. >> So I propose the following text >> >> In some situation it may be beneficial for the Notifier to achieve an >> average rate in a different way than the algorithm detailed in this >> document allows. However, the Notifier MUST comply with any >> "min-interval" or "max-interval" parameters that have been negotiated. >> >>> >>> Section 6.2 contains this text, which seems to mandate use of the >>> formula as an effective upper bound: >>> >>> A compliant notifier MUST generate notifications whenever the time >>> since the most recent notification exceeds the value calculated using >>> the formula defined in Section 6.3. >>> I'm not sure what this paragraph adds over the rest of the text in 6.2 >>> and 6.3, so I think you can simply remove it. >>> >> I am to let the paragraph stay there, however to allow a divergence in >> particular circumstances we will change the MUST in SHOULD >> >> A compliant notifier SHOULD generate notifications whenever the time >> since the most recent notification exceeds the value calculated using >> the formula defined in Section 6.3. >> >>>> Cheers >>>> /Sal >>>> >>> Best regards, >>> >>> Michael >>> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Feb 19 03:26:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E8828C19D for ; Fri, 19 Feb 2010 03:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, 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 s1XEHtVmvAoL for ; Fri, 19 Feb 2010 03:26:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F29D628C0EB for ; Fri, 19 Feb 2010 03:26:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bb-4b7e75d92ac1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 47.70.02429.9D57E7B4; Fri, 19 Feb 2010 12:28:25 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 19 Feb 2010 12:28:25 +0100 From: Christer Holmberg To: SIPCORE Date: Fri, 19 Feb 2010 12:28:23 +0100 Thread-Topic: OPTIONS: How to solve the forking problem? Thread-Index: AcqxVqWSeI3RpF7QQViPA2REdajiDg== 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_FF84A09F50A6DC48ACB6714F4666CC744751A5A7D7ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 11:26:49 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC744751A5A7D7ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some input regarding the OPTIONS issue. BACKGROUND: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D One of the main problems with OPTIONS is forking. In case the request is fo= rked, the UAC will only receive the capabilities of one device/UAS (which U= AS depends on which 200 OK reaches the forking proxy first). OPTIONS works fine in HTTP, where we don't have forking and an HTTP URI alw= ays identify uniquely a specific resource or a specific server. But, if I address the request to an AOR (which points to a domain, not to a= specific device) I might want to receive capabilities of all the UAS assoc= iated with that AOR/domain. First, do we agree that is a valid usage to address OPTIONS to an AOR? OR, do we think that OPTIONS should only be addressed to specific devices (= section 11 of 3261 talks about devices), in which case I guess we don't nee= d to do anything - at least not as far as forking is concerned. The rest of this e-mail is based on the assumption that we DO want to be ab= le to address OPTIONS to an AOR. ABSTRACT: =3D=3D=3D=3D=3D=3D=3D=3D=3D I have put together 3 alternative solutions on how the problem could be fix= ed. The first alternative is based on a UAS change, while the second and th= ird alternatives are based on a model where the registrar (forking proxy) s= ends a response "on behalf" of the UAS(s). The 4th alternative is of course that we do nothing, but based on previous = discussions it does seem that some people are interested in doing something= about OPTIONS. ALTERNATIVE 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In this alternative the UAS(s) send a provisional response, including the c= apabilities, to the OPTIONS request. The registrar will (hopefully) forward= all the provisional responses towards the UAC. Pros/cons: ---------------- + The major advantage of this mechanism is that it allows the UAC to get th= e capabilities of all UAS(s) associated with the AOR. + No impacts on registrar - Does not work with deployed Uas - Would the provisional response need to be PRACKed? What to do: ----------------- This alternative would most likely require an RFC: either an extension with= an associated option-tag, or an update to 3261. ALTERNATIVE 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In this alternative the registrar never forks the OPTIONS request towards t= he UAS(s). Instead, it sends a response on behalf of the UASs, based on the= information is has about the UAS(s), based on registration information (fe= ature tags etc) etc. The first question is whether 3261 already allows this: When a UAC sends an OPTIONS request addressed to an AOR, I expect to get ca= pabilities associated with that AOR (which points to a domain, not to a spe= cific device). Currently, in case of forking, I will only get the capabilit= ies from one device/UAS associated with that domain. But, if the registrar sends the OPTIONS response, it can provide capabiliti= es of all registered UAS(s) associated with the AOR/domain. So, so far I don't think 3261 forbids this kind of behavior (in fact, I thi= nk this kind of behavior actually better implements what is described in 32= 61...) Now, the best way to return the capabilities would probably be by using a m= essage body, e.g. a multipart with sipfrag body parts (each sipfrag body pa= rt representing a UAS). But, RFC3261 says that a proxy does not insert a message body in the OPTION= S response, and that is probably ok in most cases when the proxy returns it= s owns capabilities. But, when the proxy replies on behalf of the UAS(s), I= see no reason why it should not be allowed to include a body. The UAC will= get the capabilities of the UAS(s), and that is what matters. Pros/cons: ---------------- + The major advantage of this mechanism is that it allows the UAC to get th= e capabilities of all UAS(s) associated with the AOR. + In my personal opinion this does not require any changes in RFC3261 - The set of capabilities per UAS is limited to what the registrar knows ab= out the UAS (based on registration information, and/or by provisioning), so= SDP information would probably be left out. The mechanism might still be g= ood enough for many scenarios, though. What to do: ----------------- If we think RFC3261 allows this, the question is whether we consider it so = crystal clear that nothing needs to be specified, or whether it would be a = good idea to put together a BCP type-of document describing it. Or, do people think that this is NOT allowed behavior? ALTERNATIVE 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The idea is similar to Alternative 1, but in this case the registrar would = fork the OPTIONS request towards the UAS(s), then "COLLECT" the responses, = and finally send a single response which contains the capabilities of all U= AS(s) towards the UAC. Prox/Cons: ---------------- + The major advantage of this mechanism is that it allows the UAC to get th= e capabilities of all UAS(s). + The UAC will get more or less the same set of capabilities for an UAS, as= if the UAS would have sent the response directly to the UAC. - I guess most people would consider the forking proxy acting as a B2BUA in= this case, since it does not follow the 3261 rules about forwarding (or di= scarding) 200 OK responses immediately when received. What to do: ----------------- If we think this is a good solution, could it be described in a BCP? I gues= s we would not update 3261 to describe this behavior? Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC744751A5A7D7ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Some input regarding the OPTIONS issue.
 
BACKGROUND:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
One of the main problems with OPTIONS is forking. In case the request = is forked, the UAC will only receive the capabilities of one device/UAS (wh= ich UAS depends on which 200 OK reaches the forking proxy first).
 
OPTIONS works fine in HTTP, where we don't have forking and an HTTP UR= I always identify uniquely a specific resource or a specific server.
 
But, if I address the request to an AOR (which points to a domain, not= to a specific device) I might want to receive capabilities of all the UAS = associated with that AOR/domain.
 
First, do we agree that is a valid usage to address OPTIONS to an AOR?=
 
OR, do we think that OPTIONS should only be addressed to specific devi= ces (section 11 of 3261 talks about devices), in which case I guess we don'= t need to do anything - at least not as far as forking is concerned.
 
The rest of this e-mail is based on the assumption that we DO want to = be able to address OPTIONS to an AOR.
 
 
ABSTRACT:
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
I have put together 3 alternative solutions on how the problem could b= e fixed. The first alternative is based on a UAS change, while the second a= nd third alternatives are based on a model where the registrar (forking pro= xy) sends a response "on behalf" of the UAS(s).
 
The 4th alternative is of course that we do nothing, but based on prev= ious discussions it does seem that some people are interested in doing some= thing about OPTIONS.
 
 
ALTERNATIVE 1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
In this alternative the UAS(s) send a provisional response, including = the capabilities, to the OPTIONS request. The registrar will (hopefully) fo= rward all the provisional responses towards the UAC.
 
Pros/cons:
----------------
 
+ The major advantage of this mechanism is that it allows the UAC = to get the capabilities of all UAS(s) associated with the AOR.
+ No impacts on registrar
 
- Does not work with deployed Uas
- Would the provisional response need to be PRACKed?
 
What to do:
-----------------
 
This alternative would most likely require an RFC: either an extension= with an associated option-tag, or an update to 3261.
 
 
 
ALTERNATIVE 2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
In this alternative the registrar never forks the OPTIONS request towa= rds the UAS(s). Instead, it sends a response on behalf of the UASs, based o= n the information is has about the UAS(s), based on registration informatio= n (feature tags etc) etc.
 
The first question is whether 3261 already allows this:
 
When a UAC sends an OPTIONS request addressed to an AOR, I expect to g= et capabilities associated with that AOR (which points to a domain, not to = a specific device). Currently, in case of forking, I will only get the capa= bilities from one device/UAS associated with that domain.
 
But, if the registrar sends the OPTIONS response, it can provide capab= ilities of all registered UAS(s) associated with the AOR/domain.
 
So, so far I don't think 3261 forbids this kind of behavior (in fact, = I think this kind of behavior actually better implements what is described = in 3261…)
 
 
Now, the best way to return the capabilities would probably be by usin= g a message body, e.g. a multipart with sipfrag body parts (each sipfrag bo= dy part representing a UAS).
 
But, RFC3261 says that a proxy does not insert a message body in the O= PTIONS response, and that is probably ok in most cases when the proxy retur= ns its owns capabilities. But, when the proxy replies on behalf of the UAS(= s), I see no reason why it should not be allowed to include a body. The UAC will get the capabilities of the = UAS(s), and that is what matters.
 
Pros/cons:
----------------
 
+ The major advantage of this mechanism is that it allows the UAC = to get the capabilities of all UAS(s) associated with the AOR.
+ In my personal opinion this does not require any changes in RFC3= 261
 
- The set of capabilities per UAS is limited to what the registrar kno= ws about the UAS (based on registration information, and/or by provisioning= ), so SDP information would probably be left out. The mechanism might still= be good enough for many scenarios, though.
 
What to do:
-----------------
 
If we think RFC3261 allows this, the question is whether we consider i= t so crystal clear that nothing needs to be specified, or whether it would = be a good idea to put together a BCP type-of document describing it.
 
Or, do people think that this is NOT allowed behavior?
 
 
 
 
ALTERNATIVE 3:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The idea is similar to Alternative 1, but in this case the registrar w= ould fork the OPTIONS request towards the UAS(s), then "COLLECT" = the responses, and finally send a single response which contains the capabi= lities of all UAS(s) towards the UAC.
 
Prox/Cons:
----------------
 
+ The major advantage of this mechanism is that it allows the UAC = to get the capabilities of all UAS(s).
+ The UAC will get more or less the same set of capabilities for a= n UAS, as if the UAS would have sent the response directly to the UAC.
 
- I guess most people would consider the forking proxy acting as a B2B= UA in this case, since it does not follow the 3261 rules about forwarding (= or discarding) 200 OK responses immediately when received.
 
What to do:
-----------------
 
If we think this is a good solution, could it be described in a BCP? I= guess we would not update 3261 to describe this behavior?
 
 
 
Regards,
 
Christer
 
 
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC744751A5A7D7ESESSCMS0354e_-- From john.elwell@siemens-enterprise.com Fri Feb 19 05:57:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B429F3A8166 for ; Fri, 19 Feb 2010 05:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 uRH8e34a0nIv for ; Fri, 19 Feb 2010 05:57:37 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 270DB3A7CBF for ; Fri, 19 Feb 2010 05:57:36 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-948079; Fri, 19 Feb 2010 14:59:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8D0731EB82B0; Fri, 19 Feb 2010 14:59:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 14:59:22 +0100 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Fri, 19 Feb 2010 14:59:20 +0100 Thread-Topic: OPTIONS: How to solve the forking problem? Thread-Index: AcqxVqWSeI3RpF7QQViPA2REdajiDgAEKa8Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 13:57:38 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 19 February 2010 11:28 > To: SIPCORE > Subject: [sipcore] OPTIONS: How to solve the forking problem? >=20 > Hi, > =20 > Some input regarding the OPTIONS issue. > =20 > BACKGROUND: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > One of the main problems with OPTIONS is forking. In case the=20 > request is forked, the UAC will only receive the capabilities=20 > of one device/UAS (which UAS depends on which 200 OK reaches=20 > the forking proxy first). > =20 > OPTIONS works fine in HTTP, where we don't have forking and=20 > an HTTP URI always identify uniquely a specific resource or a=20 > specific server.=20 > =20 > But, if I address the request to an AOR (which points to a=20 > domain, not to a specific device) I might want to receive=20 > capabilities of all the UAS associated with that AOR/domain.=20 > =20 > First, do we agree that is a valid usage to address OPTIONS=20 > to an AOR?=20 > =20 > OR, do we think that OPTIONS should only be addressed to=20 > specific devices (section 11 of 3261 talks about devices), in=20 > which case I guess we don't need to do anything - at least=20 > not as far as forking is concerned. > =20 > The rest of this e-mail is based on the assumption that we DO=20 > want to be able to address OPTIONS to an AOR. > =20 > =20 > ABSTRACT: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > I have put together 3 alternative solutions on how the=20 > problem could be fixed. The first alternative is based on a=20 > UAS change, while the second and third alternatives are based=20 > on a model where the registrar (forking proxy) sends a=20 > response "on behalf" of the UAS(s). > =20 > The 4th alternative is of course that we do nothing, but=20 > based on previous discussions it does seem that some people=20 > are interested in doing something about OPTIONS. > =20 > =20 > ALTERNATIVE 1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > In this alternative the UAS(s) send a provisional response,=20 > including the capabilities, to the OPTIONS request. The=20 > registrar will (hopefully) forward all the provisional=20 > responses towards the UAC. > =20 > Pros/cons: > ---------------- > =20 > + The major advantage of this mechanism is that it allows the=20 > UAC to get the capabilities of all UAS(s) associated with the AOR. > + No impacts on registrar > =20 > - Does not work with deployed Uas > - Would the provisional response need to be PRACKed? [JRE] I hope this Alternative 1 is not meant to be serious. This would be c= ontrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisional = response for a non-INVITE request". I wonder how many SIP stacks would hand= le this. Also, having sent a provisional response, the UAS needs to send a = final response, so how would this interact? > =20 > What to do: > ----------------- > =20 > This alternative would most likely require an RFC: either an=20 > extension with an associated option-tag, or an update to 3261. > =20 > =20 > =20 > ALTERNATIVE 2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > In this alternative the registrar never forks the OPTIONS=20 > request towards the UAS(s). Instead, it sends a response on=20 > behalf of the UASs, based on the information is has about the=20 > UAS(s), based on registration information (feature tags etc) etc. > =20 > The first question is whether 3261 already allows this: > =20 > When a UAC sends an OPTIONS request addressed to an AOR, I=20 > expect to get capabilities associated with that AOR (which=20 > points to a domain, not to a specific device). Currently, in=20 > case of forking, I will only get the capabilities from one=20 > device/UAS associated with that domain. > =20 > But, if the registrar sends the OPTIONS response, it can=20 > provide capabilities of all registered UAS(s) associated with=20 > the AOR/domain. > =20 > So, so far I don't think 3261 forbids this kind of behavior=20 > (in fact, I think this kind of behavior actually better=20 > implements what is described in 3261...) > =20 > =20 > Now, the best way to return the capabilities would probably=20 > be by using a message body, e.g. a multipart with sipfrag=20 > body parts (each sipfrag body part representing a UAS). [JRE] And that sipfrag body part would need to contain an SDP body part to = represent the SDP capabilities of the UAS? This would make responses potent= ially very large, posing a problem for UDP. It is probably a more extreme e= xample than anything we have had before of a response being VERY MUCH large= r than a request. > =20 > But, RFC3261 says that a proxy does not insert a message body=20 > in the OPTIONS response, and that is probably ok in most=20 > cases when the proxy returns its owns capabilities. But, when=20 > the proxy replies on behalf of the UAS(s), I see no reason=20 > why it should not be allowed to include a body. The UAC will=20 > get the capabilities of the UAS(s), and that is what matters. [JRE] In this case what you call the proxy is the UAS w.r.t. this particula= r transaction, so it can include a body. > =20 > Pros/cons: > ---------------- > =20 > + The major advantage of this mechanism is that it allows the=20 > UAC to get the capabilities of all UAS(s) associated with the AOR. [JRE] I am not sure what it needs this for, but we have the reg-event packa= ge to identify all registered Uas, and then OPTIONS could be directed at ea= ch in turn. > + In my personal opinion this does not require any changes in RFC3261 > =20 > - The set of capabilities per UAS is limited to what the=20 > registrar knows about the UAS (based on registration=20 > information, and/or by provisioning), so SDP information=20 > would probably be left out. The mechanism might still be good=20 > enough for many scenarios, though. > =20 > What to do: > ----------------- > =20 > If we think RFC3261 allows this, the question is whether we=20 > consider it so crystal clear that nothing needs to be=20 > specified, or whether it would be a good idea to put together=20 > a BCP type-of document describing it. > =20 > Or, do people think that this is NOT allowed behavior? [JRE] Even if allowed, I think we might need some specification of the sipf= rag part of it, and I am concerned about the response size. But I am not co= nvinced there is a requirement to be able to use OPTIONS to get information= about multiple UAs at once. > =20 > =20 > =20 > =20 > ALTERNATIVE 3: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > The idea is similar to Alternative 1, but in this case the=20 > registrar would fork the OPTIONS request towards the UAS(s),=20 > then "COLLECT" the responses, and finally send a single=20 > response which contains the capabilities of all UAS(s)=20 > towards the UAC. [JRE] Again using sipfrags? > =20 > Prox/Cons: > ---------------- > =20 > + The major advantage of this mechanism is that it allows the=20 > UAC to get the capabilities of all UAS(s). > + The UAC will get more or less the same set of capabilities=20 > for an UAS, as if the UAS would have sent the response=20 > directly to the UAC. > =20 > - I guess most people would consider the forking proxy acting=20 > as a B2BUA in this case, since it does not follow the 3261=20 > rules about forwarding (or discarding) 200 OK responses=20 > immediately when received. > =20 > What to do: > ----------------- > =20 > If we think this is a good solution, could it be described in=20 > a BCP? I guess we would not update 3261 to describe this behavior? [JRE] Again we would need to specify the sipfrag bits of it, and I would be= concerned about the response size. John From pkyzivat@cisco.com Fri Feb 19 06:20:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A731228C288 for ; Fri, 19 Feb 2010 06:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gKS1OcPiI9LW for ; Fri, 19 Feb 2010 06:20:52 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 759D53A7EB6 for ; Fri, 19 Feb 2010 06:20:52 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJMtfktAZnwM/2dsb2JhbACbB3SlDZd9gkiCHwSDFQ X-IronPort-AV: E=Sophos;i="4.49,503,1262563200"; d="scan'208";a="87473522" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2010 14:22:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JEMcFg010299; Fri, 19 Feb 2010 14:22:38 GMT Message-ID: <4B7E9EAD.20201@cisco.com> Date: Fri, 19 Feb 2010 09:22:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 14:20:54 -0000 I pretty much agree with John. IMO there is no point in doing anything unless there is also work to clarify what the response *means* in a way that is operationally useful. Even when there is only one UA and the OPTIONS request is getting to it, the result isn't especially useful, except as a "ping" because: - nominally the response code is supposed to be the same as it would be for an INVITE. I guess that means you should get a 486 response if the UA is on a call and would reject another. But what if the UA *never* accepts INVITES - only SUBSCRIBE? Should you get 405? - If the UA can in principle support a lot of things, but not all in the same call, there is no well defined way to reflect that. I would like to see a set of use cases for how people would like to use OPTIONS where this enhancement is needed. Thanks, Paul Elwell, John wrote: > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 19 February 2010 11:28 >> To: SIPCORE >> Subject: [sipcore] OPTIONS: How to solve the forking problem? >> >> Hi, >> >> Some input regarding the OPTIONS issue. >> >> BACKGROUND: >> ============ >> >> One of the main problems with OPTIONS is forking. In case the >> request is forked, the UAC will only receive the capabilities >> of one device/UAS (which UAS depends on which 200 OK reaches >> the forking proxy first). >> >> OPTIONS works fine in HTTP, where we don't have forking and >> an HTTP URI always identify uniquely a specific resource or a >> specific server. >> >> But, if I address the request to an AOR (which points to a >> domain, not to a specific device) I might want to receive >> capabilities of all the UAS associated with that AOR/domain. >> >> First, do we agree that is a valid usage to address OPTIONS >> to an AOR? >> >> OR, do we think that OPTIONS should only be addressed to >> specific devices (section 11 of 3261 talks about devices), in >> which case I guess we don't need to do anything - at least >> not as far as forking is concerned. >> >> The rest of this e-mail is based on the assumption that we DO >> want to be able to address OPTIONS to an AOR. >> >> >> ABSTRACT: >> ========= >> >> I have put together 3 alternative solutions on how the >> problem could be fixed. The first alternative is based on a >> UAS change, while the second and third alternatives are based >> on a model where the registrar (forking proxy) sends a >> response "on behalf" of the UAS(s). >> >> The 4th alternative is of course that we do nothing, but >> based on previous discussions it does seem that some people >> are interested in doing something about OPTIONS. >> >> >> ALTERNATIVE 1: >> ============= >> >> In this alternative the UAS(s) send a provisional response, >> including the capabilities, to the OPTIONS request. The >> registrar will (hopefully) forward all the provisional >> responses towards the UAC. >> >> Pros/cons: >> ---------------- >> >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. >> + No impacts on registrar >> >> - Does not work with deployed Uas >> - Would the provisional response need to be PRACKed? > [JRE] I hope this Alternative 1 is not meant to be serious. This would be contrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisional response for a non-INVITE request". I wonder how many SIP stacks would handle this. Also, having sent a provisional response, the UAS needs to send a final response, so how would this interact? > >> >> What to do: >> ----------------- >> >> This alternative would most likely require an RFC: either an >> extension with an associated option-tag, or an update to 3261. >> >> >> >> ALTERNATIVE 2: >> ============= >> >> In this alternative the registrar never forks the OPTIONS >> request towards the UAS(s). Instead, it sends a response on >> behalf of the UASs, based on the information is has about the >> UAS(s), based on registration information (feature tags etc) etc. >> >> The first question is whether 3261 already allows this: >> >> When a UAC sends an OPTIONS request addressed to an AOR, I >> expect to get capabilities associated with that AOR (which >> points to a domain, not to a specific device). Currently, in >> case of forking, I will only get the capabilities from one >> device/UAS associated with that domain. >> >> But, if the registrar sends the OPTIONS response, it can >> provide capabilities of all registered UAS(s) associated with >> the AOR/domain. >> >> So, so far I don't think 3261 forbids this kind of behavior >> (in fact, I think this kind of behavior actually better >> implements what is described in 3261...) >> >> >> Now, the best way to return the capabilities would probably >> be by using a message body, e.g. a multipart with sipfrag >> body parts (each sipfrag body part representing a UAS). > [JRE] And that sipfrag body part would need to contain an SDP body part to represent the SDP capabilities of the UAS? This would make responses potentially very large, posing a problem for UDP. It is probably a more extreme example than anything we have had before of a response being VERY MUCH larger than a request. > >> >> But, RFC3261 says that a proxy does not insert a message body >> in the OPTIONS response, and that is probably ok in most >> cases when the proxy returns its owns capabilities. But, when >> the proxy replies on behalf of the UAS(s), I see no reason >> why it should not be allowed to include a body. The UAC will >> get the capabilities of the UAS(s), and that is what matters. > [JRE] In this case what you call the proxy is the UAS w.r.t. this particular transaction, so it can include a body. > >> >> Pros/cons: >> ---------------- >> >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. > [JRE] I am not sure what it needs this for, but we have the reg-event package to identify all registered Uas, and then OPTIONS could be directed at each in turn. > >> + In my personal opinion this does not require any changes in RFC3261 >> >> - The set of capabilities per UAS is limited to what the >> registrar knows about the UAS (based on registration >> information, and/or by provisioning), so SDP information >> would probably be left out. The mechanism might still be good >> enough for many scenarios, though. >> >> What to do: >> ----------------- >> >> If we think RFC3261 allows this, the question is whether we >> consider it so crystal clear that nothing needs to be >> specified, or whether it would be a good idea to put together >> a BCP type-of document describing it. >> >> Or, do people think that this is NOT allowed behavior? > [JRE] Even if allowed, I think we might need some specification of the sipfrag part of it, and I am concerned about the response size. But I am not convinced there is a requirement to be able to use OPTIONS to get information about multiple UAs at once. > >> >> >> >> >> ALTERNATIVE 3: >> ============= >> >> The idea is similar to Alternative 1, but in this case the >> registrar would fork the OPTIONS request towards the UAS(s), >> then "COLLECT" the responses, and finally send a single >> response which contains the capabilities of all UAS(s) >> towards the UAC. > [JRE] Again using sipfrags? > >> >> Prox/Cons: >> ---------------- >> >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s). >> + The UAC will get more or less the same set of capabilities >> for an UAS, as if the UAS would have sent the response >> directly to the UAC. >> >> - I guess most people would consider the forking proxy acting >> as a B2BUA in this case, since it does not follow the 3261 >> rules about forwarding (or discarding) 200 OK responses >> immediately when received. >> >> What to do: >> ----------------- >> >> If we think this is a good solution, could it be described in >> a BCP? I guess we would not update 3261 to describe this behavior? > [JRE] Again we would need to specify the sipfrag bits of it, and I would be concerned about the response size. > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Feb 19 06:35:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B089E28C0D8 for ; Fri, 19 Feb 2010 06:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 FanyvUm4Ad0m for ; Fri, 19 Feb 2010 06:35:04 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0FAB63A7CDD for ; Fri, 19 Feb 2010 06:35:03 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c2-4b7ea201fec7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 94.06.31641.102AE7B4; Fri, 19 Feb 2010 15:36:49 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 19 Feb 2010 15:36:45 +0100 From: Christer Holmberg To: "Elwell, John" , SIPCORE Date: Fri, 19 Feb 2010 15:36:45 +0100 Thread-Topic: OPTIONS: How to solve the forking problem? Thread-Index: AcqxVqWSeI3RpF7QQViPA2REdajiDgAEKa8QAAIcjXE= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 14:35:05 -0000 Hi John, Thanks for your reply! Regarding the size of the response, for alternative 2 I don't think it will= be an issue. Because, since the forking proxy does not communicate with th= e UAS(s), the response will not contain that much information about each UA= S. For example, there will most likely be no SDP, since UAs don't register = SDP information to the registrar. So, in case the forking proxy only return= s the registered feature tags, there would only be a one or a few header fi= elds per UAS. Maybe we wouldn't even need a sipfrag in that case. The details will have t= o be worked out, once/if we agree to study a specific alternative more in d= etail. In alternative 3 the size would be bigger - at least if the forking proxy r= eturns everything it get from the UAS(s). One solution here could be that a= n OPTIONS addressed to an AOR only returns a limited set of capabilites - p= erhaps only the GRUU for each UAS. Then the UAC can send OPTIONS directly t= o each UAS, in order to retrieve all capabilities. Last, alternative 1 was meant to be serious, but the response you gave is m= ore or less what I expected :) Regards, Christer ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Friday, February 19, 2010 3:59 PM To: Christer Holmberg; SIPCORE Subject: RE: OPTIONS: How to solve the forking problem? > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 19 February 2010 11:28 > To: SIPCORE > Subject: [sipcore] OPTIONS: How to solve the forking problem? > > Hi, > > Some input regarding the OPTIONS issue. > > BACKGROUND: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > One of the main problems with OPTIONS is forking. In case the > request is forked, the UAC will only receive the capabilities > of one device/UAS (which UAS depends on which 200 OK reaches > the forking proxy first). > > OPTIONS works fine in HTTP, where we don't have forking and > an HTTP URI always identify uniquely a specific resource or a > specific server. > > But, if I address the request to an AOR (which points to a > domain, not to a specific device) I might want to receive > capabilities of all the UAS associated with that AOR/domain. > > First, do we agree that is a valid usage to address OPTIONS > to an AOR? > > OR, do we think that OPTIONS should only be addressed to > specific devices (section 11 of 3261 talks about devices), in > which case I guess we don't need to do anything - at least > not as far as forking is concerned. > > The rest of this e-mail is based on the assumption that we DO > want to be able to address OPTIONS to an AOR. > > > ABSTRACT: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > I have put together 3 alternative solutions on how the > problem could be fixed. The first alternative is based on a > UAS change, while the second and third alternatives are based > on a model where the registrar (forking proxy) sends a > response "on behalf" of the UAS(s). > > The 4th alternative is of course that we do nothing, but > based on previous discussions it does seem that some people > are interested in doing something about OPTIONS. > > > ALTERNATIVE 1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In this alternative the UAS(s) send a provisional response, > including the capabilities, to the OPTIONS request. The > registrar will (hopefully) forward all the provisional > responses towards the UAC. > > Pros/cons: > ---------------- > > + The major advantage of this mechanism is that it allows the > UAC to get the capabilities of all UAS(s) associated with the AOR. > + No impacts on registrar > > - Does not work with deployed Uas > - Would the provisional response need to be PRACKed? [JRE] I hope this Alternative 1 is not meant to be serious. This would be c= ontrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisional = response for a non-INVITE request". I wonder how many SIP stacks would hand= le this. Also, having sent a provisional response, the UAS needs to send a = final response, so how would this interact? > > What to do: > ----------------- > > This alternative would most likely require an RFC: either an > extension with an associated option-tag, or an update to 3261. > > > > ALTERNATIVE 2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In this alternative the registrar never forks the OPTIONS > request towards the UAS(s). Instead, it sends a response on > behalf of the UASs, based on the information is has about the > UAS(s), based on registration information (feature tags etc) etc. > > The first question is whether 3261 already allows this: > > When a UAC sends an OPTIONS request addressed to an AOR, I > expect to get capabilities associated with that AOR (which > points to a domain, not to a specific device). Currently, in > case of forking, I will only get the capabilities from one > device/UAS associated with that domain. > > But, if the registrar sends the OPTIONS response, it can > provide capabilities of all registered UAS(s) associated with > the AOR/domain. > > So, so far I don't think 3261 forbids this kind of behavior > (in fact, I think this kind of behavior actually better > implements what is described in 3261...) > > > Now, the best way to return the capabilities would probably > be by using a message body, e.g. a multipart with sipfrag > body parts (each sipfrag body part representing a UAS). [JRE] And that sipfrag body part would need to contain an SDP body part to = represent the SDP capabilities of the UAS? This would make responses potent= ially very large, posing a problem for UDP. It is probably a more extreme e= xample than anything we have had before of a response being VERY MUCH large= r than a request. > > But, RFC3261 says that a proxy does not insert a message body > in the OPTIONS response, and that is probably ok in most > cases when the proxy returns its owns capabilities. But, when > the proxy replies on behalf of the UAS(s), I see no reason > why it should not be allowed to include a body. The UAC will > get the capabilities of the UAS(s), and that is what matters. [JRE] In this case what you call the proxy is the UAS w.r.t. this particula= r transaction, so it can include a body. > > Pros/cons: > ---------------- > > + The major advantage of this mechanism is that it allows the > UAC to get the capabilities of all UAS(s) associated with the AOR. [JRE] I am not sure what it needs this for, but we have the reg-event packa= ge to identify all registered Uas, and then OPTIONS could be directed at ea= ch in turn. > + In my personal opinion this does not require any changes in RFC3261 > > - The set of capabilities per UAS is limited to what the > registrar knows about the UAS (based on registration > information, and/or by provisioning), so SDP information > would probably be left out. The mechanism might still be good > enough for many scenarios, though. > > What to do: > ----------------- > > If we think RFC3261 allows this, the question is whether we > consider it so crystal clear that nothing needs to be > specified, or whether it would be a good idea to put together > a BCP type-of document describing it. > > Or, do people think that this is NOT allowed behavior? [JRE] Even if allowed, I think we might need some specification of the sipf= rag part of it, and I am concerned about the response size. But I am not co= nvinced there is a requirement to be able to use OPTIONS to get information= about multiple UAs at once. > > > > > ALTERNATIVE 3: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The idea is similar to Alternative 1, but in this case the > registrar would fork the OPTIONS request towards the UAS(s), > then "COLLECT" the responses, and finally send a single > response which contains the capabilities of all UAS(s) > towards the UAC. [JRE] Again using sipfrags? > > Prox/Cons: > ---------------- > > + The major advantage of this mechanism is that it allows the > UAC to get the capabilities of all UAS(s). > + The UAC will get more or less the same set of capabilities > for an UAS, as if the UAS would have sent the response > directly to the UAC. > > - I guess most people would consider the forking proxy acting > as a B2BUA in this case, since it does not follow the 3261 > rules about forwarding (or discarding) 200 OK responses > immediately when received. > > What to do: > ----------------- > > If we think this is a good solution, could it be described in > a BCP? I guess we would not update 3261 to describe this behavior? [JRE] Again we would need to specify the sipfrag bits of it, and I would be= concerned about the response size. John= From adam@nostrum.com Fri Feb 19 06:36:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F3C28C2A7 for ; Fri, 19 Feb 2010 06:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 UTyC5r-cg24Z for ; Fri, 19 Feb 2010 06:36:09 -0800 (PST) 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 D616928C2A5 for ; Fri, 19 Feb 2010 06:36:08 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1JEb2nH030452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 08:37:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7EA20E.3040806@nostrum.com> Date: Fri, 19 Feb 2010 08:37:02 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B7E9EAD.20201@cisco.com> In-Reply-To: <4B7E9EAD.20201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 14:36:12 -0000 I'm a bit confused. On the rather remote chance that you want to poll all of the UAs associated with an AOR, you can subscribe to the AOR's reg event state; collect the GRUUs; and then send an OPTIONS to each UA in turn. But what's the real use case here? I can't imagine anything you can do with this information that doesn't work better with callerprefs. /a On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: > I pretty much agree with John. > > IMO there is no point in doing anything unless there is also work to > clarify what the response *means* in a way that is operationally useful. > > Even when there is only one UA and the OPTIONS request is getting to > it, the result isn't especially useful, except as a "ping" because: > > - nominally the response code is supposed to be the same as > it would be for an INVITE. I guess that means you should get > a 486 response if the UA is on a call and would reject another. > But what if the UA *never* accepts INVITES - only SUBSCRIBE? > Should you get 405? > > - If the UA can in principle support a lot of things, but not > all in the same call, there is no well defined way to reflect that. > > I would like to see a set of use cases for how people would like to > use OPTIONS where this enhancement is needed. > > Thanks, > Paul > > Elwell, John wrote: >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Christer Holmberg >>> Sent: 19 February 2010 11:28 >>> To: SIPCORE >>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>> >>> Hi, >>> >>> Some input regarding the OPTIONS issue. >>> >>> BACKGROUND: >>> ============ >>> >>> One of the main problems with OPTIONS is forking. In case the >>> request is forked, the UAC will only receive the capabilities of one >>> device/UAS (which UAS depends on which 200 OK reaches the forking >>> proxy first). >>> >>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP >>> URI always identify uniquely a specific resource or a specific server. >>> But, if I address the request to an AOR (which points to a domain, >>> not to a specific device) I might want to receive capabilities of >>> all the UAS associated with that AOR/domain. >>> First, do we agree that is a valid usage to address OPTIONS to an AOR? >>> OR, do we think that OPTIONS should only be addressed to specific >>> devices (section 11 of 3261 talks about devices), in which case I >>> guess we don't need to do anything - at least not as far as forking >>> is concerned. >>> >>> The rest of this e-mail is based on the assumption that we DO want >>> to be able to address OPTIONS to an AOR. >>> >>> >>> ABSTRACT: >>> ========= >>> >>> I have put together 3 alternative solutions on how the problem could >>> be fixed. The first alternative is based on a UAS change, while the >>> second and third alternatives are based on a model where the >>> registrar (forking proxy) sends a response "on behalf" of the UAS(s). >>> >>> The 4th alternative is of course that we do nothing, but based on >>> previous discussions it does seem that some people are interested in >>> doing something about OPTIONS. >>> >>> >>> ALTERNATIVE 1: >>> ============= >>> >>> In this alternative the UAS(s) send a provisional response, >>> including the capabilities, to the OPTIONS request. The registrar >>> will (hopefully) forward all the provisional responses towards the UAC. >>> >>> Pros/cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s) associated with the AOR. >>> + No impacts on registrar >>> >>> - Does not work with deployed Uas >>> - Would the provisional response need to be PRACKed? >> [JRE] I hope this Alternative 1 is not meant to be serious. This >> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT >> issue a provisional response for a non-INVITE request". I wonder how >> many SIP stacks would handle this. Also, having sent a provisional >> response, the UAS needs to send a final response, so how would this >> interact? >> >>> >>> What to do: >>> ----------------- >>> >>> This alternative would most likely require an RFC: either an >>> extension with an associated option-tag, or an update to 3261. >>> >>> >>> >>> ALTERNATIVE 2: >>> ============= >>> >>> In this alternative the registrar never forks the OPTIONS request >>> towards the UAS(s). Instead, it sends a response on behalf of the >>> UASs, based on the information is has about the UAS(s), based on >>> registration information (feature tags etc) etc. >>> >>> The first question is whether 3261 already allows this: >>> >>> When a UAC sends an OPTIONS request addressed to an AOR, I expect to >>> get capabilities associated with that AOR (which points to a domain, >>> not to a specific device). Currently, in case of forking, I will >>> only get the capabilities from one device/UAS associated with that >>> domain. >>> >>> But, if the registrar sends the OPTIONS response, it can provide >>> capabilities of all registered UAS(s) associated with the AOR/domain. >>> >>> So, so far I don't think 3261 forbids this kind of behavior (in >>> fact, I think this kind of behavior actually better implements what >>> is described in 3261...) >>> >>> >>> Now, the best way to return the capabilities would probably be by >>> using a message body, e.g. a multipart with sipfrag body parts (each >>> sipfrag body part representing a UAS). >> [JRE] And that sipfrag body part would need to contain an SDP body >> part to represent the SDP capabilities of the UAS? This would make >> responses potentially very large, posing a problem for UDP. It is >> probably a more extreme example than anything we have had before of a >> response being VERY MUCH larger than a request. >> >>> >>> But, RFC3261 says that a proxy does not insert a message body in the >>> OPTIONS response, and that is probably ok in most cases when the >>> proxy returns its owns capabilities. But, when the proxy replies on >>> behalf of the UAS(s), I see no reason why it should not be allowed >>> to include a body. The UAC will get the capabilities of the UAS(s), >>> and that is what matters. >> [JRE] In this case what you call the proxy is the UAS w.r.t. this >> particular transaction, so it can include a body. >> >>> >>> Pros/cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s) associated with the AOR. >> [JRE] I am not sure what it needs this for, but we have the reg-event >> package to identify all registered Uas, and then OPTIONS could be >> directed at each in turn. >> >>> + In my personal opinion this does not require any changes in RFC3261 >>> >>> - The set of capabilities per UAS is limited to what the registrar >>> knows about the UAS (based on registration information, and/or by >>> provisioning), so SDP information would probably be left out. The >>> mechanism might still be good enough for many scenarios, though. >>> >>> What to do: >>> ----------------- >>> >>> If we think RFC3261 allows this, the question is whether we consider >>> it so crystal clear that nothing needs to be specified, or whether >>> it would be a good idea to put together a BCP type-of document >>> describing it. >>> >>> Or, do people think that this is NOT allowed behavior? >> [JRE] Even if allowed, I think we might need some specification of >> the sipfrag part of it, and I am concerned about the response size. >> But I am not convinced there is a requirement to be able to use >> OPTIONS to get information about multiple UAs at once. >> >>> >>> >>> >>> >>> ALTERNATIVE 3: >>> ============= >>> >>> The idea is similar to Alternative 1, but in this case the registrar >>> would fork the OPTIONS request towards the UAS(s), then "COLLECT" >>> the responses, and finally send a single response which contains the >>> capabilities of all UAS(s) towards the UAC. >> [JRE] Again using sipfrags? >> >>> >>> Prox/Cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s). >>> + The UAC will get more or less the same set of capabilities for an >>> UAS, as if the UAS would have sent the response directly to the UAC. >>> >>> - I guess most people would consider the forking proxy acting as a >>> B2BUA in this case, since it does not follow the 3261 rules about >>> forwarding (or discarding) 200 OK responses immediately when received. >>> >>> What to do: >>> ----------------- >>> >>> If we think this is a good solution, could it be described in a BCP? >>> I guess we would not update 3261 to describe this behavior? >> [JRE] Again we would need to specify the sipfrag bits of it, and I >> would be concerned about the response size. >> >> John >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Fri Feb 19 06:43:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4703A7E93 for ; Fri, 19 Feb 2010 06:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xpg9BOnpOQ8q for ; Fri, 19 Feb 2010 06:43:09 -0800 (PST) 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 6B9433A7C18 for ; Fri, 19 Feb 2010 06:43:09 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1JEipa5031091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 08:44:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7EA3E3.2080004@nostrum.com> Date: Fri, 19 Feb 2010 08:44:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christer Holmberg References: , In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806020901090800040905" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 14:43:10 -0000 This is a multi-part message in MIME format. --------------040806020901090800040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/19/10 08:36, Feb 19, Christer Holmberg wrote: > Last, alternative 1 was meant to be serious, but the response you gave is more or less what I expected :) > It's worse than John points out -- Robert recently reminded me that RFC4320 outlaws this behavior altogether: An SIP element MUST NOT send any provisional response with a Status- Code other than 100 to a non-INVITE request. /a --------------040806020901090800040905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/19/10 08:36, Feb 19, Christer Holmberg wrote: 
Last, alternative 1 was meant to be serious, but the response you gave is more or less what I expected :)

It's worse than John points out -- Robert recently reminded me that RFC4320 outlaws this behavior altogether:

   An SIP element MUST NOT send any provisional response with a Status-
   Code other than 100 to a non-INVITE request.

/a
--------------040806020901090800040905-- From dworley@avaya.com Fri Feb 19 07:50:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A5F3A8173 for ; Fri, 19 Feb 2010 07:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 kE4isy4AlZYF for ; Fri, 19 Feb 2010 07:50:27 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 104EF3A816C for ; Fri, 19 Feb 2010 07:50:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,504,1262581200"; d="scan'208";a="177207001" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Feb 2010 10:52:11 -0500 X-IronPort-AV: E=Sophos;i="4.49,504,1262581200"; d="scan'208";a="447538746" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Feb 2010 10:52:10 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1JFpoP07441; Fri, 19 Feb 2010 15:51:50 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o1JFplW05400; Fri, 19 Feb 2010 15:51:47 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 10:51:47 -0500 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Fri, 19 Feb 2010 10:51:46 -0500 Message-Id: <1266594706.3762.7.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2010 15:51:47.0129 (UTC) FILETIME=[712C1A90:01CAB17B] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:50:29 -0000 On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > One of the main problems with OPTIONS is forking. In case the request > is forked, the UAC will only receive the capabilities of one > device/UAS (which UAS depends on which 200 OK reaches the forking > proxy first). I would use: OPTIONS sip:AOR@example.com SIP/2.0 Request-Disposition: no-cancel, parallel This seems to be specified in RFC 3841 to give the results you want, although I don't expect many proxies to support it. I've written a discussion of this approach in http://tools.ietf.org/id/draft-worley-sipping-forking-03.txt in regard to SUBSCRIBE, PUBLISH, and some other cases. Dale From adam@nostrum.com Fri Feb 19 08:41:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC16B3A815B for ; Fri, 19 Feb 2010 08:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045, 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 WyAojq4dJcqg for ; Fri, 19 Feb 2010 08:41:15 -0800 (PST) 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 BBEE93A7ED7 for ; Fri, 19 Feb 2010 08:41:14 -0800 (PST) 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 o1JGgvJn040316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 10:42:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7EBF91.8020506@nostrum.com> Date: Fri, 19 Feb 2010 10:42:57 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:41:16 -0000 On 2/2/10 12:36 AM, Christer Holmberg wrote: > The Call-Info header field is missing from the table in section 8.1. > RFC 5367 allows Call-Info in NOTIFY, so I guess we also in the 3265bis > table can indicate that it is allowed for NOTIFY. I also think it > should be allowed for SUBSCRIBE, because I assume it could be used for > similar purposes as in an INVITE. Okay; I've indicated it as optional for SUBSCRIBE and NOTIFY requests. > In addition, I guess we should also see what other headers are not > listed. > That's a pretty herculean task. Here are the header fields we'd need to come up with answers for: Accept-Contact Accept-Resource-Priority Answer-Mode Flow-Timer History-Info Identity Identity-Info Join Max-Breadth Min-SE P-Access-Network-Info P-Answer-State P-Asserted-Identity P-Associated-URI P-Called-Party-ID P-Charging-Function-Addresses P-Charging-Vector P-DCS-Trace-Party-ID P-DCS-OSPS P-DCS-Billing-Info P-DCS-LAES P-DCS-Redirect P-Early-Media P-Media-Authorization P-Preferred-Identity P-Profile-Key P-Refused-URI-List P-Served-User P-User-Database P-Visited-Network-ID Path Permission-Missing Priv-Answer-Mode Privacy Reason Refer-Sub Refer-To Referred-By Reject-Contact Replaces Request-Disposition Resource-Priority Security-Client Security-Server Security-Verify Service-Route Session-Expires SIP-ETag SIP-If-Match Suppress-If-Match Target-Dialog Trigger-Consent If someone wants to embark on that effort and send text, I'm happy to include it in the document. At this point, I'm inclined to remove the table 2 stuff altogether as being more harmful than educational. If we're serious about keeping Table 2 up to date, then we need to change IANA procedures to require an update to table 2 every time a new method or header field is added. Whoever is adding the new header field or method would be required to define its relationship to all the defined header fields or methods currently registered. If we don't commit to do this, I vote that we abandon the Table 2 approach altogether. /a From pkyzivat@cisco.com Fri Feb 19 09:27:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559A33A7ED7 for ; Fri, 19 Feb 2010 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GAwgh2kKFdqc for ; Fri, 19 Feb 2010 09:27:25 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 990F73A7EBF for ; Fri, 19 Feb 2010 09:27:25 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACpZfktAZnwM/2dsb2JhbACbB3SlO5d8hGcEgxU X-IronPort-AV: E=Sophos;i="4.49,504,1262563200"; d="scan'208";a="485545249" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2010 17:29:12 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JHTCAH025184; Fri, 19 Feb 2010 17:29:12 GMT Message-ID: <4B7ECA68.3000503@cisco.com> Date: Fri, 19 Feb 2010 12:29:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dale Worley References: <1266594706.3762.7.camel@khone.us.nortel.com> In-Reply-To: <1266594706.3762.7.camel@khone.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 17:27:26 -0000 Dale, I don't see how that can work. Once the first 200 is forwarded by the proxy it isn't supposed to send any more. Even if it did, the UAC would stop looking for responses after it got the first final one. Thanks, Paul Dale Worley wrote: > On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >> One of the main problems with OPTIONS is forking. In case the request >> is forked, the UAC will only receive the capabilities of one >> device/UAS (which UAS depends on which 200 OK reaches the forking >> proxy first). > > I would use: > > OPTIONS sip:AOR@example.com SIP/2.0 > Request-Disposition: no-cancel, parallel > > This seems to be specified in RFC 3841 to give the results you want, > although I don't expect many proxies to support it. I've written a > discussion of this approach in > http://tools.ietf.org/id/draft-worley-sipping-forking-03.txt in regard > to SUBSCRIBE, PUBLISH, and some other cases. > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From root@core3.amsl.com Fri Feb 19 12:00:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9598F28C0F8; Fri, 19 Feb 2010 12:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100219200001.9598F28C0F8@core3.amsl.com> Date: Fri, 19 Feb 2010 12:00:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sipcore-rfc3265bis-01.txt Pages : 52 Date : 2010-02-19 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc3265bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-19115952.I-D@ietf.org> --NextPart-- From adam@nostrum.com Fri Feb 19 12:08:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C41C28C102 for ; Fri, 19 Feb 2010 12:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bNBTzFIJ0gFB for ; Fri, 19 Feb 2010 12:08:13 -0800 (PST) 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 409FA3A7BA5 for ; Fri, 19 Feb 2010 12:08:12 -0800 (PST) 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 o1JK9r4G001337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Feb 2010 14:09:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7EF00F.9060909@nostrum.com> Date: Fri, 19 Feb 2010 14:09:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <20100219200001.9598F28C0F8@core3.amsl.com> In-Reply-To: <20100219200001.9598F28C0F8@core3.amsl.com> Content-Type: multipart/alternative; boundary="------------060109080508040709050201" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:08:14 -0000 This is a multi-part message in MIME format. --------------060109080508040709050201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as participant] There are only a handful of changes in this version of the document, none of them pertaining to the open issues. I will be posting the open issues to the mailing list ahead of the Anaheim meeting to hopefully get closure on them, so that we don't need to spend much time discussing them at the face-to-face meeting. As always, comments are welcome -- especially on the identified open issues. /a On 2/19/10 2:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > > Title : SIP-Specific Event Notification > Author(s) : A. Roach > Filename : draft-ietf-sipcore-rfc3265bis-01.txt > Pages : 52 > Date : 2010-02-19 > > This document describes an extension to the Session Initiation > Protocol (SIP). The purpose of this extension is to provide an > extensible framework by which SIP nodes can request notification from > remote nodes indicating that certain events have occurred. > > Note that the event notification mechanisms defined herein are NOT > intended to be a general-purpose infrastructure for all classes of > event subscription and notification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------060109080508040709050201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as participant]

There are only a handful of changes in this version of the document, none of them pertaining to the open issues. I will be posting the open issues to the mailing list ahead of the Anaheim meeting to hopefully get closure on them, so that we don't need to spend much time discussing them at the face-to-face meeting.

As always, comments are welcome -- especially on the identified open issues.

/a

On 2/19/10 2:00 PM, Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.


	Title           : SIP-Specific Event Notification
	Author(s)       : A. Roach
	Filename        : draft-ietf-sipcore-rfc3265bis-01.txt
	Pages           : 52
	Date            : 2010-02-19

This document describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------060109080508040709050201-- From jmpolk@cisco.com Fri Feb 19 12:22:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047C128C110 for ; Fri, 19 Feb 2010 12:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Pz18xBlqTQ25 for ; Fri, 19 Feb 2010 12:22:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2F7E628C0DB for ; Fri, 19 Feb 2010 12:22:29 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGuCfkurRN+K/2dsb2JhbACbCXOlZpdrhGcEgxU X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="300989823" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2010 20:24:17 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1JKOGT4016210 for ; Fri, 19 Feb 2010 20:24:16 GMT Message-Id: <201002192024.o1JKOGT4016210@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Feb 2010 14:13:50 -0600 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [sipcore] New rev of Location Conveyance (-02) submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:22:30 -0000 Here are the changes in Location Conveyance -02 relative to the previous version: - added Section 2.1 to explain and scope the differences in identifying a Target vs Device and now each work in a SIP-based document. Reducing the usage of 'device' to the new section that explains how - in this document - we use the term Target instead (which is the point of the new section 2.1). - reduced using the acronym UAC only where this distinction is needed, and say UA more. - got rid of LbyR -- replacing acronym with "location URI" - tightened up the text of the doc in several sections. - fixed the ABNF of the Geolocation header to make "inserted-by=" mandatory, which is what the text already called for. - fixed the ABNF of the Geolocation-Error header to make "inserter=" and "node=" parameters mandatory, which is what the text already called for. - clarified the text covering the scenario for multiple Geolocation Header field rows (from Section 7.3.1 of 3261). - added text to the deference section (4.5) to say that Figure 4 is a general concept of deferencing, but the details are in another doc; as a result, added Geopriv's Loc-filters ID as a reference. Here I also moved the 200 OK to the INVITE to being after the NOTIFY returns the PIDF-LO, since then is the only time the INVITE sender will know whether or not the location that was included got to the destination (i.e., the dereference was successful). I'm not clarifying whether or not rough or precise location was received by the destination UAS. - Added separate "permission" based error codes for and , so the "inserter=" of location can react to exactly which flag is being asked to be changed. Since one is in the PIDF-LO and one is a SIP header parameter, I believe this addition is justified, based on RFC 5606. - fixed a few other nits Please, have a look at this new version and let us know if you have any comments. Thanks James From dean.willis@softarmor.com Sat Feb 20 18:05:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9013A7B24 for ; Sat, 20 Feb 2010 18:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 E9KF6L3xzCBy for ; Sat, 20 Feb 2010 18:05:05 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 240153A71FA for ; Sat, 20 Feb 2010 18:05:05 -0800 (PST) Received: from [10.162.10.134] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1L26nx0017937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 20 Feb 2010 20:06:52 -0600 Date: Sat, 20 Feb 2010 20:06:40 -0600 From: "Dean Willis" To: christer.holmberg@ericsson.com MIME-Version: 1.0 X-Mailer: LCG ProfiMail Message-ID: <2422846424.951163600@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 02:05:06 -0000 ------- Original message ------- > From: Christer Holmberg > Sent: 19.2.'10, 5:28 > One of the main problems with OPTIONS is forking. In case the request is > forked, the UAC will only receive the capabilities of one device/UAS > (which UAS depends on which 200 OK reaches the forking proxy first). How about the proxy that would fork instead responds with a 302 that includes in Contact an enumeration of the GRUUs for the Contacts of the AOR. The UAC then iterates across the GRUU set with OPTIONS, thereby discovering the capabilities of each registered Contact, without the privacy risks of revealing the Contacts associated with the AOR. -- Dean From christer.holmberg@ericsson.com Sun Feb 21 11:52:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929A83A8259 for ; Sun, 21 Feb 2010 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=-0.205, 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 f6pLXJbzsW7P for ; Sun, 21 Feb 2010 11:52:14 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8CBAB3A7BA1 for ; Sun, 21 Feb 2010 11:52:14 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-07-4b818f602f65 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0E.95.31641.06F818B4; Sun, 21 Feb 2010 20:54:08 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 21 Feb 2010 20:54:08 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Sun, 21 Feb 2010 20:54:07 +0100 Thread-Topic: 3265bis and Call-Info Thread-Index: AcqxgqBnkeb9VVZ0RaC9Cm22wkHhuwBq6OfQ Message-ID: References: <4B7EBF91.8020506@nostrum.com> In-Reply-To: <4B7EBF91.8020506@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 19:52:15 -0000 Hi,=20 >That's a pretty herculean task. Here are the header fields we'd need to co= me up with answers=20 >for: > > > >If someone wants to embark on that effort and send text, I'm happy to incl= ude it in the=20 >document. At this point, I'm inclined to remove the table 2 stuff altogeth= er as being more=20 >harmful than educational. > >If we're serious about keeping Table 2 up to date, then we need to change = IANA procedures to=20 >require an update to table 2 every time a new method or header field is ad= ded. Whoever is=20 >adding the new header field or method would be required to define its rela= tionship to all the=20 >defined header fields or methods currently registered. If we don't commit = to do this, I vote=20 >that we abandon the Table 2 approach altogether. We had this discussion a while ago, and it may be good to start it again. I= think at least Dean mentioned abandoning Table 2. I talked about having a = website instead, which would be easier to keep up to date, but I think the = IETF proceures didn't allow that. For example, I was requested to add a number of missing headers to the INFO= draft. However, the INFO draft does not contain all the headers you listed= in your reply. So, I totally agree with you that we need to agree on what to do with Table= 2. Maybe something to discuss in Anaheim? Until then, I guess we could at least make sure that we have the 3261 heade= rs included, and whatever other headers are defined/used in a particular sp= ecification. Regards, Christer /a From pkyzivat@cisco.com Sun Feb 21 12:01:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB4528C0E1 for ; Sun, 21 Feb 2010 12:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Xjxo4QZp8F7U for ; Sun, 21 Feb 2010 12:01:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7119728C1E3 for ; Sun, 21 Feb 2010 12:00:58 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEMggUtAZnwN/2dsb2JhbACbBXOieJcdhGsEgxU X-IronPort-AV: E=Sophos;i="4.49,512,1262563200"; d="scan'208";a="87683815" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2010 20:02:53 +0000 Received: from [10.86.242.72] (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1LK2rcM026482; Sun, 21 Feb 2010 20:02:53 GMT Message-ID: <4B81916C.9080103@cisco.com> Date: Sun, 21 Feb 2010 15:02:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <2422846424.951163600@softarmor.com> In-Reply-To: <2422846424.951163600@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:01:03 -0000 Dean, This seems like the best answer I have heard so far. Thanks, Paul Dean Willis wrote: > > > ------- Original message ------- >> From: Christer Holmberg >> Sent: 19.2.'10, 5:28 >> One of the main problems with OPTIONS is forking. In case the request >> is forked, the UAC will only receive the capabilities of one >> device/UAS (which UAS depends on which 200 OK reaches the forking >> proxy first). > > How about the proxy that would fork instead responds with a 302 that > includes in Contact an enumeration of the GRUUs for the Contacts of the > AOR. The UAC then iterates across the GRUU set with OPTIONS, thereby > discovering the capabilities of each registered Contact, without the > privacy risks of revealing the Contacts associated with the AOR. > > -- > Dean _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Sun Feb 21 12:06:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC553A7349 for ; Sun, 21 Feb 2010 12:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 dPNXPcFOuj5A for ; Sun, 21 Feb 2010 12:06:18 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7670E3A6D3F for ; Sun, 21 Feb 2010 12:06:18 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-26-4b8192ac94a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E0.F5.31641.CA2918B4; Sun, 21 Feb 2010 21:08:13 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 21 Feb 2010 21:08:12 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Sun, 21 Feb 2010 21:08:11 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: AcqxcuwFVaQ0NxElTmOJ+jomd49cuwBvcSag Message-ID: References: , <4B7EA3E3.2080004@nostrum.com> In-Reply-To: <4B7EA3E3.2080004@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:06:19 -0000 Hi, =20 >>Last, alternative 1 was meant to be serious, but the response you gave is= more or less what=20 >>I expected :) > =20 >It's worse than John points out -- Robert recently reminded me that RFC432= 0 outlaws this=20 >behavior altogether: > > > An SIP element MUST NOT send any provisional response with a Status- > Code other than 100 to a non-INVITE request. Yes, so that RFC would also require an update. So, I think we can drop alternative 1 :) (Initially I was also thinking about an alternative where all 200 OK respon= ses are forwarded towards the UAC, but since we don't send ACK for OPTIONS = it would not really work from a transaction statemachhine point of view, be= cause when would you cease the re-transmission of OPTIONS?) Regards, Christer From christer.holmberg@ericsson.com Sun Feb 21 12:26:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5243A8155 for ; Sun, 21 Feb 2010 12:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 WvqlUBcBpElT for ; Sun, 21 Feb 2010 12:26:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5F1C23A7349 for ; Sun, 21 Feb 2010 12:26:31 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-b0-4b8197691c8d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 00.D4.02429.967918B4; Sun, 21 Feb 2010 21:28:25 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 21 Feb 2010 21:28:25 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "Elwell, John" Date: Sun, 21 Feb 2010 21:28:25 +0100 Thread-Topic: OPTIONS: What does it mean? ( was: OPTIONS: How to solve the forking problem?) Thread-Index: AcqxcT2ilJ4fyLSbROWbszcCwfntIABwGxPg Message-ID: References: <4B7E9EAD.20201@cisco.com> In-Reply-To: <4B7E9EAD.20201@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] OPTIONS: What does it mean? ( was: OPTIONS: How to solve the forking problem?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:26:33 -0000 =20 Hi Paul, >IMO there is no point in doing anything unless there is also work to clari= fy what the=20 >response *means* in a way that is operationally useful. I agree with you 100%.. The issue you raise is the other issue related to OPTIONS. Unfortunaly I di= dn't have time to send out an e-mail about that. And, the what-does-it-mean issue needs to be solved no matter what we do wi= th the forking issue, so I guess I should have sent out an e-mail about tha= t first (I guess my thinking was that if the 2nd forking alternative is alr= eady allowed, we wouldn't need to spend so much time discussng that). >Even when there is only one UA and the OPTIONS request is getting to it, t= he result isn't=20 >especially useful, except as a "ping" because: > >- nominally the response code is supposed to be the same as > it would be for an INVITE. I guess that means you should get > a 486 response if the UA is on a call and would reject another. > But what if the UA *never* accepts INVITES - only SUBSCRIBE? > Should you get 405? When the OPTIONS text was written, we didn't have SUBSCRIBE, so we need to = agree whether we should be talking about "returning the capabilities at thi= s moment", instead of "what would the INVITE response be at this moment". So, yes, that is one issue. >- If the UA can in principle support a lot of things, but not > all in the same call, there is no well defined way to reflect that. True. I would assume that it should be made clear that OPTIONS is about ret= urning capabilities in general, and that there is no guarantee that everyth= ing will be available for a particutlar=20 call.=20 Another issue is related to the usage of feature tags. RFC 3841 says that a= UAS can perform feature tag matching when receiving a request, and reject = a request if it doesn't support required feature tags. I guess that is fine= for INVITE, but do we want to have that kind of behavior for OPTIONS also? >I would like to see a set of use cases for how people would like to use OP= TIONS where this=20 >enhancement is needed. I will talk about that in the forking issue thread. So, talking about the specific what-does-it-mean issue: do people have an i= nterest in trying to solve that? Thanks! Regards, Christer Elwell, John wrote: > =20 >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 19 February 2010 11:28 >> To: SIPCORE >> Subject: [sipcore] OPTIONS: How to solve the forking problem? >> >> Hi, >> =20 >> Some input regarding the OPTIONS issue. >> =20 >> BACKGROUND: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> One of the main problems with OPTIONS is forking. In case the request=20 >> is forked, the UAC will only receive the capabilities of one=20 >> device/UAS (which UAS depends on which 200 OK reaches the forking=20 >> proxy first). >> =20 >> OPTIONS works fine in HTTP, where we don't have forking and an HTTP=20 >> URI always identify uniquely a specific resource or a specific=20 >> server. >> =20 >> But, if I address the request to an AOR (which points to a domain,=20 >> not to a specific device) I might want to receive capabilities of all=20 >> the UAS associated with that AOR/domain. >> =20 >> First, do we agree that is a valid usage to address OPTIONS to an=20 >> AOR? >> =20 >> OR, do we think that OPTIONS should only be addressed to specific=20 >> devices (section 11 of 3261 talks about devices), in which case I=20 >> guess we don't need to do anything - at least not as far as forking=20 >> is concerned. >> =20 >> The rest of this e-mail is based on the assumption that we DO want to=20 >> be able to address OPTIONS to an AOR. >> =20 >> =20 >> ABSTRACT: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> I have put together 3 alternative solutions on how the problem could=20 >> be fixed. The first alternative is based on a UAS change, while the=20 >> second and third alternatives are based on a model where the=20 >> registrar (forking proxy) sends a response "on behalf" of the UAS(s). >> =20 >> The 4th alternative is of course that we do nothing, but based on=20 >> previous discussions it does seem that some people are interested in=20 >> doing something about OPTIONS. >> =20 >> =20 >> ALTERNATIVE 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> In this alternative the UAS(s) send a provisional response, including=20 >> the capabilities, to the OPTIONS request. The registrar will=20 >> (hopefully) forward all the provisional responses towards the UAC. >> =20 >> Pros/cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. >> + No impacts on registrar >> =20 >> - Does not work with deployed Uas >> - Would the provisional response need to be PRACKed? > [JRE] I hope this Alternative 1 is not meant to be serious. This would be= contrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisiona= l response for a non-INVITE request". I wonder how many SIP stacks would ha= ndle this. Also, having sent a provisional response, the UAS needs to send = a final response, so how would this interact? >=20 >> =20 >> What to do: >> ----------------- >> =20 >> This alternative would most likely require an RFC: either an=20 >> extension with an associated option-tag, or an update to 3261. >> =20 >> =20 >> =20 >> ALTERNATIVE 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> In this alternative the registrar never forks the OPTIONS request=20 >> towards the UAS(s). Instead, it sends a response on behalf of the=20 >> UASs, based on the information is has about the UAS(s), based on=20 >> registration information (feature tags etc) etc. >> =20 >> The first question is whether 3261 already allows this: >> =20 >> When a UAC sends an OPTIONS request addressed to an AOR, I expect to=20 >> get capabilities associated with that AOR (which points to a domain,=20 >> not to a specific device). Currently, in case of forking, I will only=20 >> get the capabilities from one device/UAS associated with that domain. >> =20 >> But, if the registrar sends the OPTIONS response, it can provide=20 >> capabilities of all registered UAS(s) associated with the AOR/domain. >> =20 >> So, so far I don't think 3261 forbids this kind of behavior (in fact,=20 >> I think this kind of behavior actually better implements what is=20 >> described in 3261...) >> =20 >> =20 >> Now, the best way to return the capabilities would probably be by=20 >> using a message body, e.g. a multipart with sipfrag body parts (each=20 >> sipfrag body part representing a UAS). > [JRE] And that sipfrag body part would need to contain an SDP body part t= o represent the SDP capabilities of the UAS? This would make responses pote= ntially very large, posing a problem for UDP. It is probably a more extreme= example than anything we have had before of a response being VERY MUCH lar= ger than a request. >=20 >> =20 >> But, RFC3261 says that a proxy does not insert a message body in the=20 >> OPTIONS response, and that is probably ok in most cases when the=20 >> proxy returns its owns capabilities. But, when the proxy replies on=20 >> behalf of the UAS(s), I see no reason why it should not be allowed to=20 >> include a body. The UAC will get the capabilities of the UAS(s), and=20 >> that is what matters. > [JRE] In this case what you call the proxy is the UAS w.r.t. this particu= lar transaction, so it can include a body. >=20 >> =20 >> Pros/cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. > [JRE] I am not sure what it needs this for, but we have the reg-event pac= kage to identify all registered Uas, and then OPTIONS could be directed at = each in turn. >=20 >> + In my personal opinion this does not require any changes in RFC3261 >> =20 >> - The set of capabilities per UAS is limited to what the registrar=20 >> knows about the UAS (based on registration information, and/or by=20 >> provisioning), so SDP information would probably be left out. The=20 >> mechanism might still be good enough for many scenarios, though. >> =20 >> What to do: >> ----------------- >> =20 >> If we think RFC3261 allows this, the question is whether we consider=20 >> it so crystal clear that nothing needs to be specified, or whether it=20 >> would be a good idea to put together a BCP type-of document=20 >> describing it. >> =20 >> Or, do people think that this is NOT allowed behavior? > [JRE] Even if allowed, I think we might need some specification of the si= pfrag part of it, and I am concerned about the response size. But I am not = convinced there is a requirement to be able to use OPTIONS to get informati= on about multiple UAs at once. >=20 >> =20 >> =20 >> =20 >> =20 >> ALTERNATIVE 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> The idea is similar to Alternative 1, but in this case the registrar=20 >> would fork the OPTIONS request towards the UAS(s), then "COLLECT" the=20 >> responses, and finally send a single response which contains the=20 >> capabilities of all UAS(s) towards the UAC. > [JRE] Again using sipfrags? >=20 >> =20 >> Prox/Cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s). >> + The UAC will get more or less the same set of capabilities >> for an UAS, as if the UAS would have sent the response directly to=20 >> the UAC. >> =20 >> - I guess most people would consider the forking proxy acting as a=20 >> B2BUA in this case, since it does not follow the 3261 rules about=20 >> forwarding (or discarding) 200 OK responses immediately when=20 >> received. >> =20 >> What to do: >> ----------------- >> =20 >> If we think this is a good solution, could it be described in a BCP?=20 >> I guess we would not update 3261 to describe this behavior? > [JRE] Again we would need to specify the sipfrag bits of it, and I would = be concerned about the response size. >=20 > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Sun Feb 21 12:30:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6603A3A824F for ; Sun, 21 Feb 2010 12:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 41PAQ01vOZ0P for ; Sun, 21 Feb 2010 12:30:05 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6D2E03A8155 for ; Sun, 21 Feb 2010 12:30:05 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-ba-4b81983f22f9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C7.86.31641.F38918B4; Sun, 21 Feb 2010 21:31:59 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 21 Feb 2010 21:31:59 +0100 From: Christer Holmberg To: 'Dale Worley' Date: Sun, 21 Feb 2010 21:31:58 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqxe4EfKJmCf5DZT3e+OFBUIeBpMgBuRNMA Message-ID: References: <1266594706.3762.7.camel@khone.us.nortel.com> In-Reply-To: <1266594706.3762.7.camel@khone.us.nortel.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:30:06 -0000 Hi Dale, I am not sure I understand how your example would solve it. My understanding of 3261 is that the forking proxy will discard all but the= first non-INVITE 200 OK. Are you saying that "no-cancel" overrides that, or did I missunderstand som= ething? Regards, Christer -----Original Message----- From: Dale Worley [mailto:dworley@avaya.com]=20 Sent: 19. helmikuuta 2010 17:52 To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > One of the main problems with OPTIONS is forking. In case the request=20 > is forked, the UAC will only receive the capabilities of one=20 > device/UAS (which UAS depends on which 200 OK reaches the forking=20 > proxy first). I would use: OPTIONS sip:AOR@example.com SIP/2.0 Request-Disposition: no-cancel, parallel =20 This seems to be specified in RFC 3841 to give the results you want, althou= gh I don't expect many proxies to support it. I've written a discussion of= this approach in http://tools.ietf.org/id/draft-worley-sipping-forking-03.= txt in regard to SUBSCRIBE, PUBLISH, and some other cases. Dale From christer.holmberg@ericsson.com Sun Feb 21 12:43:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EF53A7B46 for ; Sun, 21 Feb 2010 12:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.193, 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 StmEBm2X5k8k for ; Sun, 21 Feb 2010 12:43:28 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 793F63A7228 for ; Sun, 21 Feb 2010 12:43:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-93-4b819b61e9b0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 30.35.02429.16B918B4; Sun, 21 Feb 2010 21:45:21 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 21 Feb 2010 21:45:21 +0100 From: Christer Holmberg To: 'Dean Willis' Date: Sun, 21 Feb 2010 21:45:21 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: AcqymozBfm3N+2ZvQ1a84HIRs9BgZwAmtT2g Message-ID: References: <2422846424.951163600@softarmor.com> In-Reply-To: <2422846424.951163600@softarmor.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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:43:29 -0000 Hi Dean,=20 >>One of the main problems with OPTIONS is forking. In case the request=20 >>is forked, the UAC will only receive the capabilities of one=20 >>device/UAS (which UAS depends on which 200 OK reaches the forking proxy f= irst). > >How about the proxy that would fork instead responds with a 302 that inclu= des in Contact an=20 >enumeration of the GRUUs for the Contacts of the AOR. The UAC then iterate= s across the GRUU=20 >set with OPTIONS, thereby discovering the capabilities of each registered = Contact, without=20 >the privacy risks of revealing the Contacts associated with the AOR. Very interesting idea, and I for sure will add that as an alternative. I guess we could discuss whether it still would be possible for the forking= proxy to also include, in addtition to the GRUUs, the registered feature t= ags for the UASs, in which case it would be very similar to alternative 2 (= the differences being that you use another response code and include the in= formation in a header instead of the message body). That information may be enough in many cases, and even if the UAC needs mor= e information the information may help to decide to which UASs it sends sub= sequent OPTIONS request in order to retrieve more information (SDP, Contact= etc).=20 For example, if the UAC is interested in video capabilities it would be abl= e to send OPTIONS only to those UASs that have registered support of video. Thanks! Christer From christer.holmberg@ericsson.com Sun Feb 21 12:49:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF8F3A8155 for ; Sun, 21 Feb 2010 12:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 JhUHwiVeCGpk for ; Sun, 21 Feb 2010 12:49:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BAA633A7B46 for ; Sun, 21 Feb 2010 12:48:59 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-06-4b819cae7b5c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 77.55.02429.EAC918B4; Sun, 21 Feb 2010 21:50:54 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 21 Feb 2010 21:50:54 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Dean Willis Date: Sun, 21 Feb 2010 21:50:53 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: AcqzMNvaURyYbyVyTDOQCUNpQCLVKwABgDqw Message-ID: References: <2422846424.951163600@softarmor.com> <4B81916C.9080103@cisco.com> In-Reply-To: <4B81916C.9080103@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:49:00 -0000 I was missing the typical Dean Willis metaphor, though :)=20 Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 21. helmikuuta 2010 22:03 To: Dean Willis Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? Dean, This seems like the best answer I have heard so far. Thanks, Paul Dean Willis wrote: >=20 >=20 > ------- Original message ------- >> From: Christer Holmberg >> Sent: 19.2.'10, 5:28 >> One of the main problems with OPTIONS is forking. In case the request=20 >> is forked, the UAC will only receive the capabilities of one=20 >> device/UAS (which UAS depends on which 200 OK reaches the forking=20 >> proxy first). >=20 > How about the proxy that would fork instead responds with a 302 that=20 > includes in Contact an enumeration of the GRUUs for the Contacts of=20 > the AOR. The UAC then iterates across the GRUU set with OPTIONS,=20 > thereby discovering the capabilities of each registered Contact,=20 > without the privacy risks of revealing the Contacts associated with the A= OR. >=20 > -- > Dean _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From gao.yang2@zte.com.cn Sun Feb 21 17:10:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF3D3A836E for ; Sun, 21 Feb 2010 17:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 qFXjakEVN+Ij for ; Sun, 21 Feb 2010 17:10:01 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8E4063A836C for ; Sun, 21 Feb 2010 17:09:59 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469071727820181; Mon, 22 Feb 2010 08:43:49 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.4394537513; Mon, 22 Feb 2010 09:10:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o1M1Bgou095887; Mon, 22 Feb 2010 09:11:42 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B81916C.9080103@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 22 Feb 2010 09:10:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-02-22 09:11:40, Serialize complete at 2010-02-22 09:11:40 Content-Type: multipart/alternative; boundary="=_alternative 00068D66482576D2_=" X-MAIL: mse1.zte.com.cn o1M1Bgou095887 Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 01:10:02 -0000 This is a multipart message in MIME format. --=_alternative 00068D66482576D2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KzENCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAw MTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCg0KDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4gDQq3orz+yMs6ICBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDItMjIgMDQ6MDINCg0KytW8/sjLDQpEZWFu IFdpbGxpcyA8ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT4NCrOty80NCnNpcGNvcmVAaWV0Zi5v cmcNCtb3zOINClJlOiBbc2lwY29yZV0gT1BUSU9OUzogSG93IHRvIHNvbHZlIHRoZSBmb3JraW5n IHByb2JsZW0/DQoNCg0KDQoNCg0KDQpEZWFuLA0KDQpUaGlzIHNlZW1zIGxpa2UgdGhlIGJlc3Qg YW5zd2VyIEkgaGF2ZSBoZWFyZCBzbyBmYXIuDQoNCiAgICAgICAgICAgICAgICAgVGhhbmtzLA0K ICAgICAgICAgICAgICAgICBQYXVsDQoNCkRlYW4gV2lsbGlzIHdyb3RlOg0KPiANCj4gDQo+IC0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tDQo+PiBGcm9tOiBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gU2VudDogMTkuMi4nMTAsICA1 OjI4DQo+PiBPbmUgb2YgdGhlIG1haW4gcHJvYmxlbXMgd2l0aCBPUFRJT05TIGlzIGZvcmtpbmcu IEluIGNhc2UgdGhlIHJlcXVlc3QgDQo+PiBpcyBmb3JrZWQsIHRoZSBVQUMgd2lsbCBvbmx5IHJl Y2VpdmUgdGhlIGNhcGFiaWxpdGllcyBvZiBvbmUgDQo+PiBkZXZpY2UvVUFTICh3aGljaCBVQVMg ZGVwZW5kcyBvbiB3aGljaCAyMDAgT0sgcmVhY2hlcyB0aGUgZm9ya2luZyANCj4+IHByb3h5IGZp cnN0KS4NCj4gDQo+IEhvdyBhYm91dCB0aGUgcHJveHkgdGhhdCB3b3VsZCBmb3JrIGluc3RlYWQg cmVzcG9uZHMgd2l0aCBhIDMwMiB0aGF0IA0KPiBpbmNsdWRlcyBpbiBDb250YWN0IGFuIGVudW1l cmF0aW9uIG9mIHRoZSBHUlVVcyBmb3IgdGhlIENvbnRhY3RzIG9mIHRoZSANCj4gQU9SLiBUaGUg VUFDIHRoZW4gaXRlcmF0ZXMgYWNyb3NzIHRoZSBHUlVVIHNldCB3aXRoIE9QVElPTlMsIHRoZXJl YnkgDQo+IGRpc2NvdmVyaW5nIHRoZSBjYXBhYmlsaXRpZXMgb2YgZWFjaCByZWdpc3RlcmVkIENv bnRhY3QsIHdpdGhvdXQgdGhlIA0KPiBwcml2YWN5IHJpc2tzIG9mIHJldmVhbGluZyB0aGUgQ29u dGFjdHMgYXNzb2NpYXRlZCB3aXRoIHRoZSBBT1IuDQo+IA0KPiAtLSANCj4gRGVhbiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxp bmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 00068D66482576D2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJz cDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJy Pg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZu YnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEwLTAyLTIyIDA0OjAyPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkRlYW4gV2lsbGlzICZsdDtkZWFuLndpbGxp c0Bzb2Z0YXJtb3IuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBPUFRJT05TOiBIb3cgdG8gc29sdmUNCnRo ZSBmb3JraW5nIHByb2JsZW0/PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFuLDxicj4NCjxicj4NClRoaXMgc2VlbXMgbGlrZSB0aGUg YmVzdCBhbnN3ZXIgSSBoYXZlIGhlYXJkIHNvIGZhci48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQpQYXVsPGJyPg0KPGJyPg0KRGVhbiBXaWxsaXMgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS08YnI+DQomZ3Q7Jmd0 OyBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tJmd0Ozxicj4NCiZndDsmZ3Q7IFNlbnQ6IDE5LjIuJzEwLCAmbmJzcDs1OjI4PGJyPg0KJmd0 OyZndDsgT25lIG9mIHRoZSBtYWluIHByb2JsZW1zIHdpdGggT1BUSU9OUyBpcyBmb3JraW5nLiBJ biBjYXNlIHRoZQ0KcmVxdWVzdCA8YnI+DQomZ3Q7Jmd0OyBpcyBmb3JrZWQsIHRoZSBVQUMgd2ls bCBvbmx5IHJlY2VpdmUgdGhlIGNhcGFiaWxpdGllcyBvZiBvbmUgPGJyPg0KJmd0OyZndDsgZGV2 aWNlL1VBUyAod2hpY2ggVUFTIGRlcGVuZHMgb24gd2hpY2ggMjAwIE9LIHJlYWNoZXMgdGhlIGZv cmtpbmcNCjxicj4NCiZndDsmZ3Q7IHByb3h5IGZpcnN0KS48YnI+DQomZ3Q7IDxicj4NCiZndDsg SG93IGFib3V0IHRoZSBwcm94eSB0aGF0IHdvdWxkIGZvcmsgaW5zdGVhZCByZXNwb25kcyB3aXRo IGEgMzAyIHRoYXQNCjxicj4NCiZndDsgaW5jbHVkZXMgaW4gQ29udGFjdCBhbiBlbnVtZXJhdGlv biBvZiB0aGUgR1JVVXMgZm9yIHRoZSBDb250YWN0cyBvZg0KdGhlIDxicj4NCiZndDsgQU9SLiBU aGUgVUFDIHRoZW4gaXRlcmF0ZXMgYWNyb3NzIHRoZSBHUlVVIHNldCB3aXRoIE9QVElPTlMsIHRo ZXJlYnkNCjxicj4NCiZndDsgZGlzY292ZXJpbmcgdGhlIGNhcGFiaWxpdGllcyBvZiBlYWNoIHJl Z2lzdGVyZWQgQ29udGFjdCwgd2l0aG91dCB0aGUNCjxicj4NCiZndDsgcHJpdmFjeSByaXNrcyBv ZiByZXZlYWxpbmcgdGhlIENvbnRhY3RzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQU9SLjxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IERlYW4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNpcGNvcmUgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8 YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXBjb3JlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1Ro ZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMm bmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJz cDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtw ZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJz cDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpU aGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0 dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5k Jm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3Rv Jm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJz cDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtp biZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2lu YXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZu YnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJz cDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRo aXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3Im bmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50 aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00068D66482576D2_=-- From dean.willis@softarmor.com Sun Feb 21 20:28:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F13228C22C for ; Sun, 21 Feb 2010 20:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 gzQG1Due3aLV for ; Sun, 21 Feb 2010 20:28:02 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9B14428C201 for ; Sun, 21 Feb 2010 20:28:02 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1M4TsWJ027465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 21 Feb 2010 22:29:56 -0600 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 21 Feb 2010 22:29:48 -0600 References: <4B7EBF91.8020506@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 04:28:03 -0000 On Feb 21, 2010, at 1:54 PM, Christer Holmberg wrote: > > Hi, > >> That's a pretty herculean task. Here are the header fields we'd >> need to come up with answers >> for: >> >> >> >> If someone wants to embark on that effort and send text, I'm happy >> to include it in the >> document. At this point, I'm inclined to remove the table 2 stuff >> altogether as being more >> harmful than educational. >> >> If we're serious about keeping Table 2 up to date, then we need to >> change IANA procedures to >> require an update to table 2 every time a new method or header >> field is added. Whoever is >> adding the new header field or method would be required to define >> its relationship to all the >> defined header fields or methods currently registered. If we don't >> commit to do this, I vote >> that we abandon the Table 2 approach altogether. > > We had this discussion a while ago, and it may be good to start it > again. I think at least Dean mentioned abandoning Table 2. I talked > about having a website instead, which would be easier to keep up to > date, but I think the IETF proceures didn't allow that. Right. for things that one might use a website for, we have IANA registries. One could replace Table 2 with a registry, and have new RFCs update that registry. -- Dean From christer.holmberg@ericsson.com Sun Feb 21 21:08:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861B228C23B for ; Sun, 21 Feb 2010 21:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=-2.680, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492] 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 Gkoy1nkdemm7 for ; Sun, 21 Feb 2010 21:08:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8B3E828C196 for ; Sun, 21 Feb 2010 21:08:26 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c2-4b8211be7ef1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C3.7C.31641.EB1128B4; Mon, 22 Feb 2010 06:10:22 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 22 Feb 2010 06:10:22 +0100 From: Christer Holmberg To: 'Adam Roach' , Paul Kyzivat Date: Mon, 22 Feb 2010 06:10:21 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: AcqxcSabXjC2/NjbTVCKOg0Y/5vLCwBymNAg Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B7EA20E.3040806@nostrum.com> In-Reply-To: <4B7EA20E.3040806@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 05:08:28 -0000 Hi,=20 >I'm a bit confused. On the rather remote chance that you want to poll all = of the UAs=20 >associated with an AOR, I am not sure I agree on the "remote chance" thing. From my personal experi= ence, people are more interested in all UASs behind an AOR, in order to set= feature tag values etc accordingly when later esttablishing a session. >you can subscribe to the AOR's reg event state; collect the GRUUs; and the= n send an OPTIONS=20 >to each UA in turn. Sure, you can do that.=20 The idea behind the proposal, however, is that you would at least be able t= o get SOME information (even if only the gruus of the UASs, per Dean's prop= osal) using a single request. Then, if you need additional information (SDP etc), sending individual OPTI= ONS might be the best solution. But, the information you got in the first r= esponse might help you to decided to which UASs you are going to send indiv= idual OPTIONS. >But what's the real use case here? I can't imagine anything you can do wit= h this information=20 >that doesn't work better with callerprefs. One of the use-cases I have in mind is actually to enable better use of cal= lerprefs. For example, assume that Alice wants to make a call, and her first option i= s to reach UAS devices that support video. So, she wants to use callerprefs= to require video support. However, if no UAS support video, the call may g= et rejected. Alice could of course send a request which does not require video, but then= the call might be answered by a phone which doesn't support it, even if an= other phone would have supported it. In addition, if all the non-video phones also get the request it might mean= more early dialogs etc, that at least on wireless accesses can create a nu= mber of resource issues.=20 Sure, you can BYE unwanted early dialogs, but why create them in the first = place? A similar example (which is also described in RFC3261, I believe) is when A= lice wants to use an exension using the Require header, and wants to make s= ure that there are UASs supporting the extension. So, in general I don't think the use-case is very different usages of OPTIO= NS, but it would allow users to get at least some capabilities of all users= behind an AOR using a single request. Regards, Christer On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: > I pretty much agree with John. > > IMO there is no point in doing anything unless there is also work to=20 > clarify what the response *means* in a way that is operationally useful. > > Even when there is only one UA and the OPTIONS request is getting to=20 > it, the result isn't especially useful, except as a "ping" because: > > - nominally the response code is supposed to be the same as > it would be for an INVITE. I guess that means you should get > a 486 response if the UA is on a call and would reject another. > But what if the UA *never* accepts INVITES - only SUBSCRIBE? > Should you get 405? > > - If the UA can in principle support a lot of things, but not > all in the same call, there is no well defined way to reflect that. > > I would like to see a set of use cases for how people would like to=20 > use OPTIONS where this enhancement is needed. > > Thanks, > Paul > > Elwell, John wrote: >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >>> Behalf Of Christer Holmberg >>> Sent: 19 February 2010 11:28 >>> To: SIPCORE >>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>> >>> Hi, >>> >>> Some input regarding the OPTIONS issue. >>> >>> BACKGROUND: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> One of the main problems with OPTIONS is forking. In case the=20 >>> request is forked, the UAC will only receive the capabilities of one=20 >>> device/UAS (which UAS depends on which 200 OK reaches the forking=20 >>> proxy first). >>> >>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP=20 >>> URI always identify uniquely a specific resource or a specific server. >>> But, if I address the request to an AOR (which points to a domain,=20 >>> not to a specific device) I might want to receive capabilities of=20 >>> all the UAS associated with that AOR/domain. >>> First, do we agree that is a valid usage to address OPTIONS to an AOR? >>> OR, do we think that OPTIONS should only be addressed to specific=20 >>> devices (section 11 of 3261 talks about devices), in which case I=20 >>> guess we don't need to do anything - at least not as far as forking=20 >>> is concerned. >>> >>> The rest of this e-mail is based on the assumption that we DO want=20 >>> to be able to address OPTIONS to an AOR. >>> >>> >>> ABSTRACT: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> I have put together 3 alternative solutions on how the problem could=20 >>> be fixed. The first alternative is based on a UAS change, while the=20 >>> second and third alternatives are based on a model where the=20 >>> registrar (forking proxy) sends a response "on behalf" of the UAS(s). >>> >>> The 4th alternative is of course that we do nothing, but based on=20 >>> previous discussions it does seem that some people are interested in=20 >>> doing something about OPTIONS. >>> >>> >>> ALTERNATIVE 1: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> In this alternative the UAS(s) send a provisional response,=20 >>> including the capabilities, to the OPTIONS request. The registrar=20 >>> will (hopefully) forward all the provisional responses towards the UAC. >>> >>> Pros/cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s) associated with the AOR. >>> + No impacts on registrar >>> >>> - Does not work with deployed Uas >>> - Would the provisional response need to be PRACKed? >> [JRE] I hope this Alternative 1 is not meant to be serious. This=20 >> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT=20 >> issue a provisional response for a non-INVITE request". I wonder how=20 >> many SIP stacks would handle this. Also, having sent a provisional=20 >> response, the UAS needs to send a final response, so how would this=20 >> interact? >> >>> >>> What to do: >>> ----------------- >>> >>> This alternative would most likely require an RFC: either an=20 >>> extension with an associated option-tag, or an update to 3261. >>> >>> >>> >>> ALTERNATIVE 2: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> In this alternative the registrar never forks the OPTIONS request=20 >>> towards the UAS(s). Instead, it sends a response on behalf of the=20 >>> UASs, based on the information is has about the UAS(s), based on=20 >>> registration information (feature tags etc) etc. >>> >>> The first question is whether 3261 already allows this: >>> >>> When a UAC sends an OPTIONS request addressed to an AOR, I expect to=20 >>> get capabilities associated with that AOR (which points to a domain,=20 >>> not to a specific device). Currently, in case of forking, I will=20 >>> only get the capabilities from one device/UAS associated with that=20 >>> domain. >>> >>> But, if the registrar sends the OPTIONS response, it can provide=20 >>> capabilities of all registered UAS(s) associated with the AOR/domain. >>> >>> So, so far I don't think 3261 forbids this kind of behavior (in=20 >>> fact, I think this kind of behavior actually better implements what=20 >>> is described in 3261...) >>> >>> >>> Now, the best way to return the capabilities would probably be by=20 >>> using a message body, e.g. a multipart with sipfrag body parts (each=20 >>> sipfrag body part representing a UAS). >> [JRE] And that sipfrag body part would need to contain an SDP body=20 >> part to represent the SDP capabilities of the UAS? This would make=20 >> responses potentially very large, posing a problem for UDP. It is=20 >> probably a more extreme example than anything we have had before of a=20 >> response being VERY MUCH larger than a request. >> >>> >>> But, RFC3261 says that a proxy does not insert a message body in the=20 >>> OPTIONS response, and that is probably ok in most cases when the=20 >>> proxy returns its owns capabilities. But, when the proxy replies on=20 >>> behalf of the UAS(s), I see no reason why it should not be allowed=20 >>> to include a body. The UAC will get the capabilities of the UAS(s),=20 >>> and that is what matters. >> [JRE] In this case what you call the proxy is the UAS w.r.t. this=20 >> particular transaction, so it can include a body. >> >>> >>> Pros/cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s) associated with the AOR. >> [JRE] I am not sure what it needs this for, but we have the reg-event=20 >> package to identify all registered Uas, and then OPTIONS could be=20 >> directed at each in turn. >> >>> + In my personal opinion this does not require any changes in=20 >>> + RFC3261 >>> >>> - The set of capabilities per UAS is limited to what the registrar=20 >>> knows about the UAS (based on registration information, and/or by=20 >>> provisioning), so SDP information would probably be left out. The=20 >>> mechanism might still be good enough for many scenarios, though. >>> >>> What to do: >>> ----------------- >>> >>> If we think RFC3261 allows this, the question is whether we consider=20 >>> it so crystal clear that nothing needs to be specified, or whether=20 >>> it would be a good idea to put together a BCP type-of document=20 >>> describing it. >>> >>> Or, do people think that this is NOT allowed behavior? >> [JRE] Even if allowed, I think we might need some specification of=20 >> the sipfrag part of it, and I am concerned about the response size. >> But I am not convinced there is a requirement to be able to use=20 >> OPTIONS to get information about multiple UAs at once. >> >>> >>> >>> >>> >>> ALTERNATIVE 3: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> The idea is similar to Alternative 1, but in this case the registrar=20 >>> would fork the OPTIONS request towards the UAS(s), then "COLLECT" >>> the responses, and finally send a single response which contains the=20 >>> capabilities of all UAS(s) towards the UAC. >> [JRE] Again using sipfrags? >> >>> >>> Prox/Cons: >>> ---------------- >>> >>> + The major advantage of this mechanism is that it allows the UAC to >>> get the capabilities of all UAS(s). >>> + The UAC will get more or less the same set of capabilities for an >>> UAS, as if the UAS would have sent the response directly to the UAC. >>> >>> - I guess most people would consider the forking proxy acting as a=20 >>> B2BUA in this case, since it does not follow the 3261 rules about=20 >>> forwarding (or discarding) 200 OK responses immediately when received. >>> >>> What to do: >>> ----------------- >>> >>> If we think this is a good solution, could it be described in a BCP?=20 >>> I guess we would not update 3261 to describe this behavior? >> [JRE] Again we would need to specify the sipfrag bits of it, and I=20 >> would be concerned about the response size. >> >> John >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From salvatore.loreto@ericsson.com Sun Feb 21 22:44:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0DE3A808C for ; Sun, 21 Feb 2010 22:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=-0.503, 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 c458Q9HTtdrV for ; Sun, 21 Feb 2010 22:44:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CF63F3A8383 for ; Sun, 21 Feb 2010 22:44:04 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-f6-4b822829f1da Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 69.F2.02429.928228B4; Mon, 22 Feb 2010 07:46:01 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 07:45:36 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 07:45:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9B4D9264E for ; Mon, 22 Feb 2010 08:45:35 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 668AE21A41 for ; Mon, 22 Feb 2010 08:45:35 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 293AF219C4 for ; Mon, 22 Feb 2010 08:45:35 +0200 (EET) Message-ID: <4B82280E.8090306@ericsson.com> Date: Mon, 22 Feb 2010 08:45:34 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 22 Feb 2010 06:45:36.0228 (UTC) FILETIME=[A36EB240:01CAB38A] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Fwd: New Version Notification for draft-ietf-sipcore-event-rate-control-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 06:44:07 -0000 Hi, we have just submitted a new version of the draft that addresses all the comments received during the WGLC (ended yesterday): https://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ cheers Sal -------- Original Message -------- A new version of I-D, draft-ietf-sipcore-event-rate-control-03.txt has been successfuly submitted by Salvatore Loreto and posted to the IETF repository. Filename: draft-ietf-sipcore-event-rate-control Revision: 03 Title: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Creation_date: 2010-02-22 WG ID: sipcore Number_of_pages: 23 Abstract: This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. The IETF Secretariat. From root@core3.amsl.com Sun Feb 21 22:45:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3CF0F3A808C; Sun, 21 Feb 2010 22:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100222064502.3CF0F3A808C@core3.amsl.com> Date: Sun, 21 Feb 2010 22:45:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 06:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-03.txt Pages : 23 Date : 2010-02-21 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-event-rate-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-21223344.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Mon Feb 22 02:25:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3190528C0EF for ; Mon, 22 Feb 2010 02:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 TZYgRVLEvwxZ for ; Mon, 22 Feb 2010 02:25:53 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EB0D43A77B5 for ; Mon, 22 Feb 2010 02:25:52 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-962207; Mon, 22 Feb 2010 11:27:46 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id BCAA21EB82AE; Mon, 22 Feb 2010 11:27:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 22 Feb 2010 11:27:46 +0100 From: "Elwell, John" To: Adam Roach , "sipcore@ietf.org" Date: Mon, 22 Feb 2010 11:27:44 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt Thread-Index: Acqxn4hTZuEhBnBPS1Ww1X7m+1lCugCCd8AQ Message-ID: References: <20100219200001.9598F28C0F8@core3.amsl.com> <4B7EF00F.9060909@nostrum.com> In-Reply-To: <4B7EF00F.9060909@nostrum.com> 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_A444A0F8084434499206E78C106220CAB93E109DMCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 10:25:54 -0000 --_000_A444A0F8084434499206E78C106220CAB93E109DMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, The newly added reference RFC 4528 is wrong - should be RFC 4538. John ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 19 February 2010 20:10 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt [as participant] There are only a handful of changes in this version of the document, none o= f them pertaining to the open issues. I will be posting the open issues to = the mailing list ahead of the Anaheim meeting to hopefully get closure on t= hem, so that we don't need to spend much time discussing them at the face-t= o-face meeting. As always, comments are welcome -- especially on the identified open issues= . /a On 2/19/10 2:00 PM, Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working G= roup of the IETF. Title : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sipcore-rfc3265bis-01.txt Pages : 52 Date : 2010-02-19 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_A444A0F8084434499206E78C106220CAB93E109DMCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam,
 
The newly added reference RFC 4528 is wrong - shou= ld be RFC=20 4538.
 
John
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 19 February 2010 20:10
To:=20 sipcore@ietf.org
Subject: Re: [sipcore] I-D=20 Action:draft-ietf-sipcore-rfc3265bis-01.txt

[as participant]

There are only a handful of changes in= this=20 version of the document, none of them pertaining to the open issues. I wi= ll be=20 posting the open issues to the mailing list ahead of the Anaheim meeting = to=20 hopefully get closure on them, so that we don't need to spend much time=20 discussing them at the face-to-face meeting.

As always, comments a= re=20 welcome -- especially on the identified open issues.

/a

On= =20 2/19/10 2:00 PM, Internet-Drafts@ietf.org wro= te:=20 
A New Internet-Draft is available from the on-line Int=
ernet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working G=
roup of the IETF.


	Title           : SIP-Specific Event Notification
	Author(s)       : A. Roach
	Filename        : draft-ietf-sipcore-rfc3265bis-01.txt
	Pages           : 52
	Date            : 2010-02-19

This document describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts=
/draft-ietf-sipcore-rfc3265bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
sipcore mailing list
sipcor=
e@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_A444A0F8084434499206E78C106220CAB93E109DMCHP058Aglobala_-- From pkyzivat@cisco.com Mon Feb 22 05:19:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2203A83D5 for ; Mon, 22 Feb 2010 05:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BoX9aM16GdDQ for ; Mon, 22 Feb 2010 05:19:21 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3FEBF3A83D4 for ; Mon, 22 Feb 2010 05:19:20 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABkUgktAZnwM/2dsb2JhbACbB3OiR5dZhGsEgxU X-IronPort-AV: E=Sophos;i="4.49,518,1262563200"; d="scan'208";a="87928203" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2010 13:21:18 +0000 Received: from [10.86.242.72] (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1MDLIDW001805; Mon, 22 Feb 2010 13:21:18 GMT Message-ID: <4B8284CC.8050800@cisco.com> Date: Mon, 22 Feb 2010 08:21:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B7EBF91.8020506@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:19:21 -0000 Dean Willis wrote: >> We had this discussion a while ago, and it may be good to start it >> again. I think at least Dean mentioned abandoning Table 2. I talked >> about having a website instead, which would be easier to keep up to >> date, but I think the IETF proceures didn't allow that. > > Right. for things that one might use a website for, we have IANA > registries. > > One could replace Table 2 with a registry, and have new RFCs update that > registry. I support this approach. Thanks, Paul From pkyzivat@cisco.com Mon Feb 22 05:23:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E184F28C1BD for ; Mon, 22 Feb 2010 05:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.107 X-Spam-Level: X-Spam-Status: No, score=-8.107 tagged_above=-999 required=5 tests=[AWL=-2.492, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492, RCVD_IN_DNSWL_HI=-8] 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 6IyF3jxhN91t for ; Mon, 22 Feb 2010 05:23:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1AC3F28C1C4 for ; Mon, 22 Feb 2010 05:23:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABkUgktAZnwM/2dsb2JhbACbB3OiR5dZgkqCIQSDFQ X-IronPort-AV: E=Sophos;i="4.49,518,1262563200"; d="scan'208";a="87928777" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2010 13:25:08 +0000 Received: from [10.86.242.72] (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1MDP7XG003309; Mon, 22 Feb 2010 13:25:07 GMT Message-ID: <4B8285B2.80801@cisco.com> Date: Mon, 22 Feb 2010 08:25:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7E9EAD.20201@cisco.com> <4B7EA20E.3040806@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:23:12 -0000 For the "prefer video" option you mention, you can use callerprefs specifically to express that, so that devices with video capabilities are tried first, and others as a fallback. Look at the callerprefs usecases RFC. Thanks, Paul Christer Holmberg wrote: > Hi, > >> I'm a bit confused. On the rather remote chance that you want to poll all of the UAs >> associated with an AOR, > > I am not sure I agree on the "remote chance" thing. From my personal experience, people are more interested in all UASs behind an AOR, in order to set feature tag values etc accordingly when later esttablishing a session. > >> you can subscribe to the AOR's reg event state; collect the GRUUs; and then send an OPTIONS >> to each UA in turn. > > Sure, you can do that. > > The idea behind the proposal, however, is that you would at least be able to get SOME information (even if only the gruus of the UASs, per Dean's proposal) using a single request. > > Then, if you need additional information (SDP etc), sending individual OPTIONS might be the best solution. But, the information you got in the first response might help you to decided to which UASs you are going to send individual OPTIONS. > >> But what's the real use case here? I can't imagine anything you can do with this information >> that doesn't work better with callerprefs. > > One of the use-cases I have in mind is actually to enable better use of callerprefs. > > For example, assume that Alice wants to make a call, and her first option is to reach UAS devices that support video. So, she wants to use callerprefs to require video support. However, if no UAS support video, the call may get rejected. > > Alice could of course send a request which does not require video, but then the call might be answered by a phone which doesn't support it, even if another phone would have supported it. > > In addition, if all the non-video phones also get the request it might mean more early dialogs etc, that at least on wireless accesses can create a number of resource issues. > > Sure, you can BYE unwanted early dialogs, but why create them in the first place? > > A similar example (which is also described in RFC3261, I believe) is when Alice wants to use an exension using the Require header, and wants to make sure that there are UASs supporting the extension. > > So, in general I don't think the use-case is very different usages of OPTIONS, but it would allow users to get at least some capabilities of all users behind an AOR using a single request. > > Regards, > > Christer > > > On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: >> I pretty much agree with John. >> >> IMO there is no point in doing anything unless there is also work to >> clarify what the response *means* in a way that is operationally useful. >> >> Even when there is only one UA and the OPTIONS request is getting to >> it, the result isn't especially useful, except as a "ping" because: >> >> - nominally the response code is supposed to be the same as >> it would be for an INVITE. I guess that means you should get >> a 486 response if the UA is on a call and would reject another. >> But what if the UA *never* accepts INVITES - only SUBSCRIBE? >> Should you get 405? >> >> - If the UA can in principle support a lot of things, but not >> all in the same call, there is no well defined way to reflect that. >> >> I would like to see a set of use cases for how people would like to >> use OPTIONS where this enhancement is needed. >> >> Thanks, >> Paul >> >> Elwell, John wrote: >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 19 February 2010 11:28 >>>> To: SIPCORE >>>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>>> >>>> Hi, >>>> >>>> Some input regarding the OPTIONS issue. >>>> >>>> BACKGROUND: >>>> ============ >>>> >>>> One of the main problems with OPTIONS is forking. In case the >>>> request is forked, the UAC will only receive the capabilities of one >>>> device/UAS (which UAS depends on which 200 OK reaches the forking >>>> proxy first). >>>> >>>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP >>>> URI always identify uniquely a specific resource or a specific server. >>>> But, if I address the request to an AOR (which points to a domain, >>>> not to a specific device) I might want to receive capabilities of >>>> all the UAS associated with that AOR/domain. >>>> First, do we agree that is a valid usage to address OPTIONS to an AOR? >>>> OR, do we think that OPTIONS should only be addressed to specific >>>> devices (section 11 of 3261 talks about devices), in which case I >>>> guess we don't need to do anything - at least not as far as forking >>>> is concerned. >>>> >>>> The rest of this e-mail is based on the assumption that we DO want >>>> to be able to address OPTIONS to an AOR. >>>> >>>> >>>> ABSTRACT: >>>> ========= >>>> >>>> I have put together 3 alternative solutions on how the problem could >>>> be fixed. The first alternative is based on a UAS change, while the >>>> second and third alternatives are based on a model where the >>>> registrar (forking proxy) sends a response "on behalf" of the UAS(s). >>>> >>>> The 4th alternative is of course that we do nothing, but based on >>>> previous discussions it does seem that some people are interested in >>>> doing something about OPTIONS. >>>> >>>> >>>> ALTERNATIVE 1: >>>> ============= >>>> >>>> In this alternative the UAS(s) send a provisional response, >>>> including the capabilities, to the OPTIONS request. The registrar >>>> will (hopefully) forward all the provisional responses towards the UAC. >>>> >>>> Pros/cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC to >>>> get the capabilities of all UAS(s) associated with the AOR. >>>> + No impacts on registrar >>>> >>>> - Does not work with deployed Uas >>>> - Would the provisional response need to be PRACKed? >>> [JRE] I hope this Alternative 1 is not meant to be serious. This >>> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT >>> issue a provisional response for a non-INVITE request". I wonder how >>> many SIP stacks would handle this. Also, having sent a provisional >>> response, the UAS needs to send a final response, so how would this >>> interact? >>> >>>> What to do: >>>> ----------------- >>>> >>>> This alternative would most likely require an RFC: either an >>>> extension with an associated option-tag, or an update to 3261. >>>> >>>> >>>> >>>> ALTERNATIVE 2: >>>> ============= >>>> >>>> In this alternative the registrar never forks the OPTIONS request >>>> towards the UAS(s). Instead, it sends a response on behalf of the >>>> UASs, based on the information is has about the UAS(s), based on >>>> registration information (feature tags etc) etc. >>>> >>>> The first question is whether 3261 already allows this: >>>> >>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect to >>>> get capabilities associated with that AOR (which points to a domain, >>>> not to a specific device). Currently, in case of forking, I will >>>> only get the capabilities from one device/UAS associated with that >>>> domain. >>>> >>>> But, if the registrar sends the OPTIONS response, it can provide >>>> capabilities of all registered UAS(s) associated with the AOR/domain. >>>> >>>> So, so far I don't think 3261 forbids this kind of behavior (in >>>> fact, I think this kind of behavior actually better implements what >>>> is described in 3261...) >>>> >>>> >>>> Now, the best way to return the capabilities would probably be by >>>> using a message body, e.g. a multipart with sipfrag body parts (each >>>> sipfrag body part representing a UAS). >>> [JRE] And that sipfrag body part would need to contain an SDP body >>> part to represent the SDP capabilities of the UAS? This would make >>> responses potentially very large, posing a problem for UDP. It is >>> probably a more extreme example than anything we have had before of a >>> response being VERY MUCH larger than a request. >>> >>>> But, RFC3261 says that a proxy does not insert a message body in the >>>> OPTIONS response, and that is probably ok in most cases when the >>>> proxy returns its owns capabilities. But, when the proxy replies on >>>> behalf of the UAS(s), I see no reason why it should not be allowed >>>> to include a body. The UAC will get the capabilities of the UAS(s), >>>> and that is what matters. >>> [JRE] In this case what you call the proxy is the UAS w.r.t. this >>> particular transaction, so it can include a body. >>> >>>> Pros/cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC to >>>> get the capabilities of all UAS(s) associated with the AOR. >>> [JRE] I am not sure what it needs this for, but we have the reg-event >>> package to identify all registered Uas, and then OPTIONS could be >>> directed at each in turn. >>> >>>> + In my personal opinion this does not require any changes in >>>> + RFC3261 >>>> >>>> - The set of capabilities per UAS is limited to what the registrar >>>> knows about the UAS (based on registration information, and/or by >>>> provisioning), so SDP information would probably be left out. The >>>> mechanism might still be good enough for many scenarios, though. >>>> >>>> What to do: >>>> ----------------- >>>> >>>> If we think RFC3261 allows this, the question is whether we consider >>>> it so crystal clear that nothing needs to be specified, or whether >>>> it would be a good idea to put together a BCP type-of document >>>> describing it. >>>> >>>> Or, do people think that this is NOT allowed behavior? >>> [JRE] Even if allowed, I think we might need some specification of >>> the sipfrag part of it, and I am concerned about the response size. >>> But I am not convinced there is a requirement to be able to use >>> OPTIONS to get information about multiple UAs at once. >>> >>>> >>>> >>>> >>>> ALTERNATIVE 3: >>>> ============= >>>> >>>> The idea is similar to Alternative 1, but in this case the registrar >>>> would fork the OPTIONS request towards the UAS(s), then "COLLECT" >>>> the responses, and finally send a single response which contains the >>>> capabilities of all UAS(s) towards the UAC. >>> [JRE] Again using sipfrags? >>> >>>> Prox/Cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC to >>>> get the capabilities of all UAS(s). >>>> + The UAC will get more or less the same set of capabilities for an >>>> UAS, as if the UAS would have sent the response directly to the UAC. >>>> >>>> - I guess most people would consider the forking proxy acting as a >>>> B2BUA in this case, since it does not follow the 3261 rules about >>>> forwarding (or discarding) 200 OK responses immediately when received. >>>> >>>> What to do: >>>> ----------------- >>>> >>>> If we think this is a good solution, could it be described in a BCP? >>>> I guess we would not update 3261 to describe this behavior? >>> [JRE] Again we would need to specify the sipfrag bits of it, and I >>> would be concerned about the response size. >>> >>> John >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Mon Feb 22 05:37:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE88628C2E0 for ; Mon, 22 Feb 2010 05:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NiGaEe-TE92H for ; Mon, 22 Feb 2010 05:37:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DFDE528C2DF for ; Mon, 22 Feb 2010 05:37:16 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bb-4b828901970d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id FD.A0.02429.109828B4; Mon, 22 Feb 2010 14:39:14 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 14:39:13 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 14:39:13 +0100 Message-ID: <4B828901.1090809@ericsson.com> Date: Mon, 22 Feb 2010 15:39:13 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2010 13:39:13.0520 (UTC) FILETIME=[6BB0EF00:01CAB3C4] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC: draft-ietf-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:37:17 -0000 Folks, we would like to WGLC the following draft: http://tools.ietf.org/id/draft-ietf-sipcore-reinvite-01.txt This WGLC will end on March 8th. Please, send your comments on this draft to this list. Thanks, Gonzalo SIPCORE co-chair From dworley@avaya.com Mon Feb 22 09:31:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2043E28C133 for ; Mon, 22 Feb 2010 09:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 i43ct4iAFjoB for ; Mon, 22 Feb 2010 09:31:41 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2030328C151 for ; Mon, 22 Feb 2010 09:31:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="206222127" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Feb 2010 12:33:39 -0500 X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="448423187" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2010 12:33:39 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1MHXHl19847 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 22 Feb 2010 17:33:18 GMT Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1MHXFH02390; Mon, 22 Feb 2010 17:33:15 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 12:33:14 -0500 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Mon, 22 Feb 2010 12:33:14 -0500 Message-Id: <1266859994.3760.25.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2010 17:33:14.0956 (UTC) FILETIME=[1D0A08C0:01CAB3E5] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:31:44 -0000 On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > But, if I address the request to an AOR (which points to a domain, not > to a specific device) I might want to receive capabilities of all the > UAS associated with that AOR/domain. There is an ambiguity regarding what UAs you want to query. Do you want to query the UAs registered to the AOR in question, or do you want to query the UAs that an INVITE sent to the AOR would reach? Dale From dworley@avaya.com Mon Feb 22 09:35:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAB528C16C for ; Mon, 22 Feb 2010 09:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 M144Gnhy82XP for ; Mon, 22 Feb 2010 09:35:35 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B3F6428C151 for ; Mon, 22 Feb 2010 09:35:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="206222737" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Feb 2010 12:37:20 -0500 X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="448424542" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2010 12:37:20 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1MHaxl21318 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 22 Feb 2010 17:36:59 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o1MHauG13120; Mon, 22 Feb 2010 17:36:56 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 12:36:56 -0500 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: <1266594706.3762.7.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 22 Feb 2010 12:36:56 -0500 Message-Id: <1266860216.3760.30.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2010 17:36:56.0554 (UTC) FILETIME=[A11F34A0:01CAB3E5] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:35:36 -0000 On Sun, 2010-02-21 at 21:31 +0100, Christer Holmberg wrote: > I am not sure I understand how your example would solve it. > > My understanding of 3261 is that the forking proxy will discard all > but the first non-INVITE 200 OK. > > Are you saying that "no-cancel" overrides that, or did I > missunderstand something? My understanding is that the *intended (but poorly documented) meaning* of "Request-Disposition: no-cancel" is to request that the proxy forward all 2xx responses upstream, in much the way that it ordinarily would for INVITEs. Otherwise, why would the proxy not cancel other forks when it receives a 2xx? Dale From dworley@avaya.com Mon Feb 22 09:41:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29663A6B45 for ; Mon, 22 Feb 2010 09:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 orPP2YuYZbqH for ; Mon, 22 Feb 2010 09:41:54 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B40613A7982 for ; Mon, 22 Feb 2010 09:41:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="206223715" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Feb 2010 12:43:50 -0500 X-IronPort-AV: E=Sophos;i="4.49,519,1262581200"; d="scan'208";a="448428081" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2010 12:43:50 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1MHhSl23809 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Mon, 22 Feb 2010 17:43:29 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1MHhQH04784; Mon, 22 Feb 2010 17:43:26 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 12:43:25 -0500 From: "Dale Worley" To: Brett Tate In-Reply-To: <747A6506A991724FB09B129B79D5FEB61460173AD4@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB61460173AD4@EXMBXCLUS01.citservers.local> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 22 Feb 2010 12:43:25 -0500 Message-Id: <1266860605.3760.33.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2010 17:43:25.0936 (UTC) FILETIME=[89362F00:01CAB3E6] Cc: SIPCORE Subject: Re: [sipcore] RFC 4028 Errata ID 1681: From tag not changing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:41:55 -0000 On Wed, 2010-02-17 at 05:51 -0800, Brett Tate wrote: > Concerning RFC 4028 Errata ID 1681, I disagree with the suggested > resolution. > > The following is the link to the errata: > http://www.rfc-editor.org/errata_search.php?eid=1681 > > http://www.nostrum.com/~rjsparks/rai-errata-batch1.html suggests to > approve the 1681 errata. However RFC 3261 section 8.1.3.5 conflicts > with the errata since it indicates that the From SHOULD be the same. I agree with you there -- when sending a new INVITE to correct an error in a previous one, the from-tag SHOULD be the same. (In practice, it MUST be the same.) Dale From christer.holmberg@ericsson.com Mon Feb 22 09:46:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76ACF28C342 for ; Mon, 22 Feb 2010 09:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.147, 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 xHV4T9OvkySU for ; Mon, 22 Feb 2010 09:46:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 47AFD28C173 for ; Mon, 22 Feb 2010 09:46:37 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bf-4b82c373968e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id AC.7C.02429.373C28B4; Mon, 22 Feb 2010 18:48:35 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 22 Feb 2010 18:48:35 +0100 From: Christer Holmberg To: 'Dale Worley' Date: Mon, 22 Feb 2010 18:48:35 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz5S5Ij6cSRcNNQfWd14BQyDZEfQAARj4g Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> In-Reply-To: <1266859994.3760.25.camel@khone.us.nortel.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:46:39 -0000 Hi Dale,=20 >> But, if I address the request to an AOR (which points to a domain, not=20 >> to a specific device) I might want to receive capabilities of all the=20 >> UAS associated with that AOR/domain. > >There is an ambiguity regarding what UAs you want to query. Do you want t= o query the UAs=20 >registered to the AOR in question, or do you want to query the UAs that an= INVITE sent to the=20 >AOR would reach? I want to query the UAs registered to the AOR. Regards, Christer From pkyzivat@cisco.com Mon Feb 22 09:52:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E617328C1C9 for ; Mon, 22 Feb 2010 09:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TV6Y+eawmgLF for ; Mon, 22 Feb 2010 09:52:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 500D228C173 for ; Mon, 22 Feb 2010 09:52:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEtTgktAZnwN/2dsb2JhbACbA3OlIZd9hGsEgxU X-IronPort-AV: E=Sophos;i="4.49,519,1262563200"; d="scan'208";a="87987816" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2010 17:54:07 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1MHs7v2028680; Mon, 22 Feb 2010 17:54:07 GMT Message-ID: <4B82C4BE.3090303@cisco.com> Date: Mon, 22 Feb 2010 12:54:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dale Worley References: <1266859994.3760.25.camel@khone.us.nortel.com> In-Reply-To: <1266859994.3760.25.camel@khone.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:52:13 -0000 Dale Worley wrote: > On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >> But, if I address the request to an AOR (which points to a domain, not >> to a specific device) I might want to receive capabilities of all the >> UAS associated with that AOR/domain. > > There is an ambiguity regarding what UAs you want to query. Do you want > to query the UAs registered to the AOR in question, or do you want to > query the UAs that an INVITE sent to the AOR would reach? Or do you want to query the server responsible for the AOR itself? (I.e. the proxy.) From christer.holmberg@ericsson.com Mon Feb 22 09:54:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F4C28C17B for ; Mon, 22 Feb 2010 09:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 epQOfPFuBQYv for ; Mon, 22 Feb 2010 09:54:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E57B428C343 for ; Mon, 22 Feb 2010 09:54:06 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-fd-4b82c53414c2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6D.EC.02429.435C28B4; Mon, 22 Feb 2010 18:56:05 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 22 Feb 2010 18:56:04 +0100 From: Christer Holmberg To: 'Dale Worley' Date: Mon, 22 Feb 2010 18:56:03 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz5bp9jz/7CzSZQlyPhRLsSsoaGQAAbwog Message-ID: References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> In-Reply-To: <1266860216.3760.30.camel@khone.us.nortel.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:54:08 -0000 Hi Dale, I think "no-cancel" is not applicable to OPTIONS, because: 1. OPTIONS are not cancelled by the forking proxy in the first place. 2. OPTIONS responses are re-transmitted when a re-transmission of the reque= st is received. For how long would the UAC keep re-transmitting the OPTIONS= request? How does it know that there will be no more 200 OKs? Regards, Christer=20 -----Original Message----- From: Dale Worley [mailto:dworley@avaya.com]=20 Sent: 22. helmikuuta 2010 19:37 To: Christer Holmberg Cc: SIPCORE Subject: RE: [sipcore] OPTIONS: How to solve the forking problem? On Sun, 2010-02-21 at 21:31 +0100, Christer Holmberg wrote: > I am not sure I understand how your example would solve it. >=20 > My understanding of 3261 is that the forking proxy will discard all=20 > but the first non-INVITE 200 OK. >=20 > Are you saying that "no-cancel" overrides that, or did I=20 > missunderstand something? My understanding is that the *intended (but poorly documented) meaning* of = "Request-Disposition: no-cancel" is to request that the proxy forward all 2= xx responses upstream, in much the way that it ordinarily would for INVITEs= . Otherwise, why would the proxy not cancel other forks when it receives a= 2xx? Dale From pkyzivat@cisco.com Mon Feb 22 10:05:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D188028C369 for ; Mon, 22 Feb 2010 10:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 U5DokQcCLHtT for ; Mon, 22 Feb 2010 10:05:50 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F376B28C366 for ; Mon, 22 Feb 2010 10:05:49 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFdWgktAZnwN/2dsb2JhbACbA3OlHZd/hGsEgxU X-IronPort-AV: E=Sophos;i="4.49,520,1262563200"; d="scan'208";a="241696482" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2010 18:07:36 +0000 Received: from [161.44.182.184] (dhcp-161-44-182-184.cisco.com [161.44.182.184]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1MI7aPw003250; Mon, 22 Feb 2010 18:07:36 GMT Message-ID: <4B82C7E7.9060805@cisco.com> Date: Mon, 22 Feb 2010 13:07:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Dale Worley' , SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:05:50 -0000 None of this matters, because for non-invite transactions the UAC's state machine is going to be done when the first final response is received. It isn't going to be prepared to handle other 200 responses to the same transaction. Thanks, Paul Christer Holmberg wrote: > Hi Dale, > > I think "no-cancel" is not applicable to OPTIONS, because: > > 1. OPTIONS are not cancelled by the forking proxy in the first place. > > 2. OPTIONS responses are re-transmitted when a re-transmission of the request is received. For how long would the UAC keep re-transmitting the OPTIONS request? How does it know that there will be no more 200 OKs? > > Regards, > > Christer > > -----Original Message----- > From: Dale Worley [mailto:dworley@avaya.com] > Sent: 22. helmikuuta 2010 19:37 > To: Christer Holmberg > Cc: SIPCORE > Subject: RE: [sipcore] OPTIONS: How to solve the forking problem? > > On Sun, 2010-02-21 at 21:31 +0100, Christer Holmberg wrote: >> I am not sure I understand how your example would solve it. >> >> My understanding of 3261 is that the forking proxy will discard all >> but the first non-INVITE 200 OK. >> >> Are you saying that "no-cancel" overrides that, or did I >> missunderstand something? > > My understanding is that the *intended (but poorly documented) meaning* of "Request-Disposition: no-cancel" is to request that the proxy forward all 2xx responses upstream, in much the way that it ordinarily would for INVITEs. Otherwise, why would the proxy not cancel other forks when it receives a 2xx? > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Feb 22 10:12:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD1A3A7982 for ; Mon, 22 Feb 2010 10:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 J7BQVcbDRGAC for ; Mon, 22 Feb 2010 10:12:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 172143A7870 for ; Mon, 22 Feb 2010 10:12:23 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-43-4b82c97e1f83 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1D.40.31641.E79C28B4; Mon, 22 Feb 2010 19:14:22 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 22 Feb 2010 19:14:21 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Dale Worley Date: Mon, 22 Feb 2010 19:14:21 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz6Axe7P+skS4FSxGGeeUMDt4eaAAAMlaw Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> In-Reply-To: <4B82C4BE.3090303@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:12:28 -0000 Hi,=20 >>> But, if I address the request to an AOR (which points to a domain,=20 >>> not to a specific device) I might want to receive capabilities of all=20 >>> the UAS associated with that AOR/domain. >>=20 >> There is an ambiguity regarding what UAs you want to query. Do you=20 >> want to query the UAs registered to the AOR in question, or do you=20 >> want to query the UAs that an INVITE sent to the AOR would reach? > >Or do you want to query the server responsible for the AOR itself? >(I.e. the proxy.) If the server responses on behalf of the server it can of course also inclu= de its own capabilities. But, a server that only sends back its capabilities might use a 200 instead= of 302 (if we would move forward with that solution for AOR query). But, those things would need to be studied and clarified. Regards, Christer= From christer.holmberg@ericsson.com Mon Feb 22 10:13:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3713A7B2E for ; Mon, 22 Feb 2010 10:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 GY0Nm1jNxYDt for ; Mon, 22 Feb 2010 10:13:39 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1D56A3A7870 for ; Mon, 22 Feb 2010 10:13:38 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-30-4b82c9c9ae41 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 96.0E.02429.9C9C28B4; Mon, 22 Feb 2010 19:15:37 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 22 Feb 2010 19:15:36 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Mon, 22 Feb 2010 19:15:36 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz6fPtRvbsWQg4Qn+Cga4oe6kJnwAAP4iA Message-ID: References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> In-Reply-To: <4B82C7E7.9060805@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-Brightmail-Tracker: AAAAAA== Cc: 'Dale Worley' , SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:13:40 -0000 Agree. Christer=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 22. helmikuuta 2010 20:08 To: Christer Holmberg Cc: 'Dale Worley'; SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? None of this matters, because for non-invite transactions the UAC's state m= achine is going to be done when the first final response is received. It is= n't going to be prepared to handle other 200 responses to the same transact= ion. Thanks, Paul Christer Holmberg wrote: > Hi Dale, >=20 > I think "no-cancel" is not applicable to OPTIONS, because: >=20 > 1. OPTIONS are not cancelled by the forking proxy in the first place. >=20 > 2. OPTIONS responses are re-transmitted when a re-transmission of the req= uest is received. For how long would the UAC keep re-transmitting the OPTIO= NS request? How does it know that there will be no more 200 OKs? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Dale Worley [mailto:dworley@avaya.com] > Sent: 22. helmikuuta 2010 19:37 > To: Christer Holmberg > Cc: SIPCORE > Subject: RE: [sipcore] OPTIONS: How to solve the forking problem? >=20 > On Sun, 2010-02-21 at 21:31 +0100, Christer Holmberg wrote: >> I am not sure I understand how your example would solve it. >> >> My understanding of 3261 is that the forking proxy will discard all=20 >> but the first non-INVITE 200 OK. >> >> Are you saying that "no-cancel" overrides that, or did I=20 >> missunderstand something? >=20 > My understanding is that the *intended (but poorly documented) meaning* o= f "Request-Disposition: no-cancel" is to request that the proxy forward all= 2xx responses upstream, in much the way that it ordinarily would for INVIT= Es. Otherwise, why would the proxy not cancel other forks when it receives= a 2xx? >=20 > Dale >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Mon Feb 22 10:28:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D66228C2E8 for ; Mon, 22 Feb 2010 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-2.632, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492] 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 Vd9ZnCLosGQy for ; Mon, 22 Feb 2010 10:28:34 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8A6B528C2BD for ; Mon, 22 Feb 2010 10:28:33 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-29-4b82cd47b91e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6D.CE.02429.74DC28B4; Mon, 22 Feb 2010 19:30:31 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 22 Feb 2010 19:30:31 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Mon, 22 Feb 2010 19:30:30 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: AcqzwnqxNYfe6RFaRDKil93KbHSvRgAKUhTg Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B7EA20E.3040806@nostrum.com> <4B8285B2.80801@cisco.com> In-Reply-To: <4B8285B2.80801@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:28:35 -0000 Hi, >For the "prefer video" option you mention, you can use callerprefs specifi= cally to express=20 >that, so that devices with video capabilities are tried first, and others = as a fallback. Sure, there are cases where it will work, e.g. if you don't require certain= s extensions and you don't want the message to look differen if it will rea= ch a "non-video" device. Regards, Christer Christer Holmberg wrote: > Hi, >=20 >> I'm a bit confused. On the rather remote chance that you want to poll=20 >> all of the UAs associated with an AOR, >=20 > I am not sure I agree on the "remote chance" thing. From my personal expe= rience, people are more interested in all UASs behind an AOR, in order to s= et feature tag values etc accordingly when later esttablishing a session. >=20 >> you can subscribe to the AOR's reg event state; collect the GRUUs;=20 >> and then send an OPTIONS to each UA in turn. >=20 > Sure, you can do that.=20 >=20 > The idea behind the proposal, however, is that you would at least be able= to get SOME information (even if only the gruus of the UASs, per Dean's pr= oposal) using a single request. >=20 > Then, if you need additional information (SDP etc), sending individual OP= TIONS might be the best solution. But, the information you got in the first= response might help you to decided to which UASs you are going to send ind= ividual OPTIONS. >=20 >> But what's the real use case here? I can't imagine anything you can=20 >> do with this information that doesn't work better with callerprefs. >=20 > One of the use-cases I have in mind is actually to enable better use of c= allerprefs. >=20 > For example, assume that Alice wants to make a call, and her first option= is to reach UAS devices that support video. So, she wants to use callerpre= fs to require video support. However, if no UAS support video, the call may= get rejected. >=20 > Alice could of course send a request which does not require video, but th= en the call might be answered by a phone which doesn't support it, even if = another phone would have supported it. >=20 > In addition, if all the non-video phones also get the request it might me= an more early dialogs etc, that at least on wireless accesses can create a = number of resource issues.=20 >=20 > Sure, you can BYE unwanted early dialogs, but why create them in the firs= t place? >=20 > A similar example (which is also described in RFC3261, I believe) is when= Alice wants to use an exension using the Require header, and wants to make= sure that there are UASs supporting the extension. >=20 > So, in general I don't think the use-case is very different usages of OPT= IONS, but it would allow users to get at least some capabilities of all use= rs behind an AOR using a single request. >=20 > Regards, >=20 > Christer >=20 >=20 > On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: >> I pretty much agree with John. >> >> IMO there is no point in doing anything unless there is also work to=20 >> clarify what the response *means* in a way that is operationally useful. >> >> Even when there is only one UA and the OPTIONS request is getting to=20 >> it, the result isn't especially useful, except as a "ping" because: >> >> - nominally the response code is supposed to be the same as >> it would be for an INVITE. I guess that means you should get >> a 486 response if the UA is on a call and would reject another. >> But what if the UA *never* accepts INVITES - only SUBSCRIBE? >> Should you get 405? >> >> - If the UA can in principle support a lot of things, but not >> all in the same call, there is no well defined way to reflect that. >> >> I would like to see a set of use cases for how people would like to=20 >> use OPTIONS where this enhancement is needed. >> >> Thanks, >> Paul >> >> Elwell, John wrote: >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >>>> Behalf Of Christer Holmberg >>>> Sent: 19 February 2010 11:28 >>>> To: SIPCORE >>>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>>> >>>> Hi, >>>> >>>> Some input regarding the OPTIONS issue. >>>> >>>> BACKGROUND: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> One of the main problems with OPTIONS is forking. In case the=20 >>>> request is forked, the UAC will only receive the capabilities of=20 >>>> one device/UAS (which UAS depends on which 200 OK reaches the=20 >>>> forking proxy first). >>>> >>>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP=20 >>>> URI always identify uniquely a specific resource or a specific server. >>>> But, if I address the request to an AOR (which points to a domain,=20 >>>> not to a specific device) I might want to receive capabilities of=20 >>>> all the UAS associated with that AOR/domain. >>>> First, do we agree that is a valid usage to address OPTIONS to an AOR? >>>> OR, do we think that OPTIONS should only be addressed to specific=20 >>>> devices (section 11 of 3261 talks about devices), in which case I=20 >>>> guess we don't need to do anything - at least not as far as forking=20 >>>> is concerned. >>>> >>>> The rest of this e-mail is based on the assumption that we DO want=20 >>>> to be able to address OPTIONS to an AOR. >>>> >>>> >>>> ABSTRACT: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> I have put together 3 alternative solutions on how the problem=20 >>>> could be fixed. The first alternative is based on a UAS change,=20 >>>> while the second and third alternatives are based on a model where=20 >>>> the registrar (forking proxy) sends a response "on behalf" of the UAS(= s). >>>> >>>> The 4th alternative is of course that we do nothing, but based on=20 >>>> previous discussions it does seem that some people are interested=20 >>>> in doing something about OPTIONS. >>>> >>>> >>>> ALTERNATIVE 1: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> In this alternative the UAS(s) send a provisional response,=20 >>>> including the capabilities, to the OPTIONS request. The registrar=20 >>>> will (hopefully) forward all the provisional responses towards the UAC= . >>>> >>>> Pros/cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>> + to >>>> get the capabilities of all UAS(s) associated with the AOR. >>>> + No impacts on registrar >>>> >>>> - Does not work with deployed Uas >>>> - Would the provisional response need to be PRACKed? >>> [JRE] I hope this Alternative 1 is not meant to be serious. This=20 >>> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT=20 >>> issue a provisional response for a non-INVITE request". I wonder how=20 >>> many SIP stacks would handle this. Also, having sent a provisional=20 >>> response, the UAS needs to send a final response, so how would this=20 >>> interact? >>> >>>> What to do: >>>> ----------------- >>>> >>>> This alternative would most likely require an RFC: either an=20 >>>> extension with an associated option-tag, or an update to 3261. >>>> >>>> >>>> >>>> ALTERNATIVE 2: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> In this alternative the registrar never forks the OPTIONS request=20 >>>> towards the UAS(s). Instead, it sends a response on behalf of the=20 >>>> UASs, based on the information is has about the UAS(s), based on=20 >>>> registration information (feature tags etc) etc. >>>> >>>> The first question is whether 3261 already allows this: >>>> >>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect=20 >>>> to get capabilities associated with that AOR (which points to a=20 >>>> domain, not to a specific device). Currently, in case of forking, I=20 >>>> will only get the capabilities from one device/UAS associated with=20 >>>> that domain. >>>> >>>> But, if the registrar sends the OPTIONS response, it can provide=20 >>>> capabilities of all registered UAS(s) associated with the AOR/domain. >>>> >>>> So, so far I don't think 3261 forbids this kind of behavior (in=20 >>>> fact, I think this kind of behavior actually better implements what=20 >>>> is described in 3261...) >>>> >>>> >>>> Now, the best way to return the capabilities would probably be by=20 >>>> using a message body, e.g. a multipart with sipfrag body parts=20 >>>> (each sipfrag body part representing a UAS). >>> [JRE] And that sipfrag body part would need to contain an SDP body=20 >>> part to represent the SDP capabilities of the UAS? This would make=20 >>> responses potentially very large, posing a problem for UDP. It is=20 >>> probably a more extreme example than anything we have had before of=20 >>> a response being VERY MUCH larger than a request. >>> >>>> But, RFC3261 says that a proxy does not insert a message body in=20 >>>> the OPTIONS response, and that is probably ok in most cases when=20 >>>> the proxy returns its owns capabilities. But, when the proxy=20 >>>> replies on behalf of the UAS(s), I see no reason why it should not=20 >>>> be allowed to include a body. The UAC will get the capabilities of=20 >>>> the UAS(s), and that is what matters. >>> [JRE] In this case what you call the proxy is the UAS w.r.t. this=20 >>> particular transaction, so it can include a body. >>> >>>> Pros/cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>> + to >>>> get the capabilities of all UAS(s) associated with the AOR. >>> [JRE] I am not sure what it needs this for, but we have the=20 >>> reg-event package to identify all registered Uas, and then OPTIONS=20 >>> could be directed at each in turn. >>> >>>> + In my personal opinion this does not require any changes in >>>> + RFC3261 >>>> >>>> - The set of capabilities per UAS is limited to what the registrar=20 >>>> knows about the UAS (based on registration information, and/or by=20 >>>> provisioning), so SDP information would probably be left out. The=20 >>>> mechanism might still be good enough for many scenarios, though. >>>> >>>> What to do: >>>> ----------------- >>>> >>>> If we think RFC3261 allows this, the question is whether we=20 >>>> consider it so crystal clear that nothing needs to be specified, or=20 >>>> whether it would be a good idea to put together a BCP type-of=20 >>>> document describing it. >>>> >>>> Or, do people think that this is NOT allowed behavior? >>> [JRE] Even if allowed, I think we might need some specification of=20 >>> the sipfrag part of it, and I am concerned about the response size. >>> But I am not convinced there is a requirement to be able to use=20 >>> OPTIONS to get information about multiple UAs at once. >>> >>>> >>>> >>>> >>>> ALTERNATIVE 3: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> The idea is similar to Alternative 1, but in this case the=20 >>>> registrar would fork the OPTIONS request towards the UAS(s), then "COL= LECT" >>>> the responses, and finally send a single response which contains=20 >>>> the capabilities of all UAS(s) towards the UAC. >>> [JRE] Again using sipfrags? >>> >>>> Prox/Cons: >>>> ---------------- >>>> >>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>> + to >>>> get the capabilities of all UAS(s). >>>> + The UAC will get more or less the same set of capabilities for an >>>> UAS, as if the UAS would have sent the response directly to the UAC. >>>> >>>> - I guess most people would consider the forking proxy acting as a=20 >>>> B2BUA in this case, since it does not follow the 3261 rules about=20 >>>> forwarding (or discarding) 200 OK responses immediately when received. >>>> >>>> What to do: >>>> ----------------- >>>> >>>> If we think this is a good solution, could it be described in a BCP?=20 >>>> I guess we would not update 3261 to describe this behavior? >>> [JRE] Again we would need to specify the sipfrag bits of it, and I=20 >>> would be concerned about the response size. >>> >>> John >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Mon Feb 22 10:33:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB7D28C342 for ; Mon, 22 Feb 2010 10:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 44QpNrptjME4 for ; Mon, 22 Feb 2010 10:32:59 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 18D5F28C0DC for ; Mon, 22 Feb 2010 10:32:58 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-08-4b82ce519f98 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 99.0F.02429.15EC28B4; Mon, 22 Feb 2010 19:34:57 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 22 Feb 2010 19:34:57 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Dean Willis Date: Mon, 22 Feb 2010 19:34:55 +0100 Thread-Topic: [sipcore] 3265bis and Call-Info Thread-Index: Acqzwe/EK0ud58uCRU+aBkIle6csQAAK2BZg Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> In-Reply-To: <4B8284CC.8050800@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:33:00 -0000 Hi, I think that idea sounds good also. What about the table that shows for which methods (requests and/or response= types) a header is applicable? Would it be possible to do something simila= r for that? It would need to be updated whenever a new method is defined (w= hich isn't that often). Regards, Christer=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 22. helmikuuta 2010 15:21 To: Dean Willis Cc: Christer Holmberg; SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info Dean Willis wrote: >> We had this discussion a while ago, and it may be good to start it=20 >> again. I think at least Dean mentioned abandoning Table 2. I talked=20 >> about having a website instead, which would be easier to keep up to=20 >> date, but I think the IETF proceures didn't allow that. >=20 > Right. for things that one might use a website for, we have IANA=20 > registries. >=20 > One could replace Table 2 with a registry, and have new RFCs update=20 > that registry. I support this approach. Thanks, Paul From salvatore.loreto@ericsson.com Mon Feb 22 10:55:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8947928C217 for ; Mon, 22 Feb 2010 10:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, 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 5HQsCMW5aynA for ; Mon, 22 Feb 2010 10:55:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4DCFC3A7D1E for ; Mon, 22 Feb 2010 10:55:18 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-7a-4b82d38d4586 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DC.62.31641.D83D28B4; Mon, 22 Feb 2010 19:57:17 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 19:57:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 19:57:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7E261245C; Mon, 22 Feb 2010 20:57:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 38CD621A41; Mon, 22 Feb 2010 20:57:16 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CAD02219C4; Mon, 22 Feb 2010 20:57:15 +0200 (EET) Message-ID: <4B82D38B.1090601@ericsson.com> Date: Mon, 22 Feb 2010 20:57:15 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: sipcore@ietf.org, Paul Kyzivat , Dale Worley References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> In-Reply-To: <4B82C4BE.3090303@cisco.com> Content-Type: multipart/alternative; boundary="------------000301040507000707000707" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 22 Feb 2010 18:57:16.0494 (UTC) FILETIME=[DA07AEE0:01CAB3F0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:55:20 -0000 This is a multi-part message in MIME format. --------------000301040507000707000707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/22/2010 07:54 PM, Paul Kyzivat wrote: > > Dale Worley wrote: > >> On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >> >>> But, if I address the request to an AOR (which points to a domain, not >>> to a specific device) I might want to receive capabilities of all the >>> UAS associated with that AOR/domain. >>> >> There is an ambiguity regarding what UAs you want to query. Do you want >> to query the UAs registered to the AOR in question, or do you want to >> query the UAs that an INVITE sent to the AOR would reach? >> > Or do you want to query the server responsible for the AOR itself? > (I.e. the proxy.) > I tend to agree with Paul, RFC3261 section 11: The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. moreover 3261 defines: Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. so "in theory" a SIP OPTIONS request to an AoR should be interpreted as a request to a SIP Proxy/Server that is authoritative for that AoR, and then the response should be... without any body... /Sal --------------000301040507000707000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/22/2010 07:54 PM, Paul Kyzivat wrote: 

Dale Worley wrote:
  
On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
    
But, if I address the request to an AOR (which points to a domain, not
to a specific device) I might want to receive capabilities of all the
UAS associated with that AOR/domain. 
      
There is an ambiguity regarding what UAs you want to query.  Do you want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?
    
Or do you want to query the server responsible for the AOR itself?
(I.e. the proxy.)
I tend to agree with Paul,

RFC3261 section 11:

   The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.
moreover 3261 defines:
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.


so "in theory" a SIP OPTIONS request to an AoR should be interpreted as
a request to a SIP Proxy/Server that is authoritative for that AoR,
and then the response should be... without any body...

/Sal
--------------000301040507000707000707-- From ietf.hanserik@gmail.com Mon Feb 22 11:01:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BEA28C350 for ; Mon, 22 Feb 2010 11:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 e+NFaDElNnop for ; Mon, 22 Feb 2010 11:01:42 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 56A8828C305 for ; Mon, 22 Feb 2010 11:01:42 -0800 (PST) Received: by ewy28 with SMTP id 28so3100739ewy.28 for ; Mon, 22 Feb 2010 11:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dLJqLz1XkL8BDN6HRj2uHowDVSLVkLxzVNdeVyOw+LA=; b=dTFOIm9Bqpmm/b6x36QxRTt1Gh2iLqA4yUKrXivvqA3wDvoAB4rST9cZej5kGdMy0w tX3pU7lQgVrWrQtcLGsuSQKmeSI4C39hodgUHNzCEJ/qL1cayLxfyeG1pXz+xCuQktls 8bdqn1LxNhDZtLLo886QabStSVEj3RfKzcrUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z8Q4CRvmXrne2Ua53y/3KIFiuLnRGmeWjST5G/vvzV9t91Gs9BsZmBgZB0fkfym0Rd jN9VDC1m3eZV1K+9Dy3kXd8GwQIQCpMIWuXjvk25GivgtuG9MILPKRmdfjQkLSFWHu3w bPzTyceaIbT1jwhxA0oOxqfLmoHROfI2XHC+Y= MIME-Version: 1.0 Received: by 10.213.65.138 with SMTP id j10mr847278ebi.23.1266865418120; Mon, 22 Feb 2010 11:03:38 -0800 (PST) In-Reply-To: <4B82D38B.1090601@ericsson.com> References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> Date: Mon, 22 Feb 2010 20:03:37 +0100 Message-ID: <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> From: Hans Erik van Elburg To: Salvatore Loreto Content-Type: multipart/alternative; boundary=00c09f8e5d8539b704048035179b Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:01:44 -0000 --00c09f8e5d8539b704048035179b Content-Type: text/plain; charset=ISO-8859-1 If you would follow that logic no request would ever reach a UA. BR, /Hans Erik van Elburg On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > On 02/22/2010 07:54 PM, Paul Kyzivat wrote: > > Dale Worley wrote: > > > On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > > > But, if I address the request to an AOR (which points to a domain, not > to a specific device) I might want to receive capabilities of all the > UAS associated with that AOR/domain. > > > There is an ambiguity regarding what UAs you want to query. Do you want > to query the UAs registered to the AOR in question, or do you want to > query the UAs that an INVITE sent to the AOR would reach? > > > Or do you want to query the server responsible for the AOR itself? > (I.e. the proxy.) > > > I tend to agree with Paul, > > RFC3261 section 11: > > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. > > > moreover 3261 defines: > > Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > > > > so "in theory" a SIP OPTIONS request to an AoR should be interpreted as > a request to a SIP Proxy/Server that is authoritative for that AoR, > and then the response should be... without any body... > > /Sal > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --00c09f8e5d8539b704048035179b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you would follow that logic no request would ever reach a UA.

BR,=
/Hans Erik van Elburg


On Mon, Feb 22, 2010 at 7:57 PM, Salvato= re Loreto <salvatore.loreto@ericsson.com> wrote:
=20
On 02/22/2010 07:54 PM, Paul Kyzivat wrote: 
Dale Worley wrote:
  
On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
    
But, if I address the request to an AOR (which points to a domai=
n, not
to a specific device) I might want to receive capabilities of all the
UAS associated with that AOR/domain.=20
      
There is an ambiguity regarding what UAs you want to query.  Do yo=
u want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?
    
Or do you want to query the server responsible for the AOR itself?
(I.e. the proxy.)
I tend to agree with Paul,

RFC3261 section 11:

   The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.
moreover 3261 defines:
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.


so "in theory" a SIP OPTIONS request to an AoR should be interpre= ted as
a request to a SIP Proxy/Server that is authoritative for that AoR,
and then the response should be... without any body...

/Sal

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--00c09f8e5d8539b704048035179b-- From pkyzivat@cisco.com Mon Feb 22 11:07:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA79328C350 for ; Mon, 22 Feb 2010 11:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.076 X-Spam-Level: X-Spam-Status: No, score=-8.076 tagged_above=-999 required=5 tests=[AWL=-2.461, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492, RCVD_IN_DNSWL_HI=-8] 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 GMIOE69vvttg for ; Mon, 22 Feb 2010 11:06:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1283528C37B for ; Mon, 22 Feb 2010 11:06:59 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAORkgktAZnwN/2dsb2JhbACbA3OlV5gDgkqCIQSDFQ X-IronPort-AV: E=Sophos;i="4.49,520,1262563200"; d="scan'208";a="154981219" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2010 19:08:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1MJ8vAV026216; Mon, 22 Feb 2010 19:08:57 GMT Message-ID: <4B82D647.2040203@cisco.com> Date: Mon, 22 Feb 2010 14:08:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7E9EAD.20201@cisco.com> <4B7EA20E.3040806@nostrum.com> <4B8285B2.80801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:07:00 -0000 Christer Holmberg wrote: > Hi, > >> For the "prefer video" option you mention, you can use callerprefs specifically to express >> that, so that devices with video capabilities are tried first, and others as a fallback. > > Sure, there are cases where it will work, e.g. if you don't require certains extensions and you don't want the message to look differen if it will reach a "non-video" device. While its an incredible pain, you can specify fairly sophisticated selection criteria. IMO the most fundamental issue with this approach is you are never certain if your *preferences* will be honored, whether this is because of conflicting policies, or because the devices just don't support the processing of callerprefs. I recognize that there is a lot more certainty when the caller can examine all the possibilities and make its own decisions. But this is also fundamentally limited, because the called user may well be unwilling to share with you the information you need to make your decision. (I quite likely will not let unknown callers know how many UAs of which types I have connected, or what algorithms I might use to decide to route your call to one of them or to VM.) One answer is for the caller to first try presence. If it can get info via presence, then it can make its own decision based on that. If not, It can try using callerprefs and hope for the best. You can view OPTIONS as a poor man's version of one-shot presence. Rather than fix it, maybe we should be trying to work our some recommendations for providing presence information to unknown subscribers. Thanks, Paul > Regards, > > Christer > > > > > > Christer Holmberg wrote: >> Hi, >> >>> I'm a bit confused. On the rather remote chance that you want to poll >>> all of the UAs associated with an AOR, >> I am not sure I agree on the "remote chance" thing. From my personal experience, people are more interested in all UASs behind an AOR, in order to set feature tag values etc accordingly when later esttablishing a session. >> >>> you can subscribe to the AOR's reg event state; collect the GRUUs; >>> and then send an OPTIONS to each UA in turn. >> Sure, you can do that. >> >> The idea behind the proposal, however, is that you would at least be able to get SOME information (even if only the gruus of the UASs, per Dean's proposal) using a single request. >> >> Then, if you need additional information (SDP etc), sending individual OPTIONS might be the best solution. But, the information you got in the first response might help you to decided to which UASs you are going to send individual OPTIONS. >> >>> But what's the real use case here? I can't imagine anything you can >>> do with this information that doesn't work better with callerprefs. >> One of the use-cases I have in mind is actually to enable better use of callerprefs. >> >> For example, assume that Alice wants to make a call, and her first option is to reach UAS devices that support video. So, she wants to use callerprefs to require video support. However, if no UAS support video, the call may get rejected. >> >> Alice could of course send a request which does not require video, but then the call might be answered by a phone which doesn't support it, even if another phone would have supported it. >> >> In addition, if all the non-video phones also get the request it might mean more early dialogs etc, that at least on wireless accesses can create a number of resource issues. >> >> Sure, you can BYE unwanted early dialogs, but why create them in the first place? >> >> A similar example (which is also described in RFC3261, I believe) is when Alice wants to use an exension using the Require header, and wants to make sure that there are UASs supporting the extension. >> >> So, in general I don't think the use-case is very different usages of OPTIONS, but it would allow users to get at least some capabilities of all users behind an AOR using a single request. >> >> Regards, >> >> Christer >> >> >> On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: >>> I pretty much agree with John. >>> >>> IMO there is no point in doing anything unless there is also work to >>> clarify what the response *means* in a way that is operationally useful. >>> >>> Even when there is only one UA and the OPTIONS request is getting to >>> it, the result isn't especially useful, except as a "ping" because: >>> >>> - nominally the response code is supposed to be the same as >>> it would be for an INVITE. I guess that means you should get >>> a 486 response if the UA is on a call and would reject another. >>> But what if the UA *never* accepts INVITES - only SUBSCRIBE? >>> Should you get 405? >>> >>> - If the UA can in principle support a lot of things, but not >>> all in the same call, there is no well defined way to reflect that. >>> >>> I would like to see a set of use cases for how people would like to >>> use OPTIONS where this enhancement is needed. >>> >>> Thanks, >>> Paul >>> >>> Elwell, John wrote: >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>> Behalf Of Christer Holmberg >>>>> Sent: 19 February 2010 11:28 >>>>> To: SIPCORE >>>>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>>>> >>>>> Hi, >>>>> >>>>> Some input regarding the OPTIONS issue. >>>>> >>>>> BACKGROUND: >>>>> ============ >>>>> >>>>> One of the main problems with OPTIONS is forking. In case the >>>>> request is forked, the UAC will only receive the capabilities of >>>>> one device/UAS (which UAS depends on which 200 OK reaches the >>>>> forking proxy first). >>>>> >>>>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP >>>>> URI always identify uniquely a specific resource or a specific server. >>>>> But, if I address the request to an AOR (which points to a domain, >>>>> not to a specific device) I might want to receive capabilities of >>>>> all the UAS associated with that AOR/domain. >>>>> First, do we agree that is a valid usage to address OPTIONS to an AOR? >>>>> OR, do we think that OPTIONS should only be addressed to specific >>>>> devices (section 11 of 3261 talks about devices), in which case I >>>>> guess we don't need to do anything - at least not as far as forking >>>>> is concerned. >>>>> >>>>> The rest of this e-mail is based on the assumption that we DO want >>>>> to be able to address OPTIONS to an AOR. >>>>> >>>>> >>>>> ABSTRACT: >>>>> ========= >>>>> >>>>> I have put together 3 alternative solutions on how the problem >>>>> could be fixed. The first alternative is based on a UAS change, >>>>> while the second and third alternatives are based on a model where >>>>> the registrar (forking proxy) sends a response "on behalf" of the UAS(s). >>>>> >>>>> The 4th alternative is of course that we do nothing, but based on >>>>> previous discussions it does seem that some people are interested >>>>> in doing something about OPTIONS. >>>>> >>>>> >>>>> ALTERNATIVE 1: >>>>> ============= >>>>> >>>>> In this alternative the UAS(s) send a provisional response, >>>>> including the capabilities, to the OPTIONS request. The registrar >>>>> will (hopefully) forward all the provisional responses towards the UAC. >>>>> >>>>> Pros/cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC >>>>> + to >>>>> get the capabilities of all UAS(s) associated with the AOR. >>>>> + No impacts on registrar >>>>> >>>>> - Does not work with deployed Uas >>>>> - Would the provisional response need to be PRACKed? >>>> [JRE] I hope this Alternative 1 is not meant to be serious. This >>>> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT >>>> issue a provisional response for a non-INVITE request". I wonder how >>>> many SIP stacks would handle this. Also, having sent a provisional >>>> response, the UAS needs to send a final response, so how would this >>>> interact? >>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> This alternative would most likely require an RFC: either an >>>>> extension with an associated option-tag, or an update to 3261. >>>>> >>>>> >>>>> >>>>> ALTERNATIVE 2: >>>>> ============= >>>>> >>>>> In this alternative the registrar never forks the OPTIONS request >>>>> towards the UAS(s). Instead, it sends a response on behalf of the >>>>> UASs, based on the information is has about the UAS(s), based on >>>>> registration information (feature tags etc) etc. >>>>> >>>>> The first question is whether 3261 already allows this: >>>>> >>>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect >>>>> to get capabilities associated with that AOR (which points to a >>>>> domain, not to a specific device). Currently, in case of forking, I >>>>> will only get the capabilities from one device/UAS associated with >>>>> that domain. >>>>> >>>>> But, if the registrar sends the OPTIONS response, it can provide >>>>> capabilities of all registered UAS(s) associated with the AOR/domain. >>>>> >>>>> So, so far I don't think 3261 forbids this kind of behavior (in >>>>> fact, I think this kind of behavior actually better implements what >>>>> is described in 3261...) >>>>> >>>>> >>>>> Now, the best way to return the capabilities would probably be by >>>>> using a message body, e.g. a multipart with sipfrag body parts >>>>> (each sipfrag body part representing a UAS). >>>> [JRE] And that sipfrag body part would need to contain an SDP body >>>> part to represent the SDP capabilities of the UAS? This would make >>>> responses potentially very large, posing a problem for UDP. It is >>>> probably a more extreme example than anything we have had before of >>>> a response being VERY MUCH larger than a request. >>>> >>>>> But, RFC3261 says that a proxy does not insert a message body in >>>>> the OPTIONS response, and that is probably ok in most cases when >>>>> the proxy returns its owns capabilities. But, when the proxy >>>>> replies on behalf of the UAS(s), I see no reason why it should not >>>>> be allowed to include a body. The UAC will get the capabilities of >>>>> the UAS(s), and that is what matters. >>>> [JRE] In this case what you call the proxy is the UAS w.r.t. this >>>> particular transaction, so it can include a body. >>>> >>>>> Pros/cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC >>>>> + to >>>>> get the capabilities of all UAS(s) associated with the AOR. >>>> [JRE] I am not sure what it needs this for, but we have the >>>> reg-event package to identify all registered Uas, and then OPTIONS >>>> could be directed at each in turn. >>>> >>>>> + In my personal opinion this does not require any changes in >>>>> + RFC3261 >>>>> >>>>> - The set of capabilities per UAS is limited to what the registrar >>>>> knows about the UAS (based on registration information, and/or by >>>>> provisioning), so SDP information would probably be left out. The >>>>> mechanism might still be good enough for many scenarios, though. >>>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> If we think RFC3261 allows this, the question is whether we >>>>> consider it so crystal clear that nothing needs to be specified, or >>>>> whether it would be a good idea to put together a BCP type-of >>>>> document describing it. >>>>> >>>>> Or, do people think that this is NOT allowed behavior? >>>> [JRE] Even if allowed, I think we might need some specification of >>>> the sipfrag part of it, and I am concerned about the response size. >>>> But I am not convinced there is a requirement to be able to use >>>> OPTIONS to get information about multiple UAs at once. >>>> >>>>> >>>>> >>>>> ALTERNATIVE 3: >>>>> ============= >>>>> >>>>> The idea is similar to Alternative 1, but in this case the >>>>> registrar would fork the OPTIONS request towards the UAS(s), then "COLLECT" >>>>> the responses, and finally send a single response which contains >>>>> the capabilities of all UAS(s) towards the UAC. >>>> [JRE] Again using sipfrags? >>>> >>>>> Prox/Cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC >>>>> + to >>>>> get the capabilities of all UAS(s). >>>>> + The UAC will get more or less the same set of capabilities for an >>>>> UAS, as if the UAS would have sent the response directly to the UAC. >>>>> >>>>> - I guess most people would consider the forking proxy acting as a >>>>> B2BUA in this case, since it does not follow the 3261 rules about >>>>> forwarding (or discarding) 200 OK responses immediately when received. >>>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> If we think this is a good solution, could it be described in a BCP? >>>>> I guess we would not update 3261 to describe this behavior? >>>> [JRE] Again we would need to specify the sipfrag bits of it, and I >>>> would be concerned about the response size. >>>> >>>> John >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From salvatore.loreto@ericsson.com Mon Feb 22 11:14:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92D73A8213 for ; Mon, 22 Feb 2010 11:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, 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 FWohyiiFQ6Lc for ; Mon, 22 Feb 2010 11:14:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 66FA93A7C42 for ; Mon, 22 Feb 2010 11:14:26 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bb-4b82d8081514 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 35.11.02429.808D28B4; Mon, 22 Feb 2010 20:16:24 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 20:16:23 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 20:16:23 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 93188245C; Mon, 22 Feb 2010 21:16:23 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 50DC421A41; Mon, 22 Feb 2010 21:16:23 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E4C8D219C4; Mon, 22 Feb 2010 21:16:22 +0200 (EET) Message-ID: <4B82D806.1020103@ericsson.com> Date: Mon, 22 Feb 2010 21:16:22 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hans Erik van Elburg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> In-Reply-To: <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------050806060704070100080208" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 22 Feb 2010 19:16:23.0901 (UTC) FILETIME=[85F018D0:01CAB3F3] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Dale Worley Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:14:29 -0000 This is a multi-part message in MIME format. --------------050806060704070100080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit not really, the problem is only with OPTIONS requests: The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. so when you address the request to an AoR ... there is a clear ambiguity on what you are really requesting. even if "historically" the usage is that you want to query the UAs than an INVITE sent to the AoR would reach, /Sal On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote: > If you would follow that logic no request would ever reach a UA. > > BR, > /Hans Erik van Elburg > > > On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto > > > wrote: > > On 02/22/2010 07:54 PM, Paul Kyzivat wrote: >> Dale Worley wrote: >> >>> On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >>> >>>> But, if I address the request to an AOR (which points to a domain, not >>>> to a specific device) I might want to receive capabilities of all the >>>> UAS associated with that AOR/domain. >>>> >>> There is an ambiguity regarding what UAs you want to query. Do you want >>> to query the UAs registered to the AOR in question, or do you want to >>> query the UAs that an INVITE sent to the AOR would reach? >>> >> Or do you want to query the server responsible for the AOR itself? >> (I.e. the proxy.) >> > I tend to agree with Paul, > > RFC3261 section 11: > > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. > > > > moreover 3261 defines: > > Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > > > > so "in theory" a SIP OPTIONS request to an AoR should be > interpreted as > a request to a SIP Proxy/Server that is authoritative for that AoR, > and then the response should be... without any body... > > /Sal > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --------------050806060704070100080208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit not really, the problem is only with OPTIONS requests:

   The SIP method OPTIONS allows a UA to query another UA or a proxy
   server as to its capabilities.

so when you address the request to an AoR ... there is a clear ambiguity on what you are really requesting.

even if "historically" the usage is that you want to query the UAs than an INVITE sent to the AoR would reach,

/Sal

On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote:
If you would follow that logic no request would ever reach a UA.

BR,
/Hans Erik van Elburg


On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
On 02/22/2010 07:54 PM, Paul Kyzivat wrote: 
Dale Worley wrote:
  
On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
    
But, if I address the request to an AOR (which points to a domain, not
to a specific device) I might want to receive capabilities of all the
UAS associated with that AOR/domain. 
      
There is an ambiguity regarding what UAs you want to query.  Do you want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?
    
Or do you want to query the server responsible for the AOR itself?
(I.e. the proxy.)
I tend to agree with Paul,

RFC3261 section 11:

   The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.
moreover 3261 defines:
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.


so "in theory" a SIP OPTIONS request to an AoR should be interpreted as
a request to a SIP Proxy/Server that is authoritative for that AoR,
and then the response should be... without any body...

/Sal

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



--------------050806060704070100080208-- From ietf.hanserik@gmail.com Mon Feb 22 11:21:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427C23A7FAC for ; Mon, 22 Feb 2010 11:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ay1o6YMF8S50 for ; Mon, 22 Feb 2010 11:21:31 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id BB27C3A7D1B for ; Mon, 22 Feb 2010 11:21:30 -0800 (PST) Received: by ewy28 with SMTP id 28so3123797ewy.28 for ; Mon, 22 Feb 2010 11:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SHvSr44JQpUNvGCV7+P1OUw+jdcdqaGSv3FlLBW4fnI=; b=OipEUHs+yX/h/xeMURfsuwpZhqDdY2clzaW8vPSUj9qp8HDwMKkS62KHldOfx9PrUW kO/cIo2bhu6+o0kcGyBuSeid4yzb+BbehM4u9eyR5VW3UStylD0nC64jy1GCCZ5CA700 CbAAqRLZiYiXHwx5gEZlTNTXFY3OuTPV/kJmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lmf4CixmeLtoMAWfG9kM4GxA3M2lVIHPqMBCvuAtGBz/c7pnOqWp3t1zN1CJp25US/ g8edbEGVH9aeWL7rNSlw6NwUjcgP4suJM97pvcJ+OdzDE3dh0/F/4j4NOW/aqY15z7cY RCzkptk/4j37NVjwyeOkMEu5abWnSGDnw02dY= MIME-Version: 1.0 Received: by 10.213.51.195 with SMTP id e3mr4554607ebg.96.1266866603870; Mon, 22 Feb 2010 11:23:23 -0800 (PST) In-Reply-To: <4B82D806.1020103@ericsson.com> References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> <4B82D806.1020103@ericsson.com> Date: Mon, 22 Feb 2010 20:23:23 +0100 Message-ID: <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> From: Hans Erik van Elburg To: Salvatore Loreto Content-Type: multipart/alternative; boundary=00163613756ae6cdce0480355d78 Cc: "sipcore@ietf.org" , Dale Worley Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:21:32 -0000 --00163613756ae6cdce0480355d78 Content-Type: text/plain; charset=ISO-8859-1 The sentence "The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server." does not imply that you can only adress AOR's. If a Request-URI happen to contain a proxy servers address, then the request will be targeted at the proxy server and not at a UA. If it contains an AOR then it is adressed at whatever entities the location server lookup function resolves to (this may even be recursive). /Hans Erik van Elburg On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > not really, the problem is only with OPTIONS requests: > > The SIP method OPTIONS allows a UA to query another UA or a proxy > server as to its capabilities. > > > so when you address the request to an AoR ... there is a clear ambiguity on > what you are really requesting. > > even if "historically" the usage is that you want to query the UAs than an > INVITE sent to the AoR would reach, > > /Sal > > > On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote: > > If you would follow that logic no request would ever reach a UA. > > BR, > /Hans Erik van Elburg > > > On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto < > salvatore.loreto@ericsson.com> wrote: > > On 02/22/2010 07:54 PM, Paul Kyzivat wrote: > > Dale Worley wrote: > > > On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > > > But, if I address the request to an AOR (which points to a domain, not > to a specific device) I might want to receive capabilities of all the > UAS associated with that AOR/domain. > > > There is an ambiguity regarding what UAs you want to query. Do you want > to query the UAs registered to the AOR in question, or do you want to > query the UAs that an INVITE sent to the AOR would reach? > > > Or do you want to query the server responsible for the AOR itself? > (I.e. the proxy.) > > > I tend to agree with Paul, > > RFC3261 section 11: > > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. > > > > moreover 3261 defines: > > Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > > > > so "in theory" a SIP OPTIONS request to an AoR should be interpreted as > a request to a SIP Proxy/Server that is authoritative for that AoR, > and then the response should be... without any body... > > /Sal > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > --00163613756ae6cdce0480355d78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The sentence "The target of the OPTIONS request is identified by the R= equest-URI, which could identify another UA or a SIP server." does n= ot imply that you can only adress AOR's.

If a Request-URI happe= n to contain a proxy servers address, then the request will be targeted at = the proxy server and not at a UA. If it contains an AOR then it is adressed= at whatever entities the location server lookup function resolves to (this= may even be recursive).

/Hans Erik van Elburg


On Mon, Feb 22, 2010 at 8:16 PM, Salvato= re Loreto <salvatore.loreto@ericsson.com> wrote:=
=20
not really, the problem is only with OPTIONS requests:

   The SIP method OPTIONS allows a UA to query another UA or a proxy
   server as to its capabilities.

so when you address the request to an AoR ... there is a clear ambiguity on what you are really requesting.

even if "historically" the usage is that you want to query the UA= s than an INVITE sent to the AoR would reach,

/Sal


On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote:
=20 If you would follow that logic no request would ever reach a UA.

BR,
/Hans Erik van Elburg


On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto <salvatore.loret= o@ericsson.com> wrote:
On 02/22/2010 07:54 PM, Paul Kyzivat wrote: 
Dale Worley wrote:
  
On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
    
But, if I address the request to an AOR (which points to a d=
omain, not
to a specific device) I might want to receive capabilities of all the
UAS associated with that AOR/domain.=20
      
There is an ambiguity regarding what UAs you want to query.  D=
o you want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?
    
Or do you want to query the server responsible for the AOR itsel=
f?
(I.e. the proxy.)
I tend to agree with Paul,

RFC3261 section 11:

   The target of the OPTIONS request is identified by the Request-=
URI,
   which could identify another UA or a SIP server.
moreover 3261 defines:
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS U=
RI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.


so "in theory" a SIP OPTIONS request to an AoR should be interpre= ted as
a request to a SIP Proxy/Server that is authoritative for that AoR,
and then the response should be... without any body...

/Sal

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/sipcore




--00163613756ae6cdce0480355d78-- From salvatore.loreto@ericsson.com Mon Feb 22 11:28:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACDF28C1AB for ; Mon, 22 Feb 2010 11:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, 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 D1cGLwQAGlR7 for ; Mon, 22 Feb 2010 11:28:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4FD3528C1A4 for ; Mon, 22 Feb 2010 11:28:46 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-27-4b82db64f2fa Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 03.24.31641.46BD28B4; Mon, 22 Feb 2010 20:30:44 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 20:30:43 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 20:30:43 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ADEC7245C; Mon, 22 Feb 2010 21:30:43 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 786DD21A41; Mon, 22 Feb 2010 21:30:43 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 23898219C4; Mon, 22 Feb 2010 21:30:43 +0200 (EET) Message-ID: <4B82DB62.8040405@ericsson.com> Date: Mon, 22 Feb 2010 21:30:42 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hans Erik van Elburg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> <4B82D806.1020103@ericsson.com> <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> In-Reply-To: <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060100030303040306010401" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 22 Feb 2010 19:30:43.0989 (UTC) FILETIME=[86971C50:01CAB3F5] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Dale Worley Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:28:47 -0000 This is a multi-part message in MIME format. --------------060100030303040306010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/22/2010 09:23 PM, Hans Erik van Elburg wrote: > The sentence "The target of the OPTIONS request is identified by the > Request-URI, which could identify another UA or a SIP server." does > not imply that you can only adress AOR's. > > If a Request-URI happen to contain a proxy servers address, then the > request will be targeted at the proxy server and not at a UA. If it > contains an AOR then it is adressed at whatever entities the location > server lookup function resolves to (this may even be recursive). it could be a possibility but I do still think 3261 is unclear here. /Sal --------------060100030303040306010401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/22/2010 09:23 PM, Hans Erik van Elburg wrote:
The sentence "The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server." does not imply that you can only adress AOR's.

If a Request-URI happen to contain a proxy servers address, then the request will be targeted at the proxy server and not at a UA. If it contains an AOR then it is adressed at whatever entities the location server lookup function resolves to (this may even be recursive).

it could be a possibility
but I do still think 3261 is unclear here.

/Sal
--------------060100030303040306010401-- From pkyzivat@cisco.com Mon Feb 22 11:32:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6053A832E for ; Mon, 22 Feb 2010 11:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SJ4OeSGAcF0b for ; Mon, 22 Feb 2010 11:32:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E0CE53A832F for ; Mon, 22 Feb 2010 11:32:56 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL1qgktAZnwN/2dsb2JhbACbA3OlZpgKgkqCIQSDFQ X-IronPort-AV: E=Sophos;i="4.49,520,1262563200"; d="scan'208";a="154997015" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2010 19:34:56 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1MJYt8C005467; Mon, 22 Feb 2010 19:34:55 GMT Message-ID: <4B82DC63.5060203@cisco.com> Date: Mon, 22 Feb 2010 14:34:59 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> <4B82D806.1020103@ericsson.com> <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> In-Reply-To: <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dale Worley , "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:32:58 -0000 Hans Erik van Elburg wrote: > The sentence "The target of the OPTIONS request is identified by the > Request-URI, which could identify another UA or a SIP server." does not > imply that you can only adress AOR's. > > If a Request-URI happen to contain a proxy servers address, then the > request will be targeted at the proxy server and not at a UA. If it > contains an AOR then it is adressed at whatever entities the location > server lookup function resolves to (this may even be recursive). When a request is addressed to sip:alice@atlanta.org, it eventually lands on a server that is responsible for atlanta.org. Where it goes from there is up to that server. Often its a proxy with a registrar, and it forks based on registered contacts. But that is certainly not required behavior, and often its more subtle than that. (Look at IMS.) For instance, its pretty common for the proxy to note that the request is a SUBSCRIBE, and then at the event package name, and select a particular server to route to. It can of course also to decide to route certain requests to "itself" as a UA for processing it provides. When it gets OPTIONS, it could have special routing rules for that. Routing the way it would an INVITE is at best an INVITE-centric view of the world. And even that doesn't do anything very useful if there are multiple contacts registered. Thanks, Paul > /Hans Erik van Elburg > > > On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto > > > wrote: > > not really, the problem is only with OPTIONS requests: > > The SIP method OPTIONS allows a UA to query another UA or a proxy > server as to its capabilities. > > > so when you address the request to an AoR ... there is a clear > ambiguity on what you are really requesting. > > even if "historically" the usage is that you want to query the UAs > than an INVITE sent to the AoR would reach, > > /Sal > > > On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote: >> If you would follow that logic no request would ever reach a UA. >> >> BR, >> /Hans Erik van Elburg >> >> >> On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto >> > > wrote: >> >> On 02/22/2010 07:54 PM, Paul Kyzivat wrote: >>> Dale Worley wrote: >>> >>>> On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >>>> >>>>> But, if I address the request to an AOR (which points to a domain, not >>>>> to a specific device) I might want to receive capabilities of all the >>>>> UAS associated with that AOR/domain. >>>>> >>>> There is an ambiguity regarding what UAs you want to query. Do you want >>>> to query the UAs registered to the AOR in question, or do you want to >>>> query the UAs that an INVITE sent to the AOR would reach? >>>> >>> Or do you want to query the server responsible for the AOR itself? >>> (I.e. the proxy.) >>> >> I tend to agree with Paul, >> >> RFC3261 section 11: >> >> The target of the OPTIONS request is identified by the Request-URI, >> which could identify another UA or a SIP server. >> >> >> >> moreover 3261 defines: >> >> Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI >> that points to a domain with a location service that can map >> the URI to another URI where the user might be available. >> >> >> >> so "in theory" a SIP OPTIONS request to an AoR should be >> interpreted as >> a request to a SIP Proxy/Server that is authoritative for that >> AoR, >> and then the response should be... without any body... >> >> /Sal >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > > From ietf.hanserik@gmail.com Mon Feb 22 11:36:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349E128C35C for ; Mon, 22 Feb 2010 11:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tMQydXD98g9Y for ; Mon, 22 Feb 2010 11:36:08 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id AA02B28C353 for ; Mon, 22 Feb 2010 11:36:07 -0800 (PST) Received: by ewy28 with SMTP id 28so3141312ewy.28 for ; Mon, 22 Feb 2010 11:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VNosumkDNANNstdq853Tz9KxF5k2Os0BpxFLM3uRfC0=; b=rIpQKh1tecuEdGVH3B41l7Ezq5SrHVRrcpS/9RNv2MxUcfxmsz81TzwlNFYj/12y4u hWbwJcR0vhwpP2eN/Ch7Oyk5Z6GAb4lhHedUiMSrvnGYiVsnrPOeICWLlmbvO3Wz4ds/ Co+x+7r9WIOpO4/X37ZTmskte8fmywaJ5+VF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PpCy0to2Up2eA3BfSG0LRe44rBql7lVQ5VUqy6LjbOA+mDSi/hFXTd2Dr/1iRkDN5o SzN4FVDyCPemVWdKwP2ZjKT7+OTCmJMLNuNI69X89HDCjiOJZBYmepEOkymObMwT/HD6 rhAPXIo6Dt4Fm6NoTJ3/Phmqh7ehUjDXG3kU4= MIME-Version: 1.0 Received: by 10.213.97.35 with SMTP id j35mr6355200ebn.4.1266867483708; Mon, 22 Feb 2010 11:38:03 -0800 (PST) In-Reply-To: <4B82DC63.5060203@cisco.com> References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <9ae56b1e1002221103w78676363v67e4cfaa1077cd52@mail.gmail.com> <4B82D806.1020103@ericsson.com> <9ae56b1e1002221123g12f46e04v810e71ca35e5d5fa@mail.gmail.com> <4B82DC63.5060203@cisco.com> Date: Mon, 22 Feb 2010 20:38:03 +0100 Message-ID: <9ae56b1e1002221138r50ecc090of993f437da9fa9d4@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001636c5a83b580e03048035921c Cc: Dale Worley , "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:36:10 -0000 --001636c5a83b580e03048035921c Content-Type: text/plain; charset=ISO-8859-1 I think that you are saying here that the location server lookup function may have other ways of determining the next target then based on registration alone. but it is not contradicting. /Hans Erik van Elburg On Mon, Feb 22, 2010 at 8:34 PM, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: > >> The sentence "The target of the OPTIONS request is identified by the >> Request-URI, which could identify another UA or a SIP server." does not >> imply that you can only adress AOR's. >> >> If a Request-URI happen to contain a proxy servers address, then the >> request will be targeted at the proxy server and not at a UA. If it contains >> an AOR then it is adressed at whatever entities the location server lookup >> function resolves to (this may even be recursive). >> > > When a request is addressed to sip:alice@atlanta.org, > it eventually lands on a server that is responsible for atlanta.org. Where > it goes from there is up to that server. Often its a proxy with a registrar, > and it forks based on registered contacts. But that is certainly not > required behavior, and often its more subtle than that. (Look at IMS.) > > For instance, its pretty common for the proxy to note that the request is a > SUBSCRIBE, and then at the event package name, and select a particular > server to route to. It can of course also to decide to route certain > requests to "itself" as a UA for processing it provides. > > When it gets OPTIONS, it could have special routing rules for that. Routing > the way it would an INVITE is at best an INVITE-centric view of the world. > And even that doesn't do anything very useful if there are multiple contacts > registered. > > Thanks, > Paul > > /Hans Erik van Elburg >> >> >> >> On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto < >> salvatore.loreto@ericsson.com > >> wrote: >> >> not really, the problem is only with OPTIONS requests: >> >> The SIP method OPTIONS allows a UA to query another UA or a proxy >> server as to its capabilities. >> >> so when you address the request to an AoR ... there is a clear >> ambiguity on what you are really requesting. >> >> even if "historically" the usage is that you want to query the UAs >> than an INVITE sent to the AoR would reach, >> >> /Sal >> >> >> On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote: >> >>> If you would follow that logic no request would ever reach a UA. >>> >>> BR, >>> /Hans Erik van Elburg >>> >>> >>> On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto >>> >> > wrote: >>> >>> On 02/22/2010 07:54 PM, Paul Kyzivat wrote: >>> >>>> Dale Worley wrote: >>>> >>>> >>>>> On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: >>>>> >>>>> >>>>>> But, if I address the request to an AOR (which points to a >>>>>> domain, not >>>>>> to a specific device) I might want to receive capabilities of >>>>>> all the >>>>>> UAS associated with that AOR/domain. >>>>>> >>>>> There is an ambiguity regarding what UAs you want to query. Do >>>>> you want >>>>> to query the UAs registered to the AOR in question, or do you >>>>> want to >>>>> query the UAs that an INVITE sent to the AOR would reach? >>>>> >>>>> >>>> Or do you want to query the server responsible for the AOR >>>> itself? >>>> (I.e. the proxy.) >>>> >>>> >>> I tend to agree with Paul, >>> >>> RFC3261 section 11: >>> >>> The target of the OPTIONS request is identified by the >>> Request-URI, >>> which could identify another UA or a SIP server. >>> >>> >>> moreover 3261 defines: >>> >>> Address-of-Record: An address-of-record (AOR) is a SIP or SIPS >>> URI >>> that points to a domain with a location service that can map >>> the URI to another URI where the user might be available. >>> >>> >>> so "in theory" a SIP OPTIONS request to an AoR should be >>> interpreted as >>> a request to a SIP Proxy/Server that is authoritative for that >>> AoR, >>> and then the response should be... without any body... >>> >>> /Sal >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >> >> --001636c5a83b580e03048035921c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that you are saying here that the location server lookup function m= ay have other ways of determining the next target then based on registratio= n alone. but it is not contradicting.

/Hans Erik van E= lburg


On Mon, Feb 22, 2010 at 8:34 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:


Hans Erik van Elburg wrote:
The sentence "The target of the OPTIONS request is identified by the R= equest-URI, which could identify another UA or a SIP server." does not= imply that you can only adress AOR's.

If a Request-URI happen to contain a proxy servers address, then the reques= t will be targeted at the proxy server and not at a UA. If it contains an A= OR then it is adressed at whatever entities the location server lookup func= tion resolves to (this may even be recursive).

When a request is addressed to sip:alice@atlanta.org, it eventually lands on a server= that is responsible for a= tlanta.org. Where it goes from there is up to that server. Often its a = proxy with a registrar, and it forks based on registered contacts. But that= is certainly not required behavior, and often its more subtle than that. (= Look at IMS.)

For instance, its pretty common for the proxy to note that the request is a= SUBSCRIBE, and then at the event package name, and select a particular ser= ver to route to. It can of course also to decide to route certain requests = to "itself" as a UA for processing it provides.

When it gets OPTIONS, it could have special routing rules for that. Routing= the way it would an INVITE is at best an INVITE-centric view of the world.= And even that doesn't do anything very useful if there are multiple co= ntacts registered.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

/Hans Erik van Elburg



On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto <salvatore.loreto@ericsson.com= <mailto:salvatore.loreto@ericsson.com>> wrote:

=A0 =A0not really, the problem is only with OPTIONS requests:

=A0 =A0 =A0 The SIP method OPTIONS allows a UA to query another UA or a pr= oxy
=A0 =A0 =A0 server as to its capabilities.

=A0 =A0so when you address the request to an AoR ... there is a clear
=A0 =A0ambiguity on what you are really requesting.

=A0 =A0even if "historically" the usage is that you want to quer= y the UAs
=A0 =A0than an INVITE sent to the AoR would reach,

=A0 =A0/Sal


=A0 =A0On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote:
=A0 =A0If you would follow that logic no request would ever reach a UA.
=A0 =A0BR,
=A0 =A0/Hans Erik van Elburg


=A0 =A0On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto
=A0 =A0<salvatore.loreto@ericsson.com
=A0 =A0<mailto:salvatore.loreto@ericsson.com>> wrote:

=A0 =A0 =A0 =A0On 02/22/2010 07:54 PM, Paul Kyzivat wrote:
=A0 =A0 =A0 =A0Dale Worley wrote:
=A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:=
=A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0But, if I address the request to an AOR (which points to a = domain, not
=A0 =A0 =A0 =A0to a specific device) I might want to receive capabilities = of all the
=A0 =A0 =A0 =A0UAS associated with that AOR/domain. =A0 =A0 =A0 =A0 =A0 = =A0 =A0
=A0 =A0 =A0 =A0There is an ambiguity regarding what UAs you want to query.= =A0Do you want
=A0 =A0 =A0 =A0to query the UAs registered to the AOR in question, or do y= ou want to
=A0 =A0 =A0 =A0query the UAs that an INVITE sent to the AOR would reach? =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0Or do you want to query the server responsible for the AOR = itself?
=A0 =A0 =A0 =A0(I.e. the proxy.)
=A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0I tend to agree with Paul,

=A0 =A0 =A0 =A0RFC3261 section 11:

=A0 =A0 =A0 =A0 =A0 The target of the OPTIONS request is identified by the= Request-URI,
=A0 =A0 =A0 =A0 =A0 which could identify another UA or a SIP server.

=A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0moreover 3261 defines:

=A0 =A0 =A0 =A0 =A0 =A0Address-of-Record: An address-of-record (AOR) is a = SIP or SIPS URI
=A0 =A0 =A0 =A0 =A0 =A0that points to a domain with a location service tha= t can map
=A0 =A0 =A0 =A0 =A0 =A0the URI to another URI where the user might be avai= lable.


=A0 =A0 =A0 =A0so "in theory" a SIP OPTIONS request to an AoR sh= ould be
=A0 =A0 =A0 =A0interpreted as
=A0 =A0 =A0 =A0a request to a SIP Proxy/Server that is authoritative for t= hat
=A0 =A0 =A0 =A0AoR,
=A0 =A0 =A0 =A0and then the response should be... without any body...

=A0 =A0 =A0 =A0/Sal

=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0sipco= re@ietf.org <mailto:sipcore@ietf.org>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore





--001636c5a83b580e03048035921c-- From christer.holmberg@ericsson.com Mon Feb 22 11:36:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4E83A832F for ; Mon, 22 Feb 2010 11:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, 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 8bFsblp77Tao for ; Mon, 22 Feb 2010 11:36:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5C64D3A8213 for ; Mon, 22 Feb 2010 11:36:19 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-5f-4b82dd29722b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 54.22.02429.92DD28B4; Mon, 22 Feb 2010 20:38:17 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 22 Feb 2010 20:38:17 +0100 From: Christer Holmberg To: Salvatore Loreto , "sipcore@ietf.org" , Paul Kyzivat , Dale Worley Date: Mon, 22 Feb 2010 20:38:16 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz8N8ZSxcUhSMfTP+Qp7WK+PDPLAABL7Rg Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> In-Reply-To: <4B82D38B.1090601@ericsson.com> 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_FF84A09F50A6DC48ACB6714F4666CC744E1A845FFBESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:36:20 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC744E1A845FFBESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I don't think I am "disagreeing" with Paul. Also, if the response from the server will contain only a limited set of UA= S information we may not need a body. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Salvatore Loreto Sent: 22. helmikuuta 2010 20:57 To: sipcore@ietf.org; Paul Kyzivat; Dale Worley Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? On 02/22/2010 07:54 PM, Paul Kyzivat wrote: Dale Worley wrote: On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: But, if I address the request to an AOR (which points to a domain, not to a specific device) I might want to receive capabilities of all the UAS associated with that AOR/domain. There is an ambiguity regarding what UAs you want to query. Do you want to query the UAs registered to the AOR in question, or do you want to query the UAs that an INVITE sent to the AOR would reach? Or do you want to query the server responsible for the AOR itself? (I.e. the proxy.) I tend to agree with Paul, RFC3261 section 11: The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. moreover 3261 defines: Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. so "in theory" a SIP OPTIONS request to an AoR should be interpreted as a request to a SIP Proxy/Server that is authoritative for that AoR, and then the response should be... without any body... /Sal --_000_FF84A09F50A6DC48ACB6714F4666CC744E1A845FFBESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I don't think I am "disagreeing" with=20 Paul.
 
Also, if the response from the server will contain= only a=20 limited set of UAS information we may not need a body.
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Salvatore=20 Loreto
Sent: 22. helmikuuta 2010 20:57
To: sipcore@ietf= .org;=20 Paul Kyzivat; Dale Worley
Subject: Re: [sipcore] OPTIONS: How to = solve=20 the forking problem?

On 02/22/2010 07:54 PM, Paul Kyzivat wrote:=20 
Dale Worley wrote:
  
On Fri, 2010-02-19 at 12:28 +010=
0, Christer Holmberg wrote:
    
But, if I address the request =
to an AOR (which points to a domain, not
to a specific device) I might want to receive capabilities of all the
UAS associated with that AOR/domain.=20
      
There is an ambiguity regarding wha=
t UAs you want to query.  Do you want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?
    
Or do you want to query the server re=
sponsible for the AOR itself?
(I.e. the proxy.)
I tend to agree with Paul,

RFC3261 section=20 11:

   The target of the OPTIONS request is identified by the R=
equest-URI,
   which could identify another UA or a SIP server.
moreover 3261 defines:
Address-of-Record: An address-of-record (AOR) is a SIP or =
SIPS URI
that points to a domain with a location service that can map
the URI to another URI where the user might be available.


so=20 "in theory" a SIP OPTIONS request to an AoR should be interpreted as
a= =20 request to a SIP Proxy/Server that is authoritative for that AoR,
and th= en=20 the response should be... without any body...

/Sal
--_000_FF84A09F50A6DC48ACB6714F4666CC744E1A845FFBESESSCMS0354e_-- From alan.b.johnston@gmail.com Mon Feb 22 12:15:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD4B28C243 for ; Mon, 22 Feb 2010 12:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 KJiafTxDsi6x for ; Mon, 22 Feb 2010 12:15:18 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id BCA7128C39B for ; Mon, 22 Feb 2010 12:15:14 -0800 (PST) Received: by pzk33 with SMTP id 33so275086pzk.5 for ; Mon, 22 Feb 2010 12:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=azacaRwpCF5oPK7x4VEVRTQhhS+FqNdLhhEMcifmthc=; b=oJywQ1K8Zxbtq6JM5H1+bBWTfqCamABSxymrugEt3lq9DLO9N6nyD0C94LoiI86vvN PO3Lx2Kp4MWFAF+pW3vEjWQ/s+PgDd+EhLaheLwnYzbnKbPQ/OS53CKX8C2FBKhyY1Au vLUfWW+Z/tE1b9pC4Lv26XUnCWwQJfovAKKZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QEL35fEXtvBc1RDRqlNChIBVgw2ZX9alajpp3n6ZeGJ8W2yNZ+cOnDwKKhYCNlmw2v y+tOGPJYgEqKh6qhdX8wQ3pIaHHUn0Ej5AXcLZD8RSnJAEAOefpw6RPkpn1KYdXmfEDB IxdX4mABuNb6g11B0ueVs/GT0ZyhRmYWe5iN8= Received: by 10.141.23.16 with SMTP id a16mr1381250rvj.290.1266869827607; Mon, 22 Feb 2010 12:17:07 -0800 (PST) Received: from null-001124a33aad.wufi.wustl.edu (pat2.wufi.wustl.edu [128.252.78.82]) by mx.google.com with ESMTPS id 11sm586100pwi.10.2010.02.22.12.17.04 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 12:17:06 -0800 (PST) Message-ID: <4B82E63D.6020603@gmail.com> Date: Mon, 22 Feb 2010 14:17:01 -0600 From: Alan Johnston User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 20:15:19 -0000 Christer, See below. - Alan - On 2/22/10 1:38 PM, Christer Holmberg wrote: > Hi, > > I don't think I am "disagreeing" with Paul. > > Also, if the response from the server will contain only a limited set of UAS information we may not need a body. > > Regards, > > Christer > > ________________________________ > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: 22. helmikuuta 2010 20:57 > To: sipcore@ietf.org; Paul Kyzivat; Dale Worley > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? > > On 02/22/2010 07:54 PM, Paul Kyzivat wrote: > > > Dale Worley wrote: > > > On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote: > > > But, if I address the request to an AOR (which points to a domain, not > to a specific device) I might want to receive capabilities of all the > UAS associated with that AOR/domain. > > > There is an ambiguity regarding what UAs you want to query. Do you want > to query the UAs registered to the AOR in question, or do you want to > query the UAs that an INVITE sent to the AOR would reach? > > > Or do you want to query the server responsible for the AOR itself? > (I.e. the proxy.) > > > I tend to agree with Paul, > > RFC3261 section 11: > > > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. > > > > moreover 3261 defines: > > Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > > > so "in theory" a SIP OPTIONS request to an AoR should be interpreted as > a request to a SIP Proxy/Server that is authoritative for that AoR, > and then the response should be... without any body... I can tell you this was not the intent of this text. It is correct that a proxy authoritative for a domain can apply any policy to any request directed at an AoR in that domain. However, for a proxy to answer an OPTIONS on behalf of a user/UA would be very surprising to me, and I don't think RFC 3261 implies this. > > /Sal > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Feb 22 17:05:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5A228C20F for ; Mon, 22 Feb 2010 17:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 Qp3g9VgYczCO for ; Mon, 22 Feb 2010 17:05:36 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 36CCB28C4B6 for ; Mon, 22 Feb 2010 17:05:36 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c9-4b832a56ffae Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BE.73.31641.65A238B4; Tue, 23 Feb 2010 02:07:34 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Feb 2010 02:07:34 +0100 From: Christer Holmberg To: 'Alan Johnston' , "sipcore@ietf.org" Date: Tue, 23 Feb 2010 02:07:34 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz/A31Nr/Gr1qaSJGCqk/58gQvswAJsHzg Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> In-Reply-To: <4B82E63D.6020603@gmail.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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 01:05:37 -0000 Hi Alan,=20 >I can tell you this was not the intent of this text. It is correct that a= proxy=20 >authoritative for a domain can apply any policy to any request directed at= an AoR in that=20 >domain. However, for a proxy to answer an OPTIONS on behalf of a user/UA = would be very=20 >surprising to me, and I don't think RFC 3261 implies this. I agree that the RFC does not talk about answering on behalf of UAs.=20 The question is whether we COULD allow the proxy to answer on behalf of the= UASs. I don't it breaks anything. We do need to take message size into con= sideration, and for that reason one idea is that the reponse from the proxy= would contain very limited set of UAS information (in order to get the ful= l set of information (SDP etc) the UAC will have to send an OPTIONS address= ed to a specific UAS). Regards, Christer From ietf.hanserik@gmail.com Tue Feb 23 00:55:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA37A28C550 for ; Tue, 23 Feb 2010 00:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fLMY3vhTPTQG for ; Tue, 23 Feb 2010 00:55:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id AA58F28C117 for ; Tue, 23 Feb 2010 00:55:07 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so846987eyd.51 for ; Tue, 23 Feb 2010 00:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eJ3i8jNJ865NwtkG+A4MbY4e6UkFm/QAkmqONpRjUDY=; b=n//K8MnalXv5Ei2lSV+B9wiwJ5n2jmYMHTCPz4AL/mk5bXP6Osh9aKdEDCS0LHxaYu eQxInUmFkGVW5/FXwSoP3aKKQF/bswsrdM/eojdDCgtYdVO6KFf34IaGkIHRtu6G+GuA wPcth6hdAjA1Y6ar0X2J4ldWMDMcxnEqOebcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yu8CkqXxrXIPgqI7rQkpCOpGxBl1XmA5ZscPq/Je3gCf5G7Iv5FSmLl50nfW8ClPuc i+EU77DUa1nZONGP5PXScgtuHJHXVHKElGH5EUIOkU9ptI2bhmjNSV2741pawxgqhh9A 0lPA6oDMsOE3gbivRtcjQivUTKhXCEG32H8Sc= MIME-Version: 1.0 Received: by 10.213.100.139 with SMTP id y11mr435500ebn.50.1266915426033; Tue, 23 Feb 2010 00:57:06 -0800 (PST) In-Reply-To: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> Date: Tue, 23 Feb 2010 09:57:05 +0100 Message-ID: <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> From: Hans Erik van Elburg To: Christer Holmberg Content-Type: multipart/alternative; boundary=001636c5a67eede28a048040bb36 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:55:09 -0000 --001636c5a67eede28a048040bb36 Content-Type: text/plain; charset=ISO-8859-1 Agreed. Of course a proxy equiped with such policy can do that. It is kind of a domain specific service. For that you do not have to bend the interpretation of the original RFC3261 text. If you use the 302 approach proposed by Dean, then do you need to do anything specification wise? /Hans Erik van Elburg On Tue, Feb 23, 2010 at 2:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Alan, > > >I can tell you this was not the intent of this text. It is correct that a > proxy > >authoritative for a domain can apply any policy to any request directed at > an AoR in that > >domain. However, for a proxy to answer an OPTIONS on behalf of a user/UA > would be very > >surprising to me, and I don't think RFC 3261 implies this. > > I agree that the RFC does not talk about answering on behalf of UAs. > > The question is whether we COULD allow the proxy to answer on behalf of the > UASs. I don't it breaks anything. We do need to take message size into > consideration, and for that reason one idea is that the reponse from the > proxy would contain very limited set of UAS information (in order to get the > full set of information (SDP etc) the UAC will have to send an OPTIONS > addressed to a specific UAS). > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001636c5a67eede28a048040bb36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed. Of course a proxy equiped with such policy can do that. It is kind = of a domain specific service.
For that you do not have to bend the inter= pretation of the original RFC3261 text.

If you use the 302 approach = proposed by Dean, then do you need to do anything specification wise?

/Hans Erik van Elburg


On Tue, Feb 23, 2010 at 2:07 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Alan,

>I can tell you this was not the intent of this text. =A0It is correct t= hat a proxy
>authoritative for a domain can apply any policy to any request directed= at an AoR in that
>domain. =A0However, for a proxy to answer an OPTIONS on behalf of a use= r/UA would be very
>surprising to me, and I don't think RFC 3261 implies this.

I agree that the RFC does not talk about answering on behalf of UAs.<= br>
The question is whether we COULD allow the proxy to answer on behalf of the= UASs. I don't it breaks anything. We do need to take message size into= consideration, and for that reason one idea is that the reponse from the p= roxy would contain very limited set of UAS information (in order to get the= full set of information (SDP etc) the UAC will have to send an OPTIONS add= ressed to a specific UAS).

Regards,

Christer

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001636c5a67eede28a048040bb36-- From pkyzivat@cisco.com Tue Feb 23 06:25:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A857B28C1B7 for ; Tue, 23 Feb 2010 06:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 h0ZimK1jEdd3 for ; Tue, 23 Feb 2010 06:24:59 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 02AC528C1CC for ; Tue, 23 Feb 2010 06:24:58 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL90g0tAZnwM/2dsb2JhbACbC3OkNphQhGwEgxU X-IronPort-AV: E=Sophos;i="4.49,526,1262563200"; d="scan'208";a="88222713" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 14:27:01 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1NER1Cj008293; Tue, 23 Feb 2010 14:27:01 GMT Message-ID: <4B83E5B5.1000504@cisco.com> Date: Tue, 23 Feb 2010 09:27:01 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> In-Reply-To: <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 14:25:04 -0000 Hans Erik van Elburg wrote: > Agreed. Of course a proxy equiped with such policy can do that. It is > kind of a domain specific service. > For that you do not have to bend the interpretation of the original > RFC3261 text. > > If you use the 302 approach proposed by Dean, then do you need to do > anything specification wise? No. Its entirely above board. Having the proxy respond on behalf of the endpoints may or may not be entirely conforming, depending on how it responds. E.g. if it attempts to include a multipart with multiple SDP bodies then it may be technically conforming, but will confuse most UACs. Thanks, Paul > /Hans Erik van Elburg > > > On Tue, Feb 23, 2010 at 2:07 AM, Christer Holmberg > > > wrote: > > > Hi Alan, > > >I can tell you this was not the intent of this text. It is > correct that a proxy > >authoritative for a domain can apply any policy to any request > directed at an AoR in that > >domain. However, for a proxy to answer an OPTIONS on behalf of a > user/UA would be very > >surprising to me, and I don't think RFC 3261 implies this. > > I agree that the RFC does not talk about answering on behalf of UAs. > > The question is whether we COULD allow the proxy to answer on behalf > of the UASs. I don't it breaks anything. We do need to take message > size into consideration, and for that reason one idea is that the > reponse from the proxy would contain very limited set of UAS > information (in order to get the full set of information (SDP etc) > the UAC will have to send an OPTIONS addressed to a specific UAS). > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Tue Feb 23 08:00:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9918028C2F8 for ; Tue, 23 Feb 2010 08:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ofr-kMS6zjV4 for ; Tue, 23 Feb 2010 08:00:42 -0800 (PST) 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 00FC628C2EE for ; Tue, 23 Feb 2010 08:00:37 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1NG0q6x036241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 10:00:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B83FBB4.40208@nostrum.com> Date: Tue, 23 Feb 2010 10:00:52 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> In-Reply-To: <4B83E5B5.1000504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:00:51 -0000 On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: >> Agreed. Of course a proxy equiped with such policy can do that. It is >> kind of a domain specific service. >> For that you do not have to bend the interpretation of the original >> RFC3261 text. >> >> If you use the 302 approach proposed by Dean, then do you need to do >> anything specification wise? > > No. Its entirely above board. > > Having the proxy respond on behalf of the endpoints may or may not be > entirely conforming, depending on how it responds. That's not how I read Dean's proposal. The "Proxy/Registrar" isn't responding on behalf of the UAs. It's letting the UAC know where to find all the registered UAs. What I see Dean proposing is something like this: Dean Registrar Adam 1 Adam 2 Adam 3 | | | | | |OPTIONS | | | | |-------->| | | | | | | | | |302 | | | | |Contact: sip:adam1.example.com | |Contact: sip:adam2.example.com | |Contact: sip:adam3.example.com | |<--------| | | | | | | | | |OPTIONS | | | | |------------------>| | | |200 | | | | |<------------------| | | | | | | | |OPTIONS | | | | |---------------------------->| | |200 | | | | |<----------------------------| | | | | | | |OPTIONS | | | | |-------------------------------------->| |200 | | | | |<--------------------------------------| Perfectly above board, normal handling. Keep in mind that the Registrar can stay in the path by returning GRUUs instead of contacts that go directly to the UAs. It all works just fine either way. /a From adam@nostrum.com Tue Feb 23 08:04:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3203A7EA2 for ; Tue, 23 Feb 2010 08:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KRSNN3A2c38T for ; Tue, 23 Feb 2010 08:04:44 -0800 (PST) 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 7478B3A84A5 for ; Tue, 23 Feb 2010 08:04:43 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1NG6hQH036647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 10:06:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B83FD13.7060708@nostrum.com> Date: Tue, 23 Feb 2010 10:06:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> In-Reply-To: <4B83FBB4.40208@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:04:46 -0000 On 2/23/10 10:00, Feb 23, Adam Roach wrote: > On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >> >> >> Hans Erik van Elburg wrote: >>> Agreed. Of course a proxy equiped with such policy can do that. It >>> is kind of a domain specific service. >>> For that you do not have to bend the interpretation of the original >>> RFC3261 text. >>> >>> If you use the 302 approach proposed by Dean, then do you need to do >>> anything specification wise? >> >> No. Its entirely above board. >> >> Having the proxy respond on behalf of the endpoints may or may not be >> entirely conforming, depending on how it responds. > > That's not how I read Dean's proposal. The "Proxy/Registrar" isn't > responding on behalf of the UAs. It's letting the UAC know where to > find all the registered UAs. Whoops, sorry. I got the threads crossed. /a From pkyzivat@cisco.com Tue Feb 23 08:09:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FE028C2EF for ; Tue, 23 Feb 2010 08:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 NJ2MIZwPapZg for ; Tue, 23 Feb 2010 08:09:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 19B4128C1D8 for ; Tue, 23 Feb 2010 08:09:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFuNg0tAZnwN/2dsb2JhbACbC3OlCZhdhGwEgxU X-IronPort-AV: E=Sophos;i="4.49,526,1262563200"; d="scan'208";a="88276109" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2010 16:11:20 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1NGBK8s020218; Tue, 23 Feb 2010 16:11:20 GMT Message-ID: <4B83FE28.2010503@cisco.com> Date: Tue, 23 Feb 2010 11:11:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> In-Reply-To: <4B83FBB4.40208@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:09:19 -0000 Adam, Maybe the thread has branched too much to follow. I was contrasting two things, one by Dean and the other by Christer. I agree with you re Dean's. The alternative proposal was for the "proxy" to answer on behalf of the registered endpoints, with an aggregate response. Exactly what that aggregate response would look like is not clear. At one point I had suggested that the "proxy" could send its own OPTIONS requests to the endpoints. If so, and if their responses contained SDP, then an aggregate response might require a multipart. The Dean suggestion is by far the better one. Thanks, Paul Adam Roach wrote: > On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >> >> >> Hans Erik van Elburg wrote: >>> Agreed. Of course a proxy equiped with such policy can do that. It is >>> kind of a domain specific service. >>> For that you do not have to bend the interpretation of the original >>> RFC3261 text. >>> >>> If you use the 302 approach proposed by Dean, then do you need to do >>> anything specification wise? >> >> No. Its entirely above board. >> >> Having the proxy respond on behalf of the endpoints may or may not be >> entirely conforming, depending on how it responds. > > That's not how I read Dean's proposal. The "Proxy/Registrar" isn't > responding on behalf of the UAs. It's letting the UAC know where to find > all the registered UAs. > > What I see Dean proposing is something like this: > > Dean Registrar Adam 1 Adam 2 Adam 3 > | | | | | > |OPTIONS | | | | > |-------->| | | | > | | | | | > |302 | | | | > |Contact: sip:adam1.example.com | > |Contact: sip:adam2.example.com | > |Contact: sip:adam3.example.com | > |<--------| | | | > | | | | | > |OPTIONS | | | | > |------------------>| | | > |200 | | | | > |<------------------| | | > | | | | | > |OPTIONS | | | | > |---------------------------->| | > |200 | | | | > |<----------------------------| | > | | | | | > |OPTIONS | | | | > |-------------------------------------->| > |200 | | | | > |<--------------------------------------| > > Perfectly above board, normal handling. Keep in mind that the Registrar > can stay in the path by returning GRUUs instead of contacts that go > directly to the UAs. It all works just fine either way. > > /a > From adam@nostrum.com Tue Feb 23 19:44:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CFC28C1D6 for ; Tue, 23 Feb 2010 19:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ptrPM+YUN2rd for ; Tue, 23 Feb 2010 19:44:52 -0800 (PST) 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 16D0A28C16F for ; Tue, 23 Feb 2010 19:44:50 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1O3kn72088966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 21:46:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B84A129.2010705@nostrum.com> Date: Tue, 23 Feb 2010 21:46:49 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> In-Reply-To: <4B8284CC.8050800@cisco.com> Content-Type: multipart/alternative; boundary="------------050705000700060001060104" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:44:55 -0000 This is a multi-part message in MIME format. --------------050705000700060001060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as a participant] On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote: > > > Dean Willis wrote: > >>> We had this discussion a while ago, and it may be good to start it >>> again. I think at least Dean mentioned abandoning Table 2. I talked >>> about having a website instead, which would be easier to keep up to >>> date, but I think the IETF proceures didn't allow that. >> >> Right. for things that one might use a website for, we have IANA >> registries. >> >> One could replace Table 2 with a registry, and have new RFCs update >> that registry. > > I support this approach. Okay. If we go down this path -- and I think it's a little bit crazy -- then we'll need to ferret out the correct values for the current header fields and methods to set up the initial registry. Because of the haphazard way we've handled this, the table contains substantial gaps. I wrote a script to parse out all the formal Table 2 expansions from the RFCs that define SIP header fields and SIP methods, and merge them into a single view of what has been defined to date. With the caveat that this is a lot of data, and something might have been missed, here's what it looks like: Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF REG SUB UPD Accept 2xx - - - ? o - - m* - - - o - o Accept 415 - c - ? c m* o c c m* c c o c Accept R - o - o o - o m* o o o o o o Accept-Contact R ar o o o o o o o o o ? o - o o Accept-Encoding 2xx - - - ? o - - m* - - - o - o Accept-Encoding 415 - c - ? c m* o c c m* c c o c Accept-Encoding R - o - o o - o o o o o o o o Accept-Language 2xx - - - ? o - - m* - - - o - o Accept-Language 415 - c - ? c m* o c c m* c c o c Accept-Language R - o - o o - o o o o o o o o Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o Alert-Info 180 - - - ? o - - - - ? ? - - ? Alert-Info R - - - ? o - - - - - - - - - Alert-Info r ? ? ? ? ? ? ? ? ? - - ? ? - Allow 2xx - o - ? m* o o m* o ? ? o o o Allow 405 - m - o m m m m m m m m m m Allow R - o - ? o o o o o o ? o o o Allow r - o - ? o o o o o o ? o o o Allow-Events 2xx - o - ? o ? o o o ? ? o o ? Allow-Events 489 - - - ? - ? m - - m ? - m ? Allow-Events R o o - ? o ? o o o o ? o o - Allow-Events r ? ? ? ? ? ? ? ? ? ? ? ? ? - Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Authentication-Info 2xx - o - ? o o o o o o o o o o Authorization R o o o o o o o o o o o o o o Call-ID c r m m m m m m m m m m m m m m Call-Info R ar - - - ? o o ? o - o - o ? o Call-Info r ar - - - ? o o ? o - o - o ? o Contact 1xx - - - - o - o - - - - - o o Contact 2xx - - - - m - o o - - m o m m Contact 3xx - o - - o o m o o o ? o m o Contact 485 - o - - o o o o o o ? o o o Contact R o - - o m - m o - - m o m m Content-Disposition R o o - ? o o o o o o o o o o Content-Disposition r o o - ? o o o o o o o o o o Content-Encoding R o o - o o o o o o o o o o o Content-Encoding r o o - o o o o o o o o o o o Content-Language R o o - ? o o o o o o o o o o Content-Language r o o - ? o o o o o o o o o o Content-Length R ar t t t o t t t t t t o t t t Content-Length r ar t t t o t t t t t t o t t t Content-Type R * * - * * * * * * * * * * * Content-Type r * * - * * * * * * * * * * * CSeq c r m m m m m m m m m m m m m m Date R a o o o o o o o o o o o o o o Date r a o o o o o o o o o o o o o o Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Error-Info 300-699 a - o o ? o o o o o o ? o o o Event R - - - ? - ? m - - m ? - m - Event r ? ? ? ? ? ? ? ? ? ? ? ? ? - Expires R - - - o o o - - - o o o o - Expires r - - - o o o - - - o ? o o - Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >From c r m m m m m m m m m m m m m m History-Info R amdr - - - - o o o o - o o o o - History-Info r amdr - - - - o o o o - o o o o - Identity R a o o - ? o ? ? o ? ? ? o ? ? Identity-Info R a o o - ? o ? ? o ? ? ? o ? ? In-Reply-To R - - - ? o o - - - - - - - - In-Reply-To r ? ? ? ? ? ? ? ? ? ? - ? ? - Join R - - - - o - - - - - - - - - Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Max-Forwards R amr m m m o m m m m m m m m m m MIME-Version R o o - ? o ? o o o o o o o o MIME-Version r o o - ? o ? o o o o o o o o Min-Expires 423 - - - ? - ? - - - m ? m m ? Min-Expires R ? ? ? ? ? ? ? ? ? ? - ? ? - Min-Expires r ? ? ? ? ? ? ? ? ? ? - ? ? - Min-SE 422 - - - ? m ? - - - ? ? - - m Min-SE R amr - - - ? o ? - - - ? ? - - o Organization R ar - - - o o o - o - o o o o o Organization r ar - - - o o o - o - o o o o o P-Access-Network-Info R dr - o - o o o o o o ? o o o o P-Access-Network-Info r dr - o - o o o o o o ? o o o o P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ? P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ? P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ? P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ? P-Associated-URI 2xx - - - ? - ? ? - ? ? ? o ? ? P-Called-Party-ID R amr - - - - o o - o - ? o - o - P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Charging-Vector R admr - o - o o o o o o ? o o o o P-Charging-Vector r admr - o - o o o o o o ? o o o o P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ? P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ? P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ? P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ? P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ? P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ? P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ? P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ? P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? - P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ? P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o P-Media-Authorization R ad o - - - o ? - - o ? ? - - o P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ? P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ? P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Visited-Network-ID R ad - - - - o o - o - ? o o o - Path 2xx - - - - ? - ? ? - ? ? ? o ? ? Path R ar - - - ? - ? ? - ? ? ? o ? ? Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Priority R ar - - - o o o - - - o - - o - Priority r ? ? ? ? ? ? ? ? ? ? ? ? ? - Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Privacy R amrd o o o ? o o o o ? ? ? o o o Privacy r amrd o o o ? o o o o ? ? ? o o o Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o Proxy-Authenticate 407 ar - m - o m m m m m m m m m m Proxy-Authorization R dr o o - o o o o o o o o o o o RAck R - - - ? - ? - - m ? ? - - - Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Record-Route 18x mr - o o ? o ? ? o o ? o - ? o Record-Route 2xx mr - o o o o ? o o o ? o - o o Record-Route R ar o o o o o - o o o - o - o o Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ? Refer-Sub 2xx - - - - - - - - - - o - - - Refer-Sub R - - - - - - - - - - o - - - Refer-To R - - - ? - ? ? - ? ? ? - ? ? Referred-By R - o - ? o ? ? o ? ? ? o ? ? Reject-Contact R ar o o o o o o o o o ? o - o o Replaces R - - - - o - - - - - - - - - Reply-To R - - - ? o o - - - - - - - - Reply-To r - - - ? o o - - - - - - - - Request-Disposition R ar o o o o o o o o o ? o o o o Require R ar - c - o c c o c c o c c o c Require r ar - c - ? c c o c c o c c o c Resource-Priority R amdr o o o o o o o o o o o o o o Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Retry-After 404 - o o o o ? o o o o o o o o Retry-After 413 - o o ? o ? o o o o o o o o Retry-After 480 - o o o o ? o o o o o o o o Retry-After 486 - o o o o ? o o o o o o o o Retry-After 4xx ? ? ? ? ? o ? ? ? ? ? ? ? ? Route R adr c c c o c o c c c c c c c c RSeq 1xx - - - ? o ? o - - ? ? - o ? RSeq R ? ? ? ? ? ? ? ? ? ? ? ? ? - RSeq r ? ? ? ? ? ? ? ? ? ? ? ? ? - Security-Client R ard - o - ? o o o o ? ? ? o o o Security-Server 421 - o - ? o o o o ? ? ? o o o Security-Server 494 - o - ? o o o o ? ? ? o o o Security-Verify R ard - o - ? o o o o ? ? ? o o o Server r - o o o o o o o o o o o o o Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ? Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o Session-Expires R amr - - - ? o ? - - - ? ? - - o SIP-ETag 2xx - - - - - - - - - m - - - - SIP-If-Match R - - - - - - - - - o - - - - Subject R - - - o o o - - - o - - - - Subject r ? ? ? ? ? ? ? ? ? ? ? ? ? - Subscription-State R - - - ? - ? m - - ? ? - - - Subscription-State r ? ? ? ? ? ? ? ? ? ? ? ? ? - Supported 2xx - o o ? m* ? o m* o o o o o o Supported R - o o ? m* ? o o o o o o o o Target-Dialog R - - - - - o - - - - - o - o - Timestamp R o o o o o o o o o o o o o o Timestamp r o o o o o o o o o o o o o o To c r m m m m m m m m m m m m m m Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Unsupported 420 - m - o m o o m m o o m o m User-Agent R o o o o o o o o o o o o o o User-Agent r o o o o o o o o o o o o o o Via R amr m m m ? m m ? m ? m ? m ? m Via rc dr m m m ? m m ? m ? m ? m ? m Warning r - o o o o o o o o o o o o o WWW-Authenticate 401 ar - m - o m m m m m m m m m m WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o See all those question marks? Someone needs to come up with actual values for each of those cells. Some are going to be pretty easy to answer; others will require substantial research and/or debate. It seems like a lot of effort to me. Are we certain the return on our investment of time will be worth it? /a --------------050705000700060001060104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as a participant]

On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote:


Dean Willis wrote:

We had this discussion a while ago, and it may be good to start it again. I think at least Dean mentioned abandoning Table 2. I talked about having a website instead, which would be easier to keep up to date, but I think the IETF proceures didn't allow that.

Right. for things that one might use a website for, we have IANA registries.

One could replace Table 2 with a registry, and have new RFCs update that registry.

I support this approach.

Okay. If we go down this path -- and I think it's a little bit crazy -- then we'll need to ferret out the correct values for the current header fields and methods to set up the initial registry.

Because of the haphazard way we've handled this, the table contains substantial gaps. I wrote a script to parse out all the formal Table 2 expansions from the RFCs that define SIP header fields and SIP methods, and merge them into a single view of what has been defined to date. With the caveat that this is a lot of data, and something might have been missed, here's what it looks like:

Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF REG SUB UPD
Accept 2xx
- - - ? o - - m* - - - o - o
Accept 415
- c - ? c m* o c c m* c c o c
Accept R
- o - o o - o m* o o o o o o
Accept-Contact R ar o o o o o o o o o ? o - o o
Accept-Encoding 2xx
- - - ? o - - m* - - - o - o
Accept-Encoding 415
- c - ? c m* o c c m* c c o c
Accept-Encoding R
- o - o o - o o o o o o o o
Accept-Language 2xx
- - - ? o - - m* - - - o - o
Accept-Language 415
- c - ? c m* o c c m* c c o c
Accept-Language R
- o - o o - o o o o o o o o
Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o
Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o
Alert-Info 180
- - - ? o - - - - ? ? - - ?
Alert-Info R
- - - ? o - - - - - - - - -
Alert-Info r
? ? ? ? ? ? ? ? ? - - ? ? -
Allow 2xx
- o - ? m* o o m* o ? ? o o o
Allow 405
- m - o m m m m m m m m m m
Allow R
- o - ? o o o o o o ? o o o
Allow r
- o - ? o o o o o o ? o o o
Allow-Events 2xx
- o - ? o ? o o o ? ? o o ?
Allow-Events 489
- - - ? - ? m - - m ? - m ?
Allow-Events R
o o - ? o ? o o o o ? o o -
Allow-Events r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Authentication-Info 2xx
- o - ? o o o o o o o o o o
Authorization R
o o o o o o o o o o o o o o
Call-ID c r m m m m m m m m m m m m m m
Call-Info R ar - - - ? o o ? o - o - o ? o
Call-Info r ar - - - ? o o ? o - o - o ? o
Contact 1xx
- - - - o - o - - - - - o o
Contact 2xx
- - - - m - o o - - m o m m
Contact 3xx
- o - - o o m o o o ? o m o
Contact 485
- o - - o o o o o o ? o o o
Contact R
o - - o m - m o - - m o m m
Content-Disposition R
o o - ? o o o o o o o o o o
Content-Disposition r
o o - ? o o o o o o o o o o
Content-Encoding R
o o - o o o o o o o o o o o
Content-Encoding r
o o - o o o o o o o o o o o
Content-Language R
o o - ? o o o o o o o o o o
Content-Language r
o o - ? o o o o o o o o o o
Content-Length R ar t t t o t t t t t t o t t t
Content-Length r ar t t t o t t t t t t o t t t
Content-Type R
* * - * * * * * * * * * * *
Content-Type r
* * - * * * * * * * * * * *
CSeq c r m m m m m m m m m m m m m m
Date R a o o o o o o o o o o o o o o
Date r a o o o o o o o o o o o o o o
Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Error-Info 300-699 a - o o ? o o o o o o ? o o o
Event R
- - - ? - ? m - - m ? - m -
Event r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Expires R
- - - o o o - - - o o o o -
Expires r
- - - o o o - - - o ? o o -
Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
From c r m m m m m m m m m m m m m m
History-Info R amdr - - - - o o o o - o o o o -
History-Info r amdr - - - - o o o o - o o o o -
Identity R a o o - ? o ? ? o ? ? ? o ? ?
Identity-Info R a o o - ? o ? ? o ? ? ? o ? ?
In-Reply-To R
- - - ? o o - - - - - - - -
In-Reply-To r
? ? ? ? ? ? ? ? ? ? - ? ? -
Join R
- - - - o - - - - - - - - -
Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Max-Forwards R amr m m m o m m m m m m m m m m
MIME-Version R
o o - ? o ? o o o o o o o o
MIME-Version r
o o - ? o ? o o o o o o o o
Min-Expires 423
- - - ? - ? - - - m ? m m ?
Min-Expires R
? ? ? ? ? ? ? ? ? ? - ? ? -
Min-Expires r
? ? ? ? ? ? ? ? ? ? - ? ? -
Min-SE 422
- - - ? m ? - - - ? ? - - m
Min-SE R amr - - - ? o ? - - - ? ? - - o
Organization R ar - - - o o o - o - o o o o o
Organization r ar - - - o o o - o - o o o o o
P-Access-Network-Info R dr - o - o o o o o o ? o o o o
P-Access-Network-Info r dr - o - o o o o o o ? o o o o
P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ?
P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ?
P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ?
P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ?
P-Associated-URI 2xx
- - - ? - ? ? - ? ? ? o ? ?
P-Called-Party-ID R amr - - - - o o - o - ? o - o -
P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Charging-Vector R admr - o - o o o o o o ? o o o o
P-Charging-Vector r admr - o - o o o o o o ? o o o o
P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ?
P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ?
P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ?
P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? -
P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o
P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o
P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ?
P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o
P-Media-Authorization R ad o - - - o ? - - o ? ? - - o
P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ?
P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ?
P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Visited-Network-ID R ad - - - - o o - o - ? o o o -
Path 2xx - - - - ? - ? ? - ? ? ? o ? ?
Path R ar - - - ? - ? ? - ? ? ? o ? ?
Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Priority R ar - - - o o o - - - o - - o -
Priority r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Privacy R amrd o o o ? o o o o ? ? ? o o o
Privacy r amrd o o o ? o o o o ? ? ? o o o
Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o
Proxy-Authenticate 407 ar - m - o m m m m m m m m m m
Proxy-Authorization R dr o o - o o o o o o o o o o o
RAck R
- - - ? - ? - - m ? ? - - -
Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Record-Route 18x mr - o o ? o ? ? o o ? o - ? o
Record-Route 2xx mr - o o o o ? o o o ? o - o o
Record-Route R ar o o o o o - o o o - o - o o
Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ?
Refer-Sub 2xx
- - - - - - - - - - o - - -
Refer-Sub R
- - - - - - - - - - o - - -
Refer-To R
- - - ? - ? ? - ? ? ? - ? ?
Referred-By R
- o - ? o ? ? o ? ? ? o ? ?
Reject-Contact R ar o o o o o o o o o ? o - o o
Replaces R
- - - - o - - - - - - - - -
Reply-To R
- - - ? o o - - - - - - - -
Reply-To r
- - - ? o o - - - - - - - -
Request-Disposition R ar o o o o o o o o o ? o o o o
Require R ar - c - o c c o c c o c c o c
Require r ar - c - ? c c o c c o c c o c
Resource-Priority R amdr o o o o o o o o o o o o o o
Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Retry-After 404
- o o o o ? o o o o o o o o
Retry-After 413
- o o ? o ? o o o o o o o o
Retry-After 480
- o o o o ? o o o o o o o o
Retry-After 486
- o o o o ? o o o o o o o o
Retry-After 4xx
? ? ? ? ? o ? ? ? ? ? ? ? ?
Route R adr c c c o c o c c c c c c c c
RSeq 1xx
- - - ? o ? o - - ? ? - o ?
RSeq R
? ? ? ? ? ? ? ? ? ? ? ? ? -
RSeq r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Security-Client R ard - o - ? o o o o ? ? ? o o o
Security-Server 421
- o - ? o o o o ? ? ? o o o
Security-Server 494
- o - ? o o o o ? ? ? o o o
Security-Verify R ard - o - ? o o o o ? ? ? o o o
Server r
- o o o o o o o o o o o o o
Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ?
Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o
Session-Expires R amr - - - ? o ? - - - ? ? - - o
SIP-ETag 2xx
- - - - - - - - - m - - - -
SIP-If-Match R
- - - - - - - - - o - - - -
Subject R
- - - o o o - - - o - - - -
Subject r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Subscription-State R
- - - ? - ? m - - ? ? - - -
Subscription-State r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Supported 2xx
- o o ? m* ? o m* o o o o o o
Supported R
- o o ? m* ? o o o o o o o o
Target-Dialog R - - - - - o - - - - - o - o -
Timestamp R
o o o o o o o o o o o o o o
Timestamp r
o o o o o o o o o o o o o o
To c r m m m m m m m m m m m m m m
Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Unsupported 420
- m - o m o o m m o o m o m
User-Agent R
o o o o o o o o o o o o o o
User-Agent r
o o o o o o o o o o o o o o
Via R amr m m m ? m m ? m ? m ? m ? m
Via rc dr m m m ? m m ? m ? m ? m ? m
Warning r
- o o o o o o o o o o o o o
WWW-Authenticate 401 ar - m - o m m m m m m m m m m
WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o


See all those question marks? Someone needs to come up with actual values for each of those cells. Some are going to be pretty easy to answer; others will require substantial research and/or debate.

It seems like a lot of effort to me. Are we certain the return on our investment of time will be worth it?

/a
--------------050705000700060001060104-- From adam@nostrum.com Tue Feb 23 19:46:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778E028C18E for ; Tue, 23 Feb 2010 19:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qPZ4tp7WyZTW for ; Tue, 23 Feb 2010 19:46:21 -0800 (PST) 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 CD10A28C16F for ; Tue, 23 Feb 2010 19:46:19 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1O3mHBI089076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 21:48:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B84A181.90008@nostrum.com> Date: Tue, 23 Feb 2010 21:48:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> In-Reply-To: <4B8284CC.8050800@cisco.com> Content-Type: multipart/alternative; boundary="------------000002030100010504070703" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:46:24 -0000 This is a multi-part message in MIME format. --------------000002030100010504070703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-sending with a new subject line, since this has almost nothing to do with 3265bis any longer. Sorry for the additional noise. [as a participant] On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote: > > > Dean Willis wrote: > >>> We had this discussion a while ago, and it may be good to start it >>> again. I think at least Dean mentioned abandoning Table 2. I talked >>> about having a website instead, which would be easier to keep up to >>> date, but I think the IETF proceures didn't allow that. >> >> Right. for things that one might use a website for, we have IANA >> registries. >> >> One could replace Table 2 with a registry, and have new RFCs update >> that registry. > > I support this approach. Okay. If we go down this path -- and I think it's a little bit crazy -- then we'll need to ferret out the correct values for the current header fields and methods to set up the initial registry. Because of the haphazard way we've handled this, the table contains substantial gaps. I wrote a script to parse out all the formal Table 2 expansions from the RFCs that define SIP header fields and SIP methods, and merge them into a single view of what has been defined to date. With the caveat that this is a lot of data, and something might have been missed, here's what it looks like: Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF REG SUB UPD Accept 2xx - - - ? o - - m* - - - o - o Accept 415 - c - ? c m* o c c m* c c o c Accept R - o - o o - o m* o o o o o o Accept-Contact R ar o o o o o o o o o ? o - o o Accept-Encoding 2xx - - - ? o - - m* - - - o - o Accept-Encoding 415 - c - ? c m* o c c m* c c o c Accept-Encoding R - o - o o - o o o o o o o o Accept-Language 2xx - - - ? o - - m* - - - o - o Accept-Language 415 - c - ? c m* o c c m* c c o c Accept-Language R - o - o o - o o o o o o o o Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o Alert-Info 180 - - - ? o - - - - ? ? - - ? Alert-Info R - - - ? o - - - - - - - - - Alert-Info r ? ? ? ? ? ? ? ? ? - - ? ? - Allow 2xx - o - ? m* o o m* o ? ? o o o Allow 405 - m - o m m m m m m m m m m Allow R - o - ? o o o o o o ? o o o Allow r - o - ? o o o o o o ? o o o Allow-Events 2xx - o - ? o ? o o o ? ? o o ? Allow-Events 489 - - - ? - ? m - - m ? - m ? Allow-Events R o o - ? o ? o o o o ? o o - Allow-Events r ? ? ? ? ? ? ? ? ? ? ? ? ? - Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Authentication-Info 2xx - o - ? o o o o o o o o o o Authorization R o o o o o o o o o o o o o o Call-ID c r m m m m m m m m m m m m m m Call-Info R ar - - - ? o o ? o - o - o ? o Call-Info r ar - - - ? o o ? o - o - o ? o Contact 1xx - - - - o - o - - - - - o o Contact 2xx - - - - m - o o - - m o m m Contact 3xx - o - - o o m o o o ? o m o Contact 485 - o - - o o o o o o ? o o o Contact R o - - o m - m o - - m o m m Content-Disposition R o o - ? o o o o o o o o o o Content-Disposition r o o - ? o o o o o o o o o o Content-Encoding R o o - o o o o o o o o o o o Content-Encoding r o o - o o o o o o o o o o o Content-Language R o o - ? o o o o o o o o o o Content-Language r o o - ? o o o o o o o o o o Content-Length R ar t t t o t t t t t t o t t t Content-Length r ar t t t o t t t t t t o t t t Content-Type R * * - * * * * * * * * * * * Content-Type r * * - * * * * * * * * * * * CSeq c r m m m m m m m m m m m m m m Date R a o o o o o o o o o o o o o o Date r a o o o o o o o o o o o o o o Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Error-Info 300-699 a - o o ? o o o o o o ? o o o Event R - - - ? - ? m - - m ? - m - Event r ? ? ? ? ? ? ? ? ? ? ? ? ? - Expires R - - - o o o - - - o o o o - Expires r - - - o o o - - - o ? o o - Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >From c r m m m m m m m m m m m m m m History-Info R amdr - - - - o o o o - o o o o - History-Info r amdr - - - - o o o o - o o o o - Identity R a o o - ? o ? ? o ? ? ? o ? ? Identity-Info R a o o - ? o ? ? o ? ? ? o ? ? In-Reply-To R - - - ? o o - - - - - - - - In-Reply-To r ? ? ? ? ? ? ? ? ? ? - ? ? - Join R - - - - o - - - - - - - - - Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Max-Forwards R amr m m m o m m m m m m m m m m MIME-Version R o o - ? o ? o o o o o o o o MIME-Version r o o - ? o ? o o o o o o o o Min-Expires 423 - - - ? - ? - - - m ? m m ? Min-Expires R ? ? ? ? ? ? ? ? ? ? - ? ? - Min-Expires r ? ? ? ? ? ? ? ? ? ? - ? ? - Min-SE 422 - - - ? m ? - - - ? ? - - m Min-SE R amr - - - ? o ? - - - ? ? - - o Organization R ar - - - o o o - o - o o o o o Organization r ar - - - o o o - o - o o o o o P-Access-Network-Info R dr - o - o o o o o o ? o o o o P-Access-Network-Info r dr - o - o o o o o o ? o o o o P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ? P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ? P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ? P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ? P-Associated-URI 2xx - - - ? - ? ? - ? ? ? o ? ? P-Called-Party-ID R amr - - - - o o - o - ? o - o - P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Charging-Vector R admr - o - o o o o o o ? o o o o P-Charging-Vector r admr - o - o o o o o o ? o o o o P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ? P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ? P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ? P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ? P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ? P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ? P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ? P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ? P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? - P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ? P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o P-Media-Authorization R ad o - - - o ? - - o ? ? - - o P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ? P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ? P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P-Visited-Network-ID R ad - - - - o o - o - ? o o o - Path 2xx - - - - ? - ? ? - ? ? ? o ? ? Path R ar - - - ? - ? ? - ? ? ? o ? ? Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Priority R ar - - - o o o - - - o - - o - Priority r ? ? ? ? ? ? ? ? ? ? ? ? ? - Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Privacy R amrd o o o ? o o o o ? ? ? o o o Privacy r amrd o o o ? o o o o ? ? ? o o o Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o Proxy-Authenticate 407 ar - m - o m m m m m m m m m m Proxy-Authorization R dr o o - o o o o o o o o o o o RAck R - - - ? - ? - - m ? ? - - - Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Record-Route 18x mr - o o ? o ? ? o o ? o - ? o Record-Route 2xx mr - o o o o ? o o o ? o - o o Record-Route R ar o o o o o - o o o - o - o o Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ? Refer-Sub 2xx - - - - - - - - - - o - - - Refer-Sub R - - - - - - - - - - o - - - Refer-To R - - - ? - ? ? - ? ? ? - ? ? Referred-By R - o - ? o ? ? o ? ? ? o ? ? Reject-Contact R ar o o o o o o o o o ? o - o o Replaces R - - - - o - - - - - - - - - Reply-To R - - - ? o o - - - - - - - - Reply-To r - - - ? o o - - - - - - - - Request-Disposition R ar o o o o o o o o o ? o o o o Require R ar - c - o c c o c c o c c o c Require r ar - c - ? c c o c c o c c o c Resource-Priority R amdr o o o o o o o o o o o o o o Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Retry-After 404 - o o o o ? o o o o o o o o Retry-After 413 - o o ? o ? o o o o o o o o Retry-After 480 - o o o o ? o o o o o o o o Retry-After 486 - o o o o ? o o o o o o o o Retry-After 4xx ? ? ? ? ? o ? ? ? ? ? ? ? ? Route R adr c c c o c o c c c c c c c c RSeq 1xx - - - ? o ? o - - ? ? - o ? RSeq R ? ? ? ? ? ? ? ? ? ? ? ? ? - RSeq r ? ? ? ? ? ? ? ? ? ? ? ? ? - Security-Client R ard - o - ? o o o o ? ? ? o o o Security-Server 421 - o - ? o o o o ? ? ? o o o Security-Server 494 - o - ? o o o o ? ? ? o o o Security-Verify R ard - o - ? o o o o ? ? ? o o o Server r - o o o o o o o o o o o o o Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ? Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o Session-Expires R amr - - - ? o ? - - - ? ? - - o SIP-ETag 2xx - - - - - - - - - m - - - - SIP-If-Match R - - - - - - - - - o - - - - Subject R - - - o o o - - - o - - - - Subject r ? ? ? ? ? ? ? ? ? ? ? ? ? - Subscription-State R - - - ? - ? m - - ? ? - - - Subscription-State r ? ? ? ? ? ? ? ? ? ? ? ? ? - Supported 2xx - o o ? m* ? o m* o o o o o o Supported R - o o ? m* ? o o o o o o o o Target-Dialog R - - - - - o - - - - - o - o - Timestamp R o o o o o o o o o o o o o o Timestamp r o o o o o o o o o o o o o o To c r m m m m m m m m m m m m m m Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Unsupported 420 - m - o m o o m m o o m o m User-Agent R o o o o o o o o o o o o o o User-Agent r o o o o o o o o o o o o o o Via R amr m m m ? m m ? m ? m ? m ? m Via rc dr m m m ? m m ? m ? m ? m ? m Warning r - o o o o o o o o o o o o o WWW-Authenticate 401 ar - m - o m m m m m m m m m m WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o See all those question marks? Someone needs to come up with actual values for each of those cells. Some are going to be pretty easy to answer; others will require substantial research and/or debate. It seems like a lot of effort to me. Are we certain the return on our investment of time will be worth it? /a --------------000002030100010504070703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-sending with a new subject line, since this has almost nothing to do with 3265bis any longer. Sorry for the additional noise.

[as a participant]

On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote:


Dean Willis wrote:

We had this discussion a while ago, and it may be good to start it again. I think at least Dean mentioned abandoning Table 2. I talked about having a website instead, which would be easier to keep up to date, but I think the IETF proceures didn't allow that.

Right. for things that one might use a website for, we have IANA registries.

One could replace Table 2 with a registry, and have new RFCs update that registry.

I support this approach.

Okay. If we go down this path -- and I think it's a little bit crazy -- then we'll need to ferret out the correct values for the current header fields and methods to set up the initial registry.

Because of the haphazard way we've handled this, the table contains substantial gaps. I wrote a script to parse out all the formal Table 2 expansions from the RFCs that define SIP header fields and SIP methods, and merge them into a single view of what has been defined to date. With the caveat that this is a lot of data, and something might have been missed, here's what it looks like:

Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF REG SUB UPD
Accept 2xx
- - - ? o - - m* - - - o - o
Accept 415
- c - ? c m* o c c m* c c o c
Accept R
- o - o o - o m* o o o o o o
Accept-Contact R ar o o o o o o o o o ? o - o o
Accept-Encoding 2xx
- - - ? o - - m* - - - o - o
Accept-Encoding 415
- c - ? c m* o c c m* c c o c
Accept-Encoding R
- o - o o - o o o o o o o o
Accept-Language 2xx
- - - ? o - - m* - - - o - o
Accept-Language 415
- c - ? c m* o c c m* c c o c
Accept-Language R
- o - o o - o o o o o o o o
Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o
Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o
Alert-Info 180
- - - ? o - - - - ? ? - - ?
Alert-Info R
- - - ? o - - - - - - - - -
Alert-Info r
? ? ? ? ? ? ? ? ? - - ? ? -
Allow 2xx
- o - ? m* o o m* o ? ? o o o
Allow 405
- m - o m m m m m m m m m m
Allow R
- o - ? o o o o o o ? o o o
Allow r
- o - ? o o o o o o ? o o o
Allow-Events 2xx
- o - ? o ? o o o ? ? o o ?
Allow-Events 489
- - - ? - ? m - - m ? - m ?
Allow-Events R
o o - ? o ? o o o o ? o o -
Allow-Events r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Authentication-Info 2xx
- o - ? o o o o o o o o o o
Authorization R
o o o o o o o o o o o o o o
Call-ID c r m m m m m m m m m m m m m m
Call-Info R ar - - - ? o o ? o - o - o ? o
Call-Info r ar - - - ? o o ? o - o - o ? o
Contact 1xx
- - - - o - o - - - - - o o
Contact 2xx
- - - - m - o o - - m o m m
Contact 3xx
- o - - o o m o o o ? o m o
Contact 485
- o - - o o o o o o ? o o o
Contact R
o - - o m - m o - - m o m m
Content-Disposition R
o o - ? o o o o o o o o o o
Content-Disposition r
o o - ? o o o o o o o o o o
Content-Encoding R
o o - o o o o o o o o o o o
Content-Encoding r
o o - o o o o o o o o o o o
Content-Language R
o o - ? o o o o o o o o o o
Content-Language r
o o - ? o o o o o o o o o o
Content-Length R ar t t t o t t t t t t o t t t
Content-Length r ar t t t o t t t t t t o t t t
Content-Type R
* * - * * * * * * * * * * *
Content-Type r
* * - * * * * * * * * * * *
CSeq c r m m m m m m m m m m m m m m
Date R a o o o o o o o o o o o o o o
Date r a o o o o o o o o o o o o o o
Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Error-Info 300-699 a - o o ? o o o o o o ? o o o
Event R
- - - ? - ? m - - m ? - m -
Event r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Expires R
- - - o o o - - - o o o o -
Expires r
- - - o o o - - - o ? o o -
Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
From c r m m m m m m m m m m m m m m
History-Info R amdr - - - - o o o o - o o o o -
History-Info r amdr - - - - o o o o - o o o o -
Identity R a o o - ? o ? ? o ? ? ? o ? ?
Identity-Info R a o o - ? o ? ? o ? ? ? o ? ?
In-Reply-To R
- - - ? o o - - - - - - - -
In-Reply-To r
? ? ? ? ? ? ? ? ? ? - ? ? -
Join R
- - - - o - - - - - - - - -
Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Max-Forwards R amr m m m o m m m m m m m m m m
MIME-Version R
o o - ? o ? o o o o o o o o
MIME-Version r
o o - ? o ? o o o o o o o o
Min-Expires 423
- - - ? - ? - - - m ? m m ?
Min-Expires R
? ? ? ? ? ? ? ? ? ? - ? ? -
Min-Expires r
? ? ? ? ? ? ? ? ? ? - ? ? -
Min-SE 422
- - - ? m ? - - - ? ? - - m
Min-SE R amr - - - ? o ? - - - ? ? - - o
Organization R ar - - - o o o - o - o o o o o
Organization r ar - - - o o o - o - o o o o o
P-Access-Network-Info R dr - o - o o o o o o ? o o o o
P-Access-Network-Info r dr - o - o o o o o o ? o o o o
P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ?
P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ?
P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ?
P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ?
P-Associated-URI 2xx
- - - ? - ? ? - ? ? ? o ? ?
P-Called-Party-ID R amr - - - - o o - o - ? o - o -
P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Charging-Vector R admr - o - o o o o o o ? o o o o
P-Charging-Vector r admr - o - o o o o o o ? o o o o
P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ?
P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ?
P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ?
P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ?
P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? -
P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o
P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o
P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ?
P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o
P-Media-Authorization R ad o - - - o ? - - o ? ? - - o
P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ?
P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ?
P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
P-Visited-Network-ID R ad - - - - o o - o - ? o o o -
Path 2xx - - - - ? - ? ? - ? ? ? o ? ?
Path R ar - - - ? - ? ? - ? ? ? o ? ?
Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Priority R ar - - - o o o - - - o - - o -
Priority r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Privacy R amrd o o o ? o o o o ? ? ? o o o
Privacy r amrd o o o ? o o o o ? ? ? o o o
Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o
Proxy-Authenticate 407 ar - m - o m m m m m m m m m m
Proxy-Authorization R dr o o - o o o o o o o o o o o
RAck R
- - - ? - ? - - m ? ? - - -
Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Record-Route 18x mr - o o ? o ? ? o o ? o - ? o
Record-Route 2xx mr - o o o o ? o o o ? o - o o
Record-Route R ar o o o o o - o o o - o - o o
Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ?
Refer-Sub 2xx
- - - - - - - - - - o - - -
Refer-Sub R
- - - - - - - - - - o - - -
Refer-To R
- - - ? - ? ? - ? ? ? - ? ?
Referred-By R
- o - ? o ? ? o ? ? ? o ? ?
Reject-Contact R ar o o o o o o o o o ? o - o o
Replaces R
- - - - o - - - - - - - - -
Reply-To R
- - - ? o o - - - - - - - -
Reply-To r
- - - ? o o - - - - - - - -
Request-Disposition R ar o o o o o o o o o ? o o o o
Require R ar - c - o c c o c c o c c o c
Require r ar - c - ? c c o c c o c c o c
Resource-Priority R amdr o o o o o o o o o o o o o o
Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Retry-After 404
- o o o o ? o o o o o o o o
Retry-After 413
- o o ? o ? o o o o o o o o
Retry-After 480
- o o o o ? o o o o o o o o
Retry-After 486
- o o o o ? o o o o o o o o
Retry-After 4xx
? ? ? ? ? o ? ? ? ? ? ? ? ?
Route R adr c c c o c o c c c c c c c c
RSeq 1xx
- - - ? o ? o - - ? ? - o ?
RSeq R
? ? ? ? ? ? ? ? ? ? ? ? ? -
RSeq r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Security-Client R ard - o - ? o o o o ? ? ? o o o
Security-Server 421
- o - ? o o o o ? ? ? o o o
Security-Server 494
- o - ? o o o o ? ? ? o o o
Security-Verify R ard - o - ? o o o o ? ? ? o o o
Server r
- o o o o o o o o o o o o o
Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ?
Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o
Session-Expires R amr - - - ? o ? - - - ? ? - - o
SIP-ETag 2xx
- - - - - - - - - m - - - -
SIP-If-Match R
- - - - - - - - - o - - - -
Subject R
- - - o o o - - - o - - - -
Subject r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Subscription-State R
- - - ? - ? m - - ? ? - - -
Subscription-State r
? ? ? ? ? ? ? ? ? ? ? ? ? -
Supported 2xx
- o o ? m* ? o m* o o o o o o
Supported R
- o o ? m* ? o o o o o o o o
Target-Dialog R - - - - - o - - - - - o - o -
Timestamp R
o o o o o o o o o o o o o o
Timestamp r
o o o o o o o o o o o o o o
To c r m m m m m m m m m m m m m m
Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Unsupported 420
- m - o m o o m m o o m o m
User-Agent R
o o o o o o o o o o o o o o
User-Agent r
o o o o o o o o o o o o o o
Via R amr m m m ? m m ? m ? m ? m ? m
Via rc dr m m m ? m m ? m ? m ? m ? m
Warning r
- o o o o o o o o o o o o o
WWW-Authenticate 401 ar - m - o m m m m m m m m m m
WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o


See all those question marks? Someone needs to come up with actual values for each of those cells. Some are going to be pretty easy to answer; others will require substantial research and/or debate.

It seems like a lot of effort to me. Are we certain the return on our investment of time will be worth it?

/a

--------------000002030100010504070703-- From christer.holmberg@ericsson.com Tue Feb 23 23:34:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273303A7507 for ; Tue, 23 Feb 2010 23:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 sQr6r2Pv4M+q for ; Tue, 23 Feb 2010 23:34:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 975E13A6774 for ; Tue, 23 Feb 2010 23:34:25 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-55-4b84d6fdf987 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B7.77.01038.DF6D48B4; Wed, 24 Feb 2010 08:36:29 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Feb 2010 08:36:29 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Adam Roach Date: Wed, 24 Feb 2010 08:36:29 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq0otpX+SLT+mDTQvijQlAm7Fdb+wAW133g Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> In-Reply-To: <4B83FE28.2010503@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:34:27 -0000 Hi, Unless someone objects, I think we can drop the alternative where the proxy= would include SDP for the UASs, because that could cause message size iss= ues etc... If an UAC wants to get such information, it needs to send an OPT= IONS request addressed to the actual UAS. Dean suggested that the proxy returns the gruus of the UASs. But, as I said= earlier, I still think we should consider whether the proxy could return t= he registered feature tags of the UASs, together with the gruus, since the = proxy has that information.=20 In fact, I believe that could help getting people to implement callerprefs = (and gruu), because it would be a use-case where it is really good to do so= . Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 23. helmikuuta 2010 18:11 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? Adam, Maybe the thread has branched too much to follow. I was contrasting two things, one by Dean and the other by Christer. I agree with you re Dean's. The alternative proposal was for the "proxy" to answer on behalf of the reg= istered endpoints, with an aggregate response. Exactly what that aggregate = response would look like is not clear. At one point I had suggested that th= e "proxy" could send its own OPTIONS requests to the endpoints. If so, and = if their responses contained SDP, then an aggregate response might require = a multipart. The Dean suggestion is by far the better one. Thanks, Paul Adam Roach wrote: > On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >> >> >> Hans Erik van Elburg wrote: >>> Agreed. Of course a proxy equiped with such policy can do that. It=20 >>> is kind of a domain specific service. >>> For that you do not have to bend the interpretation of the original >>> RFC3261 text. >>> >>> If you use the 302 approach proposed by Dean, then do you need to do=20 >>> anything specification wise? >> >> No. Its entirely above board. >> >> Having the proxy respond on behalf of the endpoints may or may not be=20 >> entirely conforming, depending on how it responds. >=20 > That's not how I read Dean's proposal. The "Proxy/Registrar" isn't=20 > responding on behalf of the UAs. It's letting the UAC know where to=20 > find all the registered UAs. >=20 > What I see Dean proposing is something like this: >=20 > Dean Registrar Adam 1 Adam 2 Adam 3 > | | | | | > |OPTIONS | | | | > |-------->| | | | > | | | | | > |302 | | | | > |Contact: sip:adam1.example.com | > |Contact: sip:adam2.example.com | > |Contact: sip:adam3.example.com | > |<--------| | | | > | | | | | > |OPTIONS | | | | > |------------------>| | | > |200 | | | | > |<------------------| | | > | | | | | > |OPTIONS | | | | > |---------------------------->| | > |200 | | | | > |<----------------------------| | > | | | | | > |OPTIONS | | | | > |-------------------------------------->| > |200 | | | | > |<--------------------------------------| >=20 > Perfectly above board, normal handling. Keep in mind that the=20 > Registrar can stay in the path by returning GRUUs instead of contacts=20 > that go directly to the UAs. It all works just fine either way. >=20 > /a >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Feb 23 23:52:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A8328C193 for ; Tue, 23 Feb 2010 23:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[AWL=-2.594, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492] 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 6RmcIN1u1ne5 for ; Tue, 23 Feb 2010 23:52:57 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2415228C0D7 for ; Tue, 23 Feb 2010 23:52:56 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-ad-4b84db553566 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 65.25.31641.55BD48B4; Wed, 24 Feb 2010 08:55:01 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 24 Feb 2010 08:55:01 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 24 Feb 2010 08:55:00 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acqz8oSycplVMvjlRuqXK0UDtzl2MwBMxTSw Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B7EA20E.3040806@nostrum.com> <4B8285B2.80801@cisco.com> <4B82D647.2040203@cisco.com> In-Reply-To: <4B82D647.2040203@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:52:59 -0000 Hi,=20 >>>For the "prefer video" option you mention, you can use callerprefs=20 >>>specifically to express that, so that devices with video capabilities ar= e tried first, and=20 >>>others as a fallback. >>=20 >>Sure, there are cases where it will work, e.g. if you don't require certa= ins extensions and=20 >>you don't want the message to look differen if it will reach a "non-video= " device. > >While its an incredible pain, you can specify fairly sophisticated selecti= on criteria. IMO=20 >the most fundamental issue with this approach is you are never certain if = your *preferences*=20 >will be honored, whether this is because of conflicting policies, or becau= se the devices just=20 >don't support the processing of callerprefs. > >I recognize that there is a lot more certainty when the caller can examine= all the=20 >possibilities and make its own decisions. But this is also fundamentally l= imited, because the=20 >called user may well be unwilling to share with you the information you ne= ed to make your=20 >decision. (I quite likely will not let unknown callers know how many UAs o= f which types I=20 >have connected, or what algorithms I might use to decide to route your cal= l to one of them or=20 >to VM.) True. And, I don't think we should mandate what information the proxy retur= ns. It could be based on whatever policies. For example, if the proxy does not want to return the number of UAs, it cou= ld simply e.g return the registered feature tags, but not per UAS. That wou= ld at least let the UAC know what type of features are supported, eventhoug= h not which UAS support what. >You can view OPTIONS as a poor man's version of one-shot presence.=20 >Rather than fix it, maybe we should be trying to work our some recommendat= ions for providing=20 >presence information to unknown subscribers. One could do that, but I think that the OPTIONS fix we've been discussing w= ould still be sufficient in many cases. Regards, Christer > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > Christer Holmberg wrote: >> Hi, >> >>> I'm a bit confused. On the rather remote chance that you want to=20 >>> poll all of the UAs associated with an AOR, >> I am not sure I agree on the "remote chance" thing. From my personal exp= erience, people are more interested in all UASs behind an AOR, in order to = set feature tag values etc accordingly when later esttablishing a session. >> >>> you can subscribe to the AOR's reg event state; collect the GRUUs;=20 >>> and then send an OPTIONS to each UA in turn. >> Sure, you can do that.=20 >> >> The idea behind the proposal, however, is that you would at least be abl= e to get SOME information (even if only the gruus of the UASs, per Dean's p= roposal) using a single request. >> >> Then, if you need additional information (SDP etc), sending individual O= PTIONS might be the best solution. But, the information you got in the firs= t response might help you to decided to which UASs you are going to send in= dividual OPTIONS. >> >>> But what's the real use case here? I can't imagine anything you can=20 >>> do with this information that doesn't work better with callerprefs. >> One of the use-cases I have in mind is actually to enable better use of = callerprefs. >> >> For example, assume that Alice wants to make a call, and her first optio= n is to reach UAS devices that support video. So, she wants to use callerpr= efs to require video support. However, if no UAS support video, the call ma= y get rejected. >> >> Alice could of course send a request which does not require video, but t= hen the call might be answered by a phone which doesn't support it, even if= another phone would have supported it. >> >> In addition, if all the non-video phones also get the request it might m= ean more early dialogs etc, that at least on wireless accesses can create a= number of resource issues.=20 >> >> Sure, you can BYE unwanted early dialogs, but why create them in the fir= st place? >> >> A similar example (which is also described in RFC3261, I believe) is whe= n Alice wants to use an exension using the Require header, and wants to mak= e sure that there are UASs supporting the extension. >> >> So, in general I don't think the use-case is very different usages of OP= TIONS, but it would allow users to get at least some capabilities of all us= ers behind an AOR using a single request. >> >> Regards, >> >> Christer >> >> >> On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote: >>> I pretty much agree with John. >>> >>> IMO there is no point in doing anything unless there is also work to=20 >>> clarify what the response *means* in a way that is operationally useful= . >>> >>> Even when there is only one UA and the OPTIONS request is getting to=20 >>> it, the result isn't especially useful, except as a "ping" because: >>> >>> - nominally the response code is supposed to be the same as >>> it would be for an INVITE. I guess that means you should get >>> a 486 response if the UA is on a call and would reject another. >>> But what if the UA *never* accepts INVITES - only SUBSCRIBE? >>> Should you get 405? >>> >>> - If the UA can in principle support a lot of things, but not >>> all in the same call, there is no well defined way to reflect that. >>> >>> I would like to see a set of use cases for how people would like to=20 >>> use OPTIONS where this enhancement is needed. >>> >>> Thanks, >>> Paul >>> >>> Elwell, John wrote: >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]=20 >>>>> On Behalf Of Christer Holmberg >>>>> Sent: 19 February 2010 11:28 >>>>> To: SIPCORE >>>>> Subject: [sipcore] OPTIONS: How to solve the forking problem? >>>>> >>>>> Hi, >>>>> >>>>> Some input regarding the OPTIONS issue. >>>>> >>>>> BACKGROUND: >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> One of the main problems with OPTIONS is forking. In case the=20 >>>>> request is forked, the UAC will only receive the capabilities of=20 >>>>> one device/UAS (which UAS depends on which 200 OK reaches the=20 >>>>> forking proxy first). >>>>> >>>>> OPTIONS works fine in HTTP, where we don't have forking and an=20 >>>>> HTTP URI always identify uniquely a specific resource or a specific s= erver. >>>>> But, if I address the request to an AOR (which points to a domain,=20 >>>>> not to a specific device) I might want to receive capabilities of=20 >>>>> all the UAS associated with that AOR/domain. >>>>> First, do we agree that is a valid usage to address OPTIONS to an AOR= ? >>>>> OR, do we think that OPTIONS should only be addressed to specific=20 >>>>> devices (section 11 of 3261 talks about devices), in which case I=20 >>>>> guess we don't need to do anything - at least not as far as=20 >>>>> forking is concerned. >>>>> >>>>> The rest of this e-mail is based on the assumption that we DO want=20 >>>>> to be able to address OPTIONS to an AOR. >>>>> >>>>> >>>>> ABSTRACT: >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> I have put together 3 alternative solutions on how the problem=20 >>>>> could be fixed. The first alternative is based on a UAS change,=20 >>>>> while the second and third alternatives are based on a model where=20 >>>>> the registrar (forking proxy) sends a response "on behalf" of the UAS= (s). >>>>> >>>>> The 4th alternative is of course that we do nothing, but based on=20 >>>>> previous discussions it does seem that some people are interested=20 >>>>> in doing something about OPTIONS. >>>>> >>>>> >>>>> ALTERNATIVE 1: >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> In this alternative the UAS(s) send a provisional response,=20 >>>>> including the capabilities, to the OPTIONS request. The registrar=20 >>>>> will (hopefully) forward all the provisional responses towards the UA= C. >>>>> >>>>> Pros/cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>>> + to >>>>> get the capabilities of all UAS(s) associated with the AOR. >>>>> + No impacts on registrar >>>>> >>>>> - Does not work with deployed Uas >>>>> - Would the provisional response need to be PRACKed? >>>> [JRE] I hope this Alternative 1 is not meant to be serious. This=20 >>>> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT=20 >>>> issue a provisional response for a non-INVITE request". I wonder=20 >>>> how many SIP stacks would handle this. Also, having sent a=20 >>>> provisional response, the UAS needs to send a final response, so=20 >>>> how would this interact? >>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> This alternative would most likely require an RFC: either an=20 >>>>> extension with an associated option-tag, or an update to 3261. >>>>> >>>>> >>>>> >>>>> ALTERNATIVE 2: >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> In this alternative the registrar never forks the OPTIONS request=20 >>>>> towards the UAS(s). Instead, it sends a response on behalf of the=20 >>>>> UASs, based on the information is has about the UAS(s), based on=20 >>>>> registration information (feature tags etc) etc. >>>>> >>>>> The first question is whether 3261 already allows this: >>>>> >>>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect=20 >>>>> to get capabilities associated with that AOR (which points to a=20 >>>>> domain, not to a specific device). Currently, in case of forking,=20 >>>>> I will only get the capabilities from one device/UAS associated=20 >>>>> with that domain. >>>>> >>>>> But, if the registrar sends the OPTIONS response, it can provide=20 >>>>> capabilities of all registered UAS(s) associated with the AOR/domain. >>>>> >>>>> So, so far I don't think 3261 forbids this kind of behavior (in=20 >>>>> fact, I think this kind of behavior actually better implements=20 >>>>> what is described in 3261...) >>>>> >>>>> >>>>> Now, the best way to return the capabilities would probably be by=20 >>>>> using a message body, e.g. a multipart with sipfrag body parts=20 >>>>> (each sipfrag body part representing a UAS). >>>> [JRE] And that sipfrag body part would need to contain an SDP body=20 >>>> part to represent the SDP capabilities of the UAS? This would make=20 >>>> responses potentially very large, posing a problem for UDP. It is=20 >>>> probably a more extreme example than anything we have had before of=20 >>>> a response being VERY MUCH larger than a request. >>>> >>>>> But, RFC3261 says that a proxy does not insert a message body in=20 >>>>> the OPTIONS response, and that is probably ok in most cases when=20 >>>>> the proxy returns its owns capabilities. But, when the proxy=20 >>>>> replies on behalf of the UAS(s), I see no reason why it should not=20 >>>>> be allowed to include a body. The UAC will get the capabilities of=20 >>>>> the UAS(s), and that is what matters. >>>> [JRE] In this case what you call the proxy is the UAS w.r.t. this=20 >>>> particular transaction, so it can include a body. >>>> >>>>> Pros/cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>>> + to >>>>> get the capabilities of all UAS(s) associated with the AOR. >>>> [JRE] I am not sure what it needs this for, but we have the=20 >>>> reg-event package to identify all registered Uas, and then OPTIONS=20 >>>> could be directed at each in turn. >>>> >>>>> + In my personal opinion this does not require any changes in >>>>> + RFC3261 >>>>> >>>>> - The set of capabilities per UAS is limited to what the registrar=20 >>>>> knows about the UAS (based on registration information, and/or by=20 >>>>> provisioning), so SDP information would probably be left out. The=20 >>>>> mechanism might still be good enough for many scenarios, though. >>>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> If we think RFC3261 allows this, the question is whether we=20 >>>>> consider it so crystal clear that nothing needs to be specified,=20 >>>>> or whether it would be a good idea to put together a BCP type-of=20 >>>>> document describing it. >>>>> >>>>> Or, do people think that this is NOT allowed behavior? >>>> [JRE] Even if allowed, I think we might need some specification of=20 >>>> the sipfrag part of it, and I am concerned about the response size. >>>> But I am not convinced there is a requirement to be able to use=20 >>>> OPTIONS to get information about multiple UAs at once. >>>> >>>>> >>>>> >>>>> ALTERNATIVE 3: >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> The idea is similar to Alternative 1, but in this case the=20 >>>>> registrar would fork the OPTIONS request towards the UAS(s), then "CO= LLECT" >>>>> the responses, and finally send a single response which contains=20 >>>>> the capabilities of all UAS(s) towards the UAC. >>>> [JRE] Again using sipfrags? >>>> >>>>> Prox/Cons: >>>>> ---------------- >>>>> >>>>> + The major advantage of this mechanism is that it allows the UAC=20 >>>>> + to >>>>> get the capabilities of all UAS(s). >>>>> + The UAC will get more or less the same set of capabilities for=20 >>>>> + an >>>>> UAS, as if the UAS would have sent the response directly to the UAC. >>>>> >>>>> - I guess most people would consider the forking proxy acting as a=20 >>>>> B2BUA in this case, since it does not follow the 3261 rules about=20 >>>>> forwarding (or discarding) 200 OK responses immediately when received= . >>>>> >>>>> What to do: >>>>> ----------------- >>>>> >>>>> If we think this is a good solution, could it be described in a BCP?= =20 >>>>> I guess we would not update 3261 to describe this behavior? >>>> [JRE] Again we would need to specify the sipfrag bits of it, and I=20 >>>> would be concerned about the response size. >>>> >>>> John >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 From pkyzivat@cisco.com Wed Feb 24 06:46:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200B728C194 for ; Wed, 24 Feb 2010 06:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Wyxq4rCAHMeV for ; Wed, 24 Feb 2010 06:46:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 23A7528C163 for ; Wed, 24 Feb 2010 06:46:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO7KhEtAZnwM/2dsb2JhbACbEnOkfZhGhHIEgxY X-IronPort-AV: E=Sophos;i="4.49,532,1262563200"; d="scan'208";a="88521058" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2010 14:48:22 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1OEmMPA005563; Wed, 24 Feb 2010 14:48:22 GMT Message-ID: <4B853C37.6040706@cisco.com> Date: Wed, 24 Feb 2010 09:48:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A129.2010705@nostrum.com> In-Reply-To: <4B84A129.2010705@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 14:46:18 -0000 Adam Roach wrote: > See all those question marks? Someone needs to come up with actual > values for each of those cells. Some are going to be pretty easy to > answer; others will require substantial research and/or debate. > > It seems like a lot of effort to me. Are we certain the return on our > investment of time will be worth it? Isn't it the case that every implementor also has to figure out those question marks? (And how consistent are the results when they do so?) If the answers for each of those question marks aren't easy to find, then doesn't that make it even more important to find them? If they can't each be defined by citing a particular document and section, then I suspect some new normative document will be required to nail them down. Thanks, Paul From pkyzivat@cisco.com Wed Feb 24 06:52:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8235228C192 for ; Wed, 24 Feb 2010 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7+SkmEC-VeCU for ; Wed, 24 Feb 2010 06:52:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4E8AC28C172 for ; Wed, 24 Feb 2010 06:52:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABrMhEtAZnwM/2dsb2JhbACbEnOkeZhGhHIEgxY X-IronPort-AV: E=Sophos;i="4.49,532,1262563200"; d="scan'208";a="88652902" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2010 14:54:18 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1OEsIXf007317; Wed, 24 Feb 2010 14:54:18 GMT Message-ID: <4B853D9C.1010109@cisco.com> Date: Wed, 24 Feb 2010 09:54:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 14:52:13 -0000 It is already permissible for a proxy to do as you suggest - return a 300 with multiple contacts, and include the feature tags that were provided at registration. The question would be whether to somehow make this mandatory. Thanks, Paul Christer Holmberg wrote: > Hi, > > Unless someone objects, I think we can drop the alternative where the proxy would include SDP for the UASs, because that could cause message size issues etc... If an UAC wants to get such information, it needs to send an OPTIONS request addressed to the actual UAS. > > Dean suggested that the proxy returns the gruus of the UASs. But, as I said earlier, I still think we should consider whether the proxy could return the registered feature tags of the UASs, together with the gruus, since the proxy has that information. > > In fact, I believe that could help getting people to implement callerprefs (and gruu), because it would be a use-case where it is really good to do so. > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23. helmikuuta 2010 18:11 > To: Adam Roach > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? > > Adam, > > Maybe the thread has branched too much to follow. > > I was contrasting two things, one by Dean and the other by Christer. > I agree with you re Dean's. > > The alternative proposal was for the "proxy" to answer on behalf of the registered endpoints, with an aggregate response. Exactly what that aggregate response would look like is not clear. At one point I had suggested that the "proxy" could send its own OPTIONS requests to the endpoints. If so, and if their responses contained SDP, then an aggregate response might require a multipart. > > The Dean suggestion is by far the better one. > > Thanks, > Paul > > Adam Roach wrote: >> On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >>> >>> Hans Erik van Elburg wrote: >>>> Agreed. Of course a proxy equiped with such policy can do that. It >>>> is kind of a domain specific service. >>>> For that you do not have to bend the interpretation of the original >>>> RFC3261 text. >>>> >>>> If you use the 302 approach proposed by Dean, then do you need to do >>>> anything specification wise? >>> No. Its entirely above board. >>> >>> Having the proxy respond on behalf of the endpoints may or may not be >>> entirely conforming, depending on how it responds. >> That's not how I read Dean's proposal. The "Proxy/Registrar" isn't >> responding on behalf of the UAs. It's letting the UAC know where to >> find all the registered UAs. >> >> What I see Dean proposing is something like this: >> >> Dean Registrar Adam 1 Adam 2 Adam 3 >> | | | | | >> |OPTIONS | | | | >> |-------->| | | | >> | | | | | >> |302 | | | | >> |Contact: sip:adam1.example.com | >> |Contact: sip:adam2.example.com | >> |Contact: sip:adam3.example.com | >> |<--------| | | | >> | | | | | >> |OPTIONS | | | | >> |------------------>| | | >> |200 | | | | >> |<------------------| | | >> | | | | | >> |OPTIONS | | | | >> |---------------------------->| | >> |200 | | | | >> |<----------------------------| | >> | | | | | >> |OPTIONS | | | | >> |-------------------------------------->| >> |200 | | | | >> |<--------------------------------------| >> >> Perfectly above board, normal handling. Keep in mind that the >> Registrar can stay in the path by returning GRUUs instead of contacts >> that go directly to the UAs. It all works just fine either way. >> >> /a >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Wed Feb 24 07:57:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A889328C17E for ; Wed, 24 Feb 2010 07:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 13MrQ9dA+jme for ; Wed, 24 Feb 2010 07:57:44 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CAF813A70FC for ; Wed, 24 Feb 2010 07:57:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,532,1262581200"; d="scan'208";a="5055761" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Feb 2010 10:59:49 -0500 X-IronPort-AV: E=Sophos;i="4.49,532,1262581200"; d="scan'208";a="449253429" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Feb 2010 10:59:49 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1OFxSw10382; Wed, 24 Feb 2010 15:59:28 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o1OFxQY08071; Wed, 24 Feb 2010 15:59:26 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 10:59:24 -0500 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: <1266859994.3760.25.camel@khone.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 23 Feb 2010 13:38:28 -0500 Message-Id: <1266950308.10428.9.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2010 15:59:24.0521 (UTC) FILETIME=[55DD5590:01CAB56A] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:57:44 -0000 On Mon, 2010-02-22 at 18:48 +0100, Christer Holmberg wrote: > I want to query the UAs registered to the AOR. In which case, you don't want to send a request "to" the AOR, as it may well get forwarded to various other places. What you really want is the reg event package for the AOR, and then you can query the registered contacts. That appears to be insecure, but your intention is to get information about the capabilities of every registered contact, and any method that lets you do so pretty much tells what the contacts are. (And if it doesn't directly, properly constructed INVITEs that reach exactly one contact will eventually reveal the contact addresses of all of them.) Dale From dworley@avaya.com Wed Feb 24 07:57:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEB428C1DC for ; Wed, 24 Feb 2010 07:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 sA0xkS4YPhdO for ; Wed, 24 Feb 2010 07:57:51 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id BDE2128C1E3 for ; Wed, 24 Feb 2010 07:57:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,532,1262581200"; d="scan'208";a="5055771" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Feb 2010 10:59:52 -0500 X-IronPort-AV: E=Sophos;i="4.49,532,1262581200"; d="scan'208";a="449253448" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Feb 2010 10:59:51 -0500 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o1OFxVw10397; Wed, 24 Feb 2010 15:59:31 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o1OFxSY08083; Wed, 24 Feb 2010 15:59:28 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 10:59:24 -0500 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4B82C7E7.9060805@cisco.com> References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 23 Feb 2010 13:42:58 -0500 Message-Id: <1266950578.10428.13.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2010 15:59:25.0177 (UTC) FILETIME=[56416E90:01CAB56A] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:57:51 -0000 On Mon, 2010-02-22 at 13:07 -0500, Paul Kyzivat wrote: > None of this matters, because for non-invite transactions the UAC's > state machine is going to be done when the first final response is > received. It isn't going to be prepared to handle other 200 responses to > the same transaction. If "Request-Disposition: no-cancel" is to have any sensible effect, it means that "stray" 200 responses will be forwarded upstream, as they would for an INVITE. RFC 3841 is explicit that Request-Disposition can be used on non-INVITE requests. Dale From jmpolk@cisco.com Wed Feb 24 09:44:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BEE28C24F for ; Wed, 24 Feb 2010 09:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1HmQuhQ-6vm1 for ; Wed, 24 Feb 2010 09:44:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CBC1828C1CA for ; Wed, 24 Feb 2010 09:44:07 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,533,1262563200"; d="scan'208";a="92045155" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2010 17:46:15 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1OHkEEA008395; Wed, 24 Feb 2010 17:46:14 GMT Message-Id: <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Feb 2010 11:46:12 -0600 To: Adam Roach , Paul Kyzivat From: "James M. Polk" In-Reply-To: <4B84A181.90008@nostrum.com> References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 17:44:09 -0000 Adam Thanks for doing this script. Is it posted anywhere (perhaps on the SIPCORE site)? I use two mail apps, and it looked great in the first app, but not so great in the second app. WRT the topic, I understand this will become something of an albatross (wrt the amount of work it'll take and arguments we'll have over some of the indications) -- but I believe it will ultimately be useful. One point that will cause you a little more work in your script, when loading this on a webpage, if you could add the specific reference RFCs to the right of the columns where each header is defined (including updates perhaps) -- this would help. I know some are obvious, while others are not to readers/researchers. James At 09:48 PM 2/23/2010, Adam Roach wrote: >Re-sending with a new subject line, since this has almost nothing to >do with 3265bis any longer. Sorry for the additional noise. > >[as a participant] > >On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote: >> >> >>Dean Willis wrote: >> >>>>We had this discussion a while ago, and it may be good to start >>>>it again. I think at least Dean mentioned abandoning Table 2. I >>>>talked about having a website instead, which would be easier to >>>>keep up to date, but I think the IETF proceures didn't allow that. >>> >>>Right. for things that one might use a website for, we have IANA >>>registries. >>> >>>One could replace Table 2 with a registry, and have new RFCs >>>update that registry. >> >>I support this approach. > >Okay. If we go down this path -- and I think it's a little bit crazy >-- then we'll need to ferret out the correct values for the current >header fields and methods to set up the initial registry. > >Because of the haphazard way we've handled this, the table contains >substantial gaps. I wrote a script to parse out all the formal Table >2 expansions from the RFCs that define SIP header fields and SIP >methods, and merge them into a single view of what has been defined >to date. With the caveat that this is a lot of data, and something >might have been missed, here's what it looks like: > >Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF >REG SUB UPD >Accept 2xx >- - - ? o - - m* - - - o - o >Accept 415 >- c - ? c m* o c c m* c c o c >Accept R >- o - o o - o m* o o o o o o >Accept-Contact R ar o o o o o o o o o ? o - o o >Accept-Encoding 2xx >- - - ? o - - m* - - - o - o >Accept-Encoding 415 >- c - ? c m* o c c m* c c o c >Accept-Encoding R >- o - o o - o o o o o o o o >Accept-Language 2xx >- - - ? o - - m* - - - o - o >Accept-Language 415 >- c - ? c m* o c c m* c c o c >Accept-Language R >- o - o o - o o o o o o o o >Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o >Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o >Alert-Info 180 >- - - ? o - - - - ? ? - - ? >Alert-Info R >- - - ? o - - - - - - - - - >Alert-Info r >? ? ? ? ? ? ? ? ? - - ? ? - >Allow 2xx >- o - ? m* o o m* o ? ? o o o >Allow 405 >- m - o m m m m m m m m m m >Allow R >- o - ? o o o o o o ? o o o >Allow r >- o - ? o o o o o o ? o o o >Allow-Events 2xx >- o - ? o ? o o o ? ? o o ? >Allow-Events 489 >- - - ? - ? m - - m ? - m ? >Allow-Events R >o o - ? o ? o o o o ? o o - >Allow-Events r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Authentication-Info 2xx >- o - ? o o o o o o o o o o >Authorization R >o o o o o o o o o o o o o o >Call-ID c r m m m m m m m m m m m m m m >Call-Info R ar - - - ? o o ? o - o - o ? o >Call-Info r ar - - - ? o o ? o - o - o ? o >Contact 1xx >- - - - o - o - - - - - o o >Contact 2xx >- - - - m - o o - - m o m m >Contact 3xx >- o - - o o m o o o ? o m o >Contact 485 >- o - - o o o o o o ? o o o >Contact R >o - - o m - m o - - m o m m >Content-Disposition R >o o - ? o o o o o o o o o o >Content-Disposition r >o o - ? o o o o o o o o o o >Content-Encoding R >o o - o o o o o o o o o o o >Content-Encoding r >o o - o o o o o o o o o o o >Content-Language R >o o - ? o o o o o o o o o o >Content-Language r >o o - ? o o o o o o o o o o >Content-Length R ar t t t o t t t t t t o t t t >Content-Length r ar t t t o t t t t t t o t t t >Content-Type R >* * - * * * * * * * * * * * >Content-Type r >* * - * * * * * * * * * * * >CSeq c r m m m m m m m m m m m m m m >Date R a o o o o o o o o o o o o o o >Date r a o o o o o o o o o o o o o o >Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Error-Info 300-699 a - o o ? o o o o o o ? o o o >Event R >- - - ? - ? m - - m ? - m - >Event r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Expires R >- - - o o o - - - o o o o - >Expires r >- - - o o o - - - o ? o o - >Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > From c r m m m m m m m m m m m m m m >History-Info R amdr - - - - o o o o - o o o o - >History-Info r amdr - - - - o o o o - o o o o - >Identity R a o o - ? o ? ? o ? ? ? o ? ? >Identity-Info R a o o - ? o ? ? o ? ? ? o ? ? >In-Reply-To R >- - - ? o o - - - - - - - - >In-Reply-To r >? ? ? ? ? ? ? ? ? ? - ? ? - >Join R >- - - - o - - - - - - - - - >Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Max-Forwards R amr m m m o m m m m m m m m m m >MIME-Version R >o o - ? o ? o o o o o o o o >MIME-Version r >o o - ? o ? o o o o o o o o >Min-Expires 423 >- - - ? - ? - - - m ? m m ? >Min-Expires R >? ? ? ? ? ? ? ? ? ? - ? ? - >Min-Expires r >? ? ? ? ? ? ? ? ? ? - ? ? - >Min-SE 422 >- - - ? m ? - - - ? ? - - m >Min-SE R amr - - - ? o ? - - - ? ? - - o >Organization R ar - - - o o o - o - o o o o o >Organization r ar - - - o o o - o - o o o o o >P-Access-Network-Info R dr - o - o o o o o o ? o o o o >P-Access-Network-Info r dr - o - o o o o o o ? o o o o >P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ? >P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ? >P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ? >P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ? >P-Associated-URI 2xx >- - - ? - ? ? - ? ? ? o ? ? >P-Called-Party-ID R amr - - - - o o - o - ? o - o - >P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >P-Charging-Vector R admr - o - o o o o o o ? o o o o >P-Charging-Vector r admr - o - o o o o o o ? o o o o >P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ? >P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ? >P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ? >P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ? >P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ? >P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ? >P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ? >P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ? >P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? - >P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o >P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o >P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ? >P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o >P-Media-Authorization R ad o - - - o ? - - o ? ? - - o >P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ? >P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ? >P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >P-Visited-Network-ID R ad - - - - o o - o - ? o o o - >Path 2xx - - - - ? - ? ? - ? ? ? o ? ? >Path R ar - - - ? - ? ? - ? ? ? o ? ? >Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Priority R ar - - - o o o - - - o - - o - >Priority r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Privacy R amrd o o o ? o o o o ? ? ? o o o >Privacy r amrd o o o ? o o o o ? ? ? o o o >Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o >Proxy-Authenticate 407 ar - m - o m m m m m m m m m m >Proxy-Authorization R dr o o - o o o o o o o o o o o >RAck R >- - - ? - ? - - m ? ? - - - >Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Record-Route 18x mr - o o ? o ? ? o o ? o - ? o >Record-Route 2xx mr - o o o o ? o o o ? o - o o >Record-Route R ar o o o o o - o o o - o - o o >Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ? >Refer-Sub 2xx >- - - - - - - - - - o - - - >Refer-Sub R >- - - - - - - - - - o - - - >Refer-To R >- - - ? - ? ? - ? ? ? - ? ? >Referred-By R >- o - ? o ? ? o ? ? ? o ? ? >Reject-Contact R ar o o o o o o o o o ? o - o o >Replaces R >- - - - o - - - - - - - - - >Reply-To R >- - - ? o o - - - - - - - - >Reply-To r >- - - ? o o - - - - - - - - >Request-Disposition R ar o o o o o o o o o ? o o o o >Require R ar - c - o c c o c c o c c o c >Require r ar - c - ? c c o c c o c c o c >Resource-Priority R amdr o o o o o o o o o o o o o o >Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Retry-After 404 >- o o o o ? o o o o o o o o >Retry-After 413 >- o o ? o ? o o o o o o o o >Retry-After 480 >- o o o o ? o o o o o o o o >Retry-After 486 >- o o o o ? o o o o o o o o >Retry-After 4xx >? ? ? ? ? o ? ? ? ? ? ? ? ? >Route R adr c c c o c o c c c c c c c c >RSeq 1xx >- - - ? o ? o - - ? ? - o ? >RSeq R >? ? ? ? ? ? ? ? ? ? ? ? ? - >RSeq r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Security-Client R ard - o - ? o o o o ? ? ? o o o >Security-Server 421 >- o - ? o o o o ? ? ? o o o >Security-Server 494 >- o - ? o o o o ? ? ? o o o >Security-Verify R ard - o - ? o o o o ? ? ? o o o >Server r >- o o o o o o o o o o o o o >Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ? >Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o >Session-Expires R amr - - - ? o ? - - - ? ? - - o >SIP-ETag 2xx >- - - - - - - - - m - - - - >SIP-If-Match R >- - - - - - - - - o - - - - >Subject R >- - - o o o - - - o - - - - >Subject r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Subscription-State R >- - - ? - ? m - - ? ? - - - >Subscription-State r >? ? ? ? ? ? ? ? ? ? ? ? ? - >Supported 2xx >- o o ? m* ? o m* o o o o o o >Supported R >- o o ? m* ? o o o o o o o o >Target-Dialog R - - - - - o - - - - - o - o - >Timestamp R >o o o o o o o o o o o o o o >Timestamp r >o o o o o o o o o o o o o o >To c r m m m m m m m m m m m m m m >Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Unsupported 420 >- m - o m o o m m o o m o m >User-Agent R >o o o o o o o o o o o o o o >User-Agent r >o o o o o o o o o o o o o o >Via R amr m m m ? m m ? m ? m ? m ? m >Via rc dr m m m ? m m ? m ? m ? m ? m >Warning r >- o o o o o o o o o o o o o >WWW-Authenticate 401 ar - m - o m m m m m m m m m m >WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o > > >See all those question marks? Someone needs to come up with actual >values for each of those cells. Some are going to be pretty easy to >answer; others will require substantial research and/or debate. > >It seems like a lot of effort to me. Are we certain the return on >our investment of time will be worth it? > >/a > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Feb 24 10:46:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB9B3A8405 for ; Wed, 24 Feb 2010 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 VXT+32AEET3N for ; Wed, 24 Feb 2010 10:46:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3808E28B56A for ; Wed, 24 Feb 2010 10:46:17 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-f9-4b8574780fd9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id FB.B2.01038.874758B4; Wed, 24 Feb 2010 19:48:24 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Feb 2010 19:48:23 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 24 Feb 2010 19:48:22 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq1YWWsbYuGBy87QIG8chc+i6s2XQAH9Lpw Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> <4B853D9C.1010109@cisco.com> In-Reply-To: <4B853D9C.1010109@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 18:46:19 -0000 Hi,=20 >It is already permissible for a proxy to do as you suggest - return a 300 = with multiple=20 >contacts, and include the feature tags that were provided at registration. > >The question would be whether to somehow make this mandatory. That is one option. I have also been thinking about an alternative whether the proxy could make= the decission whether to send a 300 response, or fork the OPTIONS towards = the UAS(s), based on the=20 information received in the OPTIONS request. But, I will indicate that as a separate issue. Regards, Christer Christer Holmberg wrote: > Hi, >=20 > Unless someone objects, I think we can drop the alternative where the pro= xy would include SDP for the UASs, because that could cause message size i= ssues etc... If an UAC wants to get such information, it needs to send an O= PTIONS request addressed to the actual UAS. >=20 > Dean suggested that the proxy returns the gruus of the UASs. But, as I sa= id earlier, I still think we should consider whether the proxy could return= the registered feature tags of the UASs, together with the gruus, since th= e proxy has that information.=20 >=20 > In fact, I believe that could help getting people to implement callerpref= s (and gruu), because it would be a use-case where it is really good to do = so. >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 23. helmikuuta 2010 18:11 > To: Adam Roach > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? >=20 > Adam, >=20 > Maybe the thread has branched too much to follow. >=20 > I was contrasting two things, one by Dean and the other by Christer. > I agree with you re Dean's. >=20 > The alternative proposal was for the "proxy" to answer on behalf of the r= egistered endpoints, with an aggregate response. Exactly what that aggregat= e response would look like is not clear. At one point I had suggested that = the "proxy" could send its own OPTIONS requests to the endpoints. If so, an= d if their responses contained SDP, then an aggregate response might requir= e a multipart. >=20 > The Dean suggestion is by far the better one. >=20 > Thanks, > Paul >=20 > Adam Roach wrote: >> On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >>> >>> Hans Erik van Elburg wrote: >>>> Agreed. Of course a proxy equiped with such policy can do that. It=20 >>>> is kind of a domain specific service. >>>> For that you do not have to bend the interpretation of the original >>>> RFC3261 text. >>>> >>>> If you use the 302 approach proposed by Dean, then do you need to=20 >>>> do anything specification wise? >>> No. Its entirely above board. >>> >>> Having the proxy respond on behalf of the endpoints may or may not=20 >>> be entirely conforming, depending on how it responds. >> That's not how I read Dean's proposal. The "Proxy/Registrar" isn't=20 >> responding on behalf of the UAs. It's letting the UAC know where to=20 >> find all the registered UAs. >> >> What I see Dean proposing is something like this: >> >> Dean Registrar Adam 1 Adam 2 Adam 3 >> | | | | | >> |OPTIONS | | | | >> |-------->| | | | >> | | | | | >> |302 | | | | >> |Contact: sip:adam1.example.com | >> |Contact: sip:adam2.example.com | >> |Contact: sip:adam3.example.com | >> |<--------| | | | >> | | | | | >> |OPTIONS | | | | >> |------------------>| | | >> |200 | | | | >> |<------------------| | | >> | | | | | >> |OPTIONS | | | | >> |---------------------------->| | >> |200 | | | | >> |<----------------------------| | >> | | | | | >> |OPTIONS | | | | >> |-------------------------------------->| >> |200 | | | | >> |<--------------------------------------| >> >> Perfectly above board, normal handling. Keep in mind that the=20 >> Registrar can stay in the path by returning GRUUs instead of contacts=20 >> that go directly to the UAs. It all works just fine either way. >> >> /a >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Wed Feb 24 10:51:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE0F28C204 for ; Wed, 24 Feb 2010 10:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 sXfVUtH8cwLy for ; Wed, 24 Feb 2010 10:51:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A5DDA28C17A for ; Wed, 24 Feb 2010 10:50:56 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-41-4b85758e6b25 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BA.03.01038.E85758B4; Wed, 24 Feb 2010 19:53:02 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Feb 2010 19:53:02 +0100 From: Christer Holmberg To: 'Dale Worley' , Paul Kyzivat Date: Wed, 24 Feb 2010 19:53:00 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq1aoP32V+A/74vTSCkRBIz4n1fnAAF34lA Message-ID: References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> <1266950578.10428.13.camel@khone.us.nortel.com> In-Reply-To: <1266950578.10428.13.camel@khone.us.nortel.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 18:51:01 -0000 Hi Dale,=20 >> None of this matters, because for non-invite transactions the UAC's=20 >> state machine is going to be done when the first final response is=20 >> received. It isn't going to be prepared to handle other 200 responses=20 >> to the same transaction. > >If "Request-Disposition: no-cancel" is to have any sensible effect, it mea= ns that "stray" 200=20 >responses will be forwarded upstream, as they would for an INVITE. RFC 38= 41 is explicit that=20 >Request-Disposition can be used on non-INVITE requests. Just because the header field is applicable, it doesn't mean all parameters= are :) But, as I asked earlier: when would the UAC cease the re-transmission of th= e OPTIONS request (or, any request for which no ACK is to be sent)? Regards, Chris Dale From christer.holmberg@ericsson.com Wed Feb 24 11:04:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7AB3A855A for ; Wed, 24 Feb 2010 11:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 zV-oMYSnOaxc for ; Wed, 24 Feb 2010 11:04:35 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D4EFD3A8555 for ; Wed, 24 Feb 2010 11:04:34 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-07-4b8578c03f9a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 19.30.31641.0C8758B4; Wed, 24 Feb 2010 20:06:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Feb 2010 20:06:40 +0100 From: Christer Holmberg To: 'Dale Worley' Date: Wed, 24 Feb 2010 20:06:39 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq1asYFsaU4XJzEQravzUdmkW0qYAAGFJ7Q Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <1266950308.10428.9.camel@khone.us.nortel.com> In-Reply-To: <1266950308.10428.9.camel@khone.us.nortel.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 19:04:36 -0000 Hi,=20 >>I want to query the UAs registered to the AOR. > >In which case, you don't want to send a request "to" the AOR, as it may we= ll get forwarded to=20 >various other places. What you really want is the reg event package for t= he AOR, and then=20 >you can query the registered contacts. Sure, if you don't care about call setup times, number of messages etc :) >That appears to be insecure, but your intention is to get information abou= t the capabilities=20 >of every registered contact, and any method that lets you do so pretty muc= h tells what the=20 >contacts are. (And if it doesn't directly, properly constructed INVITEs t= hat reach exactly=20 >one contact will eventually reveal the contact addresses of all of them.) If we are going to document (e.g. in a BCP) different ways of retrieving th= e capabilities I guess this mechanism could also be docuumented. I guess th= ere is currently nothing which prevents it? Regards, Christer From adam@nostrum.com Wed Feb 24 13:26:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0413A85C4 for ; Wed, 24 Feb 2010 13:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, 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 x4+q2Ni5VXwH for ; Wed, 24 Feb 2010 13:26:40 -0800 (PST) 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 2B7223A6884 for ; Wed, 24 Feb 2010 13:26:39 -0800 (PST) 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 o1OLSiaV075989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 15:28:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B859A0C.1060803@nostrum.com> Date: Wed, 24 Feb 2010 15:28:44 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "James M. Polk" References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> In-Reply-To: <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 21:26:41 -0000 On 2/24/10 11:46 AM, James M. Polk wrote: > Thanks for doing this script. Is it posted anywhere (perhaps on the > SIPCORE site)? With the caveat that it is a completely unstructured mound of esoteric and hacked-together perl that I threw together in quite a hurry -- and is subsequently in the "write only" category of code readability -- you can grab a copy here: https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.pl You'll need to update the "$rfc_dir" variable at the top of the script to reflect your local copy of the RFC repository. If you don't have a local copy of the RFC repository, you can get one quite easily with rsync; on any Unix-like operating system (including Cygwin under Windows): mkdir -p rfcs; rsync -avz --exclude tar ftp.rfc-editor.org::rfcs-text-only rfcs > One point that will cause you a little more work in your script, when > loading this on a webpage, if you could add the specific reference > RFCs to the right of the columns where each header is defined > (including updates perhaps) -- this would help. I know some are > obvious, while others are not to readers/researchers. I've added title attributes to each data element. This allows you to hover your mouse over anything in the table to find out where it came from. The revised HTML table is here: https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html If we decide to actually do this work, that probably won't be the final resting place -- but it's a convenient place for me to put it for now. /a From christer.holmberg@ericsson.com Wed Feb 24 13:56:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAB828C0E1 for ; Wed, 24 Feb 2010 13:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 Sln4X9G2MGMs for ; Wed, 24 Feb 2010 13:56:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 91AD63A8454 for ; Wed, 24 Feb 2010 13:56:06 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-7b-4b85a0f4c66b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 17.29.31641.4F0A58B4; Wed, 24 Feb 2010 22:58:13 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Feb 2010 22:58:11 +0100 From: Christer Holmberg To: Christer Holmberg , 'Paul Kyzivat' Date: Wed, 24 Feb 2010 22:58:10 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq1YWWsbYuGBy87QIG8chc+i6s2XQAH9LpwAAbAPyA= Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> <4B853D9C.1010109@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 21:56:08 -0000 Of course, if the contacts in the 300 response contains feature tags, the U= AC needs to remove those before sending an OPTIONS request addressed to the= contact. Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 24. helmikuuta 2010 20:48 To: 'Paul Kyzivat' Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? Hi,=20 >It is already permissible for a proxy to do as you suggest - return a=20 >300 with multiple contacts, and include the feature tags that were provide= d at registration. > >The question would be whether to somehow make this mandatory. That is one option. I have also been thinking about an alternative whether the proxy could make= the decission whether to send a 300 response, or fork the OPTIONS towards = the UAS(s), based on the information received in the OPTIONS request. But, I will indicate that as a separate issue. Regards, Christer Christer Holmberg wrote: > Hi, >=20 > Unless someone objects, I think we can drop the alternative where the pro= xy would include SDP for the UASs, because that could cause message size i= ssues etc... If an UAC wants to get such information, it needs to send an O= PTIONS request addressed to the actual UAS. >=20 > Dean suggested that the proxy returns the gruus of the UASs. But, as I sa= id earlier, I still think we should consider whether the proxy could return= the registered feature tags of the UASs, together with the gruus, since th= e proxy has that information.=20 >=20 > In fact, I believe that could help getting people to implement callerpref= s (and gruu), because it would be a use-case where it is really good to do = so. >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 23. helmikuuta 2010 18:11 > To: Adam Roach > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? >=20 > Adam, >=20 > Maybe the thread has branched too much to follow. >=20 > I was contrasting two things, one by Dean and the other by Christer. > I agree with you re Dean's. >=20 > The alternative proposal was for the "proxy" to answer on behalf of the r= egistered endpoints, with an aggregate response. Exactly what that aggregat= e response would look like is not clear. At one point I had suggested that = the "proxy" could send its own OPTIONS requests to the endpoints. If so, an= d if their responses contained SDP, then an aggregate response might requir= e a multipart. >=20 > The Dean suggestion is by far the better one. >=20 > Thanks, > Paul >=20 > Adam Roach wrote: >> On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >>> >>> Hans Erik van Elburg wrote: >>>> Agreed. Of course a proxy equiped with such policy can do that. It=20 >>>> is kind of a domain specific service. >>>> For that you do not have to bend the interpretation of the original >>>> RFC3261 text. >>>> >>>> If you use the 302 approach proposed by Dean, then do you need to=20 >>>> do anything specification wise? >>> No. Its entirely above board. >>> >>> Having the proxy respond on behalf of the endpoints may or may not=20 >>> be entirely conforming, depending on how it responds. >> That's not how I read Dean's proposal. The "Proxy/Registrar" isn't=20 >> responding on behalf of the UAs. It's letting the UAC know where to=20 >> find all the registered UAs. >> >> What I see Dean proposing is something like this: >> >> Dean Registrar Adam 1 Adam 2 Adam 3 >> | | | | | >> |OPTIONS | | | | >> |-------->| | | | >> | | | | | >> |302 | | | | >> |Contact: sip:adam1.example.com | >> |Contact: sip:adam2.example.com | >> |Contact: sip:adam3.example.com | >> |<--------| | | | >> | | | | | >> |OPTIONS | | | | >> |------------------>| | | >> |200 | | | | >> |<------------------| | | >> | | | | | >> |OPTIONS | | | | >> |---------------------------->| | >> |200 | | | | >> |<----------------------------| | >> | | | | | >> |OPTIONS | | | | >> |-------------------------------------->| >> |200 | | | | >> |<--------------------------------------| >> >> Perfectly above board, normal handling. Keep in mind that the=20 >> Registrar can stay in the path by returning GRUUs instead of contacts=20 >> that go directly to the UAs. It all works just fine either way. >> >> /a >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Feb 24 14:07:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625473A85DB for ; Wed, 24 Feb 2010 14:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 yTzPi68C3qLn for ; Wed, 24 Feb 2010 14:07:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5A9043A85DE for ; Wed, 24 Feb 2010 14:07:07 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-7f-4b85a3896e72 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8F.8D.01038.983A58B4; Wed, 24 Feb 2010 23:09:14 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Feb 2010 23:09:12 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Adam Roach Date: Wed, 24 Feb 2010 23:09:12 +0100 Thread-Topic: [sipcore] 3265bis and Call-Info Thread-Index: Acq1YG3yBmqqLCc5RW2+5qhpjSm1TgAPSAHg Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A129.2010705@nostrum.com> <4B853C37.6040706@cisco.com> In-Reply-To: <4B853C37.6040706@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:07:09 -0000 Hi, I think we should try to solve the question marks, and I am willing to help= in such exercise. We would need to discuss how we set up and divide the wo= rk. For some of the headers, I think the question marks can be solved by readin= g the specs where they are defined. For example, I think it is rather clear= where RSeq and RAck can be used. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 24. helmikuuta 2010 16:48 To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] 3265bis and Call-Info Adam Roach wrote: > See all those question marks? Someone needs to come up with actual=20 > values for each of those cells. Some are going to be pretty easy to=20 > answer; others will require substantial research and/or debate. >=20 > It seems like a lot of effort to me. Are we certain the return on our=20 > investment of time will be worth it? Isn't it the case that every implementor also has to figure out those quest= ion marks? (And how consistent are the results when they do so?) If the answers for each of those question marks aren't easy to find, then d= oesn't that make it even more important to find them? If they can't each be= defined by citing a particular document and section, then I suspect some n= ew normative document will be required to nail them down. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Feb 24 14:10:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDB83A85EC for ; Wed, 24 Feb 2010 14:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 V1QGtl+sN8dP for ; Wed, 24 Feb 2010 14:10:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7FF093A85E6 for ; Wed, 24 Feb 2010 14:10:00 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-57-4b85a4370452 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6B.E9.31641.734A58B4; Wed, 24 Feb 2010 23:12:07 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 24 Feb 2010 23:12:07 +0100 From: Christer Holmberg To: 'Adam Roach' , "James M. Polk" Date: Wed, 24 Feb 2010 23:12:06 +0100 Thread-Topic: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) Thread-Index: Acq1mFztlUZCEEbrQQ+aDynrGdAFOgABerVg Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> In-Reply-To: <4B859A0C.1060803@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:10:05 -0000 Sent the reply below using the old subject, so re-sending it here: I think we should try to solve the question marks, and I am willing to help= in such exercise. We would need to discuss how we set up and divide the wo= rk. For some of the headers, I think the question marks can be solved by readin= g the specs where they are defined. For example, I think it is rather clear= where RSeq and RAck can be used. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 24. helmikuuta 2010 23:29 To: James M. Polk Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) On 2/24/10 11:46 AM, James M. Polk wrote: > Thanks for doing this script. Is it posted anywhere (perhaps on the=20 > SIPCORE site)? With the caveat that it is a completely unstructured mound of esoteric and = hacked-together perl that I threw together in quite a hurry -- and is subse= quently in the "write only" category of code readability -- you can grab a = copy here: https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.pl You'll need to update the "$rfc_dir" variable at the top of the script to r= eflect your local copy of the RFC repository. If you don't have a local cop= y of the RFC repository, you can get one quite easily with rsync; on any Un= ix-like operating system (including Cygwin under Windows): mkdir -p rfcs; rsync -avz --exclude tar ftp.rfc-editor.org::rfcs-text-on= ly rfcs > One point that will cause you a little more work in your script, when=20 > loading this on a webpage, if you could add the specific reference=20 > RFCs to the right of the columns where each header is defined=20 > (including updates perhaps) -- this would help. I know some are=20 > obvious, while others are not to readers/researchers. I've added title attributes to each data element. This allows you to hover = your mouse over anything in the table to find out where it came from. The r= evised HTML table is here: https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html If we decide to actually do this work, that probably won't be the final res= ting place -- but it's a convenient place for me to put it for now. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Feb 24 14:14:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8ED3A85F0 for ; Wed, 24 Feb 2010 14:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 l5ZD2AEu0SRh for ; Wed, 24 Feb 2010 14:14:26 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 169DB3A85E9 for ; Wed, 24 Feb 2010 14:14:26 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALgzhUtAZnwN/2dsb2JhbACbEnOja5hChHIEgxY X-IronPort-AV: E=Sophos;i="4.49,534,1262563200"; d="scan'208";a="302605658" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2010 22:16:33 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1OMGX2m023872; Wed, 24 Feb 2010 22:16:33 GMT Message-ID: <4B85A541.2050306@cisco.com> Date: Wed, 24 Feb 2010 17:16:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> <4B853D9C.1010109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:14:27 -0000 Christer Holmberg wrote: > Of course, if the contacts in the 300 response contains feature tags, the UAC needs to remove those before sending an OPTIONS request addressed to the contact. Of course. Its only the URI from the Contact header that is used in the request. The feature tags are header params, not URI params, so they will be left behind when extracting the URI. Paul > Regards, > > Christer > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24. helmikuuta 2010 20:48 > To: 'Paul Kyzivat' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? > > > Hi, > >> It is already permissible for a proxy to do as you suggest - return a >> 300 with multiple contacts, and include the feature tags that were provided at registration. >> >> The question would be whether to somehow make this mandatory. > > That is one option. > > I have also been thinking about an alternative whether the proxy could make the decission whether to send a 300 response, or fork the OPTIONS towards the UAS(s), based on the information received in the OPTIONS request. > > But, I will indicate that as a separate issue. > > Regards, > > Christer > > > Christer Holmberg wrote: >> Hi, >> >> Unless someone objects, I think we can drop the alternative where the proxy would include SDP for the UASs, because that could cause message size issues etc... If an UAC wants to get such information, it needs to send an OPTIONS request addressed to the actual UAS. >> >> Dean suggested that the proxy returns the gruus of the UASs. But, as I said earlier, I still think we should consider whether the proxy could return the registered feature tags of the UASs, together with the gruus, since the proxy has that information. >> >> In fact, I believe that could help getting people to implement callerprefs (and gruu), because it would be a use-case where it is really good to do so. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 23. helmikuuta 2010 18:11 >> To: Adam Roach >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? >> >> Adam, >> >> Maybe the thread has branched too much to follow. >> >> I was contrasting two things, one by Dean and the other by Christer. >> I agree with you re Dean's. >> >> The alternative proposal was for the "proxy" to answer on behalf of the registered endpoints, with an aggregate response. Exactly what that aggregate response would look like is not clear. At one point I had suggested that the "proxy" could send its own OPTIONS requests to the endpoints. If so, and if their responses contained SDP, then an aggregate response might require a multipart. >> >> The Dean suggestion is by far the better one. >> >> Thanks, >> Paul >> >> Adam Roach wrote: >>> On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >>>> Hans Erik van Elburg wrote: >>>>> Agreed. Of course a proxy equiped with such policy can do that. It >>>>> is kind of a domain specific service. >>>>> For that you do not have to bend the interpretation of the original >>>>> RFC3261 text. >>>>> >>>>> If you use the 302 approach proposed by Dean, then do you need to >>>>> do anything specification wise? >>>> No. Its entirely above board. >>>> >>>> Having the proxy respond on behalf of the endpoints may or may not >>>> be entirely conforming, depending on how it responds. >>> That's not how I read Dean's proposal. The "Proxy/Registrar" isn't >>> responding on behalf of the UAs. It's letting the UAC know where to >>> find all the registered UAs. >>> >>> What I see Dean proposing is something like this: >>> >>> Dean Registrar Adam 1 Adam 2 Adam 3 >>> | | | | | >>> |OPTIONS | | | | >>> |-------->| | | | >>> | | | | | >>> |302 | | | | >>> |Contact: sip:adam1.example.com | >>> |Contact: sip:adam2.example.com | >>> |Contact: sip:adam3.example.com | >>> |<--------| | | | >>> | | | | | >>> |OPTIONS | | | | >>> |------------------>| | | >>> |200 | | | | >>> |<------------------| | | >>> | | | | | >>> |OPTIONS | | | | >>> |---------------------------->| | >>> |200 | | | | >>> |<----------------------------| | >>> | | | | | >>> |OPTIONS | | | | >>> |-------------------------------------->| >>> |200 | | | | >>> |<--------------------------------------| >>> >>> Perfectly above board, normal handling. Keep in mind that the >>> Registrar can stay in the path by returning GRUUs instead of contacts >>> that go directly to the UAs. It all works just fine either way. >>> >>> /a >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Feb 24 14:20:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA48128C25E for ; Wed, 24 Feb 2010 14:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 oWI4mXAvRBnS for ; Wed, 24 Feb 2010 14:20:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 40A3028C1AB for ; Wed, 24 Feb 2010 14:20:21 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-ea-4b85a6a4d984 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8B.4E.01038.4A6A58B4; Wed, 24 Feb 2010 23:22:28 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 24 Feb 2010 23:22:27 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 24 Feb 2010 23:22:26 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq1nwgT/+wZR6TCQn+UJ1Cefu/CXgAAMrBw Message-ID: References: <1266859994.3760.25.camel@khone.us.nortel.com> <4B82C4BE.3090303@cisco.com> <4B82D38B.1090601@ericsson.com> <4B82E63D.6020603@gmail.com> <9ae56b1e1002230057m2f7ad7c1n1331e52b8441cc34@mail.gmail.com> <4B83E5B5.1000504@cisco.com> <4B83FBB4.40208@nostrum.com> <4B83FE28.2010503@cisco.com> <4B853D9C.1010109@cisco.com> <4B85A541.2050306@cisco.com> In-Reply-To: <4B85A541.2050306@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:20:23 -0000 True.=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 25. helmikuuta 2010 0:17 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? Christer Holmberg wrote: > Of course, if the contacts in the 300 response contains feature tags, the= UAC needs to remove those before sending an OPTIONS request addressed to t= he contact. Of course. Its only the URI from the Contact header that is used in the req= uest. The feature tags are header params, not URI params, so they will be l= eft behind when extracting the URI. Paul > Regards, >=20 > Christer >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: 24. helmikuuta 2010 20:48 > To: 'Paul Kyzivat' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? >=20 >=20 > Hi, >=20 >> It is already permissible for a proxy to do as you suggest - return a=20 >> 300 with multiple contacts, and include the feature tags that were provi= ded at registration. >> >> The question would be whether to somehow make this mandatory. >=20 > That is one option. >=20 > I have also been thinking about an alternative whether the proxy could ma= ke the decission whether to send a 300 response, or fork the OPTIONS toward= s the UAS(s), based on the information received in the OPTIONS request. >=20 > But, I will indicate that as a separate issue. >=20 > Regards, >=20 > Christer >=20 >=20 > Christer Holmberg wrote: >> Hi, >> >> Unless someone objects, I think we can drop the alternative where the pr= oxy would include SDP for the UASs, because that could cause message size = issues etc... If an UAC wants to get such information, it needs to send an = OPTIONS request addressed to the actual UAS. >> >> Dean suggested that the proxy returns the gruus of the UASs. But, as I s= aid earlier, I still think we should consider whether the proxy could retur= n the registered feature tags of the UASs, together with the gruus, since t= he proxy has that information.=20 >> >> In fact, I believe that could help getting people to implement callerpre= fs (and gruu), because it would be a use-case where it is really good to do= so. >> >> Regards, >> >> Christer >> >> >> =20 >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 23. helmikuuta 2010 18:11 >> To: Adam Roach >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? >> >> Adam, >> >> Maybe the thread has branched too much to follow. >> >> I was contrasting two things, one by Dean and the other by Christer. >> I agree with you re Dean's. >> >> The alternative proposal was for the "proxy" to answer on behalf of the = registered endpoints, with an aggregate response. Exactly what that aggrega= te response would look like is not clear. At one point I had suggested that= the "proxy" could send its own OPTIONS requests to the endpoints. If so, a= nd if their responses contained SDP, then an aggregate response might requi= re a multipart. >> >> The Dean suggestion is by far the better one. >> >> Thanks, >> Paul >> >> Adam Roach wrote: >>> On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote: >>>> Hans Erik van Elburg wrote: >>>>> Agreed. Of course a proxy equiped with such policy can do that. It=20 >>>>> is kind of a domain specific service. >>>>> For that you do not have to bend the interpretation of the=20 >>>>> original >>>>> RFC3261 text. >>>>> >>>>> If you use the 302 approach proposed by Dean, then do you need to=20 >>>>> do anything specification wise? >>>> No. Its entirely above board. >>>> >>>> Having the proxy respond on behalf of the endpoints may or may not=20 >>>> be entirely conforming, depending on how it responds. >>> That's not how I read Dean's proposal. The "Proxy/Registrar" isn't=20 >>> responding on behalf of the UAs. It's letting the UAC know where to=20 >>> find all the registered UAs. >>> >>> What I see Dean proposing is something like this: >>> >>> Dean Registrar Adam 1 Adam 2 Adam 3 >>> | | | | | >>> |OPTIONS | | | | >>> |-------->| | | | >>> | | | | | >>> |302 | | | | >>> |Contact: sip:adam1.example.com | >>> |Contact: sip:adam2.example.com | >>> |Contact: sip:adam3.example.com | >>> |<--------| | | | >>> | | | | | >>> |OPTIONS | | | | >>> |------------------>| | | >>> |200 | | | | >>> |<------------------| | | >>> | | | | | >>> |OPTIONS | | | | >>> |---------------------------->| | >>> |200 | | | | >>> |<----------------------------| | >>> | | | | | >>> |OPTIONS | | | | >>> |-------------------------------------->| >>> |200 | | | | >>> |<--------------------------------------| >>> >>> Perfectly above board, normal handling. Keep in mind that the=20 >>> Registrar can stay in the path by returning GRUUs instead of=20 >>> contacts that go directly to the UAs. It all works just fine either way= . >>> >>> /a >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Wed Feb 24 14:43:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD973A85D1 for ; Wed, 24 Feb 2010 14:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 qV0jb3R1aHfx for ; Wed, 24 Feb 2010 14:43:35 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 62A613A68ED for ; Wed, 24 Feb 2010 14:43:35 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-12-4b85ac16f58f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 91.9F.01038.61CA58B4; Wed, 24 Feb 2010 23:45:42 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 24 Feb 2010 23:45:42 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "Elwell, John" Date: Wed, 24 Feb 2010 23:45:41 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: AcqxcT2ilJ4fyLSbROWbszcCwfntIABwGxPgAJxNDrA= Message-ID: References: <4B7E9EAD.20201@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:43:37 -0000 Hi, I am trying to collect issues which are unclear regarding OPTIONS. Some issues a described below, but if you are aware of others please let me= know. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 21. helmikuuta 2010 22:28 To: 'Paul Kyzivat'; Elwell, John Cc: SIPCORE Subject: [sipcore] OPTIONS: What does it mean? ( was: OPTIONS: How to solve= the forking problem?) =20 Hi Paul, >IMO there is no point in doing anything unless there is also work to=20 >clarify what the response *means* in a way that is operationally useful. I agree with you 100%.. The issue you raise is the other issue related to OPTIONS. Unfortunaly I di= dn't have time to send out an e-mail about that. And, the what-does-it-mean issue needs to be solved no matter what we do wi= th the forking issue, so I guess I should have sent out an e-mail about tha= t first (I guess my thinking was that if the 2nd forking alternative is alr= eady allowed, we wouldn't need to spend so much time discussng that). >Even when there is only one UA and the OPTIONS request is getting to=20 >it, the result isn't especially useful, except as a "ping" because: > >- nominally the response code is supposed to be the same as > it would be for an INVITE. I guess that means you should get > a 486 response if the UA is on a call and would reject another. > But what if the UA *never* accepts INVITES - only SUBSCRIBE? > Should you get 405? When the OPTIONS text was written, we didn't have SUBSCRIBE, so we need to = agree whether we should be talking about "returning the capabilities at thi= s moment", instead of "what would the INVITE response be at this moment". So, yes, that is one issue. >- If the UA can in principle support a lot of things, but not > all in the same call, there is no well defined way to reflect that. True. I would assume that it should be made clear that OPTIONS is about ret= urning capabilities in general, and that there is no guarantee that everyth= ing will be available for a particutlar call.=20 Another issue is related to the usage of feature tags. RFC 3841 says that a= UAS can perform feature tag matching when receiving a request, and reject = a request if it doesn't support required feature tags. I guess that is fine= for INVITE, but do we want to have that kind of behavior for OPTIONS also? >I would like to see a set of use cases for how people would like to use=20 >OPTIONS where this enhancement is needed. I will talk about that in the forking issue thread. So, talking about the specific what-does-it-mean issue: do people have an i= nterest in trying to solve that? Thanks! Regards, Christer Elwell, John wrote: > =20 >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 19 February 2010 11:28 >> To: SIPCORE >> Subject: [sipcore] OPTIONS: How to solve the forking problem? >> >> Hi, >> =20 >> Some input regarding the OPTIONS issue. >> =20 >> BACKGROUND: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> One of the main problems with OPTIONS is forking. In case the request=20 >> is forked, the UAC will only receive the capabilities of one=20 >> device/UAS (which UAS depends on which 200 OK reaches the forking=20 >> proxy first). >> =20 >> OPTIONS works fine in HTTP, where we don't have forking and an HTTP=20 >> URI always identify uniquely a specific resource or a specific=20 >> server. >> =20 >> But, if I address the request to an AOR (which points to a domain,=20 >> not to a specific device) I might want to receive capabilities of all=20 >> the UAS associated with that AOR/domain. >> =20 >> First, do we agree that is a valid usage to address OPTIONS to an=20 >> AOR? >> =20 >> OR, do we think that OPTIONS should only be addressed to specific=20 >> devices (section 11 of 3261 talks about devices), in which case I=20 >> guess we don't need to do anything - at least not as far as forking=20 >> is concerned. >> =20 >> The rest of this e-mail is based on the assumption that we DO want to=20 >> be able to address OPTIONS to an AOR. >> =20 >> =20 >> ABSTRACT: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> I have put together 3 alternative solutions on how the problem could=20 >> be fixed. The first alternative is based on a UAS change, while the=20 >> second and third alternatives are based on a model where the=20 >> registrar (forking proxy) sends a response "on behalf" of the UAS(s). >> =20 >> The 4th alternative is of course that we do nothing, but based on=20 >> previous discussions it does seem that some people are interested in=20 >> doing something about OPTIONS. >> =20 >> =20 >> ALTERNATIVE 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> In this alternative the UAS(s) send a provisional response, including=20 >> the capabilities, to the OPTIONS request. The registrar will >> (hopefully) forward all the provisional responses towards the UAC. >> =20 >> Pros/cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. >> + No impacts on registrar >> =20 >> - Does not work with deployed Uas >> - Would the provisional response need to be PRACKed? > [JRE] I hope this Alternative 1 is not meant to be serious. This would be= contrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisiona= l response for a non-INVITE request". I wonder how many SIP stacks would ha= ndle this. Also, having sent a provisional response, the UAS needs to send = a final response, so how would this interact? >=20 >> =20 >> What to do: >> ----------------- >> =20 >> This alternative would most likely require an RFC: either an=20 >> extension with an associated option-tag, or an update to 3261. >> =20 >> =20 >> =20 >> ALTERNATIVE 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> In this alternative the registrar never forks the OPTIONS request=20 >> towards the UAS(s). Instead, it sends a response on behalf of the=20 >> UASs, based on the information is has about the UAS(s), based on=20 >> registration information (feature tags etc) etc. >> =20 >> The first question is whether 3261 already allows this: >> =20 >> When a UAC sends an OPTIONS request addressed to an AOR, I expect to=20 >> get capabilities associated with that AOR (which points to a domain,=20 >> not to a specific device). Currently, in case of forking, I will only=20 >> get the capabilities from one device/UAS associated with that domain. >> =20 >> But, if the registrar sends the OPTIONS response, it can provide=20 >> capabilities of all registered UAS(s) associated with the AOR/domain. >> =20 >> So, so far I don't think 3261 forbids this kind of behavior (in fact,=20 >> I think this kind of behavior actually better implements what is=20 >> described in 3261...) >> =20 >> =20 >> Now, the best way to return the capabilities would probably be by=20 >> using a message body, e.g. a multipart with sipfrag body parts (each=20 >> sipfrag body part representing a UAS). > [JRE] And that sipfrag body part would need to contain an SDP body part t= o represent the SDP capabilities of the UAS? This would make responses pote= ntially very large, posing a problem for UDP. It is probably a more extreme= example than anything we have had before of a response being VERY MUCH lar= ger than a request. >=20 >> =20 >> But, RFC3261 says that a proxy does not insert a message body in the=20 >> OPTIONS response, and that is probably ok in most cases when the=20 >> proxy returns its owns capabilities. But, when the proxy replies on=20 >> behalf of the UAS(s), I see no reason why it should not be allowed to=20 >> include a body. The UAC will get the capabilities of the UAS(s), and=20 >> that is what matters. > [JRE] In this case what you call the proxy is the UAS w.r.t. this particu= lar transaction, so it can include a body. >=20 >> =20 >> Pros/cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s) associated with the AOR. > [JRE] I am not sure what it needs this for, but we have the reg-event pac= kage to identify all registered Uas, and then OPTIONS could be directed at = each in turn. >=20 >> + In my personal opinion this does not require any changes in RFC3261 >> =20 >> - The set of capabilities per UAS is limited to what the registrar=20 >> knows about the UAS (based on registration information, and/or by=20 >> provisioning), so SDP information would probably be left out. The=20 >> mechanism might still be good enough for many scenarios, though. >> =20 >> What to do: >> ----------------- >> =20 >> If we think RFC3261 allows this, the question is whether we consider=20 >> it so crystal clear that nothing needs to be specified, or whether it=20 >> would be a good idea to put together a BCP type-of document=20 >> describing it. >> =20 >> Or, do people think that this is NOT allowed behavior? > [JRE] Even if allowed, I think we might need some specification of the si= pfrag part of it, and I am concerned about the response size. But I am not = convinced there is a requirement to be able to use OPTIONS to get informati= on about multiple UAs at once. >=20 >> =20 >> =20 >> =20 >> =20 >> ALTERNATIVE 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> The idea is similar to Alternative 1, but in this case the registrar=20 >> would fork the OPTIONS request towards the UAS(s), then "COLLECT" the=20 >> responses, and finally send a single response which contains the=20 >> capabilities of all UAS(s) towards the UAC. > [JRE] Again using sipfrags? >=20 >> =20 >> Prox/Cons: >> ---------------- >> =20 >> + The major advantage of this mechanism is that it allows the >> UAC to get the capabilities of all UAS(s). >> + The UAC will get more or less the same set of capabilities >> for an UAS, as if the UAS would have sent the response directly to=20 >> the UAC. >> =20 >> - I guess most people would consider the forking proxy acting as a=20 >> B2BUA in this case, since it does not follow the 3261 rules about=20 >> forwarding (or discarding) 200 OK responses immediately when=20 >> received. >> =20 >> What to do: >> ----------------- >> =20 >> If we think this is a good solution, could it be described in a BCP?=20 >> I guess we would not update 3261 to describe this behavior? > [JRE] Again we would need to specify the sipfrag bits of it, and I would = be concerned about the response size. >=20 > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Feb 24 14:53:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C253A8588 for ; Wed, 24 Feb 2010 14:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Uyp8Smn21m50 for ; Wed, 24 Feb 2010 14:53:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 29DA73A8279 for ; Wed, 24 Feb 2010 14:53:06 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJs8hUtAZnwN/2dsb2JhbACbE3OjbJhChHIEgxY X-IronPort-AV: E=Sophos;i="4.49,534,1262563200"; d="scan'208";a="88614135" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2010 22:55:13 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1OMtDHD004380; Wed, 24 Feb 2010 22:55:13 GMT Message-ID: <4B85AE51.5070603@cisco.com> Date: Wed, 24 Feb 2010 17:55:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7E9EAD.20201@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:53:07 -0000 Christer Holmberg wrote: > Another issue is related to the usage of feature tags. RFC 3841 says that a UAS can perform feature tag matching when receiving a request, and reject a request if it doesn't support required feature tags. I guess that is fine for INVITE, but do we want to have that kind of behavior for OPTIONS also? I don't see an issue here. The callerprefs stuff is independent of method. If you don't want callerprefs applied to your OPTIONS request, don't put any callerprefs into the OPTIONS message. If they are present, then I would expect them to be honored to the same extent (optional) that they are ever honored. Thanks, Paul From pkyzivat@cisco.com Wed Feb 24 15:01:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715483A8279 for ; Wed, 24 Feb 2010 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 17wg0u1H7e2C for ; Wed, 24 Feb 2010 15:01:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 65AB128C0EB for ; Wed, 24 Feb 2010 15:01:02 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAU/hUtAZnwN/2dsb2JhbACbE3OjZZhDhHIEgxY X-IronPort-AV: E=Sophos;i="4.49,534,1262563200"; d="scan'208";a="88615337" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2010 23:03:10 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1ON39ZE006690; Wed, 24 Feb 2010 23:03:09 GMT Message-ID: <4B85B02E.6000500@cisco.com> Date: Wed, 24 Feb 2010 18:03:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7E9EAD.20201@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 23:01:03 -0000 Christer Holmberg wrote: > Hi, > > I am trying to collect issues which are unclear regarding OPTIONS. > > Some issues a described below, but if you are aware of others please let me know. Another one I have encountered: What is behavior of OPTIONS when sent "in-dialog". 3261 (I forget where) states that OPTIONS in dialog should be treated the same as out of dialog. But does it really mean that? And to what extent? The place I encountered it was people who wanted to use OPTIONS in dialog to test the liveness of the other end. In particular they wanted to test if the dialog was still live, as well as the path in general. (Of course they could have used something like UPDATE, but that isn't always supported, while OPTIONS is.) So, if an OPTIONS is received, and it has a to-tag, is it treated as an in-dialog request at least to the extent of returning a 481 if there is no matching dialog? Or is it really treated as an out-of-dialog request such that even with no matching dialog it gets a 200 response? I *think* it should get a 481 in this case if there is no matching dialog. But I think this is currently ambiguous. Thanks, Paul From adam@nostrum.com Wed Feb 24 16:21:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D823A7B04 for ; Wed, 24 Feb 2010 16:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, 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 lLgME-F6Rb9k for ; Wed, 24 Feb 2010 16:21:27 -0800 (PST) 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 AB16D3A738A for ; Wed, 24 Feb 2010 16:21:26 -0800 (PST) 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 o1P0NSNR089006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 18:23:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B85C300.6080107@nostrum.com> Date: Wed, 24 Feb 2010 18:23:28 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:21:28 -0000 On 2/24/10 4:12 PM, Christer Holmberg wrote: > Sent the reply below using the old subject, so re-sending it here: > > I think we should try to solve the question marks, and I am willing to help in such exercise. We would need to discuss how we set up and divide the work. > > For some of the headers, I think the question marks can be solved by reading the specs where they are defined. For example, I think it is rather clear where RSeq and RAck can be used. > Yep. I went through and updated the table for the ones that I could answer off the top of my head (I think I got them all correct), and the table looks a fair bit better now. https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html Now, we probably still want to audit the table -- I found some pretty egregious errors in the information extracted from the documents themselves, but the overall starting point doesn't look as bad as I thought it would at first. /a From adam@nostrum.com Wed Feb 24 16:30:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA2728C290 for ; Wed, 24 Feb 2010 16:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 6EslLj-UNduK for ; Wed, 24 Feb 2010 16:30:35 -0800 (PST) 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 585D128C29F for ; Wed, 24 Feb 2010 16:30:34 -0800 (PST) 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 o1P0Wdun089687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 18:32:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B85C527.10906@nostrum.com> Date: Wed, 24 Feb 2010 18:32:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> <4B85C300.6080107@nostrum.com> In-Reply-To: <4B85C300.6080107@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:30:37 -0000 By the way, the green entries are the ones I've entered manually (as opposed to extracting from RFCs). /a On 2/24/10 6:23 PM, Adam Roach wrote: > On 2/24/10 4:12 PM, Christer Holmberg wrote: >> Sent the reply below using the old subject, so re-sending it here: >> >> I think we should try to solve the question marks, and I am willing >> to help in such exercise. We would need to discuss how we set up and >> divide the work. >> >> For some of the headers, I think the question marks can be solved by >> reading the specs where they are defined. For example, I think it is >> rather clear where RSeq and RAck can be used. > > Yep. I went through and updated the table for the ones that I could > answer off the top of my head (I think I got them all correct), and > the table looks a fair bit better now. > > https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html > > Now, we probably still want to audit the table -- I found some pretty > egregious errors in the information extracted from the documents > themselves, but the overall starting point doesn't look as bad as I > thought it would at first. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Feb 24 16:31:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4F928C292 for ; Wed, 24 Feb 2010 16:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 JSmDTmDCOrcg for ; Wed, 24 Feb 2010 16:31:56 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 070943A8504 for ; Wed, 24 Feb 2010 16:31:55 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-f9-4b85c57a68b0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 30.45.01038.A75C58B4; Thu, 25 Feb 2010 01:34:03 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 25 Feb 2010 01:34:01 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Thu, 25 Feb 2010 01:34:00 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq1pG3o63FiIkOgR1iY1S1GR6AETgADV9uQ Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B85AE51.5070603@cisco.com> In-Reply-To: <4B85AE51.5070603@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:31:57 -0000 Hi,=20 >>Another issue is related to the usage of feature tags. RFC 3841 says that= a UAS can perform=20 >>feature tag matching when receiving a request, and reject a request if it= doesn't support=20 >>required feature tags. I guess that is fine for INVITE, but do we want to= have that kind of=20 >>behavior for OPTIONS also? > >I don't see an issue here. The callerprefs stuff is independent of method.= If you don't want >callerprefs applied to your OPTIONS request, don't put = any callerprefs into the OPTIONS=20 >message. If they are present, then I would expect them to be honored to th= e same extent=20 >(optional) that they are ever honored. Sounds ok. Of course, when the UAC indicates which feature tags IT supports it has to = included them in the Contact header, and not in Accept-Contact, but I assum= e that is obvious. Regards, Christer From christer.holmberg@ericsson.com Wed Feb 24 16:36:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCFA28C111 for ; Wed, 24 Feb 2010 16:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 PanjhSAvnk3W for ; Wed, 24 Feb 2010 16:36:20 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2FF123A8608 for ; Wed, 24 Feb 2010 16:36:19 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-d5-4b85c68236a2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BC.71.31641.286C58B4; Thu, 25 Feb 2010 01:38:27 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 25 Feb 2010 01:38:26 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Thu, 25 Feb 2010 01:38:25 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq1pYokTYp7PFHVQUi6wJoiKfL5AwADM3Mw Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> In-Reply-To: <4B85B02E.6000500@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:36:21 -0000 Hi,=20 >Another one I have encountered: > >What is behavior of OPTIONS when sent "in-dialog". > >3261 (I forget where) states that OPTIONS in dialog should be treated the = same as out of=20 >dialog. But does it really mean that? And to what extent? > >The place I encountered it was people who wanted to use OPTIONS in dialog = to test the=20 >liveness of the other end. In particular they wanted to test if the dialog= was still live, as=20 >well as the path in general.=20 >(Of course they could have used something like UPDATE, but that isn't alwa= ys supported, while=20 >OPTIONS is.) > >So, if an OPTIONS is received, and it has a to-tag, is it treated as an in= -dialog request at=20 >least to the extent of returning a 481 if there is no matching dialog? Or = is it really=20 >treated as an out-of-dialog request such that even with no matching dialog= it gets a 200=20 >response? > >I *think* it should get a 481 in this case if there is no matching dialog.= But I think this=20 >is currently ambiguous. I also think 481 should be sent. Sending an in-dialog request on a non-exis= ting dialog is a core protocol error, and I don't think specific methods sh= ould be allowed to "override" that rule. Regards, Christer From brett@broadsoft.com Thu Feb 25 04:54:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1403228C119 for ; Thu, 25 Feb 2010 04:54:41 -0800 (PST) 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 8dr9+31-743a for ; Thu, 25 Feb 2010 04:54:39 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id B902528C0F1 for ; Thu, 25 Feb 2010 04:54:39 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 25 Feb 2010 04:56:50 -0800 From: Brett Tate To: Christer Holmberg , 'Paul Kyzivat' , SIPCORE Date: Thu, 25 Feb 2010 04:56:14 -0800 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq1pYokTYp7PFHVQUi6wJoiKfL5AwADM3MwABlWiAA= Message-ID: <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 12:54:41 -0000 > > I *think* it should get a 481 in this case if there is no=20 > > matching dialog. But I think this is currently ambiguous. >=20 > I also think 481 should be sent. Sending an in-dialog request=20 > on a non-existing dialog is a core protocol error, and I don't=20 > think specific methods should be allowed to "override" that rule. Concerning returning 481 response for OPTIONS, the ambiguity has multiple p= arts since per rfc5057 OPTIONS is not part of a dialog usage. 1) When SHOULD (or MUST) it be sent: never, no dialog, no invite dialog usa= ge, or no subscribe dialog usage? 2) What does it mean: no dialog, no invite dialog usage, or no subscribe di= alog usage? The following is a link to a 2008 thread concerning the topic: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019279.ht= ml=20 From adam@nostrum.com Thu Feb 25 07:02:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1692C28C162 for ; Thu, 25 Feb 2010 07:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 64-qBrRvDUeL for ; Thu, 25 Feb 2010 07:02:12 -0800 (PST) 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 DEAEE28C1A0 for ; Thu, 25 Feb 2010 07:02:11 -0800 (PST) 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 o1PF4IFV058405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 09:04:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B869172.6050702@nostrum.com> Date: Thu, 25 Feb 2010 09:04:18 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> <4B85C300.6080107@nostrum.com> <4B85C527.10906@nostrum.com> In-Reply-To: <4B85C527.10906@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 15:02:14 -0000 I realize that I'm replying to a reply to myself -- but it's been pointed out to me that most people don't have CAcert installed as a valid root certificate issuer. To avoid SSL warnings, you can get to the table here: http://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html /a On 2/24/10 6:32 PM, Adam Roach wrote: > By the way, the green entries are the ones I've entered manually (as > opposed to extracting from RFCs). > > /a > > On 2/24/10 6:23 PM, Adam Roach wrote: >> On 2/24/10 4:12 PM, Christer Holmberg wrote: >>> Sent the reply below using the old subject, so re-sending it here: >>> >>> I think we should try to solve the question marks, and I am willing >>> to help in such exercise. We would need to discuss how we set up and >>> divide the work. >>> >>> For some of the headers, I think the question marks can be solved by >>> reading the specs where they are defined. For example, I think it is >>> rather clear where RSeq and RAck can be used. >> >> Yep. I went through and updated the table for the ones that I could >> answer off the top of my head (I think I got them all correct), and >> the table looks a fair bit better now. >> >> https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html >> >> Now, we probably still want to audit the table -- I found some pretty >> egregious errors in the information extracted from the documents >> themselves, but the overall starting point doesn't look as bad as I >> thought it would at first. >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Thu Feb 25 07:16:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2ED028C31C for ; Thu, 25 Feb 2010 07:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1eA4hG8LByzD for ; Thu, 25 Feb 2010 07:16:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5C2D128C1BE for ; Thu, 25 Feb 2010 07:16:28 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHcjhktAZnwN/2dsb2JhbACbF3OkIZhchHUEgxc X-IronPort-AV: E=Sophos;i="4.49,539,1262563200"; d="scan'208";a="88773558" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2010 15:18:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1PFIcLs000885; Thu, 25 Feb 2010 15:18:38 GMT Message-ID: <4B8694CB.70800@cisco.com> Date: Thu, 25 Feb 2010 10:18:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dale Worley References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> <1266950578.10428.13.camel@khone.us.nortel.com> In-Reply-To: <1266950578.10428.13.camel@khone.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 15:16:30 -0000 Dale Worley wrote: > On Mon, 2010-02-22 at 13:07 -0500, Paul Kyzivat wrote: >> None of this matters, because for non-invite transactions the UAC's >> state machine is going to be done when the first final response is >> received. It isn't going to be prepared to handle other 200 responses to >> the same transaction. > > If "Request-Disposition: no-cancel" is to have any sensible effect, it > means that "stray" 200 responses will be forwarded upstream, as they > would for an INVITE. RFC 3841 is explicit that Request-Disposition can > be used on non-INVITE requests. That's fine. But it does no good if the extra responses are not expected upstream and are discarded. Once the transaction state machine is torn down there is no mechanism for dealing with additional responses. The mechanisms for that only exist for INVITE. If we want that to work there is other stuff that must be updated. Thanks, Paul From pkyzivat@cisco.com Thu Feb 25 08:02:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E829B28C37F for ; Thu, 25 Feb 2010 08:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uGRXW+Q9cfJJ for ; Thu, 25 Feb 2010 08:02:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8F65128C1DE for ; Thu, 25 Feb 2010 08:02:55 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABouhktAZnwN/2dsb2JhbACbF3OkHZhdhHUEgxc X-IronPort-AV: E=Sophos;i="4.49,540,1262563200"; d="scan'208";a="88783167" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2010 16:05:06 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1PG5646019374; Thu, 25 Feb 2010 16:05:06 GMT Message-ID: <4B869FAF.80305@cisco.com> Date: Thu, 25 Feb 2010 11:05:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> <4B85C300.6080107@nostrum.com> <4B85C527.10906@nostrum.com> <4B869172.6050702@nostrum.com> In-Reply-To: <4B869172.6050702@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:02:57 -0000 Adam, IMO Accept-Contact should be optional for PUBLISH, just as it is for virtually everything else except REGISTER. (It doesn't make sense on REGISTER because that isn't routed based on contacts.) OTOH, it really doesn't make sense for in-dialog messages like PRACK, UPDATE, INFO, and NOTIFY. I don't know how it got specified as optional for those. (Not that it hurts much - it is irrelevant in those contexts.) Thanks, Paul Adam Roach wrote: > I realize that I'm replying to a reply to myself -- but it's been > pointed out to me that most people don't have CAcert installed as a > valid root certificate issuer. To avoid SSL warnings, you can get to the > table here: > > http://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html > > /a > > On 2/24/10 6:32 PM, Adam Roach wrote: >> By the way, the green entries are the ones I've entered manually (as >> opposed to extracting from RFCs). >> >> /a >> >> On 2/24/10 6:23 PM, Adam Roach wrote: >>> On 2/24/10 4:12 PM, Christer Holmberg wrote: >>>> Sent the reply below using the old subject, so re-sending it here: >>>> >>>> I think we should try to solve the question marks, and I am willing >>>> to help in such exercise. We would need to discuss how we set up and >>>> divide the work. >>>> >>>> For some of the headers, I think the question marks can be solved by >>>> reading the specs where they are defined. For example, I think it is >>>> rather clear where RSeq and RAck can be used. >>> >>> Yep. I went through and updated the table for the ones that I could >>> answer off the top of my head (I think I got them all correct), and >>> the table looks a fair bit better now. >>> >>> https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html >>> >>> Now, we probably still want to audit the table -- I found some pretty >>> egregious errors in the information extracted from the documents >>> themselves, but the overall starting point doesn't look as bad as I >>> thought it would at first. >>> >>> /a >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Thu Feb 25 08:32:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E13D28C1DE for ; Thu, 25 Feb 2010 08:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.040, 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 iqTYgMvKXFxJ for ; Thu, 25 Feb 2010 08:32:42 -0800 (PST) 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 58FDE28C1CF for ; Thu, 25 Feb 2010 08:32:42 -0800 (PST) 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 o1PGYlr4065406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 10:34:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B86A6A7.3010908@nostrum.com> Date: Thu, 25 Feb 2010 10:34:47 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <201002241746.o1OHkEEA008395@sj-core-3.cisco.com> <4B859A0C.1060803@nostrum.com> <4B85C300.6080107@nostrum.com> <4B85C527.10906@nostrum.com> <4B869172.6050702@nostrum.com> <4B869FAF.80305@cisco.com> In-Reply-To: <4B869FAF.80305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:32:43 -0000 On 2/25/10 10:05 AM, Paul Kyzivat wrote: > Adam, > > IMO Accept-Contact should be optional for PUBLISH, just as it is for > virtually everything else except REGISTER. (It doesn't make sense on > REGISTER because that isn't routed based on contacts.) Yep, I think that was a typo. There are probably others. That's why I'm highlighting my overrides in green. :) Fixed it. /a From pkyzivat@cisco.com Thu Feb 25 08:51:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA7128C3A3 for ; Thu, 25 Feb 2010 08:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Fw04GwP72Dw2 for ; Thu, 25 Feb 2010 08:51:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B5CC928C37B for ; Thu, 25 Feb 2010 08:51:00 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPY5hktAZnwM/2dsb2JhbACbF3OkQZhdhHUEgxeDAA X-IronPort-AV: E=Sophos;i="4.49,540,1262563200"; d="scan'208";a="88928501" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2010 16:53:11 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1PGrBAX022489; Thu, 25 Feb 2010 16:53:11 GMT Message-ID: <4B86AAEF.9000108@cisco.com> Date: Thu, 25 Feb 2010 11:53:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:51:02 -0000 Brett, Yes, there are many subtleties to this. I think some of the people who have asked me about this wanted to use this as an INVITE-dialog-usage status tester that is a little lighter weight than reinvite. But of course since it isn't part of the invite-dialog-usage its always possible that it might succeed because the *dialog* was still there even though the invite-dialog-usage is not. (Most people don't make the distinction, and often they are synonymous, but there are always those corner cases.) Thanks, Paul Brett Tate wrote: >>> I *think* it should get a 481 in this case if there is no >>> matching dialog. But I think this is currently ambiguous. >> I also think 481 should be sent. Sending an in-dialog request >> on a non-existing dialog is a core protocol error, and I don't >> think specific methods should be allowed to "override" that rule. > > Concerning returning 481 response for OPTIONS, the ambiguity has multiple parts since per rfc5057 OPTIONS is not part of a dialog usage. > > 1) When SHOULD (or MUST) it be sent: never, no dialog, no invite dialog usage, or no subscribe dialog usage? > > 2) What does it mean: no dialog, no invite dialog usage, or no subscribe dialog usage? > > > The following is a link to a 2008 thread concerning the topic: > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019279.html > > From brett@broadsoft.com Thu Feb 25 10:07:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22A93A86F6 for ; Thu, 25 Feb 2010 10:07:04 -0800 (PST) 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 xmGqeUB+3xBI for ; Thu, 25 Feb 2010 10:07:03 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id A179828C1E5 for ; Thu, 25 Feb 2010 10:07:00 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 25 Feb 2010 10:09:12 -0800 From: Brett Tate To: Paul Kyzivat Date: Thu, 25 Feb 2010 10:08:37 -0800 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq2OwTrgZ1EnH4rRuqg6bbIHogd2AAA54dA Message-ID: <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> In-Reply-To: <4B86AAEF.9000108@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 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 18:07:05 -0000 Hi Paul, > I think some of the people who have asked me about this wanted=20 > to use this as an INVITE-dialog-usage status tester that is a=20 > little lighter weight than reinvite.=20 Yes; and some people in 2000 wanted to do the same. As far as I know, the = idea was rejected. Some aspects are discussed within the following threads: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019279.ht= ml=20 http://www.ietf.org/mail-archive/web/sip/current/msg06338.html=20 > But of course since it isn't part of the invite-dialog-usage=20 > its always possible that it might succeed because the *dialog*=20 > was still there even though the invite-dialog-usage is not. Depending upon interpretation of the following, the *dialog* doesn't necess= arily need to exist. RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481(Call/Transaction Does Not Exist) status code and pass that to the server transaction. Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog." From ietf.hanserik@gmail.com Thu Feb 25 10:50:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4FC28C23F for ; Thu, 25 Feb 2010 10:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vWXRPIutyswh for ; Thu, 25 Feb 2010 10:50:29 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 14E7128C22C for ; Thu, 25 Feb 2010 10:50:28 -0800 (PST) Received: by ewy7 with SMTP id 7so1721367ewy.29 for ; Thu, 25 Feb 2010 10:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LRtnLLJiwA4UY4E/pju1U1m9kHwmDyTqMF4/XVKpSzk=; b=VbUVZfk2m2YydKHEwMO/jIB2puzV+aRt7cC3pLGmtcu9wFQkuxi7fs/OBgmDKyMuub zMW0Xh14k3pi/ivfIuHkGH4o/1Fgz5sj+3rAFy5Xgvsyby1ZTBC9J593KA6OQ6Gu29le bCcQ0JjSgbVO3bm2Go9R6rQWuW4RtJMd4yQR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fIwZMC3HnxJy+kiYOtg0b2AuCZzpf3q24ivgTFKeMtbu6cDuuwBddZlDgafAVKgZlF kLmhjOqZ9o9jwm+UqwYYm32Ce/N20erGxToYikCz1dcaB8feQRrV8vjbuIiro01ByD3Q f/ACM9kThdxtO+83yFvGzjiJZTqmkh5nW5YiE= MIME-Version: 1.0 Received: by 10.216.88.207 with SMTP id a57mr957671wef.200.1267123956679; Thu, 25 Feb 2010 10:52:36 -0800 (PST) In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> Date: Thu, 25 Feb 2010 19:52:36 +0100 Message-ID: <9ae56b1e1002251052r7db3b2c9t77a2e5e4c170413e@mail.gmail.com> From: Hans Erik van Elburg To: Brett Tate Content-Type: multipart/alternative; boundary=0016e6d7eaa753035004807149b0 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 18:50:30 -0000 --0016e6d7eaa753035004807149b0 Content-Type: text/plain; charset=ISO-8859-1 > > But of course since it isn't part of the invite-dialog-usage > > its always possible that it might succeed because the *dialog* > > was still there even though the invite-dialog-usage is not. > > Depending upon interpretation of the following, the *dialog* doesn't > necessarily need to exist. > > RFC 3261 section 12.2.2: > "If the UAS wishes to reject the request because it does not wish > to recreate the dialog, it MUST respond to the request with a > 481(Call/Transaction Does Not Exist) status code and pass that to > the server transaction. > > Requests that do not change in any way the state of a dialog may be > received within a dialog (for example, an OPTIONS request). They > are processed as if they had been received outside the dialog." > > Logically, one can not receive a request on a dialog if the dialog does not exist. As the last sentence refers back to the sentence before it, it says that: "Requests that do not change in any way the state of a dialog may be received within a dialog are processed as if they had been received outside the dialog." It talks a about requests received in a dialog, the processing comes second. Therefore I don't think that the processing bit overrides the rule that a "UAS that does not want to recreate a dialog for a request received in a dialog that currently does not exist MUST respond with a 481". But I agree that it is utterly confusing. /Hans Erik --0016e6d7eaa753035004807149b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0
> But of course since it isn't part of the invite-dialog-usage
> its always possible that it might succeed because the *dialog*
> was still there even though the invite-dialog-usage is not.

Depending upon interpretation of the following, the *dialog* doesn= 9;t necessarily need to exist.

RFC 3261 section 12.2.2:
"If the UAS wishes to reject the request because it does not wish
to recreate the dialog, it MUST respond to the request with a
481(Call/Transaction Does Not Exist) status code and pass that to
the server transaction.

Requests that do not change in any way the state of a dialog may be
received within a dialog (for example, an OPTIONS request). =A0They
are processed as if they had been received outside the dialog."

Logical= ly, one can not receive a request on a dialog if the dialog does not exist.= As the last sentence refers back to the sentence before it, it says that:<= br> "Requests that do not change in any way the state of a dialog may be r= eceived within a dialog are processed as if they had been received outside = the dialog."

It talks a about requests received in a dialog, th= e processing comes second.

Therefore I don't think that the processing bit overrides the rule = that a "UAS that does not want to recreate a dialog for a request rece= ived in a dialog that currently does not exist MUST respond with a 481"= ;.

But I agree that it is utterly confusing.

/Hans Erik


=
--0016e6d7eaa753035004807149b0-- From christer.holmberg@ericsson.com Thu Feb 25 11:18:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B876628C0F5 for ; Thu, 25 Feb 2010 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 zQOnvR6JrWug for ; Thu, 25 Feb 2010 11:18:44 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 43E5A3A84D7 for ; Thu, 25 Feb 2010 11:18:44 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-f0-4b86cd96ee0c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4D.7A.01038.69DC68B4; Thu, 25 Feb 2010 20:20:54 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 25 Feb 2010 20:20:54 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Dale Worley Date: Thu, 25 Feb 2010 20:20:53 +0100 Thread-Topic: [sipcore] OPTIONS: How to solve the forking problem? Thread-Index: Acq2LdQANF8H5WEpR9K0PRsqFh73xwAIECsw Message-ID: References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> <1266950578.10428.13.camel@khone.us.nortel.com> <4B8694CB.70800@cisco.com> In-Reply-To: <4B8694CB.70800@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 19:18:45 -0000 Hi,=20 >>>None of this matters, because for non-invite transactions the UAC's=20 >>>state machine is going to be done when the first final response is=20 >>>received. It isn't going to be prepared to handle other 200 responses=20 >>>to the same transaction. >>=20 >>If "Request-Disposition: no-cancel" is to have any sensible effect, it=20 >>means that "stray" 200 responses will be forwarded upstream, as they=20 >>would for an INVITE. RFC 3841 is explicit that Request-Disposition=20 >>can be used on non-INVITE requests. > >That's fine. But it does no good if the extra responses are not expected u= pstream and are=20 >discarded. Once the transaction state machine is torn down there is no mec= hanism for dealing=20 >with additional responses. The mechanisms for that only exist for INVITE. > >If we want that to work there is other stuff that must be updated. Is that really something people would want to do??? I was initially thinking about that option myself, but dropped it because I= thought it would be even more controversial (it most likely would require = some acknowledgement for the response) than defining provisional resposnes = for OPTIONS :) Regards, Christer Thanks, Paul From pkyzivat@cisco.com Thu Feb 25 11:45:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6643028C262 for ; Thu, 25 Feb 2010 11:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MPr3Gs9uCXaB for ; Thu, 25 Feb 2010 11:45:16 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 895E528C260 for ; Thu, 25 Feb 2010 11:45:16 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAtihktAZnwM/2dsb2JhbACbF3OlG5hahHUEgxc X-IronPort-AV: E=Sophos;i="4.49,541,1262563200"; d="scan'208";a="488506761" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-6.cisco.com with ESMTP; 25 Feb 2010 19:47:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1PJlRV7023861; Thu, 25 Feb 2010 19:47:27 GMT Message-ID: <4B86D3C8.7050902@cisco.com> Date: Thu, 25 Feb 2010 14:47:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <1266594706.3762.7.camel@khone.us.nortel.com> <1266860216.3760.30.camel@khone.us.nortel.com> <4B82C7E7.9060805@cisco.com> <1266950578.10428.13.camel@khone.us.nortel.com> <4B8694CB.70800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dale Worley , SIPCORE Subject: Re: [sipcore] OPTIONS: How to solve the forking problem? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 19:45:17 -0000 Christer Holmberg wrote: > Hi, > >>>> None of this matters, because for non-invite transactions the UAC's >>>> state machine is going to be done when the first final response is >>>> received. It isn't going to be prepared to handle other 200 responses >>>> to the same transaction. >>> If "Request-Disposition: no-cancel" is to have any sensible effect, it >>> means that "stray" 200 responses will be forwarded upstream, as they >>> would for an INVITE. RFC 3841 is explicit that Request-Disposition >>> can be used on non-INVITE requests. >> That's fine. But it does no good if the extra responses are not expected upstream and are >> discarded. Once the transaction state machine is torn down there is no mechanism for dealing >> with additional responses. The mechanisms for that only exist for INVITE. >> >> If we want that to work there is other stuff that must be updated. > > Is that really something people would want to do??? > > I was initially thinking about that option myself, but dropped it because I thought it would be even more controversial (it most likely would require some acknowledgement for the response) than defining provisional resposnes for OPTIONS :) IMO we don't want to go there. I was just refuting what I think was an implicit assumption by Dale that it ought to work now. Thanks, Paul From pkyzivat@cisco.com Thu Feb 25 11:53:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4820D3A8554 for ; Thu, 25 Feb 2010 11:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WWmDhAcvXqQR for ; Thu, 25 Feb 2010 11:53:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D6EA73A84D7 for ; Thu, 25 Feb 2010 11:53:01 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO5jhktAZnwN/2dsb2JhbACbF3OlLphZhHUEgxeDAA X-IronPort-AV: E=Sophos;i="4.49,541,1262563200"; d="scan'208";a="88841542" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2010 19:55:13 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1PJtDsw007207; Thu, 25 Feb 2010 19:55:13 GMT Message-ID: <4B86D597.6060009@cisco.com> Date: Thu, 25 Feb 2010 14:55:03 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 19:53:03 -0000 Brett Tate wrote: > Hi Paul, > >> I think some of the people who have asked me about this wanted >> to use this as an INVITE-dialog-usage status tester that is a >> little lighter weight than reinvite. > > Yes; and some people in 2000 wanted to do the same. As far as I know, the idea was rejected. I didn't intend to imply that I *agreed* with this usage. Its just that people still think its a good thing to do. Its part of the confusion/ambiguity about OPTIONS. > Some aspects are discussed within the following threads: > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019279.html > > http://www.ietf.org/mail-archive/web/sip/current/msg06338.html > > >> But of course since it isn't part of the invite-dialog-usage >> its always possible that it might succeed because the *dialog* >> was still there even though the invite-dialog-usage is not. > > Depending upon interpretation of the following, the *dialog* doesn't necessarily need to exist. > > RFC 3261 section 12.2.2: > "If the UAS wishes to reject the request because it does not wish > to recreate the dialog, it MUST respond to the request with a > 481(Call/Transaction Does Not Exist) status code and pass that to > the server transaction. > > Requests that do not change in any way the state of a dialog may be > received within a dialog (for example, an OPTIONS request). They > are processed as if they had been received outside the dialog." Right. *If* the OPTIONS has a to-tag, and there is no matching dialog there are several things that might happen: - it might be rejected with a 481 - it might succeed because it is treated as if received outside a dialog - it might cause the dialog to be recreated, and then succeed within it In the latter case, presumably the dialog would then end, because there are no dialog usages. Thanks, Paul From christer.holmberg@ericsson.com Thu Feb 25 12:32:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F9D3A8586 for ; Thu, 25 Feb 2010 12:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 9e4z9gO4Jqsl for ; Thu, 25 Feb 2010 12:32:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 51F663A8583 for ; Thu, 25 Feb 2010 12:32:24 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-96-4b86dedb77fb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id AB.4E.01038.BDED68B4; Thu, 25 Feb 2010 21:34:35 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 25 Feb 2010 21:34:35 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Brett Tate Date: Thu, 25 Feb 2010 21:34:34 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq2VHLmNUzGkfPGRM+Lq1sg6ka55gABBs8w Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> In-Reply-To: <4B86D597.6060009@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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 20:32:26 -0000 Hi,=20 >>> I think some of the people who have asked me about this wanted to use=20 >>> this as an INVITE-dialog-usage status tester that is a little lighter=20 >>> weight than reinvite. >>=20 >>Yes; and some people in 2000 wanted to do the same. As far as I know, th= e idea was=20 >>rejected. > >I didn't intend to imply that I *agreed* with this usage. >Its just that people still think its a good thing to do. >Its part of the confusion/ambiguity about OPTIONS. > > Some aspects are discussed within the following threads: >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/0192 > 79.html >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg06338.html >=20 >=20 >> But of course since it isn't part of the invite-dialog-usage its=20 >> always possible that it might succeed because the *dialog* was still=20 >> there even though the invite-dialog-usage is not. >=20 > Depending upon interpretation of the following, the *dialog* doesn't nece= ssarily need to exist. >=20 > RFC 3261 section 12.2.2: > "If the UAS wishes to reject the request because it does not wish to=20 > recreate the dialog, it MUST respond to the request with a=20 > 481(Call/Transaction Does Not Exist) status code and pass that to the=20 > server transaction. >=20 > Requests that do not change in any way the state of a dialog may be=20 > received within a dialog (for example, an OPTIONS request). They are=20 > processed as if they had been received outside the dialog." > >Right. > >*If* the OPTIONS has a to-tag, and there is no matching dialog there are s= everal things that=20 >might happen: >- it might be rejected with a 481 >- it might succeed because it is treated as if received outside a dialog Is that really true? As I read it, the text above says that a request recei= ved within an existing dialog may be treated as if it would have been recei= ved outside the dialog. But, we are now talking about a non-existing dialog= which the OPTIONS claims to belong to. >- it might cause the dialog to be recreated, and then succeed within it > In the latter case, presumably the dialog would then end, because > there are no dialog usages. And, this will of course depend on whether the UAS still has any knowledge = about the dialog. Personally I think this alternative is rather strange, and I've never heard= about it being used. But, I agree that the text seems to allow it. Regards, Christer