From john.elwell@siemens-enterprise.com Mon Jan 3 09:03:39 2011 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 44F773A685A for ; Mon, 3 Jan 2011 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 j5VNQRBYyuV7 for ; Mon, 3 Jan 2011 09:03:38 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C90073A67C0 for ; Mon, 3 Jan 2011 09:03:34 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2869734; Mon, 3 Jan 2011 18:03:30 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7E8B21EB82B6; Mon, 3 Jan 2011 18:03:30 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 3 Jan 2011 18:03:30 +0100 From: "Elwell, John" To: Mary Barnes Date: Mon, 3 Jan 2011 18:03:28 +0100 Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 Thread-Index: AcuniX3IOT792rFUSCygFfLxIhIeSwD3mMhQ 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 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, 03 Jan 2011 17:03:39 -0000 =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 29 December 2010 18:52 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 >=20 > Hi folks,=20 >=20 > I am in the process of completing the changes to 4244bis=20 > based on the oodles of comments. In re-reviewing the=20 > comments, I have a few additional responses below [MB2], one=20 > of which I would like feedback on - it's related to the case=20 > where the proxy is adding missing entries when there already=20 > hi-entires in the request.=20 >=20 > Thanks, > Mary. >=20 >=20 > On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John=20 > wrote: >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 02 November 2010 19:25 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on=20 > draft-ietf-sipcore-rfc4244bis-02 > > > > Hi John, > > > > Responses inline below [MB]. I will skip the ones=20 > that I replied to > > in the other response [MB]. > > > > Thanks, > > Mary. > > > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > > wrote: > > > Despite the effort that has gone into addressing comments > > raised by people on -01, I still find -02 hard to understand > > in places. I have not had time to review the whole document, > > but here are some comments up to section 7. Just as I > > finished writing this I saw Mary's response to my comments on > > -01, which I will respond to tomorrow. Apologies for any > > overlap between the two. > > > > > > >=20 >=20 > > > 27. Section 6.1.1: > > > "The proxy MUST include an hi-index attribute > > > with a value of "1"" > > > It says we are inserting an entry, not replacing any > > existing entries. Value "1" will not apply if there is an > > existing entry. > > [MB] Correct. If the prior hop did not include an=20 > hi-entry, then one > > is added. Even if there are already other hi-entries,=20 > there is no way > > to know how many hops might have been missed and=20 > thus, the indexing > > needs to be reset to 1 to reflect such. [/MB] > =09 > [JRE] So this means a downstream entity can receive two=20 > entries with index "1" (possibly with intervening entries 1.1=20 > etc.), not because of any incorrect behaviour of any of the=20 > nodes concerned, but merely because some intervening nodes=20 > don't support H-I. This was the first time I was aware of=20 > this. We should add some explanation. Personally I would=20 > prefer to continue the indexing rather than reset to "1". > =09 > =09 >=20 > [MB2] After reconsidering this, I agree with you that it=20 > would be better to not reset the index to "1" in cases where=20 > there are already hi-entries, but just not one for the=20 > previous hop However, I think it's important that it is=20 > obvious that there may be a gap. The only way I can think to=20 > do this would be to actually skip a value for the index -=20 > i.e., increment the value at the current level by 2 in the=20 > case where entries are added on behalf of prior hops in this=20 > case. This would flag that one or more intermediaries that=20 > forwarded the request did not support History-Info. This=20 > would also ensure that there are not duplicate values, which=20 > I agree could end up being extremely confusing (and the=20 > original intent was for the indices to be unique, although I=20 > am vaguely recalling this as a 4244 issue that we resolved by=20 > just setting the index to "1" - another broken aspect of 4244). [/MB2] [JRE] I agree that artificially generating a gap would make sense - but I d= on't have a vested interest in backward compatibility with 4244. John >=20 > > =09 > > > 36. "MUST forward captured History-Info in subsequent, > > > provisional, and final responses to the request sent by > > the ultimate > > > UAS (see Section 5.2)" > > > If a response does not contain any captured H-I (because > > the UAS doesn't support it), is there any requirement on the > > proxy to generate it from its own information? > > [MB] A proxy would have added an hi-entry for the UAS=20 > if it follows > > the normative procedures in this document. But, there=20 > is no way for > > the proxy to generate any additional hi-entries (in=20 > cases where the > > UAS internally retargets or B2BUA case). [/MB] > =09 > [JRE] Understood. However, let me give you an example.=20 > A proxy receives a request with entries 1 and 1.1, and=20 > forwards it thereby adding 1.1.1. Suppose the next entity is=20 > the UAS and the UAS supports H-I. The UAS will capture 1, 1.1=20 > and 1.1.1 in the returned response, so therefore the proxy=20 > forwards 1, 1.1 and 1.1.1 when it forwards the response.=20 > That's fine. However, if the UAS does not support H-I, the=20 > response will contain no entries. In this case, the proxy=20 > will be aware of entries 1, 1.1 and 1.2 and could add them=20 > when forwarding the response. This assumes a certain amount=20 > of state be held at the proxy, but no more than is required=20 > for forking, for example. > Perhaps I have misinterpreted the word "captured" in=20 > the cited text - I had assumed you meant captured in the=20 > received response, but of course it might mean captured by=20 > the proxy from the time it forwarded the request. It=20 > certainly needs some clarification. > =09 >=20 > [MB2] Agreed - the intent was that the proxy does keep track=20 > of the hi-entries and does include those in the subsequent=20 > response even in the case of a UAS that does not support=20 > History-Info. [/MB2] >=20 >=20 > > =09 > > > > > > 41. Section 7.1.3, item 6: > > > "For example, if > > > a procesing entity received failure responses for > > forks 1.1.1 and > > > 1.1.2, it would return both the 1.1.1 and=20 > 1.1.2 entries to the > > > entity that generated the hi-entry with index of 1." > > > I can't figure this out - shouldn't "index of 1" be=20 > "index of 1.1"? > > [MB] No. The processing entity in that sentence has=20 > the index of 1.1. > > The processing entity is the subject of that sentence=20 > and "it" returns > > the response to the entity that would have added the=20 > hi-entry with > > index of 1.[/MB] > =09 > [JRE] I still can't figure this out. A proxy receives a=20 > request with entries 1 and 1.1. It creates two branches,=20 > 1.1.1 and 1.1.2. Both fail, so when the proxy sends a=20 > response back, it will include entries 1.1.1 and 1.1.2. That=20 > response is sent to the entity that generated 1.1. > =09 >=20 > [MB2] Yep. I was thinking in terms of the entity that is=20 > associated with the hi-entry with index of 1.1. [/MB2] > =20 >=20 >=20 > > =09 > >=20 > = From dworley@avaya.com Mon Jan 3 09:53:25 2011 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 C2F133A69F6 for ; Mon, 3 Jan 2011 09:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 T+BDDj7+NWSz for ; Mon, 3 Jan 2011 09:53:25 -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 E9F423A69F3 for ; Mon, 3 Jan 2011 09:53:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAacIU3GmAcF/2dsb2JhbACkNHOlJAKWVIVKBIRliVY X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="52655427" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 03 Jan 2011 12:55:30 -0500 X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="565676456" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jan 2011 12:55:30 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 3 Jan 2011 12:55:29 -0500 From: "Worley, Dale R (Dale)" To: Christer Holmberg , "sipcore@ietf.org" Date: Mon, 3 Jan 2011 12:53:47 -0500 Thread-Topic: Does a forking proxy send 481? Thread-Index: AQHLoicB3RtUyQIKOk6iYgKUeLVlz5O/mgky Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05850482F0C3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850482F0C3@ESESSCMS0356.eemea.ericsson.se> 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] Does a forking proxy send 481? 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, 03 Jan 2011 17:53:25 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Question: Does the forking proxy send a 481 response to the request, or doe= s it forward it towards the remote UAS previously associated with ED1? The reason I ask is because of a question whether there should always be a = 2xx response to a PRACK, even if the associated dialog has been terminated.= But, a proxy that does not know PRACK would of course send a 481. _______________________________________________ It appears that the forking proxy has the option of sending 481 in response= to a request directed to a dialog that it knows has terminated. It seems = that PRACK is an exception to this, but as you note, the proxy may not unde= rstand PRACK. The safest implementation is that the UA should be prepared = to receive a 481 response to the PRACK. Dale From gao.yang2@zte.com.cn Mon Jan 3 21:21:42 2011 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 A28CC3A6A77 for ; Mon, 3 Jan 2011 21:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.96 X-Spam-Level: X-Spam-Status: No, score=-97.96 tagged_above=-999 required=5 tests=[AWL=2.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_93=0.6, 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 xSFyAWiSlcmL for ; Mon, 3 Jan 2011 21:21:41 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 47A5C3A6A5E for ; Mon, 3 Jan 2011 21:21:40 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Tue, 4 Jan 2011 13:19:43 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 68277.3600711371; Tue, 4 Jan 2011 13:23:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p045Np0E016826; Tue, 4 Jan 2011 13:23:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-KeepSent: FE9A94AD:A56650E3-4825780E:0019F49D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 4 Jan 2011 13:21:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-04 13:23:41, Serialize complete at 2011-01-04 13:23:41 Content-Type: multipart/alternative; boundary="=_alternative 001DA5874825780E_=" X-MAIL: mse3.zte.com.cn p045Np0E016826 Subject: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 05:21:42 -0000 This is a multipart message in MIME format. --=_alternative 001DA5874825780E_= Content-Type: text/plain; charset="US-ASCII" Hi, By our equipment's performance analysis, we(internal) find that SUBSCRIBE method always occupy a lot of resource, especially for some long duration Event Packages. (Considering the traffic model, some Event Packages, have larger call rate and longer duration than INVITE method.) Supposing the SUBSCRIBE's dialog&event resource consuming is similar to INVITE's dialog&session(signalling level) resource consuming, one Event Package's would need more resource consuming than the session usage. Considering some Event Package's event occurence probability is very low in the subscription's relative long duration lifecycle, we can make a new type of subscription which would tear down the dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequent notification out-of-dialog. I'd like to hear Adam and other RFC3265 experts' view points. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001DA5874825780E_= Content-Type: text/html; charset="US-ASCII"
Hi,

By our equipment's performance analysis, we(internal) find that SUBSCRIBE method always occupy a lot of resource, especially for some long duration Event Packages. (Considering the traffic model, some Event Packages, have larger call rate and longer duration than INVITE method.)

Supposing the SUBSCRIBE's dialog&event resource consuming is similar to INVITE's dialog&session(signalling level) resource consuming, one Event Package's would need more resource consuming than the session usage.

Considering some Event Package's event occurence probability is very low in the subscription's relative long duration lifecycle, we can make a new type of subscription which would tear down the dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequent notification out-of-dialog.

I'd like to hear Adam and other RFC3265 experts' view points.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001DA5874825780E_=-- From christer.holmberg@ericsson.com Tue Jan 4 04:42:48 2011 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 6527C3A6BB6 for ; Tue, 4 Jan 2011 04:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, J_CHICKENPOX_93=0.6, 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 hbyXRM+DFlXB for ; Tue, 4 Jan 2011 04:42:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3A87D3A6BB2 for ; Tue, 4 Jan 2011 04:42:47 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-74-4d231645e606 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E4.CA.23694.546132D4; Tue, 4 Jan 2011 13:44:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 4 Jan 2011 13:44:53 +0100 From: Christer Holmberg To: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Tue, 4 Jan 2011 13:44:52 +0100 Thread-Topic: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: Acurz5P6zghV9ebET1ue6akbIF4h6AAPN0Ag Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585048F8C5A@ESESSCMS0356.eemea.ericsson.se> 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] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 12:42:48 -0000 Hi Gao,=20 >By our equipment's performance analysis, we(internal) find that SUBSCRIBE = method always occupy a lot of resource, especially for some long duration E= vent Packages. (Considering the traffic=20 >model, some Event Packages, have larger call rate and longer duration than= INVITE method.)=20 >=09 >Supposing the SUBSCRIBE's dialog&event resource consuming is similar to IN= VITE's dialog&session(signalling level) resource consuming, one Event Packa= ge's would need more resource consuming than=20 >the session usage.=20 >=09 >Considering some Event Package's event occurence probability is very low i= n the subscription's relative long duration lifecycle, we can make a new ty= pe of subscription which would tear down the=20 >dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequen= t notification out-of-dialog.=20 >=09 >I'd like to hear Adam and other RFC3265 experts' view points.=20 I'm neither, but I have some questions for clarifications: 1. I assume the SUB sender would still need store some data, in order to ma= tch the out-of-dialog NOT to the previous SUB dialog? 2. If 1 is true, for how long would the SUB sender keep this data, and be p= repared to receive the out-of-dialog NOT? I guess the subscription timers d= on't apply in this case, or? 3. Would the out-of-dialog NOT be routed using a Contact/GRUU, rather than = the AOR, of the SUB sender, to ensure it reaches the SUB sender? Regards, Christer From dworley@avaya.com Tue Jan 4 07:51:48 2011 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 5186D3A6CB6 for ; Tue, 4 Jan 2011 07:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 vhRPNE7iWXRG for ; Tue, 4 Jan 2011 07:51:47 -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 82FD93A6C9D for ; Tue, 4 Jan 2011 07:51:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGfRIk3GmAcF/2dsb2JhbACkOnOjbQKXE4JyglgEhGiJVg X-IronPort-AV: E=Sophos;i="4.60,272,1291611600"; d="scan'208";a="52813979" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 04 Jan 2011 10:53:43 -0500 X-IronPort-AV: E=Sophos;i="4.60,272,1291611600"; d="scan'208";a="566133330" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jan 2011 10:53:42 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 4 Jan 2011 10:53:41 -0500 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Tue, 4 Jan 2011 10:53:41 -0500 Thread-Topic: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: Acurz5QtWQHzD79cTT6fQ2ai1bdXOAAU1tdQ 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] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 15:51:48 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of gao.= yang2@zte.com.cn [gao.yang2@zte.com.cn] we can make a new type of subscription which would tear down the dialog aft= er the SUBSCRIBE(and the first NOTIFY), while send the subsequent notificat= ion out-of-dialog. ________________________________________ I do not see that much saving could be obtained using the new method. The = notifier would still need to maintain knowledge of the pseudo-subscription,= as it needs to know that it must send NOTIFYs. The subscriber would still= need to maintain knowledge of the pseudo-subscription, as it needs to be a= ble to interpret the received NOTIFYs, and it needs to refresh the pseudo-s= ubscription. The only savings that I can identify are that if the intermediate elements = maintain state regarding subscription dialogs. The simple solution to such= overhead is for the intermediate elements *to not maintain state regarding= subscription dialogs*, either by being proper proxies (and thus not mainta= ining state regarding *any* dialog), or by not Record-Routing themselves du= ring the creation of subscription dialogs (and thus not needing to retain s= tate regarding subscription dialogs). In either method, the notifier would need to know a URI that routes directl= y to the subscriber. In a subscription with no Record-Routes, it would of = necessity be the Contact URI in the SUBSCRIBE. In the new method, it could= be defined in another way, but the SUBSCRIBE Contact URI seems to be suffi= cient. In either method, the best solution seems to be for the subscriber = to have a GRUU to use as its Contact URI. Dale From keith.drage@alcatel-lucent.com Tue Jan 4 08:07:27 2011 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 EA2613A6CF5 for ; Tue, 4 Jan 2011 08:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.371 X-Spam-Level: X-Spam-Status: No, score=-105.371 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, 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 FuXAfqoEHMAC for ; Tue, 4 Jan 2011 08:07:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 267243A6CDC for ; Tue, 4 Jan 2011 08:07:17 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p04G9KxD020030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Jan 2011 17:09:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 4 Jan 2011 17:09:20 +0100 From: "DRAGE, Keith (Keith)" To: "Worley, Dale R (Dale)" , "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Tue, 4 Jan 2011 17:09:18 +0100 Thread-Topic: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: Acurz5QtWQHzD79cTT6fQ2ai1bdXOAAU1tdQAAGg3MA= 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 16:07:28 -0000 Agreed. The key here is to understanding what dialog state needs to be main= tained, and the proposal as currently described does not seem to change tha= t. It merely changes formal dialog state into something that does the same = thing but is not formally defined. Of course we could remove all state altogether, but that surely is PUBLISH. Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: Tuesday, January 04, 2011 3:54 PM > To: gao.yang2@zte.com.cn; sipcore@ietf.org > Subject: Re: [sipcore] About SUBSCRIBE method's performance=20 > and Out-of-Dialog notification suggestion: >=20 > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On=20 > Behalf Of gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] >=20 > we can make a new type of subscription which would tear down=20 > the dialog after the SUBSCRIBE(and the first NOTIFY), while=20 > send the subsequent notification out-of-dialog. > ________________________________________ >=20 > I do not see that much saving could be obtained using the new=20 > method. The notifier would still need to maintain knowledge=20 > of the pseudo-subscription, as it needs to know that it must=20 > send NOTIFYs. The subscriber would still need to maintain=20 > knowledge of the pseudo-subscription, as it needs to be able=20 > to interpret the received NOTIFYs, and it needs to refresh=20 > the pseudo-subscription. >=20 > The only savings that I can identify are that if the=20 > intermediate elements maintain state regarding subscription=20 > dialogs. The simple solution to such overhead is for the=20 > intermediate elements *to not maintain state regarding=20 > subscription dialogs*, either by being proper proxies (and=20 > thus not maintaining state regarding *any* dialog), or by not=20 > Record-Routing themselves during the creation of subscription=20 > dialogs (and thus not needing to retain state regarding=20 > subscription dialogs). >=20 > In either method, the notifier would need to know a URI that=20 > routes directly to the subscriber. In a subscription with no=20 > Record-Routes, it would of necessity be the Contact URI in=20 > the SUBSCRIBE. In the new method, it could be defined in=20 > another way, but the SUBSCRIBE Contact URI seems to be=20 > sufficient. In either method, the best solution seems to be=20 > for the subscriber to have a GRUU to use as its Contact URI. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dworley@avaya.com Tue Jan 4 09:13:40 2011 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 8E5A43A6C0B for ; Tue, 4 Jan 2011 09:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 9tsDNhABsYtC for ; Tue, 4 Jan 2011 09:13:39 -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 C56BA3A6BE0 for ; Tue, 4 Jan 2011 09:13:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACbkIk3GmAcF/2dsb2JhbACkPHOlaAKWY4VKBIRoiVY X-IronPort-AV: E=Sophos;i="4.60,273,1291611600"; d="scan'208";a="257976768" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jan 2011 12:15:45 -0500 X-IronPort-AV: E=Sophos;i="4.60,273,1291611600"; d="scan'208";a="566164953" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jan 2011 12:15:45 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 4 Jan 2011 12:15:45 -0500 From: "Worley, Dale R (Dale)" To: "DRAGE, Keith (Keith)" , "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Tue, 4 Jan 2011 12:13:16 -0500 Thread-Topic: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: Acurz5QtWQHzD79cTT6fQ2ai1bdXOAAU1tdQAAGg3MAAAk6IgQ== 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] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 17:13:40 -0000 ________________________________________ From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] The key here is to understanding what dialog state needs to be maintained, = and the proposal as currently described does not seem to change that. ________________________________________ I suspect that the question is dialog state maintained in intermediate elem= ents, as many SIP systems coming from traditional telco companies implement= intermediate elements as B2BUAs, and often have up to a dozen B2BUAs in wh= at would be expected in SIP to be a single dialog. I expect Gao will clari= fy the question when his day arrives. Dale From mary.ietf.barnes@gmail.com Tue Jan 4 11:48:59 2011 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 EF5263A6AE1 for ; Tue, 4 Jan 2011 11:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.272 X-Spam-Level: X-Spam-Status: No, score=-103.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 M+YKJlBJVXi7 for ; Tue, 4 Jan 2011 11:48:58 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C94AE3A6A74 for ; Tue, 4 Jan 2011 11:48:57 -0800 (PST) Received: by yxt33 with SMTP id 33so6481166yxt.31 for ; Tue, 04 Jan 2011 11:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xBYhW7xd8pdBM0BQD2a/ReZ3ZuCfddJicLEb6YFP47o=; b=veSt3juE5E8T1pF1WoD24gPyCVPnvY4Y2L0fxJz8B+5hudDfRRFFEuGWryKohZzYHk uL9f7tiHbJg4z3W3cVfjDkjKxATsTWufrKPiUuQ9sRBSrBenRbl5+SHKWiue0UxgocTm gKpxypYSYFEqFtPCj1rFS4Q2euCIRxXWyh3dQ= 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=XblJ2eVgfBSRUE8lRnDk/WTAceg11dnuYNnv6hkIjZx6reHYYC193hPXlhdIha3krA NbycahB1EXlr/o2JVJEs8mUnpRUeaADVeujPemTr2mYAc9x0XK4BXHPvGgrxtgTSHNEE 8l1h5kh+d4EEZr11fZUEGdJsF1tEejDmHCgDA= MIME-Version: 1.0 Received: by 10.236.103.145 with SMTP id f17mr9541567yhg.61.1294170664643; Tue, 04 Jan 2011 11:51:04 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 4 Jan 2011 11:51:03 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Jan 2011 13:51:03 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c9023beacef04990a9631 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 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, 04 Jan 2011 19:49:00 -0000 --0023547c9023beacef04990a9631 Content-Type: text/plain; charset=ISO-8859-1 Backwards compatibility is a potential downside. However, I think we can debate whether it would cause problems since RFC 4244 didn't really cover the case where there were already hi-entries, but just not one for the Request URI in the incoming request. The resetting to "1" is broken in the current version of 4244bis, since it really should state that the index at the current level is reset to 1. - i.e., if you have hi-entries 1.1.1 and 1.1.2, but there is no hi-entry for the incoming request, that entry should be added with an index of 1.1.1. However, I'm suggesting that instead we skip the index value of 1.1.3, so that it's obvious that one or more intermediaries didn't support History-Info, thus avoiding duplicate entries, which could introduce problems. Thanks, Mary. On Mon, Jan 3, 2011 at 11:03 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 29 December 2010 18:52 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 > > > > Hi folks, > > > > I am in the process of completing the changes to 4244bis > > based on the oodles of comments. In re-reviewing the > > comments, I have a few additional responses below [MB2], one > > of which I would like feedback on - it's related to the case > > where the proxy is adding missing entries when there already > > hi-entires in the request. > > > > Thanks, > > Mary. > > > > > > On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John > > wrote: > > > > > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > > Sent: 02 November 2010 19:25 > > > To: Elwell, John > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-rfc4244bis-02 > > > > > > Hi John, > > > > > > Responses inline below [MB]. I will skip the ones > > that I replied to > > > in the other response [MB]. > > > > > > Thanks, > > > Mary. > > > > > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > > > wrote: > > > > Despite the effort that has gone into addressing comments > > > raised by people on -01, I still find -02 hard to understand > > > in places. I have not had time to review the whole document, > > > but here are some comments up to section 7. Just as I > > > finished writing this I saw Mary's response to my comments on > > > -01, which I will respond to tomorrow. Apologies for any > > > overlap between the two. > > > > > > > > > > > > > > > > 27. Section 6.1.1: > > > > "The proxy MUST include an hi-index attribute > > > > with a value of "1"" > > > > It says we are inserting an entry, not replacing any > > > existing entries. Value "1" will not apply if there is an > > > existing entry. > > > [MB] Correct. If the prior hop did not include an > > hi-entry, then one > > > is added. Even if there are already other hi-entries, > > there is no way > > > to know how many hops might have been missed and > > thus, the indexing > > > needs to be reset to 1 to reflect such. [/MB] > > > > [JRE] So this means a downstream entity can receive two > > entries with index "1" (possibly with intervening entries 1.1 > > etc.), not because of any incorrect behaviour of any of the > > nodes concerned, but merely because some intervening nodes > > don't support H-I. This was the first time I was aware of > > this. We should add some explanation. Personally I would > > prefer to continue the indexing rather than reset to "1". > > > > > > > > [MB2] After reconsidering this, I agree with you that it > > would be better to not reset the index to "1" in cases where > > there are already hi-entries, but just not one for the > > previous hop However, I think it's important that it is > > obvious that there may be a gap. The only way I can think to > > do this would be to actually skip a value for the index - > > i.e., increment the value at the current level by 2 in the > > case where entries are added on behalf of prior hops in this > > case. This would flag that one or more intermediaries that > > forwarded the request did not support History-Info. This > > would also ensure that there are not duplicate values, which > > I agree could end up being extremely confusing (and the > > original intent was for the indices to be unique, although I > > am vaguely recalling this as a 4244 issue that we resolved by > > just setting the index to "1" - another broken aspect of 4244). [/MB2] > [JRE] I agree that artificially generating a gap would make sense - but I > don't have a vested interest in backward compatibility with 4244. > > John > > > > > > > > > > > 36. "MUST forward captured History-Info in subsequent, > > > > provisional, and final responses to the request sent by > > > the ultimate > > > > UAS (see Section 5.2)" > > > > If a response does not contain any captured H-I (because > > > the UAS doesn't support it), is there any requirement on the > > > proxy to generate it from its own information? > > > [MB] A proxy would have added an hi-entry for the UAS > > if it follows > > > the normative procedures in this document. But, there > > is no way for > > > the proxy to generate any additional hi-entries (in > > cases where the > > > UAS internally retargets or B2BUA case). [/MB] > > > > [JRE] Understood. However, let me give you an example. > > A proxy receives a request with entries 1 and 1.1, and > > forwards it thereby adding 1.1.1. Suppose the next entity is > > the UAS and the UAS supports H-I. The UAS will capture 1, 1.1 > > and 1.1.1 in the returned response, so therefore the proxy > > forwards 1, 1.1 and 1.1.1 when it forwards the response. > > That's fine. However, if the UAS does not support H-I, the > > response will contain no entries. In this case, the proxy > > will be aware of entries 1, 1.1 and 1.2 and could add them > > when forwarding the response. This assumes a certain amount > > of state be held at the proxy, but no more than is required > > for forking, for example. > > Perhaps I have misinterpreted the word "captured" in > > the cited text - I had assumed you meant captured in the > > received response, but of course it might mean captured by > > the proxy from the time it forwarded the request. It > > certainly needs some clarification. > > > > > > [MB2] Agreed - the intent was that the proxy does keep track > > of the hi-entries and does include those in the subsequent > > response even in the case of a UAS that does not support > > History-Info. [/MB2] > > > > > > > > > > > > > > > > 41. Section 7.1.3, item 6: > > > > "For example, if > > > > a procesing entity received failure responses for > > > forks 1.1.1 and > > > > 1.1.2, it would return both the 1.1.1 and > > 1.1.2 entries to the > > > > entity that generated the hi-entry with index of 1." > > > > I can't figure this out - shouldn't "index of 1" be > > "index of 1.1"? > > > [MB] No. The processing entity in that sentence has > > the index of 1.1. > > > The processing entity is the subject of that sentence > > and "it" returns > > > the response to the entity that would have added the > > hi-entry with > > > index of 1.[/MB] > > > > [JRE] I still can't figure this out. A proxy receives a > > request with entries 1 and 1.1. It creates two branches, > > 1.1.1 and 1.1.2. Both fail, so when the proxy sends a > > response back, it will include entries 1.1.1 and 1.1.2. That > > response is sent to the entity that generated 1.1. > > > > > > [MB2] Yep. I was thinking in terms of the entity that is > > associated with the hi-entry with index of 1.1. [/MB2] > > > > > > > > > > > > > > > > > --0023547c9023beacef04990a9631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Backwards compatibility is a potential downside. =A0However, I think we can= debate whether it would cause problems since RFC 4244 didn't really co= ver the case where there were already hi-entries, but just not one for the = Request URI in the incoming request. =A0 The resetting to "1" is = broken in the current version of 4244bis, since it really should state that= the index at the current level is reset to 1. - i.e., if you have hi-entri= es 1.1.1 and 1.1.2, but there is no hi-entry for the incoming request, that= entry should be added with an index of 1.1.1. However, I'm suggesting = that instead we skip the index value of 1.1.3, so that it's obvious tha= t one or more intermediaries didn't support History-Info, thus avoiding= duplicate entries, which could introduce problems.=A0

Thanks,
Mary.=A0

On Mon, Jan 3, 2011 at 11:03 AM, Elwell, John <john.elwell@siemens-enterpr= ise.com> wrote:


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 29 December 2010 18:52 > To: Elwell, John
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 >
> Hi folks,
>
> I am in the process of completing the changes to 4244bis
> based on the oodles of comments. In re-reviewing the
> comments, I have a few additional responses below [MB2], one
> of which I would like feedback on - it's related to the case
> where the proxy is adding missing entries when there already
> hi-entires in the request.
>
> Thanks,
> Mary.
>
>
> On Wed, Nov 3, 2010 at 4:15 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> =A0 =A0 =A0 > Sent: 02 November 2010 19:25
> =A0 =A0 =A0 > To: Elwell, John
> =A0 =A0 =A0 > Cc: sipcore@ietf.= org
> =A0 =A0 =A0 > Subject: Re: [sipcore] Comments on
> draft-ietf-sipcore-rfc4244bis-02
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Hi John,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Responses inline below [MB]. =A0I will skip the ones<= br> > that I replied to
> =A0 =A0 =A0 > in the other response [MB].
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Thanks,
> =A0 =A0 =A0 > Mary.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John
> =A0 =A0 =A0 > <john.elwell@siemens-enterprise.com> wrote:
> =A0 =A0 =A0 > > Despite the effort that has gone into addressing= comments
> =A0 =A0 =A0 > raised by people on -01, I still find -02 hard to und= erstand
> =A0 =A0 =A0 > in places. I have not had time to review the whole do= cument,
> =A0 =A0 =A0 > but here are some comments up to section 7. Just as I=
> =A0 =A0 =A0 > finished writing this I saw Mary's response to my= comments on
> =A0 =A0 =A0 > -01, which I will respond to tomorrow. Apologies for = any
> =A0 =A0 =A0 > overlap between the two.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
>
>
> =A0 =A0 =A0 > > 27. Section 6.1.1:
> =A0 =A0 =A0 > > "The proxy MUST include an hi-index attribu= te
> =A0 =A0 =A0 > > =A0 =A0 =A0with a value of "1"" > =A0 =A0 =A0 > > It says we are inserting an entry, not replacing= any
> =A0 =A0 =A0 > existing entries. Value "1" will not apply = if there is an
> =A0 =A0 =A0 > existing entry.
> =A0 =A0 =A0 > [MB] Correct. If the prior hop did not include an
> hi-entry, then one
> =A0 =A0 =A0 > is added. Even if there are already other hi-entries,=
> there is no way
> =A0 =A0 =A0 > to know how many hops might have been missed and
> thus, the indexing
> =A0 =A0 =A0 > needs to be reset to 1 to reflect such. [/MB]
>
> =A0 =A0 =A0 [JRE] So this means a downstream entity can receive two > entries with index "1" (possibly with intervening entries 1.= 1
> etc.), not because of any incorrect behaviour of any of the
> nodes concerned, but merely because some intervening nodes
> don't support H-I. This was the first time I was aware of
> this. We should add some explanation. Personally I would
> prefer to continue the indexing rather than reset to "1". >
>
>
> [MB2] After reconsidering this, I agree with you that it
> would be better to not reset the index to "1" in cases where=
> there are already hi-entries, but just not one for the
> previous hop =A0 However, I think it's important that it is
> obvious that there may be a gap. The only way I can think to
> do this would be to actually skip a value for the index -
> i.e., increment the value at the current level by 2 in the
> case where entries are added on behalf of prior hops in this
> case. =A0This would flag that one or more intermediaries that
> forwarded the request did not support History-Info. =A0This
> would also ensure that there are not duplicate values, which
> I agree could end up being extremely confusing (and the
> original intent was for the indices to be unique, although I
> am vaguely recalling this as a 4244 issue that we resolved by
> just setting the index to "1" - another broken aspect of 424= 4). [/MB2]
[JRE] I agree that artificially generating a gap would make sen= se - but I don't have a vested interest in backward compatibility with = 4244.

John

>
> =A0 =A0 =A0 <snip/>
>
> =A0 =A0 =A0 > > 36. "MUST forward captured History-Info in = subsequent,
> =A0 =A0 =A0 > > =A0 provisional, and final responses to the requ= est sent by
> =A0 =A0 =A0 > the ultimate
> =A0 =A0 =A0 > > =A0 UAS (see Section 5.2)"
> =A0 =A0 =A0 > > If a response does not contain any captured H-I = (because
> =A0 =A0 =A0 > the UAS doesn't support it), is there any require= ment on the
> =A0 =A0 =A0 > proxy to generate it from its own information?
> =A0 =A0 =A0 > [MB] A proxy would have added an hi-entry for the UAS=
> if it follows
> =A0 =A0 =A0 > the normative procedures in this document. But, there=
> is no way for
> =A0 =A0 =A0 > the proxy to generate any additional hi-entries (in > cases where the
> =A0 =A0 =A0 > UAS internally retargets or B2BUA case). =A0 [/MB] >
> =A0 =A0 =A0 [JRE] Understood. However, let me give you an example.
> A proxy receives a request with entries 1 and 1.1, and
> forwards it thereby adding 1.1.1. Suppose the next entity is
> the UAS and the UAS supports H-I. The UAS will capture 1, 1.1
> and 1.1.1 in the returned response, so therefore the proxy
> forwards 1, 1.1 and 1.1.1 when it forwards the response.
> That's fine. However, if the UAS does not support H-I, the
> response will contain no entries. In this case, the proxy
> will be aware of entries 1, 1.1 and 1.2 and could add them
> when forwarding the response. This assumes a certain amount
> of state be held at the proxy, but no more than is required
> for forking, for example.
> =A0 =A0 =A0 Perhaps I have misinterpreted the word "captured"= ; in
> the cited text - I had assumed you meant captured in the
> received response, but of course it might mean captured by
> the proxy from the time it forwarded the request. It
> certainly needs some clarification.
>
>
> [MB2] Agreed - the intent was that the proxy does keep track
> of the hi-entries and does include those in the subsequent
> response even in the case of a UAS that does not support
> History-Info. [/MB2]
>
>
> =A0 =A0 =A0 <snip/>
>
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > 41. Section 7.1.3, item 6:
> =A0 =A0 =A0 > > "For example, if
> =A0 =A0 =A0 > > =A0 =A0 =A0 a procesing entity received failure = responses for
> =A0 =A0 =A0 > forks 1.1.1 and
> =A0 =A0 =A0 > > =A0 =A0 =A0 1.1.2, it would return both the 1.1.= 1 and
> 1.1.2 entries to the
> =A0 =A0 =A0 > > =A0 =A0 =A0 entity that generated the hi-entry w= ith index of 1."
> =A0 =A0 =A0 > > I can't figure this out - shouldn't &quo= t;index of 1" be
> "index of 1.1"?
> =A0 =A0 =A0 > [MB] No. =A0The processing entity in that sentence ha= s
> the index of 1.1.
> =A0 =A0 =A0 > The processing entity is the subject of that sentence=
> and "it" returns
> =A0 =A0 =A0 > the response to the entity that would have added the<= br> > hi-entry with
> =A0 =A0 =A0 > index of 1.[/MB]
>
> =A0 =A0 =A0 [JRE] I still can't figure this out. A proxy receives = a
> request with entries 1 and 1.1. It creates two branches,
> 1.1.1 and 1.1.2. Both fail, so when the proxy sends a
> response back, it will include entries 1.1.1 and 1.1.2. That
> response is sent to the entity that generated 1.1.
>
>
> [MB2] =A0Yep. I was thinking in terms of the entity that is
> associated with the hi-entry with index of 1.1. [/MB2]
>
>
>
> =A0 =A0 =A0 <snip/>
>
> =A0 =A0 =A0 <snip>
>
>

--0023547c9023beacef04990a9631-- From pkyzivat@cisco.com Tue Jan 4 12:36:59 2011 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 BEC2E3A6B94 for ; Tue, 4 Jan 2011 12:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wVxlt+IwnWx9 for ; Tue, 4 Jan 2011 12:36:58 -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 B05A83A6AC4 for ; Tue, 4 Jan 2011 12:36: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: AoEGALsTI01AZnwN/2dsb2JhbACWD44dc6NKmGyFSgSEaIYfgx0 X-IronPort-AV: E=Sophos;i="4.60,274,1291593600"; d="scan'208";a="199828928" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2011 20:39:05 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p04Kd5NZ025688 for ; Tue, 4 Jan 2011 20:39:05 GMT Message-ID: <4D238569.8010902@cisco.com> Date: Tue, 04 Jan 2011 15:39:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 20:36:59 -0000 On 1/4/2011 12:13 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] > > The key here is to understanding what dialog state needs to be maintained, and the proposal as currently described does not seem to change that. > ________________________________________ > > I suspect that the question is dialog state maintained in intermediate elements, as many SIP systems coming from traditional telco companies implement intermediate elements as B2BUAs, and often have up to a dozen B2BUAs in what would be expected in SIP to be a single dialog. I expect Gao will clarify the question when his day arrives. If this is the issue, then it just points out the obvious - that there are consequences to using B2BUAs rather than proxies. If it hurts, don't do it. Thanks, Paul From christer.holmberg@ericsson.com Tue Jan 4 12:52:52 2011 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 A3F383A69A9 for ; Tue, 4 Jan 2011 12:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMPO44+5qC8S for ; Tue, 4 Jan 2011 12:52:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BB3463A6A17 for ; Tue, 4 Jan 2011 12:52:49 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-a3-4d23891f4151 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.FB.13987.F19832D4; Tue, 4 Jan 2011 21:54:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 4 Jan 2011 21:54:54 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Tue, 4 Jan 2011 21:54:18 +0100 Thread-Topic: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: AcusT3E3slCnSDBMQ62TnMLGjM8sXAAAhzTS Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850482F0DB@ESESSCMS0356.eemea.ericsson.se> References: , , <4D238569.8010902@cisco.com> In-Reply-To: <4D238569.8010902@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== Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 20:52:52 -0000 Hi, Stateful proxies also maintain state. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Tuesday, January 04, 2011 10:39 PM To: sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dial= og notification suggestion: On 1/4/2011 12:13 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] > > The key here is to understanding what dialog state needs to be maintained= , and the proposal as currently described does not seem to change that. > ________________________________________ > > I suspect that the question is dialog state maintained in intermediate el= ements, as many SIP systems coming from traditional telco companies impleme= nt intermediate elements as B2BUAs, and often have up to a dozen B2BUAs in = what would be expected in SIP to be a single dialog. I expect Gao will cla= rify the question when his day arrives. If this is the issue, then it just points out the obvious - that there are consequences to using B2BUAs rather than proxies. If it hurts, don't do it. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From pkyzivat@cisco.com Tue Jan 4 13:08:43 2011 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 E3E4D3A6B82 for ; Tue, 4 Jan 2011 13:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hiStI0la1QT0 for ; Tue, 4 Jan 2011 13:08:42 -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 B882F3A6A17 for ; Tue, 4 Jan 2011 13:08:42 -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: AvsEALMbI01AZnwM/2dsb2JhbACkLXOjQphthUoEhGiGH4Md X-IronPort-AV: E=Sophos;i="4.60,274,1291593600"; d="scan'208";a="199606898" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2011 21:10:49 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p04LAnut028855; Tue, 4 Jan 2011 21:10:49 GMT Message-ID: <4D238CD9.7090201@cisco.com> Date: Tue, 04 Jan 2011 16:10:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: , , <4D238569.8010902@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850482F0DB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850482F0DB@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 21:08:44 -0000 On 1/4/2011 3:54 PM, Christer Holmberg wrote: > Hi, > > Stateful proxies also maintain state. Sure. But generally *less* state. For instance, often you could get by with just a transaction stateful proxy. And is it really the state that is the problem? Or is it the message processing? There is potentially a lot more work per-message for a B2BUA than a proxy. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Tuesday, January 04, 2011 10:39 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: > > On 1/4/2011 12:13 PM, Worley, Dale R (Dale) wrote: >> ________________________________________ >> From: DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] >> >> The key here is to understanding what dialog state needs to be maintained, and the proposal as currently described does not seem to change that. >> ________________________________________ >> >> I suspect that the question is dialog state maintained in intermediate elements, as many SIP systems coming from traditional telco companies implement intermediate elements as B2BUAs, and often have up to a dozen B2BUAs in what would be expected in SIP to be a single dialog. I expect Gao will clarify the question when his day arrives. > > If this is the issue, then it just points out the obvious - that there > are consequences to using B2BUAs rather than proxies. If it hurts, don't > do it. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Tue Jan 4 15:47:52 2011 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 001683A6DAC for ; Tue, 4 Jan 2011 15:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_93=0.6, SPF_PASS=-0.001, 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 TJTwUxXby4rj for ; Tue, 4 Jan 2011 15:47:50 -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 007FC3A6DAB for ; Tue, 4 Jan 2011 15:47:49 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p04NnpdB062866 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 17:49:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D23B21F.2090507@nostrum.com> Date: Tue, 04 Jan 2011 17:49:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406060903080600050101" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 04 Jan 2011 23:47:52 -0000 This is a multi-part message in MIME format. --------------020406060903080600050101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'll echo what has already been said: the notifications need some kind of correlation to match the subscription. The dialog provides this. You might be able to shave the state down a bit, but since the correlation needs to be unique (in the entire universe, forever), you probably can't make it much smaller than it already is. Without an explicit correlation between the subscribe and the NOTIFY, the only identifier you could use is the resource identifier itself. As Keith pointed out, we have something that behaves like this: PUBLISH. You can use this model, if you'd prefer; replace the subscription with provisioning information, and send a PUBLISH when you want to update state. And you need to take this with the caveat that you lose a bunch of functionality when you go from a subscription model to a publication model. But let's back up a bit. You talk about resource consumption as it pertains to a subscription; in particular, the dialog state required to keep this kind of information in memory. I'd like to do a back-of-the-napkin calculation to understand the issue. Dialogs are identified by to-tag, from-tag and call-id. On top of that, they must maintain a route set (including the Contacts) and two CSeqs (one for each direction). I'll grab a random wire trace to get a feel for the size of this information. To (with tag): ~16 bytes From (with tag): ~16 bytes Call-Id: ~24 bytes Local Contact: ~32 bytes Remote Contact: ~32 bytes Route Set (~74 bytes x 3 proxies): ~222 bytes Two CSeqs: 4 bytes That's about 346 bytes. To make the math easy, let's be sloppy and assume that miscellaneous overhead bumps this all the way to 512 bytes per dialog. That means that, in the 8 GB of RAM that my laptop has, I could store state for 16 million dialogs. In the 32-GB server-class boxes that I'm used to dimensioning for, it would take only 5 servers to store a dialog for every man, woman, child, and newborn baby in the U.S. -- or 20 servers to do the same thing for China. It would take a hair over 100 such servers to do this for every living human being. That's assuming we need to keep everything in actual wired RAM. If we're allowed to swap the data out to a pair of 2 TB hard drives (possibly sensible if the traffic is as low as you imply), this state -- one subscription for every human currently alive -- all fits on a single server. When you're talking about network servers, memory is cheap, and hard drives are cheaper. Standardization and implementation is expensive. So, I'm a bit doubtful that it would be a good investment on anyone's part to come up with a simplified model for RFC3265 subscriptions. /a On 1/3/11 11:21 PM, gao.yang2@zte.com.cn wrote: > > Hi, > > By our equipment's performance analysis, we(internal) find that > SUBSCRIBE method always occupy a lot of resource, especially for some > long duration Event Packages. (Considering the traffic model, some > Event Packages, have larger call rate and longer duration than INVITE > method.) > > Supposing the SUBSCRIBE's dialog&event resource consuming is similar > to INVITE's dialog&session(signalling level) resource consuming, one > Event Package's would need more resource consuming than the session > usage. > > Considering some Event Package's event occurence probability is very > low in the subscription's relative long duration lifecycle, we can > make a new type of subscription which would tear down the dialog after > the SUBSCRIBE(and the first NOTIFY), while send the subsequent > notification out-of-dialog. > > I'd like to hear Adam and other RFC3265 experts' view points. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --------------020406060903080600050101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'll echo what has already been said: the notifications need some kind of correlation to match the subscription. The dialog provides this. You might be able to shave the state down a bit, but since the correlation needs to be unique (in the entire universe, forever), you probably can't make it much smaller than it already is.

Without an explicit correlation between the subscribe and the NOTIFY, the only identifier you could use is the resource identifier itself. As Keith pointed out, we have something that behaves like this: PUBLISH. You can use this model, if you'd prefer; replace the subscription with provisioning information, and send a PUBLISH when you want to update state. And you need to take this with the caveat that you lose a bunch of functionality when you go from a subscription model to a publication model.

But let's back up a bit.

You talk about resource consumption as it pertains to a subscription; in particular, the dialog state required to keep this kind of information in memory. I'd like to do a back-of-the-napkin calculation to understand the issue. Dialogs are identified by to-tag, from-tag and call-id. On top of that, they must maintain a route set (including the Contacts) and two CSeqs (one for each direction).

I'll grab a random wire trace to get a feel for the size of this information.

To (with tag): ~16 bytes
From (with tag): ~16 bytes
Call-Id: ~24 bytes
Local Contact: ~32 bytes
Remote Contact: ~32 bytes
Route Set (~74 bytes x 3 proxies): ~222 bytes
Two CSeqs: 4 bytes

That's about 346 bytes. To make the math easy, let's be sloppy and assume that miscellaneous overhead bumps this all the way to 512 bytes per dialog.

That means that, in the 8 GB of RAM that my laptop has, I could store state for 16 million dialogs. In the 32-GB server-class boxes that I'm used to dimensioning for, it would take only 5 servers to store a dialog for every man, woman, child, and newborn baby in the U.S. -- or 20 servers to do the same thing for China. It would take a hair over 100 such servers to do this for every living human being.

That's assuming we need to keep everything in actual wired RAM. If we're allowed to swap the data out to a pair of 2 TB hard drives (possibly sensible if the traffic is as low as you imply), this state -- one subscription for every human currently alive -- all fits on a single server.

When you're talking about network servers, memory is cheap, and hard drives are cheaper. Standardization and implementation is expensive. So, I'm a bit doubtful that it would be a good investment on anyone's part to come up with a simplified model for RFC3265 subscriptions.

/a

On 1/3/11 11:21 PM, gao.yang2@zte.com.cn wrote:

Hi,

By our equipment's performance analysis, we(internal) find that SUBSCRIBE method always occupy a lot of resource, especially for some long duration Event Packages. (Considering the traffic model, some Event Packages, have larger call rate and longer duration than INVITE method.)

Supposing the SUBSCRIBE's dialog&event resource consuming is similar to INVITE's dialog&session(signalling level) resource consuming, one Event Package's would need more resource consuming than the session usage.

Considering some Event Package's event occurence probability is very low in the subscription's relative long duration lifecycle, we can make a new type of subscription which would tear down the dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequent notification out-of-dialog.

I'd like to hear Adam and other RFC3265 experts' view points.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--------------020406060903080600050101-- From gao.yang2@zte.com.cn Tue Jan 4 22:13:45 2011 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 3567B3A6992 for ; Tue, 4 Jan 2011 22:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.538 X-Spam-Level: X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nYBcE8NuJ9eR for ; Tue, 4 Jan 2011 22:13:43 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 652233A6A77 for ; Tue, 4 Jan 2011 22:13:41 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Wed, 5 Jan 2011 14:13:56 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 68277.3337783744; Wed, 5 Jan 2011 14:15:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id p056FDF5096226; Wed, 5 Jan 2011 14:15:13 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585048F8C5A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-KeepSent: 358C491E:316767BF-4825780F:001F809A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 5 Jan 2011 14:12:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-05 14:15:01, Serialize complete at 2011-01-05 14:15:01 Content-Type: multipart/alternative; boundary="=_alternative 002258A04825780F_=" X-MAIL: mse2.zte.com.cn p056FDF5096226 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 05 Jan 2011 06:13:45 -0000 This is a multipart message in MIME format. --=_alternative 002258A04825780F_= Content-Type: text/plain; charset="US-ASCII" Hi Christer, > 1. I assume the SUB sender would still need store some data, in > order to match the out-of-dialog NOT to the previous SUB dialog? By my primary thinking, I'd like this feature Event Package specific, that is some Event Packages which have the requirement could send notification out-of-dialog. Further, I think some Event Packages might need matching mechanism, some migt cut it out. But I think the matching mechanism is not the so heavy here, as the most memory usage is for Route Set. This heavey part could be saved while we use notification out-of-dialog. > > 2. If 1 is true, for how long would the SUB sender keep this data, > and be prepared to receive the out-of-dialog NOT? I guess the > subscription timers don't apply in this case, or? I think this could be defined Event Package specific too. > > 3. Would the out-of-dialog NOT be routed using a Contact/GRUU, > rather than the AOR, of the SUB sender, to ensure it reaches the SUB sender? To be honest, my proposal is row now, and I hadn't think this point. I agree that considering a specific heavy SUBSCRIBE usage, the "out-of-dialog" suggestion might not save impressive resource. But considering general usage, I think it would be meaningful. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002258A04825780F_= Content-Type: text/html; charset="US-ASCII"
Hi Christer,

> 1. I assume the SUB sender would still need store some data, in
> order to match the out-of-dialog NOT to the previous SUB dialog?

By my primary thinking, I'd like this feature Event Package specific, that is some Event Packages which have the requirement could send notification out-of-dialog.

Further, I think some Event Packages might need matching mechanism, some migt cut it out.

But I think the matching mechanism is not the so heavy here, as the most memory usage is for Route Set. This heavey part could be saved while we use notification out-of-dialog.

>
> 2. If 1 is true, for how long would the SUB sender keep this data,
> and be prepared to receive the out-of-dialog NOT? I guess the
> subscription timers don't apply in this case, or?

I think this could be defined Event Package specific too.

>
> 3. Would the out-of-dialog NOT be routed using a Contact/GRUU,
> rather than the AOR, of the SUB sender, to ensure it reaches the SUB sender?
To be honest, my proposal is row now, and I hadn't think this point.
I agree that considering a specific heavy SUBSCRIBE usage, the "out-of-dialog" suggestion might not save impressive resource. But considering general usage, I think it would be meaningful.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002258A04825780F_=-- From gao.yang2@zte.com.cn Tue Jan 4 22:22:39 2011 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 AC7FC3A6B1D for ; Tue, 4 Jan 2011 22:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.638 X-Spam-Level: X-Spam-Status: No, score=-101.638 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MwDWFhK0S2Jr for ; Tue, 4 Jan 2011 22:22:37 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4AC9D3A6992 for ; Tue, 4 Jan 2011 22:22:36 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Wed, 5 Jan 2011 14:22:51 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 68277.3772637948; Wed, 5 Jan 2011 14:24:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id p056OfSK003612; Wed, 5 Jan 2011 14:24:41 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4D238569.8010902@cisco.com> To: "Worley, Dale R (Dale)" , Paul Kyzivat MIME-Version: 1.0 X-KeepSent: 082175EF:9483DF20-4825780F:002282A0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 5 Jan 2011 14:21:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-05 14:24:29, Serialize complete at 2011-01-05 14:24:29 Content-Type: multipart/alternative; boundary="=_alternative 0023366A4825780F_=" X-MAIL: mse2.zte.com.cn p056OfSK003612 Cc: sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 05 Jan 2011 06:22:39 -0000 This is a multipart message in MIME format. --=_alternative 0023366A4825780F_= Content-Type: text/plain; charset="US-ASCII" Dale and Paul, > > I suspect that the question is dialog state maintained in > intermediate elements, as many SIP systems coming from traditional > telco companies implement intermediate elements as B2BUAs, and often > have up to a dozen B2BUAs in what would be expected in SIP to be a > single dialog. I expect Gao will clarify the question when his day arrives. [For Dale] I think it is about both, that is intermediate elements and the UAC/UAS. > If this is the issue, then it just points out the obvious - that there > are consequences to using B2BUAs rather than proxies. If it hurts, don't > do it. [For Paul] I think it is meaningful in cases that intermediate elements are defined B2BUA/Stateful(by some Network Architecture) or demanded B2BUA/Stateful(by users/operators). Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0023366A4825780F_= Content-Type: text/html; charset="US-ASCII"
Dale and Paul,

> > I suspect that the question is dialog state maintained in
> intermediate elements, as many SIP systems coming from traditional
> telco companies implement intermediate elements as B2BUAs, and often
> have up to a dozen B2BUAs in what would be expected in SIP to be a
> single dialog.  I expect Gao will clarify the question when his day arrives.

[For Dale] I think it is about both, that is intermediate elements and the UAC/UAS.
 
> If this is the issue, then it just points out the obvious - that there
> are consequences to using B2BUAs rather than proxies. If it hurts, don't
> do it.
[For Paul] I think it is meaningful in cases that intermediate elements are defined B2BUA/Stateful(by some Network Architecture) or demanded B2BUA/Stateful(by users/operators).

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0023366A4825780F_=-- From gao.yang2@zte.com.cn Tue Jan 4 23:21:31 2011 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 423913A6B45 for ; Tue, 4 Jan 2011 23:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.788 X-Spam-Level: X-Spam-Status: No, score=-100.788 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, 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 c5Fup+Bx4zFg for ; Tue, 4 Jan 2011 23:21:29 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 60EFD3A6A2C for ; Tue, 4 Jan 2011 23:21:28 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Wed, 5 Jan 2011 15:21:27 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 4402.3600711371; Wed, 5 Jan 2011 15:15:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p057MSKY035594; Wed, 5 Jan 2011 15:22:30 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4D23B21F.2090507@nostrum.com> To: Adam Roach MIME-Version: 1.0 X-KeepSent: 0D7B7388:3EF71F77-4825780F:0024C494; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 5 Jan 2011 15:19:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-05 15:22:19, Serialize complete at 2011-01-05 15:22:19 Content-Type: multipart/alternative; boundary="=_alternative 0028818D4825780F_=" X-MAIL: mse3.zte.com.cn p057MSKY035594 Cc: sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 05 Jan 2011 07:21:31 -0000 This is a multipart message in MIME format. --=_alternative 0028818D4825780F_= Content-Type: text/plain; charset="US-ASCII" Hi Adam, > I'll echo what has already been said: the notifications need some > kind of correlation to match the subscription. The dialog provides > this. You might be able to shave the state down a bit, but since the > correlation needs to be unique (in the entire universe, forever), > you probably can't make it much smaller than it already is. > > Without an explicit correlation between the subscribe and the > NOTIFY, the only identifier you could use is the resource identifier > itself. As Keith pointed out, we have something that behaves like > this: PUBLISH. You can use this model, if you'd prefer; replace the > subscription with provisioning information, and send a PUBLISH when > you want to update state. And you need to take this with the caveat > that you lose a bunch of functionality when you go from a > subscription model to a publication model. What I suggested is something like PUBLISH(out-of-dialog), but more. IMO, PUBLISH model hasn't define who(identify the subscriber) need which notification(identify the Event type) in PUBLISH usage. My thinking is about SUBSCRIBE model, with out-of-dialog notification for some specific Event Packages. > But let's back up a bit. > > You talk about resource consumption as it pertains to a > subscription; in particular, the dialog state required to keep this > kind of information in memory. I'd like to do a back-of-the-napkin > calculation to understand the issue. Dialogs are identified by to- > tag, from-tag and call-id. On top of that, they must maintain a > route set (including the Contacts) and two CSeqs (one for each direction). > > I'll grab a random wire trace to get a feel for the size of this information. > > To (with tag): ~16 bytes > From (with tag): ~16 bytes > Call-Id: ~24 bytes > Local Contact: ~32 bytes > Remote Contact: ~32 bytes > Route Set (~74 bytes x 3 proxies): ~222 bytes > Two CSeqs: 4 bytes > > That's about 346 bytes. To make the math easy, let's be sloppy and > assume that miscellaneous overhead bumps this all the way to 512 > bytes per dialog. > > That means that, in the 8 GB of RAM that my laptop has, I could > store state for 16 million dialogs. In the 32-GB server-class boxes > that I'm used to dimensioning for, it would take only 5 servers to > store a dialog for every man, woman, child, and newborn baby in the > U.S. -- or 20 servers to do the same thing for China. It would take > a hair over 100 such servers to do this for every living human being. > > That's assuming we need to keep everything in actual wired RAM. If > we're allowed to swap the data out to a pair of 2 TB hard drives > (possibly sensible if the traffic is as low as you imply), this > state -- one subscription for every human currently alive -- all > fits on a single server. > > When you're talking about network servers, memory is cheap, and hard > drives are cheaper. Standardization and implementation is expensive. Yes. One of our eqiopment has the similar memory consuming statistics. While memory is just one apsect of resource consuming. Further, t one equipment would have other tasks, such as call control, services and so on. So, the capacity of one equipment might not be so ideal. > So, I'm a bit doubtful that it would be a good investment on > anyone's part to come up with a simplified model for RFC3265 subscriptions. In fact, doing a practical performance analysis is hard, and it would be implementation specific. So, I suggest to evaluate it by relative compare: Considering one Event Packages, having the similar (call) arrival rate and longer holding time(some event types has much longer holding time than session) than session usage(INVITE), if we allow out-of-dialog notification, we might save resource consuming as much as(or more than) the whole session siganlling. In fact, I am not going to change the RFC3265 track a lot. I'd like to make it optional for some specific Event Packages. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0028818D4825780F_= Content-Type: text/html; charset="US-ASCII"
Hi Adam,

> I'll echo what has already been said: the notifications need some
> kind of correlation to match the subscription. The dialog provides
> this. You might be able to shave the state down a bit, but since the
> correlation needs to be unique (in the entire universe, forever),
> you probably can't make it much smaller than it already is.
>
> Without an explicit correlation between the subscribe and the
> NOTIFY, the only identifier you could use is the resource identifier
> itself. As Keith pointed out, we have something that behaves like
> this: PUBLISH. You can use this model, if you'd prefer; replace the
> subscription with provisioning information, and send a PUBLISH when
> you want to update state. And you need to take this with the caveat
> that you lose a bunch of functionality when you go from a
> subscription model to a publication model.

What I suggested is something like PUBLISH(out-of-dialog), but more. IMO, PUBLISH model hasn't define who(identify the subscriber) need which notification(identify the Event type) in PUBLISH usage. My thinking is about SUBSCRIBE model, with out-of-dialog notification for some specific Event Packages.

> But let's back up a bit.
>
> You talk about resource consumption as it pertains to a
> subscription; in particular, the dialog state required to keep this
> kind of information in memory. I'd like to do a back-of-the-napkin
> calculation to understand the issue. Dialogs are identified by to-
> tag, from-tag and call-id. On top of that, they must maintain a
> route set (including the Contacts) and two CSeqs (one for each direction).
>
> I'll grab a random wire trace to get a feel for the size of this information.
>
> To (with tag): ~16 bytes
> From (with tag): ~16 bytes
> Call-Id: ~24 bytes
> Local Contact: ~32 bytes
> Remote Contact: ~32 bytes
> Route Set (~74 bytes x 3 proxies): ~222 bytes
> Two CSeqs: 4 bytes
>
> That's about 346 bytes. To make the math easy, let's be sloppy and
> assume that miscellaneous overhead bumps this all the way to 512
> bytes per dialog.
>
> That means that, in the 8 GB of RAM that my laptop has, I could
> store state for 16 million dialogs. In the 32-GB server-class boxes
> that I'm used to dimensioning for, it would take only 5 servers to
> store a dialog for every man, woman, child, and newborn baby in the
> U.S. -- or 20 servers to do the same thing for China. It would take
> a hair over 100 such servers to do this for every living human being.
>
> That's assuming we need to keep everything in actual wired RAM. If
> we're allowed to swap the data out to a pair of 2 TB hard drives
> (possibly sensible if the traffic is as low as you imply), this
> state -- one subscription for every human currently alive -- all
> fits on a single server.
>
> When you're talking about network servers, memory is cheap, and hard
> drives are cheaper. Standardization and implementation is expensive.

Yes. One of our eqiopment has the similar memory consuming statistics.

While memory is just one apsect of resource consuming. Further, t one equipment would have other tasks, such as call control, services and so on. So, the capacity of one equipment might not be so ideal.

> So, I'm a bit doubtful that it would be a good investment on
> anyone's part to come up with a simplified model for RFC3265 subscriptions.

In fact, doing a practical performance analysis is hard, and it would be implementation specific. So, I suggest to evaluate it by relative compare:

Considering one Event Packages, having the similar (call) arrival rate and longer holding time(some event types has much longer holding time than session) than session usage(INVITE), if we allow out-of-dialog notification, we might save resource consuming as much as(or more than) the whole session siganlling.

In fact, I am not going to change the RFC3265 track a lot. I'd like to make it optional for some specific Event Packages.

Thanks,

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0028818D4825780F_=-- From ian_elz@yahoo.co.uk Fri Jan 7 02:14:28 2011 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 AB2BD3A6816 for ; Fri, 7 Jan 2011 02:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 WHEBPrkHcHhO for ; Fri, 7 Jan 2011 02:14:27 -0800 (PST) Received: from nm9-vm1.bullet.mail.ird.yahoo.com (nm9-vm1.bullet.mail.ird.yahoo.com [77.238.189.94]) by core3.amsl.com (Postfix) with SMTP id 7292A3A6809 for ; Fri, 7 Jan 2011 02:14:27 -0800 (PST) Received: from [77.238.189.49] by nm9.bullet.mail.ird.yahoo.com with NNFMP; 07 Jan 2011 10:16:33 -0000 Received: from [212.82.108.253] by tm2.bullet.mail.ird.yahoo.com with NNFMP; 07 Jan 2011 10:16:33 -0000 Received: from [127.0.0.1] by omp1018.mail.ird.yahoo.com with NNFMP; 07 Jan 2011 10:16:33 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 886834.80618.bm@omp1018.mail.ird.yahoo.com Received: (qmail 8018 invoked by uid 60001); 7 Jan 2011 10:16:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1294395393; bh=IenLpGmLzqxSp2Ss2mB6Dsthcc1pbs8HdgjD7V+AKIk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4Go/K89Xhlz8T1DJT+39eEBNBM76ADtmCU8OCGDR/2/Edvxt8Hyq4Pmq6a92WOrg/IIUYSRyAL8vpllUbYXOJD0UtSSmelsM1b0AxH41LBp4RybansE+5Y6CPGjy6V7/mZiPOEY6KohRjxVhzeJxyzV04PDGc27n8Kj/DFWfQI8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mNoUj0MDdd6UZVWpxHCYq8RCQdN486303Sv7FtaF+p7szPsVNiaRm4yB4a9j5C3+ObIRbMZjdW+bxfhBK5xASMfnq2V3dglDugSOohOLQR/9ifAF34FnwKZRHKJ1KNjXoxYrcTPV4z9f4smpsVgOHBmJ5HG9bw0MgvOj9oQGb0Y=; Message-ID: <708509.95091.qm@web29108.mail.ird.yahoo.com> X-YMail-OSG: CyEZQE0VM1l8KXMmlT7XBRkR2i1c79PXhmavF2CglY8yo4c 6EiomMw6sw1q9LWyIggWokFR3CWMQZoL7vRv33bYBtGJE1dHSxpb6Tzg7xBX R.C5E9aGRAqbzh.OdxleCrBAKSw1PvhMMU6xG3DRv_fp3bLQz8.ZXz8WCfxf cxyuhsRBrbwLtQN6EMPaqFTVNXzzgph743oOGsSm14j9ny2WYtLhSRUmBFTq 5wWmL4fgpmWNawA-- Received: from [80.231.29.20] by web29108.mail.ird.yahoo.com via HTTP; Fri, 07 Jan 2011 10:16:33 GMT X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: Date: Fri, 7 Jan 2011 10:16:33 +0000 (GMT) From: Ian Elz To: sipcore@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-783946972-1294395393=:95091" Subject: [sipcore] Third Pary Privacy in SIP 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, 07 Jan 2011 10:14:28 -0000 --0-783946972-1294395393=:95091 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All,=0A=0AI raised the issue of 3rd party identity privacy in SIP as part o= f the initial =0Adraft 4424bis discussions.=0A=0AThe issue arises as the ex= isting Privacy mechanism as defined in RFC3323 only =0Aconsiders privacy fo= r identities for the parties involved in the dialog/session. =0AThis occurs= as when RFC3323 was written there was no concept of inclusion of 3rd =0Apa= rty identities in the SIP messages. RFC4424, History-info, and the 4424bis = =0Adraft do consider the 3rd party privacy but only from the context of ide= ntities =0Aincluded in the H-I entries. The key header which currently has = no privacy =0Amechanism is Referred-by but a more flexible mechanism, backw= ardly compatible =0Awith the existing RFCs, could also be applicable to fut= ure extensions.=0A=0ABefore I attempt to begin this task I have three quest= ions:=0A=0A1. Is this worth pursuing?=0A=0A2. Is sipcore the correct place = for this discussion or should this issue be =0Araised via dispatch with the= possibility of a new WG for this work? (and all the =0Aassociated stuff re= lating =0A=0A=0A3. Should this work be a new draft which is addative to the= existing RFC3325 and =0Athe associated changes for the 'id' privacy in RFC= 3325 or should a new Privacy =0Adraft be written which includes all the exi= sting RFC3323 and RFC3325 =0Ainformation? ( There may be an issue with the = latter in that RFC3325 is =0AInformational as it realtes to the P- header "= P-Asserted-Identity".)=0A=0A=0AIan Elz=0A=0A=0A=0A --0-783946972-1294395393=:95091 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
All,

I raised the issue of 3rd party identity privacy in SIP= as part of the initial draft 4424bis discussions.

The issue arises = as the existing Privacy mechanism as defined in RFC3323 only considers priv= acy for identities for the parties involved in the dialog/session. This occ= urs as when RFC3323 was written there was no concept of inclusion of 3rd pa= rty identities in the SIP messages. RFC4424, History-info, and the 4424bis = draft do consider the 3rd party privacy but only from the context of identi= ties included in the H-I entries. The key header which currently has no pri= vacy mechanism is Referred-by but a more flexible mechanism, backwardly com= patible with the existing RFCs, could also be applicable to future extensio= ns.

Before I attempt to begin this task I have three questions:

1. Is this worth pursuing?

2. Is sipcore the corr= ect place for this discussion or should this issue be raised via dispatch w= ith the possibility of a new WG for this work? (and all the associated stuf= f relating

3. Should this work be a new draft which is addative to = the existing RFC3325 and the associated changes for the 'id' privacy in RFC= 3325 or should a new Privacy draft be written which includes all the existi= ng RFC3323 and RFC3325 information? ( There may be an issue with the latter= in that RFC3325 is Informational as it realtes to the P- header "P-Asserte= d-Identity".)

Ian Elz
=0A

=0A=0A=0A=0A --0-783946972-1294395393=:95091-- From john.elwell@siemens-enterprise.com Fri Jan 7 02:20:46 2011 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 0CCB93A6803 for ; Fri, 7 Jan 2011 02:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 DDTBRG+RloBj for ; Fri, 7 Jan 2011 02:20:43 -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 A20F83A67F9 for ; Fri, 7 Jan 2011 02:20:41 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2922031; Fri, 7 Jan 2011 11:22:43 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E9A7423F0278; Fri, 7 Jan 2011 11:22:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 Jan 2011 11:22:43 +0100 From: "Elwell, John" To: Ian Elz , "sipcore@ietf.org" Date: Fri, 7 Jan 2011 11:22:42 +0100 Thread-Topic: [sipcore] Third Pary Privacy in SIP Thread-Index: AcuuU/lXyZResuFrRKa6ht1i4BtBiAAAHQQQ Message-ID: References: <708509.95091.qm@web29108.mail.ird.yahoo.com> In-Reply-To: <708509.95091.qm@web29108.mail.ird.yahoo.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 Subject: Re: [sipcore] Third Pary Privacy in SIP 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, 07 Jan 2011 10:20:46 -0000 Ian, Concerning your first question, perhaps a short I-D describing the problem = would be a way to solicit answers. I would say submit it to DISPATCH. It i= s too early to consider your third question. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > Sent: 07 January 2011 10:17 > To: sipcore@ietf.org > Subject: [sipcore] Third Pary Privacy in SIP >=20 > All, >=20 > I raised the issue of 3rd party identity privacy in SIP as=20 > part of the initial draft 4424bis discussions. >=20 > The issue arises as the existing Privacy mechanism as defined=20 > in RFC3323 only considers privacy for identities for the=20 > parties involved in the dialog/session. This occurs as when=20 > RFC3323 was written there was no concept of inclusion of 3rd=20 > party identities in the SIP messages. RFC4424, History-info,=20 > and the 4424bis draft do consider the 3rd party privacy but=20 > only from the context of identities included in the H-I=20 > entries. The key header which currently has no privacy=20 > mechanism is Referred-by but a more flexible mechanism,=20 > backwardly compatible with the existing RFCs, could also be=20 > applicable to future extensions. >=20 > Before I attempt to begin this task I have three questions: >=20 > 1. Is this worth pursuing? >=20 > 2. Is sipcore the correct place for this discussion or should=20 > this issue be raised via dispatch with the possibility of a=20 > new WG for this work? (and all the associated stuff relating=20 >=20 > 3. Should this work be a new draft which is addative to the=20 > existing RFC3325 and the associated changes for the 'id'=20 > privacy in RFC3325 or should a new Privacy draft be written=20 > which includes all the existing RFC3323 and RFC3325=20 > information? ( There may be an issue with the latter in that=20 > RFC3325 is Informational as it realtes to the P- header=20 > "P-Asserted-Identity".) >=20 >=20 > Ian Elz >=20 >=20 > = From pkyzivat@cisco.com Fri Jan 7 06:54:53 2011 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 24F2D3A68EE for ; Fri, 7 Jan 2011 06:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 y6cl362FZPrI for ; Fri, 7 Jan 2011 06:54: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 CB58F3A68E9 for ; Fri, 7 Jan 2011 06:54:51 -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: AgEGAMa4Jk1AZnwN/2dsb2JhbACWGI4Pc6NnmDeCdYJXBIRnhiKDHg Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2011 14:56:58 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07Euwd8022759 for ; Fri, 7 Jan 2011 14:56:58 GMT Message-ID: <4D2729BA.4020202@cisco.com> Date: Fri, 07 Jan 2011 09:56:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <708509.95091.qm@web29108.mail.ird.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Third Pary Privacy in SIP 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, 07 Jan 2011 14:54:53 -0000 +1 On 1/7/2011 5:22 AM, Elwell, John wrote: > Ian, > > Concerning your first question, perhaps a short I-D describing the problem would be a way to solicit answers. I would say submit it to DISPATCH. It is too early to consider your third question. > > John > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz >> Sent: 07 January 2011 10:17 >> To: sipcore@ietf.org >> Subject: [sipcore] Third Pary Privacy in SIP >> >> All, >> >> I raised the issue of 3rd party identity privacy in SIP as >> part of the initial draft 4424bis discussions. >> >> The issue arises as the existing Privacy mechanism as defined >> in RFC3323 only considers privacy for identities for the >> parties involved in the dialog/session. This occurs as when >> RFC3323 was written there was no concept of inclusion of 3rd >> party identities in the SIP messages. RFC4424, History-info, >> and the 4424bis draft do consider the 3rd party privacy but >> only from the context of identities included in the H-I >> entries. The key header which currently has no privacy >> mechanism is Referred-by but a more flexible mechanism, >> backwardly compatible with the existing RFCs, could also be >> applicable to future extensions. >> >> Before I attempt to begin this task I have three questions: >> >> 1. Is this worth pursuing? >> >> 2. Is sipcore the correct place for this discussion or should >> this issue be raised via dispatch with the possibility of a >> new WG for this work? (and all the associated stuff relating >> >> 3. Should this work be a new draft which is addative to the >> existing RFC3325 and the associated changes for the 'id' >> privacy in RFC3325 or should a new Privacy draft be written >> which includes all the existing RFC3323 and RFC3325 >> information? ( There may be an issue with the latter in that >> RFC3325 is Informational as it realtes to the P- header >> "P-Asserted-Identity".) >> >> >> Ian Elz >> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From Internet-Drafts@ietf.org Mon Jan 10 11:30:04 2011 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 E852C28C113; Mon, 10 Jan 2011 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 6rgaAqbrni1C; Mon, 10 Jan 2011 11:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FAA28C0EF; Mon, 10 Jan 2011 11:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110193001.1186.95837.idtracker@localhost> Date: Mon, 10 Jan 2011 11:30:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-11.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, 10 Jan 2011 19:30:04 -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 : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-11.txt Pages : 18 Date : 2011-01-10 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-11.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-keep-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10111538.I-D@ietf.org> --NextPart-- From richard@shockey.us Tue Jan 11 08:21:47 2011 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 9E7AA28C2DF for ; Tue, 11 Jan 2011 08:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 TwgrHEjlqAG5 for ; Tue, 11 Jan 2011 08:21:43 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 455943A6A3C for ; Tue, 11 Jan 2011 08:21:43 -0800 (PST) Received: (qmail 18157 invoked by uid 0); 11 Jan 2011 16:24:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 11 Jan 2011 16:24:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=jQfvCNzb7I04p4PSJeFCeBt6kDyhKxvrfbxM2zhbyTbjdLDzJsj87M42uq7hBHrOXGfD4d1ump1c1Rxr1jKk8y3bBU2mNvsDXxcNmoexsZjRPS+pBRWf59W1F8TmNP2H; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pch0p-0005W4-OZ; Tue, 11 Jan 2011 09:24:00 -0700 From: "Richard Shockey" To: , Date: Tue, 11 Jan 2011 11:23:57 -0500 Message-ID: <014e01cbb1ab$f356d830$da048890$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014F_01CBB182.0A80D030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuxq/KbagRQnPNeSGOIllp3Z4bErg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: [sipcore] The SIP Forum announces the SIPNOC conference 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, 11 Jan 2011 16:21:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_014F_01CBB182.0A80D030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SIP Forum Launches SIPNOC -- SIP Network Operators Conference -- for the Worldwide Service Provider Community New two-day educational conference for service providers to focus on how to "make SIP work in the network" and address the key operational issues facing SIP in today's telecom world NORTH ANDOVER, MA (January 11, 2011) - The SIP Forum announced today the SIP Network Operators Conference (SIPNOC), a new annual conference for the international service provider community. The two-day conference will bring together the leading technical minds from the telecommunications industry to learn, discuss and formulate new ideas and strategies concerning the challenges and opportunities for SIP-based carrier services in fixed and mobile IP network environments. Unlike other events, this conference is for SIP network operations personnel, such as NOC engineers, instead of a high-level conference for executives. The first SIPNOC 2011 conference will be held at the Hyatt Dulles Hotel in Herndon, VA April 25 -27, 2011. The event website is located at www.sipnoc.org. http://www.sipforum.org/content/view/372/43/ Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_014F_01CBB182.0A80D030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The SIP Forum Launches = SIPNOC -- SIP Network Operators Conference -- for the Worldwide Service Provider = Community

New two-day educational = conference for service providers to focus on how to “make SIP work in the = network” and address the key operational issues facing SIP in today’s = telecom world

NORTH ANDOVER, MA (January 11, 2011) - The SIP Forum announced = today the SIP Network Operators Conference (SIPNOC), a new annual conference = for the international service provider community. The two-day conference will = bring together the leading technical minds from the telecommunications = industry to learn, discuss and formulate new ideas and strategies concerning the = challenges and opportunities for SIP-based carrier services in fixed and mobile IP = network environments. Unlike other events, this conference is for SIP network operations personnel, such as NOC engineers, instead of a high-level = conference for executives. The first SIPNOC 2011 conference will be held at the = Hyatt Dulles Hotel in Herndon, VA April 25 -27, 2011. The event website is = located at www.sipnoc.org.

 

http://www.sipforum.org/content/view/372/43/=

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_014F_01CBB182.0A80D030-- From aallen@rim.com Tue Jan 11 08:40:35 2011 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 6D0703A67FD for ; Tue, 11 Jan 2011 08:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 tnYdLgK6eIUA for ; Tue, 11 Jan 2011 08:40:34 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 4B6793A6A49 for ; Tue, 11 Jan 2011 08:40:33 -0800 (PST) X-AuditID: 0a666446-b7b7dae000003392-71-4d2c8889491e Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 5B.3D.13202.9888C2D4; Tue, 11 Jan 2011 11:42:49 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Jan 2011 11:42:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB1AE.93940934" x-cr-hashedpuzzle: AGXx Aya5 B2i/ CVKt EKH0 E2L3 FHJH Ge2F Gh79 GoHm Hbs7 HwGE ItzE JKQE J8ma KNJd; 1; cwBpAHAAYwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DDFA3726-E8A0-4CFC-81AF-DBCB79AD6EB2}; YQBhAGwAbABlAG4AQAByAGkAbQAuAGMAbwBtAA==; Tue, 11 Jan 2011 16:42:43 GMT; UgBlAHYAaQBzAGkAbwBuACAAbwBmACAAZAByAGEAZgB0AC0AYQBsAGwAZQBuAC0AZABpAHMAcABhAHQAYwBoAC0AaQBtAGUAaQAtAHUAcgBuAC0AYQBzAC0AaQBuAHMAdABhAG4AYwBlAGkAZAA= x-cr-puzzleid: {DDFA3726-E8A0-4CFC-81AF-DBCB79AD6EB2} Content-class: urn:content-classes:message Date: Tue, 11 Jan 2011 10:42:43 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revision of draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AcuxrpGrhd+7i5rzQgywmekWTlvSqA== From: "Andrew Allen" To: X-OriginalArrivalTime: 11 Jan 2011 16:42:49.0540 (UTC) FILETIME=[952D7040:01CBB1AE] X-Brightmail-Tracker: AAAAAgAAAZEXFZJ3 Subject: [sipcore] Revision of draft-allen-dispatch-imei-urn-as-instanceid 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, 11 Jan 2011 16:40:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB1AE.93940934 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable A revised version of draft-allen-dispatch-imei-urn-as-instanceid has just been submitted. It can be located at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-02.tx t This addresses all the editorial comments provided by Dale Worley. I believe that this version now addresses all the comments received on the list (provided by Dale and Paul Kyzivat). Recently a revised version of draft-montemurro-gsma-imei-urn that is referenced by the draft and addresses the comments on the BNF provided by Dale Worley was also submitted. It can be located at http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-06.txt ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBB1AE.93940934 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

A revised version of draft-allen-dispatch-imei-urn-as-i= nstanceid has just been submitted.

 

It can be located at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-02= .txt

 

This addresses all the editorial comments provided by D= ale Worley. I believe that this version now addresses all the comments received= on the list (provided by Dale and Paul Kyzivat).

 

Recently a revised version of draft-montemurro-gsma-ime= i-urn that is referenced by the draft and addresses the comments on the BNF provid= ed by Dale Worley was also submitted.

 

It can be located at http:/= /www.ietf.org/id/draft-montemurro-gsma-imei-urn-06.txt

 

 

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBB1AE.93940934-- From gao.yang2@zte.com.cn Wed Jan 12 01:09:33 2011 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 1C6463A69F9 for ; Wed, 12 Jan 2011 01:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.52 X-Spam-Level: X-Spam-Status: No, score=-98.52 tagged_above=-999 required=5 tests=[AWL=-2.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, 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 OYsuz8JewYem for ; Wed, 12 Jan 2011 01:09:31 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D5A3A3A681B for ; Wed, 12 Jan 2011 01:09:30 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Wed, 12 Jan 2011 17:09:55 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 96520.7255492701; Wed, 12 Jan 2011 17:11:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p0C9BGt1095711; Wed, 12 Jan 2011 17:11:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Adam Roach , Paul Kyzivat , "Worley, Dale R (Dale)" , Christer Holmberg MIME-Version: 1.0 X-KeepSent: 17380627:573A6541-48257816:0030DFC0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 12 Jan 2011 17:08:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-12 17:11:02, Serialize complete at 2011-01-12 17:11:02 Content-Type: multipart/alternative; boundary="=_alternative 003277E848257816_=" X-MAIL: mse3.zte.com.cn p0C9BGt1095711 Cc: sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 12 Jan 2011 09:09:33 -0000 This is a multipart message in MIME format. --=_alternative 003277E848257816_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkl0IHNlZW1zIHRoYXQgd2UgaGF2ZW4ndCByZWFjaGVkIGFuIGFncmVlbWVudCBmb3Ig dGhpcyB0b3BpYy4gSSdkIGxpa2UgdG8gDQpwdXQgdG9nZXRoZXIgYSBkaXNjdXNzaW9uIHRleHQg Zm9yIHRoaXMgaXNzdWUsIGluY2x1ZGluZzoNCg0KMS4gVHlwaWNhbCB0cmFmZmljIG1vZGVsIGZv ciBTVUJTQ1JJQkUgYW5kIE5vdGlmaWNhdGlvbiBhbmQgUGVyZm9ybWFuY2UgDQphbmFseXNpczsN CjIuIE91dC1vZi1EaWFsb2cgTm90aWZhY3Rpb24gb3B0aW9uYWwgc29sdXRpb25zOw0KMy4gSW50 ZXJ3b3JraW5nIGFuZCBjb21wYXRpYmlsaXR5LiANCg0KV291bGQgdGhpcyB0b3BpYyB3ZWxjb21l IGluIHRoZSBjb21pbmcgSUVURiBtZWV0aW5nIGluIEN6ZWNoPw0KDQpUaGFua3MsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0K IFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Ci0tLS0tINeqt6LIyyC439HvMTQwMTk3L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTEtMDEtMTIgMTY6 NTYgLS0tLS0NCg0KuN/R7zE0MDE5Ny91c2VyL3p0ZV9sdGQNCjIwMTEtMDEtMDUgMTU6MTkNCg0K ytW8/sjLDQpBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPg0Ks63LzQ0Kc2lwY29yZUBpZXRm Lm9yZw0K1vfM4g0KUmU6IEFib3V0IFNVQlNDUklCRSBtZXRob2QncyBwZXJmb3JtYW5jZSBhbmQg T3V0LW9mLURpYWxvZyBub3RpZmljYXRpb24gDQpzdWdnZXN0aW9uOg0KDQoNCg0KDQoNCg0KSGkg QWRhbSwNCg0KPiBJJ2xsIGVjaG8gd2hhdCBoYXMgYWxyZWFkeSBiZWVuIHNhaWQ6IHRoZSBub3Rp ZmljYXRpb25zIG5lZWQgc29tZSANCj4ga2luZCBvZiBjb3JyZWxhdGlvbiB0byBtYXRjaCB0aGUg c3Vic2NyaXB0aW9uLiBUaGUgZGlhbG9nIHByb3ZpZGVzIA0KPiB0aGlzLiBZb3UgbWlnaHQgYmUg YWJsZSB0byBzaGF2ZSB0aGUgc3RhdGUgZG93biBhIGJpdCwgYnV0IHNpbmNlIHRoZQ0KPiBjb3Jy ZWxhdGlvbiBuZWVkcyB0byBiZSB1bmlxdWUgKGluIHRoZSBlbnRpcmUgdW5pdmVyc2UsIGZvcmV2 ZXIpLCANCj4geW91IHByb2JhYmx5IGNhbid0IG1ha2UgaXQgbXVjaCBzbWFsbGVyIHRoYW4gaXQg YWxyZWFkeSBpcy4NCj4gDQo+IFdpdGhvdXQgYW4gZXhwbGljaXQgY29ycmVsYXRpb24gYmV0d2Vl biB0aGUgc3Vic2NyaWJlIGFuZCB0aGUgDQo+IE5PVElGWSwgdGhlIG9ubHkgaWRlbnRpZmllciB5 b3UgY291bGQgdXNlIGlzIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyDQo+IGl0c2VsZi4gQXMgS2Vp dGggcG9pbnRlZCBvdXQsIHdlIGhhdmUgc29tZXRoaW5nIHRoYXQgYmVoYXZlcyBsaWtlIA0KPiB0 aGlzOiBQVUJMSVNILiBZb3UgY2FuIHVzZSB0aGlzIG1vZGVsLCBpZiB5b3UnZCBwcmVmZXI7IHJl cGxhY2UgdGhlIA0KPiBzdWJzY3JpcHRpb24gd2l0aCBwcm92aXNpb25pbmcgaW5mb3JtYXRpb24s IGFuZCBzZW5kIGEgUFVCTElTSCB3aGVuIA0KPiB5b3Ugd2FudCB0byB1cGRhdGUgc3RhdGUuIEFu ZCB5b3UgbmVlZCB0byB0YWtlIHRoaXMgd2l0aCB0aGUgY2F2ZWF0IA0KPiB0aGF0IHlvdSBsb3Nl IGEgYnVuY2ggb2YgZnVuY3Rpb25hbGl0eSB3aGVuIHlvdSBnbyBmcm9tIGEgDQo+IHN1YnNjcmlw dGlvbiBtb2RlbCB0byBhIHB1YmxpY2F0aW9uIG1vZGVsLg0KDQpXaGF0IEkgc3VnZ2VzdGVkIGlz IHNvbWV0aGluZyBsaWtlIFBVQkxJU0gob3V0LW9mLWRpYWxvZyksIGJ1dCBtb3JlLiBJTU8sIA0K UFVCTElTSCBtb2RlbCBoYXNuJ3QgZGVmaW5lIHdobyhpZGVudGlmeSB0aGUgc3Vic2NyaWJlcikg bmVlZCB3aGljaCANCm5vdGlmaWNhdGlvbihpZGVudGlmeSB0aGUgRXZlbnQgdHlwZSkgaW4gUFVC TElTSCB1c2FnZS4gTXkgdGhpbmtpbmcgaXMgDQphYm91dCBTVUJTQ1JJQkUgbW9kZWwsIHdpdGgg b3V0LW9mLWRpYWxvZyBub3RpZmljYXRpb24gZm9yIHNvbWUgc3BlY2lmaWMgDQpFdmVudCBQYWNr YWdlcy4NCg0KPiBCdXQgbGV0J3MgYmFjayB1cCBhIGJpdC4NCj4gDQo+IFlvdSB0YWxrIGFib3V0 IHJlc291cmNlIGNvbnN1bXB0aW9uIGFzIGl0IHBlcnRhaW5zIHRvIGEgDQo+IHN1YnNjcmlwdGlv bjsgaW4gcGFydGljdWxhciwgdGhlIGRpYWxvZyBzdGF0ZSByZXF1aXJlZCB0byBrZWVwIHRoaXMg DQo+IGtpbmQgb2YgaW5mb3JtYXRpb24gaW4gbWVtb3J5LiBJJ2QgbGlrZSB0byBkbyBhIGJhY2st b2YtdGhlLW5hcGtpbiANCj4gY2FsY3VsYXRpb24gdG8gdW5kZXJzdGFuZCB0aGUgaXNzdWUuIERp YWxvZ3MgYXJlIGlkZW50aWZpZWQgYnkgdG8tDQo+IHRhZywgZnJvbS10YWcgYW5kIGNhbGwtaWQu IE9uIHRvcCBvZiB0aGF0LCB0aGV5IG11c3QgbWFpbnRhaW4gYSANCj4gcm91dGUgc2V0IChpbmNs dWRpbmcgdGhlIENvbnRhY3RzKSBhbmQgdHdvIENTZXFzIChvbmUgZm9yIGVhY2ggDQpkaXJlY3Rp b24pLg0KPiANCj4gSSdsbCBncmFiIGEgcmFuZG9tIHdpcmUgdHJhY2UgdG8gZ2V0IGEgZmVlbCBm b3IgdGhlIHNpemUgb2YgdGhpcyANCmluZm9ybWF0aW9uLg0KPiANCj4gVG8gKHdpdGggdGFnKTog fjE2IGJ5dGVzDQo+IEZyb20gKHdpdGggdGFnKTogfjE2IGJ5dGVzDQo+IENhbGwtSWQ6IH4yNCBi eXRlcw0KPiBMb2NhbCBDb250YWN0OiB+MzIgYnl0ZXMNCj4gUmVtb3RlIENvbnRhY3Q6IH4zMiBi eXRlcw0KPiBSb3V0ZSBTZXQgKH43NCBieXRlcyB4IDMgcHJveGllcyk6IH4yMjIgYnl0ZXMNCj4g VHdvIENTZXFzOiA0IGJ5dGVzDQo+IA0KPiBUaGF0J3MgYWJvdXQgMzQ2IGJ5dGVzLiBUbyBtYWtl IHRoZSBtYXRoIGVhc3ksIGxldCdzIGJlIHNsb3BweSBhbmQgDQo+IGFzc3VtZSB0aGF0IG1pc2Nl bGxhbmVvdXMgb3ZlcmhlYWQgYnVtcHMgdGhpcyBhbGwgdGhlIHdheSB0byA1MTIgDQo+IGJ5dGVz IHBlciBkaWFsb2cuDQo+IA0KPiBUaGF0IG1lYW5zIHRoYXQsIGluIHRoZSA4IEdCIG9mIFJBTSB0 aGF0IG15IGxhcHRvcCBoYXMsIEkgY291bGQgDQo+IHN0b3JlIHN0YXRlIGZvciAxNiBtaWxsaW9u IGRpYWxvZ3MuIEluIHRoZSAzMi1HQiBzZXJ2ZXItY2xhc3MgYm94ZXMgDQo+IHRoYXQgSSdtIHVz ZWQgdG8gZGltZW5zaW9uaW5nIGZvciwgaXQgd291bGQgdGFrZSBvbmx5IDUgc2VydmVycyB0byAN Cj4gc3RvcmUgYSBkaWFsb2cgZm9yIGV2ZXJ5IG1hbiwgd29tYW4sIGNoaWxkLCBhbmQgbmV3Ym9y biBiYWJ5IGluIHRoZSANCj4gVS5TLiAtLSBvciAyMCBzZXJ2ZXJzIHRvIGRvIHRoZSBzYW1lIHRo aW5nIGZvciBDaGluYS4gSXQgd291bGQgdGFrZSANCj4gYSBoYWlyIG92ZXIgMTAwIHN1Y2ggc2Vy dmVycyB0byBkbyB0aGlzIGZvciBldmVyeSBsaXZpbmcgaHVtYW4gYmVpbmcuDQo+IA0KPiBUaGF0 J3MgYXNzdW1pbmcgd2UgbmVlZCB0byBrZWVwIGV2ZXJ5dGhpbmcgaW4gYWN0dWFsIHdpcmVkIFJB TS4gSWYgDQo+IHdlJ3JlIGFsbG93ZWQgdG8gc3dhcCB0aGUgZGF0YSBvdXQgdG8gYSBwYWlyIG9m IDIgVEIgaGFyZCBkcml2ZXMgDQo+IChwb3NzaWJseSBzZW5zaWJsZSBpZiB0aGUgdHJhZmZpYyBp cyBhcyBsb3cgYXMgeW91IGltcGx5KSwgdGhpcyANCj4gc3RhdGUgLS0gb25lIHN1YnNjcmlwdGlv biBmb3IgZXZlcnkgaHVtYW4gY3VycmVudGx5IGFsaXZlIC0tIGFsbCANCj4gZml0cyBvbiBhIHNp bmdsZSBzZXJ2ZXIuDQo+IA0KPiBXaGVuIHlvdSdyZSB0YWxraW5nIGFib3V0IG5ldHdvcmsgc2Vy dmVycywgbWVtb3J5IGlzIGNoZWFwLCBhbmQgaGFyZA0KPiBkcml2ZXMgYXJlIGNoZWFwZXIuIFN0 YW5kYXJkaXphdGlvbiBhbmQgaW1wbGVtZW50YXRpb24gaXMgZXhwZW5zaXZlLg0KDQpZZXMuIE9u ZSBvZiBvdXIgZXFpb3BtZW50IGhhcyB0aGUgc2ltaWxhciBtZW1vcnkgY29uc3VtaW5nIHN0YXRp c3RpY3MuDQoNCldoaWxlIG1lbW9yeSBpcyBqdXN0IG9uZSBhcHNlY3Qgb2YgcmVzb3VyY2UgY29u c3VtaW5nLiBGdXJ0aGVyLCB0IG9uZSANCmVxdWlwbWVudCB3b3VsZCBoYXZlIG90aGVyIHRhc2tz LCBzdWNoIGFzIGNhbGwgY29udHJvbCwgc2VydmljZXMgYW5kIHNvIA0Kb24uIFNvLCB0aGUgY2Fw YWNpdHkgb2Ygb25lIGVxdWlwbWVudCBtaWdodCBub3QgYmUgc28gaWRlYWwuDQoNCj4gU28sIEkn bSBhIGJpdCBkb3VidGZ1bCB0aGF0IGl0IHdvdWxkIGJlIGEgZ29vZCBpbnZlc3RtZW50IG9uIA0K PiBhbnlvbmUncyBwYXJ0IHRvIGNvbWUgdXAgd2l0aCBhIHNpbXBsaWZpZWQgbW9kZWwgZm9yIFJG QzMyNjUgDQpzdWJzY3JpcHRpb25zLg0KDQpJbiBmYWN0LCBkb2luZyBhIHByYWN0aWNhbCBwZXJm b3JtYW5jZSBhbmFseXNpcyBpcyBoYXJkLCBhbmQgaXQgd291bGQgYmUgDQppbXBsZW1lbnRhdGlv biBzcGVjaWZpYy4gU28sIEkgc3VnZ2VzdCB0byBldmFsdWF0ZSBpdCBieSByZWxhdGl2ZSBjb21w YXJlOg0KDQpDb25zaWRlcmluZyBvbmUgRXZlbnQgUGFja2FnZXMsIGhhdmluZyB0aGUgc2ltaWxh ciAoY2FsbCkgYXJyaXZhbCByYXRlIGFuZCANCmxvbmdlciBob2xkaW5nIHRpbWUoc29tZSBldmVu dCB0eXBlcyBoYXMgbXVjaCBsb25nZXIgaG9sZGluZyB0aW1lIHRoYW4gDQpzZXNzaW9uKSB0aGFu IHNlc3Npb24gdXNhZ2UoSU5WSVRFKSwgaWYgd2UgYWxsb3cgb3V0LW9mLWRpYWxvZyANCm5vdGlm aWNhdGlvbiwgd2UgbWlnaHQgc2F2ZSByZXNvdXJjZSBjb25zdW1pbmcgYXMgbXVjaCBhcyhvciBt b3JlIHRoYW4pIA0KdGhlIHdob2xlIHNlc3Npb24gc2lnYW5sbGluZy4NCg0KSW4gZmFjdCwgSSBh bSBub3QgZ29pbmcgdG8gY2hhbmdlIHRoZSBSRkMzMjY1IHRyYWNrIGEgbG90LiBJJ2QgbGlrZSB0 byANCm1ha2UgaXQgb3B0aW9uYWwgZm9yIHNvbWUgc3BlY2lmaWMgRXZlbnQgUGFja2FnZXMuDQoN ClRoYW5rcywNCg0KR2FvDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003277E848257816_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SXQgc2VlbXMgdGhhdCB3ZSBoYXZlbid0 IHJlYWNoZWQgYW4NCmFncmVlbWVudCBmb3IgdGhpcyB0b3BpYy4gSSdkIGxpa2UgdG8gcHV0IHRv Z2V0aGVyIGEgZGlzY3Vzc2lvbiB0ZXh0IGZvcg0KdGhpcyBpc3N1ZSwgaW5jbHVkaW5nOjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gVHlwaWNhbCB0 cmFmZmljIG1vZGVsIGZvciBTVUJTQ1JJQkUNCmFuZCBOb3RpZmljYXRpb24gYW5kIFBlcmZvcm1h bmNlIGFuYWx5c2lzOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Mi4gT3V0LW9mLURpYWxvZyBOb3RpZmFjdGlvbiBvcHRpb25hbA0Kc29sdXRpb25zOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4gSW50ZXJ3b3JraW5nIGFuZCBj b21wYXRpYmlsaXR5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPldvdWxkIHRoaXMgdG9waWMgd2VsY29tZSBpbiB0aGUgY29taW5nDQpJRVRGIG1lZXRp bmcgaW4gQ3plY2g/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5i c3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsg uN/R7zE0MDE5Ny91c2VyL3p0ZV9sdGQNCsqxvOQgMjAxMS0wMS0xMiAxNjo1NiAtLS0tLTwvZm9u dD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj6439HvMTQwMTk3L3VzZXIvenRl X2x0ZDwvYj48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0w MS0wNSAxNToxOTwvZm9udD4NCjx0ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5BZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IEFib3V0IFNV QlNDUklCRSBtZXRob2QncyBwZXJmb3JtYW5jZQ0KYW5kIE91dC1vZi1EaWFsb2cgbm90aWZpY2F0 aW9uIHN1Z2dlc3Rpb246PC9mb250PjxhIGhyZWY9Tm90ZXM6Ly9OSk1BSUwwMS80ODI1NzE2OTAw MkRGOEVFL0RBQkE5NzVCOUZCMTEzRUI4NTI1NjRCNTAwMTI4M0VBLzQ4Qzc0NDM5MUREQzczMjA0 ODI1NzgwRTAwODJFOUUyPsG0vdM8L2E+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkhpIEFkYW0sPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj48YnI+DQomZ3Q7IEknbGwgZWNobyB3aGF0IGhhcyBhbHJlYWR5IGJlZW4gc2FpZDogdGhl IG5vdGlmaWNhdGlvbnMgbmVlZCBzb21lDQo8YnI+DQomZ3Q7IGtpbmQgb2YgY29ycmVsYXRpb24g dG8gbWF0Y2ggdGhlIHN1YnNjcmlwdGlvbi4gVGhlIGRpYWxvZyBwcm92aWRlcw0KPGJyPg0KJmd0 OyB0aGlzLiBZb3UgbWlnaHQgYmUgYWJsZSB0byBzaGF2ZSB0aGUgc3RhdGUgZG93biBhIGJpdCwg YnV0IHNpbmNlIHRoZTxicj4NCiZndDsgY29ycmVsYXRpb24gbmVlZHMgdG8gYmUgdW5pcXVlIChp biB0aGUgZW50aXJlIHVuaXZlcnNlLCBmb3JldmVyKSwNCjxicj4NCiZndDsgeW91IHByb2JhYmx5 IGNhbid0IG1ha2UgaXQgbXVjaCBzbWFsbGVyIHRoYW4gaXQgYWxyZWFkeSBpcy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgV2l0aG91dCBhbiBleHBsaWNpdCBjb3JyZWxhdGlvbiBiZXR3ZWVuIHRoZSBz dWJzY3JpYmUgYW5kIHRoZSA8YnI+DQomZ3Q7IE5PVElGWSwgdGhlIG9ubHkgaWRlbnRpZmllciB5 b3UgY291bGQgdXNlIGlzIHRoZSByZXNvdXJjZSBpZGVudGlmaWVyPGJyPg0KJmd0OyBpdHNlbGYu IEFzIEtlaXRoIHBvaW50ZWQgb3V0LCB3ZSBoYXZlIHNvbWV0aGluZyB0aGF0IGJlaGF2ZXMgbGlr ZQ0KPGJyPg0KJmd0OyB0aGlzOiBQVUJMSVNILiBZb3UgY2FuIHVzZSB0aGlzIG1vZGVsLCBpZiB5 b3UnZCBwcmVmZXI7IHJlcGxhY2UgdGhlDQo8YnI+DQomZ3Q7IHN1YnNjcmlwdGlvbiB3aXRoIHBy b3Zpc2lvbmluZyBpbmZvcm1hdGlvbiwgYW5kIHNlbmQgYSBQVUJMSVNIIHdoZW4NCjxicj4NCiZn dDsgeW91IHdhbnQgdG8gdXBkYXRlIHN0YXRlLiBBbmQgeW91IG5lZWQgdG8gdGFrZSB0aGlzIHdp dGggdGhlIGNhdmVhdA0KPGJyPg0KJmd0OyB0aGF0IHlvdSBsb3NlIGEgYnVuY2ggb2YgZnVuY3Rp b25hbGl0eSB3aGVuIHlvdSBnbyBmcm9tIGEgPGJyPg0KJmd0OyBzdWJzY3JpcHRpb24gbW9kZWwg dG8gYSBwdWJsaWNhdGlvbiBtb2RlbC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPldoYXQgSSBzdWdnZXN0ZWQgaXMgc29tZXRoaW5nIGxpa2UgUFVCTElTSChvdXQtb2Yt ZGlhbG9nKSwNCmJ1dCBtb3JlLiBJTU8sIFBVQkxJU0ggbW9kZWwgaGFzbid0IGRlZmluZSB3aG8o aWRlbnRpZnkgdGhlIHN1YnNjcmliZXIpDQpuZWVkIHdoaWNoIG5vdGlmaWNhdGlvbihpZGVudGlm eSB0aGUgRXZlbnQgdHlwZSkgaW4gUFVCTElTSCB1c2FnZS4gTXkgdGhpbmtpbmcNCmlzIGFib3V0 IFNVQlNDUklCRSBtb2RlbCwgd2l0aCBvdXQtb2YtZGlhbG9nIG5vdGlmaWNhdGlvbiBmb3Igc29t ZSBzcGVjaWZpYw0KRXZlbnQgUGFja2FnZXMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj48YnI+DQomZ3Q7IEJ1dCBsZXQncyBiYWNrIHVwIGEgYml0Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBZb3UgdGFsayBhYm91dCByZXNvdXJjZSBjb25zdW1wdGlvbiBhcyBpdCBwZXJ0YWlucyB0 byBhIDxicj4NCiZndDsgc3Vic2NyaXB0aW9uOyBpbiBwYXJ0aWN1bGFyLCB0aGUgZGlhbG9nIHN0 YXRlIHJlcXVpcmVkIHRvIGtlZXAgdGhpcw0KPGJyPg0KJmd0OyBraW5kIG9mIGluZm9ybWF0aW9u IGluIG1lbW9yeS4gSSdkIGxpa2UgdG8gZG8gYSBiYWNrLW9mLXRoZS1uYXBraW4NCjxicj4NCiZn dDsgY2FsY3VsYXRpb24gdG8gdW5kZXJzdGFuZCB0aGUgaXNzdWUuIERpYWxvZ3MgYXJlIGlkZW50 aWZpZWQgYnkgdG8tPGJyPg0KJmd0OyB0YWcsIGZyb20tdGFnIGFuZCBjYWxsLWlkLiBPbiB0b3Ag b2YgdGhhdCwgdGhleSBtdXN0IG1haW50YWluIGEgPGJyPg0KJmd0OyByb3V0ZSBzZXQgKGluY2x1 ZGluZyB0aGUgQ29udGFjdHMpIGFuZCB0d28gQ1NlcXMgKG9uZSBmb3IgZWFjaCBkaXJlY3Rpb24p Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJJ2xsIGdyYWIgYSByYW5kb20gd2lyZSB0cmFjZSB0byBn ZXQgYSBmZWVsIGZvciB0aGUgc2l6ZSBvZiB0aGlzIGluZm9ybWF0aW9uLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBUbyAod2l0aCB0YWcpOiB+MTYgYnl0ZXM8YnI+DQomZ3Q7IEZyb20gKHdpdGggdGFn KTogfjE2IGJ5dGVzPGJyPg0KJmd0OyBDYWxsLUlkOiB+MjQgYnl0ZXM8YnI+DQomZ3Q7IExvY2Fs IENvbnRhY3Q6IH4zMiBieXRlczxicj4NCiZndDsgUmVtb3RlIENvbnRhY3Q6IH4zMiBieXRlczxi cj4NCiZndDsgUm91dGUgU2V0ICh+NzQgYnl0ZXMgeCAzIHByb3hpZXMpOiB+MjIyIGJ5dGVzPGJy Pg0KJmd0OyBUd28gQ1NlcXM6IDQgYnl0ZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhdCdzIGFi b3V0IDM0NiBieXRlcy4gVG8gbWFrZSB0aGUgbWF0aCBlYXN5LCBsZXQncyBiZSBzbG9wcHkgYW5k DQo8YnI+DQomZ3Q7IGFzc3VtZSB0aGF0IG1pc2NlbGxhbmVvdXMgb3ZlcmhlYWQgYnVtcHMgdGhp cyBhbGwgdGhlIHdheSB0byA1MTIgPGJyPg0KJmd0OyBieXRlcyBwZXIgZGlhbG9nLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGF0IG1lYW5zIHRoYXQsIGluIHRoZSA4IEdCIG9mIFJBTSB0aGF0IG15 IGxhcHRvcCBoYXMsIEkgY291bGQgPGJyPg0KJmd0OyBzdG9yZSBzdGF0ZSBmb3IgMTYgbWlsbGlv biBkaWFsb2dzLiBJbiB0aGUgMzItR0Igc2VydmVyLWNsYXNzIGJveGVzDQo8YnI+DQomZ3Q7IHRo YXQgSSdtIHVzZWQgdG8gZGltZW5zaW9uaW5nIGZvciwgaXQgd291bGQgdGFrZSBvbmx5IDUgc2Vy dmVycyB0bw0KPGJyPg0KJmd0OyBzdG9yZSBhIGRpYWxvZyBmb3IgZXZlcnkgbWFuLCB3b21hbiwg Y2hpbGQsIGFuZCBuZXdib3JuIGJhYnkgaW4gdGhlDQo8YnI+DQomZ3Q7IFUuUy4gLS0gb3IgMjAg c2VydmVycyB0byBkbyB0aGUgc2FtZSB0aGluZyBmb3IgQ2hpbmEuIEl0IHdvdWxkIHRha2UNCjxi cj4NCiZndDsgYSBoYWlyIG92ZXIgMTAwIHN1Y2ggc2VydmVycyB0byBkbyB0aGlzIGZvciBldmVy eSBsaXZpbmcgaHVtYW4gYmVpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQncyBhc3N1bWlu ZyB3ZSBuZWVkIHRvIGtlZXAgZXZlcnl0aGluZyBpbiBhY3R1YWwgd2lyZWQgUkFNLiBJZg0KPGJy Pg0KJmd0OyB3ZSdyZSBhbGxvd2VkIHRvIHN3YXAgdGhlIGRhdGEgb3V0IHRvIGEgcGFpciBvZiAy IFRCIGhhcmQgZHJpdmVzIDxicj4NCiZndDsgKHBvc3NpYmx5IHNlbnNpYmxlIGlmIHRoZSB0cmFm ZmljIGlzIGFzIGxvdyBhcyB5b3UgaW1wbHkpLCB0aGlzIDxicj4NCiZndDsgc3RhdGUgLS0gb25l IHN1YnNjcmlwdGlvbiBmb3IgZXZlcnkgaHVtYW4gY3VycmVudGx5IGFsaXZlIC0tIGFsbCA8YnI+ DQomZ3Q7IGZpdHMgb24gYSBzaW5nbGUgc2VydmVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGVu IHlvdSdyZSB0YWxraW5nIGFib3V0IG5ldHdvcmsgc2VydmVycywgbWVtb3J5IGlzIGNoZWFwLCBh bmQgaGFyZDxicj4NCiZndDsgZHJpdmVzIGFyZSBjaGVhcGVyLiBTdGFuZGFyZGl6YXRpb24gYW5k IGltcGxlbWVudGF0aW9uIGlzIGV4cGVuc2l2ZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPlllcy4gT25lIG9mIG91ciBlcWlvcG1lbnQgaGFzIHRoZSBzaW1pbGFyIG1l bW9yeSBjb25zdW1pbmcNCnN0YXRpc3RpY3MuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5XaGlsZSBtZW1vcnkgaXMganVzdCBvbmUgYXBzZWN0IG9mIHJlc291cmNlIGNv bnN1bWluZy4NCkZ1cnRoZXIsIHQgb25lIGVxdWlwbWVudCB3b3VsZCBoYXZlIG90aGVyIHRhc2tz LCBzdWNoIGFzIGNhbGwgY29udHJvbCwNCnNlcnZpY2VzIGFuZCBzbyBvbi4gU28sIHRoZSBjYXBh Y2l0eSBvZiBvbmUgZXF1aXBtZW50IG1pZ2h0IG5vdCBiZSBzbyBpZGVhbC48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgU28sIEknbSBhIGJpdCBkb3VidGZ1bCB0 aGF0IGl0IHdvdWxkIGJlIGEgZ29vZCBpbnZlc3RtZW50IG9uIDxicj4NCiZndDsgYW55b25lJ3Mg cGFydCB0byBjb21lIHVwIHdpdGggYSBzaW1wbGlmaWVkIG1vZGVsIGZvciBSRkMzMjY1IHN1YnNj cmlwdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JbiBmYWN0 LCBkb2luZyBhIHByYWN0aWNhbCBwZXJmb3JtYW5jZSBhbmFseXNpcyBpcw0KaGFyZCwgYW5kIGl0 IHdvdWxkIGJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiBTbywgSSBzdWdnZXN0IHRvIGV2YWx1 YXRlDQppdCBieSByZWxhdGl2ZSBjb21wYXJlOjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Q29uc2lkZXJpbmcgb25lIEV2ZW50IFBhY2thZ2VzLCBoYXZpbmcgdGhlIHNp bWlsYXINCihjYWxsKSBhcnJpdmFsIHJhdGUgYW5kIGxvbmdlciBob2xkaW5nIHRpbWUoc29tZSBl dmVudCB0eXBlcyBoYXMgbXVjaCBsb25nZXINCmhvbGRpbmcgdGltZSB0aGFuIHNlc3Npb24pIHRo YW4gc2Vzc2lvbiB1c2FnZShJTlZJVEUpLCBpZiB3ZSBhbGxvdyBvdXQtb2YtZGlhbG9nDQpub3Rp ZmljYXRpb24sIHdlIG1pZ2h0IHNhdmUgcmVzb3VyY2UgY29uc3VtaW5nIGFzIG11Y2ggYXMob3Ig bW9yZSB0aGFuKQ0KdGhlIHdob2xlIHNlc3Npb24gc2lnYW5sbGluZy48L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkluIGZhY3QsIEkgYW0gbm90IGdvaW5nIHRvIGNoYW5n ZSB0aGUgUkZDMzI2NSB0cmFjaw0KYSBsb3QuIEknZCBsaWtlIHRvIG1ha2UgaXQgb3B0aW9uYWwg Zm9yIHNvbWUgc3BlY2lmaWMgRXZlbnQgUGFja2FnZXMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5HYW88L2ZvbnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 003277E848257816_=-- From pkyzivat@cisco.com Wed Jan 12 06:21:43 2011 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 637B628C129 for ; Wed, 12 Jan 2011 06:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NL+gtmlrGTJQ for ; Wed, 12 Jan 2011 06:21:42 -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 5A81428C128 for ; Wed, 12 Jan 2011 06:21:40 -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: AoAGABRILU1AZnwN/2dsb2JhbACECJIljhFzo1WKTwiNe4Edgzd4BIRMHIYogyA Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2011 14:23:59 +0000 Received: from [10.86.254.119] ([10.86.254.119]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0CENw1A003402; Wed, 12 Jan 2011 14:23:59 GMT Message-ID: <4D2DB97E.8080800@cisco.com> Date: Wed, 12 Jan 2011 09:23:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: "Worley, Dale R \(Dale\)" , sipcore@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 12 Jan 2011 14:21:43 -0000 On 1/12/2011 4:08 AM, gao.yang2@zte.com.cn wrote: > > Hi, > > It seems that we haven't reached an agreement for this topic. I'd like > to put together a discussion text for this issue, including: > > 1. Typical traffic model for SUBSCRIBE and Notification and Performance > analysis; > 2. Out-of-Dialog Notifaction optional solutions; > 3. Interworking and compatibility. > > Would this topic welcome in the coming IETF meeting in Czech? IMO that is premature. I'd like to see more interest on the list. You might find it useful to write up your thoughts as a draft, which might provide the basis for more to comment on. Thanks, Paul From dworley@avaya.com Wed Jan 12 06:52:21 2011 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 B813728C131 for ; Wed, 12 Jan 2011 06:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 SqZ4km6vu+ak for ; Wed, 12 Jan 2011 06:52:20 -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 A641128C108 for ; Wed, 12 Jan 2011 06:52:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJJPLU2HCzI1/2dsb2JhbACkPnOlfAKWL4VMBIRoiWI X-IronPort-AV: E=Sophos;i="4.60,313,1291611600"; d="scan'208";a="259244494" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jan 2011 09:54:39 -0500 X-IronPort-AV: E=Sophos;i="4.60,313,1291611600"; d="scan'208";a="581401082" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2011 09:54:39 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.160]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 12 Jan 2011 09:54:39 -0500 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" , Adam Roach , Paul Kyzivat , Christer Holmberg Date: Wed, 12 Jan 2011 09:53:32 -0500 Thread-Topic: About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: Thread-Index: AcuyOMSdThhaylHEQfuuqYBB3kHJ7gAL7a34 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 12 Jan 2011 14:52:22 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] Would this topic welcome in the coming IETF meeting in Czech? ________________________________________ I think you will need to convince more people that this is a problem that n= eeds to be solved before it is reasonable to present at the meeting. Dale From gao.yang2@zte.com.cn Wed Jan 12 18:18:58 2011 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 A4A613A680F; Wed, 12 Jan 2011 18:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.229 X-Spam-Level: X-Spam-Status: No, score=-99.229 tagged_above=-999 required=5 tests=[AWL=2.609, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 g+mbjYhv52KB; Wed, 12 Jan 2011 18:18:57 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D04E03A6806; Wed, 12 Jan 2011 18:18:56 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952001811080; Thu, 13 Jan 2011 10:17:03 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 25080.4046628847; Thu, 13 Jan 2011 10:14:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p0D2KtiW011315; Thu, 13 Jan 2011 10:20:55 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4D2DB97E.8080800@cisco.com> To: Paul Kyzivat , "Worley, Dale R \(Dale\)" MIME-Version: 1.0 X-KeepSent: D57FFC82:E4A89A4D-48257817:000C6EF3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 13 Jan 2011 10:17:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-13 10:20:48, Serialize complete at 2011-01-13 10:20:48 Content-Type: multipart/alternative; boundary="=_alternative 000CE94848257817_=" X-MAIL: mse3.zte.com.cn p0D2KtiW011315 Cc: sipcore@ietf.org, sipcore-bounces@ietf.org Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion: 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, 13 Jan 2011 02:18:58 -0000 This is a multipart message in MIME format. --=_alternative 000CE94848257817_= Content-Type: text/plain; charset="US-ASCII" Paul, Dale, Thanks for you two's suggestion. I will find time to do a draft first. Gao > > Hi, > > > > It seems that we haven't reached an agreement for this topic. I'd like > > to put together a discussion text for this issue, including: > > > > 1. Typical traffic model for SUBSCRIBE and Notification and Performance > > analysis; > > 2. Out-of-Dialog Notifaction optional solutions; > > 3. Interworking and compatibility. > > > > Would this topic welcome in the coming IETF meeting in Czech? > > IMO that is premature. I'd like to see more interest on the list. > You might find it useful to write up your thoughts as a draft, which > might provide the basis for more to comment on. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000CE94848257817_= Content-Type: text/html; charset="US-ASCII"
Paul, Dale,

Thanks for you two's suggestion. I will find time to do a draft first.

Gao


> > Hi,
> >
> > It seems that we haven't reached an agreement for this topic. I'd like
> > to put together a discussion text for this issue, including:
> >
> > 1. Typical traffic model for SUBSCRIBE and Notification and Performance
> > analysis;
> > 2. Out-of-Dialog Notifaction optional solutions;
> > 3. Interworking and compatibility.
> >
> > Would this topic welcome in the coming IETF meeting in Czech?
>
> IMO that is premature. I'd like to see more interest on the list.
> You might find it useful to write up your thoughts as a draft, which
> might provide the basis for more to comment on.
>
>    Thanks,
>    Paul
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000CE94848257817_=-- From richard@shockey.us Thu Jan 13 14:59:51 2011 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 6EAD83A6C16 for ; Thu, 13 Jan 2011 14:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.127 X-Spam-Level: X-Spam-Status: No, score=-101.127 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 39SsdzQ8wcMx for ; Thu, 13 Jan 2011 14:59:50 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 57F953A6C10 for ; Thu, 13 Jan 2011 14:59:50 -0800 (PST) Received: (qmail 4139 invoked by uid 0); 13 Jan 2011 23:02:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 13 Jan 2011 23:02:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=NyFkSMwOM8Jp/Hvzk0ns6ZK0cXZivdCJcwjyrIGM3A78pUXvKUhHwPjQWqR1IHt2/bWKHWtl1m7rcugmr3TPQru0ZSf2IYBHLt9pHH0p0aWR+6Q/2szn2SnoLOOc6R25; Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PdWBJ-0001Zm-Mg; Thu, 13 Jan 2011 16:02:14 -0700 From: "Richard Shockey" To: , Date: Thu, 13 Jan 2011 18:02:11 -0500 Message-ID: <003501cbb375$ea196730$be4c3590$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01CBB34C.01435F30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuzdelWVptSM4XrS/ascIT/BOiM+Q== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us} Subject: [sipcore] Progress my SIP friends progress... 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, 13 Jan 2011 22:59:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0036_01CBB34C.01435F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "Interconnected VoIP service represents an important and rapidly growing part of the U.S. voice service market." http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-304053A1.doc Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0036_01CBB34C.01435F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

"Interconnected VoIP service represents an = important and rapidly growing part of the U.S. voice service market."  =

 

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-304053A1.doc=

 

 

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0036_01CBB34C.01435F30-- From Internet-Drafts@ietf.org Fri Jan 14 12:00:05 2011 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 10A443A6C18; Fri, 14 Jan 2011 12:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 dcIgNZOyJWlM; Fri, 14 Jan 2011 12:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123B83A6BC5; Fri, 14 Jan 2011 12:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110114200002.14631.62191.idtracker@localhost> Date: Fri, 14 Jan 2011 12:00:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-08.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, 14 Jan 2011 20:00:05 -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 : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-08.txt Pages : 76 Date : 2011-01-14 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-08.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-sec-flows-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-14115503.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Fri Jan 14 12:41:57 2011 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 944493A6C7A; Fri, 14 Jan 2011 12:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 Djp9W-WsiBVz; Fri, 14 Jan 2011 12:41:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id CFD873A6C79; Fri, 14 Jan 2011 12:41:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 751F4E072D; Fri, 14 Jan 2011 12:44:23 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110114204423.751F4E072D@rfc-editor.org> Date: Fri, 14 Jan 2011 12:44:23 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6086 on Session Initiation Protocol (SIP) INFO Method and Package Framework 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, 14 Jan 2011 20:41:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6086 Title: Session Initiation Protocol (SIP) INFO Method and Package Framework Author: C. Holmberg, E. Burger, H. Kaplan Status: Standards Track Stream: IETF Date: January 2011 Mailbox: christer.holmberg@ericsson.com, eburger@standardstrack.com, hkaplan@acmepacket.com Pages: 36 Characters: 75949 Obsoletes: RFC2976 I-D Tag: draft-ietf-sipcore-info-events-10.txt URL: http://www.rfc-editor.org/rfc/rfc6086.txt This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Internet-Drafts@ietf.org Thu Jan 20 13:00:03 2011 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 563343A682A; Thu, 20 Jan 2011 13:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 dvB3A1PqqxL9; Thu, 20 Jan 2011 13:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F263A682B; Thu, 20 Jan 2011 13:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110120210001.11465.48657.idtracker@localhost> Date: Thu, 20 Jan 2011 13:00:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-12.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, 20 Jan 2011 21:00: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 : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-12.txt Pages : 19 Date : 2011-01-20 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-12.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-keep-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20125609.I-D@ietf.org> --NextPart-- From dworley@avaya.com Fri Jan 21 13:42:54 2011 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 EAB0A3A67F8 for ; Fri, 21 Jan 2011 13:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 EemwgHCURFRL for ; Fri, 21 Jan 2011 13:42:54 -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 DA6BC3A67C2 for ; Fri, 21 Jan 2011 13:42:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4AAGeNOU3GmAcF/2dsb2JhbACWDQGOXHOjawKYdIMLgkUEhG+JcA X-IronPort-AV: E=Sophos;i="4.60,359,1291611600"; d="scan'208";a="228712599" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Jan 2011 16:45:39 -0500 X-IronPort-AV: E=Sophos;i="4.60,359,1291611600"; d="scan'208";a="573699378" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jan 2011 16:45:38 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 21 Jan 2011 16:45:38 -0500 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Fri, 21 Jan 2011 16:42:15 -0500 Thread-Topic: New music-on-hold technique: Revised draft available Thread-Index: AQHLubSKYky3lK4cgEqt4vpuDDnfng== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] New music-on-hold technique: Revised draft available 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, 21 Jan 2011 21:42:55 -0000 I've updated draft-worley-service-example to take into account Paul's and J= ohn's reviews. Does anyone have any further comments? Dale https://datatracker.ietf.org/doc/draft-worley-service-example/ ________________________________________ From: IETF I-D Submission Tool [idsubmission@ietf.org] Sent: Wednesday, December 29, 2010 4:59 PM To: Worley, Dale R (Dale) Subject: New Version Notification for draft-worley-service-example-06 A new version of I-D, draft-worley-service-example-06.txt has been successf= ully submitted by Dale Worley and posted to the IETF repository. Filename: draft-worley-service-example Revision: 06 Title: Session Initiation Protocol Service Example -- Music on Ho= ld Creation_date: 2010-12-29 WG ID: Independent Submission Number_of_pages: 32 Abstract: The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the method of RFC 5359. From aallen@rim.com Fri Jan 21 14:22:52 2011 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 45FDE3A68F7 for ; Fri, 21 Jan 2011 14:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 QWkB5xqgdKKL for ; Fri, 21 Jan 2011 14:22:44 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id A738A3A684B for ; Fri, 21 Jan 2011 14:22:43 -0800 (PST) X-AuditID: 0a401fcb-b7ba1ae000000a54-a6-4d3a07d9501c Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id A1.2D.02644.9D70A3D4; Fri, 21 Jan 2011 17:25:29 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Jan 2011 17:25:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB9BA.1B48DBE8" Date: Fri, 21 Jan 2011 16:25:26 -0600 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: AcuWE+kQHPR3a668Th+74O6FYhCCTAYacMJA References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> From: "Andrew Allen" To: "Christer Holmberg" , X-OriginalArrivalTime: 21 Jan 2011 22:25:29.0933 (UTC) FILETIME=[1C41EFD0:01CBB9BA] X-Brightmail-Tracker: AAAAAgAAAZEXM08l Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 21 Jan 2011 22:22:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB9BA.1B48DBE8 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I have reviewed this draft and basically I am supportive of the objective of this work. I think the current use cases are very specific and the problem itself is even more general. I think the general requirement is that it is useful for UAs and other intermediaries to be able to detect the presence of an intermediary on the path of a registration or the route of a dialog when that intermediary provides some feature or service and be able to identify the URI of that intermediary in order to be able to address requests to it . In addition to the 3GPP specific use cases currently in the draft I think there are others including: Dealing with call feature interactions In a deployment where different intermediaries provide different call features it is sometimes necessary to be able to detect that another intermediary has invoked a particular feature as that may mean that a particular feature should not be invoked or should be invoked in a way that takes account of the invocation of the feature by the other intermediary in order to prevent conflicts between different call features. Detecting the presence of a SIP PBX SIP PBXs may be present in a network and may provide call features and other services on behalf of the UA. In some cases the UA may need to address requests to the PBX to invoke some features or services. Although presence of the PBX could be indicated using configuration this isn't really effective when there are mobile UAs moving between enterprise networks that have PBXs and public networks that don't. Detecting the presence of a telephony application server. In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony Application Server (TAS) that provides call features on behalf of the UA. However not all 3GPP networks will necessarily deploy MMTel so it is necessary that a UA be able to identify that a TAS is involved in the call and be able to send requests such as REFER to the TAS in order to perform functions like call transfer. Having the TAS always act as a full B2BUA and overwrite the Contact is not a good solution as this will cause the loss of the GRUUs of the far end UAs. In addition since the same intermediary may perform multiple features or services it is useful for the URI that is provided to identify the related call feature or service so that when the UA addresses a request to the intermediary the intermediary knows what feature or service the request is related to. Some detailed comments: Section 6 NOTE: If a route set is built using Path, Record-Route or Service- Route header fields, any inserted feature tag will be copied into the associated Route header fields, together with other header field parameters. This specification does not define any specific meaning of the feature tags present in Route header fields in such cases. I think the meaning of the feature tag in the Route header is the same it means that the entity whose URI is on the Route supports the feature Section 7 I think the direction issue may need more work. It would I think be useful to indicate the directionality. I believe that SIPCORE should adopt this and work on a solution. Andrew From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, December 07, 2010 7:38 AM To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Hi, I've submitted a new version of the proxy-feature draft. It now contains more use-cases, for which the usage of the draft have been discussed in 3GPP. In the examples there is also some wording about why the usage of the Contact header field is not seen as appropriate. I have added some text about the "direction" of capabilities. Regards, Christer ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBB9BA.1B48DBE8 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

I have reviewed this draft and basically I am supportive of t= he objective of this work.

 

I think the current use cases are very specific and the probl= em itself is even more general.

 

I think the general requirement is that it is useful for UAs= and other intermediaries to be able to detect the presence of an intermediary&nb= sp; on the path of a registration or the route of a dialog when that intermediar= y provides some feature or service and be able to identify the URI of that intermediary in order to be able to address requests to it . In addition to= the 3GPP specific use cases currently in the draft I think there are others including:

 

Dealing with call feature interactions

 

In a deployment where different intermediaries provide differ= ent call features it is sometimes necessary to be able to detect that another intermediary has invoked a particular feature as that may mean that a particular feature should not be invoked or should be invoked in a way that takes account of the invocation of the feature by the other intermediary in order to prevent conflicts between different call features.

 

Detecting the presence of a SIP PBX

 

SIP PBXs may be present in a network and may provide call features and other services on behalf of the UA. In some cases the UA may ne= ed to address requests to the PBX to invoke some features or services. Although presence of the PBX could be indicated using configuration this isn’t really effective when there are mobile UAs moving between enterprise network= s that have PBXs and public networks that don’t. 

 

Detecting the presence of a telephony application server.

 

In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony Application Server (TAS) that provides call features on behalf of= the UA. However not all 3GPP networks will necessarily deploy MMTel so it is necessary that a UA be able to identify that a TAS is involved in the call a= nd be able to send requests such as REFER to the TAS in order to perform functi= ons like call transfer. Having the TAS always act as a full B2BUA and overwrite= the Contact is not a good solution as this will cause the loss of the GRUUs of t= he far end UAs.

 

In addition since the same intermediary may perform multiple features or services it is useful for the URI that is provided to identify t= he related call feature or service so that when the UA addresses a request to t= he intermediary the intermediary knows what feature or service the request is related to.

 

Some detailed comments:

 

Section 6

 

   NOTE: If a route set is built using= Path, Record-Route or Service-

   Route header fields, any inserted feature tag will be copied into the

   associated Route header fields, together with other header field

   parameters.  This specification does not define any specific meaning

   of the feature tags present in Route header fields in such cases.

 

    &n= bsp; I think the meaning of  the feature tag in the Route header is the same= it means that the entity whose URI is on the Route supports the feature<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>

 

Section 7

 

  I think the directi= on issue may need more work. It would I think be useful to indicate the directionalit= y.

 

 I be= lieve that SIPCORE should adopt this and work on a solution.

 

Andrew

 

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of <= /b>Christer Holmberg
Sent: Tuesday, December 07, 2010 7:38 AM
To: sipcore@ietf.org
Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

 

 =

Hi,

 

I've submitted a new version of the proxy-feature draft.

 

It now contains more use-cases, for which the usage of the draft have been discussed in 3GPP.

 

In the examples there is also some wording about why the usage of the Contact header field is not seen as appropriate.

 

I have added some text about the "direction" of capabilities.=

 

Regards,

 

Christer

 

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CBB9BA.1B48DBE8-- From adam@nostrum.com Fri Jan 21 15:04:51 2011 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 2F5553A681B for ; Fri, 21 Jan 2011 15:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, SPF_PASS=-0.001, 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 U9l9gp5a1mUT for ; Fri, 21 Jan 2011 15:04:46 -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 391C63A67E4 for ; Fri, 21 Jan 2011 15:04:45 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0LN7Vtr022448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 17:07:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D3A11B3.4070402@nostrum.com> Date: Fri, 21 Jan 2011 17:07:31 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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 Chairs Subject: [sipcore] Weekly Location Conveyance Phone Calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 23:04:51 -0000 [as chair] As we discussed in Beijing, the SIPCORE chairs would like to start having weekly calls with participants interested in the "Location Conveyance with SIP" milestone to progress that work to completion as quickly as possible. To be clear, these calls are informal discussions among members of an open design team, which anyone is free to participate in. They are not interim SIPCORE meetings, and the discussion topics will be limited to Location Conveyance. The weekly calls will be every Thursday, according to the times in the following schedule (with the caveat that the Australian times occur on the following Friday morning). I apologize for the very early times in the Asia/Pacific Rim area, and for the very late times in Europe, but it's a careful balancing act (any earlier or later, and we would legitimately be in the middle of the night for one of those two locales). | AEDT | PST | MST | CST | EST | GMT | CET | EET | Jan 27 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Feb 03 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Feb 10 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Feb 17 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Feb 24 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Mar 03 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | Mar 10 | 0600 | 1100 | 1200 | 1300 | 1400 | 1900 | 2000 | 2100 | | AEDT | PDT | MDT | CDT | EDT | GMT | CET | EET | Mar 17 | 0500 | 1100 | 1200 | 1300 | 1400 | 1800 | 1900 | 2000 | Mar 24 | 0500 | 1100 | 1200 | 1300 | 1400 | 1800 | 1900 | 2000 | The timezones in the preceding chart are selected based on where I know participants in this effort are currently located. If you would like me to work up the time conversion for a specific other timezone, let me know. I plan for these conversations to run approximately 1 hour in length, although I have reserved additional conference bridge time in case we need to run over a bit. The conference bridge information follows. ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: SIPCORE Ad Hoc Disussion Date: Every Thursday, from Thursday, January 27, 2011 to no end date Time: 1:00 pm, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 921 417 233 Meeting Password: 64642401 ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://tekelec.webex.com/tekelec/j.php?ED=155345407&UID=493988047&PW=NZDZlODg0YzIx&RT=MiM3 ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Global call-in numbers: https://tekelec.webex.com/tekelec/globalcallin.php?serviceType=MC&ED=155345407&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:921 417 233 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://tekelec.webex.com/tekelec/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://tekelec.webex.com/tekelec/j.php?ED=155345407&UID=493988047&ICS=MIU&LD=1&RD=2&ST=1&SHA2=NiRHx-PbenxG5O5qGNE5NzXqvcnevu-vcTyoIXwA4/w= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://tekelec.webex.com/tekelec/systemdiagnosis.php http://www.webex.com We've got to start meeting like this(TM) CCM:+16504293300x921417233# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. From pkyzivat@cisco.com Fri Jan 21 16:58:01 2011 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 8529C3A6864 for ; Fri, 21 Jan 2011 16:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 xfYeIJf5sUT7 for ; Fri, 21 Jan 2011 16:57: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 18DA73A685D for ; Fri, 21 Jan 2011 16:57:59 -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: AoQAAKO6OU1AZnwN/2dsb2JhbACWEAGOXHOhMJsZgngTgkUEhG+GMIMl Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2011 01:00:46 +0000 Received: from [10.86.240.237] (che-vpn-cluster-1-237.cisco.com [10.86.240.237]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0M10jJ6021679 for ; Sat, 22 Jan 2011 01:00:45 GMT Message-ID: <4D3A2C3D.10508@cisco.com> Date: Fri, 21 Jan 2011 20:00:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 22 Jan 2011 00:58:01 -0000 (speaking as an individual) Inline... On 1/21/2011 5:25 PM, Andrew Allen wrote: > I have reviewed this draft and basically I am supportive of the > objective of this work. > > I think the current use cases are very specific and the problem itself > is even more general. > > I think the general requirement is that it is useful for UAs and other > intermediaries to be able to detect the presence of an intermediary on > the path of a registration or the route of a dialog when that > intermediary provides some feature or service and be able to identify > the URI of that intermediary in order to be able to address requests to > it . In addition to the 3GPP specific use cases currently in the draft I > think there are others including: A major thing that is lacking here is any explanation of what it *means* for an intermediary to "offer a feature" - what sorts of features those are, and how one might avail oneself of them. In the case of callerprefs/callee caps and currently defined, the intermediary is a proxy that does address translation based on a registrar. One knows that the way to avail themselves of the features is to send a request to an AOR with registrations and use callerprefs to request routing to a device with those features. Or, one might learn about capabilities because they are returned attached to a contact in a dialog, and then one avails oneself of the capabilities by sending a subsequent request to that contact. Now maybe this draft implies no more - that the capabilities are ones that I can get access to by sending a request to the address I find in the Route header. But of course its not normal to send a request with the R-URI being an address taken from a Route header. I think this is the usual thing - there is a framework within which this makes sense, but its defined in IMS. And as usual, the inclination is to say: please say more than that you want this to use in some unspecified way with IMS. Thanks, Paul > Dealing with call feature interactions > > In a deployment where different intermediaries provide different call > features it is sometimes necessary to be able to detect that another > intermediary has invoked a particular feature as that may mean that a > particular feature should not be invoked or should be invoked in a way > that takes account of the invocation of the feature by the other > intermediary in order to prevent conflicts between different call features. So in this case it is not about detecting *capabilities* that might be used, but rather about detecting behavior that is already being applied? > Detecting the presence of a SIP PBX > > SIP PBXs may be present in a network and may provide call features and > other services on behalf of the UA. In some cases the UA may need to > address requests to the PBX to invoke some features or services. This is more what I was getting at. But its not clear to me what the model is for "addressing requests to the PBX to invoke some features or services". > Although presence of the PBX could be indicated using configuration this > isn’t really effective when there are mobile UAs moving between > enterprise networks that have PBXs and public networks that don’t. > > Detecting the presence of a telephony application server. > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony > Application Server (TAS) that provides call features on behalf of the > UA. However not all 3GPP networks will necessarily deploy MMTel so it is > necessary that a UA be able to identify that a TAS is involved in the > call and be able to send requests such as REFER to the TAS in order to > perform functions like call transfer. Having the TAS always act as a > full B2BUA and overwrite the Contact is not a good solution as this will > cause the loss of the GRUUs of the far end UAs. This begs some higher level model of the possible components in a system and their potential relationships to one another. I realize IMS has this, that doesn't help in defining this in the ietf context. We are starting to have such things in the work that was done in BLISS. But I don't know if that is similar. And of course a bunch of ietf folk believe that IMS has it all wrong. > In addition since the same intermediary may perform multiple features or > services it is useful for the URI that is provided to identify the > related call feature or service so that when the UA addresses a request > to the intermediary the intermediary knows what feature or service the > request is related to. > > Some detailed comments: > > Section 6 > > NOTE: If a route set is built using Path, Record-Route or Service- > > Route header fields, any inserted feature tag will be copied into the > > associated Route header fields, together with other header field > > parameters. This specification does not define any specific meaning > > of the feature tags present in Route header fields in such cases. > > I think the meaning of the feature tag in the Route header is the same > it means that the entity whose URI is on the Route supports the feature Yes. Those other headers only exist to form Routes. I would think that it is presence on the Route that would matter, except in cases where presence on Record-Route leads something along the way to block the call. > Section 7 > > I think the direction issue may need more work. It would I think be > useful to indicate the directionality. > > I believe that SIPCORE should adopt this and work on a solution. I hear you. Lets see what others have to say. Thanks, Paul > Andrew > > *From:*sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Christer Holmberg > *Sent:* Tuesday, December 07, 2010 7:38 AM > *To:* sipcore@ietf.org > *Subject:* [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature > > Hi, > > I've submitted a new version of the proxy-feature draft. > > It now contains more use-cases, for which the usage of the draft have > been discussed in 3GPP. > > In the examples there is also some wording about why the usage of the > Contact header field is not seen as appropriate. > > I have added some text about the "direction" of capabilities. > > Regards, > > Christer > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sat Jan 22 01:29:18 2011 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 EA3813A67FD for ; Sat, 22 Jan 2011 01:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+++4Gp4ixYJ for ; Sat, 22 Jan 2011 01:29: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 1EE683A67F7 for ; Sat, 22 Jan 2011 01:29:16 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-84-4d3aa413be26 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.7D.13987.314AA3D4; Sat, 22 Jan 2011 10:32:03 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sat, 22 Jan 2011 10:32:03 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Sat, 22 Jan 2011 10:32:03 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu5z9D8UhecMC5qQI6eh5pB0NTuqAARpZOz Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> In-Reply-To: <4D3A2C3D.10508@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 22 Jan 2011 09:29:19 -0000 Hi Paul, The idea is that each feature specification defines what indicating support= of a feature means - in the same way it is done for UAs. For example, just because a proxy indicate support of a feature, it doesn't= automatically mean that others will address requests towards that proxy. I= t may for example mean that another entity, when it sees the feature tag, d= oes not trigger some action. I am sure there are things in the draft than can be clarified, including th= e 3GPP use-cases, but I think it would be useful to know (for me personally= , and for 3GPP that wants to use the mechanism) whether the WG is willing t= o start this work. Nobody has objected to the work as such (you even say yo= urself that it might be useful :), and all questions and issues that have b= een raised will of course have to be solved (like we always do). Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Saturday, January 22, 2011 3:00 AM To: sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipc= ore-proxy-feature (speaking as an individual) Inline... On 1/21/2011 5:25 PM, Andrew Allen wrote: > I have reviewed this draft and basically I am supportive of the > objective of this work. > > I think the current use cases are very specific and the problem itself > is even more general. > > I think the general requirement is that it is useful for UAs and other > intermediaries to be able to detect the presence of an intermediary on > the path of a registration or the route of a dialog when that > intermediary provides some feature or service and be able to identify > the URI of that intermediary in order to be able to address requests to > it . In addition to the 3GPP specific use cases currently in the draft I > think there are others including: A major thing that is lacking here is any explanation of what it *means* for an intermediary to "offer a feature" - what sorts of features those are, and how one might avail oneself of them. In the case of callerprefs/callee caps and currently defined, the intermediary is a proxy that does address translation based on a registrar. One knows that the way to avail themselves of the features is to send a request to an AOR with registrations and use callerprefs to request routing to a device with those features. Or, one might learn about capabilities because they are returned attached to a contact in a dialog, and then one avails oneself of the capabilities by sending a subsequent request to that contact. Now maybe this draft implies no more - that the capabilities are ones that I can get access to by sending a request to the address I find in the Route header. But of course its not normal to send a request with the R-URI being an address taken from a Route header. I think this is the usual thing - there is a framework within which this makes sense, but its defined in IMS. And as usual, the inclination is to say: please say more than that you want this to use in some unspecified way with IMS. Thanks, Paul > Dealing with call feature interactions > > In a deployment where different intermediaries provide different call > features it is sometimes necessary to be able to detect that another > intermediary has invoked a particular feature as that may mean that a > particular feature should not be invoked or should be invoked in a way > that takes account of the invocation of the feature by the other > intermediary in order to prevent conflicts between different call feature= s. So in this case it is not about detecting *capabilities* that might be used, but rather about detecting behavior that is already being applied? > Detecting the presence of a SIP PBX > > SIP PBXs may be present in a network and may provide call features and > other services on behalf of the UA. In some cases the UA may need to > address requests to the PBX to invoke some features or services. This is more what I was getting at. But its not clear to me what the model is for "addressing requests to the PBX to invoke some features or services". > Although presence of the PBX could be indicated using configuration this > isn=92t really effective when there are mobile UAs moving between > enterprise networks that have PBXs and public networks that don=92t. > > Detecting the presence of a telephony application server. > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony > Application Server (TAS) that provides call features on behalf of the > UA. However not all 3GPP networks will necessarily deploy MMTel so it is > necessary that a UA be able to identify that a TAS is involved in the > call and be able to send requests such as REFER to the TAS in order to > perform functions like call transfer. Having the TAS always act as a > full B2BUA and overwrite the Contact is not a good solution as this will > cause the loss of the GRUUs of the far end UAs. This begs some higher level model of the possible components in a system and their potential relationships to one another. I realize IMS has this, that doesn't help in defining this in the ietf context. We are starting to have such things in the work that was done in BLISS. But I don't know if that is similar. And of course a bunch of ietf folk believe that IMS has it all wrong. > In addition since the same intermediary may perform multiple features or > services it is useful for the URI that is provided to identify the > related call feature or service so that when the UA addresses a request > to the intermediary the intermediary knows what feature or service the > request is related to. > > Some detailed comments: > > Section 6 > > NOTE: If a route set is built using Path, Record-Route or Service- > > Route header fields, any inserted feature tag will be copied into the > > associated Route header fields, together with other header field > > parameters. This specification does not define any specific meaning > > of the feature tags present in Route header fields in such cases. > > I think the meaning of the feature tag in the Route header is the same > it means that the entity whose URI is on the Route supports the feature Yes. Those other headers only exist to form Routes. I would think that it is presence on the Route that would matter, except in cases where presence on Record-Route leads something along the way to block the call. > Section 7 > > I think the direction issue may need more work. It would I think be > useful to indicate the directionality. > > I believe that SIPCORE should adopt this and work on a solution. I hear you. Lets see what others have to say. Thanks, Paul > Andrew > > *From:*sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Christer Holmberg > *Sent:* Tuesday, December 07, 2010 7:38 AM > *To:* sipcore@ietf.org > *Subject:* [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feat= ure > > Hi, > > I've submitted a new version of the proxy-feature draft. > > It now contains more use-cases, for which the usage of the draft have > been discussed in 3GPP. > > In the examples there is also some wording about why the usage of the > Contact header field is not seen as appropriate. > > I have added some text about the "direction" of capabilities. > > Regards, > > Christer > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > > _______________________________________________ > 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 R.Jesske@telekom.de Mon Jan 24 00:48:29 2011 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 A94403A698F for ; Mon, 24 Jan 2011 00:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhKL+FmM3+2L for ; Mon, 24 Jan 2011 00:48:28 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id BBFA03A63EB for ; Mon, 24 Jan 2011 00:48:26 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jan 2011 09:51:15 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.174]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 24 Jan 2011 09:51:10 +0100 From: To: , , Date: Mon, 24 Jan 2011 09:51:08 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu5z9D8UhecMC5qQI6eh5pB0NTuqAARpZOzAGNEchA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D860F2988@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 24 Jan 2011 08:48:29 -0000 I support the work. From my side we can start the work on Christer's draft. Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer Holmberg > Gesendet: Samstag, 22. Januar 2011 10:32 > An: Paul Kyzivat; sipcore@ietf.org > Betreff: Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature > > > Hi Paul, > > The idea is that each feature specification defines what > indicating support of a feature means - in the same way it is > done for UAs. > > For example, just because a proxy indicate support of a > feature, it doesn't automatically mean that others will > address requests towards that proxy. It may for example mean > that another entity, when it sees the feature tag, does not > trigger some action. > > I am sure there are things in the draft than can be > clarified, including the 3GPP use-cases, but I think it would > be useful to know (for me personally, and for 3GPP that wants > to use the mechanism) whether the WG is willing to start this > work. Nobody has objected to the work as such (you even say > yourself that it might be useful :), and all questions and > issues that have been raised will of course have to be solved > (like we always do). > > Regards, > > Christer > > > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Saturday, January 22, 2011 3:00 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature > > (speaking as an individual) > > Inline... > > > > On 1/21/2011 5:25 PM, Andrew Allen wrote: > > I have reviewed this draft and basically I am supportive of the > > objective of this work. > > > > I think the current use cases are very specific and the > problem itself > > is even more general. > > > > I think the general requirement is that it is useful for > UAs and other > > intermediaries to be able to detect the presence of an > intermediary on > > the path of a registration or the route of a dialog when that > > intermediary provides some feature or service and be able > to identify > > the URI of that intermediary in order to be able to address > requests to > > it . In addition to the 3GPP specific use cases currently > in the draft I > > think there are others including: > > A major thing that is lacking here is any explanation of what > it *means* > for an intermediary to "offer a feature" - what sorts of > features those > are, and how one might avail oneself of them. > > In the case of callerprefs/callee caps and currently defined, the > intermediary is a proxy that does address translation based on a > registrar. One knows that the way to avail themselves of the > features is > to send a request to an AOR with registrations and use callerprefs to > request routing to a device with those features. > > Or, one might learn about capabilities because they are returned > attached to a contact in a dialog, and then one avails oneself of the > capabilities by sending a subsequent request to that contact. > > Now maybe this draft implies no more - that the capabilities are ones > that I can get access to by sending a request to the address I find in > the Route header. But of course its not normal to send a request with > the R-URI being an address taken from a Route header. > > I think this is the usual thing - there is a framework within > which this > makes sense, but its defined in IMS. And as usual, the > inclination is to > say: please say more than that you want this to use in some > unspecified > way with IMS. > > Thanks, > Paul > > > Dealing with call feature interactions > > > > In a deployment where different intermediaries provide > different call > > features it is sometimes necessary to be able to detect that another > > intermediary has invoked a particular feature as that may > mean that a > > particular feature should not be invoked or should be > invoked in a way > > that takes account of the invocation of the feature by the other > > intermediary in order to prevent conflicts between > different call features. > > So in this case it is not about detecting *capabilities* that might be > used, but rather about detecting behavior that is already > being applied? > > > Detecting the presence of a SIP PBX > > > > SIP PBXs may be present in a network and may provide call > features and > > other services on behalf of the UA. In some cases the UA may need to > > address requests to the PBX to invoke some features or services. > > This is more what I was getting at. But its not clear to me what the > model is for "addressing requests to the PBX to invoke some > features or > services". > > > Although presence of the PBX could be indicated using > configuration this > > isn't really effective when there are mobile UAs moving between > > enterprise networks that have PBXs and public networks that don't. > > > > Detecting the presence of a telephony application server. > > > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a > Telephony > > Application Server (TAS) that provides call features on > behalf of the > > UA. However not all 3GPP networks will necessarily deploy > MMTel so it is > > necessary that a UA be able to identify that a TAS is > involved in the > > call and be able to send requests such as REFER to the TAS > in order to > > perform functions like call transfer. Having the TAS always act as a > > full B2BUA and overwrite the Contact is not a good solution > as this will > > cause the loss of the GRUUs of the far end UAs. > > This begs some higher level model of the possible components > in a system > and their potential relationships to one another. I realize IMS has > this, that doesn't help in defining this in the ietf context. We are > starting to have such things in the work that was done in BLISS. But I > don't know if that is similar. And of course a bunch of ietf folk > believe that IMS has it all wrong. > > > In addition since the same intermediary may perform > multiple features or > > services it is useful for the URI that is provided to identify the > > related call feature or service so that when the UA > addresses a request > > to the intermediary the intermediary knows what feature or > service the > > request is related to. > > > > Some detailed comments: > > > > Section 6 > > > > NOTE: If a route set is built using Path, Record-Route or Service- > > > > Route header fields, any inserted feature tag will be > copied into the > > > > associated Route header fields, together with other header field > > > > parameters. This specification does not define any specific meaning > > > > of the feature tags present in Route header fields in such cases. > > > > I think the meaning of the feature tag in the Route header > is the same > > it means that the entity whose URI is on the Route supports > the feature > > Yes. Those other headers only exist to form Routes. I would think that > it is presence on the Route that would matter, except in cases where > presence on Record-Route leads something along the way to > block the call. > > > Section 7 > > > > I think the direction issue may need more work. It would I think be > > useful to indicate the directionality. > > > > I believe that SIPCORE should adopt this and work on a solution. > > I hear you. Lets see what others have to say. > > Thanks, > Paul > > > Andrew > > > > *From:*sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] *On > > Behalf Of *Christer Holmberg > > *Sent:* Tuesday, December 07, 2010 7:38 AM > > *To:* sipcore@ietf.org > > *Subject:* [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature > > > > Hi, > > > > I've submitted a new version of the proxy-feature draft. > > > > It now contains more use-cases, for which the usage of the > draft have > > been discussed in 3GPP. > > > > In the examples there is also some wording about why the > usage of the > > Contact header field is not seen as appropriate. > > > > I have added some text about the "direction" of capabilities. > > > > Regards, > > > > Christer > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > confidential > > information, privileged material (including material > protected by the > > solicitor-client or other applicable privileges), or constitute > > non-public information. Any use of this information by > anyone other than > > the intended recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the > sender and delete > > this information from your system. Use, dissemination, > distribution, or > > reproduction of this transmission by unintended recipients is not > > authorized and may be unlawful. > > > > > > > > _______________________________________________ > > 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 john.elwell@siemens-enterprise.com Mon Jan 24 07:29:58 2011 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 D4D5D3A68D5 for ; Mon, 24 Jan 2011 07:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 v3uiZrJ9qk08 for ; Mon, 24 Jan 2011 07:29:58 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C10EF3A68E6 for ; Mon, 24 Jan 2011 07:29:57 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3114885; Mon, 24 Jan 2011 16:32:51 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id DB5FC23F0292; Mon, 24 Jan 2011 16:32:51 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 24 Jan 2011 16:32:51 +0100 From: "Elwell, John" To: Andrew Allen , Christer Holmberg , "sipcore@ietf.org" Date: Mon, 24 Jan 2011 16:32:50 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: AcuWE+kQHPR3a668Th+74O6FYhCCTAYacMJAA1c3KtA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> 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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 24 Jan 2011 15:29:59 -0000 Just picking on one particular example from Andrew's post:=20 > SIP PBXs may be present in a network and may provide call=20 > features and other services on behalf of the UA. In some=20 > cases the UA may need to address requests to the PBX to=20 > invoke some features or services. Although presence of the=20 > PBX could be indicated using configuration this isn't really=20 > effective when there are mobile UAs moving between enterprise=20 > networks that have PBXs and public networks that don't. =20 [JRE] Although we all perhaps have a similar notion of what a PBX is, this = is not a tightly defined term in the SIP context (the nearest we have is th= e MARTINI notion of SIP-PBX in the context of bulk registration, but I susp= ect that is not what you have in mind). A PBX could do all sorts of things = differently from some other SIP entity (such as a Service Provider SIP prox= y), but particular behaviour is very much dependent on the design of a PBX = and how it is deployed. If proxy features are indeed to be indicated (I hav= e not yet formed an opinion on this), they should be more precisely defined= , i.e., at the level of particular features that the PBX can perform, rathe= r than just the fact it is a PBX. John From john.elwell@siemens-enterprise.com Mon Jan 24 07:30:44 2011 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 534423A68FA for ; Mon, 24 Jan 2011 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 W8SQzOtgwXas for ; Mon, 24 Jan 2011 07:30:43 -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 85E6D3A6ADD for ; Mon, 24 Jan 2011 07:30:42 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3120817; Mon, 24 Jan 2011 16:33:36 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DD31D23F0292; Mon, 24 Jan 2011 16:33:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 24 Jan 2011 16:33:36 +0100 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Date: Mon, 24 Jan 2011 16:33:35 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu5z9D8UhecMC5qQI6eh5pB0NTuqAARpZOzAHDxB3A= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> 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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 24 Jan 2011 15:30:44 -0000 Well, if everyone says they won't perform a feature because somebody else i= s going to do it, that seems like a recipe for not having the feature perfo= rmed at all. There would need to be some rules on which entity performs the= feature and which entities do not perform the feature. I am not sure this = was clear from the draft. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 22 January 2011 09:32 > To: Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Draft new version:=20 > draft-holmberg-sipcore-proxy-feature >=20 >=20 > Hi Paul, >=20 > The idea is that each feature specification defines what=20 > indicating support of a feature means - in the same way it is=20 > done for UAs. >=20 > For example, just because a proxy indicate support of a=20 > feature, it doesn't automatically mean that others will=20 > address requests towards that proxy. It may for example mean=20 > that another entity, when it sees the feature tag, does not=20 > trigger some action. >=20 > I am sure there are things in the draft than can be=20 > clarified, including the 3GPP use-cases, but I think it would=20 > be useful to know (for me personally, and for 3GPP that wants=20 > to use the mechanism) whether the WG is willing to start this=20 > work. Nobody has objected to the work as such (you even say=20 > yourself that it might be useful :), and all questions and=20 > issues that have been raised will of course have to be solved=20 > (like we always do). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Saturday, January 22, 2011 3:00 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Draft new version: =20 > draft-holmberg-sipcore-proxy-feature >=20 > (speaking as an individual) >=20 > Inline... >=20 >=20 >=20 > On 1/21/2011 5:25 PM, Andrew Allen wrote: > > I have reviewed this draft and basically I am supportive of the > > objective of this work. > > > > I think the current use cases are very specific and the=20 > problem itself > > is even more general. > > > > I think the general requirement is that it is useful for=20 > UAs and other > > intermediaries to be able to detect the presence of an=20 > intermediary on > > the path of a registration or the route of a dialog when that > > intermediary provides some feature or service and be able=20 > to identify > > the URI of that intermediary in order to be able to address=20 > requests to > > it . In addition to the 3GPP specific use cases currently=20 > in the draft I > > think there are others including: >=20 > A major thing that is lacking here is any explanation of what=20 > it *means* > for an intermediary to "offer a feature" - what sorts of=20 > features those > are, and how one might avail oneself of them. >=20 > In the case of callerprefs/callee caps and currently defined, the > intermediary is a proxy that does address translation based on a > registrar. One knows that the way to avail themselves of the=20 > features is > to send a request to an AOR with registrations and use callerprefs to > request routing to a device with those features. >=20 > Or, one might learn about capabilities because they are returned > attached to a contact in a dialog, and then one avails oneself of the > capabilities by sending a subsequent request to that contact. >=20 > Now maybe this draft implies no more - that the capabilities are ones > that I can get access to by sending a request to the address I find in > the Route header. But of course its not normal to send a request with > the R-URI being an address taken from a Route header. >=20 > I think this is the usual thing - there is a framework within=20 > which this > makes sense, but its defined in IMS. And as usual, the=20 > inclination is to > say: please say more than that you want this to use in some=20 > unspecified > way with IMS. >=20 > Thanks, > Paul >=20 > > Dealing with call feature interactions > > > > In a deployment where different intermediaries provide=20 > different call > > features it is sometimes necessary to be able to detect that another > > intermediary has invoked a particular feature as that may=20 > mean that a > > particular feature should not be invoked or should be=20 > invoked in a way > > that takes account of the invocation of the feature by the other > > intermediary in order to prevent conflicts between=20 > different call features. >=20 > So in this case it is not about detecting *capabilities* that might be > used, but rather about detecting behavior that is already=20 > being applied? >=20 > > Detecting the presence of a SIP PBX > > > > SIP PBXs may be present in a network and may provide call=20 > features and > > other services on behalf of the UA. In some cases the UA may need to > > address requests to the PBX to invoke some features or services. >=20 > This is more what I was getting at. But its not clear to me what the > model is for "addressing requests to the PBX to invoke some=20 > features or > services". >=20 > > Although presence of the PBX could be indicated using=20 > configuration this > > isn't really effective when there are mobile UAs moving between > > enterprise networks that have PBXs and public networks that don't. > > > > Detecting the presence of a telephony application server. > > > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a=20 > Telephony > > Application Server (TAS) that provides call features on=20 > behalf of the > > UA. However not all 3GPP networks will necessarily deploy=20 > MMTel so it is > > necessary that a UA be able to identify that a TAS is=20 > involved in the > > call and be able to send requests such as REFER to the TAS=20 > in order to > > perform functions like call transfer. Having the TAS always act as a > > full B2BUA and overwrite the Contact is not a good solution=20 > as this will > > cause the loss of the GRUUs of the far end UAs. >=20 > This begs some higher level model of the possible components=20 > in a system > and their potential relationships to one another. I realize IMS has > this, that doesn't help in defining this in the ietf context. We are > starting to have such things in the work that was done in BLISS. But I > don't know if that is similar. And of course a bunch of ietf folk > believe that IMS has it all wrong. >=20 > > In addition since the same intermediary may perform=20 > multiple features or > > services it is useful for the URI that is provided to identify the > > related call feature or service so that when the UA=20 > addresses a request > > to the intermediary the intermediary knows what feature or=20 > service the > > request is related to. > > > > Some detailed comments: > > > > Section 6 > > > > NOTE: If a route set is built using Path, Record-Route or Service- > > > > Route header fields, any inserted feature tag will be=20 > copied into the > > > > associated Route header fields, together with other header field > > > > parameters. This specification does not define any specific meaning > > > > of the feature tags present in Route header fields in such cases. > > > > I think the meaning of the feature tag in the Route header=20 > is the same > > it means that the entity whose URI is on the Route supports=20 > the feature >=20 > Yes. Those other headers only exist to form Routes. I would think that > it is presence on the Route that would matter, except in cases where > presence on Record-Route leads something along the way to=20 > block the call. >=20 > > Section 7 > > > > I think the direction issue may need more work. It would I think be > > useful to indicate the directionality. > > > > I believe that SIPCORE should adopt this and work on a solution. >=20 > I hear you. Lets see what others have to say. >=20 > Thanks, > Paul >=20 > > Andrew > > > > *From:*sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] *On > > Behalf Of *Christer Holmberg > > *Sent:* Tuesday, December 07, 2010 7:38 AM > > *To:* sipcore@ietf.org > > *Subject:* [sipcore] Draft new version:=20 > draft-holmberg-sipcore-proxy-feature > > > > Hi, > > > > I've submitted a new version of the proxy-feature draft. > > > > It now contains more use-cases, for which the usage of the=20 > draft have > > been discussed in 3GPP. > > > > In the examples there is also some wording about why the=20 > usage of the > > Contact header field is not seen as appropriate. > > > > I have added some text about the "direction" of capabilities. > > > > Regards, > > > > Christer > > > >=20 > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain=20 > confidential > > information, privileged material (including material=20 > protected by the > > solicitor-client or other applicable privileges), or constitute > > non-public information. Any use of this information by=20 > anyone other than > > the intended recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the=20 > sender and delete > > this information from your system. Use, dissemination,=20 > distribution, or > > reproduction of this transmission by unintended recipients is not > > authorized and may be unlawful. > > > > > > > > _______________________________________________ > > 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 christer.holmberg@ericsson.com Mon Jan 24 07:39:58 2011 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 34ACC3A68FA for ; Mon, 24 Jan 2011 07:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4vgkKVI+ae3 for ; Mon, 24 Jan 2011 07:39: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 462DD3A6ADE for ; Mon, 24 Jan 2011 07:39:55 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-4b-4d3d9df9095e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.A4.13987.9FD9D3D4; Mon, 24 Jan 2011 16:42:49 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 24 Jan 2011 16:42:48 +0100 From: Christer Holmberg To: "Elwell, John" , Paul Kyzivat , "sipcore@ietf.org" Date: Mon, 24 Jan 2011 16:42:47 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu5z9D8UhecMC5qQI6eh5pB0NTuqAARpZOzAHDxB3AAAK/lYA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519441FDAEC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> 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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 24 Jan 2011 15:39:58 -0000 Hi John,=20 >Well, if everyone says they won't perform a feature because=20 >somebody else is going to do it, that seems like a recipe for=20 >not having the feature performed at all. There would need to=20 >be some rules on which entity performs the feature and which=20 >entities do not perform the feature. Absolutely. The feature tag definition needs to contain/refer these kind of= rules. >I am not sure this was clear from the draft. It is intended to be covered in section 6, but we for sure can add more tex= t to make it clearer. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 22 January 2011 09:32 > > To: Paul Kyzivat; sipcore@ietf.org > > Subject: Re: [sipcore] Draft new version:=20 > > draft-holmberg-sipcore-proxy-feature > >=20 > >=20 > > Hi Paul, > >=20 > > The idea is that each feature specification defines what indicating=20 > > support of a feature means - in the same way it is done for UAs. > >=20 > > For example, just because a proxy indicate support of a feature, it=20 > > doesn't automatically mean that others will address=20 > requests towards=20 > > that proxy. It may for example mean that another entity,=20 > when it sees=20 > > the feature tag, does not trigger some action. > >=20 > > I am sure there are things in the draft than can be clarified,=20 > > including the 3GPP use-cases, but I think it would be=20 > useful to know=20 > > (for me personally, and for 3GPP that wants to use the mechanism)=20 > > whether the WG is willing to start this work. Nobody has=20 > objected to=20 > > the work as such (you even say yourself that it might be useful :),=20 > > and all questions and issues that have been raised will of=20 > course have=20 > > to be solved (like we always do). > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org]=20 > On Behalf Of=20 > > Paul Kyzivat [pkyzivat@cisco.com] > > Sent: Saturday, January 22, 2011 3:00 AM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Draft new version: =20 > > draft-holmberg-sipcore-proxy-feature > >=20 > > (speaking as an individual) > >=20 > > Inline... > >=20 > >=20 > >=20 > > On 1/21/2011 5:25 PM, Andrew Allen wrote: > > > I have reviewed this draft and basically I am supportive of the=20 > > > objective of this work. > > > > > > I think the current use cases are very specific and the > > problem itself > > > is even more general. > > > > > > I think the general requirement is that it is useful for > > UAs and other > > > intermediaries to be able to detect the presence of an > > intermediary on > > > the path of a registration or the route of a dialog when that=20 > > > intermediary provides some feature or service and be able > > to identify > > > the URI of that intermediary in order to be able to address > > requests to > > > it . In addition to the 3GPP specific use cases currently > > in the draft I > > > think there are others including: > >=20 > > A major thing that is lacking here is any explanation of what it=20 > > *means* for an intermediary to "offer a feature" - what sorts of=20 > > features those are, and how one might avail oneself of them. > >=20 > > In the case of callerprefs/callee caps and currently defined, the=20 > > intermediary is a proxy that does address translation based on a=20 > > registrar. One knows that the way to avail themselves of=20 > the features=20 > > is to send a request to an AOR with registrations and use=20 > callerprefs=20 > > to request routing to a device with those features. > >=20 > > Or, one might learn about capabilities because they are returned=20 > > attached to a contact in a dialog, and then one avails=20 > oneself of the=20 > > capabilities by sending a subsequent request to that contact. > >=20 > > Now maybe this draft implies no more - that the=20 > capabilities are ones=20 > > that I can get access to by sending a request to the=20 > address I find in=20 > > the Route header. But of course its not normal to send a=20 > request with=20 > > the R-URI being an address taken from a Route header. > >=20 > > I think this is the usual thing - there is a framework within which=20 > > this makes sense, but its defined in IMS. And as usual, the=20 > > inclination is to > > say: please say more than that you want this to use in some=20 > > unspecified way with IMS. > >=20 > > Thanks, > > Paul > >=20 > > > Dealing with call feature interactions > > > > > > In a deployment where different intermediaries provide > > different call > > > features it is sometimes necessary to be able to detect=20 > that another=20 > > > intermediary has invoked a particular feature as that may > > mean that a > > > particular feature should not be invoked or should be > > invoked in a way > > > that takes account of the invocation of the feature by the other=20 > > > intermediary in order to prevent conflicts between > > different call features. > >=20 > > So in this case it is not about detecting *capabilities*=20 > that might be=20 > > used, but rather about detecting behavior that is already being=20 > > applied? > >=20 > > > Detecting the presence of a SIP PBX > > > > > > SIP PBXs may be present in a network and may provide call > > features and > > > other services on behalf of the UA. In some cases the UA=20 > may need to=20 > > > address requests to the PBX to invoke some features or services. > >=20 > > This is more what I was getting at. But its not clear to me=20 > what the=20 > > model is for "addressing requests to the PBX to invoke some=20 > features=20 > > or services". > >=20 > > > Although presence of the PBX could be indicated using > > configuration this > > > isn't really effective when there are mobile UAs moving between=20 > > > enterprise networks that have PBXs and public networks that don't. > > > > > > Detecting the presence of a telephony application server. > > > > > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a > > Telephony > > > Application Server (TAS) that provides call features on > > behalf of the > > > UA. However not all 3GPP networks will necessarily deploy > > MMTel so it is > > > necessary that a UA be able to identify that a TAS is > > involved in the > > > call and be able to send requests such as REFER to the TAS > > in order to > > > perform functions like call transfer. Having the TAS=20 > always act as a=20 > > > full B2BUA and overwrite the Contact is not a good solution > > as this will > > > cause the loss of the GRUUs of the far end UAs. > >=20 > > This begs some higher level model of the possible components in a=20 > > system and their potential relationships to one another. I=20 > realize IMS=20 > > has this, that doesn't help in defining this in the ietf=20 > context. We=20 > > are starting to have such things in the work that was done=20 > in BLISS.=20 > > But I don't know if that is similar. And of course a bunch of ietf=20 > > folk believe that IMS has it all wrong. > >=20 > > > In addition since the same intermediary may perform > > multiple features or > > > services it is useful for the URI that is provided to=20 > identify the=20 > > > related call feature or service so that when the UA > > addresses a request > > > to the intermediary the intermediary knows what feature or > > service the > > > request is related to. > > > > > > Some detailed comments: > > > > > > Section 6 > > > > > > NOTE: If a route set is built using Path, Record-Route or Service- > > > > > > Route header fields, any inserted feature tag will be > > copied into the > > > > > > associated Route header fields, together with other header field > > > > > > parameters. This specification does not define any=20 > specific meaning > > > > > > of the feature tags present in Route header fields in such cases. > > > > > > I think the meaning of the feature tag in the Route header > > is the same > > > it means that the entity whose URI is on the Route supports > > the feature > >=20 > > Yes. Those other headers only exist to form Routes. I would=20 > think that=20 > > it is presence on the Route that would matter, except in=20 > cases where=20 > > presence on Record-Route leads something along the way to block the=20 > > call. > >=20 > > > Section 7 > > > > > > I think the direction issue may need more work. It would=20 > I think be=20 > > > useful to indicate the directionality. > > > > > > I believe that SIPCORE should adopt this and work on a solution. > >=20 > > I hear you. Lets see what others have to say. > >=20 > > Thanks, > > Paul > >=20 > > > Andrew > > > > > > *From:*sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] *On > > > Behalf Of *Christer Holmberg > > > *Sent:* Tuesday, December 07, 2010 7:38 AM > > > *To:* sipcore@ietf.org > > > *Subject:* [sipcore] Draft new version:=20 > > draft-holmberg-sipcore-proxy-feature > > > > > > Hi, > > > > > > I've submitted a new version of the proxy-feature draft. > > > > > > It now contains more use-cases, for which the usage of the > > draft have > > > been discussed in 3GPP. > > > > > > In the examples there is also some wording about why the > > usage of the > > > Contact header field is not seen as appropriate. > > > > > > I have added some text about the "direction" of capabilities. > > > > > > Regards, > > > > > > Christer > > > > > >=20 > >=20 > --------------------------------------------------------------------- > > > This transmission (including any attachments) may contain > > confidential > > > information, privileged material (including material > > protected by the > > > solicitor-client or other applicable privileges), or constitute=20 > > > non-public information. Any use of this information by > > anyone other than > > > the intended recipient is prohibited. If you have received this=20 > > > transmission in error, please immediately reply to the > > sender and delete > > > this information from your system. Use, dissemination, > > distribution, or > > > reproduction of this transmission by unintended recipients is not=20 > > > authorized and may be unlawful. > > > > > > > > > > > > _______________________________________________ > > > 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 aallen@rim.com Mon Jan 24 07:42:28 2011 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 DA7663A6AE2 for ; Mon, 24 Jan 2011 07:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 3Sf49xkQ5JNX for ; Mon, 24 Jan 2011 07:42:28 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id D85C53A6ADE for ; Mon, 24 Jan 2011 07:42:27 -0800 (PST) X-AuditID: 0a666446-b7b8cae0000009e2-10-4d3d9e910d21 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 35.89.02530.19E9D3D4; Mon, 24 Jan 2011 10:45:22 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Jan 2011 10:45:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Mon, 24 Jan 2011 09:45:17 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature Thread-Index: AcuWE+kQHPR3a668Th+74O6FYhCCTAYacMJAA1c3KtAAAMquhw== From: "Andrew Allen" To: , , X-OriginalArrivalTime: 24 Jan 2011 15:45:21.0848 (UTC) FILETIME=[B5902380:01CBBBDD] X-Brightmail-Tracker: AAAAAwAAAZEXMpcWFzNPJQ== Subject: Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature 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, 24 Jan 2011 15:42:29 -0000 John I agree the indication needs to identify the features supported not just the= presence of an entity. Andrew ----- Original Message ----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Monday, January 24, 2011 09:32 AM To: Andrew Allen; Christer Holmberg ; sipcor= e@ietf.org Subject: RE: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-featur= e Just picking on one particular example from Andrew's post: > SIP PBXs may be present in a network and may provide call > features and other services on behalf of the UA. In some > cases the UA may need to address requests to the PBX to > invoke some features or services. Although presence of the > PBX could be indicated using configuration this isn't really > effective when there are mobile UAs moving between enterprise > networks that have PBXs and public networks that don't. [JRE] Although we all perhaps have a similar notion of what a PBX is, this i= s not a tightly defined term in the SIP context (the nearest we have is the= MARTINI notion of SIP-PBX in the context of bulk registration, but I suspec= t that is not what you have in mind). A PBX could do all sorts of things dif= ferently from some other SIP entity (such as a Service Provider SIP proxy),= but particular behaviour is very much dependent on the design of a PBX and= how it is deployed. If proxy features are indeed to be indicated (I have no= t yet formed an opinion on this), they should be more precisely defined, i.e= ., at the level of particular features that the PBX can perform, rather than= just the fact it is a PBX. John ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Mon Jan 24 09:09:53 2011 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 BFC1D3A6AF6 for ; Mon, 24 Jan 2011 09:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frwkZINoNwHT for ; Mon, 24 Jan 2011 09:09:52 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 319953A6B09 for ; Mon, 24 Jan 2011 09:09:52 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-a5-4d3db30ecb93 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 10.07.23694.E03BD3D4; Mon, 24 Jan 2011 18:12:46 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 24 Jan 2011 18:12:28 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Mon, 24 Jan 2011 18:12:26 +0100 Thread-Topic: 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel Thread-Index: Acu76d/T5rktUPNuRt+UPdEqX8dydQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519441FDB80@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A058519441FDB80ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel 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, 24 Jan 2011 17:09:53 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058519441FDB80ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, An issue that came up during the review of 199 was whether the fact that a = proxy was allowed to send unreliable 199 responses, even in the case of Req= uire:100rel. The WG previously agreed that Require:100rel as such does not affect proxie= s. But, the issue that has been raised is more related to the UAC: it could= receive unreliable 199 responses even if it has required provisional respo= nses to be sent reliably. So, people asked whether we would need to update RFC 3262, and state that a= UAC has to be ready to receive unreliable provisional responses even in th= e case of Require:100rel. Another proposal was so simply say that a proxy is not allowed to send 199 = responses in case of Require:100rel, and include a recommendation that the = UAC does not use Require:100rel when also indicating support of 199 - unles= s the UAC also uses other extensions that mandates Require:100rel, that is. My suggestion is to move forward with the second proposal, i.e. to say that= a proxy must not send 199 responses in case of Require:100rel. If someone objects to such way forward, please indicate it on the list (pre= ferable together with an alternative solution) by Friday this week. Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058519441FDB80ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
An issue that came up during the review of 199 was wh= ether the fact that a proxy was allowed to send unreliable 199 responses, e= ven in the case of Require:100rel.
 
The WG previously agreed that Require:100rel as such = does not affect proxies. But, the issue that has been raised is more relate= d to the UAC: it could receive unreliable 199 responses even if it has requ= ired provisional responses to be sent reliably.
 
So, people asked whether we would need to update RFC = 3262, and state that a UAC has to be ready to receive unreliable provisiona= l responses even in the case of Require:100rel.
 
Another proposal was so simply say that a proxy is no= t allowed to send 199 responses in case of Require:100rel, and include a re= commendation that the UAC does not use Require:100rel when also indicating = support of 199 - unless the UAC also uses other extensions that mandates Require:100rel, that is.
 
My suggestion is to move forward with the second prop= osal, i.e. to say that a proxy must not send 199 responses in case of Requi= re:100rel.
 
If someone objects to such way forward, please indica= te it on the list (preferable together with an alternative solution) by Fri= day this week.
 
Thanks!
 
Regards,
 
Christer
 
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058519441FDB80ESESSCMS0356e_-- From iesg-secretary@ietf.org Mon Jan 24 09:49:37 2011 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 064FE3A68F8; Mon, 24 Jan 2011 09:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 wEQWKATFm6RZ; Mon, 24 Jan 2011 09:49:36 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C40B3A691F; Mon, 24 Jan 2011 09:49:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124174935.31524.26653.idtracker@localhost> Date: Mon, 24 Jan 2011 09:49:35 -0800 Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'Indication of support for keep-alive' to Proposed Standard (draft-ietf-sipcore-keep-12.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, 24 Jan 2011 17:49:37 -0000 The IESG has approved the following document: - 'Indication of support for keep-alive' (draft-ietf-sipcore-keep-12.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-keep/ Technical Summary This document defines a mechanism by which adjacent SIP entities can negotiate the use of the NAT keep-alive mechanism defined in RFC 5626, even if the other mechanisms described in RFC 5626 are not being applied. Working Group Summary The document was largely without controversy during its lifetime. Early in the discussion of the mechanism (in the SIP working group), several people challenged the utility of a mechanism for negotiating this kind of behavior (as opposed to simply sending keep-alives unilaterally). Ultimately, the working group decided that the chances for things "going wrong" under those circumstances were too great, and elected to define an explicit negotiation mechanism. Document Quality Several implementors and network operators have indicated that the have need of and plan to implement the mechanism described in this document. It is not known whether any implementations of the mechanism exist. RFC Editor Note: (This note applies to -12 of the document) In section 10, OLD: To lower the chances of the malicious SIP entity's actions having adverse affects on such proxies, when a SIP entity sends STUN keep- alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages, it MUST, based on the procedure in section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error response is received for the STUN request, stop sending keep-alives for the remaining duration of the dialog (if the sending of keep- alives were negotiated for a dialog) or until the sending of keep- alives is re-negotiated for the registration (if the sending keep- alives were negotiated for a registration). NEW: To lower the chances of the malicious SIP entity's actions having adverse affects on such proxies, when a SIP entity sends STUN keep- alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages (as described in section 7.2.1 of RFC 5389, [RFC5389] it MUST stop sending keep-alives for the remaining duration of the dialog (if the sending of keep- alives were negotiated for a dialog) or until the sending of keep- alives is re-negotiated for the registration (if the sending keep- alives were negotiated for a registration). In Section 8.1, OLD: This section describes the syntax extensions to the ABNF syntax defined in RFC 3261, by defining a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. NEW: This section extends the ABNF definition of via-params from RFC3261 by adding a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. EQUAL is defined in RFC 3261. DIGIT is defined in RFC 5234. From mohamed.ati@orange-ftgroup.com Tue Jan 25 04:36:42 2011 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 7B29628C0EF for ; Tue, 25 Jan 2011 04:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_SINGLE_LETTER_H=0.672, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, 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 VakXx6TQDE6G for ; Tue, 25 Jan 2011 04:36:41 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1357B28C0E9 for ; Tue, 25 Jan 2011 04:36:41 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A97866C0004 for ; Tue, 25 Jan 2011 13:40:06 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9B1B76C0001 for ; Tue, 25 Jan 2011 13:40:06 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 13:39:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBC8C.ED1D6F74" Date: Tue, 25 Jan 2011 13:39:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Timer H and Timer B must have the same value ??? Thread-Index: Acu3LDc4vSwRNCGWRXiE1Np6XChtkQFYDGlwAAAQkVA= From: To: X-OriginalArrivalTime: 25 Jan 2011 12:39:37.0688 (UTC) FILETIME=[ED8A0580:01CBBC8C] Subject: Re: [sipcore] SIP Timer H and Timer B must have the same value ??? 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, 25 Jan 2011 12:36:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBC8C.ED1D6F74 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit > Hi all, > > I have a probleme understanding the following sentence RFC 3261 regarding H and B Timers in section 17.2.1. > "Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request." > Is this means that Timer H (in the server) and Timer B (in the client) must have the same value at both sides of a SIP hop ? > > If yes, why is this necessary and what are the impacts of not respecting this rule ? In fact, in some times this rule could not be satisfied: timers H and B are multiple of Timer T1 and this later may different at both sides of the SIP hop which is possible as the SIP hop node may have different types of connections at both sides (e.g. radio / Fiber). See figure below. > > P-CSCF S-CSCF > (T1= 2s) (T1= 500ms) > | | > | INVITE | > > $B",(J> |-------------------->| > | | | > | | | > Timer B | | | > 64*T1=128s| | 1xx | > | | <-------------| > $B",(J> > | | | | > | | | | > | | | | Timer H > | | | | 64*T1=32s > | > $B"-(J> > | > | > | > > $B"-(J> > > The Timer B controls transaction timeouts in INVITE Transaction. > > The Timer H determines when the server transaction abandons retransmitting the response 200 OK. > > > > ------_=_NextPart_001_01CBBC8C.ED1D6F74 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit RE: SIP Timer H and Timer B must have the same value ???

Hi all,

I have a probleme understanding the following sentence RFC 3261 regarding H and B Timers in section 17.2.1.

"Timer H determines when the server transaction abandons retransmitting the response.  Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request."

Is this means that Timer H (in the server) and Timer B (in the client) must have the same value at both sides of a SIP hop ?

If yes, why is this necessary and what are the impacts of not respecting this rule ?  In fact, in some times this rule could not be satisfied: timers H and B are multiple of Timer T1 and this later may different at both sides of the SIP hop which is possible as the SIP hop node may have different types of connections at both sides (e.g. radio / Fiber). See figure below.

            P-CSCF                         S-CSCF

                     (T1= 2s)            (T1= 500ms)
                         |                     |
                         |       INVITE        |
                     $B",(J   |-------------------->|
                     |   |                     |
                     |   |                     |
             Timer B |   |                     |
           64*T1=128s|   |              1xx          |
                     |   |              <-------------| $B",(J
                     |   |                     | |
                     |   |                     | |
                     |   |                     | |    Timer H
                     |   |                     | |   64*T1=32s   
                     |                           $B"-(J
                     |
                     |
                     |
                                                        $B"-(J                                       

The Timer B controls transaction timeouts in INVITE Transaction.

The Timer H determines when the server transaction abandons retransmitting the response 200 OK.




------_=_NextPart_001_01CBBC8C.ED1D6F74-- From adam@nostrum.com Tue Jan 25 06:12:13 2011 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 BE7753A6ACE for ; Tue, 25 Jan 2011 06:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, FS_SINGLE_LETTER_H=0.672, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 hPFrO6gdwECH for ; Tue, 25 Jan 2011 06:12: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 74CB43A6A8E for ; Tue, 25 Jan 2011 06:12:11 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0PEF6Do064657 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 08:15:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D3EDAEA.7050403@nostrum.com> Date: Tue, 25 Jan 2011 08:15:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.ati@orange-ftgroup.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030101080501070909050606" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Timer H and Timer B must have the same value ??? 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, 25 Jan 2011 14:12:13 -0000 This is a multi-part message in MIME format. --------------030101080501070909050606 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit [as participant] On 1/25/11 06:39, Jan 25, mohamed.ati@orange-ftgroup.com wrote: > > I have a probleme understanding the following sentence RFC 3261 > regarding H and B Timers in section 17.2.1. > > "/Timer H determines when the server transaction abandons > retransmitting the response. //Its value is chosen to equal Timer B, > the amount of time a client transaction will continue to retry sending > a request./"// > > Is this means that Timer H (in the server) and Timer B (in the client) > must have the same value at both sides of a SIP hop ? > > If yes, why is this necessary and what are the impacts of not > respecting this rule ? In fact, in some times this rule could not be > satisfied: timers H and B are multiple of Timer T1 and this later may > different at both sides of the SIP hop which is possible as the SIP > hop node may have different types of connections at both sides (e.g. > radio / Fiber). See figure below. > Actually, it's never a good idea to have differing values for T1 between a client and a server. Robert Sparks has put together a good writeup of the related issues here: http://blog.tekelec.com/blog/bid/13564/Changing-SIP-s-Transaction-Timers-Part-1-of-2 http://blog.tekelec.com/blog/bid/13566/Changing-SIP-s-Transaction-Timers-Part-2-of-2 [as chair] In the future, please address this kind of question to the sip-implementors mailing list. See https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors /a --------------030101080501070909050606 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit [as participant]

On 1/25/11 06:39, Jan 25, mohamed.ati@orange-ftgroup.com wrote:
RE: SIP Timer H and Timer B must have the same value ???

I have a probleme understanding the following sentence RFC 3261 regarding H and B Timers in section 17.2.1.

"Timer H determines when the server transaction abandons retransmitting the response.  Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request."

Is this means that Timer H (in the server) and Timer B (in the client) must have the same value at both sides of a SIP hop ?

If yes, why is this necessary and what are the impacts of not respecting this rule ?  In fact, in some times this rule could not be satisfied: timers H and B are multiple of Timer T1 and this later may different at both sides of the SIP hop which is possible as the SIP hop node may have different types of connections at both sides (e.g. radio / Fiber). See figure below.


Actually, it's never a good idea to have differing values for T1 between a client and a server. Robert Sparks has put together a good writeup of the related issues here:

http://blog.tekelec.com/blog/bid/13564/Changing-SIP-s-Transaction-Timers-Part-1-of-2
http://blog.tekelec.com/blog/bid/13566/Changing-SIP-s-Transaction-Timers-Part-2-of-2

[as chair]

In the future, please address this kind of question to the sip-implementors mailing list. See https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

/a
--------------030101080501070909050606-- From adam@nostrum.com Tue Jan 25 07:26:54 2011 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 977B33A67E9 for ; Tue, 25 Jan 2011 07:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 QNasL5HmxvjS for ; Tue, 25 Jan 2011 07:26:53 -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 B92E23A67E7 for ; Tue, 25 Jan 2011 07:26:52 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0PFTe1F071069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 09:29:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D3EEC64.2080302@nostrum.com> Date: Tue, 25 Jan 2011 09:29:40 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------020701060104050205080704" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 25 Jan 2011 15:26:54 -0000 This is a multi-part message in MIME format. --------------020701060104050205080704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit [as an individual] On 1/22/11 03:32, Jan 22, Christer Holmberg wrote: > I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, and for 3GPP that wants to use the mechanism) whether the WG is willing to start this work. Nobody has objected to the work as such (you even say yourself that it might be useful :), and all questions and issues that have been raised will of course have to be solved (like we always do). I don't think it's completely accurate to say that no objections have been registered. Cullen's message on November 9th was a pretty clear objection. Others -- like Dale -- have expressed confusion about how this mechanism is supposed to be used (and whether we're really talking about proxies, B2BUAs, or something else entirely that lives outside of the valid behavior defined by SIP). Many of the other responses have been somewhat pro-forma "3GPP wants this, so let's do it" messages without any other content. I'm not discounting them as meaningless, but they don't get us any closer to understanding what you're trying to do or addressing the concerns that have been expressed. So, I think we need to back up and get everyone on the same page. The use cases you've added to the document are a good start, but I note that the section headings all start with the same word. I would suggest -- and I'm doing this as an individual, not as a chair -- that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" document that: 1. contains a concise description of the problem being solved; 2. contains one or more general (non-IMS, applicable to the Internet) use cases; 3. contains a list of requirements on the solution; and 4. [this is the most important part] contains no protocol mechanism discussion at all. I think RFC5947 is a good example of how such a document can look. /a --------------020701060104050205080704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit [as an individual]

On 1/22/11 03:32, Jan 22, Christer Holmberg wrote: 
I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, and for 3GPP that wants to use the mechanism) whether the WG is willing to start this work. Nobody has objected to the work as such (you even say yourself that it might be useful :), and all questions and issues that have been raised will of course have to be solved (like we always do).

I don't think it's completely accurate to say that no objections have been registered. Cullen's message on November 9th was a pretty clear objection. Others -- like Dale -- have expressed confusion about how this mechanism is supposed to be used (and whether we're really talking about proxies, B2BUAs, or something else entirely that lives outside of the valid behavior defined by SIP). Many of the other responses have been somewhat pro-forma "3GPP wants this, so let's do it" messages without any other content. I'm not discounting them as meaningless, but they don't get us any closer to understanding what you're trying to do or addressing the concerns that have been expressed.

So, I think we need to back up and get everyone on the same page. The use cases you've added to the document are a good start, but I note that the section headings all start with the same word.

I would suggest -- and I'm doing this as an individual, not as a chair -- that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" document that:

  1. contains a concise description of the problem being solved;
  2. contains one or more general (non-IMS, applicable to the Internet) use cases;
  3. contains a list of requirements on the solution; and
  4. [this is the most important part] contains no protocol mechanism discussion at all.

I think RFC5947 is a good example of how such a document can look.

/a
--------------020701060104050205080704-- From christer.holmberg@ericsson.com Tue Jan 25 08:30:54 2011 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 8766E3A6817 for ; Tue, 25 Jan 2011 08:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpHedHr9KmTu for ; Tue, 25 Jan 2011 08:30:53 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2D25B3A680F for ; Tue, 25 Jan 2011 08:30:53 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-07-4d3efb6e366a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.63.13987.E6BFE3D4; Tue, 25 Jan 2011 17:33:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 25 Jan 2011 17:33:46 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Tue, 25 Jan 2011 17:33:45 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu8pLQsZ8wFFl/uQ0esYTT22vQSswABACQA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> In-Reply-To: <4D3EEC64.2080302@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@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 25 Jan 2011 16:30:54 -0000 Hi,=20 >I am sure there are things in the draft than can be clarified, including t= he 3GPP use-cases, but I think it would be useful to know (for me personall= y,=20 >and for 3GPP that wants to use the mechanism) whether the WG is willing to= start this work. Nobody has objected to the work as such (you even say=20 >yourself that it might be useful :), and all questions and issues that hav= e been raised will of course have to be solved (like we always do). > =09 > >I don't think it's completely accurate to say that no objections have been= registered. Cullen's message on November 9th was a pretty clear objection. I didn't read his message as an objection, but more as a question why we ca= n't use a B2BUA instead.=20 >Others -- like Dale -- have expressed confusion about how this mechanism i= s supposed to be used (and whether we're really talking about proxies, B2BU= As,=20 >or something else entirely that lives outside of the valid behavior define= d by SIP). I tried to address Dale's issues in the latest version of the draft, but I = may have missed something. >Many of the other responses have been somewhat pro-forma "3GPP wants this,= so let's do it" messages without any other content. I'm not discounting th= em=20 >as meaningless, but they don't get us any closer to understanding what you= 're trying to do or addressing the concerns that have been expressed. >=09 >So, I think we need to back up and get everyone on the same page. The use = cases you've added to the document are a good start, but I note that the=20 >section headings all start with the same word. >=09 >I would suggest -- and I'm doing this as an individual, not as a chair -- = that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" document tha= t: > > 1. contains a concise description of the problem being solved;=20 > =09 > 2. contains one or more general (non-IMS, applicable to the Internet) use= cases;=20 > > 3. contains a list of requirements on the solution; and=20 > =09 > 4. [this is the most important part] contains no protocol mechanism discu= ssion at all.=20 I'll try to put something together. But, just for my understanding: what happens if there are no non-IMS use ca= ses? >I think RFC5947 is a good example of how such a document can look. Regards, Christer =09 From adam@nostrum.com Tue Jan 25 11:22:14 2011 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 7A6153A6852 for ; Tue, 25 Jan 2011 11:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, SPF_PASS=-0.001, 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 ljerVMk13L7h for ; Tue, 25 Jan 2011 11:22: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 448413A6816 for ; Tue, 25 Jan 2011 11:22:13 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0PJOLMd094716 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 13:24:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D3F2365.2070504@nostrum.com> Date: Tue, 25 Jan 2011 13:24:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 25 Jan 2011 19:22:14 -0000 [as individual] On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: > I'll try to put something together. > But, just for my understanding: what happens if there are no non-IMS use cases? Then we need to try to figure out whether the inapplicability of the problem is due to the fact that it is being stated in overly-narrow terms (i.e., is there a more general problem here that does have applicability to the Internet?), or whether it is due to the fact that it only arises because of a specific architecture. If it's the first case, we'll probably need to generalize the problem to include the Internet (you know, the "I" in "IETF"). Then, you'll have a much easier time getting the WG to adopt it and the IESG to approve it. If the problem only exists because of certain walled-garden architectures, then things get trickier -- both in the WG and in the IESG. /a From R.Jesske@telekom.de Wed Jan 26 05:05:51 2011 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 619123A69AE for ; Wed, 26 Jan 2011 05:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxSHd+-s6eM6 for ; Wed, 26 Jan 2011 05:05:50 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 34DFC3A6857 for ; Wed, 26 Jan 2011 05:05:49 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 26 Jan 2011 14:07:59 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.69]) by he110890 ([10.134.92.131]) with mapi; Wed, 26 Jan 2011 14:07:50 +0100 From: To: , Date: Wed, 26 Jan 2011 14:07:49 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu8xaMn6Z+NjWqQSlqpf3vn6ry6yQAkzBwA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> In-Reply-To: <4D3F2365.2070504@nostrum.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 26 Jan 2011 13:05:51 -0000 Hi, there is an scenario which I would see also within the Internet approach. P= erhaps others too. When you register it would be useful to know if the proper emergency servic= e is served by the provider you are connected to. Such an explicit indication would help. Alice P1 REGISTRAR | | | |--- REGISTER-------------->| | | | | | |--- REGISTER-------------->| | | Path: P1;emergency | | | | | | | | |<-- 200 OK ----------------| | | Path: P1;emergency | | | Service-Route: REG | |<-- 200 OK ----------------| | | Path: P1;emergency | | | Service-Route: REG | | | | | So that Alice is now sure that an emergency call will get thought and the c= orrect emergency centre will be reached. Which is not even guaranteed in an= pure internet environment depended which service provider is chosen. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Adam Roach > Gesendet: Dienstag, 25. Januar 2011 20:24 > An: Christer Holmberg > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature > > [as individual] > > On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: > > I'll try to put something together. > > But, just for my understanding: what happens if there are > no non-IMS use cases? > > Then we need to try to figure out whether the inapplicability of the > problem is due to the fact that it is being stated in overly-narrow > terms (i.e., is there a more general problem here that does have > applicability to the Internet?), or whether it is due to the > fact that > it only arises because of a specific architecture. > > If it's the first case, we'll probably need to generalize the > problem to > include the Internet (you know, the "I" in "IETF"). Then, > you'll have a > much easier time getting the WG to adopt it and the IESG to > approve it. > > If the problem only exists because of certain walled-garden > architectures, then things get trickier -- both in the WG and > in the IESG. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed Jan 26 09:31:40 2011 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 9BE0E3A6845 for ; Wed, 26 Jan 2011 09:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 KdQBdbl+g3v1 for ; Wed, 26 Jan 2011 09:31:39 -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 B7DAC3A693B for ; Wed, 26 Jan 2011 09:31:39 -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: AosFAE7qP01AZnwN/2dsb2JhbACWWI4gc6EtjV2NfoVPBIUXhxKDRg Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2011 17:34:40 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0QHYeRQ005918 for ; Wed, 26 Jan 2011 17:34:40 GMT Message-ID: <4D405B30.8020503@cisco.com> Date: Wed, 26 Jan 2011 12:34:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 26 Jan 2011 17:31:40 -0000 inline On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > Hi, > there is an scenario which I would see also within the Internet approach. Perhaps others too. > > When you register it would be useful to know if the proper emergency service is served by the provider you are connected to. > Such an explicit indication would help. > > > Alice P1 REGISTRAR > | | | > |--- REGISTER-------------->| | > | | | > | |--- REGISTER-------------->| > | | Path: P1;emergency | > | | | > | | | > | |<-- 200 OK ----------------| > | | Path: P1;emergency | > | | Service-Route: REG | > |<-- 200 OK ----------------| | > | Path: P1;emergency | | > | Service-Route: REG | | > | | | > > So that Alice is now sure that an emergency call will get thought and the correct emergency centre will be reached. Which is not even guaranteed in an pure internet environment depended which service provider is chosen. Why is presence of this parameter on *Path* appropriate? Path has nothing to do with new calls originated by Alice. If anything were relevant, it would be Service-Route, which Alice would include in Route when making a new call. And, what does the "emergency" capability *mean*? Does it mean that it can route requests with urn:sos as the R-URI? Or that it recognizes URIs containing dial strings that contain emergency numbers? Or what? (If the latter, emergency numbers for what locale(s)?, and encoded in what manner?) But, why is this needed? Why not just send the request and cope with failure to route if/when it happens? Thanks, Paul From adam@nostrum.com Wed Jan 26 14:58:59 2011 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 985D73A69F5 for ; Wed, 26 Jan 2011 14:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SPF_PASS=-0.001, 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 OTt-VYZ1UMDp for ; Wed, 26 Jan 2011 14:58:58 -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 559403A6890 for ; Wed, 26 Jan 2011 14:58:58 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0QN1whV049614 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 26 Jan 2011 17:01:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D40A7E6.5050403@nostrum.com> Date: Wed, 26 Jan 2011 17:01:58 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Reminder: Location conveyance phone calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 22:59:00 -0000 Just a reminder that we're having a call to discuss the location conveyance draft tomorrow, January 27th. If you missed the original message (or if your email system didn't render it in a reasonable fashion), the time and bridge information is in the email archives here: http://www.ietf.org/mail-archive/web/sipcore/current/msg03878.html /a From christer.holmberg@ericsson.com Thu Jan 27 05:52:27 2011 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 CD72D3A6826 for ; Thu, 27 Jan 2011 05:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEj5Eu+iMHDU for ; Thu, 27 Jan 2011 05:52: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 A5C883A6803 for ; Thu, 27 Jan 2011 05:52:26 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-78-4d41794f44ed Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F6.B1.23694.F49714D4; Thu, 27 Jan 2011 14:55:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 27 Jan 2011 14:55:26 +0100 From: Christer Holmberg To: Adam Roach Date: Thu, 27 Jan 2011 14:55:25 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu8xZUNBn4ESCXXRAm4BnYzPds59gBTZHMw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> In-Reply-To: <4D3F2365.2070504@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@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 13:52:28 -0000 Hi, Eventhough I would be happy to see usage outside of IMS for the mechanism, = I don't see why 3GPP people should have to try to invent such use-cases "by= force".=20 I think there could be usages for SIP-PBXs, but I don't have any specific r= equirement/use-case to put on the table. Regarding the WG and IESG, we have specified mechanisms for 3GPP before, e.= g based on RFC 4083, and my understanding is that there is some kind of agr= eement between 3GPP and IETF. I do realize that we are not talking about a = P- header in this case, but that should not change the fundamental agreemen= t. But, if you now are saying that, unless there is a non-IMS use-case, IETF (= or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I= really think 3GPP should be informed about that. BTW, there is an *I* in IMS also :) Regards, Christer =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 25. tammikuuta 2011 21:24 > To: Christer Holmberg > Cc: Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Draft new version:=20 > draft-holmberg-sipcore-proxy-feature >=20 > [as individual] >=20 > On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: > > I'll try to put something together. > > But, just for my understanding: what happens if there are=20 > no non-IMS use cases? >=20 > Then we need to try to figure out whether the inapplicability=20 > of the problem is due to the fact that it is being stated in=20 > overly-narrow terms (i.e., is there a more general problem=20 > here that does have applicability to the Internet?), or=20 > whether it is due to the fact that it only arises because of=20 > a specific architecture. >=20 > If it's the first case, we'll probably need to generalize the=20 > problem to include the Internet (you know, the "I" in=20 > "IETF"). Then, you'll have a much easier time getting the WG=20 > to adopt it and the IESG to approve it. >=20 > If the problem only exists because of certain walled-garden=20 > architectures, then things get trickier -- both in the WG and=20 > in the IESG. >=20 > /a > = From pkyzivat@cisco.com Thu Jan 27 06:05:31 2011 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 8C22C3A683E for ; Thu, 27 Jan 2011 06:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WdC+F3O2EA6Z for ; Thu, 27 Jan 2011 06:05:30 -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 955333A67A5 for ; Thu, 27 Jan 2011 06:05:30 -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: AvsEAMILQU1AZnwM/2dsb2JhbACke3OgCJs7hU8EhReHEINE Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 14:08:29 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RE8TM5015120; Thu, 27 Jan 2011 14:08:29 GMT Message-ID: <4D417C5C.9030501@cisco.com> Date: Thu, 27 Jan 2011 09:08:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 14:05:31 -0000 Christer, The reason for including something for non-IMS usage is to motivate those not involved in IMS to be interested in the work. I guess that a sufficient mass of IMS participants would work, but its harder to get consensus without some of the others. Thanks, Paul On 1/27/2011 8:55 AM, Christer Holmberg wrote: > > Hi, > > Eventhough I would be happy to see usage outside of IMS for the mechanism, I don't see why 3GPP people should have to try to invent such use-cases "by force". > > I think there could be usages for SIP-PBXs, but I don't have any specific requirement/use-case to put on the table. > > Regarding the WG and IESG, we have specified mechanisms for 3GPP before, e.g based on RFC 4083, and my understanding is that there is some kind of agreement between 3GPP and IETF. I do realize that we are not talking about a P- header in this case, but that should not change the fundamental agreement. > > But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about that. > > BTW, there is an *I* in IMS also :) > > Regards, > > Christer > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 25. tammikuuta 2011 21:24 >> To: Christer Holmberg >> Cc: Paul Kyzivat; sipcore@ietf.org >> Subject: Re: [sipcore] Draft new version: >> draft-holmberg-sipcore-proxy-feature >> >> [as individual] >> >> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: >>> I'll try to put something together. >>> But, just for my understanding: what happens if there are >> no non-IMS use cases? >> >> Then we need to try to figure out whether the inapplicability >> of the problem is due to the fact that it is being stated in >> overly-narrow terms (i.e., is there a more general problem >> here that does have applicability to the Internet?), or >> whether it is due to the fact that it only arises because of >> a specific architecture. >> >> If it's the first case, we'll probably need to generalize the >> problem to include the Internet (you know, the "I" in >> "IETF"). Then, you'll have a much easier time getting the WG >> to adopt it and the IESG to approve it. >> >> If the problem only exists because of certain walled-garden >> architectures, then things get trickier -- both in the WG and >> in the IESG. >> >> /a >> From christer.holmberg@ericsson.com Thu Jan 27 06:19:33 2011 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 C43C43A686C for ; Thu, 27 Jan 2011 06:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzKeGXwdWnrG for ; Thu, 27 Jan 2011 06:19:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 705DC3A683E for ; Thu, 27 Jan 2011 06:19:31 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-80-4d417faaf99b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A2.95.23694.AAF714D4; Thu, 27 Jan 2011 15:22:34 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 27 Jan 2011 15:22:22 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 27 Jan 2011 15:22:20 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+K7GCT2UpP+RGTfe5eE23ETz8twAAQwJw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B093@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D417C5C.9030501@cisco.com> In-Reply-To: <4D417C5C.9030501@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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 14:19:33 -0000 Hi,=20 >The reason for including something for non-IMS usage is to motivate those = not involved in IMS to be interested in the=20 >work. I understand that, and I encourage people to think of use-cases that could = make the feature useful also outside IMS. Because, there is nothing IMS spe= cific with the feature itself, eventhough the current use cases come from I= MS. But, I would be very surprised if the lack of non-IMS use-cases would becom= e a show stopper. >I guess that a sufficient mass of IMS participants would work, but its har= der to get consensus without some of=20 >the others. Well, I think that a number of IMS participants, that also attend SIPCORE, = have indicated support of the draft. I have also received comments on the d= raft itself from many of those, so there is interest in actually participat= ing in the work. Regards, Christer > On 1/27/2011 8:55 AM, Christer Holmberg wrote: > > > > Hi, > > > > Eventhough I would be happy to see usage outside of IMS for=20 > the mechanism, I don't see why 3GPP people should have to try=20 > to invent such use-cases "by force". > > > > I think there could be usages for SIP-PBXs, but I don't=20 > have any specific requirement/use-case to put on the table. > > > > Regarding the WG and IESG, we have specified mechanisms for=20 > 3GPP before, e.g based on RFC 4083, and my understanding is=20 > that there is some kind of agreement between 3GPP and IETF. I=20 > do realize that we are not talking about a P- header in this=20 > case, but that should not change the fundamental agreement. > > > > But, if you now are saying that, unless there is a non-IMS=20 > use-case, IETF (or, at least SIPCORE) is no more going to=20 > accept doing any work for 3GPP, I really think 3GPP should be=20 > informed about that. > > > > BTW, there is an *I* in IMS also :) > > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: 25. tammikuuta 2011 21:24 > >> To: Christer Holmberg > >> Cc: Paul Kyzivat; sipcore@ietf.org > >> Subject: Re: [sipcore] Draft new version: > >> draft-holmberg-sipcore-proxy-feature > >> > >> [as individual] > >> > >> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: > >>> I'll try to put something together. > >>> But, just for my understanding: what happens if there are > >> no non-IMS use cases? > >> > >> Then we need to try to figure out whether the=20 > inapplicability of the=20 > >> problem is due to the fact that it is being stated in=20 > overly-narrow=20 > >> terms (i.e., is there a more general problem here that does have=20 > >> applicability to the Internet?), or whether it is due to the fact=20 > >> that it only arises because of a specific architecture. > >> > >> If it's the first case, we'll probably need to generalize=20 > the problem=20 > >> to include the Internet (you know, the "I" in "IETF").=20 > Then, you'll=20 > >> have a much easier time getting the WG to adopt it and the IESG to=20 > >> approve it. > >> > >> If the problem only exists because of certain walled-garden=20 > >> architectures, then things get trickier -- both in the WG=20 > and in the=20 > >> IESG. > >> > >> /a > >> > = From R.Jesske@telekom.de Thu Jan 27 07:18:01 2011 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 64C933A68F0 for ; Thu, 27 Jan 2011 07:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvyCZP2V0n5n for ; Thu, 27 Jan 2011 07:18:00 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 215713A68EF for ; Thu, 27 Jan 2011 07:17:59 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jan 2011 16:20:59 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.69]) by he110890 ([10.134.92.131]) with mapi; Thu, 27 Jan 2011 16:20:58 +0100 From: To: , Date: Thu, 27 Jan 2011 16:20:52 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu9f3vh+3m5QYFUQ0KhZJ6olw9MLgAtC51Q Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> In-Reply-To: <4D405B30.8020503@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 15:18:01 -0000 Hi Paul, I tried to express a possible use case more in general. So "emergency" means that the Call is passed through an Server that assures= that a INVITE with a URI addressing a emergency number e.g. 110@domain or = 999@domain or it could also use sos@domain will be handled correctly by the= AS and will be forwarded to the next emergency centre. My example was pointing to a use-case that could be happen within the inter= net, when service provider will support emergency. Und the user will be inf= ormed that he is sure that the emergency call will be passed through with t= he first INVITE. And not waiting for certain responses if the call will not= succeed. My intension was to try to point to possible internet applications that cou= ld use Christers draft. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Mittwoch, 26. Januar 2011 18:35 > An: sipcore@ietf.org > Betreff: Re: [sipcore] Draft new version: > draft-holmberg-sipcore-proxy-feature > > inline > > On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > > Hi, > > there is an scenario which I would see also within the > Internet approach. Perhaps others too. > > > > When you register it would be useful to know if the proper > emergency service is served by the provider you are connected to. > > Such an explicit indication would help. > > > > > > Alice P1 > REGISTRAR > > | | | > > |--- REGISTER-------------->| | > > | | | > > | |--- REGISTER-------------->| > > | | Path: P1;emergency | > > | | | > > | | | > > | |<-- 200 OK ----------------| > > | | Path: P1;emergency | > > | | Service-Route: REG | > > |<-- 200 OK ----------------| | > > | Path: P1;emergency | | > > | Service-Route: REG | | > > | | | > > > > So that Alice is now sure that an emergency call will get > thought and the correct emergency centre will be reached. > Which is not even guaranteed in an pure internet environment > depended which service provider is chosen. > > Why is presence of this parameter on *Path* appropriate? Path has > nothing to do with new calls originated by Alice. If anything were > relevant, it would be Service-Route, which Alice would > include in Route > when making a new call. > > And, what does the "emergency" capability *mean*? Does it > mean that it > can route requests with urn:sos as the R-URI? Or that it > recognizes URIs > containing dial strings that contain emergency numbers? Or > what? (If the > latter, emergency numbers for what locale(s)?, and encoded in > what manner?) > > But, why is this needed? Why not just send the request and cope with > failure to route if/when it happens? > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Thu Jan 27 07:30:42 2011 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 AD2683A67B6 for ; Thu, 27 Jan 2011 07:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SPF_PASS=-0.001, 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 MJSe0KfiOhfZ for ; Thu, 27 Jan 2011 07:30:41 -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 3C50B3A67B2 for ; Thu, 27 Jan 2011 07:30:41 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RFXgEr036774 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 09:33:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D419056.8080502@nostrum.com> Date: Thu, 27 Jan 2011 09:33:42 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 15:30:42 -0000 I think what Paul is saying is that the "emergency" capability would have to be in the service route, not the path -- since the Path has zero, zilch, nada, nothing to do with calls *made* by the handset. For my own part, I have some serious concerns about this kind of example, as it relies on named services, not capabilities. I suggest you very carefully read sections 5 and 6 of RFC5897. /a On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: > Hi Paul, > I tried to express a possible use case more in general. > So "emergency" means that the Call is passed through an Server that assures that a INVITE with a URI addressing a emergency number e.g. 110@domain or 999@domain or it could also use sos@domain will be handled correctly by the AS and will be forwarded to the next emergency centre. > > My example was pointing to a use-case that could be happen within the internet, when service provider will support emergency. Und the user will be informed that he is sure that the emergency call will be passed through with the first INVITE. And not waiting for certain responses if the call will not succeed. > > My intension was to try to point to possible internet applications that could use Christers draft. > > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Mittwoch, 26. Januar 2011 18:35 >> An: sipcore@ietf.org >> Betreff: Re: [sipcore] Draft new version: >> draft-holmberg-sipcore-proxy-feature >> >> inline >> >> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: >>> Hi, >>> there is an scenario which I would see also within the >> Internet approach. Perhaps others too. >>> When you register it would be useful to know if the proper >> emergency service is served by the provider you are connected to. >>> Such an explicit indication would help. >>> >>> >>> Alice P1 >> REGISTRAR >>> | | | >>> |--- REGISTER-------------->| | >>> | | | >>> | |--- REGISTER-------------->| >>> | | Path: P1;emergency | >>> | | | >>> | | | >>> | |<-- 200 OK ----------------| >>> | | Path: P1;emergency | >>> | | Service-Route: REG | >>> |<-- 200 OK ----------------| | >>> | Path: P1;emergency | | >>> | Service-Route: REG | | >>> | | | >>> >>> So that Alice is now sure that an emergency call will get >> thought and the correct emergency centre will be reached. >> Which is not even guaranteed in an pure internet environment >> depended which service provider is chosen. >> >> Why is presence of this parameter on *Path* appropriate? Path has >> nothing to do with new calls originated by Alice. If anything were >> relevant, it would be Service-Route, which Alice would >> include in Route >> when making a new call. >> >> And, what does the "emergency" capability *mean*? Does it >> mean that it >> can route requests with urn:sos as the R-URI? Or that it >> recognizes URIs >> containing dial strings that contain emergency numbers? Or >> what? (If the >> latter, emergency numbers for what locale(s)?, and encoded in >> what manner?) >> >> But, why is this needed? Why not just send the request and cope with >> failure to route if/when it happens? >> >> Thanks, >> Paul >> _______________________________________________ >> 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 aallen@rim.com Thu Jan 27 07:34:55 2011 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 0FA043A68C5 for ; Thu, 27 Jan 2011 07:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cDAl5us9Kife for ; Thu, 27 Jan 2011 07:34:53 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id A5B983A67E4 for ; Thu, 27 Jan 2011 07:34:53 -0800 (PST) X-AuditID: 0a666446-b7b18ae000000dfd-bc-4d4191544fd2 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 18.3F.03581.451914D4; Thu, 27 Jan 2011 10:37:56 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Jan 2011 10:37:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 27 Jan 2011 09:35:49 -0600 Message-ID: In-Reply-To: <4D417C5C.9030501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+K7Z6gh+uskpsQSWpaGlnmPcnFAACo3SA References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se><4D3EEC64.2080302@nostrum.com><7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se><4D3F2365.2070504@nostrum.com><7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D417C5C.9030501@cisco.com> From: "Andrew Allen" To: "Paul Kyzivat" , "Christer Holmberg" X-OriginalArrivalTime: 27 Jan 2011 15:37:56.0582 (UTC) FILETIME=[2B673060:01CBBE38] X-Brightmail-Tracker: AAAAAgAAAZEXRF1w Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 15:34:55 -0000 Paul, I expressed already that I think that solving this problem is also useful for non IMS environments such as IP PBXs in enterprises. More generally it could be useful in an internet environment whenever a SIP proxy wishes to advertise its support for some feature or capability. I also would like to point out that some of the features developed in SIP over the past decade that were initially seen as IMS only or IMS requirements initiated features have later been seen to be useful to the wider community and included as part of the solutions for other later SIP work and made it into the Hitchikers guide. Some examples include: P-Asserted-Identity header field, UPDATE method, Path header field, Registration Events Package I also would like to indicate that I am willing to contribute and review this work if it is adopted. Andrew -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, January 27, 2011 8:08 AM To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature Christer, The reason for including something for non-IMS usage is to motivate those not involved in IMS to be interested in the work. I guess that a sufficient mass of IMS participants would work, but its harder to get consensus without some of the others. Thanks, Paul On 1/27/2011 8:55 AM, Christer Holmberg wrote: > > Hi, > > Eventhough I would be happy to see usage outside of IMS for the mechanism, I don't see why 3GPP people should have to try to invent such use-cases "by force". > > I think there could be usages for SIP-PBXs, but I don't have any specific requirement/use-case to put on the table. > > Regarding the WG and IESG, we have specified mechanisms for 3GPP before, e.g based on RFC 4083, and my understanding is that there is some kind of agreement between 3GPP and IETF. I do realize that we are not talking about a P- header in this case, but that should not change the fundamental agreement. > > But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about that. > > BTW, there is an *I* in IMS also :) > > Regards, > > Christer > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 25. tammikuuta 2011 21:24 >> To: Christer Holmberg >> Cc: Paul Kyzivat; sipcore@ietf.org >> Subject: Re: [sipcore] Draft new version: >> draft-holmberg-sipcore-proxy-feature >> >> [as individual] >> >> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: >>> I'll try to put something together. >>> But, just for my understanding: what happens if there are >> no non-IMS use cases? >> >> Then we need to try to figure out whether the inapplicability >> of the problem is due to the fact that it is being stated in >> overly-narrow terms (i.e., is there a more general problem >> here that does have applicability to the Internet?), or >> whether it is due to the fact that it only arises because of >> a specific architecture. >> >> If it's the first case, we'll probably need to generalize the >> problem to include the Internet (you know, the "I" in >> "IETF"). Then, you'll have a much easier time getting the WG >> to adopt it and the IESG to approve it. >> >> If the problem only exists because of certain walled-garden >> architectures, then things get trickier -- both in the WG and >> in the IESG. >> >> /a >> _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Thu Jan 27 07:57:59 2011 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 8A1763A682A for ; Thu, 27 Jan 2011 07:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 6VnnSMRgqVhg for ; Thu, 27 Jan 2011 07:57:58 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 10ADD3A67C3 for ; Thu, 27 Jan 2011 07:57:57 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-e7-4d4196bc9fa1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 08.2E.13987.CB6914D4; Thu, 27 Jan 2011 17:01:00 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 27 Jan 2011 17:01:00 +0100 From: Christer Holmberg To: Adam Roach , "R.Jesske@telekom.de" Date: Thu, 27 Jan 2011 17:00:58 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+N5gFzF920S24SgCcD2EGX6n9qAAArfdA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B17B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> In-Reply-To: <4D419056.8080502@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 15:57:59 -0000 Hi,=20 >I think what Paul is saying is that the "emergency"=20 >capability would have to be in the service route, not the=20 >path -- since the Path has zero, zilch, nada, nothing to do=20 >with calls *made* by the handset. According to RFC 5626, a UAC can use the "ob" parameter - present in the Pa= th header field - at least to determine whether to send keep-alives. But, in networks that support emergency calls, and the feature tag, the reg= istrar can also use the Path to generate the Service-Route (which means the= feature tag will be inserted in the Service-Route). >For my own part, I have some serious concerns about this kind=20 >of example, as it relies on named services, not capabilities.=20 >I suggest you very carefully read sections 5 and 6 of RFC5897. You asked for non-IMS use-cases, and you got a proposal. I think we could d= o some brainstorming around it, and see whether it could result in somethin= g useful. Regards, Christer > On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: > > Hi Paul, > > I tried to express a possible use case more in general. > > So "emergency" means that the Call is passed through an=20 > Server that assures that a INVITE with a URI addressing a=20 > emergency number e.g. 110@domain or 999@domain or it could=20 > also use sos@domain will be handled correctly by the AS and=20 > will be forwarded to the next emergency centre. > > > > My example was pointing to a use-case that could be happen=20 > within the internet, when service provider will support=20 > emergency. Und the user will be informed that he is sure that=20 > the emergency call will be passed through with the first=20 > INVITE. And not waiting for certain responses if the call=20 > will not succeed. > > > > My intension was to try to point to possible internet=20 > applications that could use Christers draft. > > > > Best Regards > > > > Roland > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > >> Gesendet: Mittwoch, 26. Januar 2011 18:35 > >> An: sipcore@ietf.org > >> Betreff: Re: [sipcore] Draft new version: > >> draft-holmberg-sipcore-proxy-feature > >> > >> inline > >> > >> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > >>> Hi, > >>> there is an scenario which I would see also within the > >> Internet approach. Perhaps others too. > >>> When you register it would be useful to know if the proper > >> emergency service is served by the provider you are connected to. > >>> Such an explicit indication would help. > >>> > >>> > >>> Alice P1 > >> REGISTRAR > >>> | | =20 > | > >>> |--- REGISTER-------------->| =20 > | > >>> | | =20 > | > >>> | |---=20 > REGISTER-------------->| > >>> | | Path:=20 > P1;emergency | > >>> | | =20 > | > >>> | | =20 > | > >>> | |<-- 200 OK=20 > ----------------| > >>> | | Path:=20 > P1;emergency | > >>> | | =20 > Service-Route: REG | > >>> |<-- 200 OK ----------------| =20 > | > >>> | Path: P1;emergency | =20 > | > >>> | Service-Route: REG | =20 > | > >>> | | =20 > | > >>> > >>> So that Alice is now sure that an emergency call will get > >> thought and the correct emergency centre will be reached. > >> Which is not even guaranteed in an pure internet=20 > environment depended=20 > >> which service provider is chosen. > >> > >> Why is presence of this parameter on *Path* appropriate? Path has=20 > >> nothing to do with new calls originated by Alice. If anything were=20 > >> relevant, it would be Service-Route, which Alice would include in=20 > >> Route when making a new call. > >> > >> And, what does the "emergency" capability *mean*? Does it=20 > mean that=20 > >> it can route requests with urn:sos as the R-URI? Or that it=20 > >> recognizes URIs containing dial strings that contain emergency=20 > >> numbers? Or what? (If the latter, emergency numbers for what=20 > >> locale(s)?, and encoded in what manner?) > >> > >> But, why is this needed? Why not just send the request and=20 > cope with=20 > >> failure to route if/when it happens? > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@nostrum.com Thu Jan 27 07:59:28 2011 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 AE7743A682A for ; Thu, 27 Jan 2011 07:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, SPF_PASS=-0.001, 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 2X7nHHKEQyz2 for ; Thu, 27 Jan 2011 07:59: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 784963A6816 for ; Thu, 27 Jan 2011 07:59:27 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RG2RxX039360 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 10:02:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D419713.7030000@nostrum.com> Date: Thu, 27 Jan 2011 10:02:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 15:59:28 -0000 [as an individual] On 1/27/11 7:55 AM, Christer Holmberg wrote: > But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about that. Heh. If I were to make that kind of statement, it would be as a chair, and in coordination with the area directors. But that's not what I said, or meant to imply. I said things would "get trickier," meaning you'll face opposition from the members of the working group that hold generality as a key SIP attribute. I'm pointing out, just as a participant, that you will have a harder time drumming up interest for a niche mechanism than you will for a general one. Another hurdle you're going to face is harmonizing your proposal with RFC 5897. All three of your examples rely on doing, just about as vigorously as possible, precisely what RFC 5897 says not to do. /a From christer.holmberg@ericsson.com Thu Jan 27 08:04:51 2011 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 4415D3A682A for ; Thu, 27 Jan 2011 08:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCxHDUVJqa1m for ; Thu, 27 Jan 2011 08:04:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 373593A63CB for ; Thu, 27 Jan 2011 08:04:50 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-d2-4d419859d34b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 21.EE.13987.958914D4; Thu, 27 Jan 2011 17:07:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 27 Jan 2011 17:07:53 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Thu, 27 Jan 2011 17:07:48 +0100 Thread-Topic: Proxy-feature use-case: forking capability [was: Draft new version: draft-holmberg-sipcore-proxy-feature] Thread-Index: Acu+O5nBl5aHToRzQN6gM0EPa6zplAAAGg0g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B18D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> In-Reply-To: <4D419713.7030000@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== Subject: [sipcore] Proxy-feature use-case: forking capability [was: Draft new version: draft-holmberg-sipcore-proxy-feature] 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, 27 Jan 2011 16:04:51 -0000 Hi, One general use-case that I have been thinking about is a feature tag indic= ating=20 forking capability. Now, such indicator as such might not be very useful, but the feature=20 tag could also have values indicating what kind of forking has taken=20 place. I think that could be useful information in issues related to=20 forking, e.g. decissions regarding early media etc. For example: Record-Route: sip:myProxy.com;forking-para=3D4=20 (4 here indicates how many parallel forks have been created) Regards, Christer=20 From pkyzivat@cisco.com Thu Jan 27 08:11:50 2011 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 07B903A67D3 for ; Thu, 27 Jan 2011 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.23 X-Spam-Level: X-Spam-Status: No, score=-110.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 0p0t+gnvpi6C for ; Thu, 27 Jan 2011 08:11:42 -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 552DE3A6903 for ; Thu, 27 Jan 2011 08:11:41 -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: AvsEAA4pQU1AZnwN/2dsb2JhbACkfXOgNI1cjWCFTwSFF4cQg0Q Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 16:14:40 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0RGEZON015291; Thu, 27 Jan 2011 16:14:40 GMT Message-ID: <4D4199EB.5050705@cisco.com> Date: Thu, 27 Jan 2011 11:14:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Roach References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> In-Reply-To: <4D419056.8080502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 16:11:50 -0000 inline replies to both Adam and Roland On 1/27/2011 10:33 AM, Adam Roach wrote: > I think what Paul is saying is that the "emergency" capability would > have to be in the service route, not the path -- since the Path has > zero, zilch, nada, nothing to do with calls *made* by the handset. Yep. This is a key reason for the importance of use cases. Without this case, would we have had a hint that these features should go into Service-Route? Worse, would we be having UAs checking Record-Route in order to make decisions about what will happen when the UA originates requests? > For my own part, I have some serious concerns about this kind of > example, as it relies on named services, not capabilities. I suggest you > very carefully read sections 5 and 6 of RFC5897. +1 > /a > > On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: >> Hi Paul, >> I tried to express a possible use case more in general. >> So "emergency" means that the Call is passed through an Server that >> assures that a INVITE with a URI addressing a emergency number e.g. >> 110@domain or 999@domain or it could also use sos@domain will be >> handled correctly by the AS and will be forwarded to the next >> emergency centre. This is where it gets dicy. How would the UAC know that something advertising support for "emergency" was compatible with the UAC? For instance, does the UAC encode a dial string like "110" into a URI in a way that the "emergency" service will recognize as a dial string, and will the emergency service recognize the emergency dial strings that the user of the device is likely to use? One answer to that is that it isn't "emergency" that is reported as a capability, its "IMS-Vx.y-emergency", and there is an external spec somewhere that spells out in detail what behavior that implies. But that presents a very difficult model for interoperation. >> My example was pointing to a use-case that could be happen within the >> internet, when service provider will support emergency. Und the user >> will be informed that he is sure that the emergency call will be >> passed through with the first INVITE. And not waiting for certain >> responses if the call will not succeed. We have a solution for emergency calls - its the sos urn. And IIRC there has been some discussion of ways that a UAC could "test the path" to that URN when it connects to a network so it could inform the user if that will work or not. I'm pretty sure ecrit would have something to say about this example. >> My intension was to try to point to possible internet applications >> that could use Christers draft. Thank you for trying. So far what it has done is act as a counter example. Thanks, Paul >> Best Regards >> >> Roland >> >>> -----Ursprüngliche Nachricht----- >>> Von: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>> Gesendet: Mittwoch, 26. Januar 2011 18:35 >>> An: sipcore@ietf.org >>> Betreff: Re: [sipcore] Draft new version: >>> draft-holmberg-sipcore-proxy-feature >>> >>> inline >>> >>> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: >>>> Hi, >>>> there is an scenario which I would see also within the >>> Internet approach. Perhaps others too. >>>> When you register it would be useful to know if the proper >>> emergency service is served by the provider you are connected to. >>>> Such an explicit indication would help. >>>> >>>> >>>> Alice P1 >>> REGISTRAR >>>> | | | >>>> |--- REGISTER-------------->| | >>>> | | | >>>> | |--- REGISTER-------------->| >>>> | | Path: P1;emergency | >>>> | | | >>>> | | | >>>> | |<-- 200 OK ----------------| >>>> | | Path: P1;emergency | >>>> | | Service-Route: REG | >>>> |<-- 200 OK ----------------| | >>>> | Path: P1;emergency | | >>>> | Service-Route: REG | | >>>> | | | >>>> >>>> So that Alice is now sure that an emergency call will get >>> thought and the correct emergency centre will be reached. >>> Which is not even guaranteed in an pure internet environment >>> depended which service provider is chosen. >>> >>> Why is presence of this parameter on *Path* appropriate? Path has >>> nothing to do with new calls originated by Alice. If anything were >>> relevant, it would be Service-Route, which Alice would >>> include in Route >>> when making a new call. >>> >>> And, what does the "emergency" capability *mean*? Does it >>> mean that it >>> can route requests with urn:sos as the R-URI? Or that it >>> recognizes URIs >>> containing dial strings that contain emergency numbers? Or >>> what? (If the >>> latter, emergency numbers for what locale(s)?, and encoded in >>> what manner?) >>> >>> But, why is this needed? Why not just send the request and cope with >>> failure to route if/when it happens? >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> 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 Thu Jan 27 08:12:23 2011 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 D6AAA3A67D3 for ; Thu, 27 Jan 2011 08:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjkAHbOctUqi for ; Thu, 27 Jan 2011 08:12:23 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 70B223A6917 for ; Thu, 27 Jan 2011 08:12:22 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-97-4d419a1dc87a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F2.83.23694.D1A914D4; Thu, 27 Jan 2011 17:15:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 27 Jan 2011 17:15:25 +0100 From: Christer Holmberg To: Adam Roach Date: Thu, 27 Jan 2011 17:15:23 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+O5nBl5aHToRzQN6gM0EPa6zplAAAMMwA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> In-Reply-To: <4D419713.7030000@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@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 16:12:23 -0000 Hi,=20 >I'm pointing out, just as a participant, that you will have a=20 >harder time drumming up interest for a niche mechanism than=20 >you will for a general one. I think a number of people have already shown interest for this. >Another hurdle you're going to face is harmonizing your=20 >proposal with RFC 5897. All three of your examples rely on=20 >doing, just about as vigorously as possible, precisely what=20 >RFC 5897 says not to do. Feature tags indicate support of a capability. EVERY feature tag does that = - even if inserted in a Contact header field by a UA - and the feature tag = specification needs to define the meaning of that capability. The important thing is that it cannot be assumed that other entities unders= tand the meaning of the feature tag in order to progress a call (in such ca= ses you will also need an option-tag, inserted in a Require/Proxy-Require h= eader field). Regards, Christer= From christer.holmberg@ericsson.com Thu Jan 27 08:29:16 2011 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 39F123A6914 for ; Thu, 27 Jan 2011 08:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 uPkOnGzJu3+L for ; Thu, 27 Jan 2011 08:29:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 912103A6903 for ; Thu, 27 Jan 2011 08:29:14 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-5a-4d419e11b18b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C2.35.23694.11E914D4; Thu, 27 Jan 2011 17:32:17 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 27 Jan 2011 17:32:17 +0100 From: Christer Holmberg To: Paul Kyzivat , Adam Roach Date: Thu, 27 Jan 2011 17:32:16 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+PVjgbKUefA7hTNOIl2RGFu0SjAAAOlNg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> In-Reply-To: <4D4199EB.5050705@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 16:29:16 -0000 =20 >>I think what Paul is saying is that the "emergency"=20 >>capability would have to be in the service route, not the path -- since t= he Path has=20 >>zero, zilch, nada, nothing to do with calls *made* by the handset. >=20 >Yep. This is a key reason for the importance of use cases.=20 >Without this case, would we have had a hint that these=20 >features should go into Service-Route? >=20 >Worse, would we be having UAs checking Record-Route in order=20 >to make decisions about what will happen when the UA=20 >originates requests? >=20 >>For my own part, I have some serious concerns about this kind of=20 >>example, as it relies on named services, not capabilities.=20 >>I suggest you very carefully read sections 5 and 6 of RFC5897. >=20 >+1 I am not sure what the difference between a feature and a service is... For example, RFC 5897 seems to call things like call forwarding and call sc= reening as features, while I am sure others would call them services.=20 I also see the IMS use-cases in the draft as features provided in IMS netwo= rks. Being able to handle emergency calls could also be seen as a feature.= =20 So, I think it would be a waste of time to argue about whether something is= a service or a feature. Again, the important thing, which I think was also raised many times during= the good old days of service-id discussions, is that indicating support of= a capability is just that - indicating support of a capability. Others may= choose to enable that capability, or they may not. But, in order to execut= e the capability, one must of course implement the associated feature speci= fication (whether it's an RFC or some other specification). Regards, Christer >=20 > > /a > > > > On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: > >> Hi Paul, > >> I tried to express a possible use case more in general. > >> So "emergency" means that the Call is passed through an=20 > Server that=20 > >> assures that a INVITE with a URI addressing a emergency number e.g. > >> 110@domain or 999@domain or it could also use sos@domain will be=20 > >> handled correctly by the AS and will be forwarded to the next=20 > >> emergency centre. >=20 > This is where it gets dicy. How would the UAC know that=20 > something advertising support for "emergency" was compatible=20 > with the UAC? >=20 > For instance, does the UAC encode a dial string like "110"=20 > into a URI in a way that the "emergency" service will=20 > recognize as a dial string, and will the emergency service=20 > recognize the emergency dial strings that the user of the=20 > device is likely to use? >=20 > One answer to that is that it isn't "emergency" that is=20 > reported as a capability, its "IMS-Vx.y-emergency", and there=20 > is an external spec somewhere that spells out in detail what=20 > behavior that implies. >=20 > But that presents a very difficult model for interoperation. >=20 > >> My example was pointing to a use-case that could be happen=20 > within the=20 > >> internet, when service provider will support emergency.=20 > Und the user=20 > >> will be informed that he is sure that the emergency call will be=20 > >> passed through with the first INVITE. And not waiting for certain=20 > >> responses if the call will not succeed. >=20 > We have a solution for emergency calls - its the sos urn. And=20 > IIRC there has been some discussion of ways that a UAC could=20 > "test the path" to that URN when it connects to a network so=20 > it could inform the user if that will work or not. >=20 > I'm pretty sure ecrit would have something to say about this example. >=20 > >> My intension was to try to point to possible internet applications=20 > >> that could use Christers draft. >=20 > Thank you for trying. So far what it has done is act as a=20 > counter example. >=20 > Thanks, > Paul >=20 > >> Best Regards > >> > >> Roland > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: sipcore-bounces@ietf.org > >>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > >>> Gesendet: Mittwoch, 26. Januar 2011 18:35 > >>> An: sipcore@ietf.org > >>> Betreff: Re: [sipcore] Draft new version: > >>> draft-holmberg-sipcore-proxy-feature > >>> > >>> inline > >>> > >>> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > >>>> Hi, > >>>> there is an scenario which I would see also within the > >>> Internet approach. Perhaps others too. > >>>> When you register it would be useful to know if the proper > >>> emergency service is served by the provider you are connected to. > >>>> Such an explicit indication would help. > >>>> > >>>> > >>>> Alice P1 > >>> REGISTRAR > >>>> | | | > >>>> |--- REGISTER-------------->| | > >>>> | | | > >>>> | |--- REGISTER-------------->| > >>>> | | Path: P1;emergency | > >>>> | | | > >>>> | | | > >>>> | |<-- 200 OK ----------------| > >>>> | | Path: P1;emergency | > >>>> | | Service-Route: REG | > >>>> |<-- 200 OK ----------------| | > >>>> | Path: P1;emergency | | > >>>> | Service-Route: REG | | > >>>> | | | > >>>> > >>>> So that Alice is now sure that an emergency call will get > >>> thought and the correct emergency centre will be reached. > >>> Which is not even guaranteed in an pure internet environment=20 > >>> depended which service provider is chosen. > >>> > >>> Why is presence of this parameter on *Path* appropriate? Path has=20 > >>> nothing to do with new calls originated by Alice. If=20 > anything were=20 > >>> relevant, it would be Service-Route, which Alice would include in=20 > >>> Route when making a new call. > >>> > >>> And, what does the "emergency" capability *mean*? Does it=20 > mean that=20 > >>> it can route requests with urn:sos as the R-URI? Or that it=20 > >>> recognizes URIs containing dial strings that contain emergency=20 > >>> numbers? Or what? (If the latter, emergency numbers for what=20 > >>> locale(s)?, and encoded in what manner?) > >>> > >>> But, why is this needed? Why not just send the request=20 > and cope with=20 > >>> failure to route if/when it happens? > >>> > >>> Thanks, > >>> Paul > >>> _______________________________________________ > >>> 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 Jan 27 08:39:29 2011 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 EBA8E3A6836 for ; Thu, 27 Jan 2011 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-0.001, 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 itTQdtZYfUcP for ; Thu, 27 Jan 2011 08:39:29 -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 60DA528C14E for ; Thu, 27 Jan 2011 08:39:26 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RGgQ2g042864 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 10:42:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D41A072.9040202@nostrum.com> Date: Thu, 27 Jan 2011 10:42:26 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 16:39:30 -0000 On 1/27/11 10:32 AM, Christer Holmberg wrote: > I am not sure what the difference between a feature and a service is... Then it's a good thing RFC 5897 provides guidance on that front: "The best way to avoid this problem is to use feature tags that can be matched to well-defined signaling features -- media types, required SIP extensions, and so on. In particular, the golden rule is that the granularity of feature tags must be equivalent to the granularity of individual features that can be signaled in SIP." /a From christer.holmberg@ericsson.com Thu Jan 27 09:03:48 2011 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 86BD23A6934 for ; Thu, 27 Jan 2011 09:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYsv4aTUJpF6 for ; Thu, 27 Jan 2011 09:03:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 270423A692D for ; Thu, 27 Jan 2011 09:03:46 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-1f-4d41a62afda4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.78.23694.A26A14D4; Thu, 27 Jan 2011 18:06:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 27 Jan 2011 18:06:49 +0100 From: Christer Holmberg To: Adam Roach Date: Thu, 27 Jan 2011 18:06:48 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+QS+Vxi7jb1ojQ8K/E3WNvTMWpAAAYXsg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1C9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41A072.9040202@nostrum.com> In-Reply-To: <4D41A072.9040202@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@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:03:48 -0000 Hi,=20 >>I am not sure what the difference between a feature and a=20 >>service is... >=20 >Then it's a good thing RFC 5897 provides guidance on that front: >=20 >"The best way to avoid this problem is to use feature tags=20 >that can be matched to well-defined signaling features -- media=20 >types, required SIP extensions, and so on. In particular,=20 >the golden rule is that the granularity of feature tags must be=20 >equivalent to the granularity of individual features that can be=20 >signaled in SIP." I am not sure how much the text really clarifies. But, assuming it does, it probably works for pure SIP features, associated = with a single dialog. For example, I think the forking capability indicator= I suggested fits fine into that. But, the features in the draft are more complex than that, and may include = multiple dialogs etc. Having said that, if you think there is a better way of solving the use-cas= es in the draft, I am willing to hear about it. Regards, Christer= From adam@nostrum.com Thu Jan 27 09:06:36 2011 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 90EF428C143 for ; Thu, 27 Jan 2011 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, SPF_PASS=-0.001, 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 s28dhSFdrloo for ; Thu, 27 Jan 2011 09:06: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 751F928C125 for ; Thu, 27 Jan 2011 09:06:35 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RH9Uij045191 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 11:09:30 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D41A6CA.1010609@nostrum.com> Date: Thu, 27 Jan 2011 11:09:30 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41A072.9040202@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1C9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B1C9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:06:36 -0000 [as an individual] On 1/27/11 11:06 AM, Christer Holmberg wrote: > Having said that, if you think there is a better way of solving the > use-cases in the draft, I am willing to hear about it. Splendid. What are your requirements? Answer in internet-draft form, please. /a From christer.holmberg@ericsson.com Thu Jan 27 09:10:27 2011 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 2579A28C13C for ; Thu, 27 Jan 2011 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG7ZRvRoItES for ; Thu, 27 Jan 2011 09:10:25 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0F6EC28C125 for ; Thu, 27 Jan 2011 09:10:24 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-84-4d41a7b7c312 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 92.F8.23694.7B7A14D4; Thu, 27 Jan 2011 18:13:28 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 27 Jan 2011 18:13:27 +0100 From: Christer Holmberg To: Adam Roach Date: Thu, 27 Jan 2011 18:13:25 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+RPrErK5doFYgS5eDC/63c4rqRgAACTbQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1CF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41A072.9040202@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1C9@ESESSCMS0356.eemea.ericsson.se> <4D41A6CA.1010609@nostrum.com> In-Reply-To: <4D41A6CA.1010609@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@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:10:28 -0000 Hi,=20 >>Having said that, if you think there is a better way of solving the=20 >>use-cases in the draft, I am willing to hear about it. >=20 >Splendid. What are your requirements? Answer in internet-draft form, pleas= e. I already indicated that I will do that. What I am trying to figure out, based on the feedback I have got from you a= nd Paul, is whether writing such a draft would be a waste of time, unless I= can come up with non-IMS use-cases. Regards, Christer From pkyzivat@cisco.com Thu Jan 27 09:12:50 2011 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 3D06D28C141 for ; Thu, 27 Jan 2011 09:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 y5wvUmlT19GQ for ; Thu, 27 Jan 2011 09:12:49 -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 4D95A28C13C for ; Thu, 27 Jan 2011 09:12:49 -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: AvsEAB83QU1AZnwN/2dsb2JhbACkfXOgRZtIgneCWASFF4cQg0Q Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 17:15:53 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0RHFquf011799; Thu, 27 Jan 2011 17:15:52 GMT Message-ID: <4D41A848.1090304@cisco.com> Date: Thu, 27 Jan 2011 12:15:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:12:50 -0000 On 1/27/2011 11:15 AM, Christer Holmberg wrote: >> Another hurdle you're going to face is harmonizing your >> proposal with RFC 5897. All three of your examples rely on >> doing, just about as vigorously as possible, precisely what >> RFC 5897 says not to do. > > Feature tags indicate support of a capability. EVERY feature tag does that - even if inserted in a Contact header field by a UA - and the feature tag specification needs to define the meaning of that capability. > > The important thing is that it cannot be assumed that other entities understand the meaning of the feature tag in order to progress a call (in such cases you will also need an option-tag, inserted in a Require/Proxy-Require header field). There was also an extended discussion (battle?), around the time the callerprefs came out, about the validity of using feature-tags (capabilities) to identify arbitrary *services* where the service was to be defined in some external, potentially restricted document. The crux of the argument was whether capabilities were orthogonal to one another or not. The concern was (and remains) that interoperability is severely limited if there are potentially many ways of specifying the same capability, as part of this service or that service. (IIRC, one of the examples used was video calling, where somebody might describe a capability "video-phone" that implies a particular combination of audio and video. Two UAs that supported this might work well together, but somebody with a UA that supports exactly the same media types and *could* interoperate if connected, might fail to interoperate for lack of specifying the proper feature-tag.) We run a risk of going through the same thing here. That is what 5897 was about too. Thanks, Paul From md3135@att.com Thu Jan 27 09:19:43 2011 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 6ABD73A681B for ; Thu, 27 Jan 2011 09:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.123 X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, 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 MN7FKjiJ5SBI for ; Thu, 27 Jan 2011 09:19:41 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 7763A3A67B3 for ; Thu, 27 Jan 2011 09:19:41 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1296148962!24080388!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6968 invoked from network); 27 Jan 2011 17:22:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jan 2011 17:22:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0RHLnfG006976 for ; Thu, 27 Jan 2011 12:21:49 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0RHISwi003464 for ; Thu, 27 Jan 2011 12:21:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 12:20:20 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA08F56ABB@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4D419713.7030000@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+O67DYjwYaUD4Q5a3OOStZK/3TQACmegg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se><4D3EEC64.2080302@nostrum.com><7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se><4D3F2365.2070504@nostrum.com><7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Adam Roach" , "Christer Holmberg" Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:19:43 -0000 Adam, Could you please consult with the AD and chairs on Christer's question? It would be useful for 3GPP to understand the working relationship. Regards, Martin -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, January 27, 2011 11:02 AM To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature [as an individual] On 1/27/11 7:55 AM, Christer Holmberg wrote: > But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about that. Heh. If I were to make that kind of statement, it would be as a chair,=20 and in coordination with the area directors. But that's not what I said, or meant to imply. I said things would "get trickier," meaning you'll=20 face opposition from the members of the working group that hold=20 generality as a key SIP attribute. I'm pointing out, just as a participant, that you will have a harder=20 time drumming up interest for a niche mechanism than you will for a=20 general one. Another hurdle you're going to face is harmonizing your proposal with=20 RFC 5897. All three of your examples rely on doing, just about as=20 vigorously as possible, precisely what RFC 5897 says not to do. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Thu Jan 27 09:21:18 2011 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 78A0A3A68FE for ; Thu, 27 Jan 2011 09:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.227 X-Spam-Level: X-Spam-Status: No, score=-110.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 QAXO-DAo6o2f for ; Thu, 27 Jan 2011 09:21:10 -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 914643A682D for ; Thu, 27 Jan 2011 09:21:04 -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: AvsEAHY5QU1AZnwM/2dsb2JhbACkfXOgS41cjWyFTwSFF4cQg0Q Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 17:24:08 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RHO7p9007093; Thu, 27 Jan 2011 17:24:07 GMT Message-ID: <4D41AA37.1060009@cisco.com> Date: Thu, 27 Jan 2011 12:24:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:21:18 -0000 On 1/27/2011 11:32 AM, Christer Holmberg wrote: > I am not sure what the difference between a feature and a service is... > > For example, RFC 5897 seems to call things like call forwarding and call screening as features, while I am sure others would call them services. > > I also see the IMS use-cases in the draft as features provided in IMS networks. Being able to handle emergency calls could also be seen as a feature. > > So, I think it would be a waste of time to argue about whether something is a service or a feature. IMO the key differences are: - the definition must be publicly available - capabilities/feature-tags should be orthogonal (And of course it is impossible to verify orthogonality without the definitions being available.) My gut feeling is that most "services" are an assemblage of a number of capabilities. Thanks, Paul > Again, the important thing, which I think was also raised many times during the good old days of service-id discussions, is that indicating support of a capability is just that - indicating support of a capability. Others may choose to enable that capability, or they may not. But, in order to execute the capability, one must of course implement the associated feature specification (whether it's an RFC or some other specification). > > Regards, > > Christer > > > > > > >> >>> /a >>> >>> On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: >>>> Hi Paul, >>>> I tried to express a possible use case more in general. >>>> So "emergency" means that the Call is passed through an >> Server that >>>> assures that a INVITE with a URI addressing a emergency number e.g. >>>> 110@domain or 999@domain or it could also use sos@domain will be >>>> handled correctly by the AS and will be forwarded to the next >>>> emergency centre. >> >> This is where it gets dicy. How would the UAC know that >> something advertising support for "emergency" was compatible >> with the UAC? >> >> For instance, does the UAC encode a dial string like "110" >> into a URI in a way that the "emergency" service will >> recognize as a dial string, and will the emergency service >> recognize the emergency dial strings that the user of the >> device is likely to use? >> >> One answer to that is that it isn't "emergency" that is >> reported as a capability, its "IMS-Vx.y-emergency", and there >> is an external spec somewhere that spells out in detail what >> behavior that implies. >> >> But that presents a very difficult model for interoperation. >> >>>> My example was pointing to a use-case that could be happen >> within the >>>> internet, when service provider will support emergency. >> Und the user >>>> will be informed that he is sure that the emergency call will be >>>> passed through with the first INVITE. And not waiting for certain >>>> responses if the call will not succeed. >> >> We have a solution for emergency calls - its the sos urn. And >> IIRC there has been some discussion of ways that a UAC could >> "test the path" to that URN when it connects to a network so >> it could inform the user if that will work or not. >> >> I'm pretty sure ecrit would have something to say about this example. >> >>>> My intension was to try to point to possible internet applications >>>> that could use Christers draft. >> >> Thank you for trying. So far what it has done is act as a >> counter example. >> >> Thanks, >> Paul >> >>>> Best Regards >>>> >>>> Roland >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>>>> Gesendet: Mittwoch, 26. Januar 2011 18:35 >>>>> An: sipcore@ietf.org >>>>> Betreff: Re: [sipcore] Draft new version: >>>>> draft-holmberg-sipcore-proxy-feature >>>>> >>>>> inline >>>>> >>>>> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: >>>>>> Hi, >>>>>> there is an scenario which I would see also within the >>>>> Internet approach. Perhaps others too. >>>>>> When you register it would be useful to know if the proper >>>>> emergency service is served by the provider you are connected to. >>>>>> Such an explicit indication would help. >>>>>> >>>>>> >>>>>> Alice P1 >>>>> REGISTRAR >>>>>> | | | >>>>>> |--- REGISTER-------------->| | >>>>>> | | | >>>>>> | |--- REGISTER-------------->| >>>>>> | | Path: P1;emergency | >>>>>> | | | >>>>>> | | | >>>>>> | |<-- 200 OK ----------------| >>>>>> | | Path: P1;emergency | >>>>>> | | Service-Route: REG | >>>>>> |<-- 200 OK ----------------| | >>>>>> | Path: P1;emergency | | >>>>>> | Service-Route: REG | | >>>>>> | | | >>>>>> >>>>>> So that Alice is now sure that an emergency call will get >>>>> thought and the correct emergency centre will be reached. >>>>> Which is not even guaranteed in an pure internet environment >>>>> depended which service provider is chosen. >>>>> >>>>> Why is presence of this parameter on *Path* appropriate? Path has >>>>> nothing to do with new calls originated by Alice. If >> anything were >>>>> relevant, it would be Service-Route, which Alice would include in >>>>> Route when making a new call. >>>>> >>>>> And, what does the "emergency" capability *mean*? Does it >> mean that >>>>> it can route requests with urn:sos as the R-URI? Or that it >>>>> recognizes URIs containing dial strings that contain emergency >>>>> numbers? Or what? (If the latter, emergency numbers for what >>>>> locale(s)?, and encoded in what manner?) >>>>> >>>>> But, why is this needed? Why not just send the request >> and cope with >>>>> failure to route if/when it happens? >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> 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 christer.holmberg@ericsson.com Thu Jan 27 09:24:18 2011 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 048B928C142 for ; Thu, 27 Jan 2011 09:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 4V-75GhxIjXs for ; Thu, 27 Jan 2011 09:24: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 E09E828C125 for ; Thu, 27 Jan 2011 09:24:04 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-10-4d41aaea6a14 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 78.C5.13987.AEAA14D4; Thu, 27 Jan 2011 18:27:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 27 Jan 2011 18:26:44 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 27 Jan 2011 18:26:39 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+RwYYqTY96ONdQAyuH12JcvEBsAAACPRg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1D3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41AA37.1060009@cisco.com> In-Reply-To: <4D41AA37.1060009@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:24:19 -0000 Hi,=20 >IMO the key differences are: >=20 >- the definition must be publicly available >- capabilities/feature-tags should be orthogonal >=20 >(And of course it is impossible to verify orthogonality=20 >without the definitions being available.) As far as I know, all 3GPP specifications are publicly available. Regards, Christer >=20 > > Again, the important thing, which I think was also raised=20 > many times during the good old days of service-id=20 > discussions, is that indicating support of a capability is=20 > just that - indicating support of a capability. Others may=20 > choose to enable that capability, or they may not. But, in=20 > order to execute the capability, one must of course implement=20 > the associated feature specification (whether it's an RFC or=20 > some other specification). > > > > Regards, > > > > Christer > > > > > > > > > > > > > >> > >>> /a > >>> > >>> On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote: > >>>> Hi Paul, > >>>> I tried to express a possible use case more in general. > >>>> So "emergency" means that the Call is passed through an > >> Server that > >>>> assures that a INVITE with a URI addressing a emergency=20 > number e.g. > >>>> 110@domain or 999@domain or it could also use sos@domain will be=20 > >>>> handled correctly by the AS and will be forwarded to the next=20 > >>>> emergency centre. > >> > >> This is where it gets dicy. How would the UAC know that something=20 > >> advertising support for "emergency" was compatible with the UAC? > >> > >> For instance, does the UAC encode a dial string like "110" > >> into a URI in a way that the "emergency" service will=20 > recognize as a=20 > >> dial string, and will the emergency service recognize the=20 > emergency=20 > >> dial strings that the user of the device is likely to use? > >> > >> One answer to that is that it isn't "emergency" that is=20 > reported as a=20 > >> capability, its "IMS-Vx.y-emergency", and there is an=20 > external spec=20 > >> somewhere that spells out in detail what behavior that implies. > >> > >> But that presents a very difficult model for interoperation. > >> > >>>> My example was pointing to a use-case that could be happen > >> within the > >>>> internet, when service provider will support emergency. > >> Und the user > >>>> will be informed that he is sure that the emergency call will be=20 > >>>> passed through with the first INVITE. And not waiting=20 > for certain=20 > >>>> responses if the call will not succeed. > >> > >> We have a solution for emergency calls - its the sos urn. And IIRC=20 > >> there has been some discussion of ways that a UAC could "test the=20 > >> path" to that URN when it connects to a network so it could inform=20 > >> the user if that will work or not. > >> > >> I'm pretty sure ecrit would have something to say about=20 > this example. > >> > >>>> My intension was to try to point to possible internet=20 > applications=20 > >>>> that could use Christers draft. > >> > >> Thank you for trying. So far what it has done is act as a counter=20 > >> example. > >> > >> Thanks, > >> Paul > >> > >>>> Best Regards > >>>> > >>>> Roland > >>>> > >>>>> -----Urspr=FCngliche Nachricht----- > >>>>> Von: sipcore-bounces@ietf.org > >>>>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > >>>>> Gesendet: Mittwoch, 26. Januar 2011 18:35 > >>>>> An: sipcore@ietf.org > >>>>> Betreff: Re: [sipcore] Draft new version: > >>>>> draft-holmberg-sipcore-proxy-feature > >>>>> > >>>>> inline > >>>>> > >>>>> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > >>>>>> Hi, > >>>>>> there is an scenario which I would see also within the > >>>>> Internet approach. Perhaps others too. > >>>>>> When you register it would be useful to know if the proper > >>>>> emergency service is served by the provider you are=20 > connected to. > >>>>>> Such an explicit indication would help. > >>>>>> > >>>>>> > >>>>>> Alice P1 > >>>>> REGISTRAR > >>>>>> | | | > >>>>>> |--- REGISTER-------------->| | > >>>>>> | | | > >>>>>> | |--- REGISTER-------------->| > >>>>>> | | Path: P1;emergency | > >>>>>> | | | > >>>>>> | | | > >>>>>> | |<-- 200 OK ----------------| > >>>>>> | | Path: P1;emergency | > >>>>>> | | Service-Route: REG | > >>>>>> |<-- 200 OK ----------------| | > >>>>>> | Path: P1;emergency | | > >>>>>> | Service-Route: REG | | > >>>>>> | | | > >>>>>> > >>>>>> So that Alice is now sure that an emergency call will get > >>>>> thought and the correct emergency centre will be reached. > >>>>> Which is not even guaranteed in an pure internet environment=20 > >>>>> depended which service provider is chosen. > >>>>> > >>>>> Why is presence of this parameter on *Path*=20 > appropriate? Path has=20 > >>>>> nothing to do with new calls originated by Alice. If > >> anything were > >>>>> relevant, it would be Service-Route, which Alice would=20 > include in=20 > >>>>> Route when making a new call. > >>>>> > >>>>> And, what does the "emergency" capability *mean*? Does it > >> mean that > >>>>> it can route requests with urn:sos as the R-URI? Or that it=20 > >>>>> recognizes URIs containing dial strings that contain emergency=20 > >>>>> numbers? Or what? (If the latter, emergency numbers for what=20 > >>>>> locale(s)?, and encoded in what manner?) > >>>>> > >>>>> But, why is this needed? Why not just send the request > >> and cope with > >>>>> failure to route if/when it happens? > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> 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 christer.holmberg@ericsson.com Thu Jan 27 09:37:20 2011 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 78CFF3A69A3 for ; Thu, 27 Jan 2011 09:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, 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 ZpAm+OQX7tDc for ; Thu, 27 Jan 2011 09:37: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 321813A699E for ; Thu, 27 Jan 2011 09:37:18 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-1f-4d41ae0694f5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 64.DA.23694.60EA14D4; Thu, 27 Jan 2011 18:40:22 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 27 Jan 2011 18:40:21 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 27 Jan 2011 18:40:13 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+Re8sOhpsjLXYRyi072cvMQog7wAAbSGg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1DC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> <4D41A848.1090304@cisco.com> In-Reply-To: <4D41A848.1090304@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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:37:20 -0000 Hi,=20 >>>Another hurdle you're going to face is harmonizing your=20 >>>proposal with RFC 5897. All three of your examples rely on doing, just a= bout as=20 >>>vigorously as possible, precisely what RFC 5897 says not to do. >> >>Feature tags indicate support of a capability. EVERY=20 >>feature tag does that - even if inserted in a Contact header=20 >>field by a UA - and the feature tag specification needs to=20 >>define the meaning of that capability. >> >>The important thing is that it cannot be assumed that other=20 >>entities understand the meaning of the feature tag in order=20 >>to progress a call (in such cases you will also need an=20 >>option-tag, inserted in a Require/Proxy-Require header field). >>=20 >>There was also an extended discussion (battle?), around the=20 >>time the callerprefs came out, about the validity of using=20 >>feature-tags (capabilities) to identify arbitrary *services* where the=20 >>service was to be defined in some external, potentially=20 >>restricted document. 3GPP specifications are as external as IETF RFCs. It is also important to remember that the proposed work is not about specif= ying specific feature tags, but a generic mechanism to carry proxy-inserted= feature tags.=20 I have no problem to include a statement saying that feature tags specifica= tions that use the mechanism MUST be publicly available. >The crux of the argument was whether capabilities were=20 >orthogonal to one another or not. The concern was (and=20 >remains) that interoperability is severely limited if there=20 >are potentially many ways of specifying the same capability,=20 >as part of this service or that service. Yes, but that relates to most things we do. >(IIRC, one of the examples used was video calling, where=20 >somebody might describe a capability "video-phone" that=20 >implies a particular combination of audio and video. Two UAs=20 >that supported this might work well together, but somebody=20 >with a UA that supports exactly the same media types and=20 >*could* interoperate if connected, might fail to interoperate=20 >for lack of specifying the proper feature-tag.) >=20 >We run a risk of going through the same thing here. That is=20 >what 5897 was about too. The procedures associated with the 3GPP feature tags are very well document= ed, rather than being something general as "audio" and "video". And, take sip.instance as an example. It is useless unless entities support= procedures associated with it. But, if UA_A inserts sip.instance, and UE_B= does not support it, they will still be able to communicate. But, if they = want to use features associated with the feature tag, they need to support = the procedures defined for that feature. There is nothing in the "SIP signa= lling" that tells the entities what to do, if the sip.instance e.g. is goin= g to be used outside the dialog (e.g in a REFER request). Regards, Christer >=20 > Thanks, > Paul > = From pkyzivat@cisco.com Thu Jan 27 09:54:30 2011 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 00A7F3A699E for ; Thu, 27 Jan 2011 09:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 A9KzM2oXa2ay for ; Thu, 27 Jan 2011 09:54:29 -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 17E413A69AB for ; Thu, 27 Jan 2011 09:54:29 -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: AvsEAH9AQU1AZnwM/2dsb2JhbACkfXOgY5tPhU8EhReHEINE Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 17:57:32 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RHvWuG020840; Thu, 27 Jan 2011 17:57:32 GMT Message-ID: <4D41B20C.5030506@cisco.com> Date: Thu, 27 Jan 2011 12:57:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41AA37.1060009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1D3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B1D3@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 17:54:30 -0000 On 1/27/2011 12:26 PM, Christer Holmberg wrote: > > Hi, > >> IMO the key differences are: >> >> - the definition must be publicly available >> - capabilities/feature-tags should be orthogonal >> >> (And of course it is impossible to verify orthogonality >> without the definitions being available.) > > As far as I know, all 3GPP specifications are publicly available. I wasn't trying to imply that they are not, just putting a stake in the ground generally. The orthogonality also ties into the quote Adam cited. I had forgotten exactly how that was stated. It goes further. Thanks, Paul From pkyzivat@cisco.com Thu Jan 27 10:12:47 2011 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 F261D28C151 for ; Thu, 27 Jan 2011 10:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YfghjqE+Kan1 for ; Thu, 27 Jan 2011 10:12:45 -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 9553E28C152 for ; Thu, 27 Jan 2011 10:12:45 -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: Au4EAC5FQU1AZnwM/2dsb2JhbACWIo5bc6Btm1GCeIJXBIUXhxCDRA Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 18:15:49 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0RIFmAr028153; Thu, 27 Jan 2011 18:15:48 GMT Message-ID: <4D41B654.2000201@cisco.com> Date: Thu, 27 Jan 2011 13:15:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Allen References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se><4D3EEC64.2080302@nostrum.com><7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se><4D3F2365.2070504@nostrum.com><7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D417C5C.9030501@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] Draft new version:draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 18:12:47 -0000 On 1/27/2011 10:35 AM, Andrew Allen wrote: > Paul, > > I expressed already that I think that solving this problem is also > useful for non IMS environments such as IP PBXs in enterprises. More > generally it could be useful in an internet environment whenever a SIP > proxy wishes to advertise its support for some feature or capability. I still think there *might* be something of general interest and value here. When I look at it as an abstraction, it seems like a plausible one, and I like going for general capabilities rather than very specialized ones. BUT, we have often gotten ourselves caught up in problems from over-generality. It is really good to have some important use cases. And having ones that many people can relate to is especially helpful. I have a suspicion that there are use cases that much of the community can understand and relate to. They just haven't been discovered yet. > I also would like to point out that some of the features developed in > SIP over the past decade that were initially seen as IMS only or IMS > requirements initiated features have later been seen to be useful to the > wider community and included as part of the solutions for other later > SIP work and made it into the Hitchikers guide. Some examples include: > > P-Asserted-Identity header field, > UPDATE method, > Path header field, > Registration Events Package I'm not sure that UPDATE is really form IMS. (It was called something else before UPDATE, but that is *way* back.) And IIRC the registration event package had broader support than IMS right from the beginning. But I take your point. > I also would like to indicate that I am willing to contribute and review > this work if it is adopted. Thanks for that. Thanks, Paul > Andrew > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, January 27, 2011 8:08 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Draft new > version:draft-holmberg-sipcore-proxy-feature > > Christer, > > The reason for including something for non-IMS usage is to motivate > those not involved in IMS to be interested in the work. I guess that a > sufficient mass of IMS participants would work, but its harder to get > consensus without some of the others. > > Thanks, > Paul > > On 1/27/2011 8:55 AM, Christer Holmberg wrote: >> >> Hi, >> >> Eventhough I would be happy to see usage outside of IMS for the > mechanism, I don't see why 3GPP people should have to try to invent such > use-cases "by force". >> >> I think there could be usages for SIP-PBXs, but I don't have any > specific requirement/use-case to put on the table. >> >> Regarding the WG and IESG, we have specified mechanisms for 3GPP > before, e.g based on RFC 4083, and my understanding is that there is > some kind of agreement between 3GPP and IETF. I do realize that we are > not talking about a P- header in this case, but that should not change > the fundamental agreement. >> >> But, if you now are saying that, unless there is a non-IMS use-case, > IETF (or, at least SIPCORE) is no more going to accept doing any work > for 3GPP, I really think 3GPP should be informed about that. >> >> BTW, there is an *I* in IMS also :) >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: 25. tammikuuta 2011 21:24 >>> To: Christer Holmberg >>> Cc: Paul Kyzivat; sipcore@ietf.org >>> Subject: Re: [sipcore] Draft new version: >>> draft-holmberg-sipcore-proxy-feature >>> >>> [as individual] >>> >>> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote: >>>> I'll try to put something together. >>>> But, just for my understanding: what happens if there are >>> no non-IMS use cases? >>> >>> Then we need to try to figure out whether the inapplicability >>> of the problem is due to the fact that it is being stated in >>> overly-narrow terms (i.e., is there a more general problem >>> here that does have applicability to the Internet?), or >>> whether it is due to the fact that it only arises because of >>> a specific architecture. >>> >>> If it's the first case, we'll probably need to generalize the >>> problem to include the Internet (you know, the "I" in >>> "IETF"). Then, you'll have a much easier time getting the WG >>> to adopt it and the IESG to approve it. >>> >>> If the problem only exists because of certain walled-garden >>> architectures, then things get trickier -- both in the WG and >>> in the IESG. >>> >>> /a >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > From christer.holmberg@ericsson.com Thu Jan 27 10:24:49 2011 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 4EDF13A67BD for ; Thu, 27 Jan 2011 10:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXA+SA8SkinC for ; Thu, 27 Jan 2011 10:24:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 491DB28C155 for ; Thu, 27 Jan 2011 10:24:44 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-0d-4d41b9233c91 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.79.13987.329B14D4; Thu, 27 Jan 2011 19:27:47 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 27 Jan 2011 19:27:47 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 27 Jan 2011 19:27:46 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+S6z+7IT2P/hITp6kkGSzkC1krwAAqXeI Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194414F720@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se> <4D41AA37.1060009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1D3@ESESSCMS0356.eemea.ericsson.se>, <4D41B20C.5030506@cisco.com> In-Reply-To: <4D41B20C.5030506@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" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 18:24:49 -0000 Hi, In my opinion the big difference (a little simplified) from when we had the= service-id discussion is the following: - The service-id is used by the sender to REQUEST the receiver to do someth= ing. If the receiver doesn't do it (e.g. because it doesn't understand the = service-id) the sender might not get the assumed result in the particular d= ialog. - The feature tag is used by the sender to INFORM the receiver about a feat= ure that it supports. It's up to the receiver to determine whether it wants= to use that information for anything. And, if it doesn't (or, it doesn't e= ven understand the meaning of the feature tag), nothing will go wrong in th= e particular dialog, because the sender didn't assume the receiver to do an= ything. sip.instance is a very good example of informing. The sender doesn't really= expect the receiver to do anything with the information (unless there is a= n associated option-tag), but the receiver MAY use it e.g. to later do a ca= ll transfer. =20 So, in my opinion, THAT is the separation we need to do, rather than arguin= g about terminology.=20 (We know that people have changed "service" to "feature" in their drafts si= mply because of "political reasons", so I think it's really worthless tryin= g to categorize) Regards, Christer ________________________________________ From: Paul Kyzivat [pkyzivat@cisco.com] Sent: Thursday, January 27, 2011 7:57 PM To: Christer Holmberg Cc: Adam Roach; sipcore@ietf.org; R.Jesske@telekom.de Subject: Re: [sipcore] Draft new version: draft-holmberg-sipc= ore-proxy-feature On 1/27/2011 12:26 PM, Christer Holmberg wrote: > > Hi, > >> IMO the key differences are: >> >> - the definition must be publicly available >> - capabilities/feature-tags should be orthogonal >> >> (And of course it is impossible to verify orthogonality >> without the definitions being available.) > > As far as I know, all 3GPP specifications are publicly available. I wasn't trying to imply that they are not, just putting a stake in the ground generally. The orthogonality also ties into the quote Adam cited. I had forgotten exactly how that was stated. It goes further. Thanks, Paul= From pkyzivat@cisco.com Thu Jan 27 10:48:19 2011 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 6AF6E3A69D1 for ; Thu, 27 Jan 2011 10:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8, 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 e3pCUmziuUW3 for ; Thu, 27 Jan 2011 10:48: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 078863A67F7 for ; Thu, 27 Jan 2011 10:48:17 -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: AvsEAGNNQU1AZnwN/2dsb2JhbACkfXOgbJtUgneCWASFF4cQg0Q Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2011 18:51:21 +0000 Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0RIpK6K018714; Thu, 27 Jan 2011 18:51:21 GMT Message-ID: <4D41BEA8.1000303@cisco.com> Date: Thu, 27 Jan 2011 13:51:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> <4D41A848.1090304@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1DC@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B1DC@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 18:48:19 -0000 On 1/27/2011 12:40 PM, Christer Holmberg wrote: > > Hi, > >>>> Another hurdle you're going to face is harmonizing your >>>> proposal with RFC 5897. All three of your examples rely on doing, just about as >>>> vigorously as possible, precisely what RFC 5897 says not to do. >>> >>> Feature tags indicate support of a capability. EVERY >>> feature tag does that - even if inserted in a Contact header >>> field by a UA - and the feature tag specification needs to >>> define the meaning of that capability. >>> >>> The important thing is that it cannot be assumed that other >>> entities understand the meaning of the feature tag in order >>> to progress a call (in such cases you will also need an >>> option-tag, inserted in a Require/Proxy-Require header field). >>> >>> There was also an extended discussion (battle?), around the >>> time the callerprefs came out, about the validity of using >>> feature-tags (capabilities) to identify arbitrary *services* where the >>> service was to be defined in some external, potentially >>> restricted document. > > 3GPP specifications are as external as IETF RFCs. > > It is also important to remember that the proposed work is not about specifying specific feature tags, but a generic mechanism to carry proxy-inserted feature tags. What I'm still missing is a generic definition of what it means for an intermediary in sip signaling (especially a proxy) to have capabilities. With 3840/3841 I have a general understanding that: - I can use callerprefs to suggest policies for getting my request to a UAS that has the stated capabilities - that I can use fairly obvious sip signaling to make use of the capabilities. (E.g. if the video feature tag is present then I can expect that video lines in my offers will at least be understood.) I'm not getting that level of understanding with this proposal yet. What I understand is that a server wanting to announce a capability is expected to put the feature tag on its record-route entry. I don't know if that is intended to convey information to the UAC or the UAS, or to other intermediaries on one side or the other (or both) in the transaction? And are these intended to apply for the dialog being established, or more broadly? (R-R only applies to the dialog.) Nor do I understand *how* such features would be invoked? Again, is this *within* the dialog? Or is this through a new dialog or a transaction outside a dialog? For instance, I suppose that if the feature were attached to an entry in a Service-Route header, then it would be copied into a Route header for requests outside an existing dialog, and them *maybe* the UAC could infer that something specific might happen to those requests. But that is strange to me - I expect that Route headers are used to steer a request through a sequence of proxies before getting to a particular destination. But I don't expect those proxies to do anything except ensure that the request actually reaches the R-URI and then works in accord with the request I sent for the UAS. If the feature was attached to an entry in a Path header, then the same considerations might apply but from the perspective of the "proxy" associated with the registrar. These would become Route headers on requests outbound from it. While there are certainly feature-specific things to be said, the general model of what is going on is still not clear to me. > I have no problem to include a statement saying that feature tags specifications that use the mechanism MUST be publicly available. > >> The crux of the argument was whether capabilities were >> orthogonal to one another or not. The concern was (and >> remains) that interoperability is severely limited if there >> are potentially many ways of specifying the same capability, >> as part of this service or that service. > > Yes, but that relates to most things we do. And its something we must constantly be mindful of. >> (IIRC, one of the examples used was video calling, where >> somebody might describe a capability "video-phone" that >> implies a particular combination of audio and video. Two UAs >> that supported this might work well together, but somebody >> with a UA that supports exactly the same media types and >> *could* interoperate if connected, might fail to interoperate >> for lack of specifying the proper feature-tag.) >> >> We run a risk of going through the same thing here. That is >> what 5897 was about too. > > The procedures associated with the 3GPP feature tags are very well documented, rather than being something general as "audio" and "video". > > And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able to communicate. But, if they want to use features associated with the feature tag, they need to support the procedures defined for that feature. There is nothing in the "SIP signalling" that tells the entities what to do, if the sip.instance e.g. is going to be used outside the dialog (e.g in a REFER request). sip.instance may have been a mistake. It makes sense as a Contact header parameter, but whether it is truly a capability/feature is a bit shaky. Even so, its not an "outbound" feature, and its inclusion does not mean that you want outbound functionality. It merely says "this is who I am" and thus can be used for many things. Thanks, Paul From adam@nostrum.com Thu Jan 27 12:43:25 2011 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 4E2BD3A6A51 for ; Thu, 27 Jan 2011 12:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, SPF_PASS=-0.001, 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 BXuQN3CXh+jY for ; Thu, 27 Jan 2011 12:43:24 -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 B0F3D3A6916 for ; Thu, 27 Jan 2011 12:43:23 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RKkQPi064209 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 14:46:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D41D9A2.9070303@nostrum.com> Date: Thu, 27 Jan 2011 14:46:26 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Ad-hoc call notes 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, 27 Jan 2011 20:43:25 -0000 [as an individual] I took some (occasionally interrupted) notes on the location conveyance call today. /a Location Conveyance Ad-Hoc Phone Call January 12, 2011 ======================================================= Participants: Adam Roach Jon Peterson Hannes Tschofenig James Polk John Elwell Martin Thomson Paul Kyzivat Robert Sparks First Issue: Use of IANA-registered option tags Proposal is to use "geolocation-sip" and "geolocation-http" Martin Thomson beleives this is sufficient for HELD, and that "geolocation-held" would be too specific General agreement from various that this approach seems sound. Second Issue: Is standards action the right level? Jon thinks we won't need many, so setting the bar high is good. Paul K agrees that the more we have, the less interoperability is fostered, so a high bar helps overall. Third Issue: Removal of 200-class geoloc errors Jon thinks there might be some cruft left behind from this change. The assertion is that these can be communicated using normal SIP error codes, and that we don't want to re-state a bunch of normative behavior from 3261. James and Paul expressed concerns about not noting the use of specific error codes. James notes that one of the motivations for 200 codes was to be able to communicate to the client "your location is stale, update it and try again." Jon points out that he's trying to get rid of as many error codes as possible. James says he's find with that, but that we should tell implementors to use a 503 with a "Retry-After" for the conditions previously covered by 200. Martin Thomson indicates that 503 isn't really the right semantic, because it isn't an overload condition. Stale location isn't a server error. Robert: 503 isn't really "I'm overloaded." It's "Stop talking to me." The assertion seems to be that we can collapse everything into 100. Martin is okay with that, but that we might want to put additional text in the 100 description to include problems ("can't find it, can't parse, not good enough"). Proposal is to make existing 300s into new 200s, and so on. (Bascially, I don't have permission to get to your location). 100: get me different or better location 2xx (formerly 3xx): fix your permissions 3xx (formerly 4xx): get me a URI that works (or a location-by-value) James talks about a use case where he sends a "geolocation-sip" message, but can't subscribe to the SIP resource (because, e.g., of firewalls). Adam points out that you end up with some really bad protocol timer interactions if you wait for the NOTIFY to show up, and that the only way to really make sure that the server has received the information would be to set up a subscription to that state. Martin points out that there's no way to signal "I can't dereference, just send me a location by value." Jon thinks we don't need that. The reason people don't use LbyV is by necessity, and this isn't something the client will likely be able to solve. LbyR is mostly for use cases where the network won't provide data to the endpoint, and so LbyR is the only option. Martin proposes that's a good reason for omitting specific text on the issue. James asks whether we need to solve this problem? And do we need to fix it for both INVITE and non-INVITE? Jon asserts that the "200 OK" should simply indicate that the message has been received, not that the location has been successfully retrieved. Some dicussion follows, the upshot of which is (1) Non-INVITE transactions can't pend for long enough to dereference [will add text], and (2) The call flows are examples, not normative. Other data flows are possible. From jmpolk@cisco.com Thu Jan 27 13:26:33 2011 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 74FD328C195 for ; Thu, 27 Jan 2011 13:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 y8vBExvfB4lY for ; Thu, 27 Jan 2011 13:26:32 -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 D8A5328C192 for ; Thu, 27 Jan 2011 13:26:31 -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: AvsEAKZyQU2rRN+K/2dsb2JhbACkfXOgWJtAhU8EhRc Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2011 21:29:36 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0RLTZB5025892; Thu, 27 Jan 2011 21:29:35 GMT Message-Id: <201101272129.p0RLTZB5025892@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Jan 2011 15:29:31 -0600 To: Adam Roach , "SIPCORE (Session Initiation Protocol Core) WG" From: "James M. Polk" In-Reply-To: <4D41D9A2.9070303@nostrum.com> References: <4D41D9A2.9070303@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Ad-hoc call notes 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, 27 Jan 2011 21:26:33 -0000 At 02:46 PM 1/27/2011, Adam Roach wrote: >[as an individual] comments and clarifications in-line below >I took some (occasionally interrupted) notes on the location >conveyance call today. > >/a > >Location Conveyance Ad-Hoc Phone Call January 12, 2011 >======================================================= > >Participants: > Adam Roach > Jon Peterson > Hannes Tschofenig > James Polk > John Elwell > Martin Thomson > Paul Kyzivat > Robert Sparks > >First Issue: Use of IANA-registered option tags > > Proposal is to use "geolocation-sip" and "geolocation-http" > > Martin Thomson beleives this is sufficient for HELD, and that > "geolocation-held" would be too specific > > General agreement from various that this approach seems sound. everyone on the call seemed to believe this was a really good way forward. >Second Issue: Is standards action the right level? > > Jon thinks we won't need many, so setting the bar high is good. > > Paul K agrees that the more we have, the less interoperability > is fostered, so a high bar helps overall. > >Third Issue: Removal of 200-class geoloc errors > > Jon thinks there might be some cruft left behind from this change. > The assertion is that these can be communicated using normal SIP > error codes, and that we don't want to re-state a bunch of normative > behavior from 3261. > > James and Paul expressed concerns about not noting the use of > specific error codes. > > James notes that one of the motivations for 200 codes was to > be able to communicate to the client "your location is stale, > update it and try again." > > Jon points out that he's trying to get rid of as many error codes > as possible. > > James says he's find with that, but that we should tell implementors > to use a 503 with a "Retry-After" for the conditions previously > covered by 200. > > Martin Thomson indicates that 503 isn't really the right semantic, > because it isn't an overload condition. Stale location isn't > a server error. > > Robert: 503 isn't really "I'm overloaded." It's "Stop talking to me." > > > The assertion seems to be that we can collapse everything into 100. correction: not "everything" into one error code, but all the - bad location - can't parse location - don't understand what (location) you sent me - you left (a) key part(s) of your location out - etc all these types of errors above are to be collapsed into the 100 geoloc error code > Martin is okay with that, but that we might want to put additional > text in the 100 description to include problems ("can't find it, > can't parse, not good enough"). > > Proposal is to make existing 300s into new 200s, and so on. (Bascially, > I don't have permission to get to your location). > > 100: get me different or better location > 2xx (formerly 3xx): fix your permissions > 3xx (formerly 4xx): get me a URI that works (or a location-by-value) this 3xx isn't solved yet, as "get me a URI that works (or a location-by-value)" is solved with Jon's new option-tags. This last error category was to indicate there was a problem during Dereferencing (i.e., "Dereference Failure") which was to be included in the SIP response back to the UAC to inform them whether or not the location that the UAC included reached it's destination (or, conversely to the intermediary server that inserted location). It appears that we can keep this for the INVITE request, but that for ther other request types this plays badly with session timers (as Adam chronicles below), so we'll modify the text accordingly. > James talks about a use case where he sends a "geolocation-sip" > message, but can't subscribe to the SIP resource (because, e.g., > of firewalls). > > Adam points out that you end up with some really bad protocol timer > interactions if you wait for the NOTIFY to show up, and that the > only way to really make sure that the server has received the > information would be to set up a subscription to that state. > > Martin points out that there's no way to signal "I can't dereference, > just send me a location by value." > > Jon thinks we don't need that. The reason people don't use LbyV is > by necessity, and this isn't something the client will likely > be able to solve. LbyR is mostly for use cases where the network > won't provide data to the endpoint, and so LbyR is the only option. > > Martin proposes that's a good reason for omitting specific text on the > issue. > > James asks whether we need to solve this problem? And do we need to > fix it for both INVITE and non-INVITE? > > Jon asserts that the "200 OK" should simply indicate that the message > has been received, not that the location has been successfully > retrieved. Jon said this, but I don't believe others on the call agreed to this by the time the call ended. For example, I think we need a verification that location sent was received, and not treat that by basically ignoring if location was in the message at all. This goes towards treating location reception explicitly vs. implicitly. > Some dicussion follows, the upshot of which is (1) Non-INVITE transactions > can't pend for long enough to dereference [will add text], and > (2) The call flows are examples, not normative. Other data flows > are possible. this was agreeable on the call and Adam (perhaps via Robert) to offer as text for inclusion. (btw - I have now seen the text, and it looks good) James >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Thu Jan 27 13:43:21 2011 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 999283A69D4 for ; Thu, 27 Jan 2011 13:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 p80t2ydGJpzN for ; Thu, 27 Jan 2011 13:43:20 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7DAEE3A69D7 for ; Thu, 27 Jan 2011 13:43:20 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:41672 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S42041670Ab1A0VqY (ORCPT ); Thu, 27 Jan 2011 15:46:24 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 27 Jan 2011 15:46:24 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 28 Jan 2011 05:46:21 +0800 From: "Thomson, Martin" To: "James M. Polk" , Adam Roach , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 28 Jan 2011 05:46:18 +0800 Thread-Topic: [sipcore] Ad-hoc call notes Thread-Index: Acu+aVDQlUXZCbmUQvSo+1+9YRA8lgAACLtA Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA14D72@SISPE7MB1.commscope.com> References: <4D41D9A2.9070303@nostrum.com> <201101272129.p0RLTZB5025892@sj-core-4.cisco.com> In-Reply-To: <201101272129.p0RLTZB5025892@sj-core-4.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Ad-hoc call notes 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, 27 Jan 2011 21:43:21 -0000 QWdyZWUgd2l0aCBKYW1lcywgb25lIG1pbm9yIHRoaW5nIHRvIGFkZCBiZWxvdy4uLg0KDQpPbiAy MDExLTAxLTI4IGF0IDA4OjI5OjMxLCBKYW1lcyBNLiBQb2xrIHdyb3RlOg0KPiA+ICAgUHJvcG9z YWwgaXMgdG8gbWFrZSBleGlzdGluZyAzMDBzIGludG8gbmV3IDIwMHMsIGFuZCBzbyBvbi4NCj4g KEJhc2NpYWxseSwNCj4gPiAgICAgSSBkb24ndCBoYXZlIHBlcm1pc3Npb24gdG8gZ2V0IHRvIHlv dXIgbG9jYXRpb24pLg0KPiA+DQo+ID4gICAgICAgMTAwOiBnZXQgbWUgZGlmZmVyZW50IG9yIGJl dHRlciBsb2NhdGlvbg0KPiA+ICAgICAgIDJ4eCAoZm9ybWVybHkgM3h4KTogZml4IHlvdXIgcGVy bWlzc2lvbnMNCj4gPiAgICAgICAzeHggKGZvcm1lcmx5IDR4eCk6IGdldCBtZSBhIFVSSSB0aGF0 IHdvcmtzIChvciBhIGxvY2F0aW9uLWJ5LQ0KPiB2YWx1ZSkNCj4gDQo+IHRoaXMgM3h4IGlzbid0 IHNvbHZlZCB5ZXQsIGFzICJnZXQgbWUgYSBVUkkgdGhhdCB3b3JrcyAob3IgYQ0KPiBsb2NhdGlv bi1ieS12YWx1ZSkiIGlzIHNvbHZlZCB3aXRoIEpvbidzIG5ldyBvcHRpb24tdGFncy4gVGhpcyBs YXN0DQo+IGVycm9yIGNhdGVnb3J5IHdhcyB0byBpbmRpY2F0ZSB0aGVyZSB3YXMgYSBwcm9ibGVt IGR1cmluZw0KPiBEZXJlZmVyZW5jaW5nIChpLmUuLCAiRGVyZWZlcmVuY2UgRmFpbHVyZSIpIHdo aWNoIHdhcyB0byBiZSBpbmNsdWRlZA0KPiBpbiB0aGUgU0lQIHJlc3BvbnNlIGJhY2sgdG8gdGhl IFVBQyB0byBpbmZvcm0gdGhlbSB3aGV0aGVyIG9yIG5vdCB0aGUNCj4gbG9jYXRpb24gdGhhdCB0 aGUgVUFDIGluY2x1ZGVkIHJlYWNoZWQgaXQncyBkZXN0aW5hdGlvbiAob3IsDQo+IGNvbnZlcnNl bHkgdG8gdGhlIGludGVybWVkaWFyeSBzZXJ2ZXIgdGhhdCBpbnNlcnRlZCBsb2NhdGlvbikuICBJ dA0KPiBhcHBlYXJzIHRoYXQgd2UgY2FuIGtlZXAgdGhpcyBmb3IgdGhlIElOVklURSByZXF1ZXN0 LCBidXQgdGhhdCBmb3INCj4gdGhlciBvdGhlciByZXF1ZXN0IHR5cGVzIHRoaXMgcGxheXMgYmFk bHkgd2l0aCBzZXNzaW9uIHRpbWVycyAoYXMNCj4gQWRhbSBjaHJvbmljbGVzIGJlbG93KSwgc28g d2UnbGwgbW9kaWZ5IHRoZSB0ZXh0IGFjY29yZGluZ2x5Lg0KIA0KTXkgc3VnZ2VzdGlvbnMgbWF5 IGhhdmUgYmVlbiBtaXNpbnRlcnByZXRlZC4gIEkgd2FzIG9ubHkgc3VnZ2VzdGluZyB0aGF0IHRo ZXJlIGFyZSBhIHNwZWNpZmljIGFjdGlvbnMgdGhhdCBtaWdodCBiZSB1c2VmdWwgaW4gcmVzcG9u c2UgdG8gZWFjaCBvZiB0aGUgY2xhc3NlcyBvZiBnZW9sb2NhdGlvbi1lcnJvciAoMXh4LCAyeHgg YW5kIDN4eCkuICBUaGF0J3MgbXkgdGVzdCBmb3Igd2hldGhlciB0aGUgZGlzdGluY3Rpb24gYmV0 d2VlbiBlYWNoIGNsYXNzIGlzIGdvb2QuICBUaGF0J3MgdGhlIHRoZW9yZXRpY2FsIHRlc3QgSSB1 c2UuDQoNClRoZXJlIGFyZSBteXJpYWQgcmVhc29ucyB0aGF0ICh0aGUgbmV3KSAzeHggbWlnaHQg YXJpc2UgaW4gcHJhY3RpY2UuICBVbnN1cHBvcnRlZCBwcm90b2NvbHMgd2UndmUgYWRkcmVzc2Vk IHdpdGggdGhlIG9wdGlvbiB0YWdzLiAgRm9yIHRoZSByZXN0LCBmaXJld2FsbHMsIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb2JsZW1zIGFyZSBhbGwgcG9zc2libGUgYW5kIGFy ZSBhbGwgcG90ZW50aWFsbHkgdW5yZXBhaXJhYmxlLiAgV2hlbiB0aGF0IGhhcHBlbnMsIHRoYXQn cyByZWdyZXR0YWJsZTsgYnV0IGluIHByYWN0aWNlLCB0aGluZ3MgZmFpbCBhbGwgdGhlIHRpbWUg YW5kIHRoYXQncyBiZXlvbmQgdGhlIHBvd2VyIG9mIHRoZSBwcm90b2NvbCBkZXNpZ24gdG8gZml4 Lg0KDQpXaGF0IGlzIHRoZXJlIHNlZW1zIGFkZXF1YXRlIHRvIGFkZHJlc3MgdGhlIHByb2JsZW1z IHdlIGtub3cgYW5kIGNhcmUgYWJvdXQuDQoNCj4gPiAgIEphbWVzIGFza3Mgd2hldGhlciB3ZSBu ZWVkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbT8gQW5kIGRvIHdlIG5lZWQgdG8NCj4gPiAgICAgZml4 IGl0IGZvciBib3RoIElOVklURSBhbmQgbm9uLUlOVklURT8NCj4gPg0KPiA+ICAgSm9uIGFzc2Vy dHMgdGhhdCB0aGUgIjIwMCBPSyIgc2hvdWxkIHNpbXBseSBpbmRpY2F0ZSB0aGF0IHRoZQ0KPiBt ZXNzYWdlDQo+ID4gICAgIGhhcyBiZWVuIHJlY2VpdmVkLCBub3QgdGhhdCB0aGUgbG9jYXRpb24g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5DQo+ID4gICAgIHJldHJpZXZlZC4NCj4gDQo+IEpvbiBzYWlk IHRoaXMsIGJ1dCBJIGRvbid0IGJlbGlldmUgb3RoZXJzIG9uIHRoZSBjYWxsIGFncmVlZCB0byB0 aGlzDQo+IGJ5IHRoZSB0aW1lIHRoZSBjYWxsIGVuZGVkLiBGb3IgZXhhbXBsZSwgSSB0aGluayB3 ZSBuZWVkIGENCj4gdmVyaWZpY2F0aW9uIHRoYXQgbG9jYXRpb24gc2VudCB3YXMgcmVjZWl2ZWQs IGFuZCBub3QgdHJlYXQgdGhhdCBieQ0KPiBiYXNpY2FsbHkgaWdub3JpbmcgaWYgbG9jYXRpb24g d2FzIGluIHRoZSBtZXNzYWdlIGF0IGFsbC4gVGhpcyBnb2VzDQo+IHRvd2FyZHMgdHJlYXRpbmcg bG9jYXRpb24gcmVjZXB0aW9uIGV4cGxpY2l0bHkgdnMuIGltcGxpY2l0bHkuDQoNCkpvbiB3YWxr IHRhbGtpbmcgYWJvdXQgTUVTU0FHRSBzcGVjaWZpY2FsbHkuICBJdCBzZWVtZWQgdGhhdCB0aGVy ZSB3b3VsZCBiZSBsaXR0bGUgcmVhc29uIHRvIHdpdGhob2xkIGEgMjAwIGJhc2VkIG9uIHdoZXRo ZXIgb3Igbm90IHRoZSBVUkkgaGFkIGJlZW4gc3VjY2Vzc2Z1bGx5IGZvbGxvd2VkIG9yIG5vdC4g IFRoYXQgd2FzIGluIHJlYnV0dGFsIHRvIGEgc3BlY2lmaWMgcXVlc3Rpb24gYWJvdXQgTUVTU0FH RSAtIEknbSBub3Qgc3VyZSBpZiB0aGlzIHdhcyBpbnRlbmRlZCB0byBjb3ZlciBhbGwgY2FzZXMu DQoNCkluIGFueSBjYXNlLCBJIHRoaW5rIHRoYXQgdGhlIGdlbmVyYWwgaWRlYSBvZiB0aGUgdGV4 dCAoYXMgcHJvbWlzZWQpIHRoYXQgc2F5czogSWYgeW91IGRvbid0IGRlcmVmZXJlbmNlIGFuZCBz ZW5kIDIwMCBhbnl3YXksIG1ha2Ugc3VyZSB5b3UgaGF2ZSBhbm90aGVyIGNoYW5uZWwgdG8gdXNl IGlmIHByb2JsZW1zIGFyaXNlLg0KDQo+ID4gICBTb21lIGRpY3Vzc2lvbiBmb2xsb3dzLCB0aGUg dXBzaG90IG9mIHdoaWNoIGlzICgxKSBOb24tSU5WSVRFDQo+IHRyYW5zYWN0aW9ucw0KPiA+ICAg ICBjYW4ndCBwZW5kIGZvciBsb25nIGVub3VnaCB0byBkZXJlZmVyZW5jZSBbd2lsbCBhZGQgdGV4 dF0sIGFuZA0KPiA+ICAgICAoMikgVGhlIGNhbGwgZmxvd3MgYXJlIGV4YW1wbGVzLCBub3Qgbm9y bWF0aXZlLiBPdGhlciBkYXRhIGZsb3dzDQo+ID4gICAgIGFyZSBwb3NzaWJsZS4NCj4gDQo+IHRo aXMgd2FzIGFncmVlYWJsZSBvbiB0aGUgY2FsbCBhbmQgQWRhbSAocGVyaGFwcyB2aWEgUm9iZXJ0 KSB0byBvZmZlcg0KPiBhcyB0ZXh0IGZvciBpbmNsdXNpb24uDQo+IA0KPiAoYnR3IC0gSSBoYXZl IG5vdyBzZWVuIHRoZSB0ZXh0LCBhbmQgaXQgbG9va3MgZ29vZCkNCg0KR29vZC4gIEkgdG9vIHdv dWxkIGxpa2UgdG8gc2VlIHRoZSB0ZXh0LiAgKEFuIHVwZGF0ZWQgZHJhZnQgd2lsbCBzdWZmaWNl IDopDQoNCi0tTWFydGluDQoNCg== From christer.holmberg@ericsson.com Thu Jan 27 14:19:46 2011 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 E38883A6A60 for ; Thu, 27 Jan 2011 14:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, 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 qFmn3+RB6doT for ; Thu, 27 Jan 2011 14:19:45 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 13C453A69E7 for ; Thu, 27 Jan 2011 14:19:44 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-7d-4d41f0385699 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 84.17.23694.830F14D4; Thu, 27 Jan 2011 23:22:48 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 27 Jan 2011 23:22:47 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 27 Jan 2011 23:22:46 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu+UzIOjKczWJEOQDWU68huZfZCpwAGbcDR Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194414F723@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se> <4D41A848.1090304@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B1DC@ESESSCMS0356.eemea.ericsson.se>, <4D41BEA8.1000303@cisco.com> In-Reply-To: <4D41BEA8.1000303@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] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 27 Jan 2011 22:19:47 -0000 Hi, >>>>> Another hurdle you're going to face is harmonizing your >>>>> proposal with RFC 5897. All three of your examples rely on doing, jus= t about as >>>>> vigorously as possible, precisely what RFC 5897 says not to do. >>>> >>>> Feature tags indicate support of a capability. EVERY >>>> feature tag does that - even if inserted in a Contact header >>>> field by a UA - and the feature tag specification needs to >>>> define the meaning of that capability. >>>> >>>> The important thing is that it cannot be assumed that other >>>> entities understand the meaning of the feature tag in order >>>> to progress a call (in such cases you will also need an >>>> option-tag, inserted in a Require/Proxy-Require header field). >>>> >>>> There was also an extended discussion (battle?), around the >>>> time the callerprefs came out, about the validity of using >>>> feature-tags (capabilities) to identify arbitrary *services* where the >>>> service was to be defined in some external, potentially >>>> restricted document. >> >>3GPP specifications are as external as IETF RFCs. >> >>It is also important to remember that the proposed work is not about spec= ifying specific feature tags, but a generic mechanism to carry proxy-insert= ed feature tags. > >What I'm still missing is a generic definition of what it means for an >intermediary in sip signaling (especially a proxy) to have capabilities. > >With 3840/3841 I have a general understanding that: >- I can use callerprefs to suggest policies for getting my request > to a UAS that has the stated capabilities >- that I can use fairly obvious sip signaling to make use of the > capabilities. (E.g. if the video feature tag is present then I can > expect that video lines in my offers will at least be understood.) That might have been the use-cases we were aware of when writing 3840/3841,= but there is nothing in the general feature tag defintion that makes that = limitation. >I'm not getting that level of understanding with this proposal yet. What >I understand is that a server wanting to announce a capability is >expected to put the feature tag on its record-route entry. I don't know >if that is intended to convey information to the UAC or the UAS, or to >other intermediaries on one side or the other (or both) in the >transaction? And are these intended to apply for the dialog being >established, or more broadly? (R-R only applies to the dialog.) On a high level, it's about indicating support of a capability to other ent= ities. But, as the draft also says, each feature specification has to define the u= sage of the feature tag, and what indicating support of the capability real= ly means - in the same way when a UA indicates support of a capability (exc= ept for the purpose of making forking decissions, when nobody really needs = to know the semantics of the feature tag). It is also true that R-R only applies to the dialog, but I don't think it's= explicitly forbidden to use information received from a dialog in other di= alogs.=20 But, the scope of a feature tag needs to be described in the feature tag de= finition. >Nor do I understand *how* such features would be invoked? Again, is this >*within* the dialog? Or is this through a new dialog or a transaction >outside a dialog? Again, that needs to be described in the feature tag definition. >For instance, I suppose that if the feature were attached to an entry in >a Service-Route header, then it would be copied into a Route header for >requests outside an existing dialog, and them *maybe* the UAC could >infer that something specific might happen to those requests. But that >is strange to me - I expect that Route headers are used to steer a >request through a sequence of proxies before getting to a particular >destination. But I don't expect those proxies to do anything except >ensure that the request actually reaches the R-URI and then works in >accord with the request I sent for the UAS. You need to define in which header fields the feature tag has a meaning, an= d what that meaning is. >If the feature was attached to an entry in a Path header, then the same >considerations might apply but from the perspective of the "proxy" >associated with the registrar. These would become Route headers on >requests outbound from it. Yes, and you would need to define that the feature tag only has meaning whe= n present in a Path header field. Take the "ob" parameter as an example. It's inserted in the Path header fie= ld. It may therefore be copied into the Route header fields, but it doesn't= (AFAIR) really have any meaning there. Take the Contact header field as an example. When you register the UA with = the registrar, you may include features tags indicating capabilities that y= our support. The registrar will them insert them into the R-URI of an incom= ing INVITE, but they don't really have any meaning there. There are only th= ere because the registrar copies the Contact into the R-URI. And, they are = going to be there during the whole dialog, eventhough they won't be used fo= r anything. It's part of the SIP design that sometimes we copy paste things from one he= ader field to another, eventhough all information as such might not be need= ed. We need to define what meaning, if any, the information has in specific= header fields and situations. >While there are certainly feature-specific things to be said, the general = model of what is going on is still not clear to me. The general model is pretty much the same as for UAs - indicating support o= f a capability - eventhough I agree that you need to consider more things (= e.g. the meaning in different header fields) when defining the usage by a p= roxy. I try to explain that in the draft. >> I have no problem to include a statement saying that feature tags specif= ications that use the mechanism MUST be publicly available. >> >>> The crux of the argument was whether capabilities were >>> orthogonal to one another or not. The concern was (and >>> remains) that interoperability is severely limited if there >>> are potentially many ways of specifying the same capability, >>> as part of this service or that service. >> >> Yes, but that relates to most things we do. > >And its something we must constantly be mindful of. And that's why we have different review procedures etc to handle that. 3GPP= is also looking for existing mechanisms first. >>> (IIRC, one of the examples used was video calling, where >>> somebody might describe a capability "video-phone" that >>> implies a particular combination of audio and video. Two UAs >>> that supported this might work well together, but somebody >>> with a UA that supports exactly the same media types and >>> *could* interoperate if connected, might fail to interoperate >>> for lack of specifying the proper feature-tag.) >>> >>> We run a risk of going through the same thing here. That is >>> what 5897 was about too. >> >> The procedures associated with the 3GPP feature tags are very well docum= ented, rather than being something general as "audio" and "video". >> >> And, take sip.instance as an example. It is useless unless entities supp= ort procedures associated with it. But, if UA_A inserts sip.instance, and U= E_B does not support it, they will still be able to=20 >>communicate. But, if they want to use features associated with the featur= e tag, they need to support the procedures defined for that feature. There = is nothing in the "SIP signalling" that tells the entities what=20 >>to do, if the sip.instance e.g. is going to be used outside the dialog (e= .g in a REFER request). > >sip.instance may have been a mistake. It makes sense as a Contact header >parameter, but whether it is truly a capability/feature is a bit shaky. I agree. It doesn't really indicate support of a feature, unless you would = define it as "the capability to be globally reachable". BUT, it's still one of the most used feature tags in SIP :) >Even so, its not an "outbound" feature, and its inclusion does not mean >that you want outbound functionality. It merely says "this is who I am" >and thus can be used for many things. Exactly. Regards, Christer= From jon.peterson@neustar.biz Thu Jan 27 15:33:06 2011 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 942BD3A6A9E for ; Thu, 27 Jan 2011 15:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.434 X-Spam-Level: X-Spam-Status: No, score=-104.434 tagged_above=-999 required=5 tests=[AWL=2.165, BAYES_00=-2.599, 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 m1ozvSPDz+V5 for ; Thu, 27 Jan 2011 15:33:05 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 492053A6A3B for ; Thu, 27 Jan 2011 15:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1296171363; x=1611530938; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=uHtKGVO61WHXuCo11DTtl I3zNQlRczGEbEcHHFhM6V4=; b=ImUpVqCumxv1FnS32nFR45p5jwzpcaix2uLGA 3C500bKO+/zuZ2NPRehg+e3VK1FNNQINUZfLPO/aYX8jfM/CA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.19183535; Thu, 27 Jan 2011 18:36:02 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 27 Jan 2011 18:36:02 -0500 From: "Peterson, Jon" To: "Thomson, Martin" Date: Thu, 27 Jan 2011 18:36:00 -0500 Thread-Topic: [sipcore] Ad-hoc call notes Thread-Index: Acu+evTtVB1D31KAQcmvFEVJxNxlFg== Message-ID: <48F995DF-D6C1-466D-934B-445082BDFC44@neustar.biz> References: <4D41D9A2.9070303@nostrum.com> <201101272129.p0RLTZB5025892@sj-core-4.cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA14D72@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA14D72@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 63lZd6OI5Le/jxqY0ATYhA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Ad-hoc call notes 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, 27 Jan 2011 23:33:07 -0000 >>>=20 >>=20 >> Jon said this, but I don't believe others on the call agreed to this >> by the time the call ended. For example, I think we need a >> verification that location sent was received, and not treat that by >> basically ignoring if location was in the message at all. This goes >> towards treating location reception explicitly vs. implicitly. >=20 > Jon walk talking about MESSAGE specifically. It seemed that there would = be little reason to withhold a 200 based on whether or not the URI had been= successfully followed or not. That was in rebuttal to a specific question= about MESSAGE - I'm not sure if this was intended to cover all cases. >=20 > In any case, I think that the general idea of the text (as promised) that= says: If you don't dereference and send 200 anyway, make sure you have ano= ther channel to use if problems arise. What I said repeatedly was that we should not try to build the expected beh= avior of applications into the low-level protocol building blocks. The term= ination of a non-INVITE transaction like MESSAGE with a 200 response, I sai= d, acknowledges that at a protocol level the transaction was "OK," not that= the payload of the message is useful or agreeable. If you send me a MESSAG= E method with the text "can i borrow $40?", the 200 OK does not imply that = I accede to your request. For some applications relying on non-INVITE trans= actions, I can imagine the 200 meaning nothing more than "I got the message= ," not "I got the message and I was able to dereference the URI in it."=20 I am especially concerned here about the implication that location by-refer= ence simply does not work for non-INVITE transactions, since those transact= ions would ordinarily complete before the dereference could be performed. W= e'd need to look at specific use cases to figure out the best way to adapt = non-INVITE transactions to their behavior, but for the time being, I think = we just need to add to 3.2 a note suggesting that for non-INVITE transactio= ns, the defer may not be performed prior to sending a 200 response. Jon Peterson NeuStar, Inc.= From john.elwell@siemens-enterprise.com Fri Jan 28 09:23:42 2011 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 957F63A67C2 for ; Fri, 28 Jan 2011 09:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 nm5bjK63qKaM for ; Fri, 28 Jan 2011 09:23:41 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 354A53A67F4 for ; Fri, 28 Jan 2011 09:23:40 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3191457; Fri, 28 Jan 2011 18:26:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id E848E23F0290; Fri, 28 Jan 2011 18:26:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 28 Jan 2011 18:26:47 +0100 From: "Elwell, John" To: "R.Jesske@telekom.de" , "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Fri, 28 Jan 2011 18:26:45 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu9f3vh+3m5QYFUQ0KhZJ6olw9MLgAtC51QADaNDqA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 28 Jan 2011 17:23:42 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 27 January 2011 15:21 > To: pkyzivat@cisco.com; sipcore@ietf.org > Subject: Re: [sipcore] Draft new version:=20 > draft-holmberg-sipcore-proxy-feature >=20 > Hi Paul, > I tried to express a possible use case more in general. > So "emergency" means that the Call is passed through an=20 > Server that assures that a INVITE with a URI addressing a=20 > emergency number e.g. 110@domain or 999@domain or it could=20 > also use sos@domain will be handled correctly by the AS and=20 > will be forwarded to the next emergency centre. [JRE] This doesn't make sense to me. How can a single feature tag indicatin= g support for emergency tell me how to code the URI (with 110@domain or 999= @domain or sos@domain, etc.)? John >=20 > My example was pointing to a use-case that could be happen=20 > within the internet, when service provider will support=20 > emergency. Und the user will be informed that he is sure that=20 > the emergency call will be passed through with the first=20 > INVITE. And not waiting for certain responses if the call=20 > will not succeed. >=20 > My intension was to try to point to possible internet=20 > applications that could use Christers draft. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > > Gesendet: Mittwoch, 26. Januar 2011 18:35 > > An: sipcore@ietf.org > > Betreff: Re: [sipcore] Draft new version: > > draft-holmberg-sipcore-proxy-feature > > > > inline > > > > On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > > > Hi, > > > there is an scenario which I would see also within the > > Internet approach. Perhaps others too. > > > > > > When you register it would be useful to know if the proper > > emergency service is served by the provider you are connected to. > > > Such an explicit indication would help. > > > > > > > > > Alice P1 > > REGISTRAR > > > | | =20 > | > > > |--- REGISTER-------------->| =20 > | > > > | | =20 > | > > > | |---=20 > REGISTER-------------->| > > > | | Path:=20 > P1;emergency | > > > | | =20 > | > > > | | =20 > | > > > | |<-- 200 OK=20 > ----------------| > > > | | Path:=20 > P1;emergency | > > > | | =20 > Service-Route: REG | > > > |<-- 200 OK ----------------| =20 > | > > > | Path: P1;emergency | =20 > | > > > | Service-Route: REG | =20 > | > > > | | =20 > | > > > > > > So that Alice is now sure that an emergency call will get > > thought and the correct emergency centre will be reached. > > Which is not even guaranteed in an pure internet environment > > depended which service provider is chosen. > > > > Why is presence of this parameter on *Path* appropriate? Path has > > nothing to do with new calls originated by Alice. If anything were > > relevant, it would be Service-Route, which Alice would > > include in Route > > when making a new call. > > > > And, what does the "emergency" capability *mean*? Does it > > mean that it > > can route requests with urn:sos as the R-URI? Or that it > > recognizes URIs > > containing dial strings that contain emergency numbers? Or > > what? (If the > > latter, emergency numbers for what locale(s)?, and encoded in > > what manner?) > > > > But, why is this needed? Why not just send the request and cope with > > failure to route if/when it happens? > > > > Thanks, > > Paul > > _______________________________________________ > > 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 Fri Jan 28 14:47:53 2011 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 050953A68B7 for ; Fri, 28 Jan 2011 14:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 v4dNd3Wddfal for ; Fri, 28 Jan 2011 14:47:51 -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 9E6C03A67EC for ; Fri, 28 Jan 2011 14:47:51 -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: AvsEACPXQk1AZnwM/2dsb2JhbAClA3OgM5tKhU8EhRiHD4NE Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Jan 2011 22:50:58 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0SMowUd029464; Fri, 28 Jan 2011 22:50:58 GMT Message-ID: <4D434852.3010006@cisco.com> Date: Fri, 28 Jan 2011 17:50:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Eric Burger Subject: [sipcore] SIP Network Operators Conference (SIPNOC) 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, 28 Jan 2011 22:47:53 -0000 I received a request from Eric Burger to post this. It seems appropriately relevant. -------- Original Message -------- The SIP Forum is holding its first SIP Network Operators Conference (SIPNOC) on April 25th to the 27th, 2011, at the Hyatt Dulles Hotel in Herndon, Virginia – a few minutes from Dulles International Airport. SIPNOC is a technical conference developed for service providers and carriers to gather and discuss the challenges of deploying and implementing SIP-based communications technology, and to share the best-practices and strategies that enable the successful and profitable operation of SIP-based services and applications in fixed and mobile IP network environments. Unlike other events, this conference is for SIP network operations personnel, such as NOC engineers, rather than a high-level conference for executives. For more information about SIPNOC, including the preliminary schedule of events and other important details about the conference, please visit http://www.sipnoc.org. The SIPNOC Program Committee is seeking proposals for presentations, panels, or BOFs (Birds-Of-a-Feather sessions) for the SIPNOC 2011 program. We invite presentations highlighting issues relating to SIP network deployments. Operators are encouraged to present on successes, issues, and concerns found in their deployments. Vendors are encouraged to work with operators to present real-world deployment experiences. The deadline for submission of presentation/paper abstracts and draft slides is February 21, 2011. Full details of the submission process and policies, as well as other SIPNOC 2011 dates of interest, can be found at: http://www.sipforum.org/content/view/374/275/ I look forward to seeing you at the event! Best Wishes, Eric Burger SIPNOC Chair From hannes.tschofenig@gmx.net Sun Jan 30 03:36:47 2011 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 178E53A693B for ; Sun, 30 Jan 2011 03:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 1qF88ituEm6S for ; Sun, 30 Jan 2011 03:36:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id D4B833A691D for ; Sun, 30 Jan 2011 03:36:45 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2011 11:39:54 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp010) with SMTP; 30 Jan 2011 12:39:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181PVIg8aw1SX1B2exs/CTkYmFD7o04m4sxe6H+gq WxC4MlYcX3/DYG Message-ID: <4D454DFC.9050901@gmx.net> Date: Sun, 30 Jan 2011 13:39:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 30 Jan 2011 11:36:47 -0000 On 1/27/2011 3:55 PM, Christer Holmberg wrote: > Eventhough I would be happy to see usage outside of IMS for the mechanism, I don't see why 3GPP people should have to try to invent such use-cases "by force". Christer, the challenge is to figure out whether there are more generic usage patterns that can be identified. The idea of developing these more generic features is that you could re-use them in different usage environments. Standardizing point-solutions is quite expensive and the results often do not see deployment. Specifically, there is the question about how much standardization is necessary to get the basic level of interoperability to let those players in the application eco-system extend their software in a way that it works with others. In general, it is fair to say that standardizing each application has not been very successful. Does that make sense? Ciao Hannes From christer.holmberg@ericsson.com Sun Jan 30 04:28:27 2011 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 9B7373A6965 for ; Sun, 30 Jan 2011 04:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPgL1VIKEgEx for ; Sun, 30 Jan 2011 04:28:26 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7F3153A6973 for ; Sun, 30 Jan 2011 04:28:24 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-dd-4d455a26bc12 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.09.23694.62A554D4; Sun, 30 Jan 2011 13:31:34 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 30 Jan 2011 13:31:33 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Sun, 30 Jan 2011 13:31:33 +0100 Thread-Topic: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel Thread-Index: Acu76d/T5rktUPNuRt+UPdEqX8dydQEj54Qg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944155A16@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058519441FDB80@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058519441FDB80@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A05851944155A16ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel 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, 30 Jan 2011 12:28:27 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851944155A16ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As there were no objections, I have now submitted a new version (-04) of th= e draft, that implements the suggested changes below. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 24. tammikuuta 2011 19:12 To: sipcore@ietf.org Subject: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in= case of Require:100rel Hi, An issue that came up during the review of 199 was whether the fact that a = proxy was allowed to send unreliable 199 responses, even in the case of Req= uire:100rel. The WG previously agreed that Require:100rel as such does not affect proxie= s. But, the issue that has been raised is more related to the UAC: it could= receive unreliable 199 responses even if it has required provisional respo= nses to be sent reliably. So, people asked whether we would need to update RFC 3262, and state that a= UAC has to be ready to receive unreliable provisional responses even in th= e case of Require:100rel. Another proposal was so simply say that a proxy is not allowed to send 199 = responses in case of Require:100rel, and include a recommendation that the = UAC does not use Require:100rel when also indicating support of 199 - unles= s the UAC also uses other extensions that mandates Require:100rel, that is. My suggestion is to move forward with the second proposal, i.e. to say that= a proxy must not send 199 responses in case of Require:100rel. If someone objects to such way forward, please indicate it on the list (pre= ferable together with an alternative solution) by Friday this week. Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05851944155A16ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
As there were no objections, I have now submitted = a new=20 version (-04) of the draft, that implements the suggested changes=20 below.
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: 24. tammikuuta 2011 19:12
To:=20 sipcore@ietf.org
Subject: [sipcore] 199 issue: UAC issue when pro= xies=20 send unreliable 199 in case of Require:100rel

 
Hi,
 
An issue that came up during the review of 199 was whet= her the=20 fact that a proxy was allowed to send unreliable 199 responses, even in the= case=20 of Require:100rel.
 
The WG previously agreed that Require:100rel as such do= es not=20 affect proxies. But, the issue that has been raised is more related to the = UAC:=20 it could receive unreliable 199 responses even if it has required provision= al=20 responses to be sent reliably.
 
So, people asked whether we would need to update RFC 32= 62, and=20 state that a UAC has to be ready to receive unreliable provisional response= s=20 even in the case of Require:100rel.
 
Another proposal was so simply say that a proxy is not = allowed=20 to send 199 responses in case of Require:100rel, and include a recommendati= on=20 that the UAC does not use Require:100rel when also indicating support of 19= 9 -=20 unless the UAC also uses other extensions that mandates Require:100rel, tha= t=20 is.
 
My suggestion is to move forward with the second propos= al,=20 i.e. to say that a proxy must not send 199 responses in case of=20 Require:100rel.
 
If someone objects to such way forward, please indicate= it on=20 the list (preferable together with an alternative solution) by Friday this= =20 week.
 
Thanks!
 
Regards,
 
Christer
 
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05851944155A16ESESSCMS0356e_-- From Internet-Drafts@ietf.org Sun Jan 30 04:30:02 2011 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 A23AE3A696E; Sun, 30 Jan 2011 04:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qZs3irJZBUZR; Sun, 30 Jan 2011 04:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897CD3A679C; Sun, 30 Jan 2011 04:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110130123001.7394.10551.idtracker@localhost> Date: Sun, 30 Jan 2011 04:30:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-04.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: Sun, 30 Jan 2011 12: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 : Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-04.txt Pages : 16 Date : 2011-01-30 This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-04.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-199-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-30042520.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Sun Jan 30 04:38:56 2011 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 8C71E3A6973 for ; Sun, 30 Jan 2011 04:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m6m3S9EqC-d for ; Sun, 30 Jan 2011 04:38:55 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8C0BC3A67B2 for ; Sun, 30 Jan 2011 04:38:55 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-99-4d455c9e3d43 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 70.59.23694.E9C554D4; Sun, 30 Jan 2011 13:42:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 30 Jan 2011 13:42:04 +0100 From: Christer Holmberg To: 'Hannes Tschofenig' Date: Sun, 30 Jan 2011 13:42:03 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: AcvAcmq2uKkZDRylR0iHuhFn21MbnwAB24qw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944155A18@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D454DFC.9050901@gmx.net> In-Reply-To: <4D454DFC.9050901@gmx.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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 30 Jan 2011 12:38:56 -0000 Hi,=20 >the challenge is to figure out whether there are more generic usage patter= ns that can be identified. The idea of developing these more generic featur= es is that you could re-use them in different usage=20 >environments. Standardizing point-solutions is quite expensive and the res= ults often do not see deployment. Use-cases don't come up just like that. They might come later, or the might= never come. Curently 3GPP has identified a number of use-case, and for tha= t a solution is needed. >Specifically, there is the question about how much standardization is nece= ssary to get the basic level of interoperability to let those players in th= e application eco-system extend their software in a=20 >way that it works with others. In general, it is fair to say that standard= izing each application has not been very successful. > >Does that make sense? Not really. I am not asking IETF to standardize an application, only a gene= ric indication mechanism. OR, are you saying that 3GPP should just go ahead and do this, without any = IETF standardization (after all, there are no backward compability issues, = as the feature tags will simply be seen as unsupported parameters by entiti= es not supporting them). Regards, Christer From christer.holmberg@ericsson.com Mon Jan 31 02:37:50 2011 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 74E373A68ED for ; Mon, 31 Jan 2011 02:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 eMSXQwiZQJav for ; Mon, 31 Jan 2011 02:37:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F0E6D3A68F6 for ; Mon, 31 Jan 2011 02:37:48 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-94-4d4691bd674a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 76.75.13987.DB1964D4; Mon, 31 Jan 2011 11:41:02 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 31 Jan 2011 11:41:00 +0100 From: Christer Holmberg To: "'Elwell, John'" , "R.Jesske@telekom.de" , "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Mon, 31 Jan 2011 11:40:59 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu9f3vh+3m5QYFUQ0KhZJ6olw9MLgAtC51QADaNDqAAiUoi4A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944155A21@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 31 Jan 2011 10:37:50 -0000 Hi,=20 >>I tried to express a possible use case more in general. >>So "emergency" means that the Call is passed through an Server that=20 >>assures that a INVITE with a URI addressing a emergency number e.g.=20 >>110@domain or 999@domain or it could also use sos@domain will be=20 >>handled correctly by the AS and will be forwarded to the next=20 >>emergency centre. >[JRE] This doesn't make sense to me. How can a single feature tag indicati= ng support for emergency tell me how to code the URI (with 110@domain or 99= 9@domain or sos@domain, etc.)? Feature tags can have values, which could be used to indicate that. For exa= mple: emergency=3D"999@domain". However, I am not sure that the use-case was about informing what the emerg= ency number is, but to indicate that the proxy can handle emergency calls -= whatever the URI to indicate emergency calls within that network is. Regards, Christer >=20 > My example was pointing to a use-case that could be happen within the=20 > internet, when service provider will support emergency. Und the user=20 > will be informed that he is sure that the emergency call will be=20 > passed through with the first INVITE. And not waiting for certain=20 > responses if the call will not succeed. >=20 > My intension was to try to point to possible internet applications=20 > that could use Christers draft. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > > Gesendet: Mittwoch, 26. Januar 2011 18:35 > > An: sipcore@ietf.org > > Betreff: Re: [sipcore] Draft new version: > > draft-holmberg-sipcore-proxy-feature > > > > inline > > > > On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > > > Hi, > > > there is an scenario which I would see also within the > > Internet approach. Perhaps others too. > > > > > > When you register it would be useful to know if the proper > > emergency service is served by the provider you are connected to. > > > Such an explicit indication would help. > > > > > > > > > Alice P1 > > REGISTRAR > > > | | =20 > | > > > |--- REGISTER-------------->| =20 > | > > > | | =20 > | > > > | |---=20 > REGISTER-------------->| > > > | | Path:=20 > P1;emergency | > > > | | =20 > | > > > | | =20 > | > > > | |<-- 200 OK=20 > ----------------| > > > | | Path:=20 > P1;emergency | > > > | | =20 > Service-Route: REG | > > > |<-- 200 OK ----------------| =20 > | > > > | Path: P1;emergency | =20 > | > > > | Service-Route: REG | =20 > | > > > | | =20 > | > > > > > > So that Alice is now sure that an emergency call will get > > thought and the correct emergency centre will be reached. > > Which is not even guaranteed in an pure internet environment=20 > > depended which service provider is chosen. > > > > Why is presence of this parameter on *Path* appropriate? Path has=20 > > nothing to do with new calls originated by Alice. If anything were=20 > > relevant, it would be Service-Route, which Alice would include in=20 > > Route when making a new call. > > > > And, what does the "emergency" capability *mean*? Does it mean that=20 > > it can route requests with urn:sos as the R-URI? Or that it=20 > > recognizes URIs containing dial strings that contain emergency=20 > > numbers? Or what? (If the latter, emergency numbers for what=20 > > locale(s)?, and encoded in what manner?) > > > > But, why is this needed? Why not just send the request and cope with=20 > > failure to route if/when it happens? > > > > Thanks, > > Paul > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Mon Jan 31 04:00:29 2011 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 169783A6915 for ; Mon, 31 Jan 2011 04:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 leAzZdUKDyPN for ; Mon, 31 Jan 2011 04:00:28 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E894B3A68DF for ; Mon, 31 Jan 2011 04:00:27 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3199128; Mon, 31 Jan 2011 13:03:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EF46923F028E; Mon, 31 Jan 2011 13:03:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 31 Jan 2011 13:03:35 +0100 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Mon, 31 Jan 2011 13:03:34 +0100 Thread-Topic: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel Thread-Index: Acu76d/T5rktUPNuRt+UPdEqX8dydQEj54QgACxZc+A= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058519441FDB80@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851944155A16@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944155A16@ESESSCMS0356.eemea.ericsson.se> 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] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel 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, 31 Jan 2011 12:00:29 -0000 Christer, It seems to me that section 9 is not needed. The two normative statements i= t contains seem to duplicate normative statements made earlier, but using s= lightly different language. IMO it is not good practice to repeat normative= statements, and repeating them using different language is even worse - if= the two instances are found to have subtly different meanings, which one w= ins? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 30 January 2011 12:32 > To: sipcore@ietf.org > Subject: Re: [sipcore] 199 issue: UAC issue when proxies send=20 > unreliable 199 in case of Require:100rel >=20 > Hi, > =20 > As there were no objections, I have now submitted a new=20 > version (-04) of the draft, that implements the suggested=20 > changes below. > =20 > Regards, > =20 > Christer >=20 > ________________________________ >=20 > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24. tammikuuta 2011 19:12 > To: sipcore@ietf.org > Subject: [sipcore] 199 issue: UAC issue when proxies send=20 > unreliable 199 in case of Require:100rel >=20 >=20 > =20 > Hi, > =20 > An issue that came up during the review of 199 was whether=20 > the fact that a proxy was allowed to send unreliable 199=20 > responses, even in the case of Require:100rel. > =20 > The WG previously agreed that Require:100rel as such does not=20 > affect proxies. But, the issue that has been raised is more=20 > related to the UAC: it could receive unreliable 199 responses=20 > even if it has required provisional responses to be sent reliably. > =20 > So, people asked whether we would need to update RFC 3262,=20 > and state that a UAC has to be ready to receive unreliable=20 > provisional responses even in the case of Require:100rel. > =20 > Another proposal was so simply say that a proxy is not=20 > allowed to send 199 responses in case of Require:100rel, and=20 > include a recommendation that the UAC does not use=20 > Require:100rel when also indicating support of 199 - unless=20 > the UAC also uses other extensions that mandates=20 > Require:100rel, that is. > =20 > My suggestion is to move forward with the second proposal,=20 > i.e. to say that a proxy must not send 199 responses in case=20 > of Require:100rel. > =20 > If someone objects to such way forward, please indicate it on=20 > the list (preferable together with an alternative solution)=20 > by Friday this week. > =20 > Thanks! > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > = From christer.holmberg@ericsson.com Mon Jan 31 04:15:58 2011 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 6ED423A6BEC for ; Mon, 31 Jan 2011 04:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpFPUP3NiB0a for ; Mon, 31 Jan 2011 04:15:57 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 479DB3A6938 for ; Mon, 31 Jan 2011 04:15:56 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-66-4d46a8be4472 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C8.35.13987.EB8A64D4; Mon, 31 Jan 2011 13:19:10 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 31 Jan 2011 13:19:10 +0100 From: Christer Holmberg To: "Elwell, John" , "sipcore@ietf.org" Date: Mon, 31 Jan 2011 13:17:11 +0100 Thread-Topic: [sipcore] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel Thread-Index: Acu76d/T5rktUPNuRt+UPdEqX8dydQEj54QgACxZc+AABXmSWQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194414F73A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058519441FDB80@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851944155A16@ESESSCMS0356.eemea.ericsson.se>, 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] 199 issue: UAC issue when proxies send unreliable 199 in case of Require:100rel 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, 31 Jan 2011 12:15:58 -0000 Hi, I guess I could remove section 9, especially since we no more specify any e= xception allowing the sending of unreliable 199 responses in case of Requir= e:100rel. Thanks for the comment! Regards, Christer ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] Sent: Monday, January 31, 2011 2:03 PM To: Christer Holmberg; sipcore@ietf.org Subject: RE: [sipcore] 199 issue: UAC issue when proxies send unreliable 19= 9 in case of Require:100rel Christer, It seems to me that section 9 is not needed. The two normative statements i= t contains seem to duplicate normative statements made earlier, but using s= lightly different language. IMO it is not good practice to repeat normative= statements, and repeating them using different language is even worse - if= the two instances are found to have subtly different meanings, which one w= ins? John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 30 January 2011 12:32 > To: sipcore@ietf.org > Subject: Re: [sipcore] 199 issue: UAC issue when proxies send > unreliable 199 in case of Require:100rel > > Hi, > > As there were no objections, I have now submitted a new > version (-04) of the draft, that implements the suggested > changes below. > > Regards, > > Christer > > ________________________________ > > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24. tammikuuta 2011 19:12 > To: sipcore@ietf.org > Subject: [sipcore] 199 issue: UAC issue when proxies send > unreliable 199 in case of Require:100rel > > > > Hi, > > An issue that came up during the review of 199 was whether > the fact that a proxy was allowed to send unreliable 199 > responses, even in the case of Require:100rel. > > The WG previously agreed that Require:100rel as such does not > affect proxies. But, the issue that has been raised is more > related to the UAC: it could receive unreliable 199 responses > even if it has required provisional responses to be sent reliably. > > So, people asked whether we would need to update RFC 3262, > and state that a UAC has to be ready to receive unreliable > provisional responses even in the case of Require:100rel. > > Another proposal was so simply say that a proxy is not > allowed to send 199 responses in case of Require:100rel, and > include a recommendation that the UAC does not use > Require:100rel when also indicating support of 199 - unless > the UAC also uses other extensions that mandates > Require:100rel, that is. > > My suggestion is to move forward with the second proposal, > i.e. to say that a proxy must not send 199 responses in case > of Require:100rel. > > If someone objects to such way forward, please indicate it on > the list (preferable together with an alternative solution) > by Friday this week. > > Thanks! > > Regards, > > Christer > > > >= From john.elwell@siemens-enterprise.com Mon Jan 31 06:12:08 2011 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 299E63A6B32 for ; Mon, 31 Jan 2011 06:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 dE5PewFtcO6N for ; Mon, 31 Jan 2011 06:12:07 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E58553A683C for ; Mon, 31 Jan 2011 06:12:06 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3210018; Mon, 31 Jan 2011 15:15:20 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 12FAB1EB82C3; Mon, 31 Jan 2011 15:15:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 31 Jan 2011 15:15:20 +0100 From: "Elwell, John" To: Christer Holmberg , "R.Jesske@telekom.de" , "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Mon, 31 Jan 2011 15:15:19 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature Thread-Index: Acu9f3vh+3m5QYFUQ0KhZJ6olw9MLgAtC51QADaNDqAAiUoi4AAHM8yQ Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A21@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944155A21@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature 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, 31 Jan 2011 14:12:08 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 31 January 2011 10:41 > To: Elwell, John; R.Jesske@telekom.de; pkyzivat@cisco.com;=20 > sipcore@ietf.org > Subject: RE: [sipcore] Draft new version:=20 > draft-holmberg-sipcore-proxy-feature >=20 >=20 > Hi,=20 >=20 > >>I tried to express a possible use case more in general. > >>So "emergency" means that the Call is passed through an Server that=20 > >>assures that a INVITE with a URI addressing a emergency number e.g.=20 > >>110@domain or 999@domain or it could also use sos@domain will be=20 > >>handled correctly by the AS and will be forwarded to the next=20 > >>emergency centre. > >[JRE] This doesn't make sense to me. How can a single=20 > feature tag indicating support for emergency tell me how to=20 > code the URI (with 110@domain or 999@domain or sos@domain, etc.)? >=20 > Feature tags can have values, which could be used to indicate=20 > that. For example: emergency=3D"999@domain". >=20 > However, I am not sure that the use-case was about informing=20 > what the emergency number is, but to indicate that the proxy=20 > can handle emergency calls - whatever the URI to indicate=20 > emergency calls within that network is. [JRE] I too am not sure we should bend the feature tag mechanism to use it = for informing a UA what dial string to use. I guess the point behind my com= ment was why are we talking about dial strings here, why not the SOS URN? A= lso, are we talking about the case where the UA has identified a call as an= emergency call but has not resolved the SOS URN (by doing a LOST look-up a= nd populating the Route header field)? Or the case where the UA does not ha= ve access to location information? If the UA has performed all these functi= ons, I don't see what special support is needed from the proxy. In other wo= rds, to understand Roland's use case, I really need more information about = what function the proxy is expected to perform and how the UA knows that it= needs the proxy to do this. John >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > >=20 > > My example was pointing to a use-case that could be happen=20 > within the=20 > > internet, when service provider will support emergency. Und=20 > the user=20 > > will be informed that he is sure that the emergency call will be=20 > > passed through with the first INVITE. And not waiting for certain=20 > > responses if the call will not succeed. > >=20 > > My intension was to try to point to possible internet applications=20 > > that could use Christers draft. > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > > > Gesendet: Mittwoch, 26. Januar 2011 18:35 > > > An: sipcore@ietf.org > > > Betreff: Re: [sipcore] Draft new version: > > > draft-holmberg-sipcore-proxy-feature > > > > > > inline > > > > > > On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: > > > > Hi, > > > > there is an scenario which I would see also within the > > > Internet approach. Perhaps others too. > > > > > > > > When you register it would be useful to know if the proper > > > emergency service is served by the provider you are connected to. > > > > Such an explicit indication would help. > > > > > > > > > > > > Alice P1 > > > REGISTRAR > > > > | | =20 > > | > > > > |--- REGISTER-------------->| =20 > > | > > > > | | =20 > > | > > > > | |---=20 > > REGISTER-------------->| > > > > | | Path:=20 > > P1;emergency | > > > > | | =20 > > | > > > > | | =20 > > | > > > > | |<-- 200 OK=20 > > ----------------| > > > > | | Path:=20 > > P1;emergency | > > > > | | =20 > > Service-Route: REG | > > > > |<-- 200 OK ----------------| =20 > > | > > > > | Path: P1;emergency | =20 > > | > > > > | Service-Route: REG | =20 > > | > > > > | | =20 > > | > > > > > > > > So that Alice is now sure that an emergency call will get > > > thought and the correct emergency centre will be reached. > > > Which is not even guaranteed in an pure internet environment=20 > > > depended which service provider is chosen. > > > > > > Why is presence of this parameter on *Path* appropriate? Path has=20 > > > nothing to do with new calls originated by Alice. If=20 > anything were=20 > > > relevant, it would be Service-Route, which Alice would include in=20 > > > Route when making a new call. > > > > > > And, what does the "emergency" capability *mean*? Does it=20 > mean that=20 > > > it can route requests with urn:sos as the R-URI? Or that it=20 > > > recognizes URIs containing dial strings that contain emergency=20 > > > numbers? Or what? (If the latter, emergency numbers for what=20 > > > locale(s)?, and encoded in what manner?) > > > > > > But, why is this needed? Why not just send the request=20 > and cope with=20 > > > failure to route if/when it happens? > > > > > > Thanks, > > > Paul > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Mon Jan 31 06:28:14 2011 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 F21253A6C04 for ; Mon, 31 Jan 2011 06:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.169 X-Spam-Level: X-Spam-Status: No, score=-110.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 523HKtICyGIV for ; Mon, 31 Jan 2011 06:28:12 -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 7DC093A6C02 for ; Mon, 31 Jan 2011 06:28:12 -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: AvsEAHNWRk1AZnwN/2dsb2JhbACkd3Ohbo1fjQ6FTgSFE4cOg0U Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2011 14:31:26 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VEVQBS016981; Mon, 31 Jan 2011 14:31:26 GMT Message-ID: <4D46C7BE.4050902@cisco.com> Date: Mon, 31 Jan 2011 09:31:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> , <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A21@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944155A21@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] "emergency" via draft-holmberg-sipcore-proxy-feature 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, 31 Jan 2011 14:28:14 -0000 We are well into speculation for this hypothetical (I think) emergency service. I've changed the title to protect the innocent. To summarize a bit, I guess you are saying: - a proxy that somehow got brought in while an initial REGISTER message was being processed could mark the Path header indicating that it supports this "emergency" service. - the registrar might then take the information from that Path header to construct a Service-Route header for the UAC. This could still contain that indication of support for the "emergency" service. - the UAC, upon receiving the response to REGISTER, with a Service-Route, *could* analyze the Service-Route for service "advertisements", for services such as this emergency service. - The UAC would then have to analyze those service advertisements for ones that are applicable to it. - in the case of emergency services, the UAC might have to use the value of the emergency feature tag to decideeee one or more of the following: * this service treats calls addressed to 999@domain as emergencies. I had better encode my emergency calls that way. (Even if my user usually types 911 for an emergency.) * this service treats calls addressed to 999@domain as emergencies. My user usually types 911 for emergency, so this service does me no good. I should find another way to handle my emergency calls. * this service treats calls addressed to 999@domain as emergencies. 999 is not an emergency number for my user. In fact it is a valid non-emergency number. So I had better encode calls to 999 using something other that sip:999@domain. Note, I don't think we want to debate which of these is the "right" answer - we are way too far into the hypothetical. A more interesting thing to take from this is that its about "service discovery". That's especially true when used with REGISTER and Service-Route. But I think it may also be true with Record-Route for dialog establishment - to the extent that there is such a thing as services within a dialog. (And I think we do have examples of such things.) Then draft-holmberg-sipcore-proxy-feature can be seen as a proposed mechanism in support of service discovery. As usual, I think we would be better off backing up and defining *requirements* for service discovery in sip. Certainly there exist service discovery mechanisms for other environments. I can see how one might like to query for available Music-on-Hold services, conference mixers, etc. (AFAIK this is typically done via configuration or proprietary mechanisms right now.) While I want to discuss it further, I think I could get on board to an activity to define how to query for SIP URIs that one could send requests to in order to get specific kinds of behavior. This is at a higher level than "supports audio", "supports video" kinds of things. Its more about "once connected, what's in the audio and video?" E.g. "a music-on-hold server near me that plays pop oldies and supports wideband audio". Thanks, Paul On 1/31/2011 5:40 AM, Christer Holmberg wrote: > > Hi, > >>> I tried to express a possible use case more in general. >>> So "emergency" means that the Call is passed through an Server that >>> assures that a INVITE with a URI addressing a emergency number e.g. >>> 110@domain or 999@domain or it could also use sos@domain will be >>> handled correctly by the AS and will be forwarded to the next >>> emergency centre. >> [JRE] This doesn't make sense to me. How can a single feature tag indicating support for emergency tell me how to code the URI (with 110@domain or 999@domain or sos@domain, etc.)? > > Feature tags can have values, which could be used to indicate that. For example: emergency="999@domain". > > However, I am not sure that the use-case was about informing what the emergency number is, but to indicate that the proxy can handle emergency calls - whatever the URI to indicate emergency calls within that network is. > > Regards, > > Christer > > > > > >> >> My example was pointing to a use-case that could be happen within the >> internet, when service provider will support emergency. Und the user >> will be informed that he is sure that the emergency call will be >> passed through with the first INVITE. And not waiting for certain >> responses if the call will not succeed. >> >> My intension was to try to point to possible internet applications >> that could use Christers draft. >> >> Best Regards >> >> Roland >> >>> -----Ursprüngliche Nachricht----- >>> Von: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>> Gesendet: Mittwoch, 26. Januar 2011 18:35 >>> An: sipcore@ietf.org >>> Betreff: Re: [sipcore] Draft new version: >>> draft-holmberg-sipcore-proxy-feature >>> >>> inline >>> >>> On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote: >>>> Hi, >>>> there is an scenario which I would see also within the >>> Internet approach. Perhaps others too. >>>> >>>> When you register it would be useful to know if the proper >>> emergency service is served by the provider you are connected to. >>>> Such an explicit indication would help. >>>> >>>> >>>> Alice P1 >>> REGISTRAR >>>> | | >> | >>>> |--- REGISTER-------------->| >> | >>>> | | >> | >>>> | |--- >> REGISTER-------------->| >>>> | | Path: >> P1;emergency | >>>> | | >> | >>>> | | >> | >>>> | |<-- 200 OK >> ----------------| >>>> | | Path: >> P1;emergency | >>>> | | >> Service-Route: REG | >>>> |<-- 200 OK ----------------| >> | >>>> | Path: P1;emergency | >> | >>>> | Service-Route: REG | >> | >>>> | | >> | >>>> >>>> So that Alice is now sure that an emergency call will get >>> thought and the correct emergency centre will be reached. >>> Which is not even guaranteed in an pure internet environment >>> depended which service provider is chosen. >>> >>> Why is presence of this parameter on *Path* appropriate? Path has >>> nothing to do with new calls originated by Alice. If anything were >>> relevant, it would be Service-Route, which Alice would include in >>> Route when making a new call. >>> >>> And, what does the "emergency" capability *mean*? Does it mean that >>> it can route requests with urn:sos as the R-URI? Or that it >>> recognizes URIs containing dial strings that contain emergency >>> numbers? Or what? (If the latter, emergency numbers for what >>> locale(s)?, and encoded in what manner?) >>> >>> But, why is this needed? Why not just send the request and cope with >>> failure to route if/when it happens? >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> 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 >