From sip-bounces@ietf.org Fri Jul 01 05:45:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI5p-0005hT-Fc; Fri, 01 Jul 2005 05:45:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI5k-0005f4-SD for sip@megatron.ietf.org; Fri, 01 Jul 2005 05:45:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16386 for ; Fri, 1 Jul 2005 05:45:46 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoIVe-0000w9-GG for sip@ietf.org; Fri, 01 Jul 2005 06:12:37 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 11:45:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Comment on draft-ietf-sip-location-conveyance-00 Date: Fri, 1 Jul 2005 11:45:39 +0200 Message-ID: Thread-Topic: [Sip] Comment on draft-ietf-sip-location-conveyance-00 Thread-Index: AcV8jfoNYCk9IGuVRA6XyZSwEdMt7gBke7bQ From: "PROUVOST Sebastien RD-CORE-ISS" To: "Elwell, John" , , X-OriginalArrivalTime: 01 Jul 2005 09:45:40.0735 (UTC) FILETIME=[A469E0F0:01C57E21] X-Spam-Score: 0.7 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117808412==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2117808412== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57E21.A44CFFAE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57E21.A44CFFAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I fully agree with John. The solution presented in the draft that says that if the UAC do not = insert the location in the INVITE and if its outbound proxy has the info = and wants to have it included it into the INVITE, it returns it in a 4xx = "Retry Location Body" has several drawbacks : - What if the UAC issues the new INVITE that does not contains the = location object (because it does not support this draft for example). If = the call does not go through, this is a very big issue when the call is = an emergency call. As a service provider we cannot rely on the capacity = of the UAC to allow emergency calls to go through. - What if the UAC issues a new INVITE that contains the location object = but that does not correspond to the one the proxy gave. - This solution introduces a supplementary exchange between the UA and = its proxy which introduces an additional delay to the call = establishement (especially important if the UA is over a radio access).=20 If the draft stays as it is, this is one more reason why service = providers would need an SBC : in order to be able to insert location = information to an INVITE request without requiring any UA intervention. It is necessary for a proxy to be able to insert this location info = without having to rely on the UA's intervention.=20 Sebastien. ________________________________ De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Elwell, John Envoy=E9 : mercredi 29 juin 2005 11:19 =C0 : jmpolk@cisco.com; br@brianrosen.net Cc : sip@ietf.org Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00 James, Brian,=20 In section 9 (special provisions for emergency calls) it states:=20 "In the case where the Proxy knows the location of the UAC and does not = detect the UAC's location information message body in the message (or = determines the LO is bad), the Proxy generates a new 4XX (Retry Location = Body) error message that includes a location information message body = for that UAC to include in the subsequent message. The user agent MUST = include this message body in the subsequent emergency message." This places a new requirement on the UAC, which will not be met by UACs = that are not compliant to this document. It seems emergency calls from = such UACs will fail. Regards,=20 John=20 ------_=_NextPart_001_01C57E21.A44CFFAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment on = draft-ietf-sip-location-conveyance-00

Hi, =

I fully agree with=20 John.

The solution presented in the draft=20 that says that if the UAC do not insert the location in the = INVITE=20 and if its outbound proxy has the info and wants to have it included it=20 into the INVITE, it returns it=20 in a 4xx "Retry Location Body" = has several=20 drawbacks :

- What if the UAC issues the new INVITE that does not = contains=20 the location object (because it does not support this draft for = example). If the=20 call does not go through, this is a very big issue when the call is an = emergency=20 call. As a service provider we = cannot rely=20 on the capacity of the UAC to allow emergency calls to go=20 through.

- What if the UAC issues a new INVITE that contains = the location=20 object but that does not correspond to the one the proxy = gave.

- This solution introduces a supplementary exchange = between the=20 UA and its proxy which introduces an additional delay to the call = establishement=20 (especially important if the UA is over a radio access).

If the draft stays as it is, this is one more reason = why service=20 providers would need an SBC : in = order to=20 be able to insert location information to an INVITE request without = requiring=20 any UA = intervention.

It is = necessary for a proxy=20 to be able to insert this location info without having to rely on the = UA's=20 intervention.

Sebastien.


De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Elwell,=20 John
Envoy=E9 : mercredi 29 juin 2005 = 11:19
=C0 :=20 jmpolk@cisco.com; br@brianrosen.net
Cc :=20 sip@ietf.org
Objet : [Sip] Comment on=20 draft-ietf-sip-location-conveyance-00

James, Brian,

In section 9 (special provisions for = emergency calls)=20 it states:

"In = the case where the=20 Proxy knows the location of the UAC and does not detect the UAC's = location=20 information message body in the message (or determines the LO is bad), = the Proxy=20 generates a new 4XX (Retry Location Body) error message that includes a = location=20 information message body for that UAC to include in the subsequent=20 message.  The user agent MUST include this message body in the = subsequent=20 emergency message."

This places a new requirement on the UAC, = which will=20 not be met by UACs that are not compliant to this document. It seems = emergency=20 calls from such UACs will fail.

Regards,

John

------_=_NextPart_001_01C57E21.A44CFFAE-- --===============2117808412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2117808412==-- From sip-bounces@ietf.org Fri Jul 01 06:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoIJf-0003gT-55; Fri, 01 Jul 2005 06:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoIJc-0003fz-DY for sip@megatron.ietf.org; Fri, 01 Jul 2005 06:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21299 for ; Fri, 1 Jul 2005 06:00:05 -0400 (EDT) Received: from [145.253.85.52] (helo=srv.vodafone-terenci.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoIjW-0002My-LG for sip@ietf.org; Fri, 01 Jul 2005 06:26:57 -0400 Received: from vftemx01.terenci.internal.vodafone.com (vftemx01.terenci.internal.vodafone.com [145.253.84.21]) by srv.vodafone-terenci.com (8.12.11/8.12.11) with ESMTP id j619xcHZ006542 for ; Fri, 1 Jul 2005 11:59:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 1 Jul 2005 11:59:38 +0200 Message-ID: <14C94CA4441EDE41A38E466E9430FC8501FCE35A@vftemx01.terenci.internal.vodafone.com> Thread-Topic: unsubscribe Thread-Index: AcV+I5aYH9t3RI0oTPWzo1xcIjEiuw== From: "Brambach, Dirk, VF Terenci" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Sip] unsubscribe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1301902496==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1301902496== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57E23.97A70519" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57E23.97A70519 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe ------------------------------------------------------------------------ ---------- Dirk Brambach Senior Consultant=20 =20 mobile: +49 172 2151 658=20 mail: dirk.brambach@vodafone.com =20 ------_=_NextPart_001_01C57E23.97A70519 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe

unsubscribe

----------------------------------------------------------= ------------------------

Dirk = Brambach

Senior Consultant =

 

mobile: +49 = 172  2151 658

mail: dirk.brambach@vodafone.com  

------_=_NextPart_001_01C57E23.97A70519-- --===============1301902496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1301902496==-- From sip-bounces@ietf.org Fri Jul 01 07:47:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJzn-0007YV-SN; Fri, 01 Jul 2005 07:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJzl-0007YK-J2 for sip@megatron.ietf.org; Fri, 01 Jul 2005 07:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10770 for ; Fri, 1 Jul 2005 07:47:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoKPj-0005Rx-1f for sip@ietf.org; Fri, 01 Jul 2005 08:14:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2005 04:47:36 -0700 X-IronPort-AV: i="3.93,249,1115017200"; d="scan'208"; a="646749378:sNHT30810316" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j61BlZvM015628; Fri, 1 Jul 2005 04:47:35 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 04:47:35 -0700 Received: from [10.32.245.152] ([10.32.245.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 04:47:35 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] Comment on draft-ietf-sip-location-conveyance-00 Date: Fri, 1 Jul 2005 07:47:32 -0400 To: "PROUVOST Sebastien RD-CORE-ISS" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 01 Jul 2005 11:47:35.0222 (UTC) FILETIME=[AC300560:01C57E32] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, jmpolk@cisco.com, "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I wonder if we can use a Supported:location header to distinguish the =20= case of a UA who understands the new rules for handling location from =20= a UA that will be confused by receiving a 4xx and abandon the call. On Jul 1, 2005, at 5:45 AM, PROUVOST Sebastien RD-CORE-ISS wrote: > Hi, > > I fully agree with John. > > The solution presented in the draft that says that if the UAC do =20 > not insert the location in the INVITE and if its outbound proxy has =20= > the info and wants to have it included it into the INVITE, it =20 > returns it in a 4xx "Retry Location Body" has several drawbacks : > > - What if the UAC issues the new INVITE that does not contains the =20 > location object (because it does not support this draft for =20 > example). If the call does not go through, this is a very big issue =20= > when the call is an emergency call. As a service provider we cannot =20= > rely on the capacity of the UAC to allow emergency calls to go =20 > through. > > - What if the UAC issues a new INVITE that contains the location =20 > object but that does not correspond to the one the proxy gave. > > - This solution introduces a supplementary exchange between the UA =20 > and its proxy which introduces an additional delay to the call =20 > establishement (especially important if the UA is over a radio =20 > access). > > If the draft stays as it is, this is one more reason why service =20 > providers would need an SBC : in order to be able to insert =20 > location information to an INVITE request without requiring any UA =20 > intervention. > > It is necessary for a proxy to be able to insert this location info =20= > without having to rely on the UA's intervention. > > Sebastien. > > > De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part =20 > de Elwell, John > Envoy=E9 : mercredi 29 juin 2005 11:19 > =C0 : jmpolk@cisco.com; br@brianrosen.net > Cc : sip@ietf.org > Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00 > > James, Brian, > > In section 9 (special provisions for emergency calls) it states: > > "In the case where the Proxy knows the location of the UAC and does =20= > not detect the UAC's location information message body in the =20 > message (or determines the LO is bad), the Proxy generates a new =20 > 4XX (Retry Location Body) error message that includes a location =20 > information message body for that UAC to include in the subsequent =20 > message. The user agent MUST include this message body in the =20 > subsequent emergency message." > > This places a new requirement on the UAC, which will not be met by =20 > UACs that are not compliant to this document. It seems emergency =20 > calls from such UACs will fail. > > Regards, > > John > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 14:50:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQay-0005BT-Qc; Fri, 01 Jul 2005 14:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQaw-0005AH-LR for sip@megatron.ietf.org; Fri, 01 Jul 2005 14:50:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28213 for ; Fri, 1 Jul 2005 14:50:30 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoR0x-0004RM-Kt for sip@ietf.org; Fri, 01 Jul 2005 15:17:28 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id B75B36C01C for ; Fri, 1 Jul 2005 14:50:26 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Some comments on GRUUs Date: Fri, 1 Jul 2005 14:49:13 -0400 Message-ID: <008b01c57e6d$94216a00$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200506270106.04414.lists@ohlmeier.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Nils Ohlmeier [mailto:lists@ohlmeier.org] > > My concerns with such a solution are: > - how can the UA A determine its address a.example.com? > Especially with NAT's > between the UA and the proxies this a big problem again, or? That task is simpler than I've made it appear, I think. Though I wrote the address as "a.example.com", it has to be "the address by which EP accesses A", which is most likely expressed by an absolute IP address. In any case, it comes from a "Record-Route: a.example.com" that UA A adds to the route-set, so UA A *must* know what that address is. > - the UA needs to implement Route processing logic, which was > not necessary up to now. That is true, though the Route processing logic can be fairly simple, as it only has to recognize and discard Route headers for the one address "a.example.com". (It shouldn't see any others.) Though there is more obscure processing problem -- the request-URI will be "GRUU-A@example.com", and the UA has to be able to recognize its own GRUUs and not forward them to the central server for resolution. > I think it would make more sense to not solve such routing > problems not in the > implementation but by the particular installation, because > they know a lot > better which instance is able to handle what. For the given > example two > possible routing sets could look like this: > > > > > Or > > > > > > > Both are transparent for the UAs. But I admit that they will result in a new > connection between the UA A and hp for in-dialog requests (which are send by > UA A) which might not be desired. More exactly, that is the problem I'm attempting to solve. > In any case it seems to be a very bad idea to install any required "services" > which need to see in-dialog requests on proxies which can not resolve the > GRUU contact (ep in this case.) If accounting etc. is handled at hp and ep is > not required in the Route this prevents a lot of problems. True, but that is the particular case I'm trying to solve. Not so much when EP provides some sort of AAA service, but when it sits on an address-translation boundary and must remain in the route set because A and HP cannot talk directly. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 15:48:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRVT-0006lD-35; Fri, 01 Jul 2005 15:48:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRVR-0006hu-C4 for sip@megatron.ietf.org; Fri, 01 Jul 2005 15:48:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05174 for ; Fri, 1 Jul 2005 15:48:53 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRvT-0001FY-0q for sip@ietf.org; Fri, 01 Jul 2005 16:15:51 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 53B396C01C for ; Fri, 1 Jul 2005 15:48:52 -0400 (EDT) From: "Dale Worley" To: "'Sip (E-mail)'" Subject: RE: [Sip] Some comments on GRUUs Date: Fri, 1 Jul 2005 15:47:39 -0400 Message-ID: <00a401c57e75$bda49340$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42BAB869.1070800@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > The draft I was thinking of is draft-jennings-sipping-outbound-01.txt. > It allows multiple registrations with the same instance id, but > distinguished by a unique flow id. Only one registration per > instanceid/flowid pair is permitted. > > This doesn't explicitly address GRUU, but the gruu mechanism should work > with it - the same gruu would be assigned as long as the instanceid > remains the same. In this draft you wouldn't be registering multiple > contacts in the same REGISTER call, since the point is to > send them over different paths. Well, I was thinking of how we could allow multiple contacts for a GRUU in a manner that was as close as possible to draft-ietf-sip-gruu-03. The draft is keen on two points: 1) a GRUU corresponds to an instance-ID and an AOR, and 2) a GRUU has exactly one contact. The more I think about it, the more I like (1) and the less I like (2). It seems to me that contacts could be connected to GRUUs as dynamically as they are connected to AORs. As I said before, that does not present the proxy with any routing problem that it does not already know how to solve. And now draft-jennings-sipping-outbound shows another situation where having only one contact for a GRUU is not what we really want. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 16:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSEf-000296-7o; Fri, 01 Jul 2005 16:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSEd-00020y-Dz for sip@megatron.ietf.org; Fri, 01 Jul 2005 16:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19260 for ; Fri, 1 Jul 2005 16:35:37 -0400 (EDT) Received: from ussjmh01.bea.com ([63.96.162.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSef-0001ay-HR for sip@ietf.org; Fri, 01 Jul 2005 17:02:33 -0400 Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j61KZW4w017605 for ; Fri, 1 Jul 2005 13:35:32 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 13:35:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2005 13:35:32 -0700 Message-ID: <9B47F89C6226194D9ED3D4BAB227374904048465@ussfex01.bea.com> Thread-Topic: Stateless Notification and Non-Subscribe subscriptions Thread-Index: AcV+Vx4ArH9rBpsdSrawV2HbQ7RUHwAFLEwg From: "Nasir Khan" To: X-OriginalArrivalTime: 01 Jul 2005 20:35:32.0556 (UTC) FILETIME=[6D5998C0:01C57E7C] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.7.1.25 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Stateless Notification and Non-Subscribe subscriptions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is one question that I wanted to get an opinion on and also know if it was ever discussed at some point (I could not get much from the archives on this) RFC 3265 is based on the premise of subscription state that is created and maintained by SUBSCRIBE/NOTIFY exchange and leverages on SIP Dialog machinery for ordering etc. This translates to a Dialog state creation and maintenance at the Subscriber and Notifier end. The question that I have is "Was a stateless notification service considered in SIP framework?"=20 By stateless notification I mean an entity subscribed to certain events gets the notifications when the event is generated *without* having to maintain any dialog state. Usually the notification will have some semblance of versioning in the body and the consumer (subscriber) will understand the event package and will be able to discard any notification of a prior version (if required).=20 The motivation for this line of thought is the usage similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework- 06.txt where the information to be notified to the UA is not changing very frequently but can change anytime, so you need a constant subscription (infinitely lived) and would end up maintaining subscription dialogs with very little notifications on that dialog.=20 So what I am alluding to is a mechanism (in addition to RFC 3265) where the SUBSCRIBE request behaves like a REGISTER in the sense that it installs a subscription with the subscriber (to an abstract subscription service) *without* creating any dialog, just like REGISTER registers an AOR to a location service. (This subscription can also be installed by some non-SIP means as referred to in 3265). When the event is generated the subscription service sends a NOTIFY, again *without* creating any dialog. This way the SIP Notification server shall not need to maintain any state when it doesn't need to, particularly when the event stimulus comes from outside and SIP Notification server may just send notifications (by looking up the abstract subscription service if need be).=20 Thanks Nasir Khan BEA Systems, Inc. =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 16:55:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSY8-0003vs-3k; Fri, 01 Jul 2005 16:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoSY4-0003i5-Ng for sip@megatron.ietf.org; Fri, 01 Jul 2005 16:55:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21249 for ; Fri, 1 Jul 2005 16:55:41 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoSy5-0003hl-NR for sip@ietf.org; Fri, 01 Jul 2005 17:22:38 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 3D2506C01C for ; Fri, 1 Jul 2005 16:55:38 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Stateless Notification and Non-Subscribe subscriptions Date: Fri, 1 Jul 2005 16:54:25 -0400 Message-ID: <00b701c57e7f$114491e0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904048465@ussfex01.bea.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Nasir Khan > > By stateless notification I mean an entity subscribed to > certain events > gets the notifications when the event is generated *without* having to > maintain any dialog state. This seems very difficult to do. A publisher needs to keep a list of all the subscribers to which it will send notifications. And since the publisher needs to be able to forget a subscription if it is not refreshed after a while, the subscribers need to remember to refresh their subscriptions. Both of these require state. The PUBLISH method avoids these problems, but in effect, by provisioning the list of subscribers rather than constructing it dynamically. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 17:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTO0-0004Js-HH; Fri, 01 Jul 2005 17:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTNx-000481-TP for sip@megatron.ietf.org; Fri, 01 Jul 2005 17:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26521 for ; Fri, 1 Jul 2005 17:49:19 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoTny-0001c7-KK for sip@ietf.org; Fri, 01 Jul 2005 18:16:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2005 14:49:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j61LmV7J007324; Fri, 1 Jul 2005 14:49:07 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 17:49:06 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 17:49:05 -0400 Message-ID: <42C5BA51.5040508@cisco.com> Date: Fri, 01 Jul 2005 17:49:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <00a401c57e75$bda49340$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 21:49:05.0762 (UTC) FILETIME=[B3D36420:01C57E86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "'Sip \(E-mail\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>The draft I was thinking of is draft-jennings-sipping-outbound-01.txt. >>It allows multiple registrations with the same instance id, but >>distinguished by a unique flow id. Only one registration per >>instanceid/flowid pair is permitted. >> >>This doesn't explicitly address GRUU, but the gruu mechanism should work >>with it - the same gruu would be assigned as long as the instanceid >>remains the same. In this draft you wouldn't be registering multiple >>contacts in the same REGISTER call, since the point is to >>send them over different paths. > > > Well, I was thinking of how we could allow multiple contacts for a GRUU in a > manner that was as close as possible to draft-ietf-sip-gruu-03. The draft > is keen on two points: 1) a GRUU corresponds to an instance-ID and an AOR, > and 2) a GRUU has exactly one contact. The more I think about it, the more > I like (1) and the less I like (2). It seems to me that contacts could be > connected to GRUUs as dynamically as they are connected to AORs. As I said > before, that does not present the proxy with any routing problem that it > does not already know how to solve. > > And now draft-jennings-sipping-outbound shows another situation where having > only one contact for a GRUU is not what we really want. I think we are really on the same page here. Maybe -outbound- isn't so clear, but I believe that if both it and gruu are in use then it requires that gruu allow multiple contacts for the same instance id, which an extension to the gruu spec. Instead of allowing only one contact per instance id, it only allows one per each instanceid/flowid pair. Were that all agreed to, you could achieve what you want by simply doing one registration with two contacts, which have a common instanceid but different flowids. In outbound, one purpose of flowid is to distinguish intentional registration of another contact to the same instance id from a registration of a replacement contact to that instance id. This is what would be exploited for your case. In principle this isn't needed in the case of a single registration. If one register request contains two contacts with the same instanceid, one can presume that one is not intended to supercede the other without any further hints. So conceivably the rules could be relaxed to not requie flowid in this case. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 18:05:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTdS-0003nV-03; Fri, 01 Jul 2005 18:05:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoTdP-0003nO-5E for sip@megatron.ietf.org; Fri, 01 Jul 2005 18:05:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28441 for ; Fri, 1 Jul 2005 18:05:16 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoU3R-0003E1-R9 for sip@ietf.org; Fri, 01 Jul 2005 18:32:14 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2005 15:05:09 -0700 X-IronPort-AV: i="3.93,252,1115017200"; d="scan'208"; a="195961013:sNHT42264058" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j61M526r013911; Fri, 1 Jul 2005 15:05:07 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 18:05:06 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 18:05:04 -0400 Message-ID: <42C5BE10.1070701@cisco.com> Date: Fri, 01 Jul 2005 18:05:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Stateless Notification and Non-Subscribe subscriptions References: <00b701c57e7f$114491e0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 22:05:04.0579 (UTC) FILETIME=[EF534130:01C57E88] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will second Dale. I think of REGISTER as creating a sort of "poor man's dialog". Were we to start over I don't think you would see REGISTER again in its current form, but it is grandfathered in now. Also, the way register works is based on the assumtion that REGISTER messages will not be forked to different candidate registrars. If that did happen, then register refreshing would not work right. You can't make the same assumption about subscriptions, so you need to retain the route to the server in order to properly refresh. I've been having other discussions with people about "implicit subscription" or "unsolicited notification". These are all driven by the same desire to get rid of some state or the messages that establish it. For instance lots of people want to avoid the subscription for MWI. But as yet nobody has proposed a viable way to do it. Stuff has been implemented to do this, but the cases I am aware of are hacks with major limitations. I don't think a solution that requires "some" dyanmic state, but less that a dialog, is an interesting solution. The most interesting case where I think it might be possible to come up with a solution is when the notifier knows a priori that it wants to notify all registered contacts for its own AoR. In that case the notifier has statically provisioned state about its own AoR and the need to notify that, but no dynamic state. (The MWI is an example of this case.) But I haven't yet found a good solution for even this case. Paul Dale Worley wrote: >>From: Nasir Khan >> >>By stateless notification I mean an entity subscribed to >>certain events >>gets the notifications when the event is generated *without* having to >>maintain any dialog state. > > > This seems very difficult to do. A publisher needs to keep a list of all > the subscribers to which it will send notifications. And since the > publisher needs to be able to forget a subscription if it is not refreshed > after a while, the subscribers need to remember to refresh their > subscriptions. Both of these require state. > > The PUBLISH method avoids these problems, but in effect, by provisioning the > list of subscribers rather than constructing it dynamically. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 20:00:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoVRB-0004FP-JR; Fri, 01 Jul 2005 20:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoVR9-0004Bt-BQ for sip@megatron.ietf.org; Fri, 01 Jul 2005 20:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09078 for ; Fri, 1 Jul 2005 20:00:41 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoVrA-00066h-3N for sip@ietf.org; Fri, 01 Jul 2005 20:27:41 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6200Ui7113542 for ; Fri, 1 Jul 2005 20:00:30 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6200Ugq333570 for ; Fri, 1 Jul 2005 18:00:30 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6200T8C022544 for ; Fri, 1 Jul 2005 18:00:30 -0600 Received: from [9.1.112.222] (sipc.almaden.ibm.com [9.1.112.222]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6200Tw3022537 for ; Fri, 1 Jul 2005 18:00:29 -0600 Message-ID: <42C5D91B.7050105@us.ibm.com> Date: Fri, 01 Jul 2005 17:00:27 -0700 From: "JOHN J. BARTON" User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: sip@ietf.org Subject: Re: [Sip] Stateless Notification and Non-Subscribe subscriptions References: <00b701c57e7f$114491e0$6a01010a@keywest> In-Reply-To: <00b701c57e7f$114491e0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I notice that Nasir specifically said "dialog state". Perhaps he considers dialog state somehow different from the state needed to maintain a subscription (expires, address, event I guess). Dale Worley wrote: >>From: Nasir Khan >> >>By stateless notification I mean an entity subscribed to >>certain events >>gets the notifications when the event is generated *without* having to >>maintain any dialog state. > > > This seems very difficult to do. A publisher needs to keep a list of all > the subscribers to which it will send notifications. And since the > publisher needs to be able to forget a subscription if it is not refreshed > after a while, the subscribers need to remember to refresh their > subscriptions. Both of these require state. > > The PUBLISH method avoids these problems, but in effect, by provisioning the > list of subscribers rather than constructing it dynamically. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- John J. Barton IBM Almaden Research Center http://www.almaden.ibm.com/cs/people/bartonjj/index.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 01 21:13:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoWZ7-0003yy-Aa; Fri, 01 Jul 2005 21:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoWZ5-0003vl-8J for sip@megatron.ietf.org; Fri, 01 Jul 2005 21:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15673 for ; Fri, 1 Jul 2005 21:12:59 -0400 (EDT) Received: from ussjmh01.bea.com ([63.96.162.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoWz9-0001Lr-FK for sip@ietf.org; Fri, 01 Jul 2005 21:39:59 -0400 Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j621Cw4w010090 for ; Fri, 1 Jul 2005 18:12:58 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 18:12:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2005 18:12:57 -0700 Message-ID: <9B47F89C6226194D9ED3D4BAB227374904048596@ussfex01.bea.com> Thread-Topic: Stateless Notification and Non-Subscribe subscriptions Thread-Index: AcV+Vx4ArH9rBpsdSrawV2HbQ7RUHwAOwX2g From: "Nasir Khan" To: X-OriginalArrivalTime: 02 Jul 2005 01:12:58.0042 (UTC) FILETIME=[2ED531A0:01C57EA3] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.6.29.38 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Though I do not have a solution, I think that this is a problem which will become evident when more and more uses for SIP notification mechanism come to the fore.=20 Arguably there will be cases where the use does not even warrant a SIP Notification event package. The vexing problem is the case where the subscriptions have an infinite life as in a few examples below.=20 - "Send me a notification with update to my UA when my user profile changes" (*which may happen once in months*) {SIP UA Profile framework} - "Send me a notification when my buddy is in the vicinity of 2 miles" (*which may not happen in days*) {Presence event package}=20 - "Send me notification when the administrator changes my registration state. (*which may not happen that frequently*) {Registration event package} Etc.=20 The state that is to be notified in such cases is typically resident in a database (or some other persistent store), this data is being modified by different agents, so in above three examples the agents could be=20 (a) User changing his own profile going through the self admin website (b) Presence Server (c) Registrar Administrator All this state has nothing to do with dialog semantics, but will result in unending subscriptions. =20 IMHO the "poor man's dialog" is not a bad tradeoff when you have to maintain these infinitely long subscription dialogs just because a notification may be generated once in a while. I was trying to think of a Subscription Server(like a Registrar) with a Subscription data store (like an abstract location service) and taking the argument further that Subscription having the capability of sending *out of dialog* NOTIFY (which is not the same thing as unsolicited NOTIFY when the UA is *expecting* such NOTIFIES).=20 Thanks Nasir Khan BEA Systems, Inc.=20 >I will second Dale. I think of REGISTER as creating a sort of "poor man's >dialog". Were we to start over I don't think you would see REGISTER again >in its current form, but it is grandfathered in now. > >Also, the way register works is based on the assumtion that REGISTER >messages will not be forked to different candidate registrars. If that did >happen, then register refreshing would not work right. You can't make the >same assumption about subscriptions, so you need to retain the route to the >server in order to properly refresh. > >I've been having other discussions with people about "implicit >subscription" or "unsolicited notification". These are all driven by the >same desire to get rid of some state or the messages that establish it. For >instance lots of people want to avoid the subscription for MWI. > >But as yet nobody has proposed a viable way to do it. Stuff has been >implemented to do this, but the cases I am aware of are hacks with major >limitations. > >I don't think a solution that requires "some" dyanmic state, but less that >a dialog, is an interesting solution. > >The most interesting case where I think it might be possible to come up >with a solution is when the notifier knows a priori that it wants to notify >all registered contacts for its own AoR. In that case the notifier has >statically provisioned state about its own AoR and the need to notify that, >but no dynamic state. (The MWI is an example of this case.) But I haven't >yet found a good solution for even this case. > > Paul > > >Dale Worley wrote: > >From: Nasir Khan > > >By stateless notification I mean an entity subscribed to >certain events >gets the notifications when the event is generated *without* having to >maintain any dialog state. > > > >This seems very difficult to do. A publisher needs to keep a list of all >the subscribers to which it will send notifications. And since the >publisher needs to be able to forget a subscription if it is not refreshed >after a while, the subscribers need to remember to refresh their >subscriptions. Both of these require state. > > >The PUBLISH method avoids these problems, but in effect, by provisioning the >list of subscribers rather than constructing it dynamically. > > >Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 02 14:53:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Don7d-0004Ih-Nk; Sat, 02 Jul 2005 14:53:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Don7b-0004IX-Qi for sip@megatron.ietf.org; Sat, 02 Jul 2005 14:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16866 for ; Sat, 2 Jul 2005 14:53:45 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DonXo-0006vk-3G for sip@ietf.org; Sat, 02 Jul 2005 15:20:53 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j62IrVmf204784 for ; Sat, 2 Jul 2005 18:53:31 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j62IrV2M164004 for ; Sat, 2 Jul 2005 20:53:31 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j62IrV24006903 for ; Sat, 2 Jul 2005 20:53:31 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j62IrVCb006900 for ; Sat, 2 Jul 2005 20:53:31 +0200 In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904048596@ussfex01.bea.com> To: sip@ietf.org Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Sat, 2 Jul 2005 21:53:28 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 02/07/2005 21:53:31, Serialize complete at 02/07/2005 21:53:31 X-Spam-Score: 2.3 (++) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657303159==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1657303159== Content-Type: text/html; charset="US-ASCII"
Regarding notifications we can use PUBLISH the issue is more how we establish
the SLS (State Less SUBSCIRBE).

I am not sure that we need a mechanism for creating state less subscribes in SIP
or whether this can be done via different method as XCAP or some web interface
that will store the subscription to a DB.

Usually state less subscriptions need to reach the user using any available
method at the time of the notification (any SIP contact that is available for
the user, email, SMS etc.). So if we will use SIP for registering those
subscriptions we will need to register a subscription for the AOR and not
for a specific contact.

BTW: I fully agree with Paul that if were we to start over again we would not
create REGISTER. We would probably use only PUB/SUB/NOTIFY

Avshalom Houri
IBM Software Group



"Nasir Khan" <nkhan@bea.com>
Sent by: sip-bounces@ietf.org

02/07/2005 04:12 AM

To
<sip@ietf.org>
cc
Subject
[Sip] RE: Stateless Notification and Non-Subscribe subscriptions






Though I do not have a solution, I think that this is a problem which
will become evident when more and more uses for SIP notification
mechanism come to the fore.
Arguably there will be cases where the use does not even warrant a SIP
Notification event package.

The vexing problem is the case where the subscriptions have an infinite
life as in a few examples below.

- "Send me a notification with update to my UA when my user profile
changes" (*which may happen once in months*) {SIP UA Profile framework}
- "Send me a notification when my buddy is in the vicinity of 2 miles"
(*which may not happen in days*) {Presence event package}
- "Send me notification when the administrator changes my registration
state. (*which may not happen that frequently*) {Registration event
package}

Etc.
The state that is to be notified in such cases is typically resident in
a database (or some other persistent store), this data is being modified
by different agents, so in above three examples the agents could be
(a) User changing his own profile going through the self admin website
(b) Presence Server
(c) Registrar Administrator
All this state has nothing to do with dialog semantics, but will result
in unending subscriptions.  

IMHO the "poor man's dialog" is not a bad tradeoff when you have to
maintain these infinitely long subscription dialogs just because a
notification may be generated once in a while. I was trying to think of
a Subscription Server(like a Registrar) with a Subscription data store
(like an abstract location service) and taking the argument further that
Subscription having the capability of sending *out of dialog* NOTIFY
(which is not the same thing as unsolicited NOTIFY when the UA is
*expecting* such NOTIFIES).


Thanks
Nasir Khan
BEA Systems, Inc.




>I will second Dale. I think of REGISTER as creating a sort of "poor
man's >dialog". Were we to start over I don't think you would see
REGISTER again >in its current form, but it is grandfathered in now.
>
>Also, the way register works is based on the assumtion that REGISTER
>messages will not be forked to different candidate registrars. If that
did >happen, then register refreshing would not work right. You can't
make the >same assumption about subscriptions, so you need to retain the
route to the >server in order to properly refresh.
>
>I've been having other discussions with people about "implicit
>subscription" or "unsolicited notification". These are all driven by
the >same desire to get rid of some state or the messages that establish
it. For >instance lots of people want to avoid the subscription for MWI.
>
>But as yet nobody has proposed a viable way to do it. Stuff has been
>implemented to do this, but the cases I am aware of are hacks with
major >limitations.
>
>I don't think a solution that requires "some" dyanmic state, but less
that >a dialog, is an interesting solution.
>
>The most interesting case where I think it might be possible to come up
>with a solution is when the notifier knows a priori that it wants to
notify >all registered contacts for its own AoR. In that case the
notifier has >statically provisioned state about its own AoR and the
need to notify that, >but no dynamic state. (The MWI is an example of
this case.) But I haven't >yet found a good solution for even this case.
>
>                 Paul
>
>
>Dale Worley wrote:
>
>From: Nasir Khan
>
>
>By stateless notification I mean an entity subscribed to
>certain events
>gets the notifications when the event is generated *without* having to
>maintain any dialog state.
>
>
>
>This seems very difficult to do.  A publisher needs to keep a list of
all
>the subscribers to which it will send notifications.  And since the
>publisher needs to be able to forget a subscription if it is not
refreshed
>after a while, the subscribers need to remember to refresh their
>subscriptions.  Both of these require state.
>
>
>The PUBLISH method avoids these problems, but in effect, by
provisioning the
>list of subscribers rather than constructing it dynamically.
>
>
>Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1657303159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1657303159==-- From sip-bounces@ietf.org Sun Jul 03 11:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6qr-0006S9-Nw; Sun, 03 Jul 2005 11:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6qq-0006Po-3B for sip@megatron.ietf.org; Sun, 03 Jul 2005 11:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11316 for ; Sun, 3 Jul 2005 11:57:45 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp7HE-0001GX-2E for sip@ietf.org; Sun, 03 Jul 2005 12:25:05 -0400 Received: by wproxy.gmail.com with SMTP id 36so591100wra for ; Sun, 03 Jul 2005 08:57:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UHGLfIUmpMWQRBKjDmVChgSKW6AAyDZM6QMfQUYZVQHgxHDRhoIWhX4vwd0iIDmU04WIAcARj0UzbRxoijvDu+cnc5Nr80hONwphutNM6E2dtISOD4uuZQCCaTGMyI/PD8CIeQeTlfmCEy2/PoCFbiAlfxUlVRKSnrfQgXJL3Gc= Received: by 10.54.57.78 with SMTP id f78mr2964095wra; Sun, 03 Jul 2005 08:57:31 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Sun, 3 Jul 2005 08:57:31 -0700 (PDT) Message-ID: <953beacc05070308576e95ce80@mail.gmail.com> Date: Sun, 3 Jul 2005 08:57:31 -0700 From: Rohan Mahy To: "Marco P. Rodrigues" Subject: Re: [Sip] Media Statistics in SIP 200 OK/BYE Message In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Mahy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, You may want to also have a look at: draft-johnston-sipping-rtcp-summary-06 thanks, -rohan On 6/21/05, Marco P. Rodrigues wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Is anyone aware of any documented mechanisms to send call statistics > at the end of a SIP conversation? I'm looking for something similar to > the Connection Parameters sent back in an MGCP 250 message when > a delete connection is requested. >=20 > I know some UA's (Cisco) send these statistics in the SIP 200 BYE > message but I am unable to find any reference to it in any > standards or drafts. >=20 > - -mpr > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) >=20 > iD8DBQFCuFObfj+BwLdVfecRApksAKCtixt4SoEmPRXYMiigZeVgE/jHjQCgi73E > w5JXLCW5ccN76eRMPbG6gtY=3D > =3DgIjU > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 03 11:58:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6rx-0006cG-8l; Sun, 03 Jul 2005 11:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6rv-0006c9-Ad for sip@megatron.ietf.org; Sun, 03 Jul 2005 11:58:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11405 for ; Sun, 3 Jul 2005 11:58:53 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp7IJ-0001Rj-Az for sip@ietf.org; Sun, 03 Jul 2005 12:26:12 -0400 Received: by wproxy.gmail.com with SMTP id i6so579521wra for ; Sun, 03 Jul 2005 08:58:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=do2V7VVl0vGrXgRWdx/x7vln1LQGk1xIGQqXFSN+QLX92HACWgM9nwNTriLwiVx2ITM8M1j2dlWZ4zmKHjT+bMEH31NhIbq2A6JuO/7adZIKf+19dU8QBCJMQ4bXDXUrYVQw0Bl1aSnWaTX36A3q1fYMORIRa0NsBi9euRygoGk= Received: by 10.54.53.15 with SMTP id b15mr2934607wra; Sun, 03 Jul 2005 08:58:45 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Sun, 3 Jul 2005 08:58:45 -0700 (PDT) Message-ID: <953beacc05070308585c393e6@mail.gmail.com> Date: Sun, 3 Jul 2005 08:58:45 -0700 From: Rohan Mahy To: Juha Heinanen Subject: Re: [Sip] comment on draft-ietf-sip-sctp-06.txt In-Reply-To: <200506261631.j5QGVqLE004366@rautu.tutpro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506261631.j5QGVqLE004366@rautu.tutpro.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Mahy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha, It is there for backwards compatibility with implementations that sent it in the past. thanks, -rohan On 6/26/05, Juha Heinanen wrote: > draft-ietf-sip-sctp-06.txt has a note: >=20 > Note that the value "tls", defined by RFC 3261, is intended for TLS over > TCP. >=20 > on the other hand 26.2.2 of rfc3261 has a note: >=20 > The use of transport=3Dtls has consequently been deprecated, partly > because it was specific to a single hop of the request. >=20 > so if a transport parameter indicating tls over tcp has been deprecated, > why do we now need a transport parameter indicating tls over sctp? what > makes sctp in this regards special as compared to tcp? >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 03 12:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp77j-00049L-0o; Sun, 03 Jul 2005 12:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp77g-000498-Q3 for sip@megatron.ietf.org; Sun, 03 Jul 2005 12:15:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12948 for ; Sun, 3 Jul 2005 12:15:10 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp7Y5-0002g7-Ps for sip@ietf.org; Sun, 03 Jul 2005 12:42:30 -0400 Received: by wproxy.gmail.com with SMTP id i8so1236697wra for ; Sun, 03 Jul 2005 09:15:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E7zNJbPlva4prglm/0cy3kGmQIw4fVouw/AB2hmnn8LTJSuotMaMr0GoqtAkFmAoHOUL7O9mLGPrUlYLpO0AlDlk0TmCqVdO1b63ncBw3vfxPWAlU1l4OrY4K3jjTzYE62hyyZMLSt8oUKZc4Omq5Zs6VwseydDACa0/1a/98YA= Received: by 10.54.29.17 with SMTP id c17mr613482wrc; Sun, 03 Jul 2005 09:15:03 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Sun, 3 Jul 2005 09:15:03 -0700 (PDT) Message-ID: <953beacc05070309157131a08f@mail.gmail.com> Date: Sun, 3 Jul 2005 09:15:03 -0700 From: Rohan Mahy To: Nasir Khan Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904048596@ussfex01.bea.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9B47F89C6226194D9ED3D4BAB227374904048596@ussfex01.bea.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Mahy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nasir, There is no such thing in the real world of software as an infinite subscription. Sometime in the next 5, 10, or 20 years your user agent will be unplugged, recycled, rebooted, reprogrammed, renumbered or *something* will happen to it, and unless there is a state recovery mechanism your notifier will leak memory like a sieve. For most UAs it is far more likely for the UA to change IP addresses and therefore change its Contact address once a week or once a month. Clearly you need to keep the target URI, an expiration time, and some indicator of the "version" you are sending so the "subscriber" can detect stale state. PUBLISH uses an ETag for this and you can use the CSeq in a SUB/NOT dialog. The only additional piece of state left is a Call-ID and two tags (which I only need for SUB/NOT). I don't see any convincing analysis that the Call-ID and tags create such a problem in a real implementation that actually works (i.e. that is already storing an expiration time and "version"). It is easy to remove state when you ignore the messy changes that happen in the real world, but if things didn't change, we wouldn't have jobs or interesting problems to work on. thanks, -rohan On 7/1/05, Nasir Khan wrote: >=20 > Though I do not have a solution, I think that this is a problem which > will become evident when more and more uses for SIP notification > mechanism come to the fore. > Arguably there will be cases where the use does not even warrant a SIP > Notification event package. >=20 > The vexing problem is the case where the subscriptions have an infinite > life as in a few examples below. >=20 > - "Send me a notification with update to my UA when my user profile > changes" (*which may happen once in months*) {SIP UA Profile framework} > - "Send me a notification when my buddy is in the vicinity of 2 miles" > (*which may not happen in days*) {Presence event package} > - "Send me notification when the administrator changes my registration > state. (*which may not happen that frequently*) {Registration event > package} >=20 > Etc. > The state that is to be notified in such cases is typically resident in > a database (or some other persistent store), this data is being modified > by different agents, so in above three examples the agents could be > (a) User changing his own profile going through the self admin website > (b) Presence Server > (c) Registrar Administrator > All this state has nothing to do with dialog semantics, but will result > in unending subscriptions. >=20 > IMHO the "poor man's dialog" is not a bad tradeoff when you have to > maintain these infinitely long subscription dialogs just because a > notification may be generated once in a while. I was trying to think of > a Subscription Server(like a Registrar) with a Subscription data store > (like an abstract location service) and taking the argument further that > Subscription having the capability of sending *out of dialog* NOTIFY > (which is not the same thing as unsolicited NOTIFY when the UA is > *expecting* such NOTIFIES). >=20 >=20 > Thanks > Nasir Khan > BEA Systems, Inc. >=20 >=20 >=20 >=20 > >I will second Dale. I think of REGISTER as creating a sort of "poor > man's >dialog". Were we to start over I don't think you would see > REGISTER again >in its current form, but it is grandfathered in now. > > > >Also, the way register works is based on the assumtion that REGISTER > >messages will not be forked to different candidate registrars. If that > did >happen, then register refreshing would not work right. You can't > make the >same assumption about subscriptions, so you need to retain the > route to the >server in order to properly refresh. > > > >I've been having other discussions with people about "implicit > >subscription" or "unsolicited notification". These are all driven by > the >same desire to get rid of some state or the messages that establish > it. For >instance lots of people want to avoid the subscription for MWI. > > > >But as yet nobody has proposed a viable way to do it. Stuff has been > >implemented to do this, but the cases I am aware of are hacks with > major >limitations. > > > >I don't think a solution that requires "some" dyanmic state, but less > that >a dialog, is an interesting solution. > > > >The most interesting case where I think it might be possible to come up > >with a solution is when the notifier knows a priori that it wants to > notify >all registered contacts for its own AoR. In that case the > notifier has >statically provisioned state about its own AoR and the > need to notify that, >but no dynamic state. (The MWI is an example of > this case.) But I haven't >yet found a good solution for even this case. > > > > Paul > > > > > >Dale Worley wrote: > > > >From: Nasir Khan > > > > > >By stateless notification I mean an entity subscribed to > >certain events > >gets the notifications when the event is generated *without* having to > >maintain any dialog state. > > > > > > > >This seems very difficult to do. A publisher needs to keep a list of > all > >the subscribers to which it will send notifications. And since the > >publisher needs to be able to forget a subscription if it is not > refreshed > >after a while, the subscribers need to remember to refresh their > >subscriptions. Both of these require state. > > > > > >The PUBLISH method avoids these problems, but in effect, by > provisioning the > >list of subscribers rather than constructing it dynamically. > > > > > >Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 03 13:45:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8Wm-0005e9-BH; Sun, 03 Jul 2005 13:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8Wk-0005e1-Dr for sip@megatron.ietf.org; Sun, 03 Jul 2005 13:45:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20659 for ; Sun, 3 Jul 2005 13:45:06 -0400 (EDT) Received: from primer199.gprs.dnafinland.fi ([62.78.125.199] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp8x6-0000wv-1c for sip@ietf.org; Sun, 03 Jul 2005 14:12:27 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-1) with ESMTP id j63HigAS004331; Sun, 3 Jul 2005 20:44:42 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j63Hifki004328; Sun, 3 Jul 2005 20:44:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17096.9225.372730.566481@rautu.tutpro.com> Date: Sun, 3 Jul 2005 20:44:41 +0300 From: Juha Heinanen To: Rohan Mahy Subject: Re: [Sip] comment on draft-ietf-sip-sctp-06.txt In-Reply-To: <953beacc05070308585c393e6@mail.gmail.com> References: <200506261631.j5QGVqLE004366@rautu.tutpro.com> <953beacc05070308585c393e6@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rohan Mahy writes: > It is there for backwards compatibility with implementations that sent > it in the past. what is for backwards compatibility? indication of tls over tcp has been deprecated and now people are proposing indication of tls over sctp. why is the latter now needed if the former is not anymore needed? makes no sense to me. if uri scheme is sips, then transport=tcp and transport=sctp are enough, because sips requires tls. on the other hand, if uri scheme is sip AND sip entity wants to specify that tls is used anyhow, then we need some other transport parameter to tell if tls is to be implemented over tcp or sctp. i suggest that draft-ietf-sip-sctp-06.txt is changed to cover BOTH tcp and sctp case. in case of tls/tcp, the parameter could be tls-tcp and in case of tls/sctp, the parameter could be tls-sctp. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 04 18:02:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpZ1D-0007Vf-2C; Mon, 04 Jul 2005 18:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpZ1A-0007VU-Uf for sip@megatron.ietf.org; Mon, 04 Jul 2005 18:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22277 for ; Mon, 4 Jul 2005 18:02:18 -0400 (EDT) Received: from ussjmh01.bea.com ([63.96.162.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpZRp-00081T-Bo for sip@ietf.org; Mon, 04 Jul 2005 18:29:53 -0400 Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j64M294w017411; Mon, 4 Jul 2005 15:02:09 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jul 2005 15:02:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Date: Mon, 4 Jul 2005 15:02:08 -0700 Message-ID: <9B47F89C6226194D9ED3D4BAB227374904048689@ussfex01.bea.com> Thread-Topic: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Thread-Index: AcV/6l/T/uZaEmRQS2uWzB5wtZA7jQA8ZhSg From: "Nasir Khan" To: "Rohan Mahy" X-OriginalArrivalTime: 04 Jul 2005 22:02:08.0949 (UTC) FILETIME=[05E17E50:01C580E4] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.6.29.38 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rohan, My question was motivated by practical considerations, but perhaps I could not articulate it properly, my mistake.=20 Yes. The UA will most certainly be rebooted, lose connectivity, upgraded etc. By "infinite subscription" I meant the service that needs the UA to always be subscribed (so if subscription ends by any reason, it will have to re-subscribe). The few examples I stated in previous mail using Presence Event package, Registration event package and SIP UA Profile package need the UA to be constantly subscribed for those events. (again, if subscription ends then refresh it etc.). =20 I may be venturing into implementation details here (which may vary) but I presume that most of the implementations consider dialogs to be "active" objects and hence memory-resident for most part.=20 So considering the fact that the subscriptions in examples above last as long as the user is availing the service from the service provider and there is very little notification traffic and that too triggered by external stimulus in most part, I was suggesting to think about means for dialog-less notifications, thus allowing for simpler implementations.=20 Thanks Nasir Khan BEA Systems, Inc. =20 -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Sunday, July 03, 2005 9:15 AM To: Nasir Khan Cc: sip@ietf.org Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Nasir, There is no such thing in the real world of software as an infinite subscription. Sometime in the next 5, 10, or 20 years your user agent will be unplugged, recycled, rebooted, reprogrammed, renumbered or *something* will happen to it, and unless there is a state recovery mechanism your notifier will leak memory like a sieve. For most UAs it is far more likely for the UA to change IP addresses and therefore change its Contact address once a week or once a month. Clearly you need to keep the target URI, an expiration time, and some indicator of the "version" you are sending so the "subscriber" can detect stale state. PUBLISH uses an ETag for this and you can use the CSeq in a SUB/NOT dialog. The only additional piece of state left is a Call-ID and two tags (which I only need for SUB/NOT). I don't see any convincing analysis that the Call-ID and tags create such a problem in a real implementation that actually works (i.e. that is already storing an expiration time and "version"). It is easy to remove state when you ignore the messy changes that happen in the real world, but if things didn't change, we wouldn't have jobs or interesting problems to work on. thanks, -rohan On 7/1/05, Nasir Khan wrote: >=20 > Though I do not have a solution, I think that this is a problem which > will become evident when more and more uses for SIP notification > mechanism come to the fore. > Arguably there will be cases where the use does not even warrant a SIP > Notification event package. >=20 > The vexing problem is the case where the subscriptions have an infinite > life as in a few examples below. >=20 > - "Send me a notification with update to my UA when my user profile > changes" (*which may happen once in months*) {SIP UA Profile framework} > - "Send me a notification when my buddy is in the vicinity of 2 miles" > (*which may not happen in days*) {Presence event package} > - "Send me notification when the administrator changes my registration > state. (*which may not happen that frequently*) {Registration event > package} >=20 > Etc. > The state that is to be notified in such cases is typically resident in > a database (or some other persistent store), this data is being modified > by different agents, so in above three examples the agents could be > (a) User changing his own profile going through the self admin website > (b) Presence Server > (c) Registrar Administrator > All this state has nothing to do with dialog semantics, but will result > in unending subscriptions. >=20 > IMHO the "poor man's dialog" is not a bad tradeoff when you have to > maintain these infinitely long subscription dialogs just because a > notification may be generated once in a while. I was trying to think of > a Subscription Server(like a Registrar) with a Subscription data store > (like an abstract location service) and taking the argument further that > Subscription having the capability of sending *out of dialog* NOTIFY > (which is not the same thing as unsolicited NOTIFY when the UA is > *expecting* such NOTIFIES). >=20 >=20 > Thanks > Nasir Khan > BEA Systems, Inc. >=20 >=20 >=20 >=20 > >I will second Dale. I think of REGISTER as creating a sort of "poor > man's >dialog". Were we to start over I don't think you would see > REGISTER again >in its current form, but it is grandfathered in now. > > > >Also, the way register works is based on the assumtion that REGISTER > >messages will not be forked to different candidate registrars. If that > did >happen, then register refreshing would not work right. You can't > make the >same assumption about subscriptions, so you need to retain the > route to the >server in order to properly refresh. > > > >I've been having other discussions with people about "implicit > >subscription" or "unsolicited notification". These are all driven by > the >same desire to get rid of some state or the messages that establish > it. For >instance lots of people want to avoid the subscription for MWI. > > > >But as yet nobody has proposed a viable way to do it. Stuff has been > >implemented to do this, but the cases I am aware of are hacks with > major >limitations. > > > >I don't think a solution that requires "some" dyanmic state, but less > that >a dialog, is an interesting solution. > > > >The most interesting case where I think it might be possible to come up > >with a solution is when the notifier knows a priori that it wants to > notify >all registered contacts for its own AoR. In that case the > notifier has >statically provisioned state about its own AoR and the > need to notify that, >but no dynamic state. (The MWI is an example of > this case.) But I haven't >yet found a good solution for even this case. > > > > Paul > > > > > >Dale Worley wrote: > > > >From: Nasir Khan > > > > > >By stateless notification I mean an entity subscribed to > >certain events > >gets the notifications when the event is generated *without* having to > >maintain any dialog state. > > > > > > > >This seems very difficult to do. A publisher needs to keep a list of > all > >the subscribers to which it will send notifications. And since the > >publisher needs to be able to forget a subscription if it is not > refreshed > >after a while, the subscribers need to remember to refresh their > >subscriptions. Both of these require state. > > > > > >The PUBLISH method avoids these problems, but in effect, by > provisioning the > >list of subscribers rather than constructing it dynamically. > > > > > >Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 05 00:42:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpfG7-00078L-7c; Tue, 05 Jul 2005 00:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpfG5-00077Y-6m for sip@megatron.ietf.org; Tue, 05 Jul 2005 00:42:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15128 for ; Tue, 5 Jul 2005 00:42:04 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpfgk-0004iB-DA for sip@ietf.org; Tue, 05 Jul 2005 01:09:43 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j654fkmf203790 for ; Tue, 5 Jul 2005 04:41:46 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j654fkvc159612 for ; Tue, 5 Jul 2005 06:41:46 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j654fjFH002970 for ; Tue, 5 Jul 2005 06:41:46 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j654fjXC002967; Tue, 5 Jul 2005 06:41:45 +0200 In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904048689@ussfex01.bea.com> To: "Nasir Khan" Subject: RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Tue, 5 Jul 2005 07:41:43 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 05/07/2005 07:41:45, Serialize complete at 05/07/2005 07:41:45 X-Spam-Score: 2.3 (++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0070049508==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0070049508== Content-Type: text/html; charset="US-ASCII"
If the subscription will be for a contact then I do not see any point in this.
It becomes more an implementation detail and the server can off-load non-active
subscription to a database and release memory.

I think that if do this it should be a subscription for an AOR and the server
should notify the user in any possible means it has. This way the user will be
notified even if the device that did the subscription is not connected.

Anyway, I am still not sure we need this type of subscription as it can be
achieve by other means as web interface.

Avshalom


"Nasir Khan" <nkhan@bea.com>
Sent by: sip-bounces@ietf.org

05/07/2005 01:02 AM

To
"Rohan Mahy" <rohan.mahy@gmail.com>
cc
sip@ietf.org
Subject
RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions





Rohan,

My question was motivated by practical considerations, but perhaps I
could not articulate it properly, my mistake.

Yes. The UA will most certainly be rebooted, lose connectivity, upgraded
etc. By "infinite subscription" I meant the service that needs the UA to
always be subscribed (so if subscription ends by any reason, it will
have to re-subscribe). The few examples I stated in previous mail using
Presence Event package, Registration event package and SIP UA Profile
package need the UA to be constantly subscribed for those events.
(again, if subscription ends then refresh it etc.).  

I may be venturing into implementation details here (which may vary) but
I presume that most of the implementations consider dialogs to be
"active" objects and hence memory-resident for most part.
So considering the fact that the subscriptions in examples above last as
long as the user is availing the service from the service provider and
there is very little notification traffic and that too triggered by
external stimulus in most part, I was suggesting to think about means
for dialog-less notifications, thus allowing for simpler
implementations.

Thanks

Nasir Khan
BEA Systems, Inc.


-----Original Message-----
From: Rohan Mahy [mailto:rohan.mahy@gmail.com]
Sent: Sunday, July 03, 2005 9:15 AM
To: Nasir Khan
Cc: sip@ietf.org
Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe
subscriptions

Nasir,

There is no such thing in the real world of software as an infinite
subscription.  Sometime in the next 5, 10, or 20 years your user agent
will be unplugged, recycled, rebooted, reprogrammed, renumbered or
*something* will happen to it, and unless there is a state recovery
mechanism your notifier will leak memory like a sieve.  For most UAs
it is far more likely for the UA to change IP addresses and therefore
change its Contact address once a week or once a month.

Clearly you need to keep the target URI, an expiration time, and some
indicator of the "version" you are sending so the "subscriber" can
detect stale state.  PUBLISH uses an ETag for this and you can use the
CSeq in a SUB/NOT dialog.

The only additional piece of state left is a Call-ID and two tags
(which I only need for SUB/NOT).  I don't see any convincing analysis
that the Call-ID and tags create such a problem in a real
implementation that actually works (i.e. that is already storing an
expiration time and "version").

It is easy to remove state when you ignore the messy changes that
happen in the real world, but if things didn't change, we wouldn't
have jobs or interesting problems to work on.

thanks,
-rohan


On 7/1/05, Nasir Khan <nkhan@bea.com> wrote:
>
> Though I do not have a solution, I think that this is a problem which
> will become evident when more and more uses for SIP notification
> mechanism come to the fore.
> Arguably there will be cases where the use does not even warrant a SIP
> Notification event package.
>
> The vexing problem is the case where the subscriptions have an
infinite
> life as in a few examples below.
>
> - "Send me a notification with update to my UA when my user profile
> changes" (*which may happen once in months*) {SIP UA Profile
framework}
> - "Send me a notification when my buddy is in the vicinity of 2 miles"
> (*which may not happen in days*) {Presence event package}
> - "Send me notification when the administrator changes my registration
> state. (*which may not happen that frequently*) {Registration event
> package}
>
> Etc.
> The state that is to be notified in such cases is typically resident
in
> a database (or some other persistent store), this data is being
modified
> by different agents, so in above three examples the agents could be
> (a) User changing his own profile going through the self admin website
> (b) Presence Server
> (c) Registrar Administrator
> All this state has nothing to do with dialog semantics, but will
result
> in unending subscriptions.
>
> IMHO the "poor man's dialog" is not a bad tradeoff when you have to
> maintain these infinitely long subscription dialogs just because a
> notification may be generated once in a while. I was trying to think
of
> a Subscription Server(like a Registrar) with a Subscription data store
> (like an abstract location service) and taking the argument further
that
> Subscription having the capability of sending *out of dialog* NOTIFY
> (which is not the same thing as unsolicited NOTIFY when the UA is
> *expecting* such NOTIFIES).
>
>
> Thanks
> Nasir Khan
> BEA Systems, Inc.
>
>
>
>
> >I will second Dale. I think of REGISTER as creating a sort of "poor
> man's >dialog". Were we to start over I don't think you would see
> REGISTER again >in its current form, but it is grandfathered in now.
> >
> >Also, the way register works is based on the assumtion that REGISTER
> >messages will not be forked to different candidate registrars. If
that
> did >happen, then register refreshing would not work right. You can't
> make the >same assumption about subscriptions, so you need to retain
the
> route to the >server in order to properly refresh.
> >
> >I've been having other discussions with people about "implicit
> >subscription" or "unsolicited notification". These are all driven by
> the >same desire to get rid of some state or the messages that
establish
> it. For >instance lots of people want to avoid the subscription for
MWI.
> >
> >But as yet nobody has proposed a viable way to do it. Stuff has been
> >implemented to do this, but the cases I am aware of are hacks with
> major >limitations.
> >
> >I don't think a solution that requires "some" dyanmic state, but less
> that >a dialog, is an interesting solution.
> >
> >The most interesting case where I think it might be possible to come
up
> >with a solution is when the notifier knows a priori that it wants to
> notify >all registered contacts for its own AoR. In that case the
> notifier has >statically provisioned state about its own AoR and the
> need to notify that, >but no dynamic state. (The MWI is an example of
> this case.) But I haven't >yet found a good solution for even this
case.
> >
> >       Paul
> >
> >
> >Dale Worley wrote:
> >
> >From: Nasir Khan
> >
> >
> >By stateless notification I mean an entity subscribed to
> >certain events
> >gets the notifications when the event is generated *without* having
to
> >maintain any dialog state.
> >
> >
> >
> >This seems very difficult to do.  A publisher needs to keep a list of
> all
> >the subscribers to which it will send notifications.  And since the
> >publisher needs to be able to forget a subscription if it is not
> refreshed
> >after a while, the subscribers need to remember to refresh their
> >subscriptions.  Both of these require state.
> >
> >
> >The PUBLISH method avoids these problems, but in effect, by
> provisioning the
> >list of subscribers rather than constructing it dynamically.
> >
> >
> >Dale
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0070049508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0070049508==-- From sip-bounces@ietf.org Tue Jul 05 10:34:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpoVf-0005Hj-5B; Tue, 05 Jul 2005 10:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpoVd-0005GY-Dy for sip@megatron.ietf.org; Tue, 05 Jul 2005 10:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01163 for ; Tue, 5 Jul 2005 10:34:45 -0400 (EDT) Received: from mw48.mail2world.com ([66.28.189.48] helo=mail2world.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpoqB-0004WC-B0 for sip@ietf.org; Tue, 05 Jul 2005 10:56:03 -0400 Received: from mail pickup service by mail2world.com with Microsoft SMTPSVC; Tue, 5 Jul 2005 07:22:40 -0700 auth-sender: neo@mail2Tycoon.com Received: from 10.1.202.100 unverified ([10.1.202.100]) by mwde08la.mail2world.com with Mail2World SMTP Server, Tue 05 Jul 2005 07:22:40 -07:00 Received: from [203.145.155.10] by mail2Tycoon.com with HTTP; 7/5/2005 7:22:39 AM PST thread-index: AcWBbP/nQwvWX0LmTn6sWXsSasFgsA== Thread-Topic: ACK - creates transaction? From: "Neo Smith" To: Date: Tue, 5 Jul 2005 07:22:39 -0700 Message-ID: <831601c5816c$ffe95520$64ca010a@mail2world.com> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Priority: normal X-Spam: [FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF,0,37]"\Goods\Strong" <0> X-OriginalArrivalTime: 05 Jul 2005 14:22:40.0661 (UTC) FILETIME=[00505450:01C5816D] X-Spam-Score: 2.4 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] ACK - creates transaction? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154573429==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0154573429== Content-Type: multipart/alternative; boundary="----=_NextPart_000_8317_01C58132.538A7D20" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_8317_01C58132.538A7D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Does ACK request creates a new transaction? -Neo-

_______________________________________________________________
Get the FREE email that has everyone talking at http://www.mail2world.com
Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More! ------=_NextPart_000_8317_01C58132.538A7D20 Content-Type: text/html Content-Transfer-Encoding: 7bit Hi,
Does ACK request creates a new transaction?

-Neo-

_______________________________________________________________
Get the FREE email that has everyone talking at http://www.mail2world.com
Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More! ------=_NextPart_000_8317_01C58132.538A7D20-- --===============0154573429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0154573429==-- From sip-bounces@ietf.org Tue Jul 05 10:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpolM-0000n1-Cj; Tue, 05 Jul 2005 10:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpolF-0000eD-OY for sip@megatron.ietf.org; Tue, 05 Jul 2005 10:50:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04202 for ; Tue, 5 Jul 2005 10:50:54 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DppAg-00067e-93 for sip@ietf.org; Tue, 05 Jul 2005 11:17:15 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j65EwMSj006389 for ; Tue, 5 Jul 2005 07:58:22 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j65EsInH025451 for ; Tue, 5 Jul 2005 09:54:19 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Jul 2005 20:19:21 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F30412B7EB@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: Neo Smith , sip@ietf.org Subject: RE: [Sip] ACK - creates transaction? Date: Tue, 5 Jul 2005 20:19:19 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 3.8 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640572280==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0640572280== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58170.B970A176" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C58170.B970A176 Content-Type: text/plain ACK for a 2xx creates a new transaction(special tramsaction, which doesnt have any response), but for non2xx responses its part of INVITE transaction. Rgds Retesh -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Neo Smith Sent: Tuesday, July 05, 2005 7:53 PM To: sip@ietf.org Subject: [Sip] ACK - creates transaction? Hi, Does ACK request creates a new transaction? -Neo- _______________________________________________________________ Get the FREE email that has everyone talking at http://www.mail2world.com Unlimited Email Storage - POP3 - Calendar - SMS - Translator - Much More! ------_=_NextPart_001_01C58170.B970A176 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0yMTk1ODQ3MTQtMDUwNzIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5BQ0sgDQpmb3IgYSAyeHggY3JlYXRl cyBhIG5ldyB0cmFuc2FjdGlvbihzcGVjaWFsIHRyYW1zYWN0aW9uLCB3aGljaCBkb2VzbnQgaGF2 ZSBhbnkgDQpyZXNwb25zZSksIGJ1dCBmb3Igbm9uMnh4IHJlc3BvbnNlcyBpdHMgcGFydCBvZiBJ TlZJVEUgDQp0cmFuc2FjdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz cz0yMTk1ODQ3MTQtMDUwNzIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIxOTU4NDcx NC0wNTA3MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+Umdkczwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIxOTU4NDcxNC0wNTA3MjAwNT48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+UmV0ZXNoPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4N CiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVu LXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiANCiAgc2lwLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5O ZW8gDQogIFNtaXRoPEJSPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBKdWx5IDA1LCAyMDA1IDc6NTMg UE08QlI+PEI+VG86PC9CPiANCiAgc2lwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBbU2lw XSBBQ0sgLSBjcmVhdGVzIA0KICB0cmFuc2FjdGlvbj88QlI+PEJSPjwvRk9OVD48L0RJVj5IaSw8 QlI+RG9lcyBBQ0sgcmVxdWVzdCBjcmVhdGVzIGEgbmV3IA0KICB0cmFuc2FjdGlvbj88QlI+PEJS Pi1OZW8tIDxTUEFOIGlkPW0yd1RsPg0KICA8UD48Rk9OVCBzdHlsZT0iRk9OVC1TSVpFOiAxM3B4 IiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiANCiAgc2l6ZT0yPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxC Uj5HZXQgDQogIHRoZSBGUkVFIGVtYWlsIHRoYXQgaGFzIGV2ZXJ5b25lIHRhbGtpbmcgYXQgPEEg DQogIGhyZWY9Imh0dHA6Ly93d3cubWFpbDJ3b3JsZC5jb20iIA0KICB0YXJnZXQ9bmV3Pmh0dHA6 Ly93d3cubWFpbDJ3b3JsZC5jb208L0E+PEJSPjxGT05UIGNvbG9yPSM5OTk5OTk+VW5saW1pdGVk IA0KICBFbWFpbCBTdG9yYWdlIC0gUE9QMyAtIENhbGVuZGFyIC0gU01TIC0gVHJhbnNsYXRvciAt IE11Y2ggDQogIE1vcmUhPC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPjwvQkxPQ0tRVU9URT48L0JP RFk+PC9IVE1MPg0K ------_=_NextPart_001_01C58170.B970A176-- --===============0640572280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0640572280==-- From sip-bounces@ietf.org Tue Jul 05 11:24:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppHZ-0006NV-Nj; Tue, 05 Jul 2005 11:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppHX-0006LK-7I for sip@megatron.ietf.org; Tue, 05 Jul 2005 11:24:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09331 for ; Tue, 5 Jul 2005 11:24:14 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dppca-0000Ld-MA for sip@ietf.org; Tue, 05 Jul 2005 11:46:05 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 0E4C06C023 for ; Tue, 5 Jul 2005 11:18:15 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Date: Tue, 5 Jul 2005 11:16:47 -0400 Message-ID: <015101c58174$904cd130$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904048596@ussfex01.bea.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Nasir Khan > > The vexing problem is the case where the subscriptions have > an infinite life as in a few examples below. Actually, what makes these cases vexing is the extremely low rate at which notifications will be sent. One might expect that one could just do a SUBSCRIBE with a very long expires time, but since NOTIFYs are sent within the dialog established by SUBSCRIBE, when the UA changes its contact address, the SUBSCRIBE has to be refreshed. Hence there is more traffic maintaining the subscriptions than doing notifications. So we can characterize the problem as "notifications that are less frequent than the UA changes its contact address". Within this context, it seems like PUBLISH messages would be an acceptable way to deliver the notification. PUBLISH can be sent to the user's AOR, and SIP will route the update to the current UA. (A UA may also have to request an explicit update when it starts up.) But how to maintain the state that user foo@bar wants notification of X? In practice this is often done by provisioning (foo goes to a web page to update his list of notifications), because the overhead cost of having an obsolete notification request in the database is small. But we might want to use some variant of SUBSCRIBE to maintain notifications. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 05 12:31:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqKD-00008w-C8; Tue, 05 Jul 2005 12:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqK9-00006o-Ll for sip@megatron.ietf.org; Tue, 05 Jul 2005 12:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18398 for ; Tue, 5 Jul 2005 12:31:00 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpqaP-0005MN-J0 for sip@ietf.org; Tue, 05 Jul 2005 12:47:54 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 277986C023 for ; Tue, 5 Jul 2005 12:20:10 -0400 (EDT) From: "Dale Worley" To: "'Sip (E-mail)'" Subject: RE: [Sip] Some comments on GRUUs Date: Tue, 5 Jul 2005 12:18:42 -0400 Message-ID: <016d01c5817d$36927470$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42C5BA51.5040508@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > In outbound, one purpose of flowid is to distinguish intentional > registration of another contact to the same instance id from a > registration of a replacement contact to that instance id. > This is what > would be exploited for your case. In principle this isn't > needed in the > case of a single registration. If one register request contains two > contacts with the same instanceid, one can presume that one is not > intended to supercede the other without any further hints. So > conceivably the rules could be relaxed to not requie flowid > in this case. As I see it, the concept that there should only be one contact for a given GRUU is of little value. At worst, it means that a request to the GRUU forks, but then both sides of the fork (if they both get through) go to the same device, which can select which of them it wishes to answer. And in general, if one contact is to supercede another, the UA should be cancelling the registration for the old contact, which will automatically remove it as a contact for the GRUU. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 05 13:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpqph-0003AB-Vn; Tue, 05 Jul 2005 13:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpqpf-00039M-Bs for sip@megatron.ietf.org; Tue, 05 Jul 2005 13:03:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23402 for ; Tue, 5 Jul 2005 13:03:30 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DprDA-00006V-5X for sip@ietf.org; Tue, 05 Jul 2005 13:27:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2005 10:00:03 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j65Gxwod013603; Tue, 5 Jul 2005 09:59:58 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 13:00:02 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 13:00:02 -0400 Message-ID: <42CABC91.1070501@cisco.com> Date: Tue, 05 Jul 2005 13:00:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <016d01c5817d$36927470$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 17:00:02.0188 (UTC) FILETIME=[FBE704C0:01C58182] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: "'Sip \(E-mail\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>In outbound, one purpose of flowid is to distinguish intentional >>registration of another contact to the same instance id from a >>registration of a replacement contact to that instance id. >>This is what >>would be exploited for your case. In principle this isn't >>needed in the >>case of a single registration. If one register request contains two >>contacts with the same instanceid, one can presume that one is not >>intended to supercede the other without any further hints. So >>conceivably the rules could be relaxed to not requie flowid >>in this case. > > > As I see it, the concept that there should only be one contact for a given > GRUU is of little value. I think it has been recognized that there indeed can be multiple contacts for a GRUU. But this is semantically different from different contacts for an AoR. With an AoR the assumption is that the different contacts represent distinct alternative UAs. With a GRUU the assumption is that the GRUU represents a single UA and that multiple contacts represent different ways of reaching it. The rest of the stuff around this is a matter of how to manage all this in some kind of coherent way, and preserve the above semantics. And so far the attempt has been to manage this using just the REGISTER request. (An unexplored alternative would be to use different requests to manage these two concepts.) > At worst, it means that a request to the GRUU > forks, but then both sides of the fork (if they both get through) go to the > same device, which can select which of them it wishes to answer. I believe the assumption has been that because these are alternative paths to the same destination, that they should be tried serially, and a subsequent one only tried if the first one failed in a way that is consistent with loss of connectivity. I suppose one could argue with that philosopy. > And in > general, if one contact is to supercede another, the UA should be cancelling > the registration for the old contact, which will automatically remove it as > a contact for the GRUU. In general that would be the goal. But failure scenarios may result in that not happening. E.g. a device reboots and gets a different ip address assigned to it. It doesn't remember the one it had before reboot. Paul > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 05 21:29:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpyj0-0001hO-Sh; Tue, 05 Jul 2005 21:29:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpyiw-0001fN-JZ for sip@megatron.ietf.org; Tue, 05 Jul 2005 21:29:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02638 for ; Tue, 5 Jul 2005 21:29:09 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpyvx-00067c-VY for sip@ietf.org; Tue, 05 Jul 2005 21:42:42 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j661EnvO003956 for ; Tue, 5 Jul 2005 20:14:51 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Jul 2005 09:13:29 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Jul 2005 09:13:29 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 6 Jul 2005 09:13:29 +0800 Message-ID: <2E646075B2C58B4D8DC719AF7E8613490273E4DE@exch03.qd.lucent.com> Thread-Topic: [Sip] Some comments on GRUUs Thread-Index: AcWBf0q6NRijv8/IQPaTNY7PMxtAaQASAYyg From: "Li, Bourne Bao \(Bourne\)" To: "Sip \(E-mail\)" X-OriginalArrivalTime: 06 Jul 2005 01:13:29.0366 (UTC) FILETIME=[EB27DB60:01C581C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [Sip] INFO method used for ISUP to SIP IW X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I got one question of INFO method usage for ISUP to SIP IW.=20 Per RFC 2976 said INFO is used to convey the mid-call information = between 2 UA without impacting the existing call state, which may be = used for ISUP to SIP IW. =20 My question is can INFO method be sent before the dialog has been = established, or it is only allowed to be sent after a confirmed dialog. = Because some ISUP message such as INR/INF, will be sent before ACM/ANM, = which maps to SIP will establish the confirmed dialog. Thanks, Bao _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 05 22:17:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzTQ-0004Mx-CB; Tue, 05 Jul 2005 22:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzTO-0004KX-C3 for sip@megatron.ietf.org; Tue, 05 Jul 2005 22:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06872 for ; Tue, 5 Jul 2005 22:17:10 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpzq0-0001SK-QQ for sip@ietf.org; Tue, 05 Jul 2005 22:40:39 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ600662OWNKA@szxga01-in.huawei.com> for sip@ietf.org; Wed, 06 Jul 2005 10:14:47 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ600GBVOWKOL@szxga01-in.huawei.com> for sip@ietf.org; Wed, 06 Jul 2005 10:14:47 +0800 (CST) Received: from GUEST ([10.76.176.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJ600LQJP3PJX@szxml01-in.huawei.com>; Wed, 06 Jul 2005 10:19:01 +0800 (CST) Date: Wed, 06 Jul 2005 10:10:31 +0800 From: xupeili Subject: RE: [Sip] INFO method used for ISUP to SIP IW In-reply-to: <2E646075B2C58B4D8DC719AF7E8613490273E4DE@exch03.qd.lucent.com> To: "'Li, Bourne Bao (Bourne)'" , "'Sip (E-mail)'" Message-id: <024b01c581cf$e30b2920$5fb04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org INFO can be sent after early-dialog is established. So that INR/INF should be encapsulated in INFO after early dialog. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Li, Bourne Bao (Bourne) Sent: Wednesday, July 06, 2005 9:13 AM To: Sip (E-mail) Subject: [Sip] INFO method used for ISUP to SIP IW I got one question of INFO method usage for ISUP to SIP IW. Per RFC 2976 said INFO is used to convey the mid-call information between 2 UA without impacting the existing call state, which may be used for ISUP to SIP IW. My question is can INFO method be sent before the dialog has been established, or it is only allowed to be sent after a confirmed dialog. Because some ISUP message such as INR/INF, will be sent before ACM/ANM, which maps to SIP will establish the confirmed dialog. Thanks, Bao _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 06 09:14:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9jB-0006i9-NM; Wed, 06 Jul 2005 09:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9j8-0006dQ-1N for sip@megatron.ietf.org; Wed, 06 Jul 2005 09:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17979 for ; Wed, 6 Jul 2005 09:14:07 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqA56-0002Gt-Bn for sip@ietf.org; Wed, 06 Jul 2005 09:36:53 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 15:08:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Wed, 6 Jul 2005 15:08:09 +0200 Message-ID: <49E7012A614B024B80A7D175CB9A64EC05520732@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] INFO method used for ISUP to SIP IW Thread-Index: AcWB0PL2NrSkWfEHSyKrXFnKwszMXwAWpnvg From: "GARCIN Sebastien RD-CORE-ISS" To: "xupeili" , "Li, Bourne Bao \(Bourne\)" , "Sip \(E-mail\)" X-OriginalArrivalTime: 06 Jul 2005 13:08:09.0617 (UTC) FILETIME=[C1C6E810:01C5822B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, You should follow ITU-T recommendation Q.1912.5 in this respect. Regards, =20 -----Message d'origine----- De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = xupeili Envoy=E9 : mercredi 6 juillet 2005 04:11 =C0 : 'Li, Bourne Bao (Bourne)'; 'Sip (E-mail)' Objet : RE: [Sip] INFO method used for ISUP to SIP IW INFO can be sent after early-dialog is established.=20 So that INR/INF should be encapsulated in INFO after early dialog. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Li, Bourne Bao (Bourne) Sent: Wednesday, July 06, 2005 9:13 AM To: Sip (E-mail) Subject: [Sip] INFO method used for ISUP to SIP IW I got one question of INFO method usage for ISUP to SIP IW.=20 Per RFC 2976 said INFO is used to convey the mid-call information = between 2 UA without impacting the existing call state, which may be = used for ISUP to SIP IW. =20 My question is can INFO method be sent before the dialog has been = established, or it is only allowed to be sent after a confirmed dialog. Because some ISUP message such as INR/INF, will be sent before ACM/ANM, = which maps to SIP will establish the confirmed dialog. Thanks, Bao _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 06 11:44:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC4J-0007Sp-IS; Wed, 06 Jul 2005 11:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC4F-0007Nb-N9 for sip@megatron.ietf.org; Wed, 06 Jul 2005 11:44:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12304 for ; Wed, 6 Jul 2005 11:44:03 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCPi-0001z6-VX for sip@ietf.org; Wed, 06 Jul 2005 12:06:21 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A033B1811; Wed, 6 Jul 2005 17:37:25 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 17:37:24 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 17:37:24 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Wed, 6 Jul 2005 17:37:24 +0200 Message-ID: Thread-Topic: [Sip] INFO method used for ISUP to SIP IW Thread-Index: AcWB0PL2NrSkWfEHSyKrXFnKwszMXwAWpnvgAAU0wUA= From: "Christer Holmberg (JO/LMF)" To: "GARCIN Sebastien RD-CORE-ISS" , "xupeili" , "Li, Bourne Bao (Bourne)" , "Sip (E-mail)" X-OriginalArrivalTime: 06 Jul 2005 15:37:24.0701 (UTC) FILETIME=[9B6C48D0:01C58240] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, If I remember correctly, INFO follows the rules of BYE. And, a BYE = cannot be sent in the backword direction for an early dialog, I think. So, I believe that Q.1912.5 uses 18x responses for ISUP sent backward = during early dialogs. Regards, Christer=20 LM Ericsson > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > GARCIN Sebastien RD-CORE-ISS > Sent: 6. hein=E4kuuta 2005 16:08 > To: xupeili; Li, Bourne Bao (Bourne); Sip (E-mail) > Subject: RE: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 > Hi, >=20 > You should follow ITU-T recommendation Q.1912.5 in this respect. >=20 > Regards, > =20 >=20 >=20 > -----Message d'origine----- > De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la=20 > part de xupeili > Envoy=E9 : mercredi 6 juillet 2005 04:11 > =C0 : 'Li, Bourne Bao (Bourne)'; 'Sip (E-mail)' > Objet : RE: [Sip] INFO method used for ISUP to SIP IW >=20 > INFO can be sent after early-dialog is established.=20 > So that INR/INF should be encapsulated in INFO after early dialog. >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Li, Bourne Bao (Bourne) > Sent: Wednesday, July 06, 2005 9:13 AM > To: Sip (E-mail) > Subject: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 >=20 > I got one question of INFO method usage for ISUP to SIP IW.=20 >=20 > Per RFC 2976 said INFO is used to convey the mid-call=20 > information between 2 UA without impacting the existing call=20 > state, which may be used for ISUP to SIP IW. =20 >=20 > My question is can INFO method be sent before the dialog has=20 > been established, or it is only allowed to be sent after a=20 > confirmed dialog. > Because some ISUP message such as INR/INF, will be sent=20 > before ACM/ANM, which maps to SIP will establish the confirmed dialog. >=20 > Thanks, > Bao >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 06 12:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqD65-0008GK-AM; Wed, 06 Jul 2005 12:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqD61-0008Ac-FP for sip@megatron.ietf.org; Wed, 06 Jul 2005 12:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20795 for ; Wed, 6 Jul 2005 12:49:58 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqDWL-0005Ze-3f for sip@ietf.org; Wed, 06 Jul 2005 13:17:15 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j66Gn3We022993; Wed, 6 Jul 2005 11:49:04 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Jul 2005 17:49:03 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0100E61C6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: GARCIN Sebastien RD-CORE-ISS , xupeili , "Li, Bourne Bao (Bourne)" , "Sip (E-mail)" Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Wed, 6 Jul 2005 17:49:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I hope you just mean that Q.1912.5 may provide additional guidance on = how it is interworked. Q.1912.5 cannot change the INFO method and when it is used as the SIP = changes RFC precludes that, and in any case, Q.1912.5 is only an = interworking specification, and interworking specifications cannot = rewrite the base protocol. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > GARCIN Sebastien RD-CORE-ISS > Sent: 06 July 2005 14:08 > To: xupeili; Li, Bourne Bao (Bourne); Sip (E-mail) > Subject: RE: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 > Hi, >=20 > You should follow ITU-T recommendation Q.1912.5 in this respect. >=20 > Regards, > =20 >=20 >=20 > -----Message d'origine----- > De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la=20 > part de xupeili > Envoy=E9 : mercredi 6 juillet 2005 04:11 > =C0 : 'Li, Bourne Bao (Bourne)'; 'Sip (E-mail)' > Objet : RE: [Sip] INFO method used for ISUP to SIP IW >=20 > INFO can be sent after early-dialog is established.=20 > So that INR/INF should be encapsulated in INFO after early dialog. >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Li, Bourne Bao (Bourne) > Sent: Wednesday, July 06, 2005 9:13 AM > To: Sip (E-mail) > Subject: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 >=20 > I got one question of INFO method usage for ISUP to SIP IW.=20 >=20 > Per RFC 2976 said INFO is used to convey the mid-call=20 > information between 2 UA without impacting the existing call=20 > state, which may be used for ISUP to SIP IW. =20 >=20 > My question is can INFO method be sent before the dialog has=20 > been established, or it is only allowed to be sent after a=20 > confirmed dialog. > Because some ISUP message such as INR/INF, will be sent=20 > before ACM/ANM, which maps to SIP will establish the confirmed = dialog. >=20 > Thanks, > Bao >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 06 13:23:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDce-0001O8-43; Wed, 06 Jul 2005 13:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDcO-0001Bu-Bq for sip@megatron.ietf.org; Wed, 06 Jul 2005 13:23:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25409 for ; Wed, 6 Jul 2005 13:23:21 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqDz4-0004Uc-Eg for sip@ietf.org; Wed, 06 Jul 2005 13:46:55 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id DF5F06C029 for ; Wed, 6 Jul 2005 13:18:52 -0400 (EDT) From: "Dale Worley" To: "'Sip (E-mail)'" Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Wed, 6 Jul 2005 13:17:21 -0400 Message-ID: <007101c5824e$9261a560$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Christer Holmberg (JO/LMF) > > If I remember correctly, INFO follows the rules of BYE. And, > a BYE cannot be sent in the backword direction for an early > dialog, I think. The text of RFC 2976 is rather ambiguous on this point. It says that various headers are to be handled "as defined for the BYE request" (section 2.4), but it doesn't say that *when it can be sent* is as for the BYE request. It does envision that INFO requests can be forked (section 4), which can only happen if an INFO is sent not only in an early dialog, but before a 1xx response has established a to-tag. (A request with a to-tag is within an established route set and can't fork.) My guess is that INFO can be sent at any time (and proxies should handle it correctly), but if it is sent before a dialog has been confirmed, due consideration should be given toward ensuring that it will be routed to the destination(s) you intend and interpreted correctly by them. A lot of this probably depends on the details of your particular use of INFO, which may be different from other uses of INFO. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 06 13:40:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDsh-0007l1-FN; Wed, 06 Jul 2005 13:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDsf-0007hl-K6 for sip@megatron.ietf.org; Wed, 06 Jul 2005 13:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27586 for ; Wed, 6 Jul 2005 13:40:13 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqEGL-00075F-Uq for sip@ietf.org; Wed, 06 Jul 2005 14:04:47 -0400 Received: from Mpierce1@aol.com by imo-d20.mx.aol.com (mail_out_v38_r1.7.) id t.ce.6bdd95de (16633); Wed, 6 Jul 2005 13:35:08 -0400 (EDT) Message-ID: Date: Wed, 6 Jul 2005 13:35:08 EDT Subject: Re: [Sip] INFO method used for ISUP to SIP IW To: christer.holmberg@ericsson.com, sebastien.garcin@francetelecom.com, xupeili@huawei.com, bbli@lucent.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Score: 0.7 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034576470==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1034576470== Content-Type: multipart/alternative; boundary="part1_ce.6bdd95de.2ffd704c_boundary" --part1_ce.6bdd95de.2ffd704c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/6/2005 11:47:52 AM Eastern Daylight Time, christer.holmberg@ericsson.com writes: > If I remember correctly, INFO follows the rules of BYE. And, a BYE cannot > be sent in the backword direction for an early dialog, I think. > RFC 2976 says that the INFO follows the rules for BYE as contained in RFC 2543, which is now obsolete, so where does that leave us? RFC 2543 didn't mention "early dialog". Can anyone say that RFC 3261 is exactly the same in this area? We've already seen at least three different opinions on this question. Mike --part1_ce.6bdd95de.2ffd704c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 7/6/2005 11:47:52 AM Eastern Daylight Time, christer.holmberg@er= icsson.com writes:


If I remember correctly, INFO f= ollows the rules of BYE. And, a BYE cannot be sent in the backword direction= for an early dialog, I think.


RFC 2976 says that the INFO follows the rules for BYE as contained in RFC 25= 43, which is now obsolete, so where does that leave us? RFC 2543 didn't ment= ion "early dialog". Can anyone say that RFC 3261 is exactly the same in this= area?

We've already seen at least three different opinions on this question.

Mike
 --part1_ce.6bdd95de.2ffd704c_boundary-- --===============1034576470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1034576470==-- From sip-bounces@ietf.org Wed Jul 06 15:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFue-0008Gc-9d; Wed, 06 Jul 2005 15:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFuF-0007yB-QZ; Wed, 06 Jul 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10047; Wed, 6 Jul 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqGLH-00085s-H7; Wed, 06 Jul 2005 16:18:00 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DqFuD-00087c-Vm; Wed, 06 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-feature-param-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Conveying Feature Tags with Session Initiation Protocol REFER Method Author(s) : O. Levin, A. Johnston Filename : draft-ietf-sip-refer-feature-param-00.txt Pages : 6 Date : 2005-7-6 This document extends the SIP REFER method, defined in RFC 3515, to convey feature parameters defined in RFC 3840. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-feature-param-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-feature-param-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-6114957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-feature-param-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-feature-param-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-6114957.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 06 22:58:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqMaw-0007EW-8S; Wed, 06 Jul 2005 22:58:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqMat-0007DG-O5 for sip@megatron.ietf.org; Wed, 06 Jul 2005 22:58:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27979 for ; Wed, 6 Jul 2005 22:58:29 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqN1n-0002VA-N9 for sip@ietf.org; Wed, 06 Jul 2005 23:26:20 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ800BCULM4PJ@szxga01-in.huawei.com> for sip@ietf.org; Thu, 07 Jul 2005 10:58:52 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ8008ZLLM4K8@szxga01-in.huawei.com> for sip@ietf.org; Thu, 07 Jul 2005 10:58:52 +0800 (CST) Received: from GUEST ([10.76.176.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJ80083QLT8CF@szxml01-in.huawei.com>; Thu, 07 Jul 2005 11:03:08 +0800 (CST) Date: Thu, 07 Jul 2005 10:54:42 +0800 From: xupeili Subject: RE: [Sip] INFO method used for ISUP to SIP IW In-reply-to: To: Mpierce1@aol.com, christer.holmberg@ericsson.com, sebastien.garcin@francetelecom.com, bbli@lucent.com, dworley@pingtel.com, drage@lucent.com, sip@ietf.org Message-id: <000001c5829f$39a12440$5fb04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Now there are 2 questions: (1) When can INFO be sent? Can it be sent from callee to caller? At the time when RFC2976 is created, "early dialog" is not introduces. Although RFC2976 said that it follows the rules for BYE. I guess the indended meaning is that it should follow the rules for messages inside dialog such as BYE. Since it can be used to carry end-to-end information(sometimes before dialog is confirmed like UPDATE), there is no reason to prohibit it from being sent by callee within dialog. Where it can be sent before early dialog is an interesting question, It may depend on the intent of the message. Considering the forking issure, if it carries the information which must be sent to the designated recipient, it`s better to send in within a dialog. In this case, my personal opinion is that early dialog should be established as early as possible to make UPDATE or INFO possible to be delivered. even there is no explicit progress indicator for ringing or queing etc. (2) for ISUP interworking where to encapsulate backword ISUP message like INR? INFO or reliable 1xx? If we agree that INFO can be sent in both direction. It may be sent either in reliable 1xx or INFO. RFC3398 section 13.1 have some rule: "From the caller to the callee, other ISUP messages SHOULD be encapsulated (see [3]) inside INFO messages, even if the INVITE transaction is still not finished. " "From the callee to the caller, if a message is received by a gateway before the call has been answered (i.e., ANM is received) it SHOULD be encapsulated in an INFO, provided that this will not be the first SIP message sent in the backwards direction (in which case it SHOULD be encapsulated in a provisional 1xx response). Similarly a message which is received on the originating side (probably in response to an INR) before a 200 OK has been received by the gateway should be carried within an INFO. " -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mpierce1@aol.com Sent: Thursday, July 07, 2005 1:35 AM To: christer.holmberg@ericsson.com; sebastien.garcin@francetelecom.com; xupeili@huawei.com; bbli@lucent.com; sip@ietf.org Subject: Re: [Sip] INFO method used for ISUP to SIP IW In a message dated 7/6/2005 11:47:52 AM Eastern Daylight Time, christer.holmberg@ericsson.com writes: If I remember correctly, INFO follows the rules of BYE. And, a BYE cannot be sent in the backword direction for an early dialog, I think. RFC 2976 says that the INFO follows the rules for BYE as contained in RFC 2543, which is now obsolete, so where does that leave us? RFC 2543 didn't mention "early dialog". Can anyone say that RFC 3261 is exactly the same in this area? We've already seen at least three different opinions on this question. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 01:43:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPAP-0000TC-Tx; Thu, 07 Jul 2005 01:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPAN-0000Qy-NN for sip@megatron.ietf.org; Thu, 07 Jul 2005 01:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07435 for ; Thu, 7 Jul 2005 01:43:18 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPbU-0000X1-Np for sip@ietf.org; Thu, 07 Jul 2005 02:11:22 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2005 22:43:09 -0700 X-IronPort-AV: i="3.93,267,1115017200"; d="scan'208"; a="647447661:sNHT27967724" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j675h8vM009746; Wed, 6 Jul 2005 22:43:08 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 01:43:07 -0400 Received: from [192.168.1.100] ([10.86.240.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 01:43:07 -0400 Message-ID: <42CCC0EB.1010807@cisco.com> Date: Thu, 07 Jul 2005 01:43:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Sip] updated GRUU spec References: <421D6223.5050607@cisco.com> <428CF7BB.5070302@nortel.com> In-Reply-To: <428CF7BB.5070302@nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 05:43:07.0629 (UTC) FILETIME=[C090A1D0:01C582B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org sorry for the delay in responding Tom, and thanks for the comment. Response below. Tom Taylor wrote: > Minor comment on the GRUU spec. At the beginning of section 8.4.1, the > procedure reads: > > "... the proxy MUST check if the Request URI is a GRUU created by that > domain. > > > "If the GRUU does not exist within the domain, the proxy MUST generate > a 404 (Not Found) response to the request." > > I'd suggest that "GRUU" in that last paragraph be changed to "Request > URI", since the proxy doesn't, absent a GRID parameter, know that it is > dealing with a GRUU. > Actually, thats not right - it can know. It depends on the gruu construction algorithm. This actually relates to an open issue I raised at the last IETF - how the proxy knows to send a 404 vs. a 480. Here is the full text of the first two paragraphs of this section: 8.4.1 Request Targeting When a proxy server receives a request, and the proxy owns the domain in the Request URI, and the proxy is supposed to access a Location Service in order to compute request targets (as specified in Section 16.5 of RFC 3261 [1]), the proxy MUST check if the Request URI is a GRUU created by that domain. If the GRUU does not exist within the domain, the proxy MUST generate a 404 (Not Found) response to the request. I'd suggest adding the following sentence to the end of the first paragraph: "If the Request-URI is not within the domain of the proxy, the proxy follows the procedures in RFC 3261 and rejects the request. If the Request URI is within the domain of the proxy, and the proxy knows of the resource, but it is not a GRUU, processing is outside of the scope of this specification. If the request URI is within the domain of the proxy, and the URI has been constructed by the domain such that the proxy is able to determine that it has the form of a GRUU for an AOR that is unknown within the domain, the proxy rejects the request with a 404. If the request URI is within the domain of the proxy, and the URI has been constructed by the domain such that the proxy is able to determine that it has the form of a GRUU for an AOR that known within the domain, but the instance ID is unknown, the proxy SHOULD generate a 480." This makes things much more specific, and also provides an algorithm for sending a 404 vs. a 480 that is readily realizable. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 02:15:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPeQ-0002Yo-V1; Thu, 07 Jul 2005 02:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPeO-0002Ri-RL for sip@megatron.ietf.org; Thu, 07 Jul 2005 02:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22862 for ; Thu, 7 Jul 2005 02:14:19 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQ5W-0005fu-2k for sip@ietf.org; Thu, 07 Jul 2005 02:42:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2005 02:14:09 -0400 X-IronPort-AV: i="3.93,267,1115006400"; d="scan'208"; a="61320237:sNHT27604968" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j676E8q7005085; Thu, 7 Jul 2005 02:14:08 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:14:08 -0400 Received: from [192.168.1.100] ([10.86.240.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:14:08 -0400 Message-ID: <42CCC82F.3040205@cisco.com> Date: Thu, 07 Jul 2005 02:14:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <016d01c5817d$36927470$6a01010a@keywest> In-Reply-To: <016d01c5817d$36927470$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 06:14:08.0301 (UTC) FILETIME=[159CA5D0:01C582BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: "'Sip \(E-mail\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>In outbound, one purpose of flowid is to distinguish intentional >>registration of another contact to the same instance id from a >>registration of a replacement contact to that instance id. >>This is what >>would be exploited for your case. In principle this isn't >>needed in the >>case of a single registration. If one register request contains two >>contacts with the same instanceid, one can presume that one is not >>intended to supercede the other without any further hints. So >>conceivably the rules could be relaxed to not requie flowid >>in this case. > > > As I see it, the concept that there should only be one contact for a given > GRUU is of little value. There is a lot of value when the client is not trying to have redundant paths to reach the same instance, which is the only case when you really want multiple contacts for the same gruu. For this reason, the multiple-contacts thing is being handled in the sipping-outbound draft. Now, the problem is, as you point out, that draft-ietf-sip-gruu is fairly dogmatic about a single contact per gruu, when we know we are about to modify that behavior in the sipping-outbound draft. One of the changes I am making in the next revision of gruu is to add some weasel words that open the door for a future spec to define a case where multiple contacts would be permitted. > At worst, it means that a request to the GRUU > forks, but then both sides of the fork (if they both get through) go to the > same device, which can select which of them it wishes to answer. And in > general, if one contact is to supercede another, the UA should be cancelling > the registration for the old contact, which will automatically remove it as > a contact for the GRUU. That was the initial design. The problem it had was a terrible amplification of avalanche restart load. If a bunch of clients restart due to a restoration of power after an outage, you have at least a doubleing of the number of registration transactions that need to be processed. In the initial design, where the registrar prohibited multiple registered contacts with the same instance ID, it took four transactions: 1. initial registration that fails 2. query registration to learn existing contacts 3. registration to remove the exsiting contact 4. registration to add the new one if you allow multiple contacts with the same instance ID to register, you can reduce that to two: 1. initial registration, response indicates multiple contacts with the same instance ID 2. second registration to remove the old one The avalanche restart was considered sufficiently nasty that it was worthwhile to have this enforcement about a single contact for a particular instance ID, which we'll relax somewhat with sipping-outbound, but all that does is add an additional parameter to the uniqueness key - the flow ID. Same basic idea though - you can only have one contact for a specific flowID/instanceID, and if you register a second one it actually clobbers the first. That behavior gets you the benefits of multiple contacts without the avalanche restart consequences. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 02:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPiR-0006NE-1z; Thu, 07 Jul 2005 02:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPiN-0006JO-TF for sip@megatron.ietf.org; Thu, 07 Jul 2005 02:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26891 for ; Thu, 7 Jul 2005 02:18:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQ9U-00068g-Ut for sip@ietf.org; Thu, 07 Jul 2005 02:46:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2005 23:18:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j676IDvM026288; Wed, 6 Jul 2005 23:18:13 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:18:16 -0400 Received: from [192.168.1.100] ([10.86.240.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:18:15 -0400 Message-ID: <42CCC927.9040306@cisco.com> Date: Thu, 07 Jul 2005 02:18:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <004e01c57671$10484180$6a01010a@keywest> In-Reply-To: <004e01c57671$10484180$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 06:18:15.0988 (UTC) FILETIME=[A93EAF40:01C582BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, Firstly, thanks for these most excellent and thoughtful comments. I'm going to respond to each party separately. Dale Worley wrote: > > * GRUUs when you don't have an AOR. > > There are times when a UA doesn't really represent a permanent entity, > and yet it would be useful for it to obtain a GRUU. (Consider a set > of UAs that form a distributed monitoring system.) The current system > makes obtaining a GRUU inherently part of registration as a contact > for an AOR. But as an extension, a registration agent could allow > registrations whose only effect is to create GRUUs, and not create > contact points for an AOR. > > A plausible mechanism for this operation is a registration whose To > address (normally the AOR to which the contact is to be registered) is > the same as the registration agent's request-URI, "sip:". > > A simplified example of such a registration and its response is: > > REGISTER sip:example.com SIP/2.0 > From: Callee ;tag=a73kszlfl > To: Callee > Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 > CSeq: 1 REGISTER > Supported: gruu > Contact: > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > > SIP/2.0 200 OK > From: Callee ;tag=a73kszlfl > To: Callee ;tag=b88sn > Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 > CSeq: 1 REGISTER > Contact: > ;gruu="sip:hha9s8d=-999a@example.com" > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > ;expires=3600 > > After that, the UA at "sip:callee@192.0.2.1" could be reached via > "sip:hha9s8d=-999a@example.com". I agree with Paul here that this seems of limited applicability. It would represent an additional feature of gruu, and as such I'd rather leave it out of scope. There are numerous ways to do this downstream if we should so desire. I'd suggest you write up an I-D on the specific motivations if you'd like to pursue it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 02:24:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPnq-0002Bn-9F; Thu, 07 Jul 2005 02:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPnn-0002Ba-Rt for sip@megatron.ietf.org; Thu, 07 Jul 2005 02:24:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01603 for ; Thu, 7 Jul 2005 02:23:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQEr-0007YF-Ky for sip@ietf.org; Thu, 07 Jul 2005 02:52:02 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2005 23:23:50 -0700 X-IronPort-AV: i="3.93,267,1115017200"; d="scan'208"; a="196829647:sNHT26856432" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j676Nk6p005861; Wed, 6 Jul 2005 23:23:47 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:23:46 -0400 Received: from [192.168.1.100] ([10.86.240.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 02:23:46 -0400 Message-ID: <42CCCA71.3080502@cisco.com> Date: Thu, 07 Jul 2005 02:23:45 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <005201c5773b$5fbced40$6a01010a@keywest> In-Reply-To: <005201c5773b$5fbced40$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 06:23:46.0453 (UTC) FILETIME=[6E37A450:01C582BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "'Sip \(E-mail\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dale Worley wrote: > >>>* Syntax of URNs >>> >>>The "sip.instance" parameter has a value which is a URN. However, a >>>number of examples in draft-ietf-sip-gruu-03 show the URN surrounded >>>with "<...>", which is not strictly valid. Though this would be >>>unlikely to cause functional problems in real implmentations, the >>>examples should be corrected: >> >>The <> is part of the syntax defined in 3840.3841 for callerprefs >>feature parameters. It indicates that the enclosed is a string rather >>than a list of tokens. > > > OK, thanks for explaining that. Looking at 3840, I guess I never realized > that the "feature predicates" it discusses were to be used for declaring the > features that a UA possesses, rather than what one would expect from the > name, a predicate *filtering* the features of some arbitrary UA. And > looking at the definition of "Contact Predicate" in section 3, I notice that > it does not really define what the contact predicate is a predicate *of*. > Has there been any clarification of that? The definitions are all lifted from RFC2533. The presence of the <>s has been a source of confusion in the gruu spec. They do need to be there. I've clarified the text in the spec to make it clear that this is the case. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 03:10:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQWg-0003r8-If; Thu, 07 Jul 2005 03:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQWW-0003n3-TM for sip@megatron.ietf.org; Thu, 07 Jul 2005 03:10:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05244 for ; Thu, 7 Jul 2005 03:10:15 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQxc-00006m-BD for sip@ietf.org; Thu, 07 Jul 2005 03:38:20 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3B5351019; Thu, 7 Jul 2005 09:10:00 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 09:09:59 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 09:09:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Thu, 7 Jul 2005 09:09:58 +0200 Message-ID: Thread-Topic: [Sip] INFO method used for ISUP to SIP IW Thread-Index: AcWCS3mdKaEIgGsbSNmuqWeJZ4wrLAAdscrQ From: "Christer Holmberg (JO/LMF)" To: "Drage, Keith (Keith)" , "GARCIN Sebastien RD-CORE-ISS" , "xupeili" , "Li, Bourne Bao (Bourne)" , "Sip (E-mail)" X-OriginalArrivalTime: 07 Jul 2005 07:09:58.0951 (UTC) FILETIME=[E2C14370:01C582C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >I hope you just mean that Q.1912.5 may provide additional=20 >guidance on how it is interworked. Yes. Q.1912.5 says that certain ISUP messages, in certain situations, = are encapsulated and carried in SIP 18x responses. >Q.1912.5 cannot change the INFO method and when it is used as=20 >the SIP changes RFC precludes that, and in any case, Q.1912.5=20 >is only an interworking specification, and interworking=20 >specifications cannot rewrite the base protocol. I don't think the Q.1912.5 changes the INFO method. The reason Q.1912.5 = says how ISUP messages are interworked, and in the case of SIP-I also = carried, in SIP messages. And, all that is of course based on what is = allowed from a SIP perspective. Regards, Christer LM Ericsson > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > GARCIN Sebastien RD-CORE-ISS > > Sent: 06 July 2005 14:08 > > To: xupeili; Li, Bourne Bao (Bourne); Sip (E-mail) > > Subject: RE: [Sip] INFO method used for ISUP to SIP IW > >=20 > >=20 > > Hi, > >=20 > > You should follow ITU-T recommendation Q.1912.5 in this respect. > >=20 > > Regards, > > =20 > >=20 > >=20 > > -----Message d'origine----- > > De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la=20 > > part de xupeili > > Envoy=E9 : mercredi 6 juillet 2005 04:11 > > =C0 : 'Li, Bourne Bao (Bourne)'; 'Sip (E-mail)' > > Objet : RE: [Sip] INFO method used for ISUP to SIP IW > >=20 > > INFO can be sent after early-dialog is established.=20 > > So that INR/INF should be encapsulated in INFO after early dialog. > >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of Li, Bourne Bao (Bourne) > > Sent: Wednesday, July 06, 2005 9:13 AM > > To: Sip (E-mail) > > Subject: [Sip] INFO method used for ISUP to SIP IW > >=20 > >=20 > >=20 > > I got one question of INFO method usage for ISUP to SIP IW.=20 > >=20 > > Per RFC 2976 said INFO is used to convey the mid-call=20 > > information between 2 UA without impacting the existing call=20 > > state, which may be used for ISUP to SIP IW. =20 > >=20 > > My question is can INFO method be sent before the dialog has=20 > > been established, or it is only allowed to be sent after a=20 > > confirmed dialog. > > Because some ISUP message such as INR/INF, will be sent=20 > > before ACM/ANM, which maps to SIP will establish the=20 > confirmed dialog. > >=20 > > Thanks, > > Bao > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 03:18:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQev-0003AI-Hr; Thu, 07 Jul 2005 03:18:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQes-00038y-9P for sip@megatron.ietf.org; Thu, 07 Jul 2005 03:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06022 for ; Thu, 7 Jul 2005 03:18:52 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqR60-0001iQ-R3 for sip@ietf.org; Thu, 07 Jul 2005 03:46:57 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A8DD3149F; Thu, 7 Jul 2005 09:17:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 09:17:46 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 09:17:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Thu, 7 Jul 2005 09:17:45 +0200 Message-ID: Thread-Topic: [Sip] INFO method used for ISUP to SIP IW Thread-Index: AcWCn/gMVk86GLwnQfenpxAv2jem8gAI06oQ From: "Christer Holmberg (JO/LMF)" To: "xupeili" , , , , , , X-OriginalArrivalTime: 07 Jul 2005 07:17:45.0554 (UTC) FILETIME=[F8DF3B20:01C582C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, No matter if, at the end of the day, it is allowed to send INFO backward = in an early dialog or not, Q.1912.5 currently says that 18x is used to = carry most ISUP messages in the backward direction during early dialogs. = Someone also mentioned forking. If you have SIP-I with forking there are = a number of of other issues to think about, so "INFO vs 18x" is probably = going to be the least of your problems :) Regards, Christer LM Ericsson > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > xupeili > Sent: 7. hein=E4kuuta 2005 5:55 > To: Mpierce1@aol.com; Christer Holmberg (JO/LMF); > sebastien.garcin@francetelecom.com; bbli@lucent.com; > dworley@pingtel.com; drage@lucent.com; sip@ietf.org > Subject: RE: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 > Hi, >=20 > Now there are 2 questions:=20 >=20 > (1) When can INFO be sent? Can it be sent from callee to caller? >=20 > At the time when RFC2976 is created, "early dialog" is not introduces. > Although RFC2976 said that it follows the rules for BYE.=20 > I guess the indended meaning is that it should follow the=20 > rules for messages > inside dialog such as BYE. > Since it can be used to carry end-to-end=20 > information(sometimes before dialog > is confirmed like UPDATE), there is no reason to prohibit it=20 > from being sent > by callee within dialog. >=20 > Where it can be sent before early dialog is an interesting=20 > question, It may > depend on the intent of the message.=20 > Considering the forking issure, if it carries the information=20 > which must be > sent to the designated recipient, it`s better to send in=20 > within a dialog. >=20 > In this case, my personal opinion is that early dialog should=20 > be established > as early as possible to make UPDATE or INFO possible to be delivered.=20 > even there is no explicit progress indicator for ringing or=20 > queing etc. >=20 > (2) for ISUP interworking where to encapsulate backword ISUP=20 > message like > INR? INFO or reliable 1xx? >=20 > If we agree that INFO can be sent in both direction. It may=20 > be sent either > in reliable 1xx or INFO.=20 >=20 > RFC3398 section 13.1 have some rule:=20 > "From the caller to the callee, other ISUP messages SHOULD be > encapsulated (see [3]) inside INFO messages, even if the INVITE > transaction is still not finished. " >=20 > "From the callee to the caller, if a message is received by a gateway > before the call has been answered (i.e., ANM is received) it SHOULD > be encapsulated in an INFO, provided that this will not be=20 > the first > SIP message sent in the backwards direction (in which case=20 > it SHOULD > be encapsulated in a provisional 1xx response). Similarly a message > which is received on the originating side (probably in=20 > response to an > INR) before a 200 OK has been received by the gateway should be > carried within an INFO. " >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Mpierce1@aol.com > Sent: Thursday, July 07, 2005 1:35 AM > To: christer.holmberg@ericsson.com;=20 > sebastien.garcin@francetelecom.com; > xupeili@huawei.com; bbli@lucent.com; sip@ietf.org > Subject: Re: [Sip] INFO method used for ISUP to SIP IW >=20 > In a message dated 7/6/2005 11:47:52 AM Eastern Daylight Time, > christer.holmberg@ericsson.com writes: >=20 >=20 >=20 > If I remember correctly, INFO follows the rules of BYE. And,=20 > a BYE cannot be > sent in the backword direction for an early dialog, I think. >=20 >=20 > RFC 2976 says that the INFO follows the rules for BYE as=20 > contained in RFC > 2543, which is now obsolete, so where does that leave us? RFC=20 > 2543 didn't > mention "early dialog". Can anyone say that RFC 3261 is=20 > exactly the same in > this area? >=20 > We've already seen at least three different opinions on this question. >=20 > Mike >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 03:35:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQuS-0000fK-Dc; Thu, 07 Jul 2005 03:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQuQ-0000dE-Jr for sip@megatron.ietf.org; Thu, 07 Jul 2005 03:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07371 for ; Thu, 7 Jul 2005 03:34:56 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqRLZ-0005YY-03 for sip@ietf.org; Thu, 07 Jul 2005 04:03:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2005 00:34:48 -0700 X-IronPort-AV: i="3.93,267,1115017200"; d="scan'208"; a="292664751:sNHT67161962" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j677Yjod022923; Thu, 7 Jul 2005 00:34:45 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 03:34:47 -0400 Received: from [192.168.1.100] ([10.86.240.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 03:34:46 -0400 Message-ID: <42CCDB16.3050909@cisco.com> Date: Thu, 07 Jul 2005 03:34:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] Some comments on GRUUs References: <004e01c57671$10484180$6a01010a@keywest> In-Reply-To: <004e01c57671$10484180$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 07:34:47.0015 (UTC) FILETIME=[59B5CF70:01C582C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: "Sip \(E-mail\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dale Worley wrote: > * Routing problem. > > Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem > that can result when a UA uses a GRUU as its target address. In the > worse case, shown in Figure 5 of the I-D, assume that a User Agent A > in domain "example.com" has established a dialog with User Agent B in > another domain. Furthermore, domain "example.com" has a home proxy HP > that maintains and interprets GRUUs in "example.com". But the home > proxy can only contact UA A via an edge proxy EP. > > Thus, when UA A established the dialog with UA B, the message flow > was: > > UA B <--- HP <--- EP <--- UA A > > Assuming that both HP and EP Record-Route themselves (EP must R-R > itself), at UA B the full routing (route-set plus target URI) is: > > > > > > (The domain names "hp.example.com" and "ep.example.com" are more > likely to be absolute IP addresses, but writing them symbolically > makes the example easier to understand.) > > When UA B sends an in-dialog request to UA A, EP is unable to use the > target URI to reach UA A and instead sends the request back to HP, the > server for the domain "example.com". HP resolves the GRUU to the > contact address, and forwards the request through EP to UA A. The > full flow is: > > UA B ---> HP ---> EP > | > +--------+ > | > v > HP ---> EP ---> UA A > > Fundamentally the problem is that the Contact header in UA A's request > that established the dialog is being overloaded with two distinct > purposes. On one hand, we want it to be a globally-valid URI for > contacting UA A, a GRUU. On the other hand, we want it to be the > final item in a list of addresses of waypoints for routing messages > within the dialog. But these two requirements are contradictory -- > because of NATing or AAA (authentication, authorization, accounting), > there may be no URI that is both gobally routable and usable for > direct access to the UA. > > There is a fairly simple solution to this: When establishing the > dialog, UA A needs to insert a Record-Route that provides its locally > usable contact address, so as to mask the GRUU that is its target URI. > Then, the full routing as seen by UA B is: > > > > > > > Then, when an in-dialog request from UA B reaches EP, it will have > "Route: ", "Route: ", > and a request-URI of "GRUU-A@example.com". EP recognizes > "ep.example.com" as one of its own addresses and deletes it. EP then > sends the request to the next Route address, "a.example.com", which is > a locally usable address. > > In accordance with normal processing rules, UA A recognizes > "a.example.com" as one of its addresses and removes the Route > containing it. It then recognizes the request-URI > "GRUU-A@example.com" as also being one of its addresses, and processes > the request. > > Clearly, this mechanism can be used simultaneously by both ends of a > dialog. > > For the benefit of external diagnostic agents, it may be worth > defining two URI-parameters, one to mark URIs that are GRUUs, and one > to mark route-set URIs that are the locally-usable addresses. For > example: > > > > > > > This mechanism does have the limitation that the true target URIs for > the dialog are no longer the stated contact URIs and cannot be changed > during the dialog by a re-INVITE. This is something I have considered off and on, not so much in the context of gruu, but for SIP processing in general, and that is whether or not the registered contact ought to have been populated by the proxy into a route rather than into the request URI, in which case the request URI would be the original AOR. A bunch of problems get solved if you do this. For example, the problem that motivated the development of P-Called-Party-ID in RFC 3455. As such, there is at the core here a fairly fundamental change to route/contact processing, and using gruu as a vehicle for introducing it. The main issue I ran into with this was the notion of domain ownership; it implied that mid-dialog requests would have a request URI that identified a target resource that is really owned by a proxy in the domain, yet the request is routed to, and terminates at, a UA that can really only claim ownership over its own IP address. This may seem like a theoretical problem, but it manifests itself in some of the real issues raised by Nils around invocation of services. Another issue is the one raised by Nils: Nils Ohlmeier wrote: > My concerns with such a solution are: > - how can the UA A determine its address a.example.com? Especially with NAT's > between the UA and the proxies this a big problem again, or? This is indeed a big problem. The solution proposed for this is in the sipping-outbound draft, which basically allows the gruu to get bound to a connection to the EP rather than to the IP address and port of the UA. This means that, in order to be reachable by the proxy, the address the proxy uses needs to be the gruu, and that leads us right back to square one. I suppose a fix for this is this. When the sipping-outbound mechanism is in use, a proxy will insert a Path header field value into the REGISTER that identifies the "connection" that the client registered through. This URI is used by the proxy for incoming requests to route them towards that client, more or less ignoring the request URI. Note that the Path values are returned to the client in the 200 OK to register. So, the client could use that Path value in its record-route value. That would solve the nat problem at least. However, one of the benefits that gruu brings to the table is that it adds a layer of indirection for mid-dialog request routing. If you have a session in progress and you end up re-registering, possibly to a different proxy, mid-dialog requests can still be delivered to you. This need arises for some of the mobility use cases, and for various failure cases where the client loses its connection to the server. If we put a client IP address or a connection URI (as learned from Path) into the record-route, we pin the mid-dialog requests to that specific IP address or connection, eliminating these benefits. That said, your suggestion is a simple way to solve an otherwise nasty problem. Indeed, you are absolutely correct that the gruu has really a split personality; its being used as a way to reach a specific UA instance for a mid-dialog request, but also as a way to reach a UA instance outside of a dialog. There are, unfortunately, differences in the types of features that a proxy might want to invoke on the request depending on whether its mid-dialog or an initial request, and that is a consequence of this split personality you point to. The net/net for me is that I think my original proposal, of just allowing the proxy to remove its record-route header field in the 200 OK, is really the simplest. There are a few ways the proxy can determine that it is safe to remove the record-route. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 05:52:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqT3c-0004Nd-Ko; Thu, 07 Jul 2005 05:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqT3a-0004NA-4F for sip@megatron.ietf.org; Thu, 07 Jul 2005 05:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17297 for ; Thu, 7 Jul 2005 05:52:31 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqTUi-0002rz-MQ for sip@ietf.org; Thu, 07 Jul 2005 06:20:38 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4DC324F0003; Thu, 7 Jul 2005 11:52:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 11:52:21 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 11:52:21 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] INFO method used for ISUP to SIP IW Date: Thu, 7 Jul 2005 11:52:21 +0200 Message-ID: Thread-Topic: [Sip] INFO method used for ISUP to SIP IW Thread-Index: AcWCn/gMVk86GLwnQfenpxAv2jem8gAI06oQAAFyETA= From: "Christer Holmberg (JO/LMF)" To: "xupeili" , , , , , , X-OriginalArrivalTime: 07 Jul 2005 09:52:21.0596 (UTC) FILETIME=[91D2E9C0:01C582D9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Also, if I remember correctly, this was in fact discussed on the = SIP/SIPPING list at the time when we were working on Q.1912.5., so I = assume that our understanding of the usage of INFO was verified at that = time. Regards, Christer LM Ericsson > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Christer Holmberg (JO/LMF) > Sent: 7. hein=E4kuuta 2005 10:18 > To: xupeili; Mpierce1@aol.com; sebastien.garcin@francetelecom.com; > bbli@lucent.com; dworley@pingtel.com; drage@lucent.com; sip@ietf.org > Subject: RE: [Sip] INFO method used for ISUP to SIP IW >=20 >=20 >=20 > Hi, >=20 > No matter if, at the end of the day, it is allowed to send=20 > INFO backward in an early dialog or not, Q.1912.5 currently=20 > says that 18x is used to carry most ISUP messages in the=20 > backward direction during early dialogs.=20 >=20 > Someone also mentioned forking. If you have SIP-I with=20 > forking there are a number of of other issues to think about,=20 > so "INFO vs 18x" is probably going to be the least of your problems :) >=20 > Regards, >=20 > Christer > LM Ericsson >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > xupeili > > Sent: 7. hein=E4kuuta 2005 5:55 > > To: Mpierce1@aol.com; Christer Holmberg (JO/LMF); > > sebastien.garcin@francetelecom.com; bbli@lucent.com; > > dworley@pingtel.com; drage@lucent.com; sip@ietf.org > > Subject: RE: [Sip] INFO method used for ISUP to SIP IW > >=20 > >=20 > > Hi, > >=20 > > Now there are 2 questions:=20 > >=20 > > (1) When can INFO be sent? Can it be sent from callee to caller? > >=20 > > At the time when RFC2976 is created, "early dialog" is not=20 > introduces. > > Although RFC2976 said that it follows the rules for BYE.=20 > > I guess the indended meaning is that it should follow the=20 > > rules for messages > > inside dialog such as BYE. > > Since it can be used to carry end-to-end=20 > > information(sometimes before dialog > > is confirmed like UPDATE), there is no reason to prohibit it=20 > > from being sent > > by callee within dialog. > >=20 > > Where it can be sent before early dialog is an interesting=20 > > question, It may > > depend on the intent of the message.=20 > > Considering the forking issure, if it carries the information=20 > > which must be > > sent to the designated recipient, it`s better to send in=20 > > within a dialog. > >=20 > > In this case, my personal opinion is that early dialog should=20 > > be established > > as early as possible to make UPDATE or INFO possible to be=20 > delivered.=20 > > even there is no explicit progress indicator for ringing or=20 > > queing etc. > >=20 > > (2) for ISUP interworking where to encapsulate backword ISUP=20 > > message like > > INR? INFO or reliable 1xx? > >=20 > > If we agree that INFO can be sent in both direction. It may=20 > > be sent either > > in reliable 1xx or INFO.=20 > >=20 > > RFC3398 section 13.1 have some rule:=20 > > "From the caller to the callee, other ISUP messages SHOULD be > > encapsulated (see [3]) inside INFO messages, even if the INVITE > > transaction is still not finished. " > >=20 > > "From the callee to the caller, if a message is received by=20 > a gateway > > before the call has been answered (i.e., ANM is=20 > received) it SHOULD > > be encapsulated in an INFO, provided that this will not be=20 > > the first > > SIP message sent in the backwards direction (in which case=20 > > it SHOULD > > be encapsulated in a provisional 1xx response).=20 > Similarly a message > > which is received on the originating side (probably in=20 > > response to an > > INR) before a 200 OK has been received by the gateway should be > > carried within an INFO. " > >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of > > Mpierce1@aol.com > > Sent: Thursday, July 07, 2005 1:35 AM > > To: christer.holmberg@ericsson.com;=20 > > sebastien.garcin@francetelecom.com; > > xupeili@huawei.com; bbli@lucent.com; sip@ietf.org > > Subject: Re: [Sip] INFO method used for ISUP to SIP IW > >=20 > > In a message dated 7/6/2005 11:47:52 AM Eastern Daylight Time, > > christer.holmberg@ericsson.com writes: > >=20 > >=20 > >=20 > > If I remember correctly, INFO follows the rules of BYE. And,=20 > > a BYE cannot be > > sent in the backword direction for an early dialog, I think. > >=20 > >=20 > > RFC 2976 says that the INFO follows the rules for BYE as=20 > > contained in RFC > > 2543, which is now obsolete, so where does that leave us? RFC=20 > > 2543 didn't > > mention "early dialog". Can anyone say that RFC 3261 is=20 > > exactly the same in > > this area? > >=20 > > We've already seen at least three different opinions on=20 > this question. > >=20 > > Mike > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 06:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqU6W-00049i-V4; Thu, 07 Jul 2005 06:59:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqU6V-00047b-7J for sip@megatron.ietf.org; Thu, 07 Jul 2005 06:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23070 for ; Thu, 7 Jul 2005 06:59:36 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUXe-0000Xl-QP for sip@ietf.org; Thu, 07 Jul 2005 07:27:44 -0400 Received: from [192.168.2.4] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j67B395l027358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2005 06:03:10 -0500 Message-ID: <42CD0B1A.3060408@softarmor.com> Date: Thu, 07 Jul 2005 05:59:38 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Orit Levin , Gonzalo Camarillo Subject: [Sip] draft-ietf-sip-refer-feature-param-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Are we ready to working group last call the refer with feature parameters draft? http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-00.txt -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 07:21:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqURT-00070Y-AA; Thu, 07 Jul 2005 07:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqURQ-000701-Qu for sip@megatron.ietf.org; Thu, 07 Jul 2005 07:21:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24994 for ; Thu, 7 Jul 2005 07:21:13 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUsa-000512-Ay for sip@ietf.org; Thu, 07 Jul 2005 07:49:21 -0400 Received: from [192.168.2.4] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j67BOk4T027549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2005 06:24:47 -0500 Message-ID: <42CD102B.6040703@softarmor.com> Date: Thu, 07 Jul 2005 06:21:15 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <015101c58174$904cd130$6a01010a@keywest> In-Reply-To: <015101c58174$904cd130$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: >But how to maintain the state that user foo@bar wants notification of X? In >practice this is often done by provisioning (foo goes to a web page to >update his list of notifications), because the overhead cost of having an >obsolete notification request in the database is small. But we might want >to use some variant of SUBSCRIBE to maintain notifications. > > I'd like to counter-propose a "subscription aggregator" -- that is, allow a single SUBSCRIBE request to establish a dialog upon which notifications for multiple event sources might occur. One might then define a metapackage that includes, for example, subscription to reg-event, mwi, config, presence resource-list, and all the other things that a UA might subscribe to on startup. Jonathan has proposed making REGISTER create a dialog for the servicing of subscriptions. I think an aggregator would be much cleaner. Now, as o how it might work -- the set of subscriptions to be aggregated should be defined dynamically. One idea would be to use the body of the SUBSCRIBE request to contain a URI list, with each such URI representing a resource to be SUBSCRIBEd to. This approach is consistent with the URI list work: see http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-03.txt Another approach would be to use a server-contained list that would be modified using XCAP. This is closer to the orignal resource-list work. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 08:57:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVx0-00068C-FB; Thu, 07 Jul 2005 08:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVwy-00064H-SM for sip@megatron.ietf.org; Thu, 07 Jul 2005 08:57:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02664 for ; Thu, 7 Jul 2005 08:57:55 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqWO9-0005qQ-AW for sip@ietf.org; Thu, 07 Jul 2005 09:26:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j67CvjCr028913; Thu, 7 Jul 2005 15:57:50 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 15:57:49 +0300 Received: from [192.168.1.185] ([10.162.252.139]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Jul 2005 15:57:49 +0300 Message-ID: <42CD26CB.6010208@nokia.com> Date: Thu, 07 Jul 2005 15:57:47 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Dale Worley Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <015101c58174$904cd130$6a01010a@keywest> In-Reply-To: <015101c58174$904cd130$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 12:57:49.0077 (UTC) FILETIME=[7A51C450:01C582F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Inline. ext Dale Worley wrote: >>From: Nasir Khan >> >>The vexing problem is the case where the subscriptions have >>an infinite life as in a few examples below. > > > Actually, what makes these cases vexing is the extremely low rate at which > notifications will be sent. One might expect that one could just do a > SUBSCRIBE with a very long expires time, but since NOTIFYs are sent within > the dialog established by SUBSCRIBE, when the UA changes its contact > address, the SUBSCRIBE has to be refreshed. Hence there is more traffic > maintaining the subscriptions than doing notifications. > > So we can characterize the problem as "notifications that are less frequent > than the UA changes its contact address". I agree this is a major deficiency in the SIP events framework. It is partly due to the fact that the SUBSCRIBE method is overloaded to do initial subscriptions, refreshes, as well as fetches within dialogs. Therefore, the notifier will always generate a NOTIFY upon receiving a SUBSCRIBE, even though the subscriber may already have that state and thus doesn't actually need it. I think there is a way to solve this, and I'm working on an I-D to lay out the problem and start the discussion on possible solutions. Hopefully will have it ready before Monday. ;) > Within this context, it seems like PUBLISH messages would be an acceptable > way to deliver the notification. PUBLISH can be sent to the user's AOR, and > SIP will route the update to the current UA. (A UA may also have to request > an explicit update when it starts up.) I don't see much benefit in this. Simply changing the method from a dialog creating one to a non-dialog-creating one doesn't solve the actual problem of being able to maintain subscriptions with little (or no) overhead. > But how to maintain the state that user foo@bar wants notification of X? In > practice this is often done by provisioning (foo goes to a web page to > update his list of notifications), because the overhead cost of having an > obsolete notification request in the database is small. But we might want > to use some variant of SUBSCRIBE to maintain notifications. Right. Cheers, Aki > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 09:41:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdE-00064p-0e; Thu, 07 Jul 2005 09:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWdC-00064e-N6 for sip@megatron.ietf.org; Thu, 07 Jul 2005 09:41:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07151 for ; Thu, 7 Jul 2005 09:41:32 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX4N-0008VW-F2 for sip@ietf.org; Thu, 07 Jul 2005 10:09:40 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id D7F9E6C02A for ; Thu, 7 Jul 2005 09:41:27 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Date: Thu, 7 Jul 2005 09:39:53 -0400 Message-ID: <003b01c582f9$5b5ff4d0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42CD26CB.6010208@nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > I agree this is a major deficiency in the SIP events framework. It is > partly due to the fact that the SUBSCRIBE method is overloaded to do > initial subscriptions, refreshes, as well as fetches within dialogs. > Therefore, the notifier will always generate a NOTIFY upon > receiving a > SUBSCRIBE, even though the subscriber may already have that state and > thus doesn't actually need it. More exactly, SUBSCRIBE is optimized for the situation where subscriptions are relatively short lived, and the state they receive changes quite frequently. The "dialog state" event package is the sort of thing SUBSCRIBE works well for. > I don't see much benefit in this. Simply changing the method from a > dialog creating one to a non-dialog-creating one doesn't solve the > actual problem of being able to maintain subscriptions with little (or > no) overhead. In terms of message traffic, replacing SUBSCRIBE with PUBLISH helps a great deal. Because SUBSCRIBE maintains a dialog, every time the UA's address changes, it has to refresh the subscription. With PUBLISH, those overhead messages are eliminated, at the cost of increased routing effort for every notification. In the end, there's no way to maintain a subscription without maintaining a record that the subscription exists. The protocol question is how to minimize the number of overhead messages. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 10:36:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXUc-0003Bi-Bk; Thu, 07 Jul 2005 10:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXUa-0003B6-06 for sip@megatron.ietf.org; Thu, 07 Jul 2005 10:36:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12792 for ; Thu, 7 Jul 2005 10:36:41 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqXvl-0003Cw-Iz for sip@ietf.org; Thu, 07 Jul 2005 11:04:50 -0400 Received: from Mpierce1@aol.com by imo-m27.mx.aol.com (mail_out_v38_r1.7.) id t.15.48319640 (4214); Thu, 7 Jul 2005 10:36:08 -0400 (EDT) Message-ID: <15.48319640.2ffe97d8@aol.com> Date: Thu, 7 Jul 2005 10:36:08 EDT Subject: Re: [Sip] INFO method used for ISUP to SIP IW To: christer.holmberg@ericsson.com, drage@lucent.com, sebastien.garcin@francetelecom.com, xupeili@huawei.com, bbli@lucent.com, sip@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Score: 0.7 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2144514571==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2144514571== Content-Type: multipart/alternative; boundary="part1_15.48319640.2ffe97d8_boundary" --part1_15.48319640.2ffe97d8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/7/2005 3:13:35 AM Eastern Daylight Time, christer.holmberg@ericsson.com writes: > Yes. Q.1912.5 says that certain ISUP messages, in certain situations, are > encapsulated and carried in SIP 18x responses. > Q.1912.5 doesn't say much about INFO at all. The only reference is explaining how "transparent" messages how encapsulated, and it says they are carried in the following: a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established. b) INFO message in all other cases. This means that INFO is only used after a confirmed dialog, not before, at least in the backward direction. Q.1912.5 doesn't really describe the use of INFO in the forward direction, but it must be allowed, since it lists ISUP messages like Facility Request and User-to-User Information that can go in that direction. Mike Pierce --part1_15.48319640.2ffe97d8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 7/7/2005 3:13:35 AM Eastern Daylight Time, christer.holmberg@eri= csson.com writes:


Yes. Q.1912.5 says that certain= ISUP messages, in certain situations, are encapsulated and carried in SIP 1= 8x responses.


Q.1912.5 doesn't say much about INFO at all. The only reference is explainin= g how "transparent" messages how encapsulated, and it says they are carried=20= in the following:

a) 183 Session Progress provisional response if this is sent by the I-IWU i= n the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

This means that INFO is only used after a confirmed dialog, not before, at l= east in the backward direction. Q.1912.5 doesn't really describe the use of=20= INFO in the forward direction, but it must be allowed, since it lists ISUP m= essages like Facility Request and User-to-User Information that can go in th= at direction.

Mike Pierce
 --part1_15.48319640.2ffe97d8_boundary-- --===============2144514571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2144514571==-- From sip-bounces@ietf.org Thu Jul 07 19:39:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqfy5-0000xh-K4; Thu, 07 Jul 2005 19:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqfy3-0000wf-ID for sip@megatron.ietf.org; Thu, 07 Jul 2005 19:39:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16127 for ; Thu, 7 Jul 2005 19:39:40 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqgPK-00071M-Vh for sip@ietf.org; Thu, 07 Jul 2005 20:07:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2005 16:39:34 -0700 X-IronPort-AV: i="3.93,271,1115017200"; d="scan'208"; a="293902797:sNHT89972036" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j67NdXvM028591; Thu, 7 Jul 2005 16:39:33 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 19:39:33 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.217.157]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 19:39:32 -0400 Message-Id: <4.3.2.7.2.20050707181851.03460008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jul 2005 18:39:31 -0500 To: "Elwell, John" From: "James M. Polk" In-Reply-To: <50B1CBA96870A34799A506B2313F266705C2E290@ntht201e.siemensc omms.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jul 2005 23:39:32.0873 (UTC) FILETIME=[205EC790:01C5834D] X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] Re: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John Sorry for hte late reply - I was on PTO. Comments below: At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: >James, Brian, > >In section 9 (special provisions for emergency calls) it states: > >"In the case where the Proxy knows the location of the UAC and does not >detect the UAC's location information message body in the message (or >determines the LO is bad), the Proxy generates a new 4XX (Retry Location >Body) error message that includes a location information message body for >that UAC to include in the subsequent message. The user agent MUST >include this message body in the subsequent emergency message." > >This places a new requirement on the UAC, yes it does >which will not be met by UACs that are not compliant to this document. Yes, this is true for all extensions >It seems emergency calls from such UACs will fail. Emergency calls only route to the appropriate PSAP based on the location of the caller. This will not change. SIP has no concept of physical location. If my current UA dials tel:911, where will the INVITE go to? 911 is good here in Dallas, Texas - just as it is good in New York City. There is no area code (ever) indicating where a 911 call is from or to. So how does the Proxy receiving this 911 as a Request-URI know how to route the message? The answer is in multiple steps: The INVITE first has to be identified as an emergency call - a Request-URI 911 will do this inside the US (112 works inside Europe), or Henning's proposed "sos@..." will do this in the future as it progresses. The second piece to this puzzle is providing the location of the UAC. This serves 2 purposes: 1) it provides the location of the UAC to now look for the appropriate PSAP in that geographic area (the ECRIT WG is working on defining that mapping protocol/means of a UAC's location to the appropriate PSAP Request-URI), and 2) Providing the lcoation in the INVITE to the PSAP will give the PSAP operator a location to dispatch first responders to. Without location in the INVITE, how are either of these functions accomplished? SIP currently cannot do either without an extension to the protocol. While adding a certain message body type isn't technically an extension, it is a change in behavior of a UAC and a Proxy/intermediary (to look for the location message body). Given the existing SIP rules stating message bodies cannot be added to a SIP message by a SIP Proxy Server, we're limited with what we can do. If the Proxy knows the location of the UAC, it has to have a means of informing the UAC of this location. There are several ways to do this - the one chosen here is a new 425 Response code (which is an extension to SIP) that includes a message body of the UAC's location to be used in the subsequent INVITE by the UAC. The user will not know of this initial rejection, and the UAC will need to know to send a new INVITE with this message body included. I could have put in a 3XX Response to do this, but chose not to. I don't understand Dave Oran's comment about adding a Supported header (Location) since this document doesn't allow a by-reference header. Does this answer your question? >Regards, > >John cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 20:20:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgbB-0001Le-Fy; Thu, 07 Jul 2005 20:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqgb8-0001Iw-Ok for sip@megatron.ietf.org; Thu, 07 Jul 2005 20:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18558 for ; Thu, 7 Jul 2005 20:20:05 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqh2Q-00023s-FI for sip@ietf.org; Thu, 07 Jul 2005 20:48:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2005 17:19:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,272,1115017200"; d="scan'208"; a="922798:sNHT25138744" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j680JvVu020797; Thu, 7 Jul 2005 20:19:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 20:19:47 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.217.157]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 20:19:56 -0400 Message-Id: <4.3.2.7.2.20050707183938.03b43610@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jul 2005 19:19:55 -0500 To: "PROUVOST Sebastien RD-CORE-ISS" , "Elwell, John" , From: "James M. Polk" Subject: RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2005 00:19:56.0280 (UTC) FILETIME=[C4D55780:01C58352] X-Spam-Score: 0.2 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sebastien At 11:45 AM 7/1/2005 +0200, PROUVOST Sebastien RD-CORE-ISS wrote: >Hi, > >I fully agree with John. I hope I just answered his concerns with the limitations of the existing=20 SIP architecture and emergency calling in the message I just sent to the=20 list. Let me address your questions directly here >The solution presented in the draft that says that if the UAC do not=20 >insert the location in the INVITE and if its outbound proxy has the info=20 >and wants to have it included it into the INVITE, it returns it in a 4xx=20 >"Retry Location Body" has several drawbacks : > >- What if the UAC issues the new INVITE that does not contains the=20 >location object I'll turn this one around on you: What if the only INVITE were received by= =20 the outbound proxy with no location included... where would that Proxy=20 route the message to? Because there is no realm or domain part of a emergency call today, there=20 is no place for SIP servers to look up where the UAC is or the destination= =20 UAS is to route the message to. The message will not go anywhere today. So= =20 we need an extension to SIP to accomplish this. This document is to address what needs to be done in SIP to convey=20 location. The ECRIT WG is chartered with how to take a well formed SIP=20 message (with location) and route it towards the appropriate PSAP. >(because it does not support this draft for example). If the call does not= =20 >go through, this is a very big issue when the call is an emergency call. I fully agree - yet I do not see another way of solving this issue other=20 than to have location in the INVITE. Let me explain this: If you want location to be in a header, the UAC doesn't have that=20 information unless it's told that information - or - the SIP proxy server=20 inserts this header in the INVITE message once it determines it is an=20 emergency call. This means the SIP Proxy always has to know where the UAC=20 is. That sounds like the SP is tracking the UAC. That enables tracking of=20 users through their UAs. Doesn't this have some privacy concerns? Do you want to be tracked everywhere you go for the one or two times in=20 your life you call 911 or 112? Further, what if I merely want to send my location to you in an IM. Do I=20 have to rely on a tracking SP to insert it into my MESSAGE Request message= =20 towards you in order for you to receive it from me? What if I use two different SPs: one for Voice and one for IM. Now I have=20 to have two SPs tracking me all the time because IM will be just as easy to= =20 use in the near future for emergency services as voice calling 911/112 is=20 today. Where does this additive SPs stop? How many SPs need to be able to=20 track me (through my UAC) to provide location conveyance services? This is= =20 every minute of every day, 7 days a week, 365 days a year, on every UAC you= =20 and I own. >As a service provider we cannot rely on the capacity of the UAC to allow=20 >emergency calls to go through. What if your UAC's have a GPS? Is this not the best means of determining=20 location of the UAC? Is this going to be forbidden? If it is not, then we=20 have to have a consistent means for allowing a GPS assisted UAC to convey=20 its location for whatever purpose, even emergencies. I believe you have a trust issue with the system. That's a separate issue -= =20 and a lot of folks have that belief. If the designed system isn't good=20 enough, design a better system. >- What if the UAC issues a new INVITE that contains the location object=20 >but that does not correspond to the one the proxy gave. Then that is not a well behaving UAC. Folks that call for emergency want to= =20 get help. If their UAC fails on them, it fails. What if I have an emergency= =20 today and my existing GSM phone fails for whatever reason? It also fails.=20 I'm in just as much trouble. We need to build the best products for each=20 situation, but the IETF isn't defining products themselves, it's defining=20 protocols and triggers within protocols to provide features/functions. >- This solution introduces a supplementary exchange between the UA and its= =20 >proxy which introduces an additional delay to the call establishement=20 >(especially important if the UA is over a radio access). how much more delay do you expect this single exchange to cause? It's one=20 round trip between one application layer hop - it's not that much time.=20 But, do you have a figure in mind that makes this undesireable? >If the draft stays as it is, this is one more reason why service providers= =20 >would need an SBC and this isn't going to inject any delays? huh? > : in order to be able to insert location information to an INVITE=20 > request without requiring any UA intervention. this will require the SBC to be completely stateful as to where EVERY UAC=20 is at all times just in case a UAC calls for an emergency. That means every= =20 second of every day for the life of that UAC, and every other UAC within=20 that realm. Do you believe that will scale? Do you believe that will not cause delay in the look-up of where a=20 particular UAC is in a location database? Does the SBC have this database local for all UACs that it could receive a= =20 911/112 INVITE from, or is this datebase more centralized within the SP= realm? How many SBCs are you expecting per realm? How current is the database of UAC locations among all SBCs? I'm having a hard time believing an SBC inserting location into the INVITE= =20 will increase efficiency. I think getting location down into the UAC is the= =20 most efficient means of location conveyance - especially for emergency= calling. >It is necessary for a proxy to be able to insert this location info=20 >without having to rely on the UA's intervention. Why is it necessary? >Sebastien. > > >---------- >De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de=20 >Elwell, John >Envoy=E9 : mercredi 29 juin 2005 11:19 >=C0 : jmpolk@cisco.com; br@brianrosen.net >Cc : sip@ietf.org >Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00 > >James, Brian, > >In section 9 (special provisions for emergency calls) it states: > >"In the case where the Proxy knows the location of the UAC and does not=20 >detect the UAC's location information message body in the message (or=20 >determines the LO is bad), the Proxy generates a new 4XX (Retry Location=20 >Body) error message that includes a location information message body for= =20 >that UAC to include in the subsequent message. The user agent MUST=20 >include this message body in the subsequent emergency message." > >This places a new requirement on the UAC, which will not be met by UACs=20 >that are not compliant to this document. It seems emergency calls from=20 >such UACs will fail. > >Regards, > >John cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 07 22:20:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqiU2-0003iE-3V; Thu, 07 Jul 2005 22:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqiTy-0003dz-Sy for sip@megatron.ietf.org; Thu, 07 Jul 2005 22:20:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26466 for ; Thu, 7 Jul 2005 22:20:48 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqivD-0005Bu-9E for sip@ietf.org; Thu, 07 Jul 2005 22:49:04 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJA00EMZEN52W@szxga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jul 2005 10:23:30 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJA00BPUEN5RU@szxga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jul 2005 10:23:29 +0800 (CST) Received: from GUEST ([10.76.176.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJA00HO0EU92G@szxml01-in.huawei.com>; Fri, 08 Jul 2005 10:27:45 +0800 (CST) Date: Fri, 08 Jul 2005 10:19:17 +0800 From: xupeili Subject: RE: [Sip] INFO method used for ISUP to SIP IW In-reply-to: <15.48319640.2ffe97d8@aol.com> To: Mpierce1@aol.com, christer.holmberg@ericsson.com, drage@lucent.com, sebastien.garcin@francetelecom.com, bbli@lucent.com, sip@ietf.org Message-id: <000001c58363$71455fa0$5fb04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167407074==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1167407074== Content-type: multipart/alternative; boundary="Boundary_(ID_dVXmXwtrRmm0hvVwSlRrbw)" This is a multi-part message in MIME format. --Boundary_(ID_dVXmXwtrRmm0hvVwSlRrbw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, This is my understanding of Q.1912.5 principle : Q.1912.5 will not re-define the general principle of when INFO can be sent. This should be under the IETF SIP umbrella. As our discussion these days, INFO should be sent in both direction after dialog(including early and confirm state ) is established. Q.1912.5 does have rule on how, when and where to encapsulate ISUP message under the SIP principle. Q.1912.5 just recommend that It is better to facilitate 18x to encapsulate backward ISUP messages before dialog is confirmed. All other case may include (1) forward ISUP messages before dialog is confirmed ,(2) other forward or backward messages after dialog is confirmed. Just as chister mentioned: the final issue may go to whether to encapsulate backword ISUP message befor dialog is confirmed in 1xx or INFO. For those messages with match meaning (180-ACM/CPG, 183-ACM/CPG) , the rule is clearly defined in Q.1912.5. For those ISUP message just need transparently sent and without meaning-matching messages in SIP like INF/INR. 18x and INFO may both suitable. From the implementation point of view, it`s better for SIP-ISUP IWU to support both. Best reguards! Peili Xu -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mpierce1@aol.com Sent: Thursday, July 07, 2005 10:36 PM To: christer.holmberg@ericsson.com; drage@lucent.com; sebastien.garcin@francetelecom.com; xupeili@huawei.com; bbli@lucent.com; sip@ietf.org Subject: Re: [Sip] INFO method used for ISUP to SIP IW In a message dated 7/7/2005 3:13:35 AM Eastern Daylight Time, christer.holmberg@ericsson.com writes: Yes. Q.1912.5 says that certain ISUP messages, in certain situations, are encapsulated and carried in SIP 18x responses. Q.1912.5 doesn't say much about INFO at all. The only reference is explaining how "transparent" messages how encapsulated, and it says they are carried in the following: a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established. b) INFO message in all other cases. This means that INFO is only used after a confirmed dialog, not before, at least in the backward direction. Q.1912.5 doesn't really describe the use of INFO in the forward direction, but it must be allowed, since it lists ISUP messages like Facility Request and User-to-User Information that can go in that direction. Mike Pierce --Boundary_(ID_dVXmXwtrRmm0hvVwSlRrbw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=A0=A0=A0=A0=A0=A0= =A0=A0=A0Hi,

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 This is my understanding of Q.1912.5 principle :

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Q.1912.5 will not re-define the general principle of when INFO can be sent. This = should be under the IETF SIP umbrella.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 As our discussion these days, INFO should be sent in both direction after = dialog(including early and confirm state ) is established.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Q.1912.5 does have rule on how, when and where to encapsulate ISUP message under = the SIP principle.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Q.1912.5 just recommend that It is better to facilitate 18x to encapsulate = backward ISUP messages before dialog is confirmed. =A0=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 All other case may include =A0(1) forward ISUP messages before dialog is confirmed = =A0,(2) other forward or backward messages after dialog is = confirmed.

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Just as chister mentioned: the final issue may go to whether to encapsulate backword = ISUP message befor dialog is confirmed in 1xx or INFO.

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 For those messages with match meaning (180-ACM/CPG, 183-ACM/CPG) , the rule is = clearly defined in Q.1912.5.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 For those ISUP message just need transparently sent and without meaning-matching = messages in SIP like INF/INR.

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 18x and INFO may both suitable. =A0From the implementation point of view, it`s = better for SIP-ISUP IWU to support both.

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Best reguards!

 

=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Peili Xu

 

-----Original Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Mpierce1@aol.com
Sent: Thursday, July 07, 2005 10:36 PM
To: christer.holmberg@ericsson.= com; drage@lucent.com; = sebastien.garcin@francetele= com.com; xupeili@huawei.com; bbli@lucent.com; sip@ietf.org
Subject: Re: [Sip] INFO = method used for ISUP to SIP IW

 

In a message = dated 7/7/2005 3:13:35 AM Eastern Daylight Time, christer.holmberg@ericsson.c= om writes:



Yes. Q.1912.5 = says that certain ISUP messages, in certain situations, are encapsulated and = carried in SIP 18x responses.



Q.1912.5 doesn't say much about INFO at all. The only reference is = explaining how "transparent" messages how encapsulated, and it says they = are carried in the following:

a) 183 Session Progress provisional response if this is sent by the = I-IWU in the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

This means that INFO is only used after a confirmed dialog, not before, = at least in the backward direction. Q.1912.5 doesn't really describe the = use of INFO in the forward direction, but it must be allowed, since it lists = ISUP messages like Facility Request and User-to-User Information that can go = in that direction.

Mike Pierce

--Boundary_(ID_dVXmXwtrRmm0hvVwSlRrbw)-- --===============1167407074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1167407074==-- From sip-bounces@ietf.org Fri Jul 08 04:45:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqoU9-00048l-VR; Fri, 08 Jul 2005 04:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqoU7-00046N-Ko for sip@megatron.ietf.org; Fri, 08 Jul 2005 04:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10993 for ; Fri, 8 Jul 2005 04:45:21 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqovR-00085d-JA for sip@ietf.org; Fri, 08 Jul 2005 05:13:40 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IJA00C01W73YY@siemenscomms.co.uk> for sip@ietf.org; Fri, 08 Jul 2005 09:42:39 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IJA00C6CW73DC@siemenscomms.co.uk>; Fri, 08 Jul 2005 09:42:39 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 08 Jul 2005 09:44:57 +0100 Content-return: allowed Date: Fri, 08 Jul 2005 09:44:55 +0100 From: "Elwell, John" To: "James M. Polk" Message-id: <50B1CBA96870A34799A506B2313F266705D49583@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, (Replying also to your message to Sebastien) I agree that in many environments the UAC will be the best or only place to supply location information, in which case obviously one will need a UA enhanced with the ability to provide location information when making an emergency call. However, there will be some environments (notably enterprise environments) where the proxy has knowledge of UA location. Sending back a 4xx will work fine if the UA supports this. However, the ability for the proxy to add location information (in a header) when forwarding the request would be useful in order to support existing UAs that do not have this enhancement. John > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: 08 July 2005 00:40 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > John > > Sorry for hte late reply - I was on PTO. Comments below: > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > >James, Brian, > > > >In section 9 (special provisions for emergency calls) it states: > > > >"In the case where the Proxy knows the location of the UAC > and does not > >detect the UAC's location information message body in the > message (or > >determines the LO is bad), the Proxy generates a new 4XX > (Retry Location > >Body) error message that includes a location information > message body for > >that UAC to include in the subsequent message. The user agent MUST > >include this message body in the subsequent emergency message." > > > >This places a new requirement on the UAC, > > yes it does > > >which will not be met by UACs that are not compliant to this > document. > > Yes, this is true for all extensions > > >It seems emergency calls from such UACs will fail. > > Emergency calls only route to the appropriate PSAP based on > the location of > the caller. This will not change. SIP has no concept of > physical location. > If my current UA dials tel:911, where will the INVITE go to? > 911 is good > here in Dallas, Texas - just as it is good in New York City. > There is no > area code (ever) indicating where a 911 call is from or to. > So how does the > Proxy receiving this 911 as a Request-URI know how to route > the message? > The answer is in multiple steps: > > The INVITE first has to be identified as an emergency call - > a Request-URI > 911 will do this inside the US (112 works inside Europe), or > Henning's > proposed "sos@..." will do this in the future as it progresses. > > The second piece to this puzzle is providing the location of > the UAC. This > serves 2 purposes: > > 1) it provides the location of the UAC to now look for the > appropriate PSAP > in that geographic area (the ECRIT WG is working on defining > that mapping > protocol/means of a UAC's location to the appropriate PSAP > Request-URI), and > > 2) Providing the lcoation in the INVITE to the PSAP will give > the PSAP > operator a location to dispatch first responders to. > > Without location in the INVITE, how are either of these > functions accomplished? > > SIP currently cannot do either without an extension to the protocol. > > While adding a certain message body type isn't technically an > extension, it > is a change in behavior of a UAC and a Proxy/intermediary (to > look for the > location message body). > > Given the existing SIP rules stating message bodies cannot be > added to a > SIP message by a SIP Proxy Server, we're limited with what we can do. > > If the Proxy knows the location of the UAC, it has to have a means of > informing the UAC of this location. There are several ways to > do this - the > one chosen here is a new 425 Response code (which is an > extension to SIP) > that includes a message body of the UAC's location to be used in the > subsequent INVITE by the UAC. The user will not know of this initial > rejection, and the UAC will need to know to send a new INVITE > with this > message body included. > > I could have put in a 3XX Response to do this, but chose not to. > > I don't understand Dave Oran's comment about adding a > Supported header > (Location) since this document doesn't allow a by-reference header. > > Does this answer your question? > > > >Regards, > > > >John > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 05:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqovR-0002i8-Rd; Fri, 08 Jul 2005 05:13:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqovP-0002i3-Sr for sip@megatron.ietf.org; Fri, 08 Jul 2005 05:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12852 for ; Fri, 8 Jul 2005 05:13:33 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqpMm-0002hc-0d for sip@ietf.org; Fri, 08 Jul 2005 05:41:52 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 11:12:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00 Date: Fri, 8 Jul 2005 11:12:10 +0200 Message-ID: <49E7012A614B024B80A7D175CB9A64EC0556FD61@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00 Thread-Index: AcWDUvBUQvH7O/RoRH2oliqj0MWotAASBc0w From: "GARCIN Sebastien RD-CORE-ISS" To: "James M. Polk" , "PROUVOST Sebastien RD-CORE-ISS" , "Elwell, John" , X-OriginalArrivalTime: 08 Jul 2005 09:12:11.0723 (UTC) FILETIME=[1FD739B0:01C5839D] X-Spam-Score: 0.2 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, Fist, s=E9bastien wasn't arguing against the need for an extension in = the INVITE, we fully support this. The problem is that network operators = have one very important goal: - the need to support a large range of terminals, not only complex ones = and this requirement is even stronger when dealing with emergency calls. = The solution proposed here might have some benefits for certain = situations, but it would be a pity not to come up with a solution that = doesnot require any specific terminal functionnality and would most = likely cause non-standardized solution to be used. S=E9bastien G. -----Message d'origine----- De : James M. Polk [mailto:jmpolk@cisco.com]=20 Envoy=E9 : vendredi 8 juillet 2005 02:20 =C0 : PROUVOST Sebastien RD-CORE-ISS; Elwell, John; br@brianrosen.net Cc : sip@ietf.org; GARCIN Sebastien RD-CORE-ISS Objet : RE: [Sip] Second Comment on = draft-ietf-sip-location-conveyance-00 Sebastien At 11:45 AM 7/1/2005 +0200, PROUVOST Sebastien RD-CORE-ISS wrote: >Hi, > >I fully agree with John. I hope I just answered his concerns with the limitations of the existing = SIP architecture and emergency calling in the message I just sent to the = list. Let me address your questions directly here >The solution presented in the draft that says that if the UAC do not=20 >insert the location in the INVITE and if its outbound proxy has the=20 >info and wants to have it included it into the INVITE, it returns it in = >a 4xx "Retry Location Body" has several drawbacks : > >- What if the UAC issues the new INVITE that does not contains the=20 >location object I'll turn this one around on you: What if the only INVITE were received = by the outbound proxy with no location included... where would that = Proxy route the message to? Because there is no realm or domain part of a emergency call today, = there is no place for SIP servers to look up where the UAC is or the = destination UAS is to route the message to. The message will not go = anywhere today. So we need an extension to SIP to accomplish this. This document is to address what needs to be done in SIP to convey = location. The ECRIT WG is chartered with how to take a well formed SIP = message (with location) and route it towards the appropriate PSAP. >(because it does not support this draft for example). If the call does=20 >not go through, this is a very big issue when the call is an emergency = call. I fully agree - yet I do not see another way of solving this issue other = than to have location in the INVITE. Let me explain this: If you want location to be in a header, the UAC doesn't have that = information unless it's told that information - or - the SIP proxy = server inserts this header in the INVITE message once it determines it = is an emergency call. This means the SIP Proxy always has to know where = the UAC is. That sounds like the SP is tracking the UAC. That enables = tracking of users through their UAs. Doesn't this have some privacy concerns? Do you want to be tracked everywhere you go for the one or two times in = your life you call 911 or 112? Further, what if I merely want to send my location to you in an IM. Do I = have to rely on a tracking SP to insert it into my MESSAGE Request = message towards you in order for you to receive it from me? What if I use two different SPs: one for Voice and one for IM. Now I = have to have two SPs tracking me all the time because IM will be just as = easy to use in the near future for emergency services as voice calling = 911/112 is today. Where does this additive SPs stop? How many SPs need = to be able to track me (through my UAC) to provide location conveyance = services? This is every minute of every day, 7 days a week, 365 days a = year, on every UAC you and I own. >As a service provider we cannot rely on the capacity of the UAC to=20 >allow emergency calls to go through. What if your UAC's have a GPS? Is this not the best means of determining = location of the UAC? Is this going to be forbidden? If it is not, then = we have to have a consistent means for allowing a GPS assisted UAC to = convey its location for whatever purpose, even emergencies. I believe you have a trust issue with the system. That's a separate = issue - and a lot of folks have that belief. If the designed system = isn't good enough, design a better system. >- What if the UAC issues a new INVITE that contains the location object = >but that does not correspond to the one the proxy gave. Then that is not a well behaving UAC. Folks that call for emergency want = to get help. If their UAC fails on them, it fails. What if I have an = emergency today and my existing GSM phone fails for whatever reason? It = also fails.=20 I'm in just as much trouble. We need to build the best products for each = situation, but the IETF isn't defining products themselves, it's = defining protocols and triggers within protocols to provide = features/functions. >- This solution introduces a supplementary exchange between the UA and=20 >its proxy which introduces an additional delay to the call=20 >establishement (especially important if the UA is over a radio access). how much more delay do you expect this single exchange to cause? It's = one round trip between one application layer hop - it's not that much = time.=20 But, do you have a figure in mind that makes this undesireable? >If the draft stays as it is, this is one more reason why service = providers=20 >would need an SBC and this isn't going to inject any delays? huh? > : in order to be able to insert location information to an INVITE=20 > request without requiring any UA intervention. this will require the SBC to be completely stateful as to where EVERY = UAC=20 is at all times just in case a UAC calls for an emergency. That means = every=20 second of every day for the life of that UAC, and every other UAC within = that realm. Do you believe that will scale? Do you believe that will not cause delay in the look-up of where a=20 particular UAC is in a location database? Does the SBC have this database local for all UACs that it could receive = a=20 911/112 INVITE from, or is this datebase more centralized within the SP = realm? How many SBCs are you expecting per realm? How current is the database of UAC locations among all SBCs? I'm having a hard time believing an SBC inserting location into the = INVITE=20 will increase efficiency. I think getting location down into the UAC is = the=20 most efficient means of location conveyance - especially for emergency = calling. >It is necessary for a proxy to be able to insert this location info=20 >without having to rely on the UA's intervention. Why is it necessary? >Sebastien. > > >---------- >De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de=20 >Elwell, John >Envoy=E9 : mercredi 29 juin 2005 11:19 >=C0 : jmpolk@cisco.com; br@brianrosen.net >Cc : sip@ietf.org >Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00 > >James, Brian, > >In section 9 (special provisions for emergency calls) it states: > >"In the case where the Proxy knows the location of the UAC and does not = >detect the UAC's location information message body in the message (or=20 >determines the LO is bad), the Proxy generates a new 4XX (Retry = Location=20 >Body) error message that includes a location information message body = for=20 >that UAC to include in the subsequent message. The user agent MUST=20 >include this message body in the subsequent emergency message." > >This places a new requirement on the UAC, which will not be met by UACs = >that are not compliant to this document. It seems emergency calls from=20 >such UACs will fail. > >Regards, > >John cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 14:40:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqxm8-0001RZ-FA; Fri, 08 Jul 2005 14:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqxm5-0001RU-SR for sip@megatron.ietf.org; Fri, 08 Jul 2005 14:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05137 for ; Fri, 8 Jul 2005 14:40:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqyDU-0001RE-Hp for sip@ietf.org; Fri, 08 Jul 2005 15:08:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2005 11:40:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j68Ie9vq006932; Fri, 8 Jul 2005 11:40:16 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 11:40:18 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.206]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 11:40:17 -0700 Message-Id: <4.3.2.7.2.20050708132249.03ba4678@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jul 2005 13:40:16 -0500 To: "Elwell, John" From: "James M. Polk" In-Reply-To: <50B1CBA96870A34799A506B2313F266705D49583@ntht201e.siemensc omms.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jul 2005 18:40:17.0689 (UTC) FILETIME=[7CA8E090:01C583EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John At 09:44 AM 7/8/2005 +0100, Elwell, John wrote: >James, > >(Replying also to your message to Sebastien) >I agree that in many environments the UAC will be the best or only place to >supply location information, in which case obviously one will need a UA >enhanced with the ability to provide location information when making an >emergency call. > >However, there will be some environments (notably enterprise environments) >where the proxy has knowledge of UA location. Sending back a 4xx will work >fine if the UA supports this. However, the ability for the proxy to add >location information (in a header) when forwarding the request would be >useful in order to support existing UAs that do not have this enhancement. Ok, but can you solve this in a header: - the Geopriv WG was chartered with mandating security and privacy of a endsystem's location information (RFC3963) - based on the rules established by a "rulemaker" (which can be the enduser, the domain administrator or the combination), and I do not know how this can be accomplished if location is shown in a header inserted without the user's knowledge or control. SIP message headers are TLS or IPsec hop-by-hop encrypted at best (right?), and may not be encrypted at all even one hop away from the UAC, so how is the user's privacy concerns about their location information not being divulged addressed? This is accomplished if location were placed in a message body - which cannot be added in transit by a Proxy. This draft provides a means for a Proxy to say "hey, you need a location body in that message, here, use in your subsequent message". This is the 425 (Retry Location Body) Response I have in the doc. To give some history, I orignially had location in a new header, but was told it had to be moved to the body by the WG, the chairs and the ADs (at Vienna). This was based on Geopriv guidelines. So, I'm not necessarily disagreeing with you that there may be cases in a header is better than in a body, but I don't know how to *not* violate the specifics or spirit of what Geopriv is doing. RFC3963 is pretty clear that privacy concerns need to always be taken into account when identity is conveyed. Any suggestions? >John > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 08 July 2005 00:40 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > > > John > > > > Sorry for hte late reply - I was on PTO. Comments below: > > > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > > > >James, Brian, > > > > > >In section 9 (special provisions for emergency calls) it states: > > > > > >"In the case where the Proxy knows the location of the UAC > > and does not > > >detect the UAC's location information message body in the > > message (or > > >determines the LO is bad), the Proxy generates a new 4XX > > (Retry Location > > >Body) error message that includes a location information > > message body for > > >that UAC to include in the subsequent message. The user agent MUST > > >include this message body in the subsequent emergency message." > > > > > >This places a new requirement on the UAC, > > > > yes it does > > > > >which will not be met by UACs that are not compliant to this > > document. > > > > Yes, this is true for all extensions > > > > >It seems emergency calls from such UACs will fail. > > > > Emergency calls only route to the appropriate PSAP based on > > the location of > > the caller. This will not change. SIP has no concept of > > physical location. > > If my current UA dials tel:911, where will the INVITE go to? > > 911 is good > > here in Dallas, Texas - just as it is good in New York City. > > There is no > > area code (ever) indicating where a 911 call is from or to. > > So how does the > > Proxy receiving this 911 as a Request-URI know how to route > > the message? > > The answer is in multiple steps: > > > > The INVITE first has to be identified as an emergency call - > > a Request-URI > > 911 will do this inside the US (112 works inside Europe), or > > Henning's > > proposed "sos@..." will do this in the future as it progresses. > > > > The second piece to this puzzle is providing the location of > > the UAC. This > > serves 2 purposes: > > > > 1) it provides the location of the UAC to now look for the > > appropriate PSAP > > in that geographic area (the ECRIT WG is working on defining > > that mapping > > protocol/means of a UAC's location to the appropriate PSAP > > Request-URI), and > > > > 2) Providing the lcoation in the INVITE to the PSAP will give > > the PSAP > > operator a location to dispatch first responders to. > > > > Without location in the INVITE, how are either of these > > functions accomplished? > > > > SIP currently cannot do either without an extension to the protocol. > > > > While adding a certain message body type isn't technically an > > extension, it > > is a change in behavior of a UAC and a Proxy/intermediary (to > > look for the > > location message body). > > > > Given the existing SIP rules stating message bodies cannot be > > added to a > > SIP message by a SIP Proxy Server, we're limited with what we can do. > > > > If the Proxy knows the location of the UAC, it has to have a means of > > informing the UAC of this location. There are several ways to > > do this - the > > one chosen here is a new 425 Response code (which is an > > extension to SIP) > > that includes a message body of the UAC's location to be used in the > > subsequent INVITE by the UAC. The user will not know of this initial > > rejection, and the UAC will need to know to send a new INVITE > > with this > > message body included. > > > > I could have put in a 3XX Response to do this, but chose not to. > > > > I don't understand Dave Oran's comment about adding a > > Supported header > > (Location) since this document doesn't allow a by-reference header. > > > > Does this answer your question? > > > > > > >Regards, > > > > > >John > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented. > > cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 14:51:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqxwn-0007NP-Pv; Fri, 08 Jul 2005 14:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqxwl-0007L5-IB for sip@megatron.ietf.org; Fri, 08 Jul 2005 14:51:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06070 for ; Fri, 8 Jul 2005 14:51:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqyOA-0001t7-IQ for sip@ietf.org; Fri, 08 Jul 2005 15:19:57 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2005 11:51:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,274,1115017200"; d="scan'208"; a="1036750:sNHT21920784" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j68IpLk6011576; Fri, 8 Jul 2005 14:51:21 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 14:51:26 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 14:51:21 -0400 Message-ID: <42CECB29.4040404@cisco.com> Date: Fri, 08 Jul 2005 14:51:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <015101c58174$904cd130$6a01010a@keywest> <42CD102B.6040703@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2005 18:51:21.0127 (UTC) FILETIME=[08197B70:01C583EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Dale Worley wrote: > >> But how to maintain the state that user foo@bar wants notification of >> X? In >> practice this is often done by provisioning (foo goes to a web page to >> update his list of notifications), because the overhead cost of having an >> obsolete notification request in the database is small. But we might >> want >> to use some variant of SUBSCRIBE to maintain notifications. >> >> > I'd like to counter-propose a "subscription aggregator" -- that is, > allow a single SUBSCRIBE request to establish a dialog upon which > notifications for multiple event > sources might occur. Whether this is useful depends on your goals. THis is a little like an RLS on steroids. Like an RLS, it does not in general reduce the total amount of work done in the system as a whole - instead it moves the place where some of the work is done and also somewhat increases the total amount of work done. It reduces the amount of work that must be done by the watchers. It does nothing to the amount of work that must be done by the notifiers. And it increases the amount of work that must be done by the "subscription aggregator". (From nothing to somewhat more than the total of what would otherwise have been done by the watchers.) But I think one of the goals here is to reduce the load on the servers. > One might then define a metapackage that includes, for example, > subscription to reg-event, mwi, config, presence resource-list, and all > the other things that a UA might subscribe to on startup. I thing this would require defining a new event type ('multiple-events'?), together with the content type used by it. The content type would have to be able to embed the notification content for any of the aggregated event types. Not rocket science - definitely could be done. > Jonathan has proposed making REGISTER create a dialog for the servicing > of subscriptions. I think an aggregator would be much cleaner. I agree it is "cleaner" in the sense that it doesn't change the semantics of anything currently existing. But we will have to agree on what our goals are before we can decide what is "better". Paul > Now, as o how it might work -- the set of subscriptions to be aggregated > should be defined dynamically. One idea would be to use the body of the > SUBSCRIBE request to contain a URI list, with each such URI representing > a resource to be SUBSCRIBEd to. This approach is consistent with the URI > list work: > see > http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-03.txt > > > Another approach would be to use a server-contained list that would be > modified using XCAP. This is closer to the orignal resource-list work. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 15:13:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyII-0000vs-Hn; Fri, 08 Jul 2005 15:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyIE-0000vn-CW for sip@megatron.ietf.org; Fri, 08 Jul 2005 15:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08314 for ; Fri, 8 Jul 2005 15:13:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqyjf-0002k1-8M for sip@ietf.org; Fri, 08 Jul 2005 15:42:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2005 12:13:35 -0700 X-IronPort-AV: i="3.93,274,1115017200"; d="scan'208"; a="647749090:sNHT36962356" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j68JD9Vt025126; Fri, 8 Jul 2005 12:13:32 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 12:13:26 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 12:13:24 -0700 Message-Id: <4.3.2.7.2.20050708135004.03c485f0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jul 2005 14:13:02 -0500 To: "GARCIN Sebastien RD-CORE-ISS" , "PROUVOST Sebastien RD-CORE-ISS" , "Elwell, John" From: "James M. Polk" Subject: RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00 In-Reply-To: <49E7012A614B024B80A7D175CB9A64EC0556FD61@ftrdmel1.rd.franc etelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2005 19:13:25.0160 (UTC) FILETIME=[1D48E280:01C583F1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 11:12 AM 7/8/2005 +0200, GARCIN Sebastien RD-CORE-ISS wrote: >James, > >Fist, s=E9bastien wasn't arguing against the need for an extension in the= =20 >INVITE, we fully support this. The problem is that network operators have= =20 >one very important goal: > >- the need to support a large range of terminals, not only complex ones=20 >and this requirement is even stronger when dealing with emergency calls. > >The solution proposed here might have some benefits for certain=20 >situations, but it would be a pity not to come up with a solution that=20 >doesnot require any specific terminal functionnality and would most likely= =20 >cause non-standardized solution to be used. There are a few requirements that need to be met for emergecny calls: 1) determine the call is an emergency call 2) determine where the UAC is 3) route the call set-up messages to the appropriate PSAP for that UAC 4) update the location of the UAC to the PSAP if the UAC moves #1 above is solved by Henning's sos@ document #2 is hard. There are several documents addressing this (RFC3825, Henning's= =20 civic version that's still an ID), and there is GPS locally to the UAC, or= =20 manual configuration. The hardest part of #2 is that this needs to be good= =20 100% of the time, meaning something has to be statefully aware of the UAC's= =20 location wherever it is every second of every day (I feel I'm repeating=20 myself). So, is that statefulness in the UAC or in a server (or series of=20 servers) within a domain/realm? The most scalable location for this=20 information is in the UAC. Getting the info to the UAC is easy for wired=20 and limited range wireless devices. It gets harder for longer range=20 wireless devices. I believe in the US that cellular location determination is conveyed on the= =20 PSAP operator's terminal something like 15 seconds after the call is placed= =20 to the PSAP. This means the call is routed to the most likely PSAP based on= =20 the originating cell tower the signal came from. Once at the PSAP, sw there= =20 goes out and searches for the actual location of the caller (cell twoer=20 triangulation providing GPS coordinates - which get mapped to a street map= =20 database, which generates a street address for where the caller is). #3 can be solved once the location of the UAC is determined and forwarded=20 to the PSAP, because each should have a database to resolve the specific=20 location of the UAC to its proper PSAP. The ECRIT WG is chartered with=20 solving this. Once any PSAP receives the call, it should be able to "transfer" the call=20 to the more appropriate PSAP (if the original PSAP wasn't the correct one).= =20 This should direct and could be over quite secure communications between=20 PSAPs that know each other through an SA. #4 is not so hard if the UAC knows its location and determines it has=20 moved. At last year's Minneeapolis meeting, the WG was quite clear that the= =20 UPDATE Method is to be used by the UAC to update its location even after=20 the dialog has been established. If the UAC does not know its location, then whatever is statefully aware of= =20 the UAC's location will have to convey that change in UAC location to the=20 PSAP about the UAC. I'm not sure at all what message that would be. Would=20 the Proxy originate an UPDATE message towards the PSAP UAS that the=20 original UAC knows nothing about? I can see that being messy, as I can see= =20 the (PSAP) UAS 200 OKing to the user's UAC (which would be ignored because= =20 it didn't originate the UPDATE). >S=E9bastien G. > > >-----Message d'origine----- >De : James M. Polk [mailto:jmpolk@cisco.com] >Envoy=E9 : vendredi 8 juillet 2005 02:20 >=C0 : PROUVOST Sebastien RD-CORE-ISS; Elwell, John; br@brianrosen.net >Cc : sip@ietf.org; GARCIN Sebastien RD-CORE-ISS >Objet : RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00 > >Sebastien > >At 11:45 AM 7/1/2005 +0200, PROUVOST Sebastien RD-CORE-ISS wrote: > > >Hi, > > > >I fully agree with John. > >I hope I just answered his concerns with the limitations of the existing=20 >SIP architecture and emergency calling in the message I just sent to the=20 >list. Let me address your questions directly here > > > >The solution presented in the draft that says that if the UAC do not > >insert the location in the INVITE and if its outbound proxy has the > >info and wants to have it included it into the INVITE, it returns it in > >a 4xx "Retry Location Body" has several drawbacks : > > > >- What if the UAC issues the new INVITE that does not contains the > >location object > >I'll turn this one around on you: What if the only INVITE were received by= =20 >the outbound proxy with no location included... where would that Proxy=20 >route the message to? > >Because there is no realm or domain part of a emergency call today, there= =20 >is no place for SIP servers to look up where the UAC is or the destination= =20 >UAS is to route the message to. The message will not go anywhere today. So= =20 >we need an extension to SIP to accomplish this. > >This document is to address what needs to be done in SIP to convey=20 >location. The ECRIT WG is chartered with how to take a well formed SIP=20 >message (with location) and route it towards the appropriate PSAP. > > >(because it does not support this draft for example). If the call does > >not go through, this is a very big issue when the call is an emergency= call. > >I fully agree - yet I do not see another way of solving this issue other=20 >than to have location in the INVITE. Let me explain this: > >If you want location to be in a header, the UAC doesn't have that=20 >information unless it's told that information - or - the SIP proxy server= =20 >inserts this header in the INVITE message once it determines it is an=20 >emergency call. This means the SIP Proxy always has to know where the UAC= =20 >is. That sounds like the SP is tracking the UAC. That enables tracking of= =20 >users through their UAs. > >Doesn't this have some privacy concerns? > >Do you want to be tracked everywhere you go for the one or two times in=20 >your life you call 911 or 112? > >Further, what if I merely want to send my location to you in an IM. Do I=20 >have to rely on a tracking SP to insert it into my MESSAGE Request message= =20 >towards you in order for you to receive it from me? > >What if I use two different SPs: one for Voice and one for IM. Now I have= =20 >to have two SPs tracking me all the time because IM will be just as easy=20 >to use in the near future for emergency services as voice calling 911/112= =20 >is today. Where does this additive SPs stop? How many SPs need to be able= =20 >to track me (through my UAC) to provide location conveyance services? This= =20 >is every minute of every day, 7 days a week, 365 days a year, on every UAC= =20 >you and I own. > > >As a service provider we cannot rely on the capacity of the UAC to > >allow emergency calls to go through. > >What if your UAC's have a GPS? Is this not the best means of determining=20 >location of the UAC? Is this going to be forbidden? If it is not, then we= =20 >have to have a consistent means for allowing a GPS assisted UAC to convey= =20 >its location for whatever purpose, even emergencies. > >I believe you have a trust issue with the system. That's a separate issue= =20 >- and a lot of folks have that belief. If the designed system isn't good=20 >enough, design a better system. > > > >- What if the UAC issues a new INVITE that contains the location object > >but that does not correspond to the one the proxy gave. > >Then that is not a well behaving UAC. Folks that call for emergency want=20 >to get help. If their UAC fails on them, it fails. What if I have an=20 >emergency today and my existing GSM phone fails for whatever reason? It=20 >also fails. >I'm in just as much trouble. We need to build the best products for each=20 >situation, but the IETF isn't defining products themselves, it's defining= =20 >protocols and triggers within protocols to provide features/functions. > > > >- This solution introduces a supplementary exchange between the UA and > >its proxy which introduces an additional delay to the call > >establishement (especially important if the UA is over a radio access). > >how much more delay do you expect this single exchange to cause? It's one= =20 >round trip between one application layer hop - it's not that much time. >But, do you have a figure in mind that makes this undesireable? > > > >If the draft stays as it is, this is one more reason why service= providers > >would need an SBC > >and this isn't going to inject any delays? huh? > > > : in order to be able to insert location information to an INVITE > > request without requiring any UA intervention. > >this will require the SBC to be completely stateful as to where EVERY UAC >is at all times just in case a UAC calls for an emergency. That means every >second of every day for the life of that UAC, and every other UAC within >that realm. Do you believe that will scale? > >Do you believe that will not cause delay in the look-up of where a >particular UAC is in a location database? > >Does the SBC have this database local for all UACs that it could receive a >911/112 INVITE from, or is this datebase more centralized within the SP= realm? > >How many SBCs are you expecting per realm? > >How current is the database of UAC locations among all SBCs? > >I'm having a hard time believing an SBC inserting location into the INVITE >will increase efficiency. I think getting location down into the UAC is the >most efficient means of location conveyance - especially for emergency=20 >calling. > > > >It is necessary for a proxy to be able to insert this location info > >without having to rely on the UA's intervention. > >Why is it necessary? > > > >Sebastien. > > > > > >---------- > >De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de > >Elwell, John > >Envoy=E9 : mercredi 29 juin 2005 11:19 > >=C0 : jmpolk@cisco.com; br@brianrosen.net > >Cc : sip@ietf.org > >Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00 > > > >James, Brian, > > > >In section 9 (special provisions for emergency calls) it states: > > > >"In the case where the Proxy knows the location of the UAC and does not > >detect the UAC's location information message body in the message (or > >determines the LO is bad), the Proxy generates a new 4XX (Retry Location > >Body) error message that includes a location information message body for > >that UAC to include in the subsequent message. The user agent MUST > >include this message body in the subsequent emergency message." > > > >This places a new requirement on the UAC, which will not be met by UACs > >that are not compliant to this document. It seems emergency calls from > >such UACs will fail. > > > >Regards, > > > >John > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 15:16:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyKf-0001SB-VP; Fri, 08 Jul 2005 15:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyKf-0001S5-11 for sip@megatron.ietf.org; Fri, 08 Jul 2005 15:16:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08624 for ; Fri, 8 Jul 2005 15:16:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqym5-0002pO-4v for sip@ietf.org; Fri, 08 Jul 2005 15:44:39 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2005 12:16:03 -0700 X-IronPort-AV: i="3.93,274,1115017200"; d="scan'208"; a="295387551:sNHT71220054" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j68JG0vM028447; Fri, 8 Jul 2005 12:16:00 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 15:16:02 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 15:16:01 -0400 Message-ID: <42CED0F2.2030501@cisco.com> Date: Fri, 08 Jul 2005 15:16:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <003b01c582f9$5b5ff4d0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2005 19:16:02.0043 (UTC) FILETIME=[7ACB54B0:01C583F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale Worley wrote: >>From: Aki Niemi [mailto:aki.niemi@nokia.com] >> >>I agree this is a major deficiency in the SIP events framework. It is >>partly due to the fact that the SUBSCRIBE method is overloaded to do >>initial subscriptions, refreshes, as well as fetches within dialogs. >>Therefore, the notifier will always generate a NOTIFY upon >>receiving a >>SUBSCRIBE, even though the subscriber may already have that state and >>thus doesn't actually need it. > > > More exactly, SUBSCRIBE is optimized for the situation where subscriptions > are relatively short lived, and the state they receive changes quite > frequently. The "dialog state" event package is the sort of thing SUBSCRIBE > works well for. > > >>I don't see much benefit in this. Simply changing the method from a >>dialog creating one to a non-dialog-creating one doesn't solve the >>actual problem of being able to maintain subscriptions with little (or >>no) overhead. > > > In terms of message traffic, replacing SUBSCRIBE with PUBLISH helps a great > deal. Because SUBSCRIBE maintains a dialog, every time the UA's address > changes, it has to refresh the subscription. With PUBLISH, those overhead > messages are eliminated, at the cost of increased routing effort for every > notification. Agree. > In the end, there's no way to maintain a subscription without maintaining a > record that the subscription exists. The protocol question is how to > minimize the number of overhead messages. There is also the issue of minimizing the *amount* of state. For a server that already operates on behalf of a particular set of AORs, the subscription state can be as small as one bit (publish to the AOR or not), up to complete dialog state plus subscription state: - from tag, to tag, dialog id - local and remote CSeq - route set - local and remote target URI - event id - event parameters - subscription expiration timer - subscription filters - ... Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 08 15:28:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyWp-0003xL-3b; Fri, 08 Jul 2005 15:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyWl-0003xG-Ue for sip@megatron.ietf.org; Fri, 08 Jul 2005 15:28:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10062 for ; Fri, 8 Jul 2005 15:28:46 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqyxx-0003Sb-AQ for sip@ietf.org; Fri, 08 Jul 2005 15:56:58 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j68JP7HP009201; Fri, 8 Jul 2005 19:25:07 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 15:25:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 Date: Fri, 8 Jul 2005 15:25:06 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502FB4@stntexch03.cis.neustar.com> Thread-Topic: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 Thread-Index: AcWD7NBxbUHcFvqzSN+opBpYhg4SEwAAt7CQ From: "Peterson, Jon" To: "James M. Polk" , "Elwell, John" X-OriginalArrivalTime: 08 Jul 2005 19:25:07.0474 (UTC) FILETIME=[BFE57F20:01C583F2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Ok, but can you solve this in a header: >=20 > - the Geopriv WG was chartered with mandating security and privacy of = a=20 > endsystem's location information (RFC3963) - based on the rules = established=20 > by a "rulemaker" (which can be the enduser, the domain administrator = or the=20 > combination), and I do not know how this can be accomplished if = location is=20 > shown in a header inserted without the user's knowledge or control. The rule-maker's ability to set policies is completely unrelated to the = protocol means by which location information is embedded in messages. = The entity that serves location information, ultimately, must be = responsible for seeing that the rule-maker's policies are enforced. This = can be accomplished if that entity has access to the user's policies and = implements them, regardless of how location information is mechanically = inserted into signaling. > SIP message headers are TLS or IPsec hop-by-hop encrypted at best = (right?),=20 > and may not be encrypted at all even one hop away from the UAC, so how = is=20 > the user's privacy concerns about their location information not being = > divulged addressed? If the location information is added by-reference in a header, then no = privacy-impacting information will appear in the message itself. = Entities that want the location information will have to dereference the = artifact in the header, and in that deferencing process, as well as in = the object yielded by dereferencing, policies can be enforced. > This is accomplished if location were placed in a message body - which = > cannot be added in transit by a Proxy. This draft provides a means for = a=20 > Proxy to say "hey, you need a location body in that message, here, use = > in your subsequent message". This is the 425 (Retry = Location=20 > Body) Response I have in the doc. All that is true, but I'm not convinced that there aren't ways for a = proxy server to associate location information with a request that don't = involve this degree of client support, and which can still provide the = necessary GEOPRIV protections. At a high level, I am also very = sympathetic to Mr. Elwell's concern that there are likely to be = environments where the proxy server (let's say the local layer-7 domain) = knows your location information, even when the endpoint and even the = access network does not. Worse, I fear there might be environments where = the local layer-7 domain might not even want to tell endpoints what it = knows about location information directly. > To give some history, I orignially had location in a new header, but = was=20 > told it had to be moved to the body by the WG, the chairs and the ADs = (at=20 > Vienna). This was based on Geopriv guidelines. Just putting the raw location information as a text field in a header = without any of the protections mandated by GEOPRIV is not a good idea, I = agree. Since a message body can contain a full GEOPRIV object, it is a = better place to put location information by-value than a header. = However, that doesn't necessarily mean that there aren't viable = approaches to location conveyance that involve headers. Placing a = reference to location information in a header, rather than the location = information itself, would be an example. > So, I'm not necessarily disagreeing with you that there may be cases = in a=20 > header is better than in a body, but I don't know how to *not* violate = the=20 > specifics or spirit of what Geopriv is doing. RFC3963 is pretty clear = that=20 > privacy concerns need to always be taken into account when identity is = > conveyed. > > Any suggestions? Use a reference. Jon Peterson NeuStar, Inc. > >John > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 08 July 2005 00:40 > > > To: Elwell, John > > > Cc: sip@ietf.org > > > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > > > > > John > > > > > > Sorry for hte late reply - I was on PTO. Comments below: > > > > > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > > > > > >James, Brian, > > > > > > > >In section 9 (special provisions for emergency calls) it states: > > > > > > > >"In the case where the Proxy knows the location of the UAC > > > and does not > > > >detect the UAC's location information message body in the > > > message (or > > > >determines the LO is bad), the Proxy generates a new 4XX > > > (Retry Location > > > >Body) error message that includes a location information > > > message body for > > > >that UAC to include in the subsequent message. The user=20 > agent MUST > > > >include this message body in the subsequent emergency message." > > > > > > > >This places a new requirement on the UAC, > > > > > > yes it does > > > > > > >which will not be met by UACs that are not compliant to this > > > document. > > > > > > Yes, this is true for all extensions > > > > > > >It seems emergency calls from such UACs will fail. > > > > > > Emergency calls only route to the appropriate PSAP based on > > > the location of > > > the caller. This will not change. SIP has no concept of > > > physical location. > > > If my current UA dials tel:911, where will the INVITE go to? > > > 911 is good > > > here in Dallas, Texas - just as it is good in New York City. > > > There is no > > > area code (ever) indicating where a 911 call is from or to. > > > So how does the > > > Proxy receiving this 911 as a Request-URI know how to route > > > the message? > > > The answer is in multiple steps: > > > > > > The INVITE first has to be identified as an emergency call - > > > a Request-URI > > > 911 will do this inside the US (112 works inside Europe), or > > > Henning's > > > proposed "sos@..." will do this in the future as it progresses. > > > > > > The second piece to this puzzle is providing the location of > > > the UAC. This > > > serves 2 purposes: > > > > > > 1) it provides the location of the UAC to now look for the > > > appropriate PSAP > > > in that geographic area (the ECRIT WG is working on defining > > > that mapping > > > protocol/means of a UAC's location to the appropriate PSAP > > > Request-URI), and > > > > > > 2) Providing the lcoation in the INVITE to the PSAP will give > > > the PSAP > > > operator a location to dispatch first responders to. > > > > > > Without location in the INVITE, how are either of these > > > functions accomplished? > > > > > > SIP currently cannot do either without an extension to=20 > the protocol. > > > > > > While adding a certain message body type isn't technically an > > > extension, it > > > is a change in behavior of a UAC and a Proxy/intermediary (to > > > look for the > > > location message body). > > > > > > Given the existing SIP rules stating message bodies cannot be > > > added to a > > > SIP message by a SIP Proxy Server, we're limited with=20 > what we can do. > > > > > > If the Proxy knows the location of the UAC, it has to=20 > have a means of > > > informing the UAC of this location. There are several ways to > > > do this - the > > > one chosen here is a new 425 Response code (which is an > > > extension to SIP) > > > that includes a message body of the UAC's location to be=20 > used in the > > > subsequent INVITE by the UAC. The user will not know of=20 > this initial > > > rejection, and the UAC will need to know to send a new INVITE > > > with this > > > message body included. > > > > > > I could have put in a 3XX Response to do this, but chose not to. > > > > > > I don't understand Dave Oran's comment about adding a > > > Supported header > > > (Location) since this document doesn't allow a=20 > by-reference header. > > > > > > Does this answer your question? > > > > > > > > > >Regards, > > > > > > > >John > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be=20 > presented. > > > >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented. >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 09 17:43:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrN6q-0003fn-NO; Sat, 09 Jul 2005 17:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrN6o-0003fi-Gz for sip@megatron.ietf.org; Sat, 09 Jul 2005 17:43:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26717 for ; Sat, 9 Jul 2005 17:43:35 -0400 (EDT) Received: from ussjmh01.bea.com ([63.96.162.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrNYU-00048k-5T for sip@ietf.org; Sat, 09 Jul 2005 18:12:14 -0400 Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j69LhTbk008443 for ; Sat, 9 Jul 2005 14:43:29 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 9 Jul 2005 14:43:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Date: Sat, 9 Jul 2005 14:43:29 -0700 Message-ID: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> Thread-Topic: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions Thread-Index: AcWEn3CGGs1Ny20uT3C7zEsF3O2VeQAKxSUg From: "Nasir Khan" To: X-OriginalArrivalTime: 09 Jul 2005 21:43:29.0385 (UTC) FILETIME=[3EA25590:01C584CF] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.7.9.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think PUBLISH solves a lot of problems that I highlighted about long lasting subscriptions with little notification traffic.=20 In order to address the issue of installing such a subscription one could argue for a new method like REGISTER (say SUBSCRIBE FOR PUBLISH) that installs this dialog-less subscription at the NOTIFIER (which the NOTIFIER may delegate to an abstract subscription store). The "SUBSCRIBE for PUBLISH" may install that subscription for an AoR and when the event is to be generated the NOTIFIER may send a PUBLISH using the regular SIP routing mechanism (potentially looking up a location service or presence information). As Dale wrote below "SUBSCRIBE is optimized for the situation where subscriptions are relatively short lived, and the state they receive changes quite frequently."=20 We need a mechanism that could be optimized for subscriptions that are long lived and state changes very infrequently.=20 So SUBSCRIBERS can have the option to use regular SUBSCRIBE or "SUBSCRIBE for PUBLISH", the latter if correctly implemented may just result in a subscription record at the NOTIFIER end and nothing more.=20 Thanks Nasir Khan BEA Systems, Inc.=20 Dale Worley wrote: >>From: Aki Niemi [mailto:aki.niemi@nokia.com] >> >>I agree this is a major deficiency in the SIP events framework. It is >>partly due to the fact that the SUBSCRIBE method is overloaded to do >>initial subscriptions, refreshes, as well as fetches within dialogs. >>Therefore, the notifier will always generate a NOTIFY upon >>receiving a >>SUBSCRIBE, even though the subscriber may already have that state and >>thus doesn't actually need it. >=20 >=20 > More exactly, SUBSCRIBE is optimized for the situation where subscriptions > are relatively short lived, and the state they receive changes quite > frequently. The "dialog state" event package is the sort of thing SUBSCRIBE > works well for. >=20 >=20 >>I don't see much benefit in this. Simply changing the method from a >>dialog creating one to a non-dialog-creating one doesn't solve the >>actual problem of being able to maintain subscriptions with little (or >>no) overhead. >=20 >=20 > In terms of message traffic, replacing SUBSCRIBE with PUBLISH helps a great > deal. Because SUBSCRIBE maintains a dialog, every time the UA's address > changes, it has to refresh the subscription. With PUBLISH, those overhead > messages are eliminated, at the cost of increased routing effort for every > notification. Agree. > In the end, there's no way to maintain a subscription without maintaining a > record that the subscription exists. The protocol question is how to > minimize the number of overhead messages. There is also the issue of minimizing the *amount* of state. For a=20 server that already operates on behalf of a particular set of AORs, the=20 subscription state can be as small as one bit (publish to the AOR or=20 not), up to complete dialog state plus subscription state: - from tag, to tag, dialog id - local and remote CSeq - route set - local and remote target URI - event id - event parameters - subscription expiration timer - subscription filters _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 10 05:41:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrYJU-0006IM-W5; Sun, 10 Jul 2005 05:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrYJS-0006Hw-7k for sip@megatron.ietf.org; Sun, 10 Jul 2005 05:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20221 for ; Sun, 10 Jul 2005 05:41:23 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrYlC-0007xN-Tc for sip@ietf.org; Sun, 10 Jul 2005 06:10:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6A9fB3H002053; Sun, 10 Jul 2005 12:41:11 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jul 2005 12:41:11 +0300 Received: from [192.168.1.185] ([10.162.253.213]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 10 Jul 2005 12:41:11 +0300 Message-ID: <42D0ED34.4000700@nokia.com> Date: Sun, 10 Jul 2005 12:41:08 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Nasir Khan Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> In-Reply-To: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2005 09:41:11.0076 (UTC) FILETIME=[8166EE40:01C58533] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Inline. ext Nasir Khan wrote: > I think PUBLISH solves a lot of problems that I highlighted about long > lasting subscriptions with little notification traffic. Let's not get stuck on method names here. Whether state is delivered using NOTIFY, PUBLISH, or INFO makes no difference here. PUBLISH doesn't solve your problems any more than INFO or MESSAGE does. Less, in fact, because in most cases PUBLISHes sent to the AoR already have a place to go, namely the compositor for that event package that in many cases is a network based server. So UAs or end user devices will actually never end up seeing those messages. > In order to address the issue of installing such a subscription one > could argue for a new method like REGISTER (say SUBSCRIBE FOR PUBLISH) > that installs this dialog-less subscription at the NOTIFIER (which the > NOTIFIER may delegate to an abstract subscription store). The "SUBSCRIBE > for PUBLISH" may install that subscription for an AoR and when the event > is to be generated the NOTIFIER may send a PUBLISH using the regular SIP > routing mechanism (potentially looking up a location service or presence > information). Ok, so the requirement is to be able to subscribe using an AoR instead of a more volatile contact address. Perhaps a GRUU can solve this issue? Another requirement I gather from this is to minimize the amount of state kept per subscription. Are you saying that the current amount, i.e., dialog state, is too much? How so? You're bound to have to store at least some state for these subscriptions, at a minimum the subscriber's address of record. And no-where is it mandated that subscriptions, as they are currently specified, have to be stored in volatile memory. You are free to store the state wherever you want, including non-volatile storage or an "abstract subscription store". This is an implementation issue. > As Dale wrote below "SUBSCRIBE is optimized for the situation where > subscriptions are relatively short lived, and the state they receive > changes quite frequently." Right, and we may have some work to do to make the long-lasting subscriptions work better. We already have such event packages as the certificate event, in which subscriptions are measured in days, instead of hours. > We need a mechanism that could be optimized for subscriptions that are > long lived and state changes very infrequently. > So SUBSCRIBERS can have the option to use regular SUBSCRIBE or > "SUBSCRIBE for PUBLISH", the latter if correctly implemented may just > result in a subscription record at the NOTIFIER end and nothing more. Right. So let's articulate the requirements and start working on improving on SIP events to solve them. I don't see PUBLISH as a silver bullet here. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 10 23:46:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrpFg-00039C-Dw; Sun, 10 Jul 2005 23:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrpFf-00037n-Bu for sip@megatron.ietf.org; Sun, 10 Jul 2005 23:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15813 for ; Sun, 10 Jul 2005 23:46:35 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrphZ-0001xb-RQ for sip@ietf.org; Mon, 11 Jul 2005 00:15:30 -0400 Received: from ep_ms7_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJG001BC2HB0E@mailout3.samsung.com> for sip@ietf.org; Mon, 11 Jul 2005 12:46:23 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJG009O62HBV8@ms7.samsung.com> for sip@ietf.org; Mon, 11 Jul 2005 12:46:23 +0900 (KST) Content-return: prohibited Date: Mon, 11 Jul 2005 03:45:03 +0000 (GMT) From: =?euc-kr?B?wvfH9r/t?= To: "sip@ietf.org" Message-id: <19066034.1121053568943.JavaMail.weblogic@ep_ml10> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050711034608938@hyunwook.cha X-MTR: 20050711034608938@hyunwook.cha X-EPLocale: ko_KR.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Subject: [Sip] Any existing effort using rport for NAT traversal of media? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hyunwook.cha@samsung.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, all. I am newbie in SIP. I have a question as subject says. There are various efforts (including STUN, ICE, rport, symmetric RTP, TURN, etc.) to solve NAT traversal problem for SIP and media session. I think rport can be used for NAT traversal of media session as well as SIP signalling. What I have in mind is as follows. UAC can send INVITE request to itself using IP address(private) and port which it want to use for media session as source ip and source port. Then, outbound proxy which is on public side receives the INVITE message and inserts received and rport fields into via header because source IP address and port given by NAT are different those in via header. So, UAC can obtain its public IP address and port associated by NAT only if it can receive inbound call request. If I am not wrong, this can be a limited solution like STUN. Any comments or advices? Thanks in advance. Joseph HyunWook Cha E-mail : hyunwook.cha@samsung.com Tel 031-279-3804 H.P 010-2828-3804 FAX 031-279-2296 VoIP Part OfficeServ Development Group Internet Infra Business Team Network System Division _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 02:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drrtd-0000sS-SO; Mon, 11 Jul 2005 02:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drrtb-0000nZ-U3 for sip@megatron.ietf.org; Mon, 11 Jul 2005 02:36:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15384 for ; Mon, 11 Jul 2005 02:35:59 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrsLR-00077y-C0 for sip@ietf.org; Mon, 11 Jul 2005 03:04:53 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IJG00901A7M8E@siemenscomms.co.uk> for sip@ietf.org; Mon, 11 Jul 2005 07:33:22 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IJG0066JA7M1I@siemenscomms.co.uk>; Mon, 11 Jul 2005 07:33:22 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Jul 2005 07:35:39 +0100 Content-return: allowed Date: Mon, 11 Jul 2005 07:35:38 +0100 From: "Elwell, John" To: "James M. Polk" Message-id: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.2 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, All of what you say is reasonable in the general context of location. However, for emergency calls I would have thought the risk of divulging location information at a proxy would be better than not supplying location information at all (which would be the case if the UAC does not have appropriate support). John > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: 08 July 2005 19:40 > To: Elwell, John > Cc: sip@ietf.org > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00 > > John > > At 09:44 AM 7/8/2005 +0100, Elwell, John wrote: > >James, > > > >(Replying also to your message to Sebastien) > >I agree that in many environments the UAC will be the best > or only place to > >supply location information, in which case obviously one > will need a UA > >enhanced with the ability to provide location information > when making an > >emergency call. > > > >However, there will be some environments (notably enterprise > environments) > >where the proxy has knowledge of UA location. Sending back a > 4xx will work > >fine if the UA supports this. However, the ability for the > proxy to add > >location information (in a header) when forwarding the > request would be > >useful in order to support existing UAs that do not have > this enhancement. > > Ok, but can you solve this in a header: > > - the Geopriv WG was chartered with mandating security and > privacy of a > endsystem's location information (RFC3963) - based on the > rules established > by a "rulemaker" (which can be the enduser, the domain > administrator or the > combination), and I do not know how this can be accomplished > if location is > shown in a header inserted without the user's knowledge or control. > > SIP message headers are TLS or IPsec hop-by-hop encrypted at > best (right?), > and may not be encrypted at all even one hop away from the > UAC, so how is > the user's privacy concerns about their location information > not being > divulged addressed? > > This is accomplished if location were placed in a message > body - which > cannot be added in transit by a Proxy. This draft provides a > means for a > Proxy to say "hey, you need a location body in that message, > here, use > in your subsequent message". This is the 425 > (Retry Location > Body) Response I have in the doc. > > To give some history, I orignially had location in a new > header, but was > told it had to be moved to the body by the WG, the chairs and > the ADs (at > Vienna). This was based on Geopriv guidelines. > > So, I'm not necessarily disagreeing with you that there may > be cases in a > header is better than in a body, but I don't know how to > *not* violate the > specifics or spirit of what Geopriv is doing. RFC3963 is > pretty clear that > privacy concerns need to always be taken into account when > identity is > conveyed. > > Any suggestions? > > > >John > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 08 July 2005 00:40 > > > To: Elwell, John > > > Cc: sip@ietf.org > > > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > > > > > John > > > > > > Sorry for hte late reply - I was on PTO. Comments below: > > > > > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > > > > > >James, Brian, > > > > > > > >In section 9 (special provisions for emergency calls) it states: > > > > > > > >"In the case where the Proxy knows the location of the UAC > > > and does not > > > >detect the UAC's location information message body in the > > > message (or > > > >determines the LO is bad), the Proxy generates a new 4XX > > > (Retry Location > > > >Body) error message that includes a location information > > > message body for > > > >that UAC to include in the subsequent message. The user > agent MUST > > > >include this message body in the subsequent emergency message." > > > > > > > >This places a new requirement on the UAC, > > > > > > yes it does > > > > > > >which will not be met by UACs that are not compliant to this > > > document. > > > > > > Yes, this is true for all extensions > > > > > > >It seems emergency calls from such UACs will fail. > > > > > > Emergency calls only route to the appropriate PSAP based on > > > the location of > > > the caller. This will not change. SIP has no concept of > > > physical location. > > > If my current UA dials tel:911, where will the INVITE go to? > > > 911 is good > > > here in Dallas, Texas - just as it is good in New York City. > > > There is no > > > area code (ever) indicating where a 911 call is from or to. > > > So how does the > > > Proxy receiving this 911 as a Request-URI know how to route > > > the message? > > > The answer is in multiple steps: > > > > > > The INVITE first has to be identified as an emergency call - > > > a Request-URI > > > 911 will do this inside the US (112 works inside Europe), or > > > Henning's > > > proposed "sos@..." will do this in the future as it progresses. > > > > > > The second piece to this puzzle is providing the location of > > > the UAC. This > > > serves 2 purposes: > > > > > > 1) it provides the location of the UAC to now look for the > > > appropriate PSAP > > > in that geographic area (the ECRIT WG is working on defining > > > that mapping > > > protocol/means of a UAC's location to the appropriate PSAP > > > Request-URI), and > > > > > > 2) Providing the lcoation in the INVITE to the PSAP will give > > > the PSAP > > > operator a location to dispatch first responders to. > > > > > > Without location in the INVITE, how are either of these > > > functions accomplished? > > > > > > SIP currently cannot do either without an extension to > the protocol. > > > > > > While adding a certain message body type isn't technically an > > > extension, it > > > is a change in behavior of a UAC and a Proxy/intermediary (to > > > look for the > > > location message body). > > > > > > Given the existing SIP rules stating message bodies cannot be > > > added to a > > > SIP message by a SIP Proxy Server, we're limited with > what we can do. > > > > > > If the Proxy knows the location of the UAC, it has to > have a means of > > > informing the UAC of this location. There are several ways to > > > do this - the > > > one chosen here is a new 425 Response code (which is an > > > extension to SIP) > > > that includes a message body of the UAC's location to be > used in the > > > subsequent INVITE by the UAC. The user will not know of > this initial > > > rejection, and the UAC will need to know to send a new INVITE > > > with this > > > message body included. > > > > > > I could have put in a 3XX Response to do this, but chose not to. > > > > > > I don't understand Dave Oran's comment about adding a > > > Supported header > > > (Location) since this document doesn't allow a > by-reference header. > > > > > > Does this answer your question? > > > > > > > > > >Regards, > > > > > > > >John > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be > presented. > > > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 03:18:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsYk-0001BR-I3; Mon, 11 Jul 2005 03:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsYj-0001BM-4L for sip@megatron.ietf.org; Mon, 11 Jul 2005 03:18:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17959 for ; Mon, 11 Jul 2005 03:18:31 -0400 (EDT) From: sushma.boppana@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drt0e-0000JE-2e for sip@ietf.org; Mon, 11 Jul 2005 03:47:26 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FDCF20818 for ; Mon, 11 Jul 2005 12:38:30 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id E46ED20816 for ; Mon, 11 Jul 2005 12:38:29 +0530 (IST) Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 12:48:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Jul 2005 12:43:50 +0530 Message-ID: <5C85125242C5BB498E26BC9644AB13B6044BE854@BLR-EC-MSG04.wipro.com> Thread-Topic: subscribe Thread-Index: AcWF6BZiAXYISHprQwSR65KK7/arbw== To: X-OriginalArrivalTime: 11 Jul 2005 07:18:20.0345 (UTC) FILETIME=[B742EA90:01C585E8] X-Spam-Score: 1.5 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Sip] subscribe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1794119059==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1794119059== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C585E8.A43407FC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C585E8.A43407FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Thanks & Regards,=20 Sushma Boppana=20 ESN -6-877-8925=20 =20 =20 =20 ------_=_NextPart_001_01C585E8.A43407FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Thanks & = Regards,
Sushma Boppana
ESN -6-877-8925 =

 

 

 

------_=_NextPart_001_01C585E8.A43407FC-- --===============1794119059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1794119059==-- From sip-bounces@ietf.org Mon Jul 11 09:20:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryDR-0007jg-Gf; Mon, 11 Jul 2005 09:20:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryDP-0007hj-DN for sip@megatron.ietf.org; Mon, 11 Jul 2005 09:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09196 for ; Mon, 11 Jul 2005 09:20:53 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DryfO-0006gT-Gf for sip@ietf.org; Mon, 11 Jul 2005 09:49:52 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6BDKdTU019772; Mon, 11 Jul 2005 16:20:45 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 16:20:44 +0300 Received: from [172.21.35.157] ([172.21.35.157]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Jul 2005 16:20:43 +0300 Message-ID: <42D2722B.1040600@nokia.com> Date: Mon, 11 Jul 2005 16:20:43 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: New draft discussing SIP events issues (was: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions) References: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> <42D0ED34.4000700@nokia.com> In-Reply-To: <42D0ED34.4000700@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2005 13:20:43.0728 (UTC) FILETIME=[5753DD00:01C5861B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ext Nasir Khan X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All, I've submitted a new I-D that discusses in detail some of the issues that have also come up in this thread, as well as proposes some potential solutions. Until it appears in the archives, you can fetch a copy at: http://people.nokia.net/~aki/drafts/draft-niemi-sipping-subnot-issues-00.txt Also: please direct discussion of the draft over to SIPPING, as I think it belongs there more than in SIP. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 09:23:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryFi-0007zC-Us; Mon, 11 Jul 2005 09:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryFg-0007yy-El for sip@megatron.ietf.org; Mon, 11 Jul 2005 09:23:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09330 for ; Mon, 11 Jul 2005 09:23:14 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dryhf-0006nc-Fc for sip@ietf.org; Mon, 11 Jul 2005 09:52:13 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 158E91609; Mon, 11 Jul 2005 15:23:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 15:23:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 15:23:06 +0200 Received: from [131.160.126.55] (rvi2-126-55.lmf.ericsson.se [131.160.126.55]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EAE9D24E9; Mon, 11 Jul 2005 16:23:05 +0300 (EEST) Message-ID: <42D272B9.3020901@ericsson.com> Date: Mon, 11 Jul 2005 16:23:05 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rakhan@hssworld.com References: <20050710164057.95897.qmail@web54204.mail.yahoo.com> In-Reply-To: <20050710164057.95897.qmail@web54204.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2005 13:23:06.0337 (UTC) FILETIME=[AC544510:01C5861B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, rakhanhss@yahoo.com Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, if you are interested in such model, I suggest you write a concrete proposal in an I-D explaining how the direct signalling between A and B would relate to the session. Effectively, you would have two endpoints in a conference using T as the conference bridge with an additional direct signalling relationship between the endpoints. The general question you would need to address in such an I-D would be how to correlate several SIP dialogs (each of which may have an associated media session) so that all its associated media sessions are treated as a single media session at the endpoints. Thanks, Gonzalo Rayees Khan wrote: > Hi, > > > What I see the main advantage in this model is that it > would allow all the involved parties, including > trancoding server, to control the session and make > others aware of the changes. It does have the > limitation that the parties should support the > mentioned extension of SIP. > > > regards > Rayees > > > --- Gonzalo Camarillo > wrote: > > >>Hi, >> >>inline: >> >> >>>One of the things that would improve the draft >> >>would >> >>>be to include the message >>>format of the messages that would be exchanged in >> >>the >> >>>call flow. >> >>The details are given in the two documents >>describing the actual models. >>The framework only provides a rough description of >>both models. >> >> >>>In section 3.1, there is a link ([10]) to >>>the document that describes it all but for 3.2 I >> >>could >> >>>not find such link. >> >>Yes, I will add such a reference. >> >> >>>What I have understood from the two section is >>>o section 3.1 - after initial dialog is >> >>established by >> >>>A with B and T, it >>> would manage the exposure of transport address >> >>of B >> >>>and T to both >>>o section 3.2 - A establishes dialog with T, which >>>acts as a B2B UA. However, >>> it would additionally act as a MiddleBox >>>Communication server (RFC 3304) >>> and establishes dialog with B. >>> >>>The alternate model could be a hybrid one. The >> >>figure >> >>>below depicts the >>>signaling relationship between the parties. >>> >>>A establishes a signaling dialog with B, and comes >> >>to >> >>>know about the capabilites >>>of B. It realizes the need for transcoding so >>>establishes dialog with T, >>>queries it for resources. If response is positive >> >>from >> >>>T it uses REFER method >>>mechanism to inform B about signaling contacts of >> >>T. B >> >>>initiates session with C >>>joining the dialog as described in RFC 3911. >>> >>> +-------+ >>> | |** >>> | T | ** >>> | |\ ** >>> +-------+ \\ ** >>> ^ * \\ ** >>> | * \\ ** >>> | * SIP ** >>> SIP * \\ ** >>> | * \\ ** >>> | * \\ ** >>> v * \ ** >>> +-------+ +-------+ >>> | | | | >>> | A | < -- SIP --> | B | >>> | | | | >>> +-------+ +-------+ >>> >>>Does it make sense? >> >>What would be the advantages of this model? >> >>Note that this model would require B to understand a >>set of extensions >>(e.g., REFER, Replaces) while the existing models >>work with vanilla SIP >>user agents on the side that does not invoke the >>transcoder. >> >>Thanks, >> >>Gonzalo >> > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 09:37:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryT3-0003j5-8b; Mon, 11 Jul 2005 09:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryT1-0003iu-EX for sip@megatron.ietf.org; Mon, 11 Jul 2005 09:37:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10680 for ; Mon, 11 Jul 2005 09:37:01 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dryv0-0007VH-Ql for sip@ietf.org; Mon, 11 Jul 2005 10:06:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2005 15:36:52 +0200 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BDa2EG013752; Mon, 11 Jul 2005 15:36:49 +0200 (MEST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 09:36:14 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 09:36:14 -0400 Message-ID: <42D275CD.5090000@cisco.com> Date: Mon, 11 Jul 2005 09:36:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nasir Khan Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions References: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2005 13:36:14.0307 (UTC) FILETIME=[81FEF330:01C5861D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nasir Khan wrote: > I think PUBLISH solves a lot of problems that I highlighted about long > lasting subscriptions with little notification traffic. > In order to address the issue of installing such a subscription one > could argue for a new method like REGISTER (say SUBSCRIBE FOR PUBLISH) > that installs this dialog-less subscription at the NOTIFIER (which the > NOTIFIER may delegate to an abstract subscription store). The "SUBSCRIBE > for PUBLISH" may install that subscription for an AoR and when the event > is to be generated the NOTIFIER may send a PUBLISH using the regular SIP > routing mechanism (potentially looking up a location service or presence > information). Subscribing using an AOR for a contact just creates new problems. There may be multiple contacts registered for that AOR, so a message (e.g. PUBLISH) addressed to the AOR may (or may not) be forked to all the registered contacts, and the forking may be serial or parallel. Once one fork succeeds there is no reason to believe an attempt will be made to deliver the message to the other contacts. For instance, if you have two phones registered for the same AOR, and a MWI status was PUBLISHed to the AOR, it might just get to one of the phones. For this technique to be useful, we need a way to ensure that all valid candidate contacts are attempted. Its especially tricky if you want to ensure delivery to all contacts, or have the sender learn of the failures. There could still be a solution down this path. But it will require a bunch of work. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 10:08:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryxD-00033L-7d; Mon, 11 Jul 2005 10:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryxB-00033D-KO for sip@megatron.ietf.org; Mon, 11 Jul 2005 10:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13492 for ; Mon, 11 Jul 2005 10:08:11 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrzPC-0000Ph-K4 for sip@ietf.org; Mon, 11 Jul 2005 10:37:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2005 07:08:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,279,1115017200"; d="scan'208"; a="1269334:sNHT21505932" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6BE84Vu014503; Mon, 11 Jul 2005 10:08:04 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 10:07:40 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 10:07:40 -0400 Message-ID: <42D27D2B.7080804@cisco.com> Date: Mon, 11 Jul 2005 10:07:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: New draft discussing SIP events issues (was: Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions) References: <9B47F89C6226194D9ED3D4BAB227374904142F44@ussfex01.bea.com> <42D0ED34.4000700@nokia.com> <42D2722B.1040600@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2005 14:07:40.0600 (UTC) FILETIME=[E6506B80:01C58621] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, ext Nasir Khan X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > In certain conditions, the overhead induced by having to maintain > subscriptions becomes prohibitively high for subscribers. Not just subscribers. Notifiers too. I find it interesting to see what you chose to include and omit as requirements. My reaction is that I think there need to be more requirements. That may mean that there will need to be a range of different behaviors in order to satisfy everyone. In general I would characterize what I hear as a desire to minimize some metric over the system that includes the "subscribers", "publishers", and any intermediaries. The optimization may include some or all of the elements in the system. (E.g. state storage in subscribers may not be important.) The following are a couple that I have heard expressed one way or another: - "subscriber" doesn't want to subscribe at all, or maintain any subscription state. Would rather just handle "notifications" as context free events. Expects notifications to be delivered to it as result of external configuration that it has no involvement with. - "notifier" doesn't want to maintain any state about those interested it. It prefers to just "publish" interesting info about itself to one place. (Note that this can be achieved by publishing to an event state agent which carries the rest of the load.) Paul Aki Niemi wrote: > All, > > I've submitted a new I-D that discusses in detail some of the issues > that have also come up in this thread, as well as proposes some > potential solutions. Until it appears in the archives, you can fetch a > copy at: > > http://people.nokia.net/~aki/drafts/draft-niemi-sipping-subnot-issues-00.txt > > > Also: please direct discussion of the draft over to SIPPING, as I think > it belongs there more than in SIP. > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 10:31:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrzJn-0000xk-8h; Mon, 11 Jul 2005 10:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrzJk-0000xN-MV for sip@megatron.ietf.org; Mon, 11 Jul 2005 10:31:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15719 for ; Mon, 11 Jul 2005 10:31:30 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drzll-0001Oj-5O for sip@ietf.org; Mon, 11 Jul 2005 11:00:30 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6BEVEOn004610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 10:31:15 -0400 (EDT) Message-ID: <42D282AC.8090705@cs.columbia.edu> Date: Mon, 11 Jul 2005 10:31:08 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 References: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think we have two orthogonal dimensions: - conferring location by value or by reference; - carrying location in the header or in a body part. All four combinations are possible. In particular, there is no restriction on the length of headers in SIP and the likely length of a location header is no larger than, say, a bunch of Via headers. Like any XML object, it can be secured (authenticated, encrypted) using XMLDSIG. There are general trade-offs between 'by value' and 'by reference'. 'By value' ensures atomicity - wherever the request goes, the by-value information goes as well. This happens to be important for emergency calling since emergency calls are often forwarded and redirected to a variety of parties with need-to-know, including backup PSAPs and first responders. On the other hand, by-reference allows to differentiate access to call information from access to location information. (However, XMLDSIG also allows this to some extent, in a PK context.) By-reference is also likely to be smaller in the SIP request, but the overall system byte efficiency may well be less - after all, the entities needing the location information will likely have to set up a connection (TCP, TLS, whatever) to the location server, with the time and space overhead of that setup swamping the object size itself. By reference also means that there's a violation of fate sharing - a call may fail due to the inability of a proxy to dereference the location pointer, e.g., due to network failures, server overload, NAT issues, race conditions or authentication failures. Thus, I think it would be helpful to look at this more systematically and from a whole-systems perspective. Henning Elwell, John wrote: > James, > > All of what you say is reasonable in the general context of location. > However, for emergency calls I would have thought the risk of divulging > location information at a proxy would be better than not supplying location > information at all (which would be the case if the UAC does not have > appropriate support). > > John > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 14:37:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds39Y-0002bS-U7; Mon, 11 Jul 2005 14:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds39X-0002b5-33 for sip@megatron.ietf.org; Mon, 11 Jul 2005 14:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08666 for ; Mon, 11 Jul 2005 14:37:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds3bY-0003bl-Bl for sip@ietf.org; Mon, 11 Jul 2005 15:06:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2005 11:36:59 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="300865812:sNHT46764530" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6BIaCW7011377; Mon, 11 Jul 2005 11:36:56 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:36:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.201]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:36:54 -0700 Message-Id: <4.3.2.7.2.20050711125156.034eeb30@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 13:36:53 -0500 To: "Elwell, John" From: "James M. Polk" In-Reply-To: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemensc omms.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jul 2005 18:36:55.0115 (UTC) FILETIME=[8327C9B0:01C58647] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John I'm not understanding your comment - but will comment enough (I hope) to tease its meaning out. You talk about a risk in divulging location information, and I'm wondering how location can be inserted into a SIP message first. A comment on the former (divulging): The risk of divulging location is still a privacy choice today in the US. You can choose in some jurisdictions to not reveal your location even when dialing 911 in the PSTN. I would never do that, but it's possible. So, in my estimation, a similar local law will be addressing divulging location information over VoIP in that same jurisdiction - if the current law doesn't. What do we do about this? Ignore it, or build into the protocol a means for obeying this knowledge law that will be imposed on vendors selling into that jurisdiction? Now to the latter topic (location insertion in SIP messages): SIP Servers (other than versions of B2BUAs) cannot insert a message body of any kind today according to RFC 3261 (agreed?). Recent discussions within the WG has this stipulation continuing. So, in order to meet what you want, this server will need to add location as a SIP header. Which one? I don't believe one exists today that could satisfy this request/requirement. That's ok. This ID can invent one if necessary. Say the location header of the form: Location: where is one of 4 choices. It is either : 1) a predetermined coordinate format like GPS (including a datum value) 2) a predetermined civic address format (with some indication if this is a postal address, a legal address or a billing address), 3) it is a freeform open string in cleartext, 4) or it is a URL to a reference on a server #1 above is like the text version of RFC3825 or GPS #2 above is like Henning's civic ID at http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-06.txt but will be more difficult in format in have #3 above is what it says - freeform cleartext like a token #4 above is a URL to a record on a server that has potentially all format versions of location and provides the ability to challenge the requestor for credentials before divulging the location of the UAC. BTW - you don't want the challenge in #4 to fail giving location out in a 911 call for call routing or responder dispatch. #4 above could also be a very long header-value (>100 characters), if that matters One issue I have with option#4 above is that this means everytime I (for example) want to provide my location to someone else, I have to give this URL-based header out, or believe my SP will (because my UA doesn't know how). This is a means for the owner of the server the URL lives on to charge for that revelation of information, kinda like a dip into a PSTN database. Do we want to create that mechanism for all location revelation? Or just for a very limited few instances where the SIP UA cannot handle providing its location? I'm open to the latter here, but know it's uncontrollable once built. If location was only for 911 type services, this is the best place for it. For a location industry to have to bow the limitation of having some other entity always in the mix makes things inefficient at best. At 07:35 AM 7/11/2005 +0100, Elwell, John wrote: >James, > >All of what you say is reasonable in the general context of location. >However, for emergency calls I would have thought the risk of divulging >location information at a proxy would be better than not supplying location >information at all (which would be the case if the UAC does not have >appropriate support). > >John > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 08 July 2005 19:40 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00 > > > > John > > > > At 09:44 AM 7/8/2005 +0100, Elwell, John wrote: > > >James, > > > > > >(Replying also to your message to Sebastien) > > >I agree that in many environments the UAC will be the best > > or only place to > > >supply location information, in which case obviously one > > will need a UA > > >enhanced with the ability to provide location information > > when making an > > >emergency call. > > > > > >However, there will be some environments (notably enterprise > > environments) > > >where the proxy has knowledge of UA location. Sending back a > > 4xx will work > > >fine if the UA supports this. However, the ability for the > > proxy to add > > >location information (in a header) when forwarding the > > request would be > > >useful in order to support existing UAs that do not have > > this enhancement. > > > > Ok, but can you solve this in a header: > > > > - the Geopriv WG was chartered with mandating security and > > privacy of a > > endsystem's location information (RFC3963) - based on the > > rules established > > by a "rulemaker" (which can be the enduser, the domain > > administrator or the > > combination), and I do not know how this can be accomplished > > if location is > > shown in a header inserted without the user's knowledge or control. > > > > SIP message headers are TLS or IPsec hop-by-hop encrypted at > > best (right?), > > and may not be encrypted at all even one hop away from the > > UAC, so how is > > the user's privacy concerns about their location information > > not being > > divulged addressed? > > > > This is accomplished if location were placed in a message > > body - which > > cannot be added in transit by a Proxy. This draft provides a > > means for a > > Proxy to say "hey, you need a location body in that message, > > here, use > > in your subsequent message". This is the 425 > > (Retry Location > > Body) Response I have in the doc. > > > > To give some history, I orignially had location in a new > > header, but was > > told it had to be moved to the body by the WG, the chairs and > > the ADs (at > > Vienna). This was based on Geopriv guidelines. > > > > So, I'm not necessarily disagreeing with you that there may > > be cases in a > > header is better than in a body, but I don't know how to > > *not* violate the > > specifics or spirit of what Geopriv is doing. RFC3963 is > > pretty clear that > > privacy concerns need to always be taken into account when > > identity is > > conveyed. > > > > Any suggestions? > > > > > > >John > > > > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: 08 July 2005 00:40 > > > > To: Elwell, John > > > > Cc: sip@ietf.org > > > > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > > > > > > > John > > > > > > > > Sorry for hte late reply - I was on PTO. Comments below: > > > > > > > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > > > > > > > >James, Brian, > > > > > > > > > >In section 9 (special provisions for emergency calls) it states: > > > > > > > > > >"In the case where the Proxy knows the location of the UAC > > > > and does not > > > > >detect the UAC's location information message body in the > > > > message (or > > > > >determines the LO is bad), the Proxy generates a new 4XX > > > > (Retry Location > > > > >Body) error message that includes a location information > > > > message body for > > > > >that UAC to include in the subsequent message. The user > > agent MUST > > > > >include this message body in the subsequent emergency message." > > > > > > > > > >This places a new requirement on the UAC, > > > > > > > > yes it does > > > > > > > > >which will not be met by UACs that are not compliant to this > > > > document. > > > > > > > > Yes, this is true for all extensions > > > > > > > > >It seems emergency calls from such UACs will fail. > > > > > > > > Emergency calls only route to the appropriate PSAP based on > > > > the location of > > > > the caller. This will not change. SIP has no concept of > > > > physical location. > > > > If my current UA dials tel:911, where will the INVITE go to? > > > > 911 is good > > > > here in Dallas, Texas - just as it is good in New York City. > > > > There is no > > > > area code (ever) indicating where a 911 call is from or to. > > > > So how does the > > > > Proxy receiving this 911 as a Request-URI know how to route > > > > the message? > > > > The answer is in multiple steps: > > > > > > > > The INVITE first has to be identified as an emergency call - > > > > a Request-URI > > > > 911 will do this inside the US (112 works inside Europe), or > > > > Henning's > > > > proposed "sos@..." will do this in the future as it progresses. > > > > > > > > The second piece to this puzzle is providing the location of > > > > the UAC. This > > > > serves 2 purposes: > > > > > > > > 1) it provides the location of the UAC to now look for the > > > > appropriate PSAP > > > > in that geographic area (the ECRIT WG is working on defining > > > > that mapping > > > > protocol/means of a UAC's location to the appropriate PSAP > > > > Request-URI), and > > > > > > > > 2) Providing the lcoation in the INVITE to the PSAP will give > > > > the PSAP > > > > operator a location to dispatch first responders to. > > > > > > > > Without location in the INVITE, how are either of these > > > > functions accomplished? > > > > > > > > SIP currently cannot do either without an extension to > > the protocol. > > > > > > > > While adding a certain message body type isn't technically an > > > > extension, it > > > > is a change in behavior of a UAC and a Proxy/intermediary (to > > > > look for the > > > > location message body). > > > > > > > > Given the existing SIP rules stating message bodies cannot be > > > > added to a > > > > SIP message by a SIP Proxy Server, we're limited with > > what we can do. > > > > > > > > If the Proxy knows the location of the UAC, it has to > > have a means of > > > > informing the UAC of this location. There are several ways to > > > > do this - the > > > > one chosen here is a new 425 Response code (which is an > > > > extension to SIP) > > > > that includes a message body of the UAC's location to be > > used in the > > > > subsequent INVITE by the UAC. The user will not know of > > this initial > > > > rejection, and the UAC will need to know to send a new INVITE > > > > with this > > > > message body included. > > > > > > > > I could have put in a 3XX Response to do this, but chose not to. > > > > > > > > I don't understand Dave Oran's comment about adding a > > > > Supported header > > > > (Location) since this document doesn't allow a > > by-reference header. > > > > > > > > Does this answer your question? > > > > > > > > > > > > >Regards, > > > > > > > > > >John > > > > > > > > > > > > cheers, > > > > James > > > > > > > > ******************* > > > > Truth is not to be argued... it is to be > > presented. > > > > > > > > > > cheers, > > James > > > > ******************* > > Truth is not to be argued... it is to be presented. > > cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 14:49:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3LW-0007Ic-BZ; Mon, 11 Jul 2005 14:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3LV-0007IV-0I for sip@megatron.ietf.org; Mon, 11 Jul 2005 14:49:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10112 for ; Mon, 11 Jul 2005 14:49:35 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds3nW-0004CL-O4 for sip@ietf.org; Mon, 11 Jul 2005 15:18:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2005 11:49:24 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="300878376:sNHT148907108" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6BInJop001115; Mon, 11 Jul 2005 11:49:20 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:49:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:49:16 -0700 Message-Id: <4.3.2.7.2.20050711134557.03c3f228@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 13:49:15 -0500 To: Henning Schulzrinne , "Elwell, John" From: "James M. Polk" Subject: Re: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 In-Reply-To: <42D282AC.8090705@cs.columbia.edu> References: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jul 2005 18:49:17.0210 (UTC) FILETIME=[3D7A7FA0:01C58649] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Henning This is a good argument for analysis (I do not disagree with anything you wrote below), but this doesn't exactly help me in the short term in which I have to update the Location ID (by next Monday morning). Do I create the Location by reference header (with supporting requirements and scemantic text for it)? Or Do we continue this analysis before I modify the ID? I believe that once it's in the ID, it'll be hard to take out. comments please At 10:31 AM 7/11/2005 -0400, Henning Schulzrinne wrote: >I think we have two orthogonal dimensions: > >- conferring location by value or by reference; > >- carrying location in the header or in a body part. > >All four combinations are possible. In particular, there is no restriction >on the length of headers in SIP and the likely length of a location header >is no larger than, say, a bunch of Via headers. Like any XML object, it >can be secured (authenticated, encrypted) using XMLDSIG. > >There are general trade-offs between 'by value' and 'by reference'. 'By >value' ensures atomicity - wherever the request goes, the by-value >information goes as well. This happens to be important for emergency >calling since emergency calls are often forwarded and redirected to a >variety of parties with need-to-know, including backup PSAPs and first >responders. > >On the other hand, by-reference allows to differentiate access to call >information from access to location information. (However, XMLDSIG also >allows this to some extent, in a PK context.) > >By-reference is also likely to be smaller in the SIP request, but the >overall system byte efficiency may well be less - after all, the entities >needing the location information will likely have to set up a connection >(TCP, TLS, whatever) to the location server, with the time and space >overhead of that setup swamping the object size itself. > >By reference also means that there's a violation of fate sharing - a call >may fail due to the inability of a proxy to dereference the location >pointer, e.g., due to network failures, server overload, NAT issues, race >conditions or authentication failures. > >Thus, I think it would be helpful to look at this more systematically and >from a whole-systems perspective. > >Henning > >Elwell, John wrote: >>James, >>All of what you say is reasonable in the general context of location. >>However, for emergency calls I would have thought the risk of divulging >>location information at a proxy would be better than not supplying location >>information at all (which would be the case if the UAC does not have >>appropriate support). >>John cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 15:06:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3c3-00038f-Js; Mon, 11 Jul 2005 15:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3c1-00038a-Oi for sip@megatron.ietf.org; Mon, 11 Jul 2005 15:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11756 for ; Mon, 11 Jul 2005 15:06:40 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds43y-0004tO-Qn for sip@ietf.org; Mon, 11 Jul 2005 15:35:41 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6BJ5QOn021288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 15:05:27 -0400 (EDT) Message-ID: <42D2C2F1.8050603@cs.columbia.edu> Date: Mon, 11 Jul 2005 15:05:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 References: <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> <4.3.2.7.2.20050711134557.03c3f228@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050711134557.03c3f228@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There seems to be sufficient confusion about the various options and their properties that clearly documenting their engineering trade-offs might speed convergence on a solution. Once we agree on the properties, we might be better able to decide which ones are important and whether these are complementary solutions that offer different trade-offs and should be pursued. Since the abstract calls the document "framework and requirements", it seems helpful to capture some of the trade-offs, particularly since the discussion takes place in two, if not three, working groups, leading to a fair amount of re-hash or partial discussions. I'm happy to send text. Henning James M. Polk wrote: > Henning > > This is a good argument for analysis (I do not disagree with anything > you wrote below), but this doesn't exactly help me in the short term in > which I have to update the Location ID (by next Monday morning). > > Do I create the Location by reference header (with supporting > requirements and scemantic text for it)? > > Or > > Do we continue this analysis before I modify the ID? > > I believe that once it's in the ID, it'll be hard to take out. > > comments please > > At 10:31 AM 7/11/2005 -0400, Henning Schulzrinne wrote: > >> I think we have two orthogonal dimensions: >> >> - conferring location by value or by reference; >> >> - carrying location in the header or in a body part. >> >> All four combinations are possible. In particular, there is no >> restriction on the length of headers in SIP and the likely length of a >> location header is no larger than, say, a bunch of Via headers. Like >> any XML object, it can be secured (authenticated, encrypted) using >> XMLDSIG. >> >> There are general trade-offs between 'by value' and 'by reference'. >> 'By value' ensures atomicity - wherever the request goes, the by-value >> information goes as well. This happens to be important for emergency >> calling since emergency calls are often forwarded and redirected to a >> variety of parties with need-to-know, including backup PSAPs and first >> responders. >> >> On the other hand, by-reference allows to differentiate access to call >> information from access to location information. (However, XMLDSIG >> also allows this to some extent, in a PK context.) >> >> By-reference is also likely to be smaller in the SIP request, but the >> overall system byte efficiency may well be less - after all, the >> entities needing the location information will likely have to set up a >> connection (TCP, TLS, whatever) to the location server, with the time >> and space overhead of that setup swamping the object size itself. >> >> By reference also means that there's a violation of fate sharing - a >> call may fail due to the inability of a proxy to dereference the >> location pointer, e.g., due to network failures, server overload, NAT >> issues, race conditions or authentication failures. >> >> Thus, I think it would be helpful to look at this more systematically >> and from a whole-systems perspective. >> >> Henning >> >> Elwell, John wrote: >> >>> James, >>> All of what you say is reasonable in the general context of location. >>> However, for emergency calls I would have thought the risk of divulging >>> location information at a proxy would be better than not supplying >>> location >>> information at all (which would be the case if the UAC does not have >>> appropriate support). >>> John > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 15:18:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3nX-0006RQ-RZ; Mon, 11 Jul 2005 15:18:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3nV-0006RL-Uc for sip@megatron.ietf.org; Mon, 11 Jul 2005 15:18:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13419 for ; Mon, 11 Jul 2005 15:18:32 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds4FY-0005Kj-QG for sip@ietf.org; Mon, 11 Jul 2005 15:47:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2005 12:17:34 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="300913747:sNHT2502252820" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6BJHJVj000792; Mon, 11 Jul 2005 12:17:32 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 12:17:30 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 12:17:30 -0700 Message-Id: <4.3.2.7.2.20050711141230.03bdbe28@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Jul 2005 14:17:28 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 In-Reply-To: <42D2C2F1.8050603@cs.columbia.edu> References: <4.3.2.7.2.20050711134557.03c3f228@email.cisco.com> <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> <50B1CBA96870A34799A506B2313F266705D49FCA@ntht201e.siemenscomms.co.uk> <4.3.2.7.2.20050711134557.03c3f228@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jul 2005 19:17:30.0346 (UTC) FILETIME=[2EAA8CA0:01C5864D] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'd be a fool to not accept a text offering. I think it best to create a separate subsection dealing with this topic in the framework&Requirements section rather than integrating anything throughout the doc, as the rest of the doc - 60% of it - is a solution set per SIP Method, per conveyance type (e2e or Proxy-Routing) This new subsection gives a point of discussion I can bring out in the WG presentation on this ID too. At 03:05 PM 7/11/2005 -0400, Henning Schulzrinne wrote: >There seems to be sufficient confusion about the various options and their >properties that clearly documenting their engineering trade-offs might >speed convergence on a solution. Once we agree on the properties, we might >be better able to decide which ones are important and whether these are >complementary solutions that offer different trade-offs and should be pursued. > >Since the abstract calls the document "framework and requirements", it >seems helpful to capture some of the trade-offs, particularly since the >discussion takes place in two, if not three, working groups, leading to a >fair amount of re-hash or partial discussions. > >I'm happy to send text. > >Henning > >James M. Polk wrote: >>Henning >>This is a good argument for analysis (I do not disagree with anything you >>wrote below), but this doesn't exactly help me in the short term in which >>I have to update the Location ID (by next Monday morning). >>Do I create the Location by reference header (with supporting >>requirements and scemantic text for it)? >>Or >>Do we continue this analysis before I modify the ID? >>I believe that once it's in the ID, it'll be hard to take out. >>comments please >>At 10:31 AM 7/11/2005 -0400, Henning Schulzrinne wrote: >> >>>I think we have two orthogonal dimensions: >>> >>>- conferring location by value or by reference; >>> >>>- carrying location in the header or in a body part. >>> >>>All four combinations are possible. In particular, there is no >>>restriction on the length of headers in SIP and the likely length of a >>>location header is no larger than, say, a bunch of Via headers. Like >>>any XML object, it can be secured (authenticated, encrypted) using XMLDSIG. >>> >>>There are general trade-offs between 'by value' and 'by reference'. 'By >>>value' ensures atomicity - wherever the request goes, the by-value >>>information goes as well. This happens to be important for emergency >>>calling since emergency calls are often forwarded and redirected to a >>>variety of parties with need-to-know, including backup PSAPs and first >>>responders. >>> >>>On the other hand, by-reference allows to differentiate access to call >>>information from access to location information. (However, XMLDSIG also >>>allows this to some extent, in a PK context.) >>> >>>By-reference is also likely to be smaller in the SIP request, but the >>>overall system byte efficiency may well be less - after all, the >>>entities needing the location information will likely have to set up a >>>connection (TCP, TLS, whatever) to the location server, with the time >>>and space overhead of that setup swamping the object size itself. >>> >>>By reference also means that there's a violation of fate sharing - a >>>call may fail due to the inability of a proxy to dereference the >>>location pointer, e.g., due to network failures, server overload, NAT >>>issues, race conditions or authentication failures. >>> >>>Thus, I think it would be helpful to look at this more systematically >>>and from a whole-systems perspective. >>> >>>Henning >>> >>>Elwell, John wrote: >>> >>>>James, >>>>All of what you say is reasonable in the general context of location. >>>>However, for emergency calls I would have thought the risk of divulging >>>>location information at a proxy would be better than not supplying location >>>>information at all (which would be the case if the UAC does not have >>>>appropriate support). >>>>John >> >>cheers, >>James >> ******************* >> Truth is not to be argued... it is to be presented. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 11 20:06:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds8IZ-0004eJ-3c; Mon, 11 Jul 2005 20:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds8IX-0004eE-0F for sip@megatron.ietf.org; Mon, 11 Jul 2005 20:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09519 for ; Mon, 11 Jul 2005 20:06:49 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds8kc-0002C8-7e for sip@ietf.org; Mon, 11 Jul 2005 20:35:55 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 11 Jul 2005 17:06:42 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208,217"; a="197628654:sNHT33089740" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6C06e6p021592 for ; Mon, 11 Jul 2005 17:06:41 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 17:11:04 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 11 Jul 2005 20:06:36 -0400 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 X-OriginalArrivalTime: 12 Jul 2005 00:11:04.0561 (UTC) FILETIME=[318E7610:01C58676] X-Spam-Score: 1.6 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] New version draft-ietf-sip-outbound-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1327097154==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1327097154== Content-type: multipart/alternative; boundary="B_3203957197_17369110" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3203957197_17369110 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Until it shows up in the repository, it can't connect to you but you can connect to it with the link below: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-00. html --B_3203957197_17369110 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable New version draft-ietf-sip-outbound-00
Until it shows up in the repository, it can't connect to you but you can co= nnect to it with the link below:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-= sip-outbound-00.html --B_3203957197_17369110-- --===============1327097154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1327097154==-- From sip-bounces@ietf.org Mon Jul 11 20:55:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds93K-00051Y-Qg; Mon, 11 Jul 2005 20:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds93I-00051Q-LX for sip@megatron.ietf.org; Mon, 11 Jul 2005 20:55:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11985 for ; Mon, 11 Jul 2005 20:55:08 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds9VM-0003aF-84 for sip@ietf.org; Mon, 11 Jul 2005 21:24:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j6C0rXO12098; Mon, 11 Jul 2005 20:53:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] New version draft-ietf-sip-outbound-00 Date: Mon, 11 Jul 2005 19:54:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0332A6E1@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] New version draft-ietf-sip-outbound-00 Thread-Index: AcWGddNQ2lSakDtjTBqUqYGrPSkVOQAAwibw From: "Francois Audet" To: "Cullen Jennings" , "Rohan Mahy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Cullen, Rohan, Looks good. Some minor comments: - You explain briefly where the 500-600s come from in section 4.2, and also the=20 25-30s. - I would use something more explicit that "stun" for the URI parameter name.=20 Perhaps something like "sip-stun" or something similar. This is to avoid people=20 confusing it with the "normal" STUN server used for media. - In section 7, the wording seems to imply that the support for STUN on a SIP UDP signalling port is mandatory, which is not acceptable. I don't believe that all=20 registrars will want to support a native SIP-STUN server. Furthermore, one may decide that if sip-outbound connections (e.g., for NAT) are supported,=20 then the UA would have to do TCP. The Registrar or Proxy needs to be able to NOT support SIP-STUN. I think this is the point of the stun URI parameter, but the wording is a little ambiguous. - On that same point, I'd like to clarify the stun URI parameter. Is this for the Request-URI that would be sent to the Registrar? Something like sip:example.com;stun? If this is the case, then the fact that the registrar uses the stun parameter as part of it's request-URI would mean that it supports=20 a SIP-STUN server. Some more details and an example would help. Cheer. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Monday, July 11, 2005 17:07 To: sip@ietf.org Subject: [Sip] New version draft-ietf-sip-outbound-00 Until it shows up in the repository, it can't connect to you but you can connect to it with the link below: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound -00.html=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 12 04:09:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFq2-0000Hd-P4; Tue, 12 Jul 2005 04:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFpw-0000HO-Jp for sip@megatron.ietf.org; Tue, 12 Jul 2005 04:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29511 for ; Tue, 12 Jul 2005 04:09:50 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsGI3-0000el-85 for sip@ietf.org; Tue, 12 Jul 2005 04:38:59 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IJI0010198193@siemenscomms.co.uk> for sip@ietf.org; Tue, 12 Jul 2005 09:07:14 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IJI0009P97WDE@siemenscomms.co.uk>; Tue, 12 Jul 2005 09:07:08 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Jul 2005 09:09:25 +0100 Content-return: allowed Date: Tue, 12 Jul 2005 09:09:24 +0100 From: "Elwell, John" To: "James M. Polk" Message-id: <50B1CBA96870A34799A506B2313F266705D83FC5@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.2 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, See in-line. John > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: 11 July 2005 19:37 > To: Elwell, John > Cc: sip@ietf.org > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00 > > John > > I'm not understanding your comment - but will comment enough > (I hope) to > tease its meaning out. You talk about a risk in divulging location > information, and I'm wondering how location can be inserted > into a SIP > message first. > > A comment on the former (divulging): > > The risk of divulging location is still a privacy choice > today in the US. > You can choose in some jurisdictions to not reveal your > location even when > dialing 911 in the PSTN. I would never do that, but it's > possible. So, in > my estimation, a similar local law will be addressing > divulging location > information over VoIP in that same jurisdiction - if the current law > doesn't. What do we do about this? Ignore it, or build into > the protocol a > means for obeying this knowledge law that will be imposed on vendors > selling into that jurisdiction? [JRE] I was not aware of that situation in the US. So maybe insertion by a proxy can be done only in jurisdications where this is allowed without user consent. Otherwise, if the UAC does not indicate support for receiving location information in a 4xx response and resubmitting the request, then the emergency call just has to proceed without location information. > > Now to the latter topic (location insertion in SIP messages): > > SIP Servers (other than versions of B2BUAs) cannot insert a > message body of > any kind today according to RFC 3261 (agreed?). Recent > discussions within > the WG has this stipulation continuing. > > So, in order to meet what you want, this server will need to > add location > as a SIP header. Which one? I don't believe one exists today > that could > satisfy this request/requirement. That's ok. This ID can > invent one if > necessary. Say the location header of the form: > > Location: > > where is one of 4 choices. It is either : > > 1) a predetermined coordinate format like GPS (including a > datum value) > 2) a predetermined civic address format (with some indication > if this is a > postal address, a legal address or a billing address), > 3) it is a freeform open string in cleartext, > 4) or it is a URL to a reference on a server [JRE] I have a tendency towards 4), but I don't pretend to have a grasp of all the pros and cons yet. > > #1 above is like the text version of RFC3825 or GPS > #2 above is like Henning's civic ID at > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-ci > vil-06.txt > but will be more difficult in format in have > #3 above is what it says - freeform cleartext like a token > #4 above is a URL to a record on a server that has > potentially all format > versions of location and provides the ability to challenge > the requestor > for credentials before divulging the location of the UAC. > > BTW - you don't want the challenge in #4 to fail giving > location out in a > 911 call for call routing or responder dispatch. > > #4 above could also be a very long header-value (>100 > characters), if that > matters > > One issue I have with option#4 above is that this means > everytime I (for > example) want to provide my location to someone else, I have > to give this > URL-based header out, or believe my SP will (because my UA > doesn't know > how). [JRE] No, the UA can still provide location in a body. The URL alternative would just be for proxy use for an emergency call where the UAC is unable to insert location information. > This is a means for the owner of the server the URL lives on to > charge for that revelation of information, kinda like a dip > into a PSTN > database. Do we want to create that mechanism for all > location revelation? > Or just for a very limited few instances where the SIP UA > cannot handle > providing its location? I'm open to the latter here, but know it's > uncontrollable once built. > > If location was only for 911 type services, this is the best > place for it. > > For a location industry to have to bow the limitation of > having some other > entity always in the mix makes things inefficient at best. > > > At 07:35 AM 7/11/2005 +0100, Elwell, John wrote: > >James, > > > >All of what you say is reasonable in the general context of location. > >However, for emergency calls I would have thought the risk > of divulging > >location information at a proxy would be better than not > supplying location > >information at all (which would be the case if the UAC does not have > >appropriate support). > > > >John > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 08 July 2005 19:40 > > > To: Elwell, John > > > Cc: sip@ietf.org > > > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00 > > > > > > John > > > > > > At 09:44 AM 7/8/2005 +0100, Elwell, John wrote: > > > >James, > > > > > > > >(Replying also to your message to Sebastien) > > > >I agree that in many environments the UAC will be the best > > > or only place to > > > >supply location information, in which case obviously one > > > will need a UA > > > >enhanced with the ability to provide location information > > > when making an > > > >emergency call. > > > > > > > >However, there will be some environments (notably enterprise > > > environments) > > > >where the proxy has knowledge of UA location. Sending back a > > > 4xx will work > > > >fine if the UA supports this. However, the ability for the > > > proxy to add > > > >location information (in a header) when forwarding the > > > request would be > > > >useful in order to support existing UAs that do not have > > > this enhancement. > > > > > > Ok, but can you solve this in a header: > > > > > > - the Geopriv WG was chartered with mandating security and > > > privacy of a > > > endsystem's location information (RFC3963) - based on the > > > rules established > > > by a "rulemaker" (which can be the enduser, the domain > > > administrator or the > > > combination), and I do not know how this can be accomplished > > > if location is > > > shown in a header inserted without the user's knowledge > or control. > > > > > > SIP message headers are TLS or IPsec hop-by-hop encrypted at > > > best (right?), > > > and may not be encrypted at all even one hop away from the > > > UAC, so how is > > > the user's privacy concerns about their location information > > > not being > > > divulged addressed? > > > > > > This is accomplished if location were placed in a message > > > body - which > > > cannot be added in transit by a Proxy. This draft provides a > > > means for a > > > Proxy to say "hey, you need a location body in that message, > > > here, use > > > in your subsequent message". This is the 425 > > > (Retry Location > > > Body) Response I have in the doc. > > > > > > To give some history, I orignially had location in a new > > > header, but was > > > told it had to be moved to the body by the WG, the chairs and > > > the ADs (at > > > Vienna). This was based on Geopriv guidelines. > > > > > > So, I'm not necessarily disagreeing with you that there may > > > be cases in a > > > header is better than in a body, but I don't know how to > > > *not* violate the > > > specifics or spirit of what Geopriv is doing. RFC3963 is > > > pretty clear that > > > privacy concerns need to always be taken into account when > > > identity is > > > conveyed. > > > > > > Any suggestions? > > > > > > > > > >John > > > > > > > > > > > > > -----Original Message----- > > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > > Sent: 08 July 2005 00:40 > > > > > To: Elwell, John > > > > > Cc: sip@ietf.org > > > > > Subject: Re: Comment on draft-ietf-sip-location-conveyance-00 > > > > > > > > > > John > > > > > > > > > > Sorry for hte late reply - I was on PTO. Comments below: > > > > > > > > > > At 10:18 AM 6/29/2005 +0100, Elwell, John wrote: > > > > > > > > > > >James, Brian, > > > > > > > > > > > >In section 9 (special provisions for emergency > calls) it states: > > > > > > > > > > > >"In the case where the Proxy knows the location of the UAC > > > > > and does not > > > > > >detect the UAC's location information message body in the > > > > > message (or > > > > > >determines the LO is bad), the Proxy generates a new 4XX > > > > > (Retry Location > > > > > >Body) error message that includes a location information > > > > > message body for > > > > > >that UAC to include in the subsequent message. The user > > > agent MUST > > > > > >include this message body in the subsequent > emergency message." > > > > > > > > > > > >This places a new requirement on the UAC, > > > > > > > > > > yes it does > > > > > > > > > > >which will not be met by UACs that are not compliant to this > > > > > document. > > > > > > > > > > Yes, this is true for all extensions > > > > > > > > > > >It seems emergency calls from such UACs will fail. > > > > > > > > > > Emergency calls only route to the appropriate PSAP based on > > > > > the location of > > > > > the caller. This will not change. SIP has no concept of > > > > > physical location. > > > > > If my current UA dials tel:911, where will the INVITE go to? > > > > > 911 is good > > > > > here in Dallas, Texas - just as it is good in New York City. > > > > > There is no > > > > > area code (ever) indicating where a 911 call is from or to. > > > > > So how does the > > > > > Proxy receiving this 911 as a Request-URI know how to route > > > > > the message? > > > > > The answer is in multiple steps: > > > > > > > > > > The INVITE first has to be identified as an emergency call - > > > > > a Request-URI > > > > > 911 will do this inside the US (112 works inside Europe), or > > > > > Henning's > > > > > proposed "sos@..." will do this in the future as it > progresses. > > > > > > > > > > The second piece to this puzzle is providing the location of > > > > > the UAC. This > > > > > serves 2 purposes: > > > > > > > > > > 1) it provides the location of the UAC to now look for the > > > > > appropriate PSAP > > > > > in that geographic area (the ECRIT WG is working on defining > > > > > that mapping > > > > > protocol/means of a UAC's location to the appropriate PSAP > > > > > Request-URI), and > > > > > > > > > > 2) Providing the lcoation in the INVITE to the PSAP will give > > > > > the PSAP > > > > > operator a location to dispatch first responders to. > > > > > > > > > > Without location in the INVITE, how are either of these > > > > > functions accomplished? > > > > > > > > > > SIP currently cannot do either without an extension to > > > the protocol. > > > > > > > > > > While adding a certain message body type isn't technically an > > > > > extension, it > > > > > is a change in behavior of a UAC and a Proxy/intermediary (to > > > > > look for the > > > > > location message body). > > > > > > > > > > Given the existing SIP rules stating message bodies cannot be > > > > > added to a > > > > > SIP message by a SIP Proxy Server, we're limited with > > > what we can do. > > > > > > > > > > If the Proxy knows the location of the UAC, it has to > > > have a means of > > > > > informing the UAC of this location. There are several ways to > > > > > do this - the > > > > > one chosen here is a new 425 Response code (which is an > > > > > extension to SIP) > > > > > that includes a message body of the UAC's location to be > > > used in the > > > > > subsequent INVITE by the UAC. The user will not know of > > > this initial > > > > > rejection, and the UAC will need to know to send a new INVITE > > > > > with this > > > > > message body included. > > > > > > > > > > I could have put in a 3XX Response to do this, but > chose not to. > > > > > > > > > > I don't understand Dave Oran's comment about adding a > > > > > Supported header > > > > > (Location) since this document doesn't allow a > > > by-reference header. > > > > > > > > > > Does this answer your question? > > > > > > > > > > > > > > > >Regards, > > > > > > > > > > > >John > > > > > > > > > > > > > > > cheers, > > > > > James > > > > > > > > > > ******************* > > > > > Truth is not to be argued... it is to be > > > presented. > > > > > > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be > presented. > > > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 12 08:26:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJpw-0004pG-2X; Tue, 12 Jul 2005 08:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJpt-0004om-LH for sip@megatron.ietf.org; Tue, 12 Jul 2005 08:26:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16270 for ; Tue, 12 Jul 2005 08:26:04 -0400 (EDT) Received: from ns.ivd.nl ([193.67.37.226] helo=ns.viataal.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsKI4-0001kg-RB for sip@ietf.org; Tue, 12 Jul 2005 08:55:14 -0400 Received: (from root@localhost) by ns.viataal.nl (8.9.3c/8.6.12) id OAA32962 for ; Tue, 12 Jul 2005 14:25:53 +0200 (CEST) Received: by ns.viataal.nl (TUNIX/Firewall SMTP Server) for id sma032834; Tue, 12 Jul 05 14:25:28 +0200 Received: from IVD-MTA by GW-SERVER.VIATAAL.NL with Novell_GroupWise; Tue, 12 Jul 2005 14:25:19 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Tue, 12 Jul 2005 14:24:39 +0200 From: "A vWijk" To: , Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, rakhanhss@yahoo.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, and this can be interesting. But we need an ID first to see what is exactly meant and can then discuss = it. :-) greetz Arnoud Arnoud A. T. van Wijk Viataal Research & Development Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> Gonzalo Camarillo 07/11/05 3:23 pm = >>> Hi, if you are interested in such model, I suggest you write a concrete=20 proposal in an I-D explaining how the direct signalling between A and B=20 would relate to the session. Effectively, you would have two endpoints=20 in a conference using T as the conference bridge with an additional=20 direct signalling relationship between the endpoints. The general question you would need to address in such an I-D would be=20 how to correlate several SIP dialogs (each of which may have an=20 associated media session) so that all its associated media sessions are=20 treated as a single media session at the endpoints. Thanks, Gonzalo Rayees Khan wrote: > Hi, >=20 >=20 > What I see the main advantage in this model is that it > would allow all the involved parties, including > trancoding server, to control the session and make > others aware of the changes. It does have the > limitation that the parties should support the > mentioned extension of SIP. >=20 >=20 > regards > Rayees >=20 >=20 > --- Gonzalo Camarillo > wrote: >=20 >=20 >>Hi, >> >>inline: >> >> >>>One of the things that would improve the draft >> >>would >> >>>be to include the message=20 >>>format of the messages that would be exchanged in >> >>the >> >>>call flow. >> >>The details are given in the two documents >>describing the actual models.=20 >>The framework only provides a rough description of >>both models. >> >> >>>In section 3.1, there is a link ([10]) to >>>the document that describes it all but for 3.2 I >> >>could >> >>>not find such link. >> >>Yes, I will add such a reference. >> >> >>>What I have understood from the two section is >>>o section 3.1 - after initial dialog is >> >>established by >> >>>A with B and T, it=20 >>> would manage the exposure of transport address >> >>of B >> >>>and T to both >>>o section 3.2 - A establishes dialog with T, which >>>acts as a B2B UA. However,=20 >>> it would additionally act as a MiddleBox >>>Communication server (RFC 3304)=20 >>> and establishes dialog with B. >>> >>>The alternate model could be a hybrid one. The >> >>figure >> >>>below depicts the=20 >>>signaling relationship between the parties.=20 >>> >>>A establishes a signaling dialog with B, and comes >> >>to >> >>>know about the capabilites >>>of B. It realizes the need for transcoding so >>>establishes dialog with T,=20 >>>queries it for resources. If response is positive >> >>from >> >>>T it uses REFER method=20 >>>mechanism to inform B about signaling contacts of >> >>T. B >> >>>initiates session with C=20 >>>joining the dialog as described in RFC 3911.=20 >>> >>> +-------+ >>> | |** >>> | T | ** >>> | |\ ** >>> +-------+ \\ ** >>> ^ * \\ ** >>> | * \\ ** >>> | * SIP ** >>> SIP * \\ ** >>> | * \\ ** >>> | * \\ ** >>> v * \ ** >>> +-------+ +-------+ >>> | | | | >>> | A | < -- SIP --> | B | >>> | | | | >>> +-------+ +-------+ >>> >>>Does it make sense? >> >>What would be the advantages of this model? >> >>Note that this model would require B to understand a >>set of extensions=20 >>(e.g., REFER, Replaces) while the existing models >>work with vanilla SIP=20 >>user agents on the side that does not invoke the >>transcoder. >> >>Thanks, >> >>Gonzalo >> >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 --=20 Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com=20 Finland http://www.hut.fi/~gonzalo=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------------------------------------------------------------------------------------------------------------- Op deze e-mail is een disclaimer van toepassing. Deze kunt u vinden op 'www.viataal.nl/disclaimer' This e-mail is subject to a disclaimer, which can be found on 'www.viataal.nl/disclaimer' http://www.viataal.nl/disclaimer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 12 10:50:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM5U-0003JJ-9w; Tue, 12 Jul 2005 10:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM5D-00038R-BJ; Tue, 12 Jul 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29714; Tue, 12 Jul 2005 10:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsMXQ-0007oO-6D; Tue, 12 Jul 2005 11:19:12 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsM5B-0006nw-GG; Tue, 12 Jul 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-e2m-sec-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : End-to-middle Security in the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sip-e2m-sec-00.txt Pages : 20 Date : 2005-7-12 Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-e2m-sec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-e2m-sec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12093955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-e2m-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-e2m-sec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12093955.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jul 12 13:43:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsOmx-0000Zy-QU; Tue, 12 Jul 2005 13:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsOmv-0000Zt-EE for sip@megatron.ietf.org; Tue, 12 Jul 2005 13:43:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18832 for ; Tue, 12 Jul 2005 13:43:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsPF9-0007z7-Jb for sip@ietf.org; Tue, 12 Jul 2005 14:12:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2005 10:43:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6CHghVt020933; Tue, 12 Jul 2005 10:43:09 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 10:43:04 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.118]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 10:43:03 -0700 Message-Id: <4.3.2.7.2.20050712123421.032455d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jul 2005 12:43:03 -0500 To: "Elwell, John" From: "James M. Polk" In-Reply-To: <50B1CBA96870A34799A506B2313F266705D83FC5@ntht201e.siemensc omms.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Jul 2005 17:43:04.0057 (UTC) FILETIME=[27B53690:01C58709] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: sip@ietf.org Subject: [Sip] RE: Comment on draft-ietf-sip-location-conveyance-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org john in-line At 09:09 AM 7/12/2005 +0100, Elwell, John wrote: >James, > >See in-line. > >John > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 11 July 2005 19:37 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: RE: Comment on draft-ietf-sip-location-conveyance-00 > > > > John > > > > I'm not understanding your comment - but will comment enough > > (I hope) to > > tease its meaning out. You talk about a risk in divulging location > > information, and I'm wondering how location can be inserted > > into a SIP > > message first. > > > > A comment on the former (divulging): > > > > The risk of divulging location is still a privacy choice > > today in the US. > > You can choose in some jurisdictions to not reveal your > > location even when > > dialing 911 in the PSTN. I would never do that, but it's > > possible. So, in > > my estimation, a similar local law will be addressing > > divulging location > > information over VoIP in that same jurisdiction - if the current law > > doesn't. What do we do about this? Ignore it, or build into > > the protocol a > > means for obeying this knowledge law that will be imposed on vendors > > selling into that jurisdiction? >[JRE] I was not aware of that situation in the US. Most aren't - and I don't know of one that is using it. I've talked to folks that run PSAPs and they have to account for it, so I know it exists. I think I remember it originated in the state Georgia (but this is only a guess), and has since gone to some other states. I have not confirmed how wide location-anonimity this is. >So maybe insertion by a >proxy can be done only in jurisdications where this is allowed without user >consent. Otherwise, if the UAC does not indicate support for receiving >location information in a 4xx response and resubmitting the request, then >the emergency call just has to proceed without location information. exactly - I have text stating the subsequent SIP Request needs to pass through the Proxy without a 425 Response. I can make that more clear/highlighted > > > > Now to the latter topic (location insertion in SIP messages): > > > > SIP Servers (other than versions of B2BUAs) cannot insert a > > message body of > > any kind today according to RFC 3261 (agreed?). Recent > > discussions within > > the WG has this stipulation continuing. > > > > So, in order to meet what you want, this server will need to > > add location > > as a SIP header. Which one? I don't believe one exists today > > that could > > satisfy this request/requirement. That's ok. This ID can > > invent one if > > necessary. Say the location header of the form: > > > > Location: > > > > where is one of 4 choices. It is either : > > > > 1) a predetermined coordinate format like GPS (including a > > datum value) > > 2) a predetermined civic address format (with some indication > > if this is a > > postal address, a legal address or a billing address), > > 3) it is a freeform open string in cleartext, > > 4) or it is a URL to a reference on a server >[JRE] I have a tendency towards 4), but I don't pretend to have a grasp of >all the pros and cons yet. I believe others feel the same way > > > > #1 above is like the text version of RFC3825 or GPS > > #2 above is like Henning's civic ID at > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-ci > > vil-06.txt > > but will be more difficult in format in have > > #3 above is what it says - freeform cleartext like a token > > #4 above is a URL to a record on a server that has > > potentially all format > > versions of location and provides the ability to challenge > > the requestor > > for credentials before divulging the location of the UAC. > > > > BTW - you don't want the challenge in #4 to fail giving > > location out in a > > 911 call for call routing or responder dispatch. > > > > #4 above could also be a very long header-value (>100 > > characters), if that > > matters > > > > One issue I have with option#4 above is that this means > > everytime I (for > > example) want to provide my location to someone else, I have > > to give this > > URL-based header out, or believe my SP will (because my UA > > doesn't know > > how). >[JRE] No, the UA can still provide location in a body. The URL alternative >would just be for proxy use for an emergency call where the UAC is unable to >insert location information. oh... that's different. I fully agree we should do as much as we can for UAs that cannot support this extension. I'll float that variant of this scenario in the preso in Paris to see if the wg agrees. I have no problems with this as you stated it. > > This is a means for the owner of the server the URL lives on to > > charge for that revelation of information, kinda like a dip > > into a PSTN > > database. Do we want to create that mechanism for all > > location revelation? > > Or just for a very limited few instances where the SIP UA > > cannot handle > > providing its location? I'm open to the latter here, but know it's > > uncontrollable once built. > > > > If location was only for 911 type services, this is the best > > place for it. > > > > For a location industry to have to bow the limitation of > > having some other > > entity always in the mix makes things inefficient at best. > > > > > > At 07:35 AM 7/11/2005 +0100, Elwell, John wrote: > > >James, cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 12 15:51:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQmv-0008PR-Az; Tue, 12 Jul 2005 15:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlf-0007qd-QK; Tue, 12 Jul 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28343; Tue, 12 Jul 2005 15:50:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDq-0003vu-2l; Tue, 12 Jul 2005 16:19:20 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlX-0000Vo-DG; Tue, 12 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-00.txt Pages : 24 Date : 2005-7-12 Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and NATs, prevent servers from connecting to User Agents in this way. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS server. This specification defines behaviors for user agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections for high availability systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12143119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12143119.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 13 05:19:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdP2-00084c-Vp; Wed, 13 Jul 2005 05:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdP0-00084P-OX for sip@megatron.ietf.org; Wed, 13 Jul 2005 05:19:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17763 for ; Wed, 13 Jul 2005 05:19:36 -0400 (EDT) Received: from 69.red-213-97-128.pooles.rima-tde.net ([213.97.128.69] helo=pc-p1-informatica.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DsdrO-000739-3B for sip@ietf.org; Wed, 13 Jul 2005 05:48:58 -0400 Date: Wed, 13 Jul 2005 10:18:42 +0000 To: "Sip" From: "Dean.willis" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hkmslrtjgtojqxwngyck" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] Re: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ----------hkmslrtjgtojqxwngyck Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [New_MP3_Player.c pl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:13 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------hkmslrtjgtojqxwngyck Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Screen and Music


----------hkmslrtjgtojqxwngyck Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----------hkmslrtjgtojqxwngyck-- From sip-bounces@ietf.org Wed Jul 13 11:36:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjHQ-0001EW-1e; Wed, 13 Jul 2005 11:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjHN-0001EQ-VO for sip@megatron.ietf.org; Wed, 13 Jul 2005 11:36:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24498 for ; Wed, 13 Jul 2005 11:36:07 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler1.mail.eds.com ([199.228.142.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsjjl-0007tF-EM for sip@ietf.org; Wed, 13 Jul 2005 12:05:32 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j6DFa21L007010 for ; Wed, 13 Jul 2005 15:36:02 GMT Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j6DFZpd6021184 for ; Wed, 13 Jul 2005 10:35:51 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j6DFZp25021179 for ; Wed, 13 Jul 2005 10:35:51 -0500 To: "SIP IETF" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 13 Jul 2005 11:42:11 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 07/13/2005 08:35:50 AM, Serialize complete at 07/13/2005 08:35:50 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Multiple MWI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2019999160==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============2019999160== Content-Type: multipart/alternative; boundary="=_alternative 0055969F8525703D_=" This is a multipart message in MIME format. --=_alternative 0055969F8525703D_= Content-Type: text/plain; charset="US-ASCII" Hi, According to RFC 3842, we can only send one MWI information related to one user account, We can have MWI info present for multiple user accounts, as it will result in less number of NOTIFY messages traveling across network. -Udit --=_alternative 0055969F8525703D_= Content-Type: text/html; charset="US-ASCII"
Hi,

According to RFC 3842, we can only send one MWI information related to one user account,
We can have MWI info present for multiple user accounts, as it will result in less number of NOTIFY messages traveling across network.

-Udit --=_alternative 0055969F8525703D_=-- --===============2019999160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2019999160==-- From sip-bounces@ietf.org Wed Jul 13 12:19:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjtU-0000mX-0B; Wed, 13 Jul 2005 12:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjtS-0000if-20 for sip@megatron.ietf.org; Wed, 13 Jul 2005 12:15:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29759 for ; Wed, 13 Jul 2005 12:15:27 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DskLs-0001P4-I1 for sip@ietf.org; Wed, 13 Jul 2005 12:44:53 -0400 Received: by wproxy.gmail.com with SMTP id 55so222175wri for ; Wed, 13 Jul 2005 09:15:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=C41A8v9LrN9GIGpXcGfUPTsNDLnLlvtyAelfRGgfeKd6JHJw5sOQxcMenQNzM273Ybnw2fQOiER2grgQ33Yc69CBjS4/ANFivreoSu8cURZUkk3clybmfjeWVUqF0k+jFKrE8wQ6UoguBVQvcub1bQuy+npgPsAQfqXJeK7/vt8= Received: by 10.54.80.12 with SMTP id d12mr341537wrb; Wed, 13 Jul 2005 09:14:45 -0700 (PDT) Received: by 10.54.54.79 with HTTP; Wed, 13 Jul 2005 09:14:44 -0700 (PDT) Message-ID: Date: Wed, 13 Jul 2005 21:44:45 +0530 From: Sip Shakers To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Sip] Doubt - Transport error handling by Server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sip Shakers List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Why transport error handling by server transaction is different from handling by client transaction? According to sec 17.1.4 client trasanction passes error to TU. But in sec 17.2.4 server transaction is being asked to follow rfc 3263. Why can't server transaction also pass the error to TU. regards, -nins _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 13 12:52:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskT1-0005Pb-IV; Wed, 13 Jul 2005 12:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskSz-0005Os-7A for sip@megatron.ietf.org; Wed, 13 Jul 2005 12:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02630 for ; Wed, 13 Jul 2005 12:52:10 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DskvO-0002qa-TS for sip@ietf.org; Wed, 13 Jul 2005 13:21:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 12:51:37 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730882A2@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Tandem switch Call typing and routing Thread-Index: AcWHyyI7bq0fBzphQ1mlCtX7FK49mw== From: "Jenkal, Vijey" To: X-OriginalArrivalTime: 13 Jul 2005 16:51:37.0521 (UTC) FILETIME=[2266F210:01C587CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Tandem switch Call typing and routing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We are researching possible ways of performing PSTN call routing at a Tandem switch that receives calls from an (or more) end-office switch over a SIP interconnection. The tandem switch is responsible for determining the type of the call and completing it to either the Local, Local-toll or Long-distance PSTN trunk based on the call type. Based on the current regulations, the call typing would have to be based on the perspective of the originating switch rather than the tandem. Is there any discussions in the SIP forum with regards to how SIP could be used to convey the right information (either as call-type, rate-center information or otherwise) to facilitate such call routing at the tandem? The current alternatives that we are investigating are: 1. Find a standardized means of conveying the call-type information to the tandem: The tandem switch would then use the combination of called party number and call-type information to route the call to the appropriate PSTN trunk. We are not, however, able to identify any standard means of conveying this information. 2. Use a combination of calling and called party number information at the tandem to perform the call typing: Our preliminary investigation reveals that maintaining such a list of possible calling and called party number information in the tandem switch's dial-plan would make the dial-plan very complex and large. To this end, this alternative, while still being looked into, does not look promising. 3. Use multiple SIP interconnections between the End-office and the tandem switch: This architecture would emulate the current set up in the PSTN network, where the end-office typically uses specific trunks to forward call calls to the tandem base on the call type. The problem with this approach, of course, is that in a market that has multiple switches, there would be multiple SIP interconnections that would have to be established and maintained, which we would like to avoid if possible. The use of a single SIP interconnection between the switches would make the implementation much more scalable and an improvement over the current PSTN methodology. We would be really interested in the forums feedback on the alternatives. Are there other alternatives, from past discussions or current drafts/RFCs that may be in progress, that we should look into as well? Thank you Vijey Jenkal VoIP Architecture Team P - 215-320-8259 E - vijey_jenkal@cable.comcast.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 13 13:39:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslCe-00085f-1K; Wed, 13 Jul 2005 13:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DslCc-00085Y-0V for sip@megatron.ietf.org; Wed, 13 Jul 2005 13:39:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05970 for ; Wed, 13 Jul 2005 13:39:19 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dslf2-0004Ti-2p for sip@ietf.org; Wed, 13 Jul 2005 14:08:46 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 65C6F6C028 for ; Wed, 13 Jul 2005 13:39:12 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Tandem switch Call typing and routing Date: Wed, 13 Jul 2005 13:37:45 -0400 Message-ID: <00ad01c587d1$950d5240$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730882A2@PACDCEXCMB01.cable.comcast.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: Jenkal, Vijey > > We are researching possible ways of performing PSTN call routing at a > Tandem switch that receives calls from an (or more) end-office switch > over a SIP interconnection. The tandem switch is responsible for > determining the type of the call and completing it to either the Local, > Local-toll or Long-distance PSTN trunk based on the call type. I'm assuming that what you want is for the end-office switch to classify the call, but the tandem switch would be acting on that classification? One method would be for the end-office switch, while it was working out how to forward the call, to attach a URI parameter to the request-URI. The tandem would examine (and remove) the URI parameter to determine how to route the call. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 14 01:04:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsvtb-0002YE-0P; Thu, 14 Jul 2005 01:04:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsvtY-0002Pp-UE for sip@megatron.ietf.org; Thu, 14 Jul 2005 01:04:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10685 for ; Thu, 14 Jul 2005 01:04:24 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DswM6-0006xk-1M for sip@ietf.org; Thu, 14 Jul 2005 01:33:55 -0400 Received: by wproxy.gmail.com with SMTP id i18so205715wra for ; Wed, 13 Jul 2005 22:04:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=OmW6+Hu9qybBsJ+5LJxCEw7pIbXFXJIaAcMYRmLmeXBcKvHlusgDLyVGD7PuVZOZKhyhscWEtYpEdf829CmH4/a2cNKuGm0D7uRWTVttH0HgbUcuaFCbniJ+PKkc8bHTOFRGZuyPJvTVqV2q3uzVy7aYH/amax5b8EtSzvsQiTs= Received: by 10.54.62.19 with SMTP id k19mr602071wra; Wed, 13 Jul 2005 22:03:19 -0700 (PDT) Received: by 10.54.95.16 with HTTP; Wed, 13 Jul 2005 22:03:19 -0700 (PDT) Message-ID: <52db68bc05071322032f6801b1@mail.gmail.com> Date: Thu, 14 Jul 2005 10:33:19 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] query about IMS in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sudhir Kumar Reddy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426115807==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1426115807== Content-Type: multipart/alternative; boundary="----=_Part_6746_5172985.1121317399502" ------=_Part_6746_5172985.1121317399502 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All I would like to know about the IMS i.e. what is the actually role of SIP i= n=20 IMS. warmest regards --=20 Sudhir Kumar Reddy Thumma 0986060751 ------=_Part_6746_5172985.1121317399502 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi All
 
I would like to know about the IMS i.e. what is the actually role of S= IP in IMS.
 
warmest regards
--
Sudhir Kumar Reddy Thumma
0986060751 ------=_Part_6746_5172985.1121317399502-- --===============1426115807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1426115807==-- From sip-bounces@ietf.org Thu Jul 14 01:22:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DswAg-0005eo-DT; Thu, 14 Jul 2005 01:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DswAe-0005e8-5D for sip@megatron.ietf.org; Thu, 14 Jul 2005 01:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13502 for ; Thu, 14 Jul 2005 01:22:03 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dswd8-0007y1-TB for sip@ietf.org; Thu, 14 Jul 2005 01:51:34 -0400 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6E5UxEU021475 for ; Wed, 13 Jul 2005 22:30:59 -0700 (MST) Received: from zin24exm02.corp.mot.com (zin24exm02.ap.mot.com [10.232.26.1]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6E5SUli015831 for ; Thu, 14 Jul 2005 00:28:32 -0500 (CDT) Received: by zin24exm02.ap.mot.com with Internet Mail Service (5.5.2657.72) id <3MBN8Y28>; Thu, 14 Jul 2005 10:51:43 +0530 Message-ID: <19B94C8C331A7546A88C88502083353B01888C02@zin24exm02.ap.mot.com> From: Avasarala Ranjit-A20990 To: Sudhir Kumar Reddy , sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 10:51:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.1 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2007282862==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2007282862== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58833.E7C80B26" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C58833.E7C80B26 Content-Type: text/plain Hi IMS uses SIP to setup multimedia calls over IP. Refer 3GPP standard TS 24.229 for more details Regards Ranjit _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar Reddy Sent: Thursday, July 14, 2005 10:33 AM To: sip@ietf.org Subject: [Sip] query about IMS in SIP Hi All I would like to know about the IMS i.e. what is the actually role of SIP in IMS. warmest regards -- Sudhir Kumar Reddy Thumma 0986060751 ------_=_NextPart_001_01C58833.E7C80B26 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQ3OSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NzQ1OTEwMDUtMTQwNzIwMDU+PEZPTlQg ZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpPC9GT05UPjwvU1BBTj48L0RJVj4N CjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc3NDU5MTAwNS0xNDA3MjAwNT48 Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElNUyB1c2VzIFNJUCB0byBzZXR1cCBtdWx0aW1lZGlhIGNhbGxzIA0Kb3ZlciBJUC4mbmJzcDsg UmVmZXIgPEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwIA0K c2l6ZT0zPjxGT05UIGNvbG9yPSMwMDAwZmY+M0dQUCBzdGFuZGFyZCBUUyAyNC4yMjkgZm9yIG1v cmUgDQpkZXRhaWxzPC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05UPjwvRElWPjwhLS0gQ29udmVydGVk IGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPg0KPFA+PFNQQU4gbGFuZz1lbi11cz48Qj48ST48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDgwODAgDQpzaXplPTI+UmVnYXJkczwvRk9OVD48L0k+PC9C PjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tdXM+PEI+PEk+PEZPTlQgZmFjZT1BcmlhbCANCmNv bG9yPSMwMDgwODAgc2l6ZT0yPlJhbmppdDwvRk9OVD48L0k+PC9CPjwvU1BBTj4gPC9QPjxCUj48 QlI+DQo8RElWPiZuYnNwOzwvRElWPjxCUj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFk ZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8Rk9O VCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IHNpcC1ib3VuY2VzQGlldGYub3JnIA0K W21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5TdWRoaXIg S3VtYXIgDQpSZWRkeTxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEp1bHkgMTQsIDIwMDUgMTA6 MzMgQU08QlI+PEI+VG86PC9CPiANCnNpcEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gW1Np cF0gcXVlcnkgYWJvdXQgSU1TIGluIA0KU0lQPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj48QlI+SGkgQWxsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIHdv dWxkIGxpa2UgdG8ga25vdyBhYm91dCB0aGUgSU1TIGkuZS4gd2hhdCBpcyB0aGUgYWN0dWFsbHkg cm9sZSBvZiBTSVAgaW4gDQpJTVMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj53YXJt ZXN0IHJlZ2FyZHM8QlI+LS0gPEJSPlN1ZGhpciBLdW1hciBSZWRkeSBUaHVtbWE8QlI+MDk4NjA2 MDc1MSANCjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C58833.E7C80B26-- --===============2007282862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2007282862==-- From sip-bounces@ietf.org Thu Jul 14 01:51:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DswdY-00065m-Oe; Thu, 14 Jul 2005 01:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DswdW-00065U-UD for sip@megatron.ietf.org; Thu, 14 Jul 2005 01:51:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15652 for ; Thu, 14 Jul 2005 01:51:53 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsx62-0000V5-CI for sip@ietf.org; Thu, 14 Jul 2005 02:21:25 -0400 Received: by zproxy.gmail.com with SMTP id 16so190647nzp for ; Wed, 13 Jul 2005 22:51:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ak+nTUanreDaCYFRkFvDo4Z5Ki3+zmy4B/W/dMQVuQkdVPo3G0gEbz+e9pq9s+JcMO7vQXnUDosmPivwEIvenLmD9bAnZgIfWwOcL4gpPkG2PBw4pzdSHIBDD8zqiycPijpn++HXV2dvUmwuoeTGaj+gLzfQfgbE/hVw7w3Vt7k= Received: by 10.36.32.5 with SMTP id f5mr76271nzf; Wed, 13 Jul 2005 22:51:41 -0700 (PDT) Received: by 10.36.106.7 with HTTP; Wed, 13 Jul 2005 22:51:40 -0700 (PDT) Message-ID: <5e0b0aab05071322511582d135@mail.gmail.com> Date: Thu, 14 Jul 2005 11:21:40 +0530 From: Prabhas Sinha To: Avasarala Ranjit-A20990 Subject: Re: [Sip] query about IMS in SIP In-Reply-To: <19B94C8C331A7546A88C88502083353B01888C02@zin24exm02.ap.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19B94C8C331A7546A88C88502083353B01888C02@zin24exm02.ap.mot.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Prabhas Sinha List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At a very high level: ------------------------------ IMS specifications have been laid to harness the 3G network's access technology and also provide multimedia services to wireless devices. IMS subsystem would be aware of the characteristics of the real-time data to be transported, codec to be used, IP addresses alongwith the port numbers, apply error correction, header compression, required QoS etc. beyond what can be achieved over the packet-switched domain. IMS subsystem consists of various SIP proxies referred to as Call Session Control Functions (CSCF). The IMS specifications describes three types of CSCFs: i) Proxy- CSCF: connects wireless device to IMS subsystem ii) Serving - CSCF: provides services to the users, which they subscribe to. Each wireless device is associated with an S-CSCF on SIP registration. The incoming and outgoing sessions passes through it. Home Subscriber Server (HSS) maintains the information about S-CSCF and user's association. HSS knows the users location and subscribed services. iii) Interrogating - CSCF: locates the associated S-CSCF for a user and routes the request to it. For details, please refer to what Ranjit has mentioned. regards, Prabhas On 7/14/05, Avasarala Ranjit-A20990 wrote: > Hi > IMS uses SIP to setup multimedia calls over IP. Refer 3GPP standard = TS > 24.229 for more details >=20 > Regards=20 > Ranjit=20 >=20 > =20 > ________________________________ > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sud= hir > Kumar Reddy > Sent: Thursday, July 14, 2005 10:33 AM > To: sip@ietf.org > Subject: [Sip] query about IMS in SIP >=20 >=20 >=20 > Hi All > =20 > I would like to know about the IMS i.e. what is the actually role of SIP = in > IMS. > =20 > warmest regards > --=20 > Sudhir Kumar Reddy Thumma > 0986060751=20 > _______________________________________________ > Sip mailing list=20 > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 14 02:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxUq-0000Ze-No; Thu, 14 Jul 2005 02:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxUo-0000X1-KQ for sip@megatron.ietf.org; Thu, 14 Jul 2005 02:46:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10445 for ; Thu, 14 Jul 2005 02:46:57 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsxxM-0002P7-Fs for sip@ietf.org; Thu, 14 Jul 2005 03:16:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2005 23:46:48 -0700 X-IronPort-AV: i="3.93,289,1115017200"; d="scan'208"; a="305467738:sNHT66853428" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6E6kjod012931 for ; Wed, 13 Jul 2005 23:46:45 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 02:46:47 -0400 Received: from [192.168.1.146] ([10.86.240.7]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 02:46:47 -0400 Message-ID: <42D60A56.8080809@cisco.com> Date: Thu, 14 Jul 2005 02:46:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2005 06:46:47.0120 (UTC) FILETIME=[CE0CF500:01C5883F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks, I've just submitted an update to the gruu spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-04.txt The changes from -03 are: * included up front discussion on properties of URIs, and how GRUU is merely a property of a URI. Application of other properties is a domain policy and not determinable from inspection of the URI * defined the opaque URI parameter, included grammar for it and a URI parameter registration. Defined its usage with gruu and gave examples of applicability to other things. * usage of the opaque parameter for construction of a GRUU is recommended, unless the anonymity property is also desired. The text describes how a UA can extract the AOR when it has a gruu that was constructed using an opaque parameter * added example algorithm for gruu construction using the opaque parameter, and removed the hashed indices algorithm that was previously there * procedure for allowing an edge proxy to remove itself from the record-route in order to eliminate spirals, was documented * Previously, the REGISTER response didnt need the Require header field with gruu. This is wrong; it does. It is now mandated with MUST strength * updated examples to use recommended basic gruu construction algorithm. It also now uses the conventions in draft-ietf-sipping-torture-tests to deal with long lines in example messages * fixed big bug in grammar, which had omitted the "<" and ">" from the definitions of the +sip.instance contact header field parameter. * a registrar no longer deletes a previous registration with the same instance ID; instead, it simply elects not to use it when proxying a request. This has the same overall effect but is more compatible with the behavior in sipping-outbound. The gruu spec defines procedures for processing requests sent to an AOR and a GRUU as a result * added a paragraph on administratively created gruus for cases where the proxy and UA instance are co-located; for network servers like gateways and voicemail servers, who have public dns entries and IP, they would simply construct a gruu and use it * more detailed recommendations on how to apply the service treatment property to gruus * clarified the usage of the angle brackets in the instance ID Contact parameter. * updated the UML to fix some missing and incorrect cardinalities * there was an example that talked about how two contacts registered to different AOR, but with the same instance ID, would get different gruu. This example incorrectly used the same contact for each AOR, which a client is not supposed to do. This was fixed. * fixed bug in grammar, so that SIPS URI are allowed for a gruu * fixed example register response in the examples section, which was missing the gruu * defined procedures for picking the gruu in an INVITE or 200 OK in the case where an instance has registered against multiple AOR * more precise definitions on when a proxy sends a 404 vs. a 480; a 480 is sent if the AOR of the gruu is known but the instance ID is not * security considerations section has a discussion on why its not that important to hide the aor and instance ID Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 14 03:53:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyXR-0007qI-LQ; Thu, 14 Jul 2005 03:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyXP-0007qD-IH for sip@megatron.ietf.org; Thu, 14 Jul 2005 03:53:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14614 for ; Thu, 14 Jul 2005 03:53:41 -0400 (EDT) Received: from mailgate1.vodafone.co.uk ([194.62.232.133] helo=hlmail01.vfl.vodafone) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsyzx-00056e-OD for sip@ietf.org; Thu, 14 Jul 2005 04:23:15 -0400 Received: from ukwcs01.vf-uk.internal.vodafone.com (ukwcs01 [10.33.127.9]) by hlmail01.vfl.vodafone (8.11.6/8.11.6) with ESMTP id j6E7rEw13912; Thu, 14 Jul 2005 08:53:15 +0100 Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by ukwcs01.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id 6C548AAY; Thu, 14 Jul 2005 08:53:06 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 08:53:05 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 08:53:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 08:53:05 +0100 Message-ID: Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIOQD5J1a2G51GRtSuDN/8J6D78AADsyvw From: "Warren, Dan, VF UK - Technology \(TS\)" To: "Prabhas Sinha" , "Avasarala Ranjit-A20990" X-OriginalArrivalTime: 14 Jul 2005 07:53:04.0772 (UTC) FILETIME=[10EA7C40:01C58849] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just a quick clarification. IMS is not just about wireless technology, = even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were = altered to make them access agnostic and thus allow IMS to be utilised = by any access (DSL, WLAN, FTTx) in such a way that an end user should = receive common service and common touch and feel regardless of how they = get to the IMS domain itself. This paradigm is being used by the ETSI TISPAN work on NGN, where new = service requirements are driving further extensions of IMS to allow for = the deployment of a PSTN-like voice service using IMS. There is also = NGN work based on IMS taking place in ATIS, ITU-T, MSF and others. Also, to clarify the references, 3GPP TS 24.229 defines the SIP profile = used in IMS between CSCF's, AS's and other devices, but there is a lot = more to IMS than just the SIP components - for example the = Diameter-SIP-Application work in AAA WG was originally driven by IMS - = so for an overview of the architecture and signalling flows, you may be = better of looking at 3GPP TS 23.228. You might also like to look at = draft-jesske-sipping-tispan-requirements-01.txt and = draft-jesske-sipping-tispan-analysis-00.txt for some detail of what is = being proposed in terms of new services in TISPAN. Cheers Dan Warren > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Prabhas Sinha > Sent: 14 July 2005 06:52 > To: Avasarala Ranjit-A20990 > Cc: sip@ietf.org > Subject: Re: [Sip] query about IMS in SIP >=20 >=20 > At a very high level: > ------------------------------ > IMS specifications have been laid to harness the 3G network's access > technology and also provide multimedia services to wireless > devices. IMS subsystem would be aware of the > characteristics of the real-time data to be transported, > codec to be used, IP addresses alongwith the port numbers, > apply error correction, header compression, required QoS > etc. beyond what can be achieved over the packet-switched > domain. > IMS subsystem consists of various SIP proxies referred to > as Call Session Control Functions (CSCF). The IMS > specifications describes three types of CSCFs: > i) Proxy- CSCF: connects wireless device to IMS subsystem > ii) Serving - CSCF: provides services to the users, which they > subscribe to. Each wireless device is associated with an S-CSCF on SIP > registration. The > incoming and outgoing sessions passes through it. Home > Subscriber Server (HSS) maintains the information > about S-CSCF and user's association. HSS knows the > users location and subscribed services. > iii) Interrogating - CSCF: locates the associated S-CSCF for a user > and routes the request to it. >=20 > For details, please refer to what Ranjit has mentioned. >=20 > regards, > Prabhas >=20 >=20 >=20 >=20 > On 7/14/05, Avasarala Ranjit-A20990 wrote: > > Hi > > IMS uses SIP to setup multimedia calls over IP. Refer=20 > 3GPP standard TS > > 24.229 for more details > >=20 > > Regards=20 > > Ranjit=20 > >=20 > > =20 > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Sudhir > > Kumar Reddy > > Sent: Thursday, July 14, 2005 10:33 AM > > To: sip@ietf.org > > Subject: [Sip] query about IMS in SIP > >=20 > >=20 > >=20 > > Hi All > > =20 > > I would like to know about the IMS i.e. what is the=20 > actually role of SIP in > > IMS. > > =20 > > warmest regards > > --=20 > > Sudhir Kumar Reddy Thumma > > 0986060751=20 > > _______________________________________________ > > Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 14 04:47:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszNZ-0001Z9-H9; Thu, 14 Jul 2005 04:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszNX-0001Z1-IF for sip@megatron.ietf.org; Thu, 14 Jul 2005 04:47:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18677 for ; Thu, 14 Jul 2005 04:47:33 -0400 (EDT) Received: from 69.red-213-97-128.pooles.rima-tde.net ([213.97.128.69] helo=pc-p1-informatica.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dszq6-0007Nt-7P for sip@ietf.org; Thu, 14 Jul 2005 05:17:07 -0400 Date: Thu, 14 Jul 2005 09:46:33 +0000 To: "Sip" From: "Dean.willis" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------idcaleeophzfzlqekvov" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Re: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ----------idcaleeophzfzlqekvov Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Doll.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/14/2005 08:41 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------idcaleeophzfzlqekvov Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Lovely animals


----------idcaleeophzfzlqekvov Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----------idcaleeophzfzlqekvov-- From sip-bounces@ietf.org Thu Jul 14 09:56:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4CW-0005Dp-Vw; Thu, 14 Jul 2005 09:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4CU-0005AP-6S for sip@megatron.ietf.org; Thu, 14 Jul 2005 09:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10013 for ; Thu, 14 Jul 2005 09:56:28 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4f5-00027C-Pm for sip@ietf.org; Thu, 14 Jul 2005 10:26:05 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 14 Jul 2005 09:58:04 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 09:57:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 09:57:50 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866016BD7@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIOQD5J1a2G51GRtSuDN/8J6D78AADsyvwAAxrDek= From: "Roy, Radhika \(AEAD\)" To: "Warren, Dan, VF UK - Technology \(TS\)" , "Prabhas Sinha" , "Avasarala Ranjit-A20990" X-OriginalArrivalTime: 14 Jul 2005 13:57:59.0932 (UTC) FILETIME=[0B72C3C0:01C5887C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735242021==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0735242021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5887C.06127F88" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5887C.06127F88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline [RRR] ________________________________ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology = (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, = even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were = altered to make them access agnostic and thus allow IMS to be utilised = by any access (DSL, WLAN, FTTx) in such a way that an end user should = receive common service and common touch and feel regardless of how they = get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea = that 3GPP's IMS is propgating the following: The access is specific to = cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear = (instead of individual contributions here and thers assuming that they = do NOT respresent 3GPP) what is their actual motivation for providing = contributions in IETF for creating standards? Is it only specific to = cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C5887C.06127F88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Sip] query about IMS in SIP=0A= =0A= =0A=
=0A=
Inline =0A= [RRR]
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on behalf = of Warren, =0A= Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 3:53 = AM
To: =0A= Prabhas Sinha; Avasarala Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=

Just a quick clarification.  IMS is not just = about wireless =0A= technology, even though it is primarily defined in 3GPP.  In 3GPP = R6, IMS =0A= specs were altered to make them access agnostic and thus allow IMS to be =0A= utilised by any access (DSL, WLAN, FTTx) in such a way that an end user = should =0A= receive common service and common touch and feel regardless of how they = get to =0A= the IMS domain itself.

=0A=

.......

[RRR] It seems to be confusing so far = 3GPP works =0A= are conerned. The idea that 3GPP's IMS is propgating the following: The = access =0A= is specific to cellular wireless, however, cellular wireless users need = to have =0A= services that IMS is defining. So, IMS may have some aspects that = may be =0A= used for other kinds of access technologies like Cable, DSL, Wireless = LANs, =0A= FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW =0A= transformed itself to be access agnostic.

=0A=

[RRR] If 3GPP does so, it will be a mountain = shfit for 3GPP =0A= in its charter, architecture, and requirements to propel in the IETF for = SIP, =0A= SIPPING, AAA, and related WGs. In fact, in another thread in NSIS = for a =0A= contribution on behalf of 3GPP, I mentioned that they should focus on = access =0A= agnostic aspects of QOS in terms of mobility instead of just cellular = wireless =0A= access.

=0A=

[RRR] The question is this: Let us involve 3GPP as a = whole to =0A= make clear (instead of individual contributions here and thers assuming = that =0A= they do NOT respresent 3GPP) what is their actual motivation for = providing =0A= contributions in IETF for creating standards? Is it only specific to = cellular =0A= wireless access? Or, is it access agnostic?

=0A= =0A= =0A= ------_=_NextPart_001_01C5887C.06127F88-- --===============0735242021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0735242021==-- From sip-bounces@ietf.org Thu Jul 14 10:16:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4VQ-0007MV-SE; Thu, 14 Jul 2005 10:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4VO-0007MM-6k for sip@megatron.ietf.org; Thu, 14 Jul 2005 10:16:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11991 for ; Thu, 14 Jul 2005 10:16:00 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4xy-0002pu-PJ for sip@ietf.org; Thu, 14 Jul 2005 10:45:37 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6EEFuuC006260; Thu, 14 Jul 2005 09:15:57 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Jul 2005 15:15:55 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0100E6B83@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Roy, Radhika (AEAD)" Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 15:15:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772912733==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1772912733== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5887E.8A512E00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5887E.8A512E00 Content-Type: text/plain; charset="iso-8859-1" As part of its cooperation with ETSI TISPAN, 3GPP may place information in its specifications that enable reuse by other organisations, as well as those that are requirements for 3GPP operation. Thus while the overall scope of 3GPP specifications will not change, you may find requirements in individual specifications that are not intended to be implemented by networks belonging to operators with GERAN or UTRAN attachments only. These requirements may be endorsed in the specifications of ETSI TISPAN, or other organisations. Thus for example in 3GPP TR 24.819, you will find some proposed amendments to 3GPP TS 24.229 which specify attachment of terminals to an IMS through an XDSL system. These are still work in progress. Finally note that most people in 3GPP participate in IETF as individuals and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP liaison representative appointed by 3GPP TSG SA (along with IETF representation in the oppposite direction). regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Inline [RRR] _____ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were altered to make them access agnostic and thus allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end user should receive common service and common touch and feel regardless of how they get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea that 3GPP's IMS is propgating the following: The access is specific to cellular wireless, however, cellular wireless users need to have services that IMS is defining. So, IMS may have some aspects that may be used for other kinds of access technologies like Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it has NOW transformed itself to be access agnostic. [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its charter, architecture, and requirements to propel in the IETF for SIP, SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a contribution on behalf of 3GPP, I mentioned that they should focus on access agnostic aspects of QOS in terms of mobility instead of just cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear (instead of individual contributions here and thers assuming that they do NOT respresent 3GPP) what is their actual motivation for providing contributions in IETF for creating standards? Is it only specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C5887E.8A512E00 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] query about IMS in SIP
As part of its cooperation with ETSI TISPAN, 3GPP may place information in its specifications that enable reuse by other organisations, as well as those that are requirements for 3GPP operation.
 
Thus while the overall scope of 3GPP specifications will not change, you may find requirements in individual specifications that are not intended to be implemented by networks belonging to operators with GERAN or UTRAN attachments only. These requirements may be endorsed in the specifications of ETSI TISPAN, or other organisations.
 
Thus for example in 3GPP TR 24.819, you will find some proposed amendments to 3GPP TS 24.229 which specify attachment of terminals to an IMS through an XDSL system. These are still work in progress.
 
Finally note that most people in 3GPP participate in IETF as individuals and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP liaison representative appointed by 3GPP TSG SA (along with IETF representation in the oppposite direction).
 
regards
 
Keith
 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD)
Sent: 14 July 2005 14:58
To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

Inline [RRR]

From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 3:53 AM
To: Prabhas Sinha; Avasarala Ranjit-A20990
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

Just a quick clarification.  IMS is not just about wireless technology, even though it is primarily defined in 3GPP.  In 3GPP R6, IMS specs were altered to make them access agnostic and thus allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end user should receive common service and common touch and feel regardless of how they get to the IMS domain itself.

.......

[RRR] It seems to be confusing so far 3GPP works are conerned. The idea that 3GPP's IMS is propgating the following: The access is specific to cellular wireless, however, cellular wireless users need to have services that IMS is defining. So, IMS may have some aspects that may be used for other kinds of access technologies like Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it has NOW transformed itself to be access agnostic.

[RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its charter, architecture, and requirements to propel in the IETF for SIP, SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a contribution on behalf of 3GPP, I mentioned that they should focus on access agnostic aspects of QOS in terms of mobility instead of just cellular wireless access.

[RRR] The question is this: Let us involve 3GPP as a whole to make clear (instead of individual contributions here and thers assuming that they do NOT respresent 3GPP) what is their actual motivation for providing contributions in IETF for creating standards? Is it only specific to cellular wireless access? Or, is it access agnostic?

------_=_NextPart_001_01C5887E.8A512E00-- --===============1772912733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1772912733==-- From sip-bounces@ietf.org Thu Jul 14 10:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4lb-0008Bu-BV; Thu, 14 Jul 2005 10:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4lZ-00089l-9K for sip@megatron.ietf.org; Thu, 14 Jul 2005 10:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13793 for ; Thu, 14 Jul 2005 10:32:43 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt5EC-0003Vn-18 for sip@ietf.org; Thu, 14 Jul 2005 11:02:20 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 14 Jul 2005 10:34:20 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 10:34:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 10:34:12 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866016BD9@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIfsV2TuLg0PxbT6C1G8RS58W9VgAAZoe/ From: "Roy, Radhika \(AEAD\)" To: "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 14 Jul 2005 14:34:21.0463 (UTC) FILETIME=[1FBDFA70:01C58881] X-Spam-Score: 0.6 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0030518145==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0030518145== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58881.1A4AAD2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58881.1A4AAD2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, Good. =20 The question is this: Is 3GPP working for access agnostic specifications = in the IETF? =20 If not, kindly summarize this to us as you seem to be working on behalf = of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of = those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP = members only). =20 Best regards, Radhika ________________________________ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP As part of its cooperation with ETSI TISPAN, 3GPP may place information = in its specifications that enable reuse by other organisations, as well = as those that are requirements for 3GPP operation. =20 Thus while the overall scope of 3GPP specifications will not change, you = may find requirements in individual specifications that are not intended = to be implemented by networks belonging to operators with GERAN or UTRAN = attachments only. These requirements may be endorsed in the = specifications of ETSI TISPAN, or other organisations. =20 Thus for example in 3GPP TR 24.819, you will find some proposed = amendments to 3GPP TS 24.229 which specify attachment of terminals to an = IMS through an XDSL system. These are still work in progress. =20 Finally note that most people in 3GPP participate in IETF as individuals = and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP = liaison representative appointed by 3GPP TSG SA (along with IETF = representation in the oppposite direction). =20 regards =20 Keith =20 Keith Drage=20 Lucent Technologies=20 drage@lucent.com=20 tel: +44 1793 776249=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Inline [RRR] ________________________________ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology = (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Just a quick clarification. IMS is not just about wireless technology, = even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were = altered to make them access agnostic and thus allow IMS to be utilised = by any access (DSL, WLAN, FTTx) in such a way that an end user should = receive common service and common touch and feel regardless of how they = get to the IMS domain itself. ....... =09 [RRR] It seems to be confusing so far 3GPP works are conerned. The idea = that 3GPP's IMS is propgating the following: The access is specific to = cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make = clear (instead of individual contributions here and thers assuming that = they do NOT respresent 3GPP) what is their actual motivation for = providing contributions in IETF for creating standards? Is it only = specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C58881.1A4AAD2C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= RE: [Sip] query about IMS in SIP=0A= =0A= =0A= =0A=
=0A=
OK, = Good.
=0A=
 
=0A=
The question is this: Is 3GPP = working for =0A= access agnostic specifications in the IETF?
=0A=
 
=0A=
If not, kindly summarize this = to us as you =0A= seem to be working on behalf of 3GPP in coordination with 3GPP- IETF = liaison as =0A= we are NOT aware of those 3GPP specs (unlike IETF, access to final specs = are =0A= limited to 3GPP members only).
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Drage, Keith (Keith) =0A= [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15 = AM
To: =0A= Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: = [Sip] =0A= query about IMS in SIP

=0A=
=0A=
As =0A= part of its cooperation with ETSI TISPAN, 3GPP may place information in = its =0A= specifications that enable reuse by other organisations, as well as = those that =0A= are requirements for 3GPP operation.
=0A=
 
=0A=
Thus =0A= while the overall scope of 3GPP specifications will not change, you may = find =0A= requirements in individual specifications that are not intended to be =0A= implemented by networks belonging to operators with GERAN or UTRAN = attachments =0A= only. These requirements may be endorsed in the specifications of ETSI = TISPAN, =0A= or other organisations.
=0A=
 
=0A=
Thus =0A= for example in 3GPP TR 24.819, you will find some proposed amendments to = 3GPP TS =0A= 24.229 which specify attachment of terminals to an IMS through an XDSL = system. =0A= These are still work in progress.
=0A=
 
=0A=
Finally note that most people in 3GPP participate in IETF as = individuals =0A= and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP = liaison =0A= representative appointed by 3GPP TSG SA (along with IETF representation = in the =0A= oppposite direction).
=0A=
 
=0A=
regards
=0A=
 
=0A=
Keith
=0A=
 
=0A=
=0A=

Keith Drage
Lucent =0A= Technologies
drage@lucent.com =0A=
tel: +44 1793 776249 =

=0A=
=0A=
-----Original Message-----
From: = sip-bounces@ietf.org =0A= [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika =0A= (AEAD)
Sent: 14 July 2005 14:58
To: Warren, Dan, = VF UK - =0A= Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=
Inline =0A= [RRR]
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on = behalf of =0A= Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 = 3:53 =0A= AM
To: Prabhas Sinha; Avasarala Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=

Just a quick clarification.  IMS is not just = about =0A= wireless technology, even though it is primarily defined in = 3GPP.  In =0A= 3GPP R6, IMS specs were altered to make them access agnostic and thus = allow =0A= IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that = an end =0A= user should receive common service and common touch and feel = regardless of how =0A= they get to the IMS domain itself.

=0A=

.......

[RRR] It seems to be confusing so far = 3GPP =0A= works are conerned. The idea that 3GPP's IMS is propgating the = following: The =0A= access is specific to cellular wireless, however, cellular wireless = users need =0A= to have services that IMS is defining. So, IMS may have some = aspects that =0A= may be used for other kinds of access technologies like Cable, DSL, = Wireless =0A= LANs, FTTx, and others, but 3GPP has NEVER defined any criteria = that it =0A= has NOW transformed itself to be access agnostic.

=0A=

[RRR] If 3GPP does so, it will be a mountain = shfit for =0A= 3GPP in its charter, architecture, and requirements to propel in the = IETF for =0A= SIP, SIPPING, AAA, and related WGs. In fact, in another thread in = NSIS =0A= for a contribution on behalf of 3GPP, I mentioned that they should = focus on =0A= access agnostic aspects of QOS in terms of mobility instead of just = cellular =0A= wireless access.

=0A=

[RRR] The question is this: Let us involve 3GPP as a = whole to =0A= make clear (instead of individual contributions here and thers = assuming that =0A= they do NOT respresent 3GPP) what is their actual motivation for = providing =0A= contributions in IETF for creating standards? Is it only specific to = cellular =0A= wireless access? Or, is it access =0A= agnostic?

=0A= ------_=_NextPart_001_01C58881.1A4AAD2C-- --===============0030518145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0030518145==-- From sip-bounces@ietf.org Thu Jul 14 10:48:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt50g-0007KN-6G; Thu, 14 Jul 2005 10:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt50e-0007Hc-Br for sip@megatron.ietf.org; Thu, 14 Jul 2005 10:48:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15400 for ; Thu, 14 Jul 2005 10:48:18 -0400 (EDT) Received: from mailgate2.vodafone.co.uk ([194.62.232.134] helo=hlmail02.vfl.vodafone) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt5TG-00047S-TY for sip@ietf.org; Thu, 14 Jul 2005 11:17:55 -0400 Received: from ukwcs06.vf-uk.internal.vodafone.com (ukwcs06 [10.33.112.206]) by hlmail02.vfl.vodafone (8.11.6/8.11.6) with ESMTP id j6EEm0i01873; Thu, 14 Jul 2005 15:48:00 +0100 Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by ukwcs06.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id K0954AA2; Thu, 14 Jul 2005 15:47:56 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 15:47:56 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 15:47:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 15:47:55 +0100 Message-ID: Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIfsV2TuLg0PxbT6C1G8RS58W9VgAAZoe/AAB0rlA= From: "Warren, Dan, VF UK - Technology \(TS\)" To: "Roy, Radhika \(AEAD\)" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 14 Jul 2005 14:47:55.0832 (UTC) FILETIME=[0524D380:01C58883] X-Spam-Score: 0.6 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0272171171==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0272171171== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58883.04CE7E14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58883.04CE7E14 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First thanks to Keith for summarising what I was about to post very long = windedly. =20 Second, 3GPP specs ARE available in their final versions without the = need for 3GPP membership. Go to www.3gpp.org, click specifications and = you can download all and any (including drafts of specs being worked = on). =20 =20 Last, 3GPP is working for extensions and definitions in IETF that enable = IMS to support all and any access type. There will be some access = dependent elements in the specification but they will not be mandatory = requirements. The variations will depend on the nature of the service = being provided. For example the current debate on the SIPPING list with = regard to the regulatory requirements on voice services is in some cases = not applicable to a mobile voice service but is of very real concern to = fixed line voice service providers. One only needs to see what is = happening between Skype and the FCC to see what can happen when = regulatory considerations are not adhered to by voice providers. =20 Cheers =20 Dan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP OK, Good. =20 The question is this: Is 3GPP working for access agnostic specifications = in the IETF? =20 If not, kindly summarize this to us as you seem to be working on behalf = of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of = those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP = members only). =20 Best regards, Radhika _____ =20 From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP As part of its cooperation with ETSI TISPAN, 3GPP may place information = in its specifications that enable reuse by other organisations, as well = as those that are requirements for 3GPP operation. =20 Thus while the overall scope of 3GPP specifications will not change, you = may find requirements in individual specifications that are not intended = to be implemented by networks belonging to operators with GERAN or UTRAN = attachments only. These requirements may be endorsed in the = specifications of ETSI TISPAN, or other organisations. =20 Thus for example in 3GPP TR 24.819, you will find some proposed = amendments to 3GPP TS 24.229 which specify attachment of terminals to an = IMS through an XDSL system. These are still work in progress. =20 Finally note that most people in 3GPP participate in IETF as individuals = and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP = liaison representative appointed by 3GPP TSG SA (along with IETF = representation in the oppposite direction). =20 regards =20 Keith =20 Keith Drage=20 Lucent Technologies=20 drage@lucent.com=20 tel: +44 1793 776249=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Inline [RRR] _____ =20 From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology = (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, = even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were = altered to make them access agnostic and thus allow IMS to be utilised = by any access (DSL, WLAN, FTTx) in such a way that an end user should = receive common service and common touch and feel regardless of how they = get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea = that 3GPP's IMS is propgating the following: The access is specific to = cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear = (instead of individual contributions here and thers assuming that they = do NOT respresent 3GPP) what is their actual motivation for providing = contributions in IETF for creating standards? Is it only specific to = cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C58883.04CE7E14 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] query about IMS in SIP
First=20 thanks to Keith for summarising what I was about to post very long=20 windedly.
 
Second, 3GPP specs ARE available in their = final=20 versions without the need for 3GPP membership.  Go to www.3gpp.org, click specifications and = you can=20 download all and any (including drafts of specs being worked on). =20
 
Last,=20 3GPP is working for extensions and definitions in IETF that enable IMS = to=20 support all and any access type.  There will be some access = dependent=20 elements in the specification but they will not be mandatory = requirements. =20 The variations will depend on the nature of the service being = provided. =20 For example the current debate on the SIPPING list with regard to the = regulatory=20 requirements on voice services is in some cases not applicable to a = mobile voice=20 service but is of very real concern to fixed line voice service = providers. =20 One only needs to see what is happening between Skype and the FCC to see = what=20 can happen when regulatory considerations are not adhered to by voice=20 providers.
 
Cheers
 
Dan
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: 14 July 2005 15:34
To: Drage, Keith=20 (Keith)
Cc: sip@ietf.org
Subject: RE: [Sip] query = about=20 IMS in SIP

OK, = Good.
 
The question is this: Is = 3GPP working for=20 access agnostic specifications in the IETF?
 
If not, kindly summarize = this to us as=20 you seem to be working on behalf of 3GPP in coordination with 3GPP- = IETF=20 liaison as we are NOT aware of those 3GPP specs (unlike IETF, access = to final=20 specs are limited to 3GPP members only).
 
Best regards,
Radhika

From: Drage, Keith (Keith)=20 [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15 = AM
To:=20 Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 query about IMS in SIP

As=20 part of its cooperation with ETSI TISPAN, 3GPP may place information = in its=20 specifications that enable reuse by other organisations, as well as = those that=20 are requirements for 3GPP operation.
 
Thus=20 while the overall scope of 3GPP specifications will not change, you = may find=20 requirements in individual specifications that are not intended to be=20 implemented by networks belonging to operators with GERAN or UTRAN = attachments=20 only. These requirements may be endorsed in the specifications of ETSI = TISPAN,=20 or other organisations.
 
Thus=20 for example in 3GPP TR 24.819, you will find some proposed amendments = to 3GPP=20 TS 24.229 which specify attachment of terminals to an IMS through an = XDSL=20 system. These are still work in progress.
 
Finally note that most people in 3GPP participate in IETF as=20 individuals and not as representatives of 3GPP, see RFC 3113. There is = only=20 one 3GPP liaison representative appointed by 3GPP TSG SA (along with = IETF=20 representation in the oppposite direction).
 
regards
 
Keith
 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: = +44 1793=20 776249

-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: 14 July 2005 14:58
To: Warren, Dan, = VF UK -=20 Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Inline=20 [RRR]

From: sip-bounces@ietf.org on = behalf of=20 Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 = 3:53=20 AM
To: Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Just a quick clarification.  IMS is not just = about=20 wireless technology, even though it is primarily defined in = 3GPP.  In=20 3GPP R6, IMS specs were altered to make them access agnostic and = thus allow=20 IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way = that an end=20 user should receive common service and common touch and feel = regardless of=20 how they get to the IMS domain itself.

.......

[RRR] It seems to be confusing so = far 3GPP=20 works are conerned. The idea that 3GPP's IMS is propgating the = following:=20 The access is specific to cellular wireless, however, cellular = wireless=20 users need to have services that IMS is defining. So, IMS may = have some=20 aspects that may be used for other kinds of access technologies like = Cable,=20 DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER = defined any=20 criteria that it has NOW transformed itself to be access agnostic.=20

[RRR] If 3GPP does so, it will be a mountain = shfit for=20 3GPP in its charter, architecture, and requirements to propel in the = IETF=20 for SIP, SIPPING, AAA, and related WGs. In fact, in another = thread in=20 NSIS for a contribution on behalf of 3GPP, I mentioned that they = should=20 focus on access agnostic aspects of QOS in terms of mobility instead = of just=20 cellular wireless access.

[RRR] The question is this: Let us involve 3GPP as = a whole=20 to make clear (instead of individual contributions here and thers = assuming=20 that they do NOT respresent 3GPP) what is their actual motivation = for=20 providing contributions in IETF for creating standards? Is it only = specific=20 to cellular wireless access? Or, is it access=20 = agnostic?

------_=_NextPart_001_01C58883.04CE7E14-- --===============0272171171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0272171171==-- From sip-bounces@ietf.org Thu Jul 14 10:59:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5Ay-0001jl-3C; Thu, 14 Jul 2005 10:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5Aw-0001iW-IH for sip@megatron.ietf.org; Thu, 14 Jul 2005 10:58:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17157 for ; Thu, 14 Jul 2005 10:58:56 -0400 (EDT) Received: from mailgate2.vodafone.co.uk ([194.62.232.134] helo=hlmail02.vfl.vodafone) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt5dY-0004rm-UO for sip@ietf.org; Thu, 14 Jul 2005 11:28:34 -0400 Received: from ukwcs02.vf-uk.internal.vodafone.com (ukwcs02 [10.33.112.204]) by hlmail02.vfl.vodafone (8.11.6/8.11.6) with ESMTP id j6EEwli06273; Thu, 14 Jul 2005 15:58:47 +0100 Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by ukwcs02.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id 72fd6AAI; Thu, 14 Jul 2005 15:58:43 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 15:58:42 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Thu, 14 Jul 2005 15:58:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 15:58:41 +0100 Message-ID: Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIfsV2TuLg0PxbT6C1G8RS58W9VgAAZoe/AAB0rlAAAIZPsA== From: "Warren, Dan, VF UK - Technology \(TS\)" To: "Warren, Dan, VF UK - Technology \(TS\)" , "Roy, Radhika \(AEAD\)" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 14 Jul 2005 14:58:42.0519 (UTC) FILETIME=[86996E70:01C58884] X-Spam-Score: 0.9 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1762322081==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1762322081== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58884.860BB4E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58884.860BB4E1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Got carried away there... TISPAN is working for extensions in IETF. = Those extensions will then ultimately be incorporated in new versions of = existing 3GPP specifications. =20 But then we're all one big happy family in ETSI land. =20 Dan =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Warren, Dan, VF UK - Technology (TS) Sent: 14 July 2005 15:48 To: Roy, Radhika (AEAD); Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP First thanks to Keith for summarising what I was about to post very long = windedly. =20 Second, 3GPP specs ARE available in their final versions without the = need for 3GPP membership. Go to www.3gpp.org, click specifications and = you can download all and any (including drafts of specs being worked = on). =20 =20 Last, 3GPP is working for extensions and definitions in IETF that enable = IMS to support all and any access type. There will be some access = dependent elements in the specification but they will not be mandatory = requirements. The variations will depend on the nature of the service = being provided. For example the current debate on the SIPPING list with = regard to the regulatory requirements on voice services is in some cases = not applicable to a mobile voice service but is of very real concern to = fixed line voice service providers. One only needs to see what is = happening between Skype and the FCC to see what can happen when = regulatory considerations are not adhered to by voice providers. =20 Cheers =20 Dan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP OK, Good. =20 The question is this: Is 3GPP working for access agnostic specifications = in the IETF? =20 If not, kindly summarize this to us as you seem to be working on behalf = of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of = those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP = members only). =20 Best regards, Radhika _____ =20 From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP As part of its cooperation with ETSI TISPAN, 3GPP may place information = in its specifications that enable reuse by other organisations, as well = as those that are requirements for 3GPP operation. =20 Thus while the overall scope of 3GPP specifications will not change, you = may find requirements in individual specifications that are not intended = to be implemented by networks belonging to operators with GERAN or UTRAN = attachments only. These requirements may be endorsed in the = specifications of ETSI TISPAN, or other organisations. =20 Thus for example in 3GPP TR 24.819, you will find some proposed = amendments to 3GPP TS 24.229 which specify attachment of terminals to an = IMS through an XDSL system. These are still work in progress. =20 Finally note that most people in 3GPP participate in IETF as individuals = and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP = liaison representative appointed by 3GPP TSG SA (along with IETF = representation in the oppposite direction). =20 regards =20 Keith =20 Keith Drage=20 Lucent Technologies=20 drage@lucent.com=20 tel: +44 1793 776249=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Inline [RRR] _____ =20 From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology = (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, = even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were = altered to make them access agnostic and thus allow IMS to be utilised = by any access (DSL, WLAN, FTTx) in such a way that an end user should = receive common service and common touch and feel regardless of how they = get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea = that 3GPP's IMS is propgating the following: The access is specific to = cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear = (instead of individual contributions here and thers assuming that they = do NOT respresent 3GPP) what is their actual motivation for providing = contributions in IETF for creating standards? Is it only specific to = cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C58884.860BB4E1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] query about IMS in SIP
Got=20 carried away there... TISPAN is working for extensions in IETF.  = Those=20 extensions will then ultimately be incorporated in new versions of = existing 3GPP=20 specifications.
 
But=20 then we're all one big happy family in ETSI land.
 
Dan
 
 
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Warren, Dan, VF UK -=20 Technology (TS)
Sent: 14 July 2005 15:48
To: Roy, = Radhika=20 (AEAD); Drage, Keith (Keith)
Cc: = sip@ietf.org
Subject: RE:=20 [Sip] query about IMS in SIP

First thanks to Keith for summarising what = I was=20 about to post very long windedly.
 
Second, 3GPP specs ARE available in their = final=20 versions without the need for 3GPP membership.  Go to www.3gpp.org, click specifications = and you can=20 download all and any (including drafts of specs being worked = on). =20
 
Last, 3GPP is working for extensions and = definitions=20 in IETF that enable IMS to support all and any access type.  = There will=20 be some access dependent elements in the specification but they will = not be=20 mandatory requirements.  The variations will depend on the nature = of the=20 service being provided.  For example the current debate on the = SIPPING=20 list with regard to the regulatory requirements on voice services is = in some=20 cases not applicable to a mobile voice service but is of very real = concern to=20 fixed line voice service providers.  One only needs to see what = is=20 happening between Skype and the FCC to see what can happen when = regulatory=20 considerations are not adhered to by voice = providers.
 
Cheers
 
Dan
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: 14 July 2005 15:34
To: Drage, Keith = (Keith)
Cc: sip@ietf.org
Subject: RE: [Sip] = query about=20 IMS in SIP

OK, = Good.
 
The question is this: Is = 3GPP working=20 for access agnostic specifications in the IETF?
 
If not, kindly summarize = this to us as=20 you seem to be working on behalf of 3GPP in coordination with 3GPP- = IETF=20 liaison as we are NOT aware of those 3GPP specs (unlike IETF, access = to=20 final specs are limited to 3GPP members only).
 
Best = regards,
Radhika

From: Drage, Keith (Keith)=20 [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15=20 AM
To: Roy, Radhika (AEAD)
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

As=20 part of its cooperation with ETSI TISPAN, 3GPP may place information = in its=20 specifications that enable reuse by other organisations, as well as = those=20 that are requirements for 3GPP operation.
 
Thus while the overall scope of 3GPP specifications will = not change,=20 you may find requirements in individual specifications that are not = intended=20 to be implemented by networks belonging to operators with GERAN or = UTRAN=20 attachments only. These requirements may be endorsed in the = specifications=20 of ETSI TISPAN, or other organisations.
 
Thus for example in 3GPP TR 24.819, you will find some = proposed=20 amendments to 3GPP TS 24.229 which specify attachment of terminals = to an IMS=20 through an XDSL system. These are still work in=20 progress.
 
Finally note that most people in 3GPP participate in IETF = as=20 individuals and not as representatives of 3GPP, see RFC 3113. There = is only=20 one 3GPP liaison representative appointed by 3GPP TSG SA (along with = IETF=20 representation in the oppposite direction).
 
regards
 
Keith
 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793=20 776249

-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: 14 July 2005 14:58
To: Warren, = Dan, VF UK=20 - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Inline=20 [RRR]

From: sip-bounces@ietf.org on = behalf of=20 Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 = 3:53=20 AM
To: Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Just a quick clarification.  IMS is not = just about=20 wireless technology, even though it is primarily defined in = 3GPP.  In=20 3GPP R6, IMS specs were altered to make them access agnostic and = thus=20 allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a = way=20 that an end user should receive common service and common touch = and feel=20 regardless of how they get to the IMS domain itself.

.......

[RRR] It seems to be confusing so = far 3GPP=20 works are conerned. The idea that 3GPP's IMS is propgating the = following:=20 The access is specific to cellular wireless, however, cellular = wireless=20 users need to have services that IMS is defining. So, IMS may = have=20 some aspects that may be used for other kinds of access = technologies like=20 Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has = NEVER=20 defined any criteria that it has NOW transformed itself to be = access=20 agnostic.

[RRR] If 3GPP does so, it will be a = mountain shfit=20 for 3GPP in its charter, architecture, and requirements to propel = in the=20 IETF for SIP, SIPPING, AAA, and related WGs. In fact, in = another=20 thread in NSIS for a contribution on behalf of 3GPP, I mentioned = that they=20 should focus on access agnostic aspects of QOS in terms of = mobility=20 instead of just cellular wireless access.

[RRR] The question is this: Let us involve 3GPP = as a whole=20 to make clear (instead of individual contributions here and thers = assuming=20 that they do NOT respresent 3GPP) what is their actual motivation = for=20 providing contributions in IETF for creating standards? Is it only = specific to cellular wireless access? Or, is it access=20 = agnostic?

------_=_NextPart_001_01C58884.860BB4E1-- --===============1762322081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1762322081==-- From sip-bounces@ietf.org Thu Jul 14 11:52:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt619-0003LQ-Bp; Thu, 14 Jul 2005 11:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt616-0003Dn-DY for sip@megatron.ietf.org; Thu, 14 Jul 2005 11:52:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24172 for ; Thu, 14 Jul 2005 11:52:49 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6Tj-0007rC-NE for sip@ietf.org; Thu, 14 Jul 2005 12:22:28 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6EFql0Q022791; Thu, 14 Jul 2005 10:52:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Jul 2005 16:52:46 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0100E6BCF@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Roy, Radhika (AEAD)" Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 16:52:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612663731==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0612663731== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5888C.05E0145C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5888C.05E0145C Content-Type: text/plain; charset="iso-8859-1" I referred in my original mail to RFC 3113, which I assume you can gain access to without further subscription or payment. This tells you exactly how you gain access to 3GPP documents, and that they are available to everybody with IP access. Indeed if you look in the right place you can gain access to every version of every specification (bar about 3 on the security algorithms) that has existed electronically. Similarly you can also gain access to the vast majority of the internal working documents that have existed since 3GPP was created, if you really have the patience to work through them. Obviously 3GPP specifications are published by the member SDOs, but as far as I understand, none of the publishing SDOs amend the contents of those 3GPP specifications from those appearing on the 3GPP site, and indeed the ETSI ones are also available free of charge for the minor pain of giving your name and email address before you obtain them. regards Keith -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP OK, Good. The question is this: Is 3GPP working for access agnostic specifications in the IETF? If not, kindly summarize this to us as you seem to be working on behalf of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP members only). Best regards, Radhika _____ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP As part of its cooperation with ETSI TISPAN, 3GPP may place information in its specifications that enable reuse by other organisations, as well as those that are requirements for 3GPP operation. Thus while the overall scope of 3GPP specifications will not change, you may find requirements in individual specifications that are not intended to be implemented by networks belonging to operators with GERAN or UTRAN attachments only. These requirements may be endorsed in the specifications of ETSI TISPAN, or other organisations. Thus for example in 3GPP TR 24.819, you will find some proposed amendments to 3GPP TS 24.229 which specify attachment of terminals to an IMS through an XDSL system. These are still work in progress. Finally note that most people in 3GPP participate in IETF as individuals and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP liaison representative appointed by 3GPP TSG SA (along with IETF representation in the oppposite direction). regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Inline [RRR] _____ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were altered to make them access agnostic and thus allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end user should receive common service and common touch and feel regardless of how they get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea that 3GPP's IMS is propgating the following: The access is specific to cellular wireless, however, cellular wireless users need to have services that IMS is defining. So, IMS may have some aspects that may be used for other kinds of access technologies like Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it has NOW transformed itself to be access agnostic. [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its charter, architecture, and requirements to propel in the IETF for SIP, SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a contribution on behalf of 3GPP, I mentioned that they should focus on access agnostic aspects of QOS in terms of mobility instead of just cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear (instead of individual contributions here and thers assuming that they do NOT respresent 3GPP) what is their actual motivation for providing contributions in IETF for creating standards? Is it only specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C5888C.05E0145C Content-Type: text/html; charset="iso-8859-1" RE: [Sip] query about IMS in SIP
I referred in my original mail to RFC 3113, which I assume you can gain access to without further subscription or payment.
 
This tells you exactly how you gain access to 3GPP documents, and that they are available to everybody with IP access.
 
Indeed if you look in the right place you can gain access to every version of every specification (bar about 3 on the security algorithms) that has existed electronically. Similarly you can also gain access to the vast majority of the internal working documents that have existed since 3GPP was created, if you really have the patience to work through them.
 
Obviously 3GPP specifications are published by the member SDOs, but as far as I understand, none of the publishing SDOs amend the contents of those 3GPP specifications from those appearing on the 3GPP site, and indeed the ETSI ones are also available free of charge for the minor pain of giving your name and email address before you obtain them.
 
regards
 
Keith
 
-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: 14 July 2005 15:34
To: Drage, Keith (Keith)
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

OK, Good.
 
The question is this: Is 3GPP working for access agnostic specifications in the IETF?
 
If not, kindly summarize this to us as you seem to be working on behalf of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP members only).
 
Best regards,
Radhika

From: Drage, Keith (Keith) [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15 AM
To: Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

As part of its cooperation with ETSI TISPAN, 3GPP may place information in its specifications that enable reuse by other organisations, as well as those that are requirements for 3GPP operation.
 
Thus while the overall scope of 3GPP specifications will not change, you may find requirements in individual specifications that are not intended to be implemented by networks belonging to operators with GERAN or UTRAN attachments only. These requirements may be endorsed in the specifications of ETSI TISPAN, or other organisations.
 
Thus for example in 3GPP TR 24.819, you will find some proposed amendments to 3GPP TS 24.229 which specify attachment of terminals to an IMS through an XDSL system. These are still work in progress.
 
Finally note that most people in 3GPP participate in IETF as individuals and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP liaison representative appointed by 3GPP TSG SA (along with IETF representation in the oppposite direction).
 
regards
 
Keith
 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD)
Sent: 14 July 2005 14:58
To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

Inline [RRR]

From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 3:53 AM
To: Prabhas Sinha; Avasarala Ranjit-A20990
Cc: sip@ietf.org
Subject: RE: [Sip] query about IMS in SIP

Just a quick clarification.  IMS is not just about wireless technology, even though it is primarily defined in 3GPP.  In 3GPP R6, IMS specs were altered to make them access agnostic and thus allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end user should receive common service and common touch and feel regardless of how they get to the IMS domain itself.

.......

[RRR] It seems to be confusing so far 3GPP works are conerned. The idea that 3GPP's IMS is propgating the following: The access is specific to cellular wireless, however, cellular wireless users need to have services that IMS is defining. So, IMS may have some aspects that may be used for other kinds of access technologies like Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it has NOW transformed itself to be access agnostic.

[RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its charter, architecture, and requirements to propel in the IETF for SIP, SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a contribution on behalf of 3GPP, I mentioned that they should focus on access agnostic aspects of QOS in terms of mobility instead of just cellular wireless access.

[RRR] The question is this: Let us involve 3GPP as a whole to make clear (instead of individual contributions here and thers assuming that they do NOT respresent 3GPP) what is their actual motivation for providing contributions in IETF for creating standards? Is it only specific to cellular wireless access? Or, is it access agnostic?

------_=_NextPart_001_01C5888C.05E0145C-- --===============0612663731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0612663731==-- From sip-bounces@ietf.org Thu Jul 14 15:36:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9VB-0007zf-LE; Thu, 14 Jul 2005 15:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9V9-0007zH-Je for sip@megatron.ietf.org; Thu, 14 Jul 2005 15:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12785 for ; Thu, 14 Jul 2005 15:36:04 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9xl-00080A-ET for sip@ietf.org; Thu, 14 Jul 2005 16:05:44 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 14 Jul 2005 15:37:38 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 15:37:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 15:37:30 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866016BDC@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIfsV2TuLg0PxbT6C1G8RS58W9VgAAZoe/AAB0rlAAAIZPsAAJZTZ8 From: "Roy, Radhika \(AEAD\)" To: "Warren, Dan, VF UK - Technology \(TS\)" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 14 Jul 2005 19:37:39.0448 (UTC) FILETIME=[7E961F80:01C588AB] X-Spam-Score: 0.9 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1868144996==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1868144996== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C588AB.790FA702" This is a multi-part message in MIME format. ------_=_NextPart_001_01C588AB.790FA702 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Excellent! =20 In fact, let me summarize as follows: =20 1. Contributions are being made (or will be made) keeping the big = picture in mind that include the entire ETSI family including 3GPP. =20 2. Primary focus of standardization in the IETF from ETSI point of view = is "Access Independent." These contributions will generally be along the = line of the standard track RFCs. =20 3. Some contributions many be "access-specific (e.g., cellular wireless, = Wireless LANs, others)," and may have some optional features. Most = likely, they will be "Informational RFCs." =20 4. Regulatory features might also influence some aspects = standardization. =20 Now, it will help us to review the contributions (ETSI/3GPP) focusing = the above. =20 Many thanks for clarifications. =20 Best regards, Radhika ________________________________ From: Warren, Dan, VF UK - Technology (TS) = [mailto:Dan.Warren@vodafone.com] Sent: Thu 7/14/2005 10:58 AM To: Warren, Dan, VF UK - Technology (TS); Roy, Radhika (AEAD); Drage, = Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Got carried away there... TISPAN is working for extensions in IETF. = Those extensions will then ultimately be incorporated in new versions of = existing 3GPP specifications. =20 But then we're all one big happy family in ETSI land. =20 Dan =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Warren, Dan, VF UK - Technology (TS) Sent: 14 July 2005 15:48 To: Roy, Radhika (AEAD); Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 First thanks to Keith for summarising what I was about to post very = long windedly. =20 Second, 3GPP specs ARE available in their final versions without the = need for 3GPP membership. Go to www.3gpp.org, click specifications and = you can download all and any (including drafts of specs being worked = on). =20 =20 Last, 3GPP is working for extensions and definitions in IETF that = enable IMS to support all and any access type. There will be some = access dependent elements in the specification but they will not be = mandatory requirements. The variations will depend on the nature of the = service being provided. For example the current debate on the SIPPING = list with regard to the regulatory requirements on voice services is in = some cases not applicable to a mobile voice service but is of very real = concern to fixed line voice service providers. One only needs to see = what is happening between Skype and the FCC to see what can happen when = regulatory considerations are not adhered to by voice providers. =20 Cheers =20 Dan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 OK, Good. =20 The question is this: Is 3GPP working for access agnostic = specifications in the IETF? =20 If not, kindly summarize this to us as you seem to be working on = behalf of 3GPP in coordination with 3GPP- IETF liaison as we are NOT = aware of those 3GPP specs (unlike IETF, access to final specs are = limited to 3GPP members only). =20 Best regards, Radhika ________________________________ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 As part of its cooperation with ETSI TISPAN, 3GPP may place = information in its specifications that enable reuse by other = organisations, as well as those that are requirements for 3GPP = operation. =20 Thus while the overall scope of 3GPP specifications will not change, = you may find requirements in individual specifications that are not = intended to be implemented by networks belonging to operators with GERAN = or UTRAN attachments only. These requirements may be endorsed in the = specifications of ETSI TISPAN, or other organisations. =20 Thus for example in 3GPP TR 24.819, you will find some proposed = amendments to 3GPP TS 24.229 which specify attachment of terminals to an = IMS through an XDSL system. These are still work in progress. =20 Finally note that most people in 3GPP participate in IETF as = individuals and not as representatives of 3GPP, see RFC 3113. There is = only one 3GPP liaison representative appointed by 3GPP TSG SA (along = with IETF representation in the oppposite direction). =20 regards =20 Keith =20 Keith Drage=20 Lucent Technologies=20 drage@lucent.com=20 tel: +44 1793 776249=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Inline [RRR] ________________________________ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - = Technology (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Just a quick clarification. IMS is not just about wireless = technology, even though it is primarily defined in 3GPP. In 3GPP R6, = IMS specs were altered to make them access agnostic and thus allow IMS = to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end = user should receive common service and common touch and feel regardless = of how they get to the IMS domain itself. ....... =09 [RRR] It seems to be confusing so far 3GPP works are conerned. The = idea that 3GPP's IMS is propgating the following: The access is specific = to cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make = clear (instead of individual contributions here and thers assuming that = they do NOT respresent 3GPP) what is their actual motivation for = providing contributions in IETF for creating standards? Is it only = specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C588AB.790FA702 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= RE: [Sip] query about IMS in SIP=0A= =0A= =0A= =0A=
=0A=
Excellent!
=0A=
 
=0A=
In fact, let me summarize as =0A= follows:
=0A=
 
=0A=
1. Contributions are being = made (or will be =0A= made) keeping the big picture in mind that include the entire ETSI = family =0A= including 3GPP.
=0A=
 
=0A=
2. Primary focus of = standardization in the =0A= IETF from ETSI point of view is "Access Independent." These = contributions will =0A= generally be along the line of the standard track RFCs.
=0A=
 
=0A=
3. Some contributions many be =0A= "access-specific (e.g., cellular wireless, Wireless LANs, others)," and =0A= may have some optional features. Most likely, they will be = "Informational =0A= RFCs."
=0A=
 
=0A=
4. Regulatory features might = also influence =0A= some aspects standardization.
=0A=
 
=0A=
Now, it will help us to = review the =0A= contributions (ETSI/3GPP) focusing the above.
=0A=
 
=0A=
Many thanks for =0A= clarifications.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Warren, Dan, VF UK - = Technology (TS) =0A= [mailto:Dan.Warren@vodafone.com]
Sent: Thu 7/14/2005 10:58 =0A= AM
To: Warren, Dan, VF UK - Technology (TS); Roy, Radhika = (AEAD); =0A= Drage, Keith (Keith)
Cc: sip@ietf.org
Subject: RE: = [Sip] =0A= query about IMS in SIP

=0A=
=0A=
Got =0A= carried away there... TISPAN is working for extensions in IETF.  = Those =0A= extensions will then ultimately be incorporated in new versions of = existing 3GPP =0A= specifications.
=0A=
 
=0A=
But =0A= then we're all one big happy family in ETSI land.
=0A=
 
=0A=
Dan
=0A=
 
=0A=
 
=0A=
=0A=
-----Original Message-----
From: = sip-bounces@ietf.org =0A= [mailto:sip-bounces@ietf.org]On Behalf Of Warren, Dan, VF UK - =0A= Technology (TS)
Sent: 14 July 2005 15:48
To: Roy, = Radhika =0A= (AEAD); Drage, Keith (Keith)
Cc: = sip@ietf.org
Subject: RE: =0A= [Sip] query about IMS in SIP

=0A=
First thanks to Keith for summarising what = I was =0A= about to post very long windedly.
=0A=
 
=0A=
Second, 3GPP specs ARE available in their = final =0A= versions without the need for 3GPP membership.  Go to www.3gpp.org, click specifications = and you can =0A= download all and any (including drafts of specs being worked = on).  =0A=
=0A=
 
=0A=
Last, 3GPP is working for extensions and = definitions =0A= in IETF that enable IMS to support all and any access type.  = There will =0A= be some access dependent elements in the specification but they will = not be =0A= mandatory requirements.  The variations will depend on the nature = of the =0A= service being provided.  For example the current debate on the = SIPPING =0A= list with regard to the regulatory requirements on voice services is = in some =0A= cases not applicable to a mobile voice service but is of very real = concern to =0A= fixed line voice service providers.  One only needs to see what = is =0A= happening between Skype and the FCC to see what can happen when = regulatory =0A= considerations are not adhered to by voice = providers.
=0A=
 
=0A=
Cheers
=0A=
 
=0A=
Dan
=0A=
=0A=
-----Original Message-----
From: = sip-bounces@ietf.org =0A= [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika =0A= (AEAD)
Sent: 14 July 2005 15:34
To: Drage, Keith =0A= (Keith)
Cc: sip@ietf.org
Subject: RE: [Sip] = query about =0A= IMS in SIP

=0A=
=0A=
OK, = Good.
=0A=
 
=0A=
The question is this: Is = 3GPP working =0A= for access agnostic specifications in the IETF?
=0A=
 
=0A=
If not, kindly summarize = this to us as =0A= you seem to be working on behalf of 3GPP in coordination with 3GPP- = IETF =0A= liaison as we are NOT aware of those 3GPP specs (unlike IETF, access = to =0A= final specs are limited to 3GPP members only).
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Drage, Keith (Keith) =0A= [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15 =0A= AM
To: Roy, Radhika (AEAD)
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=
As =0A= part of its cooperation with ETSI TISPAN, 3GPP may place information = in its =0A= specifications that enable reuse by other organisations, as well as = those =0A= that are requirements for 3GPP operation.
=0A=
 
=0A=
Thus while the overall scope of 3GPP specifications will = not change, =0A= you may find requirements in individual specifications that are not = intended =0A= to be implemented by networks belonging to operators with GERAN or = UTRAN =0A= attachments only. These requirements may be endorsed in the = specifications =0A= of ETSI TISPAN, or other organisations.
=0A=
 
=0A=
Thus for example in 3GPP TR 24.819, you will find some = proposed =0A= amendments to 3GPP TS 24.229 which specify attachment of terminals = to an IMS =0A= through an XDSL system. These are still work in =0A= progress.
=0A=
 
=0A=
Finally note that most people in 3GPP participate in IETF = as =0A= individuals and not as representatives of 3GPP, see RFC 3113. There = is only =0A= one 3GPP liaison representative appointed by 3GPP TSG SA (along with = IETF =0A= representation in the oppposite direction).
=0A=
 
=0A=
regards
=0A=
 
=0A=
Keith
=0A=
 
=0A=
=0A=

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 =0A= 776249

=0A=
=0A=
-----Original Message-----
From: = sip-bounces@ietf.org =0A= [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika =0A= (AEAD)
Sent: 14 July 2005 14:58
To: Warren, = Dan, VF UK =0A= - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=
Inline =0A= [RRR]
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on = behalf of =0A= Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 = 3:53 =0A= AM
To: Prabhas Sinha; Avasarala = Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=

Just a quick clarification.  IMS is not = just about =0A= wireless technology, even though it is primarily defined in = 3GPP.  In =0A= 3GPP R6, IMS specs were altered to make them access agnostic and = thus =0A= allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a = way =0A= that an end user should receive common service and common touch = and feel =0A= regardless of how they get to the IMS domain itself.

=0A=

.......

[RRR] It seems to be confusing so = far 3GPP =0A= works are conerned. The idea that 3GPP's IMS is propgating the = following: =0A= The access is specific to cellular wireless, however, cellular = wireless =0A= users need to have services that IMS is defining. So, IMS may = have =0A= some aspects that may be used for other kinds of access = technologies like =0A= Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has = NEVER =0A= defined any criteria that it has NOW transformed itself to be = access =0A= agnostic.

=0A=

[RRR] If 3GPP does so, it will be a = mountain shfit =0A= for 3GPP in its charter, architecture, and requirements to propel = in the =0A= IETF for SIP, SIPPING, AAA, and related WGs. In fact, in = another =0A= thread in NSIS for a contribution on behalf of 3GPP, I mentioned = that they =0A= should focus on access agnostic aspects of QOS in terms of = mobility =0A= instead of just cellular wireless access.

=0A=

[RRR] The question is this: Let us involve 3GPP = as a whole =0A= to make clear (instead of individual contributions here and thers = assuming =0A= that they do NOT respresent 3GPP) what is their actual motivation = for =0A= providing contributions in IETF for creating standards? Is it only =0A= specific to cellular wireless access? Or, is it access =0A= = agnostic?

=0A= ------_=_NextPart_001_01C588AB.790FA702-- --===============1868144996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1868144996==-- From sip-bounces@ietf.org Thu Jul 14 15:51:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9kC-0008Gl-6I; Thu, 14 Jul 2005 15:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9im-0007f8-Lc; Thu, 14 Jul 2005 15:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13684; Thu, 14 Jul 2005 15:50:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABL-0008Ra-4K; Thu, 14 Jul 2005 16:19:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ie-0006HZ-Cz; Thu, 14 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-04.txt Pages : 38 Date : 2005-7-14 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server, and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-14150424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14150424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jul 14 15:56:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9op-0001bK-81; Thu, 14 Jul 2005 15:56:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9oo-0001bD-7G for sip@megatron.ietf.org; Thu, 14 Jul 2005 15:56:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15156 for ; Thu, 14 Jul 2005 15:56:23 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtAHS-0000aq-Mr for sip@ietf.org; Thu, 14 Jul 2005 16:26:03 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 14 Jul 2005 15:58:00 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 15:58:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query about IMS in SIP Date: Thu, 14 Jul 2005 15:57:52 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866016BDD@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] query about IMS in SIP Thread-Index: AcWIjEykYVoN3F0FQPOAZz8ADtEhXwAH3xEl From: "Roy, Radhika \(AEAD\)" To: "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 14 Jul 2005 19:58:01.0620 (UTC) FILETIME=[570EC540:01C588AE] X-Spam-Score: 0.6 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0546477250==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0546477250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C588AE.5179F9C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C588AE.5179F9C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right that I can access to all 3GPP working documents. In fact, = I have been accessing many of those documents since the inception of = 3GPP. It seems to me that the scope of 3GPP works is very big and it is = not so easy to keep track for all of them for all those years with so = many versions. =20 However, the access to the standardized documents is very limited. One = can access only 3 times. More than this, the access is not provided = unless one is the member of 3GPP. =20 That is OK for the closed forum like 3GPP that does not provide = unlimited access like that of the IETF. =20 Recently, I proposed to contributors of closed forums (e.g., 3GPP) in = NSIS WG as follows: =20 1. Any standard documents of the closed forums that cannot be accessed = publicly and referred by authors to place in the website (preferably by = the author or by liaison member) that can be accessed freely by IETF = members. =20 2. Items that I mentioned in response to Dan's email. =20 Thanks for helping us to know about 3GPP/ETSI. =20 Best regards, Radhika ________________________________ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 11:52 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP I referred in my original mail to RFC 3113, which I assume you can gain = access to without further subscription or payment. =20 This tells you exactly how you gain access to 3GPP documents, and that = they are available to everybody with IP access. =20 Indeed if you look in the right place you can gain access to every = version of every specification (bar about 3 on the security algorithms) = that has existed electronically. Similarly you can also gain access to = the vast majority of the internal working documents that have existed = since 3GPP was created, if you really have the patience to work through = them. =20 Obviously 3GPP specifications are published by the member SDOs, but as = far as I understand, none of the publishing SDOs amend the contents of = those 3GPP specifications from those appearing on the 3GPP site, and = indeed the ETSI ones are also available free of charge for the minor = pain of giving your name and email address before you obtain them. =20 regards =20 Keith =20 -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 OK, Good. =20 The question is this: Is 3GPP working for access agnostic = specifications in the IETF? =20 If not, kindly summarize this to us as you seem to be working on behalf = of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of = those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP = members only). =20 Best regards, Radhika ________________________________ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 As part of its cooperation with ETSI TISPAN, 3GPP may place information = in its specifications that enable reuse by other organisations, as well = as those that are requirements for 3GPP operation. =20 Thus while the overall scope of 3GPP specifications will not change, = you may find requirements in individual specifications that are not = intended to be implemented by networks belonging to operators with GERAN = or UTRAN attachments only. These requirements may be endorsed in the = specifications of ETSI TISPAN, or other organisations. =20 Thus for example in 3GPP TR 24.819, you will find some proposed = amendments to 3GPP TS 24.229 which specify attachment of terminals to an = IMS through an XDSL system. These are still work in progress. =20 Finally note that most people in 3GPP participate in IETF as = individuals and not as representatives of 3GPP, see RFC 3113. There is = only one 3GPP liaison representative appointed by 3GPP TSG SA (along = with IETF representation in the oppposite direction). =20 regards =20 Keith =20 Keith Drage=20 Lucent Technologies=20 drage@lucent.com=20 tel: +44 1793 776249=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Inline [RRR] ________________________________ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - = Technology (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP =09 =09 Just a quick clarification. IMS is not just about wireless = technology, even though it is primarily defined in 3GPP. In 3GPP R6, = IMS specs were altered to make them access agnostic and thus allow IMS = to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end = user should receive common service and common touch and feel regardless = of how they get to the IMS domain itself. ....... =09 [RRR] It seems to be confusing so far 3GPP works are conerned. The = idea that 3GPP's IMS is propgating the following: The access is specific = to cellular wireless, however, cellular wireless users need to have = services that IMS is defining. So, IMS may have some aspects that may be = used for other kinds of access technologies like Cable, DSL, Wireless = LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it = has NOW transformed itself to be access agnostic.=20 [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its = charter, architecture, and requirements to propel in the IETF for SIP, = SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a = contribution on behalf of 3GPP, I mentioned that they should focus on = access agnostic aspects of QOS in terms of mobility instead of just = cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make = clear (instead of individual contributions here and thers assuming that = they do NOT respresent 3GPP) what is their actual motivation for = providing contributions in IETF for creating standards? Is it only = specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C588AE.5179F9C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= RE: [Sip] query about IMS in SIP=0A= =0A= =0A= =0A=
=0A=
You are right = that I can =0A= access to all 3GPP working documents. In fact, I have been accessing = many of =0A= those documents since the inception of 3GPP. It seems to me = that the =0A= scope of 3GPP works is very big and it is not so easy to keep track for = all of =0A= them for all those years with so many versions.
=0A=
 
=0A=
However, the access to the =0A= standardized documents is very limited. One can access only 3 = times. =0A= More than this, the access is not provided unless one is the member = of =0A= 3GPP.
=0A=
 
=0A=
That is OK for the closed = forum like 3GPP =0A= that does not provide unlimited access like that of the = IETF.
=0A=
 
=0A=
Recently, I proposed to = contributors of =0A= closed forums (e.g., 3GPP) in NSIS WG as follows:
=0A=
 
=0A=
1. Any standard documents of = the closed =0A= forums that cannot be accessed publicly and referred by authors to place = in the =0A= website (preferably by the author or by liaison member) that can be = accessed =0A= freely by IETF members.
=0A=
 
=0A=
2. Items that I mentioned in = response to =0A= Dan's email.
=0A=
 
=0A=
Thanks for helping us to know = about =0A= 3GPP/ETSI.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Drage, Keith (Keith) =0A= [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 11:52 = AM
To: =0A= Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: = [Sip] =0A= query about IMS in SIP

=0A=
=0A=
I =0A= referred in my original mail to RFC 3113, which I assume you can gain = access to =0A= without further subscription or payment.
=0A=
 
=0A=
This =0A= tells you exactly how you gain access to 3GPP documents, and that they = are =0A= available to everybody with IP access.
=0A=
 
=0A=
Indeed =0A= if you look in the right place you can gain access to every version of = every =0A= specification (bar about 3 on the security algorithms) that has existed =0A= electronically. Similarly you can also gain access to the vast majority = of the =0A= internal working documents that have existed since 3GPP was created, if = you =0A= really have the patience to work through them.
=0A=
 
=0A=
Obviously 3GPP specifications are published = by the =0A= member SDOs, but as far as I understand, none of the publishing SDOs = amend the =0A= contents of those 3GPP specifications from those appearing on the 3GPP = site, and =0A= indeed the ETSI ones are also available free of charge for the minor = pain of =0A= giving your name and email address before you obtain = them.
=0A=
 
=0A=
regards
=0A=
 
=0A=
Keith
=0A=
 
=0A=
=0A=
-----Original Message-----
From: Roy, Radhika = (AEAD) =0A= [mailto:RoyR@saic-abingdon.com]
Sent: 14 July 2005 =0A= 15:34
To: Drage, Keith (Keith)
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=
OK, = Good.
=0A=
 
=0A=
The question is this: Is = 3GPP working for =0A= access agnostic specifications in the IETF?
=0A=
 
=0A=
If not, kindly summarize = this to us as =0A= you seem to be working on behalf of 3GPP in coordination with 3GPP- = IETF =0A= liaison as we are NOT aware of those 3GPP specs (unlike IETF, access = to final =0A= specs are limited to 3GPP members only).
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Drage, Keith (Keith) =0A= [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15 = AM
To: =0A= Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: = [Sip] =0A= query about IMS in SIP

=0A=
=0A=
As =0A= part of its cooperation with ETSI TISPAN, 3GPP may place information = in its =0A= specifications that enable reuse by other organisations, as well as = those that =0A= are requirements for 3GPP operation.
=0A=
 
=0A=
Thus =0A= while the overall scope of 3GPP specifications will not change, you = may find =0A= requirements in individual specifications that are not intended to be =0A= implemented by networks belonging to operators with GERAN or UTRAN = attachments =0A= only. These requirements may be endorsed in the specifications of ETSI = TISPAN, =0A= or other organisations.
=0A=
 
=0A=
Thus =0A= for example in 3GPP TR 24.819, you will find some proposed amendments = to 3GPP =0A= TS 24.229 which specify attachment of terminals to an IMS through an = XDSL =0A= system. These are still work in progress.
=0A=
 
=0A=
Finally note that most people in 3GPP participate in IETF as =0A= individuals and not as representatives of 3GPP, see RFC 3113. There is = only =0A= one 3GPP liaison representative appointed by 3GPP TSG SA (along with = IETF =0A= representation in the oppposite direction).
=0A=
 
=0A=
regards
=0A=
 
=0A=
Keith
=0A=
 
=0A=
=0A=

Keith Drage
Lucent Technologies
drage@lucent.com
tel: = +44 1793 =0A= 776249

=0A=
=0A=
-----Original Message-----
From: = sip-bounces@ietf.org =0A= [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika =0A= (AEAD)
Sent: 14 July 2005 14:58
To: Warren, Dan, = VF UK - =0A= Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=
Inline =0A= [RRR]
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on = behalf of =0A= Warren, Dan, VF UK - Technology (TS)
Sent: Thu 7/14/2005 = 3:53 =0A= AM
To: Prabhas Sinha; Avasarala = Ranjit-A20990
Cc: =0A= sip@ietf.org
Subject: RE: [Sip] query about IMS in =0A= SIP

=0A=
=0A=

Just a quick clarification.  IMS is not just = about =0A= wireless technology, even though it is primarily defined in = 3GPP.  In =0A= 3GPP R6, IMS specs were altered to make them access agnostic and = thus allow =0A= IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way = that an end =0A= user should receive common service and common touch and feel = regardless of =0A= how they get to the IMS domain itself.

=0A=

.......

[RRR] It seems to be confusing so = far 3GPP =0A= works are conerned. The idea that 3GPP's IMS is propgating the = following: =0A= The access is specific to cellular wireless, however, cellular = wireless =0A= users need to have services that IMS is defining. So, IMS may = have some =0A= aspects that may be used for other kinds of access technologies like = Cable, =0A= DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER = defined any =0A= criteria that it has NOW transformed itself to be access agnostic. =0A=

=0A=

[RRR] If 3GPP does so, it will be a mountain = shfit for =0A= 3GPP in its charter, architecture, and requirements to propel in the = IETF =0A= for SIP, SIPPING, AAA, and related WGs. In fact, in another = thread in =0A= NSIS for a contribution on behalf of 3GPP, I mentioned that they = should =0A= focus on access agnostic aspects of QOS in terms of mobility instead = of just =0A= cellular wireless access.

=0A=

[RRR] The question is this: Let us involve 3GPP as = a whole =0A= to make clear (instead of individual contributions here and thers = assuming =0A= that they do NOT respresent 3GPP) what is their actual motivation = for =0A= providing contributions in IETF for creating standards? Is it only = specific =0A= to cellular wireless access? Or, is it access =0A= = agnostic?

=0A= ------_=_NextPart_001_01C588AE.5179F9C4-- --===============0546477250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0546477250==-- From sip-bounces@ietf.org Thu Jul 14 18:01:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBlO-0003it-1x; Thu, 14 Jul 2005 18:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBlM-0003iK-7W for sip@megatron.ietf.org; Thu, 14 Jul 2005 18:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10201 for ; Thu, 14 Jul 2005 18:00:57 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtCDy-0003a9-Ph for sip@ietf.org; Thu, 14 Jul 2005 18:30:39 -0400 Received: from [64.101.149.168] ([64.101.149.168]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6EM4YFJ018874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 14 Jul 2005 17:04:35 -0500 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730882A2@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C730882A2@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90a6156f3700821b79bdf5748a600b3d@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Tandem switch Call typing and routing Date: Thu, 14 Jul 2005 17:00:46 -0500 To: "Jenkal, Vijey" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jul 13, 2005, at 11:51 AM, Jenkal, Vijey wrote: > We are researching possible ways of performing PSTN call routing at a > Tandem switch that receives calls from an (or more) end-office switch > over a SIP interconnection. The tandem switch is responsible for > determining the type of the call and completing it to either the Local, > Local-toll or Long-distance PSTN trunk based on the call type. Based on > the current regulations, the call typing would have to be based on the > perspective of the originating switch rather than the tandem. Is there > any discussions in the SIP forum with regards to how SIP could be used > to convey the right information (either as call-type, rate-center > information or otherwise) to facilitate such call routing at the > tandem? > RFC 3966 defines the tel: URL scheme, and it allows for a "context" parameter. I suggest you have the edge switch set the "context" parameter to indicate its perspective, then have the tandem siwtch act on that context. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 15 02:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtK0h-000601-N8; Fri, 15 Jul 2005 02:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJEj-0001RE-NU for sip@megatron.ietf.org; Tue, 12 Jul 2005 07:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13179 for ; Tue, 12 Jul 2005 07:47:40 -0400 (EDT) Received: from ils120.uopnet.plymouth.ac.uk ([141.163.66.120] helo=03-CSEXCH.uopnet.plymouth.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsJgu-0000GU-Mp for sip@ietf.org; Tue, 12 Jul 2005 08:16:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 12:47:13 +0100 Message-ID: <27300D424F8C5D49A8FD2770280FD5C5976DE7@03-CSEXCH.uopnet.plymouth.ac.uk> Thread-Topic: SIP Thread-Index: AcWG13G4mJE8QKhpRCGbX5EOqsGdGw== From: "\(pg\) Inam Haq" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 15 Jul 2005 02:49:16 -0400 Subject: [Sip] SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hi, i want to do some research in use of SIP with in Personal Area Network = using a REFER method. can you please recommned me some reference or RFC specially for SIP = within Personal Area Netowrk. Regards, Inam Haq MS(NSE) University of Plymouth (UK) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 15 02:49:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtK0j-00060V-Fp; Fri, 15 Jul 2005 02:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drerj-00023E-B0 for sip@megatron.ietf.org; Sun, 10 Jul 2005 12:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11207 for ; Sun, 10 Jul 2005 12:41:12 -0400 (EDT) Received: from web54204.mail.yahoo.com ([206.190.39.246]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DrfJS-0005mc-BW for sip@ietf.org; Sun, 10 Jul 2005 13:10:01 -0400 Received: (qmail 95899 invoked by uid 60001); 10 Jul 2005 16:40:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mWFdDvuVZrAoCcS0sX13GtE0zBOHqUBLjkWWfZ6m7rSlh1SmWn8IX+3TfJmbMiPf0zcfiYdx/draix2iotgkc8nCQzHcK4Sv09Hc4n+ryAExhLUgcAtnV3xB+W6aMU/aKlD9NebS2sOMfS7RiY//f+f7ScA2D+XqPIS6uLcZgcY= ; Message-ID: <20050710164057.95897.qmail@web54204.mail.yahoo.com> Received: from [217.45.197.113] by web54204.mail.yahoo.com via HTTP; Sun, 10 Jul 2005 09:40:57 PDT Date: Sun, 10 Jul 2005 09:40:57 -0700 (PDT) From: Rayees Khan To: Gonzalo Camarillo In-Reply-To: <42BFB600.3000709@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 15 Jul 2005 02:49:18 -0400 Cc: sip@ietf.org, rakhanhss@yahoo.com Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rakhan@hssworld.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, What I see the main advantage in this model is that it would allow all the involved parties, including trancoding server, to control the session and make others aware of the changes. It does have the limitation that the parties should support the mentioned extension of SIP. regards Rayees --- Gonzalo Camarillo wrote: > Hi, > > inline: > > > One of the things that would improve the draft > would > > be to include the message > > format of the messages that would be exchanged in > the > > call flow. > > The details are given in the two documents > describing the actual models. > The framework only provides a rough description of > both models. > > > In section 3.1, there is a link ([10]) to > > the document that describes it all but for 3.2 I > could > > not find such link. > > Yes, I will add such a reference. > > > What I have understood from the two section is > > o section 3.1 - after initial dialog is > established by > > A with B and T, it > > would manage the exposure of transport address > of B > > and T to both > > o section 3.2 - A establishes dialog with T, which > > acts as a B2B UA. However, > > it would additionally act as a MiddleBox > > Communication server (RFC 3304) > > and establishes dialog with B. > > > > The alternate model could be a hybrid one. The > figure > > below depicts the > > signaling relationship between the parties. > > > > A establishes a signaling dialog with B, and comes > to > > know about the capabilites > > of B. It realizes the need for transcoding so > > establishes dialog with T, > > queries it for resources. If response is positive > from > > T it uses REFER method > > mechanism to inform B about signaling contacts of > T. B > > initiates session with C > > joining the dialog as described in RFC 3911. > > > > +-------+ > > | |** > > | T | ** > > | |\ ** > > +-------+ \\ ** > > ^ * \\ ** > > | * \\ ** > > | * SIP ** > > SIP * \\ ** > > | * \\ ** > > | * \\ ** > > v * \ ** > > +-------+ +-------+ > > | | | | > > | A | < -- SIP --> | B | > > | | | | > > +-------+ +-------+ > > > > Does it make sense? > > What would be the advantages of this model? > > Note that this model would require B to understand a > set of extensions > (e.g., REFER, Replaces) while the existing models > work with vanilla SIP > user agents on the side that does not invoke the > transcoder. > > Thanks, > > Gonzalo > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 15 03:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKyt-0008PS-U2; Fri, 15 Jul 2005 03:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKyr-0008N5-HA for sip@megatron.ietf.org; Fri, 15 Jul 2005 03:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11408 for ; Fri, 15 Jul 2005 03:51:31 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtLRd-0004vG-HC for sip@ietf.org; Fri, 15 Jul 2005 04:21:17 -0400 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j6F7pR119805; Fri, 15 Jul 2005 00:51:27 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 15 Jul 2005 00:50:19 -0700 To: SIP WG X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] revised version of SIP location package X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Folks, I just updated my SIP "loc" event package, which is used to carry geographic location. (See the announcement on the geopriv list.) James Polk and I have not worked out its relationship to his SIP location conveyance draft. In any case, the draft has a geopriv prefix, so I expect discussions on the content of my draft will happen in geopriv. If you have a comment about the scope or relevance of the draft as related to draft-ietf-sip-location-conveyance, feel free to discuss that here. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 15 09:08:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPvJ-0008SS-TZ; Fri, 15 Jul 2005 09:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPvE-0008S1-K3 for sip@megatron.ietf.org; Fri, 15 Jul 2005 09:08:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02658 for ; Fri, 15 Jul 2005 09:08:06 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtQO2-0007zq-GS for sip@ietf.org; Fri, 15 Jul 2005 09:37:55 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6FD7xf2005937; Fri, 15 Jul 2005 08:08:00 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 15 Jul 2005 14:07:58 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0102EF42F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Roy, Radhika (AEAD)" , "Drage, Keith (Keith)" Subject: RE: [Sip] query about IMS in SIP Date: Fri, 15 Jul 2005 14:07:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736816084==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0736816084== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5893E.36BC5BBE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5893E.36BC5BBE Content-Type: text/plain; charset="iso-8859-1" I can only assume that you are referring to the versions of 3GPP documents published by ETSI, although I am not aware of any limitation there, although you do have to access it one document at the time. While the ETSI and 3GPP sites are hosted on common platforms, they have different domain names and you should be able to tell the difference. On the 3GPP site there is no access limitation, and never has been. No 3GPP participants have accounts in order to access the 3GPP areas. I agree these are the copies before publication, but to be honest, this is what people implement from, and not the versions published by the SDOs. None of the SDOs make technical changes to the documents in publication. So to repeat - go to one of the following: www.3gpp.org http://www.3gpp.org/ftp/Specs/html-info/status-report.htm and so on there should be no limitation. If you have trouble, there are helpdesk contacts at both ETSI and 3GPP sites. regards Keith -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: 14 July 2005 20:58 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP You are right that I can access to all 3GPP working documents. In fact, I have been accessing many of those documents since the inception of 3GPP. It seems to me that the scope of 3GPP works is very big and it is not so easy to keep track for all of them for all those years with so many versions. However, the access to the standardized documents is very limited. One can access only 3 times. More than this, the access is not provided unless one is the member of 3GPP. That is OK for the closed forum like 3GPP that does not provide unlimited access like that of the IETF. Recently, I proposed to contributors of closed forums (e.g., 3GPP) in NSIS WG as follows: 1. Any standard documents of the closed forums that cannot be accessed publicly and referred by authors to place in the website (preferably by the author or by liaison member) that can be accessed freely by IETF members. 2. Items that I mentioned in response to Dan's email. Thanks for helping us to know about 3GPP/ETSI. Best regards, Radhika _____ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 11:52 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP I referred in my original mail to RFC 3113, which I assume you can gain access to without further subscription or payment. This tells you exactly how you gain access to 3GPP documents, and that they are available to everybody with IP access. Indeed if you look in the right place you can gain access to every version of every specification (bar about 3 on the security algorithms) that has existed electronically. Similarly you can also gain access to the vast majority of the internal working documents that have existed since 3GPP was created, if you really have the patience to work through them. Obviously 3GPP specifications are published by the member SDOs, but as far as I understand, none of the publishing SDOs amend the contents of those 3GPP specifications from those appearing on the 3GPP site, and indeed the ETSI ones are also available free of charge for the minor pain of giving your name and email address before you obtain them. regards Keith -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: 14 July 2005 15:34 To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP OK, Good. The question is this: Is 3GPP working for access agnostic specifications in the IETF? If not, kindly summarize this to us as you seem to be working on behalf of 3GPP in coordination with 3GPP- IETF liaison as we are NOT aware of those 3GPP specs (unlike IETF, access to final specs are limited to 3GPP members only). Best regards, Radhika _____ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 7/14/2005 10:15 AM To: Roy, Radhika (AEAD) Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP As part of its cooperation with ETSI TISPAN, 3GPP may place information in its specifications that enable reuse by other organisations, as well as those that are requirements for 3GPP operation. Thus while the overall scope of 3GPP specifications will not change, you may find requirements in individual specifications that are not intended to be implemented by networks belonging to operators with GERAN or UTRAN attachments only. These requirements may be endorsed in the specifications of ETSI TISPAN, or other organisations. Thus for example in 3GPP TR 24.819, you will find some proposed amendments to 3GPP TS 24.229 which specify attachment of terminals to an IMS through an XDSL system. These are still work in progress. Finally note that most people in 3GPP participate in IETF as individuals and not as representatives of 3GPP, see RFC 3113. There is only one 3GPP liaison representative appointed by 3GPP TSG SA (along with IETF representation in the oppposite direction). regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD) Sent: 14 July 2005 14:58 To: Warren, Dan, VF UK - Technology (TS); Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Inline [RRR] _____ From: sip-bounces@ietf.org on behalf of Warren, Dan, VF UK - Technology (TS) Sent: Thu 7/14/2005 3:53 AM To: Prabhas Sinha; Avasarala Ranjit-A20990 Cc: sip@ietf.org Subject: RE: [Sip] query about IMS in SIP Just a quick clarification. IMS is not just about wireless technology, even though it is primarily defined in 3GPP. In 3GPP R6, IMS specs were altered to make them access agnostic and thus allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such a way that an end user should receive common service and common touch and feel regardless of how they get to the IMS domain itself. ....... [RRR] It seems to be confusing so far 3GPP works are conerned. The idea that 3GPP's IMS is propgating the following: The access is specific to cellular wireless, however, cellular wireless users need to have services that IMS is defining. So, IMS may have some aspects that may be used for other kinds of access technologies like Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has NEVER defined any criteria that it has NOW transformed itself to be access agnostic. [RRR] If 3GPP does so, it will be a mountain shfit for 3GPP in its charter, architecture, and requirements to propel in the IETF for SIP, SIPPING, AAA, and related WGs. In fact, in another thread in NSIS for a contribution on behalf of 3GPP, I mentioned that they should focus on access agnostic aspects of QOS in terms of mobility instead of just cellular wireless access. [RRR] The question is this: Let us involve 3GPP as a whole to make clear (instead of individual contributions here and thers assuming that they do NOT respresent 3GPP) what is their actual motivation for providing contributions in IETF for creating standards? Is it only specific to cellular wireless access? Or, is it access agnostic? ------_=_NextPart_001_01C5893E.36BC5BBE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] query about IMS in SIP
I can=20 only assume that you are referring to the versions of 3GPP documents = published=20 by ETSI, although I am not aware of any limitation there, although you = do have=20 to access it one document at the time. While the ETSI and 3GPP sites = are hosted=20 on common platforms, they have different domain names and you should be = able to=20 tell the difference.
 
On the=20 3GPP site there is no access limitation, and never has been. No 3GPP=20 participants have accounts in order to access the 3GPP areas. I agree = these are=20 the copies before publication, but to be honest, this is what people = implement=20 from, and not the versions published by the SDOs. None of the SDOs make = technical changes to the documents in publication.
 
So to=20 repeat - go to one of the following:
 
www.3gpp.org
http:= //www.3gpp.org/ftp/Specs/html-info/status-report.htm
 
and so=20 on there should be no limitation.
 
If you=20 have trouble, there are helpdesk contacts at both ETSI and 3GPP=20 sites.
 
regards
 
Keith
 
-----Original Message-----
From: Roy, Radhika = (AEAD)=20 [mailto:RoyR@saic-abingdon.com]
Sent: 14 July 2005=20 20:58
To: Drage, Keith (Keith)
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

You are = right that I can=20 access to all 3GPP working documents. In fact, I have been accessing = many of=20 those documents since the inception of 3GPP. It seems to me = that the=20 scope of 3GPP works is very big and it is not so easy to keep track = for all of=20 them for all those years with so many versions.
 
However, the access to the = standardized documents is very limited. One can access only = 3 times.=20 More than this, the access is not provided unless one is the = member of=20 3GPP.
 
That is OK for the closed = forum like 3GPP=20 that does not provide unlimited access like that of the = IETF.
 
Recently, I proposed to = contributors of=20 closed forums (e.g., 3GPP) in NSIS WG as follows:
 
1. Any standard documents = of the closed=20 forums that cannot be accessed publicly and referred by authors to = place in=20 the website (preferably by the author or by liaison member) that can = be=20 accessed freely by IETF members.
 
2. Items that I mentioned = in response to=20 Dan's email.
 
Thanks for helping us to = know about=20 3GPP/ETSI.
 
Best regards,
Radhika

From: Drage, Keith (Keith)=20 [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 11:52 = AM
To:=20 Roy, Radhika (AEAD)
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 query about IMS in SIP

I=20 referred in my original mail to RFC 3113, which I assume you can gain = access=20 to without further subscription or payment.
 
This=20 tells you exactly how you gain access to 3GPP documents, and that = they are=20 available to everybody with IP access.
 
Indeed if you look in the right place you can gain access to = every=20 version of every specification (bar about 3 on the security = algorithms) that=20 has existed electronically. Similarly you can also gain access to the = vast=20 majority of the internal working documents that have existed since = 3GPP was=20 created, if you really have the patience to work through=20 them.
 
Obviously 3GPP specifications are = published by the=20 member SDOs, but as far as I understand, none of the publishing SDOs = amend the=20 contents of those 3GPP specifications from those appearing on the = 3GPP site,=20 and indeed the ETSI ones are also available free of charge for the = minor pain=20 of giving your name and email address before you obtain=20 them.
 
regards
 
Keith
 
-----Original Message-----
From: Roy, Radhika = (AEAD)=20 [mailto:RoyR@saic-abingdon.com]
Sent: 14 July 2005=20 15:34
To: Drage, Keith (Keith)
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

OK, = Good.
 
The question is this: Is = 3GPP working=20 for access agnostic specifications in the IETF?
 
If not, kindly summarize = this to us as=20 you seem to be working on behalf of 3GPP in coordination with 3GPP- = IETF=20 liaison as we are NOT aware of those 3GPP specs (unlike IETF, = access to=20 final specs are limited to 3GPP members only).
 
Best = regards,
Radhika

From: Drage, Keith (Keith)=20 [mailto:drage@lucent.com]
Sent: Thu 7/14/2005 10:15=20 AM
To: Roy, Radhika (AEAD)
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

As=20 part of its cooperation with ETSI TISPAN, 3GPP may place = information in its=20 specifications that enable reuse by other organisations, as well as = those=20 that are requirements for 3GPP operation.
 
Thus while the overall scope of 3GPP specifications will = not change,=20 you may find requirements in individual specifications that are not = intended=20 to be implemented by networks belonging to operators with GERAN or = UTRAN=20 attachments only. These requirements may be endorsed in the = specifications=20 of ETSI TISPAN, or other organisations.
 
Thus for example in 3GPP TR 24.819, you will find some = proposed=20 amendments to 3GPP TS 24.229 which specify attachment of terminals = to an IMS=20 through an XDSL system. These are still work in=20 progress.
 
Finally note that most people in 3GPP participate in IETF = as=20 individuals and not as representatives of 3GPP, see RFC 3113. There = is only=20 one 3GPP liaison representative appointed by 3GPP TSG SA (along = with IETF=20 representation in the oppposite direction).
 
regards
 
Keith
 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793=20 776249

-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: 14 July 2005 14:58
To: Warren, = Dan, VF UK=20 - Technology (TS); Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Inline = [RRR]

From: sip-bounces@ietf.org on = behalf of=20 Warren, Dan, VF UK - Technology (TS)
Sent: Thu = 7/14/2005 3:53=20 AM
To: Prabhas Sinha; Avasarala = Ranjit-A20990
Cc:=20 sip@ietf.org
Subject: RE: [Sip] query about IMS in=20 SIP

Just a quick clarification.  IMS is not = just about=20 wireless technology, even though it is primarily defined in = 3GPP.  In=20 3GPP R6, IMS specs were altered to make them access agnostic and = thus=20 allow IMS to be utilised by any access (DSL, WLAN, FTTx) in such = a way=20 that an end user should receive common service and common touch = and feel=20 regardless of how they get to the IMS domain itself.

.......

[RRR] It seems to be confusing = so far 3GPP=20 works are conerned. The idea that 3GPP's IMS is propgating the = following:=20 The access is specific to cellular wireless, however, cellular = wireless=20 users need to have services that IMS is defining. So, IMS = may have=20 some aspects that may be used for other kinds of access = technologies like=20 Cable, DSL, Wireless LANs, FTTx, and others, but 3GPP has = NEVER=20 defined any criteria that it has NOW transformed itself to be = access=20 agnostic.

[RRR] If 3GPP does so, it will be a = mountain shfit=20 for 3GPP in its charter, architecture, and requirements to propel = in the=20 IETF for SIP, SIPPING, AAA, and related WGs. In fact, in = another=20 thread in NSIS for a contribution on behalf of 3GPP, I mentioned = that they=20 should focus on access agnostic aspects of QOS in terms of = mobility=20 instead of just cellular wireless access.

[RRR] The question is this: Let us involve 3GPP = as a whole=20 to make clear (instead of individual contributions here and thers = assuming=20 that they do NOT respresent 3GPP) what is their actual motivation = for=20 providing contributions in IETF for creating standards? Is it = only=20 specific to cellular wireless access? Or, is it access=20 = agnostic?

------_=_NextPart_001_01C5893E.36BC5BBE-- --===============0736816084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0736816084==-- From sip-bounces@ietf.org Fri Jul 15 14:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUhM-0003zm-76; Fri, 15 Jul 2005 14:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUhG-0003tc-JN for sip@megatron.ietf.org; Fri, 15 Jul 2005 14:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01241 for ; Fri, 15 Jul 2005 14:14:00 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVA4-0003nx-Sh for sip@ietf.org; Fri, 15 Jul 2005 14:43:52 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2005 11:13:49 -0700 X-IronPort-AV: i="3.93,293,1115017200"; d="scan'208,217"; a="308264287:sNHT53155824" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6FIDfvc024116; Fri, 15 Jul 2005 11:13:45 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jul 2005 14:13:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Date: Fri, 15 Jul 2005 14:13:45 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C758D58@xmb-rtp-211.amer.cisco.com> Thread-Topic: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Thread-Index: AcVmqB6ZrIlDK1ycSKu2WiNdLoIYzAive5+Q From: "Kevin Lingle \(klingle\)" To: "Romascanu, Dan \(Dan\)" , X-OriginalArrivalTime: 15 Jul 2005 18:13:46.0690 (UTC) FILETIME=[F13DF220:01C58968] X-Spam-Score: 0.6 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: "Wijnen, Bert \(Bert\)" , jf.mule@cablelabs.com, j.schoenwaelder@iu-bremen.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0486466703==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0486466703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58968.F122C5F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58968.F122C5F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi dan. sorry for the delayed response. please see inline for my comments. j-f, please feel free to chime in. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 01, 2005 8:48 AM To: sip@ietf.org Cc: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de Subject: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review =09 =09 =20 Here are my review comments. I apologize for the delay, but unfortunately the document is not yet completely problems free, and it generated some discussions 'in the doctors room': =20 A few issues were found related to the definition of the SipMethodIdentifier TC and its usage: =20 1. The way it is defined the TC encourages extensibility, and this can be regarded as a good thing. In order to do this a vendor must invent some numerical assignment, which is not yet used by the standard, and the DESCRIPTION requires that this assignment "MUST ensure no collision with officially assigned method identifier values" but says nothing about how collision can be avoided.=20 [klingle] one would avoid collision by checking the IANA maintained list of latest officially assigned method id values... at least that was the intent/expectation. if that is sufficient, can we simply add that text? =20 It would be useful to split the identifiers numbers space into standard and experimental, and create a second experimental registry where vendors building an extension method and receive a number in the experimental space. =09 [klingle] as long as the IANA administration of the second registry isn't too much, this is a possibility. would you invision something like id values greater than 255 would be experimental space. =20 that's an arbitrary demarcation based on the assumption that there wouldn't be over 255 offical methods=20 ever defined. it would still be a vendor's responsibility to avoid collision by getting an experimental number. i would expect the experimental number would forever be allocated and not re-usuable. how much real new method creation is actually going to happen w/ SIP protocol?=20 =20 This would ensure that collisions are avoided, and experimental methods are identified at a glance. 2. Another MIB Doctor asked 'why the method name has not been used as an index as this would be the natural naming scheme. Having to go through a lookup table (in case the SipMethodIdentifier has only local significance) is painful and the alternative to establish another IANA registry to number the SIP methods seems also kind of costly.'. I am not sure that a change is necessary at this stage, as nothing is broken, but as I would suggest that you provide a rationale for this design choice.=20 [klingle] i think this was discussed at some point in the past. the rationale i recall had to do with the ease of=20 integral indexing in snmp tables vs. variable-length string indexes. keep in mind that the mib's generally a=20 machine interface in that a NM application should be doing the GETs and then has the opportunity to present=20 the data in a more user-friendly fashion to a human being. so we thought the use of string methods indexing=20 the tables everywhere was less efficient for the agent implementations. =20 3. The TC misses a DISPLAY-HINT (probably "d"), which results into a smilint warning=20 [klingle] ok. will check on that. =20 i will be on vacation next week and will try and address the editorial comments below when i return. =20 thanks for the review! kevin=20 =20 Some more editorial things.=20 =20 4. Since the document was published the Intellectual Property boilerplates were updated. See http://www.ietf.org/ietf/1id-guidelines.txt for the latest version 5. It is recommended that the module name of the SIP-TC module be changed to SIP-TC-MIB 6. typo - DESCRIPTION clause of SipStatusCodeNotifTable - "seperate" 7. typo - DESCRIPTION clause of SipMethodIdentifier - "extention" 8. typo - DESCRIPTION clause of sipServiceNotifEnable - "approriate" 9. type - DESCRIPTION clause of sipServiceWarmStart - "adminstrative" 10. There are 129 instances of too long lines in this documents. Please run idnits for the full list http://ietf.levkowetz.com/tools/idnits/idnits.pyht 11. Warnings of weird spacing in lines=20 tmp/draft-ietf-sip-mib-09.txt(4495): Line has weird spacing: '...CodeIns rena...' tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing: '...odeOuts renam...' tmp/draft-ietf-sip-mib-09.txt(4789): Line has weird spacing: '...odTable in th...' 12. As Section 8 including the Log of Changes will be taken out, but there are other sections after this section it would be better to move it to an annex and renumber, making sure that proper references from the text go to the intended place. =20 Regards, =20 Dan =20 ------_=_NextPart_001_01C58968.F122C5F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
hi dan.  sorry for the delayed=20 response.   please see inline for my comments.  j-f, = please feel=20 free
to chime in.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Romascanu, Dan=20 (Dan)
Sent: Wednesday, June 01, 2005 8:48 AM
To:=20 sip@ietf.org
Cc: Wijnen, Bert (Bert);=20 j.schoenwaelder@iu-bremen.de
Subject: [Sip]=20 draft-ietf-sip-mib-09.txt - 'MIB Doctor' review

 
Here = are my review=20 comments. I apologize for the delay, but unfortunately the document is = not yet=20 completely problems free, and it generated some discussions 'in = the=20 doctors room':
 
A = few issues were=20 found related to the definition of the SipMethodIdentifier TC and its=20 usage:
 
1.=20  The way it is defined the TC = encourages=20 extensibility, and this can be regarded as a good thing. In order to = do this a=20 vendor must invent some numerical assignment, which is not yet used by = the=20 standard, and the DESCRIPTION requires that this assignment = "MUST ensure no collision with officially = assigned method=20 identifier values" but says nothing about how collision can be = avoided.=20
[klingle] one=20 would avoid collision by checking the IANA maintained list of latest=20 officially assigned method id
values... at least that = was the=20 intent/expectation.   if that is sufficient, can we simply = add that=20 text?
 
 It would be useful to split = the=20 identifiers numbers space into standard and experimental, and create a = second=20 experimental registry where vendors building an extension method = and=20 receive a number in the experimental space.
[klingle] as long = as the IANA=20 administration of the second registry isn't too much, this is a=20 possibility.
would you invision = something like id=20 values greater than 255 would be experimental space. =20
that's an arbitrary=20 demarcation based on the assumption that there = wouldn't be=20 over 255 offical methods =
ever = defined.   it would=20 still be a vendor's responsibility to avoid collision by getting an=20 experimental number.
i would expect the = experimental=20 number would forever be allocated and not=20 re-usuable.
how much real new method = creation is=20 actually going to happen w/ SIP=20 protocol? 
 
 This would ensure that = collisions are=20 avoided, and experimental methods are identified at a=20 glance.
2. = Another MIB=20 Doctor asked 'why the method = name has not=20 been used as an index as this would be the natural naming scheme. = Having to go=20 through a lookup table (in case the SipMethodIdentifier has only local = significance) is painful and the alternative to establish another IANA = registry to number the SIP methods seems also kind of costly.'. I am = not sure=20 that a change is necessary at this stage, as nothing is broken, = but as I=20 would suggest that you provide a rationale for this design choice. =
[klingle]  i think=20 this was discussed at some point in the past.  the rationale i = recall had=20 to do with the ease of
integral indexing in = snmp tables vs.=20 variable-length string indexes.   keep in mind that the = mib's=20 generally a
machine interface in = that a NM=20 application should be doing the GETs and then has the opportunity to = present=20
the data in a more = user-friendly=20 fashion to a human being.  so we thought the use of string = methods=20 indexing
the tables everywhere = was less=20 efficient for the agent=20 implementations.
 
3. = The TC misses a=20 DISPLAY-HINT (probably "d"), which results into a smilint = warning =
[klingle] ok.  will=20 check on that.
 
i=20 will be on vacation next week and will try and address the = editorial=20 comments below
when=20 i return.
 
thanks for the=20 review!
kevin 
 
Some = more=20 editorial things.
 
4. = Since the=20 document was published the Intellectual Property boilerplates were = updated.=20 See http://www.ietf.org/= ietf/1id-guidelines.txt for=20 the latest version
5. = It is=20 recommended that the module name of the SIP-TC module be changed to=20 SIP-TC-MIB
6.=20 typo - DESCRIPTION clause of=20 SipStatusCodeNotifTable - "seperate"
7. typo -=20 DESCRIPTION clause of SipMethodIdentifier -=20 "extention"
8. typo - DESCRIPTION clause of sipServiceNotifEnable -=20 "approriate"
9.=20 type - DESCRIPTION clause of sipServiceWarmStart -=20 "adminstrative"
10.=20 There are 129 instances of too long lines in this documents. Please = run idnits=20 for the full list http://ietf.l= evkowetz.com/tools/idnits/idnits.pyht
11.=20 Warnings of weird spacing in lines
tmp/draft-ietf-sip-mib-09.txt(4495): Line = has weird=20 spacing: '...CodeIns  =20 rena...'
tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird = spacing:=20 '...odeOuts  renam...'
tmp/draft-ietf-sip-mib-09.txt(4789): = Line has=20 weird spacing: '...odTable  in th...'
12. = As Section 8=20 including the Log of Changes will be taken out, but there are other = sections=20 after this section it would be better to move it to an annex and = renumber,=20 making sure that proper references from the text go to the intended=20 place.
 
Regards,
 
Dan
 

------_=_NextPart_001_01C58968.F122C5F6-- --===============0486466703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0486466703==-- From sip-bounces@ietf.org Fri Jul 15 15:51:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWE2-0006RA-7u; Fri, 15 Jul 2005 15:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCM-0005uV-Og; Fri, 15 Jul 2005 15:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10987; Fri, 15 Jul 2005 15:50:11 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWf4-0007pu-D9; Fri, 15 Jul 2005 16:19:59 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWCB-0001vt-66; Fri, 15 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-10.txt Pages : 36 Date : 2005-7-15 This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and SIP proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15144959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15144959.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jul 18 11:13:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXJT-00058o-UF; Mon, 18 Jul 2005 11:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXJR-00058h-CG for sip@megatron.ietf.org; Mon, 18 Jul 2005 11:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19997 for ; Mon, 18 Jul 2005 11:13:43 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXms-0007yV-5n for sip@ietf.org; Mon, 18 Jul 2005 11:44:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2005 08:13:34 -0700 X-IronPort-AV: i="3.93,297,1115017200"; d="scan'208"; a="313465249:sNHT27791520" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6IFCsW3020348 for ; Mon, 18 Jul 2005 08:13:33 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:12:45 -0400 Received: from [192.168.1.102] ([10.86.242.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:12:45 -0400 Message-ID: <42DBC6ED.5090603@cisco.com> Date: Mon, 18 Jul 2005 11:12:45 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 15:12:45.0748 (UTC) FILETIME=[26DAF740:01C58BAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Sip] updated target dialog spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks, I've submitted an update to the target dialog header field spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-01.txt The changes from the previous version are: * alignment with latest gruu best practices * recommending target dialog with REFER, but not kpml; the previous spec had described its usage with kpml and dialog-event, but the latter two carry dialog info in the event header field, making it redundant. List discussion had concluded to limit usage of target-dialog to cases where it wasn't otherwise present * updated call flows accordingly There are no open issues that I am aware of, and I believe that the draft is ready for WGLC. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 18 16:58:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuchU-0004Ml-Gb; Mon, 18 Jul 2005 16:58:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuchS-0004Me-I3 for sip@megatron.ietf.org; Mon, 18 Jul 2005 16:58:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28021 for ; Mon, 18 Jul 2005 16:58:52 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DudAw-00050o-F0 for sip@ietf.org; Mon, 18 Jul 2005 17:29:23 -0400 Received: from [64.101.149.168] ([64.101.149.168]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6IL2Y0Y028088 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 18 Jul 2005 16:02:36 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 18 Jul 2005 15:58:44 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] SIP agenda requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As usual, I'll be collecting agenda requests and posting them on the softarmor site (http://www.softarmor.com/sipwg), so if you think you need a SIP agenda slot, please send me the request by Friday 8/22. note that, as usual, we'll be trying to use meeting time to talk about "hard issues" that have been discussed but not resolved on-list, rather than presenting status or try and propose new work. So we may be unable to allocate time for presentations of new drafts that have not been discussed. To make a request please send: Topic of the discussion Your name Your email The amount of time you think you need A pointer or pointers to the relevant drafts(s) To the extent possible, I'd like to get slides uploaded in advance of the meeting. So, please plan to send slides ASAP after the agenda is posted, and certainly no later than the beginning of the meeting in which you'll be leading a discussion. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 19 01:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dukk4-0001rE-2w; Tue, 19 Jul 2005 01:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dukk2-0001qX-0S for sip@megatron.ietf.org; Tue, 19 Jul 2005 01:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19550 for ; Tue, 19 Jul 2005 01:34:04 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DulDZ-0004UF-Rd for sip@ietf.org; Tue, 19 Jul 2005 02:04:39 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6J5bqMS029954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2005 00:37:52 -0500 Message-ID: <42DC90D1.9050909@softarmor.com> Date: Tue, 19 Jul 2005 00:34:09 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi , sip@ietf.org Subject: Re: [Sip] SIP agenda requests References: <42DC1DDD.8000304@nokia.com> In-Reply-To: <42DC1DDD.8000304@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > > ext Dean Willis wrote: > >> please send me the request by Friday 8/22. > > > I'm sure you meant to say 7/22. Otherwise, that'd be a little late > wouldn't it? ;) > Ok, can we make it by 7/22? Aki seems to be feeling impatient. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 19 13:29:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duvu1-0001iR-C3; Tue, 19 Jul 2005 13:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duvtz-0001i7-5J for sip@megatron.ietf.org; Tue, 19 Jul 2005 13:29:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16189 for ; Tue, 19 Jul 2005 13:29:04 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuwNd-0004az-GO for sip@ietf.org; Tue, 19 Jul 2005 13:59:47 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C3EB45FE; Tue, 19 Jul 2005 19:28:53 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 19:28:52 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 19:28:52 +0200 Received: from [131.160.126.1] (rvi2-126-gw.lmf.ericsson.se [131.160.126.1]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D59DE2500; Tue, 19 Jul 2005 20:28:51 +0300 (EEST) Message-ID: <42DD3852.70800@ericsson.com> Date: Tue, 19 Jul 2005 20:28:50 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] comment on draft-ietf-sip-sctp-06.txt References: <200506261631.j5QGVqLE004366@rautu.tutpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2005 17:28:52.0160 (UTC) FILETIME=[54D44C00:01C58C87] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Juha Heinanen , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Juha, this is a good point. My suggestion is that we remove the transport value for TLS over SCTP from the draft in AUTH48. Thanks for the comment, Gonzalo Dean Willis wrote: > On Jun 26, 2005, at 11:31 AM, Juha Heinanen wrote: > >> draft-ietf-sip-sctp-06.txt has a note: >> >> Note that the value "tls", defined by RFC 3261, is intended for TLS over >> TCP. >> >> on the other hand 26.2.2 of rfc3261 has a note: >> >> The use of transport=tls has consequently been deprecated, partly >> because it was specific to a single hop of the request. >> >> so if a transport parameter indicating tls over tcp has been deprecated, >> why do we now need a transport parameter indicating tls over sctp? what >> makes sctp in this regards special as compared to tcp? > > > I wish I knew. > > I'd like to ask Jon Peterson to comment, as I think he contributed that > line of deprecation to 3261. Then again, it was debated during a > conference call at 3:00 AM as I was attending a 3GPP meeting in Sophia > Antipolis, so I might remember wrong. > > But in any case, it's a good question. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 19 15:52:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy90-0003Nc-Iz; Tue, 19 Jul 2005 15:52:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6b-0002cq-6B; Tue, 19 Jul 2005 15:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28063; Tue, 19 Jul 2005 15:50:14 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya8-0001bb-35; Tue, 19 Jul 2005 16:20:52 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6O-0002QR-67; Tue, 19 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Suppression of Session Initiation Protocol REFER Method Implicit Subscription Author(s) : O. Levin Filename : draft-ietf-sip-refer-with-norefersub-02.txt Pages : 9 Date : 2005-7-19 This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP option tag "norefersub" is defined to indicate support for this extension. A new SIP header field "Refer-Sub" is defined to request the usage of this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-with-norefersub-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19135013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-with-norefersub-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19135013.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jul 19 15:54:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyAD-0003tr-Th; Tue, 19 Jul 2005 15:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6l-0002i7-12; Tue, 19 Jul 2005 15:50:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28154; Tue, 19 Jul 2005 15:50:24 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya4-0001ZS-6r; Tue, 19 Jul 2005 16:20:46 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6M-0002L2-Gg; Tue, 19 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-01.txt Pages : 73 Date : 2005-7-19 This document presents the framework and requirements for usage of the Session Initiation Protocol (SIP) to convey user location information from one Session Initiation Protocol (SIP) entity to another SIP entity. We consider cases where location information is conveyed from end to end, as well as cases where message routing by intermediaries is influenced by the location of the session initiator, the user agent client (UAC). We offer a set of solutions to the requirements, each based on the scenario being addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-location-conveyance-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19121453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19121453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jul 19 21:11:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv37S-0002la-NH; Tue, 19 Jul 2005 21:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv37Q-0002lV-C2 for sip@megatron.ietf.org; Tue, 19 Jul 2005 21:11:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24445 for ; Tue, 19 Jul 2005 21:11:26 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv3bA-0000ak-3L for sip@ietf.org; Tue, 19 Jul 2005 21:42:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jul 2005 18:11:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jul 2005 18:11:15 -0700 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 Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-02.txt Date: Tue, 19 Jul 2005 18:11:17 -0700 Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-02.txt Thread-Index: AcWMoVqbpocRfuhJR4qtFWlTWOks/gAJbXsg From: "Orit Levin" To: X-OriginalArrivalTime: 20 Jul 2005 01:11:15.0554 (UTC) FILETIME=[ED2E4420:01C58CC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Guys, The submitted draft is according to my best understanding of the agreement from the last IETF and I am not aware of any open issues associated with it. That being said, in the process of writing this version, I came to think that having a new general "Request-Options" or "Request" header containing any defined option tags (and being positively responded by a Require header) would be a better approach than having a specific Refer-Sub header sent in both directions as in the current draft. Any opinions? Orit. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, July 19, 2005 12:50 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Working Group > of the IETF. >=20 > Title : Suppression of Session Initiation Protocol > REFER Method Implicit Subscription > Author(s) : O. Levin > Filename : draft-ietf-sip-refer-with-norefersub-02.txt > Pages : 9 > Date : 2005-7-19 >=20 > This specification defines a way to suppress an implicit subscription > with the Session Initiation Protocol (SIP) REFER method. A new SIP > option tag "norefersub" is defined to indicate support for this > extension. A new SIP header field "Refer-Sub" is defined to request > the usage of this extension. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub - > 02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-refer-with-norefersub-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-02.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 20 15:52:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKc8-0006uc-M7; Wed, 20 Jul 2005 15:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKa9-000648-A2; Wed, 20 Jul 2005 15:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25244; Wed, 20 Jul 2005 15:50:14 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3q-0004Ka-HW; Wed, 20 Jul 2005 16:21:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007nT-3k; Wed, 20 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 20 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-target-dialog-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-target-dialog-01.txt Pages : 16 Date : 2005-7-20 This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-target-dialog-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-target-dialog-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20141021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-target-dialog-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-target-dialog-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20141021.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 20 15:53:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKcw-0007Qh-HJ; Wed, 20 Jul 2005 15:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKaE-00066W-JZ; Wed, 20 Jul 2005 15:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25326; Wed, 20 Jul 2005 15:50:20 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3r-0004L4-2X; Wed, 20 Jul 2005 16:21:04 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007ow-Ll; Wed, 20 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 20 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sip-connect-reuse-04.txt Pages : 14 Date : 2005-7-20 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connect-reuse-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connect-reuse-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20151629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20151629.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 20 22:34:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQtd-0006Ad-LI; Wed, 20 Jul 2005 22:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQtb-000662-U8 for sip@megatron.ietf.org; Wed, 20 Jul 2005 22:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00490 for ; Wed, 20 Jul 2005 22:34:45 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvRNZ-0000yv-1R for sip@ietf.org; Wed, 20 Jul 2005 23:05:45 -0400 Received: from Mpierce1@aol.com by imo-m23.mx.aol.com (mail_out_v38_r1.7.) id l.129.614a2445 (4254) for ; Wed, 20 Jul 2005 22:34:31 -0400 (EDT) Message-ID: <129.614a2445.301063b6@aol.com> Date: Wed, 20 Jul 2005 22:34:30 EDT Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Score: 0.7 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1466259595==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1466259595== Content-Type: multipart/alternative; boundary="part1_129.614a2445.301063b6_boundary" --part1_129.614a2445.301063b6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, Recently, there was a discussion of the question of whether or not the INFO can be sent before the dialog has been established. There seemed to be various opinions on this, but no clear answer. This is a very important issue for SIP-T. As I noted before, INFO is defined in RFC 2976 where it states that it follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In fact, the main question about the use of INFO relates to its use during early dialog, a concept which was defined after INFO was defined. RFC 3261 states that the BYE is used: in the caller to callee direction, either in confirmed or early dialog state in the callee to called direction, on confirmed dialog only RFC 3398 indicates that the INFO is used to carry encapsulated ISUP: in the caller to called direction, even if INVITE transaction is not finished (i.e., in both early and confirmed dialog state) in the callee to caller direction, even before answer (i.e., in both early and confirmed dialog states) So, the use of INFO in RFC 3398 does not always follow the rules for BYE as stated in RFC 2976. Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following: a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established. b) INFO message in all other cases. So the ITU-T Recommendation does have the INFO following the rules for BYE. Is this a correct interpretation? Mike Pierce --part1_129.614a2445.301063b6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable To all,=

Recently, there was a discussion of the question of whether or not the INFO=20= can be sent before the dialog has been established. There seemed to be vario= us opinions on this, but no clear answer. This is a very important issue for= SIP-T.

As I noted before, INFO is defined in RFC 2976 where it states that it follo= ws the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In=20= fact, the main question about the use of INFO relates to its use during earl= y dialog, a concept which was defined after INFO was defined.

RFC 3261 states that the BYE is used:
in the caller to callee direction, either in confirmed or early dialog state=
in the callee to called direction, on confirmed dialog only

RFC 3398 indicates that the INFO is used to carry encapsulated ISUP:
in the caller to called direction, even if INVITE transaction is not finishe= d (i.e., in both early and confirmed dialog state)
in the callee to caller direction,  even before answer (i.e., in both e= arly and confirmed dialog states)

So, the use of INFO in RFC 3398 does not always follow the rules for BYE as=20= stated in RFC 2976.

Q.1912.5, on the other hand, describes how "transparent" messages are encaps= ulated, and it says they are carried in the following:
a) 183 Session Progress provisional response if this is sent by the I-IWU in= the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

So the ITU-T Recommendation does have the INFO following the rules for BYE.<= BR>
Is this a correct interpretation?

Mike Pierce
 --part1_129.614a2445.301063b6_boundary-- --===============1466259595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1466259595==-- From sip-bounces@ietf.org Thu Jul 21 10:31:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc4o-0005Dp-EB; Thu, 21 Jul 2005 10:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc4l-0005Dh-HL for sip@megatron.ietf.org; Thu, 21 Jul 2005 10:31:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05524 for ; Thu, 21 Jul 2005 10:31:01 -0400 (EDT) Received: from web60625.mail.yahoo.com ([209.73.178.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvcYl-0003hE-GZ for Sip@ietf.org; Thu, 21 Jul 2005 11:02:07 -0400 Received: (qmail 4063 invoked by uid 60001); 21 Jul 2005 14:30:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r0gToXdurAT4ZfiM/k/QRK5m7wUDZ8SeE0/RglNM68CbJiRnBozFgYYaLP5/YBCCpxM6AoSc82jNrpUaQWJkuofnwUoOT0fxT/04oge8pOJpuTexhgb7knTcyrxDLffvFGeWSEVCCj6cmQX1wSb0bCortferOpoTFnJdNR2vlGI= ; Message-ID: <20050721143049.4061.qmail@web60625.mail.yahoo.com> Received: from [200.141.104.39] by web60625.mail.yahoo.com via HTTP; Thu, 21 Jul 2005 11:30:48 ART Date: Thu, 21 Jul 2005 11:30:48 -0300 (ART) From: Paula Oliveira To: Sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sip] About the parameter Response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1897157658==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1897157658== Content-Type: multipart/alternative; boundary="0-291908145-1121956248=:3159" --0-291908145-1121956248=:3159 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA05524 What is the parameter "response" in the field Proxy-Authorization ? Where and When this parameter are used ? What are the values that contains this parameter ? What is the order of these fields ? =20 Thanks, Paula.=20 =09 --------------------------------- Yahoo! Acesso Gr=E1tis: Internet r=E1pida e gr=E1tis. Instale o discador = agora! --0-291908145-1121956248=:3159 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA05524 What is the parameter "response" in the field
Proxy-Authorization ? Wh= ere and When this parameter
are used ? What are the values that contai= ns this
parameter ? What is the order of these fields ?
 =
 Thanks,
Paula.
 

Yahoo! Acesso Gr=E1tis: Internet r=E1pida e g= r=E1tis. Instale o discador agora! --0-291908145-1121956248=:3159-- --===============1897157658== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1897157658==-- From sip-bounces@ietf.org Thu Jul 21 10:41:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcEp-0001MN-RE; Thu, 21 Jul 2005 10:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcEn-0001MI-KU for sip@megatron.ietf.org; Thu, 21 Jul 2005 10:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06458 for ; Thu, 21 Jul 2005 10:41:23 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvciq-0004Mb-O9 for sip@ietf.org; Thu, 21 Jul 2005 11:12:29 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6LEf9MS008831; Thu, 21 Jul 2005 09:41:11 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id <3MLTA1LT>; Thu, 21 Jul 2005 09:41:09 -0500 Message-ID: From: "Ejzak, Richard P (Richard)" To: "'Mpierce1@aol.com'" , sip@ietf.org Subject: RE: [Sip] INFO method used for ISUP to SIP IW (2nd round) Date: Thu, 21 Jul 2005 09:41:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563739618==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0563739618== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E02.39E552FA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C58E02.39E552FA Content-Type: text/plain Mike, I do not agree with your interpretation of Q.1912.5. Within RFC 3261 and RFC 3262, a dialog may be established by sending a reliable provisional or final response. Q.1912.5 simply says that if you haven't sent a reliable response yet (provisional or final, to establish a dialog), encapsulate a transparent backward ISUP message in a provisional. Your interpretation is correct without 100rel, but breaks down when using 100rel. So according to Q.1912.5, any transparent encapsulated ISUP in the backward direction after transmission of a reliable provisional response will use INFO, including during the period before transmission of the 200 OK response. Note that other (not transparent) ISUP messages follow different rules in Q.1912.5. Regarding the supposed constraints on the use of INFO, RFC 2976 says the following things: It is necessary that the mid-session signaling information traverse the post session setup SIP signaling path. This is the path taken by SIP re-INVITEs, BYEs and other SIP requests that are tied to an individual session. This allows SIP proxy servers to receive, and potentially act on, the mid-session signaling information. In RFC 3261 and RFC 3262, this requirement is also satisfied when a dialog is established using a reliable provisional response in support of, for example, the UPDATE request. RFC 2976 goes on to say: Unless stated otherwise, the protocol rules for the INFO request governing the usage of tags, Route and Record-Route, retransmission and reliability, CSeq incrementing and message formatting follow those in [1] as defined for the BYE request. Reference [1] is RFC 2543. This text only discusses the rules for formatting various header. It does not constrain INFO to all aspects of the use of BYE. And that's all that's said about the relationship of INFO to BYE at user agents. The real problem is that RFC 2976 has not been updated to match RFC 3261 and RFC 3262. But the intent of the original RFC seems clear enough to allow INFO in either direction once a dialog is established, such as by sending a reliable provisional response. I see no problem with either RFC 3398 or Q.1912.5 in their use of INFO. Richard Ejzak -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, July 20, 2005 9:35 PM To: sip@ietf.org Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) To all, Recently, there was a discussion of the question of whether or not the INFO can be sent before the dialog has been established. There seemed to be various opinions on this, but no clear answer. This is a very important issue for SIP-T. As I noted before, INFO is defined in RFC 2976 where it states that it follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In fact, the main question about the use of INFO relates to its use during early dialog, a concept which was defined after INFO was defined. RFC 3261 states that the BYE is used: in the caller to callee direction, either in confirmed or early dialog state in the callee to called direction, on confirmed dialog only RFC 3398 indicates that the INFO is used to carry encapsulated ISUP: in the caller to called direction, even if INVITE transaction is not finished (i.e., in both early and confirmed dialog state) in the callee to caller direction, even before answer (i.e., in both early and confirmed dialog states) So, the use of INFO in RFC 3398 does not always follow the rules for BYE as stated in RFC 2976. Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following: a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established. b) INFO message in all other cases. So the ITU-T Recommendation does have the INFO following the rules for BYE. Is this a correct interpretation? Mike Pierce ------_=_NextPart_001_01C58E02.39E552FA Content-Type: text/html
Mike,
I do not agree with your interpretation of Q.1912.5.  Within RFC 3261 and RFC 3262, a dialog may be established by sending a reliable provisional or final response.  Q.1912.5 simply says that if you haven't sent a reliable response yet (provisional or final, to establish a dialog), encapsulate a transparent backward ISUP message in a provisional.  Your interpretation is correct without 100rel, but breaks down when using 100rel.  So according to Q.1912.5, any transparent encapsulated ISUP in the backward direction after transmission of a reliable provisional response will use INFO, including during the period before transmission of the 200 OK response.  Note that other (not transparent) ISUP messages follow different rules in Q.1912.5.
 
Regarding the supposed constraints on the use of INFO, RFC 2976 says the following things:
 

   It is necessary that the mid-session signaling information traverse
   the post session setup SIP signaling path.  This is the path taken by
   SIP re-INVITEs, BYEs and other SIP requests that are tied to an
   individual session.  This allows SIP proxy servers to receive, and
   potentially act on, the mid-session signaling information.

In RFC 3261 and RFC 3262, this requirement is also satisfied when a dialog is established using a reliable provisional response in support of, for example, the UPDATE request.  RFC 2976 goes on to say:

 

      Unless stated otherwise, the protocol rules for the INFO request
      governing the usage of tags, Route and Record-Route,
      retransmission and reliability, CSeq incrementing and message
      formatting follow those in [1] as defined for the BYE request.

Reference [1] is RFC 2543.  This text only discusses the rules for formatting various header.  It does not constrain INFO to all aspects of the use of BYE.  And that's all that's said about the relationship of INFO to BYE at user agents.

 

The real problem is that RFC 2976 has not been updated to match RFC 3261 and RFC 3262.  But the intent of the original RFC seems clear enough to allow INFO in either direction once a dialog is established, such as by sending a reliable provisional response.  I see no problem with either RFC 3398 or Q.1912.5 in their use of INFO.

 

Richard Ejzak

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, July 20, 2005 9:35 PM
To: sip@ietf.org
Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round)

To all,

Recently, there was a discussion of the question of whether or not the INFO can be sent before the dialog has been established. There seemed to be various opinions on this, but no clear answer. This is a very important issue for SIP-T.

As I noted before, INFO is defined in RFC 2976 where it states that it follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In fact, the main question about the use of INFO relates to its use during early dialog, a concept which was defined after INFO was defined.

RFC 3261 states that the BYE is used:
in the caller to callee direction, either in confirmed or early dialog state
in the callee to called direction, on confirmed dialog only

RFC 3398 indicates that the INFO is used to carry encapsulated ISUP:
in the caller to called direction, even if INVITE transaction is not finished (i.e., in both early and confirmed dialog state)
in the callee to caller direction,  even before answer (i.e., in both early and confirmed dialog states)

So, the use of INFO in RFC 3398 does not always follow the rules for BYE as stated in RFC 2976.

Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following:
a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

So the ITU-T Recommendation does have the INFO following the rules for BYE.

Is this a correct interpretation?

Mike Pierce
------_=_NextPart_001_01C58E02.39E552FA-- --===============0563739618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0563739618==-- From sip-bounces@ietf.org Thu Jul 21 15:45:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgzI-0008A4-K5; Thu, 21 Jul 2005 15:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgzG-000876-U3 for sip@megatron.ietf.org; Thu, 21 Jul 2005 15:45:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03219 for ; Thu, 21 Jul 2005 15:45:41 -0400 (EDT) Received: from web60612.mail.yahoo.com ([209.73.178.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvhTJ-0000Bx-SE for sip@ietf.org; Thu, 21 Jul 2005 16:16:49 -0400 Received: (qmail 85361 invoked by uid 60001); 21 Jul 2005 19:45:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jadJthZS4AeIx4JxBxEX14uQhOFMQTqAZuZLs0LswS/6zaCmW9SaJ3QtpWpuRNE4PJbeaBd/2C0nDWckuXdbXU0e4JxtxLpGctRKUfQDr0D7aurTBiWRjR+ufsDQwBAIanH38h+G8dBP58IltkHI84ulD+S0rPHCGTkCrMbj/2Q= ; Message-ID: <20050721194530.85359.qmail@web60612.mail.yahoo.com> Received: from [200.141.104.39] by web60612.mail.yahoo.com via HTTP; Thu, 21 Jul 2005 16:45:30 ART Date: Thu, 21 Jul 2005 16:45:30 -0300 (ART) From: Paula Oliveira To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] About the parameter Response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1638278814==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1638278814== Content-Type: multipart/alternative; boundary="0-281063401-1121975130=:84194" --0-281063401-1121975130=:84194 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA03219 Hi Robert, I am trying to develop a software that acts with a Server Sip and a Proxy= . Now I'm studying this protocol and I have a doubt about the parameter R= esponse in the field Proxy-Authorization. I know that field is encrypted = by a MD5, but I don=B4t know what fields and order these fields are encry= pted, please, help me, it 's so important to me. Thanks Paula.=20 =09 --------------------------------- Yahoo! Acesso Gr=E1tis: Internet r=E1pida e gr=E1tis. Instale o discador = agora! --0-281063401-1121975130=:84194 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA03219
Hi Robert,
I am trying to develop a software that acts with a Server Sip and a = Proxy. Now I'm studying this protocol and I have a doubt about the parame= ter Response in the field Proxy-Authorization. I know that field is encry= pted by a MD5, but I don=B4t know what fields and order these fields are = encrypted, please, help me, it 's so important to me.
Thanks
Paula.

Yahoo! Acesso Gr=E1tis: Internet r=E1pida e g= r=E1tis. Instale o discador agora! --0-281063401-1121975130=:84194-- --===============1638278814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1638278814==-- From sip-bounces@ietf.org Thu Jul 21 18:15:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvjIR-00011e-Qa; Thu, 21 Jul 2005 18:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvjIP-0000uR-4e for sip@megatron.ietf.org; Thu, 21 Jul 2005 18:13:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18140 for ; Thu, 21 Jul 2005 18:13:34 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvjmU-0003wg-FD for sip@ietf.org; Thu, 21 Jul 2005 18:44:44 -0400 Received: from [64.101.149.168] (romcmaho-w2k.cisco.com [64.101.149.168] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6LMHOmd014416 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 21 Jul 2005 17:17:25 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <0ff8c67196dcf7e1b3c802cb7f5bf043@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip@ietf.org From: Dean Willis Date: Thu, 21 Jul 2005 17:13:36 -0500 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Sip] Proposed agenda for SIP at IETF 63 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Here's the draft agenda for the SIP WG meetings at IETF 63. Please respond with any issues posthaste. Pretty tabular version at: http://www.softarmor.com/sipwg/meets/ietf63/agenda.html Monday Session 10:30-12:30 1040 Jonathan Rosenberg, GRUU draft-ietf-sip-gruu-04.txt 1100 Jonathan Rosenberg, Target Dialogs draft-ietf-sip-target-dialog-00.txt 1120 Kumiko ONO, End to Middle Security draft-ietf-sip-e2m-sec-00.txt 1140 Cullen Jennings, Outbound Connections draft-ietf-sip-outbound-00.txt 1200 Orit Levin, REFER with no Subscription draft-ietf-sip-refer-with-norefersub-02.txt 1215 Orit Levin, REFER Feature Parameters draft-ietf-sip-refer-feature-param-00.txt Tuesday Session 14:00-16:00 1400 James Polk, Location Conveyance draft-ietf-sip-location-conveyance-01.txt 1420 Feng Cao, Cullen Jennings, Response identity draft-cao-sip-response-auth-00.txt 1440 Hannes Tschofenig, SAML with SIP draft-tschofenig-sip-saml-03.txt 1500 Dean Willis Andrew Allen, Answer and Alert Mode Extension draft-willis-sip-answeralert-00.txt 1520 Cullen Jennings, Use of Certificates draft-ietf-sipping-certs-02.txt 1540 Cullen Jennings, Security flows draft-jennings-sip-sec-flows-03.txt -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 21 22:18:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvn7F-0001u7-3r; Thu, 21 Jul 2005 22:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvn7C-0001u2-MZ for sip@megatron.ietf.org; Thu, 21 Jul 2005 22:18:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11112 for ; Thu, 21 Jul 2005 22:18:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvnbK-000256-31 for sip@ietf.org; Thu, 21 Jul 2005 22:49:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2005 19:18:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6M2I6JL013053 for ; Thu, 21 Jul 2005 19:18:06 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 19:18:10 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.46]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 19:18:06 -0700 Message-Id: <4.3.2.7.2.20050721210303.02b7b4a8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Jul 2005 21:18:04 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 Jul 2005 02:18:06.0334 (UTC) FILETIME=[989E39E0:01C58E63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] New Location Conveyance ID -01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIP WG I have updated the SIP Location Conveyance ID at the following link: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt There are many changes to this version from the previous (1 month old) version. Here is a short list of those changes: - rewrote/rearranged much of the middle of the doc, - adding Reqs that have been brought to my attention, - adding a new header to solve many scenarios presented - needing a solution, - bringing up the 424 and 425 Response code sections to the beginning of the solution portion of the ID for clarity, - moving most of the XML portions of the message flows back to 10 incomplete appendixes. - I also give two examples of the same position on the earth (my house) in geo and civic to show the PIDF-LO (between the status lines only). - I spent a great deal of time walking the reader through expected behaviors of each SIP element in each scenario (this is the request, here is a viable 200 OK, now here are the alternative responses and what each significant header accomplishes - other than the Call-ID, CSeq, Via, and the other "normal" ones). This new header is (surprisingly) called "Location" - with an admittedly incomplete ABNF (sorry). This header currently has many option-tags defined, some indicating what format the location is in from the message, others indicating what format is desired to receive back from the query for the UAC's location (see the new OPTIONS and SUB/NOT sections for this), one indicates location is in the message - even if a particular intermediary cannot decrypt it. A CID pointing at which message body is location is also possible now in a SIP Request, as well as allowing for location conveyance by-reference. This last new capability has limitations that are discussed, though I do not believe I have addressed yet all the limitations of this approach. Comments to the SIP list are appreciated cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 22 08:33:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvwim-0002RE-O4; Fri, 22 Jul 2005 08:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvwik-0002QN-RF for sip@megatron.ietf.org; Fri, 22 Jul 2005 08:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08794 for ; Fri, 22 Jul 2005 08:33:40 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvxCy-0003RR-RQ for sip@ietf.org; Fri, 22 Jul 2005 09:04:58 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK100HYY4CTH5@szxga03-in.huawei.com> for sip@ietf.org; Fri, 22 Jul 2005 20:36:29 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK100BJH4CT2K@szxga03-in.huawei.com> for sip@ietf.org; Fri, 22 Jul 2005 20:36:29 +0800 (CST) Received: from GUEST ([10.76.176.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK100H6A4N9G3@szxml01-in.huawei.com>; Fri, 22 Jul 2005 20:42:45 +0800 (CST) Date: Fri, 22 Jul 2005 20:33:37 +0800 From: Peili Xu Subject: RE: [Sip] About the parameter Response In-reply-to: <20050721194530.85359.qmail@web60612.mail.yahoo.com> To: "'Paula Oliveira'" , sip@ietf.org Message-id: <001d01c58eb9$953b1ba0$5fb04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1134987232==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1134987232== Content-type: multipart/alternative; boundary="Boundary_(ID_UyxsTuwr43xF6if2RZNH9A)" This is a multi-part message in MIME format. --Boundary_(ID_UyxsTuwr43xF6if2RZNH9A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi=20 =20 The Sip-implementors mailing list may give you much help on such implementation issues=20 =20 Please go to: = http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Paula Oliveira Sent: Friday, July 22, 2005 3:46 AM To: sip@ietf.org Subject: [Sip] About the parameter Response =20 =20 Hi Robert, I am trying to develop a software that acts with a Server Sip and a = Proxy. Now I'm studying this protocol and I have a doubt about the parameter Response in the field Proxy-Authorization. I know that field is = encrypted by a MD5, but I don=B4t know what fields and order these fields are = encrypted, please, help me, it 's so important to me. Thanks Paula.=20 _____ =20 Yahoo! Acesso Gr=E1tis: Internet r=E1pida e gr=E1tis. Instale o discador = agora! --Boundary_(ID_UyxsTuwr43xF6if2RZNH9A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=A0=A0=A0=A0=A0=A0=A0Hi

 

=A0=A0=A0=A0=A0=A0 The = Sip-implementors mailing list may give you much help on such implementation issues =

 

Please go to: = h= ttp://lists.cs.columbia.edu/mailman/listinfo/sip-implementors<= /font>

 

 

-----Original Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Paula Oliveira
Sent: Friday, July 22, 2005 3:46 AM
To: sip@ietf.org<= font size=3D2 face=3DTahoma>
Subject: [Sip] About the = parameter Response

 

 

Hi Robert,

I = am trying to develop a software that acts with a Server Sip and a Proxy. Now I'm = studying this protocol and I have a doubt about the parameter Response in the = field Proxy-Authorization. I know that field is encrypted by a MD5, but I = don=B4t know what fields and order these fields are encrypted, please, help me, it 's = so important to me.

Thanks

Paula.

Yahoo! Acesso Gr=E1tis: Internet r=E1pida e gr=E1tis. Instale o discador agora!

--Boundary_(ID_UyxsTuwr43xF6if2RZNH9A)-- --===============1134987232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1134987232==-- From sip-bounces@ietf.org Fri Jul 22 08:45:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvwu8-0007bt-C5; Fri, 22 Jul 2005 08:45:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvwu5-0007XW-Hx for sip@megatron.ietf.org; Fri, 22 Jul 2005 08:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09667 for ; Fri, 22 Jul 2005 08:45:23 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvxOE-0003sF-Uu for sip@ietf.org; Fri, 22 Jul 2005 09:16:40 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK1009C649WSB@szxga02-in.huawei.com> for sip@ietf.org; Fri, 22 Jul 2005 20:34:44 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK100L7M49WL4@szxga02-in.huawei.com> for sip@ietf.org; Fri, 22 Jul 2005 20:34:44 +0800 (CST) Received: from GUEST ([10.76.176.95]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK100BQR49PNS@szxml02-in.huawei.com>; Fri, 22 Jul 2005 20:34:37 +0800 (CST) Date: Fri, 22 Jul 2005 20:28:37 +0800 From: Peili Xu Subject: RE: [Sip] INFO method used for ISUP to SIP IW (2nd round) In-reply-to: To: "'Ejzak, Richard P (Richard)'" , Mpierce1@aol.com, sip@ietf.org Message-id: <001801c58eb8$e29d1840$5fb04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986259442==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1986259442== Content-type: multipart/alternative; boundary="Boundary_(ID_EQOI2fxYZu8lBGrNASiO2w)" This is a multi-part message in MIME format. --Boundary_(ID_EQOI2fxYZu8lBGrNASiO2w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Mike, =20 I totally agree with your comments about=20 (1)INFO can be sent within dialog of cause at lease after early dialog = is established. (2)transparent backward ISUP message may be encapsulated in reliable 1xx = or INFO. =20 But from the exact Q.1912.5 specification:=20 --Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following: --a) 183 Session Progress provisional response if this is sent by the = I-IWU in the backward direction before a confirmed dialog is established. --b) INFO message in all other cases.=20 =20 It seems that backward ISUP message before call is connected must be = carried in 183 before a =93confirmed dialog=94,=20 I think this is the point which confuse some people who consider that = INFO in early dialog is another option. =20 Reguards! =20 Peili Xu =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Ejzak, Richard P (Richard) Sent: Thursday, July 21, 2005 10:41 PM To: 'Mpierce1@aol.com'; sip@ietf.org Subject: RE: [Sip] INFO method used for ISUP to SIP IW (2nd round) =20 Mike, I do not agree with your interpretation of Q.1912.5. Within RFC 3261 = and RFC 3262, a dialog may be established by sending a reliable provisional = or final response. Q.1912.5 simply says that if you haven't sent a = reliable response yet (provisional or final, to establish a dialog), encapsulate = a transparent backward ISUP message in a provisional. Your interpretation = is correct without 100rel, but breaks down when using 100rel. So according = to Q.1912.5, any transparent encapsulated ISUP in the backward direction = after transmission of a reliable provisional response will use INFO, including during the period before transmission of the 200 OK response. Note that other (not transparent) ISUP messages follow different rules in = Q.1912.5. =20 Regarding the supposed constraints on the use of INFO, RFC 2976 says the following things: =20 It is necessary that the mid-session signaling information traverse the post session setup SIP signaling path. This is the path taken by SIP re-INVITEs, BYEs and other SIP requests that are tied to an individual session. This allows SIP proxy servers to receive, and potentially act on, the mid-session signaling information. In RFC 3261 and RFC 3262, this requirement is also satisfied when a = dialog is established using a reliable provisional response in support of, for example, the UPDATE request. RFC 2976 goes on to say: =20 Unless stated otherwise, the protocol rules for the INFO request governing the usage of tags, Route and Record-Route, retransmission and reliability, CSeq incrementing and message formatting follow those in [1] as defined for the BYE request. Reference [1] is RFC 2543. This text only discusses the rules for formatting various header. It does not constrain INFO to all aspects of = the use of BYE. And that's all that's said about the relationship of INFO = to BYE at user agents. =20 The real problem is that RFC 2976 has not been updated to match RFC 3261 = and RFC 3262. But the intent of the original RFC seems clear enough to = allow INFO in either direction once a dialog is established, such as by = sending a reliable provisional response. I see no problem with either RFC 3398 or Q.1912.5 in their use of INFO. =20 Richard Ejzak -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, July 20, 2005 9:35 PM To: sip@ietf.org Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) To all, Recently, there was a discussion of the question of whether or not the = INFO can be sent before the dialog has been established. There seemed to be various opinions on this, but no clear answer. This is a very important issue for SIP-T. As I noted before, INFO is defined in RFC 2976 where it states that it follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In fact, the main question about the use of INFO relates to = its use during early dialog, a concept which was defined after INFO was = defined. RFC 3261 states that the BYE is used: in the caller to callee direction, either in confirmed or early dialog = state in the callee to called direction, on confirmed dialog only RFC 3398 indicates that the INFO is used to carry encapsulated ISUP: in the caller to called direction, even if INVITE transaction is not finished (i.e., in both early and confirmed dialog state) in the callee to caller direction, even before answer (i.e., in both = early and confirmed dialog states) So, the use of INFO in RFC 3398 does not always follow the rules for BYE = as stated in RFC 2976. Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following: a) 183 Session Progress provisional response if this is sent by the = I-IWU in the backward direction before a confirmed dialog is established. b) INFO message in all other cases.=20 So the ITU-T Recommendation does have the INFO following the rules for = BYE. Is this a correct interpretation? Mike Pierce --Boundary_(ID_EQOI2fxYZu8lBGrNASiO2w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi, = Mike,

 

=A0=A0=A0=A0=A0 I = totally agree with your comments about

(1)INFO can be sent within dialog of cause at lease after = early dialog is established.

(2)transparent backward ISUP message may be encapsulated in reliable 1xx or INFO.

 

=A0But from the exact Q.1912.5 specification: =

--Q.1912.5, on = the other hand, describes how "transparent" messages are encapsulated, = and it says they are carried in the following:
--a) 183 Session Progress provisional response if this is sent by the = I-IWU in the backward direction before a confirmed dialog is established.
--b) INFO message in all other cases.

 

It seems that = backward ISUP message before call is connected must be carried in 183 before a = “confirmed dialog”,

I think this = is the point which confuse some people who consider that INFO in early dialog is = another option.

 

Reguards!

 

Peili Xu

 

-----Original Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Ejzak, Richard P (Richard)
Sent: Thursday, July 21, 2005 10:41 PM
To: 'Mpierce1@aol.com'; sip@ietf.org
Subject: RE: [Sip] INFO = method used for ISUP to SIP IW (2nd round)

 

Mike,

I do not agree with your interpretation of Q.1912.5.  = Within RFC 3261 and RFC 3262, a dialog may be established by sending a reliable provisional or final response.  Q.1912.5 simply says that if you = haven't sent a reliable response yet (provisional or final, to establish a = dialog), encapsulate a transparent backward ISUP message in a provisional.  Your interpretation is = correct without 100rel, but breaks down when using 100rel.  So according to Q.1912.5, any transparent encapsulated ISUP in the backward direction after transmission of a = reliable provisional response will use INFO, including during the period before transmission of the 200 OK response.  Note that other (not = transparent) ISUP messages follow different rules in Q.1912.5.

 

Regarding the supposed constraints on the use of INFO, RFC = 2976 says the following things:

 

=A0=A0 It is = necessary that the mid-session signaling information traverse
=A0=A0 the post session setup SIP signaling path.=A0 This is the path = taken by
=A0=A0 SIP re-INVITEs, BYEs and other SIP requests that are tied to = an
=A0=A0 individual session.=A0 This allows SIP proxy servers to receive, = and
=A0=A0 potentially act on, the mid-session signaling = information.

In = RFC 3261 and RFC 3262, this requirement is also satisfied when a dialog is = established using a reliable provisional response in support of, for example, the = UPDATE request.  RFC 2976 goes on to say:

 

=A0=A0=A0=A0=A0 = Unless stated otherwise, the protocol rules for the INFO request
=A0=A0=A0=A0=A0 governing the usage of tags, Route and Record-Route,
=A0=A0=A0=A0=A0 retransmission and reliability, CSeq incrementing and = message
=A0=A0=A0=A0=A0 formatting follow those in [1] as defined for the BYE = request.

Reference [1] is RFC 2543.  This text only discusses the rules for formatting = various header.  It does not constrain INFO to all aspects of the use of BYE.  And = that's all that's said about the relationship of INFO to BYE at user = agents.

 

The = real problem is that RFC 2976 has not been updated to match RFC 3261 and RFC 3262.  But the intent of the original RFC seems clear enough to = allow INFO in either direction once a dialog is established, such as by sending a = reliable provisional response.  I see no problem with either RFC 3398 or = Q.1912.5 in their use of INFO.

 

Richard = Ejzak

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, July 20, = 2005 9:35 PM
To: sip@ietf.org<= font size=3D2 face=3DTahoma>
Subject: Re: [Sip] INFO = method used for ISUP to SIP IW (2nd round)

To all,

Recently, there was a discussion of the question of whether or not the = INFO can be sent before the dialog has been established. There seemed to be = various opinions on this, but no clear answer. This is a very important issue = for SIP-T.

As I noted before, INFO is defined in RFC 2976 where it states that it = follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In = fact, the main question about the use of INFO relates to its use during early = dialog, a concept which was defined after INFO was defined.

RFC 3261 states that the BYE is used:
in the caller to callee direction, either in confirmed or early dialog = state
in the callee to called direction, on confirmed dialog only

RFC 3398 indicates that the INFO is used to carry encapsulated ISUP:
in the caller to called direction, even if INVITE transaction is not = finished (i.e., in both early and confirmed dialog state)
in the callee to caller direction,  even before answer (i.e., in = both early and confirmed dialog states)

So, the use of INFO in RFC 3398 does not always follow the rules for BYE = as stated in RFC 2976.

Q.1912.5, on the other hand, describes how "transparent" = messages are encapsulated, and it says they are carried in the following:
a) 183 Session Progress provisional response if this is sent by the = I-IWU in the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

So the ITU-T Recommendation does have the INFO following the rules for = BYE.

Is this a correct interpretation?

Mike Pierce

--Boundary_(ID_EQOI2fxYZu8lBGrNASiO2w)-- --===============1986259442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1986259442==-- From sip-bounces@ietf.org Fri Jul 22 09:06:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxEL-00087y-Ql; Fri, 22 Jul 2005 09:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxEG-00085z-QX for sip@megatron.ietf.org; Fri, 22 Jul 2005 09:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12829 for ; Fri, 22 Jul 2005 09:06:14 -0400 (EDT) Received: from web60625.mail.yahoo.com ([209.73.178.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvxiP-0004eE-Nb for sip@ietf.org; Fri, 22 Jul 2005 09:37:32 -0400 Received: (qmail 70013 invoked by uid 60001); 22 Jul 2005 13:06:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1zN14M97ickvbx2SRsbLPUSem64QO8xuoSUIqPBZC3yt11og072r0IOKD49Av+s+D06fOHO4ReXgGKZ7DXQhN3KKO+OiufnJthp80JbJ7j0t9Z6jCbN/r46dzH/jRYM4Fx8TXzkeOwqlmijVzsT19rST891LR14hDflUceVc9K4= ; Message-ID: <20050722130601.70011.qmail@web60625.mail.yahoo.com> Received: from [200.141.104.39] by web60625.mail.yahoo.com via HTTP; Fri, 22 Jul 2005 10:06:01 ART Date: Fri, 22 Jul 2005 10:06:01 -0300 (ART) From: Paula Oliveira To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] About the response digest X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563431969==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0563431969== Content-Type: multipart/alternative; boundary="0-72652670-1122037561=:66935" --0-72652670-1122037561=:66935 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA12829 Hi,=20 I am developing a server sip, and now I am studying this protocol. I have= a doubt about the parameter response in the field proxy authorization. W= hat are the fields and the order that it are in the response ? I read som= e RFCs but I believe that my case is so specific, because I test every or= der that I see and I don=B4t find de correct result of a MD5. I don=B4t k= now if I want concat other fields, basically is this: A1:username:realm:password A2:method:Digest-URI response =3D MD5(MD5(A1):nonce:MD5(A2)) But I don=B4t find the correct Result. Have other field in this case ? Th= e parameter Branch is necessary ? =20 Thanks, Paula.=20 __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger=20 http://br.download.yahoo.com/messenger/=20 --0-72652670-1122037561=:66935 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA12829
Hi,

I am developing a server sip, and now I am studying this protoco= l. I have a doubt about the parameter response in the field proxy authori= zation. What are the fields and the order that it are in the response ? I= read some RFCs but I believe that my case is so specific, because I test= every order that I see and I don=B4t find de correct result of a MD5. I = don=B4t know if I want concat other fields, basically is this:
A1:username:realm:password
A2:method:Digest-URI
response =3D MD5(MD5(A1):nonce:MD5(A2))
But I don=B4t find the correct Result. Have other field in this case= ? The parameter Branch is necessary ?
 
Thanks,
Paula.

______________________________________= ____________
Converse com seus amigos em tempo real com o Yahoo! Messe= nger
http://br.download.yahoo.com/messenger/=20 --0-72652670-1122037561=:66935-- --===============0563431969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0563431969==-- From sip-bounces@ietf.org Fri Jul 22 14:40:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2Rl-00077A-MD; Fri, 22 Jul 2005 14:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2Rj-000775-Fs for sip@megatron.ietf.org; Fri, 22 Jul 2005 14:40:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09106 for ; Fri, 22 Jul 2005 14:40:29 -0400 (EDT) Received: from [216.29.181.162] (helo=mahatma.gandhilinux.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dw2vy-0000jF-IK for sip@ietf.org; Fri, 22 Jul 2005 15:11:50 -0400 Received: (qmail 30127 invoked by uid 0); 22 Jul 2005 18:40:14 -0000 Received: from unknown (HELO ?192.168.1.7?) (dbrond@68.74.104.123) by 0 with SMTP; 22 Jul 2005 18:40:14 -0000 Message-ID: <42E13D86.30309@brondsema.net> Date: Fri, 22 Jul 2005 14:40:06 -0400 From: Dave Brondsema User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 1.2 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] pgp authentication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189401618==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0189401618== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig28062B96912E763AC5594B48" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig28062B96912E763AC5594B48 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Why was pgp authentication removed in rfc3261? A note mentions "PGP MIME" is more complete, but I can't find any other RFC with a WWW-Authentication scheme for PGP. What is the recommended way to implement WWW-Authentication using PGP? Thanks! -- Dave Brondsema : dave@brondsema.net http://www.splike.com : programming http://www.brondsema.net : personal <>< --------------enig28062B96912E763AC5594B48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC4T2GVvBSb5uzznARAtCqAJwNWiKv6b/QgrLCyWkYtrA0TTwfbgCeJ7SI wFCJCvcjHHyM6htuT1FsPs4= =nH1P -----END PGP SIGNATURE----- --------------enig28062B96912E763AC5594B48-- --===============0189401618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0189401618==-- From sip-bounces@ietf.org Fri Jul 22 17:48:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5NI-0002dS-If; Fri, 22 Jul 2005 17:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5NF-0002dK-S4 for sip@megatron.ietf.org; Fri, 22 Jul 2005 17:48:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00634 for ; Fri, 22 Jul 2005 17:48:02 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5rY-0001jK-D8 for sip@ietf.org; Fri, 22 Jul 2005 18:19:25 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j6MLlpE24599; Fri, 22 Jul 2005 14:47:51 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 22 Jul 2005 14:47:47 -0700 To: SIP WG X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Dean Willis Subject: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Folks, I'd like to begin an abbreviated WGLC for draft-ietf-sip-target-dialog-01.txt. This WGLC will end on August 15th. thanks, -rohan Rohan Mahy co-chair SIP WG _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 23 10:35:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL6C-0005If-DF; Sat, 23 Jul 2005 10:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwL6A-0005Ia-Q2 for sip@megatron.ietf.org; Sat, 23 Jul 2005 10:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29297 for ; Sat, 23 Jul 2005 10:35:28 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwLaa-00071s-BD for sip@ietf.org; Sat, 23 Jul 2005 11:06:59 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IK3005014ERLO@siemenscomms.co.uk> for sip@ietf.org; Sat, 23 Jul 2005 15:32:51 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IK30014W4ERC0@siemenscomms.co.uk>; Sat, 23 Jul 2005 15:32:51 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 23 Jul 2005 15:35:11 +0100 Content-return: allowed Date: Sat, 23 Jul 2005 15:35:10 +0100 From: Elwell John Subject: RE: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt To: jdrosen@cisco.com Message-id: <50B1CBA96870A34799A506B2313F26670602E93F@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Cc: SIP WG , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Minor comments: 1. Section 3, item 2, "The user agent client believes that the request will not be authorized by the user agent server unless the user agent client can prove that it is aware of the dialog identifiers for some other dialog. Call this dialog the target dialog." Should we change "will not" to "might not"? Even if the UAC does not know for certain, use of target-dialog should be applicable. 2. Section 3, examples of use cases in which conditions are not met. There seems to be a cut-and-paste error in the second bullet - the dialog package does not show key presses. 3. Typo "speific" after last bullet. 4. Section 4, penultimate paragraph: "and thus the authorization strength is reduced to MAY". It is the strength of the requirement for authorization, not the authorization strength, that is reduced. I would propose to say instead "and thus authorization is optional". John > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: 22 July 2005 22:48 > To: SIP WG > Cc: Rohan Mahy; Dean Willis > Subject: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt > > Hi Folks, > > I'd like to begin an abbreviated WGLC for > draft-ietf-sip-target-dialog-01.txt. This WGLC will end on August > 15th. > > thanks, > -rohan > Rohan Mahy > co-chair SIP WG > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 04:00:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwxsv-0002ea-FT; Mon, 25 Jul 2005 04:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwxst-0002eV-CC for sip@megatron.ietf.org; Mon, 25 Jul 2005 04:00:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25408 for ; Mon, 25 Jul 2005 04:00:21 -0400 (EDT) Received: from mail.androme.com ([62.58.96.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwyNe-0007jm-6i for sip@ietf.org; Mon, 25 Jul 2005 04:32:13 -0400 Received: from [172.17.10.40] ([172.17.10.40]) by mail.androme.com (8.12.10/8.12.10) with ESMTP id j6P808CT008455 for ; Mon, 25 Jul 2005 10:00:08 +0200 Message-ID: <42E49C08.6050506@androme.com> Date: Mon, 25 Jul 2005 10:00:08 +0200 From: Sigrid Thijs User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Sip] History-Info vs Diversion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, I'm taking a closer look to SIP extensions that keep track of call diversions. Both the History-Info and Diversion header seem to be valid candidates. I found the following documents defining these extensions: - history-info: draft-ietf-sip-history-info-06.txt, expires July 17th, 2005 - diversion: draft-levy-diversion-08.txt, expires February 25,2005 What is the current status of these extensions? Is there still being worked on, are there new drafts on the way? kind regards, Sigrid Thijs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 04:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyOc-00009N-3v; Mon, 25 Jul 2005 04:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyOZ-00009G-U8 for sip@megatron.ietf.org; Mon, 25 Jul 2005 04:33:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27451 for ; Mon, 25 Jul 2005 04:33:06 -0400 (EDT) Received: from thymine159.gprs.dnafinland.fi ([62.78.126.159] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwytL-0000Ru-6M for sip@ietf.org; Mon, 25 Jul 2005 05:04:59 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-1) with ESMTP id j6P8WoxP004356; Mon, 25 Jul 2005 11:32:50 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j6P8WoL7004353; Mon, 25 Jul 2005 11:32:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17124.41906.568867.546457@rautu.tutpro.com> Date: Mon, 25 Jul 2005 11:32:50 +0300 From: Juha Heinanen To: Sigrid Thijs Subject: [Sip] History-Info vs Diversion In-Reply-To: <42E49C08.6050506@androme.com> References: <42E49C08.6050506@androme.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sigrid Thijs writes: > I found the following documents defining these extensions: > - history-info: draft-ietf-sip-history-info-06.txt, expires July 17th, 2005 > - diversion: draft-levy-diversion-08.txt, expires February 25,2005 > What is the current status of these extensions? Is there still being > worked on, are there new drafts on the way? draft-levy seems to be de-facto standard that many products have implemented, -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 06:48:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0Ve-0006jN-HN; Mon, 25 Jul 2005 06:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0Vc-0006jF-94; Mon, 25 Jul 2005 06:48:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05225; Mon, 25 Jul 2005 06:48:29 -0400 (EDT) Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx10Q-0004TT-Ve; Mon, 25 Jul 2005 07:20:24 -0400 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id F03BE4976A; Mon, 25 Jul 2005 10:48:07 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id BFD3D82; Mon, 25 Jul 2005 10:48:07 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id 9D6F16D; Mon, 25 Jul 2005 10:48:07 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 5974F3C; Mon, 25 Jul 2005 10:48:07 +0000 (GMT) In-Reply-To: <42E49C08.6050506@androme.com> To: Sigrid Thijs Subject: Re: [Sip] History-Info vs Diversion MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Mon, 25 Jul 2005 12:45:55 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF244 | July 13, 2005) at 25/07/2005 12:45:53, Serialize complete at 25/07/2005 12:45:53 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sigrid, Also check out the ECMA-360 standard at: http://www.ecma-international.org/publications/standards/Ecma-360.htm. It describes ways of doing diversion. Cheers, Frank Sigrid Thijs Sent by: sip-bounces@ietf.org 2005-07-25 10:00 AM To sip@ietf.org cc Subject [Sip] History-Info vs Diversion Classification Hello, I'm taking a closer look to SIP extensions that keep track of call diversions. Both the History-Info and Diversion header seem to be valid candidates. I found the following documents defining these extensions: - history-info: draft-ietf-sip-history-info-06.txt, expires July 17th, 2005 - diversion: draft-levy-diversion-08.txt, expires February 25,2005 What is the current status of these extensions? Is there still being worked on, are there new drafts on the way? kind regards, Sigrid Thijs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 08:33:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx29R-00043b-Tu; Mon, 25 Jul 2005 08:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx29Q-00043W-39 for sip@megatron.ietf.org; Mon, 25 Jul 2005 08:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14647 for ; Mon, 25 Jul 2005 08:33:43 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx2eF-0000Ny-On for sip@ietf.org; Mon, 25 Jul 2005 09:05:37 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j6PCXMF00317; Mon, 25 Jul 2005 08:33:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] History-Info vs Diversion Date: Mon, 25 Jul 2005 07:33:22 -0500 Message-ID: Thread-Topic: [Sip] History-Info vs Diversion Thread-Index: AcWQ9DhQWEM3q7GySo6zl4J0QB0rMAAIH2+w From: "Mary Barnes" To: "Juha Heinanen" , "Sigrid Thijs" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org History-Info has been approved by the IESG and is in the RFC Editor's Queue: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 10505&rfc_flag=3D0=20 Mary -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha Heinanen Sent: Monday, July 25, 2005 3:33 AM To: Sigrid Thijs Cc: sip@ietf.org Subject: [Sip] History-Info vs Diversion Sigrid Thijs writes: > I found the following documents defining these extensions: > - history-info: draft-ietf-sip-history-info-06.txt, expires July 17th, 2005 > - diversion: draft-levy-diversion-08.txt, expires February 25,2005 > What is the current status of these extensions? Is there still being=20 > worked on, are there new drafts on the way? draft-levy seems to be de-facto standard that many products have implemented, -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 11:40:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx54K-00073q-GW; Mon, 25 Jul 2005 11:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx54I-00073l-L2 for sip@megatron.ietf.org; Mon, 25 Jul 2005 11:40:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00919 for ; Mon, 25 Jul 2005 11:40:36 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5Z8-00073Q-1Y for sip@ietf.org; Mon, 25 Jul 2005 12:12:33 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2005 11:40:27 -0400 X-IronPort-AV: i="3.95,140,1120449600"; d="scan'208"; a="63803819:sNHT28590584" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6PFeQVu024370 for ; Mon, 25 Jul 2005 11:40:26 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 11:40:33 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 11:40:19 -0400 Message-ID: <42E507E3.3070704@cisco.com> Date: Mon, 25 Jul 2005 11:40:19 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2005 15:40:19.0512 (UTC) FILETIME=[29779380:01C5912F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Sip] clarifying the construction of the route header field at UA X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks, I've run into some issues recently in environments making use of the service-route header field (RFC3608). In particular, there are now many sources that can be used to construct the route header field that a UA uses in a request: * record-routes * service-route * 305 Use Proxy * configuration, either through DHCP or the config framework It was unclear how these various sources are reconciled to provide the final set, and which messages that set actually applies to (i.e., does it get used in REGISTER?). I've written up an I-D that tries to summarize the issue and proposes some clarifications: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-00.txt Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 11:53:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5Gg-0001as-1D; Mon, 25 Jul 2005 11:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5Ge-0001an-Ac for sip@megatron.ietf.org; Mon, 25 Jul 2005 11:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01958 for ; Mon, 25 Jul 2005 11:53:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5lT-0007XE-Jr for sip@ietf.org; Mon, 25 Jul 2005 12:25:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 25 Jul 2005 08:53:11 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="200400571:sNHT31404838" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6PFr8JV022743 for ; Mon, 25 Jul 2005 08:53:10 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 11:53:10 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 11:53:06 -0400 Message-ID: <42E50AE5.6020806@cisco.com> Date: Mon, 25 Jul 2005 11:53:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2005 15:53:06.0744 (UTC) FILETIME=[F2C5E380:01C59130] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Subject: [Sip] privacy in draft-ietf-sip-identity - Privacy header field ineffective X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks, Jon, Cullen and I wrote up an I-D that talks about the issues of privacy in draft-ietf-sip-identity. The draft can be found here: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt As it turns out, rfc3323 (the privacy header field), has numerous problems when applied to draft-ietf-sip-identity: Intra-Domain Privacy: Because the SIP identity mechanism relies on the domain of the From header field as a key for obtaining certificates used to validate the identity in the From header field, anonymity is restricted to being within a domain. It is no longer possible, as described in RFC 3323, to populate the From header field with "anonymous.invalid" as the domain. As a consequence, a recipient of the request will be able to determine the domain of the originator of the request, though they will not be able to determine which user within that domain sent the request. This limitation is not very troubling for domains with extremely large numbers of users. However, for small domains, such as enterprises or home networks, it can be equally revealing as the identity of the requestor themselves. Contact Privacy lost: Because the SIP identity mechanism relies on a signature over the Contact header field for referential integrity, a privacy service that provides header privacy cannot actually modify the Contact value. This will reveal the IP address of the requestor to the recipient of the request, which can often provide substantial information about the requestor. Session Privacy lost: Session privacy is accomplished through a back- to-back user agent (b2bua) that rewrites the SDP to relay session media through an intermediary. This no longer works at all with the SIP identity mechanism, as it relies on a signature over the body of the request (which contains the SDP) to provide referential integrity. Subscriber Identity Lost within Originating Domain: One of the benefits of the P-Asserted-ID header field when used in conjunction with the "id" level of privacy is that elements within the domain of the originator of the request will still be able to determine the identity of the originator. This is necessary for providing features for the requestor, accounting for their usage, and so on. With the SIP identity mechanism, if privacy is needed, the From header field contains an anonymous URI. As a result, the request has no information that can identity the user within their own domain, unless the SIP identity mechanism is used in conjunction with RFC3325, which is redundant. These problems are in addition to the problems inherent in RFC 3323 to begin with: Sensitivity to Boundary Configuration: Although RFC3323 argues strongly in favor of placing the privacy service very near the originator of the request, this goal is at odds with RFC 3325, which requires the privacy service to be on the egress edge of the trust domain. As a result, privacy is actually provided only if every egress proxy is properly configured to take positive action and remove the P-Asserted-ID header field. Because positive action from the network is required to provide privacy, this mechanism is sensitive to misconfiguration of network elements, particularly in large interconnected trust domains. Complicated Call Trace: In many networks, there is a requirement to provide a call trace feature that allows for malicious callers to be traced back to their source so that legal action can be taken. The utility of such features in a global SIP network aside, RFC 3323 makes such a feature difficult to provide since the identity of the requestor is literally removed from the request. This complicates the tracking procedures needed to identify the originator later on. Limited Flexibility The degrees of privacy that RFC 3323 could provide were coded into the tokens valid in the Privacy header field. More complicated combinations - anonymity for certain media streams but not others, for example - were not possible. The draft proposes a mechanism to fix these problems. This mechanism would allow rfc3323 to be deprecated. Comments or questions? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 14:22:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7ae-0000Wg-6l; Mon, 25 Jul 2005 14:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7ac-0000Wb-Un for sip@megatron.ietf.org; Mon, 25 Jul 2005 14:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12080 for ; Mon, 25 Jul 2005 14:22:10 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx85V-0003ha-OQ for sip@ietf.org; Mon, 25 Jul 2005 14:54:07 -0400 Received: from [192.168.2.100] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6PIQ0eF020198 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 25 Jul 2005 13:26:01 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 25 Jul 2005 13:22:17 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Orit Levin Subject: [Sip] Open questions: draft-ietf-sip-refer-with-norefersub-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jul 19, 2005, at 8:11 PM, Orit Levin wrote: > Guys, > > The submitted draft is according to my best understanding of the > agreement from the last IETF and I am not aware of any open issues > associated with it. > > That being said, in the process of writing this version, I came to > think > that having a new general "Request-Options" or "Request" header > containing any defined option tags (and being positively responded by a > Require header) would be a better approach than having a specific > Refer-Sub header sent in both directions as in the current draft. Orit has raised a what I think is a reasonable question on this draft. However, we had a strong consensus on the design team during the last meeting to proceed with the approach she has documented in the current version of the draft. It seems to me that if we are going to proceed with the refer-features model, we might wish to do norefersub using this approach. If not, then we should clearly proceed with the current consensus. So I'd like to raise two questions at this time: 1) Do we wish to proceed with a refer feature parameterization method, as in: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param -00.txt? 2) Do we wish to reopen draft-ietf-sip-refer-with-norefersub-02.txt, or submit it immediately for publication as documented according to the standing WG consensus? Thanks. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 25 14:28:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7gt-0002GD-Ke; Mon, 25 Jul 2005 14:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7gp-0002G8-Tm for sip@megatron.ietf.org; Mon, 25 Jul 2005 14:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12655 for ; Mon, 25 Jul 2005 14:28:34 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx8Bi-0003wY-Sb for sip@ietf.org; Mon, 25 Jul 2005 15:00:32 -0400 Received: from [192.168.2.100] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6PIWPYK020256 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 25 Jul 2005 13:32:26 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05c8222f9e5af23343e595171901d72a@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 25 Jul 2005 13:28:42 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] The security-flows document -- use it or lose it? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We've looked a couple of times at: http://www.ietf.org/internet-drafts/draft-jennings-sip-sec-flows-03.txt and said it was useful and needed to be done. But Cullen tells me that he's just not getting any feedback on it, and that there may not be any point in talking about it any more at SIP: So I'd like to ask the WG: 1) Do you want to see this published as a WG item and will you support this work by publicly committing the 100 or so hours needed for each of several reviewers to finalize the document? 2) Would we rather see Cullen publish this as an individual effort, and perhaps refine it successively in the future? 3) Should we give the problem up as too difficult or not interesting at this time, thank Cullen for all his hard work, and suggest he work on other more fruitful topics? Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 26 10:09:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQ7S-0007Py-94; Tue, 26 Jul 2005 10:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQ7R-0007Pt-Ct for sip@megatron.ietf.org; Tue, 26 Jul 2005 10:09:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20730 for ; Tue, 26 Jul 2005 10:09:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQcS-0005UV-Cp for sip@ietf.org; Tue, 26 Jul 2005 10:41:24 -0400 Received: from hkg-core-1.cisco.com (64.104.123.94) by sj-iport-3.cisco.com with ESMTP; 26 Jul 2005 07:08:59 -0700 X-IronPort-AV: i="3.95,143,1120460400"; d="scan'208"; a="326057897:sNHT30850036" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6QE7wOC013617 for ; Tue, 26 Jul 2005 22:09:16 +0800 (CST) Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 07:07:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] clarifying the construction of the route header field at UA Date: Tue, 26 Jul 2005 07:07:43 -0700 Message-ID: <3175C4C5F682C145B25808EB5737F16C6B6DC7@xmb-sjc-21b.amer.cisco.com> Thread-Topic: [Sip] clarifying the construction of the route header field at UA Thread-Index: AcWRL6kUT1aHTQkXT224nouLayGIRAAuEVWg From: "Kasturi Narayanan \(kasnaray\)" To: "Jonathan Rosenberg \(jdrosen\)" , "IETF SIP List" X-OriginalArrivalTime: 26 Jul 2005 14:07:43.0938 (UTC) FILETIME=[64800220:01C591EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, I have the following question/clarification. 1)In section 5.3 there is a sentence regarding 305 response handling processing. It says "This processing applies to requests both inside and outside of a dialog, and applies to all request methods, including REGISTER, with the exception of ACK and CANCEL." Need clarification.=20 How long shld a contact returned in 305 response be treated as valid. Is it temporary or shld be based on expires header. "If the above sentence meant that subsequent requests (all) shld be sent thru the contact received in 305.=20 Or Does this sentence mean that mid-call dialogs also may result in 305. Is this the case? For example a Re-Invite may result in 305? So that subsequent requests for that call are sent thru a different proxy. 2) with regard to section 5.3 (and related to section 6) for backward compatibility. UAC pre-populates Route headers A, B, C and D in the initial Invite towards UAS Proxy D decides to send a 305 with Proxy E's Contact. Proxies C,B do not handle the 305 and relay it back towards Proxy A. Then Proxy A while construction the new Request will remove the Top most route header which belongs to proxy B and replace it with the Route-header corresponding to Proxy-E and send the Request towards Proxy E. When Proxy E receives this Request it is going to POP route-header E and send it towards C which in turn is going to send it towards D. D may again send a 305 which C and E just relay it back towards A. This may need protection in the proxies or UAC to make sure which entity in the network is sending the 305 and in this case however the call is not going to succeed at all because the route-header corresponding to D is always there. So the requirement that the immediate preceding hop shld handle the 305 is almost mandatory. =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg (jdrosen) > Sent: Monday, July 25, 2005 10:40 AM > To: IETF SIP List > Subject: [Sip] clarifying the construction of the route header field at UA >=20 > Folks, >=20 > I've run into some issues recently in environments making use of the > service-route header field (RFC3608). In particular, there are now many > sources that can be used to construct the route header field that a UA > uses in a request: >=20 > * record-routes > * service-route > * 305 Use Proxy > * configuration, either through DHCP or the config framework >=20 > It was unclear how these various sources are reconciled to provide the > final set, and which messages that set actually applies to (i.e., does > it get used in REGISTER?). >=20 > I've written up an I-D that tries to summarize the issue and proposes > some clarifications: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct- > 00.txt >=20 > Comments and questions welcome. >=20 > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 26 13:21:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT73-00047k-Gr; Tue, 26 Jul 2005 13:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxT71-00047E-UQ for sip@megatron.ietf.org; Tue, 26 Jul 2005 13:21:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07567 for ; Tue, 26 Jul 2005 13:21:01 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTc7-0003os-VS for sip@ietf.org; Tue, 26 Jul 2005 13:53:12 -0400 Received: from [131.161.248.93] (open-131-161-248-93.cliq.com [131.161.248.93]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j6QHL0E15180; Tue, 26 Jul 2005 10:21:00 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 26 Jul 2005 10:21:01 -0700 To: SIP WG X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] PDF reading list available X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Folks, As usual, PDF reading lists for IETF 63 are available linked on the agenda page on softarmor: http://kevlar.softarmor.com/sipwg/meets/ietf63/agenda.html thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 26 16:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWHx-0005PN-JN; Tue, 26 Jul 2005 16:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWHv-0005PH-RV for sip@megatron.ietf.org; Tue, 26 Jul 2005 16:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22871 for ; Tue, 26 Jul 2005 16:44:29 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxWn2-0001a0-CE for sip@ietf.org; Tue, 26 Jul 2005 17:16:41 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6QKrmbi024844 for ; Tue, 26 Jul 2005 13:53:48 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6QKoi4O020268 for ; Tue, 26 Jul 2005 15:50:44 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Jul 2005 15:44:17 -0500 Message-ID: From: Baniel Uri-CUB001 To: SIP WG Date: Tue, 26 Jul 2005 15:44:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] Asking a B2BUA to add a party X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Say a UA A talks with UA B via B2BUA X. A wants to add an additional party, UA C to the call. A wants to "ask" X to initiate the addition of C to the call. I can think of INFO or NOTIFY (w/ implicit subscription) sent from A to X as the simplest way to trigger the necessary action in X. It might be even the method MESSAGE with some text which is meaningful to X... Is anyone aware of more "standardize" (but simple) way to accomplish that? In general I am asking about a SIP standardized way for a SIP element A to ask another SIP element B to perform an action, which is related to an existing dialog(s), without the need to use an additional protocol. Thx -uri (Baniel) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 26 17:22:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWsd-0007v7-Oe; Tue, 26 Jul 2005 17:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWsc-0007t6-A1 for sip@megatron.ietf.org; Tue, 26 Jul 2005 17:22:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24985 for ; Tue, 26 Jul 2005 17:22:23 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXNk-0002cy-AG for sip@ietf.org; Tue, 26 Jul 2005 17:54:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2005 14:22:17 -0700 X-IronPort-AV: i="3.95,145,1120460400"; d="scan'208"; a="651145195:sNHT30665548" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6QLMGJL006973; Tue, 26 Jul 2005 14:22:16 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:22:16 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 14:22:15 -0700 Message-Id: <4.3.2.7.2.20050726161133.03006008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Jul 2005 16:22:06 -0500 To: Baniel Uri-CUB001 , SIP WG From: "James M. Polk" Subject: Re: [Sip] Asking a B2BUA to add a party In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jul 2005 21:22:16.0054 (UTC) FILETIME=[18B13160:01C59228] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 03:44 PM 7/26/2005 -0500, Baniel Uri-CUB001 wrote: >Say a UA A talks with UA B via B2BUA X. A wants to add an additional >party, UA C to the call. >A wants to "ask" X to initiate the addition of C to the call. I can think >of INFO or NOTIFY (w/ implicit subscription) sent from A to X as the >simplest way to trigger the necessary action in X. It might be even the >method MESSAGE with some text which is meaningful to X... A sends an INV to C, sending the message at X (perhaps with a Route header of X). This might be the normal operation A, btw - based on a Service Route in the 200 OK Response to its REGISTER Request. Normally, X will forward the INV to C (being a B2BUA, this will look like X did this from C's pov). The question you have to determine is where does the RTP go? In other words, what is the 3-way bridge element for these merged streams? A? or an external element like a DSP? It isn't going to be X. If it's A, then there doesn't need to be anything special in the INV, and the SDP from A indicates A as the IP address for C's RTP stream to be set up to. If it's a DSP, B needs to be reINVITEd to this DSP too. >Is anyone aware of more "standardize" (but simple) way to accomplish that? >In general I am asking about a SIP standardized way for a SIP element A to >ask another SIP element B to perform an action, which is related to an >existing dialog(s), without the need to use an additional protocol. > >Thx >-uri (Baniel) > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 26 17:29:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWza-0001Y3-5N; Tue, 26 Jul 2005 17:29:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWzX-0001Xx-FI for sip@megatron.ietf.org; Tue, 26 Jul 2005 17:29:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25390 for ; Tue, 26 Jul 2005 17:29:33 -0400 (EDT) Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXUd-0002ph-K6 for sip@ietf.org; Tue, 26 Jul 2005 18:01:46 -0400 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 5D1A226000F; Tue, 26 Jul 2005 23:29:11 +0200 (CEST) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31184-04; Tue, 26 Jul 2005 23:29:10 +0200 (CEST) Received: from cloudcity.ohlmeier.home (e178027114.adsl.alicedsl.de [85.178.27.114]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 6358826000B; Tue, 26 Jul 2005 23:29:10 +0200 (CEST) From: Nils Ohlmeier To: sip@ietf.org Subject: Re: [Sip] The security-flows document -- use it or lose it? Date: Tue, 26 Jul 2005 23:29:08 +0200 User-Agent: KMail/1.8.1 References: <05c8222f9e5af23343e595171901d72a@softarmor.com> In-Reply-To: <05c8222f9e5af23343e595171901d72a@softarmor.com> X-Dont-Stare: at me MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507262329.09265.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, inline On Monday 25 July 2005 20:28, Dean Willis wrote: > We've looked a couple of times at: > > http://www.ietf.org/internet-drafts/draft-jennings-sip-sec-flows-03.txt > > and said it was useful and needed to be done. > > But Cullen tells me that he's just not getting any feedback on it, and > that there may not be any point in talking about it any more at SIP: > > So I'd like to ask the WG: > > > 1) Do you want to see this published as a WG item and will you support > this work by publicly committing the 100 or so hours needed for each of > several reviewers to finalize the document? Short: I (would) support it. Long: As in my opinion the whole topic of secure call flows in SIP is far less understood by the majority of the implementors as the majority might think I (would) strongly support this document. At least at the last SIPit it was very valuable. I assume the lack of feedback is caused by the fact that everybody just uses this document as a reference example to get their own implementations running. And the open questions are then direct against the documents which are defining the standards but not against this examples. > 2) Would we rather see Cullen publish this as an individual effort, and > perhaps refine it successively in the future? No. > 3) Should we give the problem up as too difficult or not interesting at > this time, thank Cullen for all his hard work, and suggest he work on > other more fruitful topics? No. Nils > > Thanks, > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 27 00:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdGA-0006xe-KQ; Wed, 27 Jul 2005 00:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdG8-0006xV-38 for sip@megatron.ietf.org; Wed, 27 Jul 2005 00:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18235 for ; Wed, 27 Jul 2005 00:11:05 -0400 (EDT) Received: from [216.29.181.162] (helo=mahatma.gandhilinux.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxdlG-0004r0-MP for sip@ietf.org; Wed, 27 Jul 2005 00:43:22 -0400 Received: (qmail 27230 invoked by uid 0); 27 Jul 2005 04:10:50 -0000 Received: from unknown (HELO ?192.168.1.7?) (dbrond@68.74.104.123) by 0 with SMTP; 27 Jul 2005 04:10:50 -0000 Message-ID: <42E707BC.6070600@brondsema.net> Date: Wed, 27 Jul 2005 00:04:12 -0400 From: Dave Brondsema User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] pgp authentication References: <42E13D86.30309@brondsema.net> In-Reply-To: <42E13D86.30309@brondsema.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 1.2 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897330414==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0897330414== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2404446EC43224373895556F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2404446EC43224373895556F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is there a better place to ask this? Dave Brondsema wrote: > > Why was pgp authentication removed in rfc3261? A note mentions "PGP > MIME" is more complete, but I can't find any other RFC with a > WWW-Authentication scheme for PGP. What is the recommended way to > implement WWW-Authentication using PGP? > > Thanks! > -- Dave Brondsema : dave@brondsema.net http://www.splike.com : programming http://www.brondsema.net : personal <>< --------------enig2404446EC43224373895556F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5we8VvBSb5uzznARAvC+AJ4+pHWbxFtYrkeW6PhOTxopOD/FegCfWGvV f1q/EmaDJ3e0lFbg7E8LoMI= =Y+3e -----END PGP SIGNATURE----- --------------enig2404446EC43224373895556F-- --===============0897330414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0897330414==-- From sip-bounces@ietf.org Wed Jul 27 01:07:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxe93-0003YS-Vl; Wed, 27 Jul 2005 01:07:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxe92-0003YN-38 for sip@megatron.ietf.org; Wed, 27 Jul 2005 01:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21320 for ; Wed, 27 Jul 2005 01:07:50 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxeeD-0006K9-C7 for sip@ietf.org; Wed, 27 Jul 2005 01:40:06 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2005 01:07:42 -0400 X-IronPort-AV: i="3.95,145,1120449600"; d="scan'208"; a="64088038:sNHT31325088" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6R57gVu018797; Wed, 27 Jul 2005 01:07:42 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 01:07:41 -0400 Received: from [192.168.1.100] ([10.86.240.226]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 01:07:41 -0400 Message-ID: <42E7169C.1030805@cisco.com> Date: Wed, 27 Jul 2005 01:07:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Baniel Uri-CUB001 Subject: Re: [Sip] Asking a B2BUA to add a party References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2005 05:07:41.0656 (UTC) FILETIME=[1DA5E580:01C59269] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org A focus is a standardized form of b2bua, and the conferencing framework provides several ways to ask the focus to add a participant. The SIP-based mechanism involves sending it a REFER. See draft-ietf-sipping-conferencing-framework and draft-ietf-sipping-cc-conferencing. This, of course, requires that the focus be visible as a focus; i.e., its not a transparent b2bua that happens to have inserted itself on the call path. In those cases, it is nonsensical IMHO to ask it to do something for you, since you dont know its there. -Jonathan R. Baniel Uri-CUB001 wrote: > Say a UA A talks with UA B via B2BUA X. A wants to add an additional party, UA C to the call. > A wants to "ask" X to initiate the addition of C to the call. I can think of INFO or NOTIFY (w/ implicit subscription) sent from A to X as the simplest way to trigger the necessary action in X. It might be even the method MESSAGE with some text which is meaningful to X... > > Is anyone aware of more "standardize" (but simple) way to accomplish that? In general I am asking about a SIP standardized way for a SIP element A to ask another SIP element B to perform an action, which is related to an existing dialog(s), without the need to use an additional protocol. > > Thx > -uri (Baniel) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 27 10:36:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn1I-0002Sc-Ng; Wed, 27 Jul 2005 10:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxn1G-0002SX-WF for sip@megatron.ietf.org; Wed, 27 Jul 2005 10:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03067 for ; Wed, 27 Jul 2005 10:36:24 -0400 (EDT) Received: from smtp.persistent.co.in ([202.54.11.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnWS-0007FC-TJ for sip@ietf.org; Wed, 27 Jul 2005 11:08:46 -0400 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/8.12.9) with ESMTP id j6REiEA6015319 for ; Wed, 27 Jul 2005 20:14:19 +0530 Received: from [10.106.5.170] ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id ADS73245 (AUTH rahul_joshi); Wed, 27 Jul 2005 20:05:44 +0530 (IST) Message-ID: <42E79C5F.5060505@persistent.co.in> Date: Wed, 27 Jul 2005 20:08:23 +0530 From: Rahul Joshi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Sip] MGCP to SIP Interworking? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is there any standard/draft for interworking between MGCP and SIP? I am specifically looking for how to map MGCP error messages e.g. NACK's to CRCX to SIP error codes. Any pointers in this regards would be help. Regards. -Rahul. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 27 10:45:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnA7-0003bY-Us; Wed, 27 Jul 2005 10:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnA5-0003bO-W2 for sip@megatron.ietf.org; Wed, 27 Jul 2005 10:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03649 for ; Wed, 27 Jul 2005 10:45:31 -0400 (EDT) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnfL-0007ZU-AC for sip@ietf.org; Wed, 27 Jul 2005 11:17:53 -0400 Received: from sonustxmail01.sonusnet.com (sonustxmail01.sonusnet.com [10.10.100.52]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j6REjCBx020011; Wed, 27 Jul 2005 10:45:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] MGCP to SIP Interworking? Date: Wed, 27 Jul 2005 09:45:12 -0500 Message-ID: <8C0CF305DEE53240BC3739EB4DC557D76B29D7@sonustxmail01.sonusnet.com> Thread-Topic: [Sip] MGCP to SIP Interworking? Thread-Index: AcWSuNpfAzJfuO1xQYusF1eHfYumSAAABT4A From: "Summers, Kevin" To: "Rahul Joshi" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Not within the IETF. The PacketCable folks may have done some work in = this area, but I don't recall ever seeing the mapping you ask about in = their specs.=20 Keep in mind there are various ways to manage a "connection" in MGCP -- = this will complicate your interworking task. =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Rahul Joshi Sent: Wednesday, July 27, 2005 9:38 AM To: sip@ietf.org Subject: [Sip] MGCP to SIP Interworking? Is there any standard/draft for interworking between MGCP and SIP? I am = specifically looking for how to map MGCP error messages e.g. NACK's to=20 CRCX to SIP error codes. Any pointers in this regards would be help. Regards. -Rahul. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 27 15:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrvD-0003WK-HR; Wed, 27 Jul 2005 15:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrvB-0003WC-7s for sip@megatron.ietf.org; Wed, 27 Jul 2005 15:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27874 for ; Wed, 27 Jul 2005 15:50:26 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxsQU-00012v-0T for sip@ietf.org; Wed, 27 Jul 2005 16:22:51 -0400 Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6RJsJXs001313 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 14:54:21 -0500 In-Reply-To: <42E707BC.6070600@brondsema.net> References: <42E13D86.30309@brondsema.net> <42E707BC.6070600@brondsema.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ac54e7042c1a8737df61654588ae8f7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] pgp authentication Date: Wed, 27 Jul 2005 14:50:33 -0500 To: Dave Brondsema X-Pgp-Agent: GPGMail 1.1 (Panther) X-Gpgmail-State: signed X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The short answer is that we removed it because it was unimplemented, incompletely specified, appeared to have no current constituency, and we didn't have time to deal with it in SIP. There's a writeup on using PEM and PGP with Apache for authentication and encryption at: http://hoohoo.ncsa.uiuc.edu/docs/PEMPGP.html that might have pointers that would help. I don't believe we actually have "a recommended way" to do www-authenticate for SIP using PGP. - -- Dean On Jul 26, 2005, at 11:04 PM, Dave Brondsema wrote: > Is there a better place to ask this? > > Dave Brondsema wrote: >> >> Why was pgp authentication removed in rfc3261? A note mentions "PGP >> MIME" is more complete, but I can't find any other RFC with a >> WWW-Authentication scheme for PGP. What is the recommended way to >> implement WWW-Authentication using PGP? >> >> Thanks! >> > > -- > Dave Brondsema : dave@brondsema.net > http://www.splike.com : programming > http://www.brondsema.net : personal > <>< > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC5+WNSE0vSqCaet8RAhyfAJ9ukryYIgV2HBr1Q8zQ9MdxNQDMfgCgkhMh 93VFjZ/NZ/rBsYluz45VHpM= =Pq/D -----END PGP SIGNATURE----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 28 05:10:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4PL-0000wA-1b; Thu, 28 Jul 2005 05:10:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4PI-0000w2-De for sip@megatron.ietf.org; Thu, 28 Jul 2005 05:10:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07840 for ; Thu, 28 Jul 2005 05:10:22 -0400 (EDT) Received: from smtpdel.hathway.com ([202.88.149.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy4uY-0005Q4-Vh for sip@ietf.org; Thu, 28 Jul 2005 05:42:53 -0400 Received: from serverfx.lei.com ([202.88.147.73]) by smtpdel.hathway.com (8.11.6/8.11.6) with ESMTP id j6S8wsj28958 for ; Thu, 28 Jul 2005 14:28:54 +0530 MIME-Version: 1.0 Date: Thu, 28 Jul 2005 14:44:29 +0530 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: RFC 791 Thread-Index: AcWTVMIaHu94Aa6WT8+eMLysC03QJg== From: "Palavesan V C. Arumugam" To: X-Spam-Score: 2.7 (++) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Subject: [Sip] RFC 791 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1524608833==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1524608833== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59354.C26B6522" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C59354.C26B6522 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI sir =20 I am new to IP networks I want some clarification in RFC 791 =20 =20 Page 18 and 19 "Loose Source and Record Route" =20 The paragraph in page 19 which states =20 "If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four" =20 I am not getting cleared with the concept of Source route and record route what does the above statement means Can someone give an insight into it with an example =20 Thanks and Regards Palavesam =20 =20 ------_=_NextPart_001_01C59354.C26B6522 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI sir

 

I am new to IP networks I want some clarification in = RFC 791

 

 

Page 18 and 19

"Loose Source and =
Record =
Route"
 
The paragraph in page 19 which =
states
 
"If the address in destination address =
field has been reached and
the pointer is not greater than the length, =
the next address in
the source route replaces the address in =
the destination address
field, and the recorded route address =
replaces the source
address just used, and pointer is increased =
by four"
 
I am not getting cleared with the concept of =
Source route and record route what does the above statement means Can =
someone give an insight into it with an =
example
 
Thanks and =
Regards
Palavesam
<=
font
size=3D2 color=3Dblack face=3D"Courier New"> 

 

------_=_NextPart_001_01C59354.C26B6522-- --===============1524608833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1524608833==-- From sip-bounces@ietf.org Thu Jul 28 06:01:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5CO-0007nT-KM; Thu, 28 Jul 2005 06:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5CM-0007mt-R2 for sip@megatron.ietf.org; Thu, 28 Jul 2005 06:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11971 for ; Thu, 28 Jul 2005 06:01:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5hj-0007IE-AN for sip@ietf.org; Thu, 28 Jul 2005 06:33:36 -0400 Received: from smtp.persistent.co.in ([202.54.11.65]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Dy591-0008Qz-6i for sip@ietf.org; Thu, 28 Jul 2005 05:57:39 -0400 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/8.12.9) with ESMTP id j6SA43A6018211 for ; Thu, 28 Jul 2005 15:34:06 +0530 Received: from persistent.co.in ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id ADT08049 (AUTH anil_jangam); Thu, 28 Jul 2005 15:25:20 +0530 (IST) Message-ID: <42E8AC28.9070605@persistent.co.in> Date: Thu, 28 Jul 2005 15:28:00 +0530 From: Anil Jangam Organization: Persistent Systems Pvt.Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rahul Joshi Subject: Re: [Sip] MGCP to SIP Interworking? References: <42E79C5F.5060505@persistent.co.in> In-Reply-To: <42E79C5F.5060505@persistent.co.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anil_jangam@persistent.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rahul Joshi wrote: > Is there any standard/draft for interworking between MGCP and SIP? I am > specifically looking for how to map MGCP error messages e.g. NACK's to > CRCX to SIP error codes. Any pointers in this regards would be help. > There is no any standard as such, which addresses the SIP-MGCP interworking. Ususally this is a function of your application (e.g. MGC/IWF) to perform the interworking. However you can think of using either: 1. Use the SIP Info method to carry the call related events. 2. Use of Invite and its responses (180 and 200) to carry the SDP and Event related data. The application of this two approaches is of course a topic for discussiion. We can get more inputs from the community. /anil. > Regards. > -Rahul. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Regards, /anil. ----------------------------------------------------------------- Anil Jangam Persistent Systems Pvt.Ltd. anil_jangam@persistent.co.in Panini, 2A, Senapati Bapat Road, tel: 91-20-2570 3764 Pune: 411 016. fax: 91-20-2567 6701 India. 91-20-2570 3701 ----------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 28 13:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyBvx-0003B0-T7; Thu, 28 Jul 2005 13:12:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyBvv-0003Av-FD for sip@megatron.ietf.org; Thu, 28 Jul 2005 13:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13608 for ; Thu, 28 Jul 2005 13:12:32 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCRP-0003tw-IE for sip@ietf.org; Thu, 28 Jul 2005 13:45:09 -0400 Received: from [192.168.2.100] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6SHGOoF008771 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 28 Jul 2005 12:16:25 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <155a3a12d83c362a87b549aeba8be9e5@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] RFC 791 Date: Thu, 28 Jul 2005 12:12:44 -0500 To: "Palavesan V C. Arumugam" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jul 28, 2005, at 4:14 AM, Palavesan V C. Arumugam wrote: > Page 18 and 19 > "Loose Source and Record Route" > =A0 > The paragraph in page 19 which states > =A0 > "If the address in destination address field has been reached and > the pointer is not greater than the length, the next address in > the source route replaces the address in the destination address > field, and the recorded route address replaces the source > address just used, and pointer is increased by four" > =A0 > I am not getting cleared with the concept of Source route and record=20= > route what does the above statement means Can someone give an insight=20= > into it with an example > =A0 > Well, either you're on the wrong list, or you're looking at the wrong=20 RFC. While RFC 791 is conceptually similar to SIP routing, it's really=20= about IP routing. That's at an entirely different ISO layer. Classically, there is two ways to do route discovery ("search" and=20 "route knowledge"), and two different ways to do additional routing=20 after that discovery has completed ("source routing" and 'route=20 knowledge"). Consider a sequence: -----E | U1---A----B----C----D----U2 where U1 wants to send a packet to U2. U1 doesn't know anything about the network except that A exists and is=20= a router, so U1 sends the packet to A. A looks at the address of the destination, and either 1) asks its=20 neighbor B, who asks E and C, and C asks D, who knows (this is=20 "search"), or 2) calculates from its knowledge of the routing fabric=20 that B is closer to U2 than is A, so S sends the packet to B, who uses=20= similar logic to forward along the chain to U2. Now, for routing subsequent transactions. Basic IP routing just=20 continues to use knowledge in the router for forwarding future packets.=20= It can do this because the routers are stateless with respect to the=20 dialog between U1 and U2 -- all the routers do is forward packets,=20 using rules and knowledge of the network topology. In the absence of=20 "record routing"(more below), stateless SIP proxies do the exact same=20 thing, but at the SIP layer ratehr than the IP layer. Some protocols, like Token-Ring and SIP, report back the sequence of=20 routers to U1, so that when U1 sends a subsequent request, that request=20= contains an explicit list of nodes to visit (in this case,=20 "A,B,C,D,U2"). SIP extends this a little bit by making it easy for nodes to "drop out"=20= of subsequent requests. In fact, "dropping out" is the default --=20 unless a node adds itself to the Record-Route list, it will get dropped=20= out. So, let's say we're using SIP and only C record routes in the above.=20 This leaves UA knowing "C,U2" and subsequent requests in the same=20 dialog do not visit A, B, E, or D. They just go from UA to C to U2. So, on to the text you're asking about -- the "length" bit is how that=20= particular protocol tracks its route list. In SIP, we generally use a=20 grammatic mechanism -- the route-set is just an ordered list of URIs. So in RFC 3261 "loose source routing", a proxy receiving a request=20 looks at the first Route entry. If the URI of that entry belongs to the proxy, the proxy pops off the entry and forwards=20 the request on towards the next entry. If the URI does NOT belong to=20 the proxy, it forwards the request with the route unmodified, unless it=20= has reason not to (local policy). There are some subtleties that apply=20= to the unfortunately not-very-clever source routing mechanism of RFC=20 2543, which we still support for backward-compatibility reasons. -- Dean= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 28 16:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEzX-00024c-C1; Thu, 28 Jul 2005 16:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEzV-00024U-3I for sip@megatron.ietf.org; Thu, 28 Jul 2005 16:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26773 for ; Thu, 28 Jul 2005 16:28:26 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyFV2-0000r0-1M for sip@ietf.org; Thu, 28 Jul 2005 17:01:04 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2005 16:28:20 -0400 X-IronPort-AV: i="3.95,150,1120449600"; d="scan'208"; a="64371927:sNHT42737112" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6SKSJk6013782; Thu, 28 Jul 2005 16:28:19 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 16:28:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Date: Thu, 28 Jul 2005 16:28:18 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C806070@xmb-rtp-211.amer.cisco.com> Thread-Topic: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Thread-Index: AcWJblDPCWbCq4aKTJmw6zhgQDHHkQKQ60Kw From: "Kevin Lingle \(klingle\)" To: X-OriginalArrivalTime: 28 Jul 2005 20:28:19.0160 (UTC) FILETIME=[E42DDD80:01C593B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , jf.mule@cablelabs.com, "Wijnen, Bert \(Bert\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hi juergen, sorry for the late reply, i was on vacation. you make good points. i am attempting to get with jean-francois mule (co-author of the I-D)=20 so we can discuss this issue. =20 kevin=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, July 15, 2005 2:52 PM To: Kevin Lingle (klingle) Cc: Romascanu, Dan (Dan); sip@ietf.org; Wijnen, Bert (Bert); jf.mule@cablelabs.com Subject: Re: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review On Fri, Jul 15, 2005 at 02:13:45PM -0400, Kevin Lingle (klingle) wrote: > A few issues were found related to the definition of the=20 > SipMethodIdentifier TC and its usage: > =20 > 1. The way it is defined the TC encourages extensibility, and this=20 > can be regarded as a good thing. In order to do this a vendor must=20 > invent some numerical assignment, which is not yet used by the=20 > standard, and the DESCRIPTION requires that this assignment "MUST=20 > ensure no collision with officially assigned method identifier values" > but says nothing about how collision can be avoided. > [klingle] one would avoid collision by checking the IANA maintained=20 > list of latest officially assigned method id > values... at least that was the intent/expectation. if that is > sufficient, can we simply add that text? I fail to see how that avoids collisions. =20 > 2. Another MIB Doctor asked 'why the method name has not been used as=20 > an index as this would be the natural naming scheme. Having to go=20 > through a lookup table (in case the SipMethodIdentifier has only local > significance) is painful and the alternative to establish another IANA > registry to number the SIP methods seems also kind of costly.'. I am=20 > not sure that a change is necessary at this stage, as nothing is=20 > broken, but as I would suggest that you provide a rationale for this=20 > design choice. > [klingle] i think this was discussed at some point in the past. > the rationale i recall had to do with the ease of=20 > integral indexing in snmp tables vs. variable-length string > indexes. keep in mind that the mib's generally a=20 > machine interface in that a NM application should be doing the GETs=20 > and then has the opportunity to present > the data in a more user-friendly fashion to a human being. so we=20 > thought the use of string methods indexing > the tables everywhere was less efficient for the agent=20 > implementations. We all know that MIBs are a machine interface. We also know that lots of people use generic MIB browsers short of a suitable machine interface. The more important point I think is that the native identification of a method is the method name. Introducing a new numeric numbering scheme plus a mapping mechanism adds complexity and increases the potential to get things wrong - I would be very careful in trading simplicity, clarity and ease of use against agent implementation efficiency gains, which clearly depend on the SNMP toolkit you use (and with many good toolkits, there hardly would be a difference). /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 09:59:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVO8-0001Ll-0K; Fri, 29 Jul 2005 09:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVO5-0001Ld-QR; Fri, 29 Jul 2005 09:58:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09934; Fri, 29 Jul 2005 09:58:55 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyVtk-0002D1-T2; Fri, 29 Jul 2005 10:31:42 -0400 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j6TDwY1l000305 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Jul 2005 08:58:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 29 Jul 2005 08:58:36 -0500 To: Simple WG , sip-implementors@cs.columbia.edu, "sip@ietf.org WG" X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] SIPIT 17 registration closes in two weeks X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIPIT 17 will take place Sep 12-16 in Stockholm, Sweden, hosted by Hotsip. Information about the event is available at sipit17.hotsip.com and www.sipit.net. Registration closes August 14 (two weeks). If you plan to attend but have not yet registered, please do so now. Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 12:29:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjV-0005XQ-CU; Fri, 29 Jul 2005 12:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjT-0005Wx-Qs for sip@megatron.ietf.org; Fri, 29 Jul 2005 12:29:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21201 for ; Fri, 29 Jul 2005 12:29:08 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYFA-0006oB-9Y for sip@ietf.org; Fri, 29 Jul 2005 13:01:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2005 09:29:01 -0700 X-IronPort-AV: i="3.95,153,1120460400"; d="scan'208"; a="327271852:sNHT28059292" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6TGT1JL012917; Fri, 29 Jul 2005 09:29:01 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 09:33:35 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 12:29:06 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWULkF9MUGBnLLNSsSEY+StDiNcow== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 29 Jul 2005 16:33:36.0839 (UTC) FILETIME=[44DFF570:01C5945B] X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Rohan Mahy Subject: [Sip] sip-connect-reuse-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm pretty sure I have said all the things below on prevision version but I'm sorry I forget the answers - might be nice if draft gave a hint to them. Should be clear that this can only be used on mutual TLS connections that are both originated from and sent to proxies with globally routable addresses that are in DNS. I'm not sure the alias tag buys much, perhaps you should just always do this. In what cases would a proxy not want to insert the alias tag? I'm not sure I see the point of the DNS verification step. It is going to be significantly harder for an attacker to prove they have possession of the private key for the domain than spoofing DNS. Agree doing both is harder than just one but not really sure I see the value. Perhaps I am missing the real purpose of the DNS verification. I also wonder about this facilitating DDOS attacks on DNS servers but given that the attacker had to do a TLS connection first I don't think this is a problem. That type of attack is going to get much more interesting if DKIM happens. Consider just a proxy making TLS connection *to* example.com. It does not make a new session for every transaction. It does this by having a chance and any time it tries to route to example.com, it looks in the cache to see if it has a connection to example.com then uses it. Yes this breaks load balancing across farms but the alternative of a connection per transaction is way worse than breaking load balancing. So if you buys this so far, why not when you receive a connection with a cert that says it is from example.com, just insert this connection into the cache - regardless of anything in the SIP messages. This has the advantage that it can all be handled at the transport layer, you don't have to do complex DNS queries to authorize it. Ignoring all that, I am worried that implementers will all just put alias in stuff they send, no reason not to. Then when receiving alias, just blindly add whatever is the advertised address with no verification. This will result in trivial highjack of whole domains and the draft needs to make it really clear how broken it will be if the verification is skipped. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 12:29:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjX-0005aP-Ve; Fri, 29 Jul 2005 12:29:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjU-0005XC-HK for sip@megatron.ietf.org; Fri, 29 Jul 2005 12:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21206 for ; Fri, 29 Jul 2005 12:29:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYFB-0006oB-RH for sip@ietf.org; Fri, 29 Jul 2005 13:01:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2005 09:29:02 -0700 X-IronPort-AV: i="3.95,153,1120460400"; d="scan'208"; a="327271854:sNHT26830280" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6TGT1JL012930; Fri, 29 Jul 2005 09:29:02 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 09:33:37 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 12:29:06 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWT1hXIkesHTnZaRJ6U9Q5RTfxcYQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 29 Jul 2005 16:33:37.0636 (UTC) FILETIME=[45599240:01C5945B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Dean Willis' Subject: [Sip] willis-sip-answeralert-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, first of all, I would like to point out the irony of you want my phone to auto answer and you will not even include your phone number in the draft. Just to prove you are too paranoid, I put my cell phone number and my email address in all my recent drafts - contrary to urban legend, it did not change my rate of spam or telemarketing in the slightest. I'd like this better if it clearly diffracted between answer and receive media and answer and send and receive. I will want different policy for the two. I would like it better if the UAS had an explicit consent mechanism to allow the UAC to do this. (ala consent framework) Seems like the alert mode could be a separate draft that might be better bundled with the loop back stuff. I think we need this auto answer stuff, we just need to figure out how to do it such that it is possible to authorize it. (and this looks like reasonable direction) I find the x and xReq a bit weird and under motivated by we need all of them but assume you will enlighten me on next rev. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 12:29:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjZ-0005bf-Mv; Fri, 29 Jul 2005 12:29:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjU-0005XD-HS for sip@megatron.ietf.org; Fri, 29 Jul 2005 12:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21204 for ; Fri, 29 Jul 2005 12:29:09 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYFB-0006oG-NA for sip@ietf.org; Fri, 29 Jul 2005 13:01:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2005 09:29:03 -0700 Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6TGT2JL012940; Fri, 29 Jul 2005 09:29:02 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 09:33:38 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 12:29:06 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWTzgJszQroUiZQQwiP6J1Qw9d7tA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 29 Jul 2005 16:33:38.0386 (UTC) FILETIME=[45CC0320:01C5945B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Sip] sip-target-dialog-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I like this and hope we can move forward with it. The lack of progress on anyone securing REFER via the current mechanism is part of what makes me believe in this. I think your security section on randomness needs a little more. 3261 only requires things to be pseudo random in that collisions are avoid. However, it allows for things to be predictable such that if I see the state of several of your request is a row, I may be able to guess the state of your random number generator and predict the next one. What we need here is not just pseudo random but crypto random. The to and from tags and probably call-id need to not be predictable. Right now, most implementations I have seen are using pseudo random (not crypto random) numbers for things like to and from tags. If they support this mechanism, then they need to start using crypto random. This may be a little hard for large GWs as they don't have many sources of randomness (such as disk drives etc) and they have to produce lots of these numbers. I think it should be possible given that they do have lots of somewhat random network events. If a UA only uses pseudo random, an attacker could send 100 calls to it, look at the to tags, guess the state of the random number generator, then try to "authorize" as the next logical call that comes to it. Anyways, I think you should add into the security section that the right things needs to be crypto random and what that means. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 12:29:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjb-0005c6-5o; Fri, 29 Jul 2005 12:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXjV-0005XO-5i for sip@megatron.ietf.org; Fri, 29 Jul 2005 12:29:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21211 for ; Fri, 29 Jul 2005 12:29:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYFC-0006oB-CY for sip@ietf.org; Fri, 29 Jul 2005 13:01:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2005 09:29:06 -0700 X-IronPort-AV: i="3.95,153,1120460400"; d="scan'208"; a="327271861:sNHT27079288" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6TGT3Is007683 for ; Fri, 29 Jul 2005 09:29:03 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 09:33:41 -0700 From: "Cullen Jennings" To: Date: Fri, 29 Jul 2005 12:29:06 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWTYHSXo6K9KFpJTGK3edNSCIwbtQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 29 Jul 2005 16:33:41.0668 (UTC) FILETIME=[47C0CE40:01C5945B] X-Spam-Score: 4.6 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] sacham-sip-media-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Few comments about this draft... I would change the feature tag from the name "privacy" to "viewers" (it could still have the values of user, organization, public). Privacy refers to another header in SIP that does not have much relation to what you are doing here and this will confuse the issue greatly and cause this to get far more security review than you wish it to get. In section 6, you argue that recording is somehow different than say coping the media onto a speaker - I don't really buy this - a caller might want a call recorded or not. The recording is associated with an endpoint. I don't buy some of the logic in here. I'm not sure I understand how the SDP is going to work without multiple rounds like preconditions work. Say and invite has an offer with nothing in SDP. Then answer wants to request that the required viewer is user. How do you do that? I think you can work this out but a bunch more is needed. Have a look at the preconditions stuff. I think you should address the problems with people just ignoring all this. Say I had a phone that allowed me to set the "I am alone" flag so that even when I was on speakerphone mode it would allow "user" level calls. I suspect I would just set it to that and leave it there. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 12:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXyO-0001ty-5W; Fri, 29 Jul 2005 12:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXyM-0001to-DR for sip@megatron.ietf.org; Fri, 29 Jul 2005 12:44:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22883 for ; Fri, 29 Jul 2005 12:44:31 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYU2-0007TY-UH for sip@ietf.org; Fri, 29 Jul 2005 13:17:20 -0400 Received: from [192.168.2.100] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6TGlIu7015855 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Jul 2005 11:47:19 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38b7da1cc2cf53161777d0600ec5172f@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 29 Jul 2005 11:43:38 -0500 To: "Cullen Jennings" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: willis-sip-answeralert-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jul 29, 2005, at 11:29 AM, Cullen Jennings wrote: > > Dean, first of all, I would like to point out the irony of you want my > phone > to auto answer and you will not even include your phone number in the > draft. > Just to prove you are too paranoid, I put my cell phone number and my > email > address in all my recent drafts - contrary to urban legend, it did not > change my rate of spam or telemarketing in the slightest. > Hey, I only put my phone in the corporate directory under duress. I couldn't change my rate of spam -- it currently approaches the link speed on my server. I'm either filtering or rejecting about 3,000 a day now. I get these HUGE sendmail log files on stuff it rejects because of spamhaus.org. Then SpamAssassin kicks in and picks out about another 500 a day. But still, 50 or 60 get through. > I'd like this better if it clearly diffracted between answer and > receive > media and answer and send and receive. I will want different policy > for the > two. > Either I don't understand the question, or it's what I had in the first rev that Paul K made me change. > I would like it better if the UAS had an explicit consent mechanism to > allow > the UAC to do this. (ala consent framework) > As opposed to "just authorization"? > Seems like the alert mode could be a separate draft that might be > better > bundled with the loop back stuff. > I suppose it could, but OMA needs something for POC last month. > I think we need this auto answer stuff, we just need to figure out how > to do > it such that it is possible to authorize it. (and this looks like > reasonable > direction) > > I find the x and xReq a bit weird and under motivated by we need all > of them > but assume you will enlighten me on next rev. > X means "I want you to use this, but if you can't, do it normally" whereas XReq says "I want you to do this so much so that if you can't or don't want to, I'd rather you rejected the call." -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 15:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyb0c-0007cX-MY; Fri, 29 Jul 2005 15:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyb0a-0007cS-Ml for sip@megatron.ietf.org; Fri, 29 Jul 2005 15:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05233 for ; Fri, 29 Jul 2005 15:59:00 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DybWG-0004AS-Pe for sip@ietf.org; Fri, 29 Jul 2005 16:31:50 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j6TJv6J19011; Fri, 29 Jul 2005 15:57:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] willis-sip-answeralert-00 Date: Fri, 29 Jul 2005 14:58:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0385938D@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] willis-sip-answeralert-00 Thread-Index: AcWT1hXIkesHTnZaRJ6U9Q5RTfxcYQAoGZcw From: "Francois Audet" To: "Cullen Jennings" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This answeralert stuff is quite useful. The document talks about it's applicability to Push-to-talk. I would also like to see a mention of it's usefulness for other features. In particular, you can use it for Intercom call features (like on any traditional PBX). Also, it would be extremely useful to allow the answer-mode to be=20 allowed in an UPDATE (and re-INVITE). That would enable many features that are available today on traditional PBXs (secretary override, and other fun stuff difficult to do today).=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 16:15:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybGX-0005CO-MQ; Fri, 29 Jul 2005 16:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybGV-0005CE-Hv for sip@megatron.ietf.org; Fri, 29 Jul 2005 16:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06488 for ; Fri, 29 Jul 2005 16:15:29 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DybmB-0004d9-LM for sip@ietf.org; Fri, 29 Jul 2005 16:48:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2005 13:15:17 -0700 X-IronPort-AV: i="3.95,154,1120460400"; d="scan'208"; a="327333717:sNHT28763068" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6TKFCul018669; Fri, 29 Jul 2005 13:15:12 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 13:19:52 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 29 Jul 2005 16:15:12 -0400 From: Cullen Jennings To: Dean Willis Message-ID: In-Reply-To: <38b7da1cc2cf53161777d0600ec5172f@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Jul 2005 20:19:53.0051 (UTC) FILETIME=[E0ED82B0:01C5947A] X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" Subject: [Sip] Re: willis-sip-answeralert-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 7/29/05 12:43 PM, "Dean Willis" wrote: >> I find the x and xReq a bit weird and under motivated by we need all >> of them >> but assume you will enlighten me on next rev. >> > > X means "I want you to use this, but if you can't, do it normally" > whereas XReq says "I want you to do this so much so that if you can't > or don't want to, I'd rather you rejected the call." Ok, makes sense when I think about it that way. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 29 16:49:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybnU-0005tS-Aj; Fri, 29 Jul 2005 16:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybnN-0005qY-VN for sip@megatron.ietf.org; Fri, 29 Jul 2005 16:49:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08467 for ; Fri, 29 Jul 2005 16:49:27 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DycJ7-0005S6-FG for sip@ietf.org; Fri, 29 Jul 2005 17:22:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2005 13:49:19 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6TKnHIs027950 for ; Fri, 29 Jul 2005 13:49:17 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 16:49:19 -0400 Received: from [192.168.1.100] ([10.86.240.212]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 16:49:19 -0400 Message-ID: <42EA964E.8070807@cisco.com> Date: Fri, 29 Jul 2005 16:49:18 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] privacy in draft-ietf-sip-identity - Privacy header field ineffective References: <42E50AE5.6020806@cisco.com> <42EA9174.10709@cisco.com> In-Reply-To: <42EA9174.10709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2005 20:49:19.0411 (UTC) FILETIME=[FDC2A830:01C5947E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael Thomas wrote: > I guess my first question would be why you'd expect -identity > to work through a b2bua in the first place. It doesn't. I'm merely pointing out that problem. It seems to me > to be *feature* that anything that changes the semantics of > the original message would break the signature. That and my > head goes in loops when say that you want source authentication > that's, well, anonymous. Not sure I follow here; I think there is a reasonable definition of an anonymous request with source authentication. > > Don't all of these problems go away if you say that the > B2BUA needs to be trusted by the originator, and that the > anonymizing service becomes the new From: address, etc? I > can't think of a case where the orignator wouldn't have to > have some trust in the anonymization service because if > nothing else it could trace your IP address back. If each b2bua rewrites the From and re-signs, we basically have a solution with equivalent security properties to P-Asserted-ID. However, in more thoroughly connected networks, those properties have significant problems as I mention in the draft. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 30 06:09:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyoHf-0003ye-Mk; Sat, 30 Jul 2005 06:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyoHd-0003yZ-Dk for sip@megatron.ietf.org; Sat, 30 Jul 2005 06:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01828 for ; Sat, 30 Jul 2005 06:09:29 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyonR-0004jD-8m for sip@ietf.org; Sat, 30 Jul 2005 06:42:26 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6UA8Ksw000083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Jul 2005 06:08:21 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j6UA8Jgj020725; Sat, 30 Jul 2005 06:08:20 -0400 Message-ID: <42EB5196.1020401@cs.columbia.edu> Date: Sat, 30 Jul 2005 06:08:22 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] sacham-sip-media-privacy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Ron Shacham X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen, thanks for the helpful comments. Some responses inline. Cullen Jennings wrote: > I would change the feature tag from the name "privacy" to "viewers" (it > could still have the values of user, organization, public). Privacy refers > to another header in SIP that does not have much relation to what you are > doing here and this will confuse the issue greatly and cause this to get far > more security review than you wish it to get. Good suggestion, although 'viewer' does imply something about video. > > In section 6, you argue that recording is somehow different than say coping > the media onto a speaker - I don't really buy this - a caller might want a > call recorded or not. The recording is associated with an endpoint. I don't > buy some of the logic in here. We were motivated by the legal distinction between real-time listening and recording. I believe many jurisdictions restrict recording in various ways (e.g., requiring mutual consent or mandating "beep" or "this call may be recorded for quality assurance" indications), while speaker phones are not subject to such restrictions. I think this makes some sense - a permanent record has different privacy implications than human overhearing. > > I'm not sure I understand how the SDP is going to work without multiple > rounds like preconditions work. Say and invite has an offer with nothing in > SDP. Then answer wants to request that the required viewer is user. How do > you do that? I think you can work this out but a bunch more is needed. Have > a look at the preconditions stuff. This definitely needs more work; we discussed preconditions internally, but didn't quite get this done in time. > > I think you should address the problems with people just ignoring all this. > Say I had a phone that allowed me to set the "I am alone" flag so that even > when I was on speakerphone mode it would allow "user" level calls. I suspect > I would just set it to that and leave it there. This indeed relies on cooperation of end users, similar to other indications such as the GEOPRIV handling indications. It makes it easy to do the right thing and, somewhat more strongly, may encourage compliance since it creates an electronic record of my wishes, rather than a "he said - she said" situation. More grist for the security considerations section... Henning > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 06:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB6h-0003cd-1d; Sun, 31 Jul 2005 06:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB6e-0003bb-Le for sip@megatron.ietf.org; Sun, 31 Jul 2005 06:31:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15665 for ; Sun, 31 Jul 2005 06:31:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBci-0004p3-B0 for sip@ietf.org; Sun, 31 Jul 2005 07:04:52 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2005 03:31:35 -0700 X-IronPort-AV: i="3.95,155,1120460400"; d="scan'208"; a="327629064:sNHT26521852" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAVZJL003316 for ; Sun, 31 Jul 2005 03:31:35 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 03:36:11 -0700 From: "Cullen Jennings" To: Date: Sun, 31 Jul 2005 12:30:48 +0200 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWVQM+uiFSRme4NQQS+0N6HliRdqA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 31 Jul 2005 10:36:11.0976 (UTC) FILETIME=[AB910C80:01C595BB] X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] tschofenig-sip-saml-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Passing assertion and artifacts optimize different things. I completely agree with the draft and we need to be able to do both. The biggest problem seem to be how to bind this to the rest of the SIP message. Let me split this into three cases 1) End to end 2) End to middle 3) middle to middle or end In case 1, end to end, one way the binding can be done using the Identity mechanism and putting the assertion or artifact in the body. The Identity provides integrity binding to these rest of the message. Case 2 is like case 1 but you might want a header like the end to middle work has defined so that all the middles do not need to read all the bodies. Case 3 seems like an age old discussion on having proxies add bodies. We have never really figured out how to solve it. At first glance it seems like just adding artifacts in headers might solve this case but it still runs into the problems with binding and understanding tampering and cut and paste. All seems hard yet many of the use cases could be solved with just case 1 or perhaps 2. Perhaps we should proceed with figuring out case 1 without yet having a solution for 3. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 06:39:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE6-0004lX-RX; Sun, 31 Jul 2005 06:39:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE3-0004kr-Gs for sip@megatron.ietf.org; Sun, 31 Jul 2005 06:39:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16228 for ; Sun, 31 Jul 2005 06:39:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBk7-00057B-4X for sip@ietf.org; Sun, 31 Jul 2005 07:12:31 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 12:39:16 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAdBDi007408 for ; Sun, 31 Jul 2005 12:39:13 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 12:39:11 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 12:39:11 +0200 Message-ID: <42EC4794.7010606@cisco.com> Date: Sat, 30 Jul 2005 23:37:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 10:39:11.0675 (UTC) FILETIME=[16ACF0B0:01C595BC] X-Spam-Score: 0.6 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-e2m-sec-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org A few comments on this. I'm not sure if these have been discussed before; sorry if they have. I'm not sure its such a good idea to reuse the 493 response code. Though it is true that the error here is that the request is undecipherable, the 493 response was defined in the context of it being undecipherable by the UAS, not an intermediate proxy. Indeed, the UAC behavior in the case where it is undecipherable for a UAS is different. There, the response body contains a public key that is supposed to be used, and the UAC re-encrypts with this public key as the only desired recipient. In the e2m case, the client keeps the original public key, but adds a new one to the set of recipients. This is a fundamentally different behavior IMHO. I'm also a bit puzzled about why a target needs to be specified for the signatures. A signed body doesn't need to be targeted for a specific proxy; any proxy can verify the signature if it likes. Perhaps I am missing something... Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 06:39:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE8-0004ly-Fw; Sun, 31 Jul 2005 06:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzBE4-0004l1-IX for sip@megatron.ietf.org; Sun, 31 Jul 2005 06:39:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16234 for ; Sun, 31 Jul 2005 06:39:21 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBk7-00057N-KY for sip@ietf.org; Sun, 31 Jul 2005 07:12:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 12:39:16 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAdDDg007414 for ; Sun, 31 Jul 2005 12:39:14 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 12:39:13 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 12:39:13 +0200 Message-ID: <42EC56DC.4090503@cisco.com> Date: Sun, 31 Jul 2005 00:43:08 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 10:39:13.0246 (UTC) FILETIME=[179CA7E0:01C595BC] X-Spam-Score: 0.7 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This draft is much improved from the previous version. Its an essential part of the SIP nat traversal story so I am glad to see that. Comments below, with big issues first. Bigger issues * I still like STUN even over TCP. It has the advantage of generating a response, and allowing the client to correlate the response to the request. See more below. * the idea of a firewall between EP and registrar is something I'd rather treat in Rohan's connect-reuse draft. Let this draft focus on the client to network connections. * I find the overview of opreations confusing; it describes many different scenarios, and gives the impression that the draft is a hodgepodge of techniques. I would prefer to cast the overview and spec overall in terms of the most genreal case - multiple edge proxies and a separate registrar - and then treat other scenarios as a simplified case. * There are definitely some terminology problems and inconsistencies around the terms connection, flow and binding. > With connection > oriented transports such as TCP or TLS, the keep alive will detect > failure after a NAT reboot. Connection oriented transport failures > are detected by having the UA periodically sends a CRLF over the > connection; if the connection has failed, a connection level error > will be reported to the UA. This is not always the case. I've run into deployments where the NATs simply dropped bindings on the floor, and then dropped any subsequent data packets without sending a reset or anything else. As such, these took a very long time to get detected as connection failures. Using a stun keepalive transaction over tcp allows these to be detected rapidly. > A CRLF can be considered the beginning > of the next message that will be sent, and therefore this approach is > backwards compatible with the core SIP specification. This is a non-issue. The client needs to know that the server is supporting this mechanism in the first place before doing anything. Its just like sigcomp; you need to know the server does it before you start. The draft proposes the stun flag for that. What you really want is something like "connection-management=stun", where you can specify different connection management techniques. You'd use that even if this was going to be over tcp. Another really important point - the presence of "connection-management=stun" or whatever in the route header field of the register also tells the proxy that the client is using the mechanisms in this spec. As such, the proxy knows that it can skip "bad things" that servers sometimes do (like be an SBC) to deal with clients behind nat. Thats another reason why you want this connection management flag there even in the tcp case. * its not clear to me that the wait time in section 4.3 provides sufficient avalanche restart protection, especially in a major case like a metropolitan power outage. You're still goint to see a huge flood of initial registrations, since the spec tells clients not to delay their initial registrations when they power up. > Any time the registrar checks if a new contact matches an > existing contact in the location database, it MUST also check and see > if both the instance-id and flow-id match. If they do not match, > then the they are not the same contact. also, need to discuss the case where the contact URI do match, but the instance-id and flow-id don't. In this case, they are NOT the same contact. >> The two algorithm for edge proxies are nearly identical with the >> exception that one integrity protects the identifier so it can not be >> tampered with. It is not clear if this integrity protection is >> needed. The WG should determine if this integrity is need or not >> then refine this specification. gruu has the same issue, and I am becoming convinced the encryption doesnt help much. Minor > capable of allowing new connections from the private address side to > the public side. It is worth noting that most UAs in the world are > deployed behind firewalls or NATs. The last sentence is true today, but who knows what the future brings. Generally, since RFC text is burned in stone, its better to avoid statements about current network deployment scenarios. > However, these systems can still form TLS > connections to a proxy or registrar such that the UA authenticates > the server certificate, and the server authenticates the UA using a > shared secret in a digest challenge. .. digest challenge over that TLS connection. > The key idea of this specification is that when a UA sends a REGISTER > request, the proxy can later use this same connection to forward any > requests that need to go to this UA. Since this spec applies to UDP also, I think you need to say here that "connection" doesnt just mean a tcp connection. Generally, the introduction seems to dance around the main point, which should be stated bluntly I think: This specification allows SIP registrations to be used to register clients behind a NAT or firewall. > flow: A Flow is a network protocol layer connection between two hosts > that is represented by the network address of both ends and the > protocol. For TCP and UDP this would include the IP addresses and > ports of both ends and the protocol (TCP or UDP). With TCP, a > flow would often have to one to one correspondence with a single > file descriptor in the operating system. > flow-id: This refers to the value of a new header parameter value for > the contact header. When UA register multiple times, each > registration gets a unique flow-id value. One would think that a flow-id identifies a flow, but based on the above definitions it doesn't. The first definition implies that a flow is identified by its 5-tuple. I think that there are really three things here. One is a "flow", which represents a logical association between a UA and a specific EP host it wishes to correspond with. A flow is identified by a flow ID. A flow manifests itself by a "connection", which is a TCP connection for TCP, and a 5-tuple for UDP. The main point is that, as clienc connections come and go, the connection IDs (the 5-tuples) change, but they are all the same flow and thus have the same flow ID. > The overall approach is fairly simple. Each UA has a unique > instance-id that stays the same for this UA even if the UA reboots or > is power cycled. reference GRUU > The overall approach is fairly simple. Each UA has a unique > instance-id that stays the same for this UA even if the UA reboots or > is power cycled. Each UA can register multiple times. Sure. But here, I think you mean it can do so multiple times against the same AOR, for the purposes of HA. > Each > registration includes the instance-id for the UA and a flow-id label > that is different for each connection. So, if I re-register on a new tcp connection (because my old one failed), this would seem to imply a new flow-id, but thats not what you want. > UAs use a keep alive mechanism to keep their flow to the proxy or > registrar alive. For TCP, TLS, and other connection oriented > protocols this is a burst containing a single CRLF. For UDP it is a > STUN request sent over the flow. I think you mean connection instead of flow as the last word here. > When a proxy goes to route a message to a UA for which it has a > binding, you have not yet defined or used the term "binding". Also in this sentence I think you are talking specifically about the registrar proxy. > The flow-id parameter is used to allow the > registrar to detect and avoid using invalid contacts when a UA > reboots, as described later in this section. reboots or reconnects since its old connection failed for some reason (like a nat reboot). > Implementors often ask why the value of the sip.instance is inside > angle brackets. This is a requirement of RFC 3840 [8] which > defines that media feature tags in SIP. Feature tags which are > strings are compared by case sensitive string comparison. To > differentiate these tags from tokens (which are not case > sensitive), case sensitive parameters such as the sip.instance > media feature tag are placed inside angle brackets. this is discussed more thoroughly in gruu now, not sure it is needed to replicate that text here > If the proxy had > multiple flows that all went to this UA, it could choose any one of > registration binding that it had for this AOR and had the same > instance-id as the selected UA. this isnt just something a proxy "could" do - its almost fundamental to the operation of this spec. The set of registrations with differing flows to the same isntance ID represent a logical bundle, of which the proxy only picks one when actually forwarding a request. > Note: The STUN mechanism is very robust and allows the detection > of a changed IP address. It may also be possible to do this with > OPTIONS messages and rport; although this approach has the > advantage of being backwards compatible, it also increases the > load on the proxy or registrar server. backwards compatibility is a red-herring; see above. OPTIONS "significantly* increases the load. > The UA MUST also add a distinct flow-id > parameter to the contact header. header field > described in RFC 3261 and RFC 3263. In particular implementers > should note that a 503 with a Retry-After is not considered a failure > to form the connection. The UA should wait the indicated amount of > time and retry the connection. these two sentences seem contradictory - its not a failure to form the connection, but you're supposed to retry the connection.. > 4.1.1 Instance-ID Selection this all belongs in gruu if needed. > User Agents that form flows with stream oriented protocols such as > TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection > to detect liveness of the flow. If when sending the CRLF, the > transport reports an error, then the connection is considered to have > failed. It is RECOMMENDED that a CRLF be sent if the flow has not > had any data sent or received in the previous 500 to 600 seconds. this time is way too long. Thing about existing IM clients like AIM. I find that AIM detects failed connections within about 30s, indicating a keepalive of around that amount of time. Remember, for the duration that a bad connection is not detected, there is a gap in availability for incoming calls. Rapid detection is essential. > User Agents that form flows with datagram oriented protocols such as > UDP SHOULD check if the URI has the "stun" tag (defined in > Section 10) and, if the tag is present, you need to specify what URI you are talking about here. > Any time a SIP message is sent and the proxy does not respond, this > is also considered a failure, the flow is closed how does one close a UDP flow? > Any time a SIP message is sent and the proxy does not respond, this > is also considered a failure, the flow is closed and the procedures > in Section 4.1 are followed to form a new flow. no - it doesnt follow the procedures in 4.1 yet. It has to figure out if it needs to wait. Generally, whenever section 4.2 concludes that a connection failed, it should refer to 4.3 for determining when to re-establish it. > however, if there > is a failure in forming this flow, the UA needs to wait a certain > amount of time before retrying to form a flow to this particular URI > in the proxy set. important to mention that this is to avoid avalanche restart > wait-time = min( 1800, (30 * (2 ^ consecutive-failures))) this formula doesn't have the base-time in it; 30s is hard-coded. > These three times SHOULD be configurable in the UA. not clear which three you mean. You should explicitly define three variables and use them in the equation above. Also, you should talk about why they would ever be changed (its based on server capacity). > o The proxy MUST NOT populate the target set with more than one > contact with the same AOR and instance-id at a time. If a request > for a particular AOR and instance-id fails with a 410 response, > the proxy SHOULD replace the failed branch with another target > with the same AOR and instance-id, but a different flow-id. you should discuss cases like sequential forking, which normally pick contacts in q-value order; it won't do that now, and would rather initially treat the ones with the same instance ID as a group and pick one of those. > Proxies MUST Record-Route so that mid dialog requests are routed over > the correct flow. just edge proxies > If a proxy or registrar receives a network error when sending a SIP > message over a particular flow, it MUST remove all the bindings that > use that flow (regardless of AOR). I thought a flow was specific to a single AOR? > Edge Proxies MUST Record-Route with the same URI that was used in the > path so that mid dialog requests still are routed over the correct > flow. The thing thats MUST strength is record-routing so that mid-dialog requests go over the same flow. You can do that without using the same URI as in the Path. > When a URI is created that refers to a SIP device that supports STUN > as described in this section, the URI parameter "stun", as defined in > Section 10 SHOULD be added to the URI. MUST I think > 9. Grammar > > This specification defines a new Contact header field parameter, > flow-id. The grammar for DIGIT and EQUAL is obtained from RFC 3261 > [3]. what about the stun parameter (prefer connection-management or something similar, per above) -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 07:32:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzC3C-0001ZA-V6; Sun, 31 Jul 2005 07:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzC3B-0001Z5-7R for sip@megatron.ietf.org; Sun, 31 Jul 2005 07:32:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18502 for ; Sun, 31 Jul 2005 07:32:12 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzCZD-00078x-A3 for sip@ietf.org; Sun, 31 Jul 2005 08:05:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 13:32:02 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VBVxDg012111 for ; Sun, 31 Jul 2005 13:31:59 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 13:31:58 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 13:31:58 +0200 Message-ID: <42ECB6AD.8050709@cisco.com> Date: Sun, 31 Jul 2005 07:31:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 11:31:58.0507 (UTC) FILETIME=[764127B0:01C595C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-refer-with-norefersub-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > The REFER specification specifies that every REFER creates an > implicit subscription between the REFER-Issuer and the REFER- > Recipient. You should add a reference to rfc3515 here. > This document defines a new SIP header field: "Refer-Sub" meaningful > within a REFER transaction only. This header field, when set to > "false", specifies that a REFER-Issuer requests that the REFER- > Recipient doesn't establish an explicit subscription and the > resultant dialog. s/explicit/implicit > This document defines a new SIP header field: "Refer-Sub". This > header field is meaningful and MAY be used with a REFER request and > the corresponding 2XX response only. This header field set to > "false" specifies that a REFER-Issuer requests that the REFER- > Recipient doesn't establish an explicit subscription and the hmm, same thing here - I wonder if perhaps you are assuming that the addition of Refer-Sub makes this an "explicit" subscription? I take "explicit" to mean, through a SUBSCRIBE. > Refer-Sub = "Refer-Sub" HCOLON refer-sub-value extension-value > refer-sub-value = "true" / "false" > extension-value = *(TEXT-UTF8char / UTF8-CONT / LWS) This grammar should follow the standards outlined in draft-ietf-sip-guidelines. The above grammar allows for the following: Refer-Sub: trueHello and I don't think you want that. I'd suggest: Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten) exten = generic-param > The "Refer-Sub" header field set to "false" MAY be used by the REFER- > Issuer only when the REFER-Issuer can be certain that the REFER > request will not be forked. the wording here doesn't provide any strength about knowing whether the request will be forked. Is it SHOULD? MUST? > "Refer-Sub" header field set to "true" in the 2xx response), an > implicit subscription is created as in default case. as in the default case > If this is not known, the other way to ensure that forking will not > > > > Levin Expires January 18, 2006 [Page 5] > > Internet-Draft SIP REFER without Subscription July 2005 > > > occur is to ensure that there are no proxies between the REFER-Issuer > and the REFER-Recipient. This could be done by sending the REFER > with a Max-Forwards: 0 header field. Any proxy receiving this > request will return a "483 Too Many Hops" response, indicating that > it is not safe to use this extension. this isn't really likely to ever work, since there are just no practical use cases these days where there are no proxies. > If the capabilities of the REFER-Recipient are not known, using the > "norefersub" tag with the Require header field is NOT RECOMMENDED. > This is due to the fact that in the event the REFER-Recipient doesn't > support the extension, in order to fallback to the normal REFER, the > REFER-Issuer will need to issue a new REFER transaction thus > resulting in additional round-trips. might be worth mentioning how the REFER-Issuer can know the capabilities. Main one is the presence of the option tag in the Supported header field of a dialog initiating request or response. Prescaps is the other. > 6. Example > > An example of REFER which suppresses the implicit subscription is > shown below: this example message shows it being sent to sip:pc-b@example.com, which is probably not a gruu. Since the draft suggests that its primarily useful in sending a request to a gruu, I suggest that the syntax follow the examples in draft-ietf-sip-gruu. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 07:51:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzCLg-0005mV-NZ; Sun, 31 Jul 2005 07:51:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzCLe-0005ly-IN for sip@megatron.ietf.org; Sun, 31 Jul 2005 07:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19227 for ; Sun, 31 Jul 2005 07:51:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzCrf-0007mK-Sw for sip@ietf.org; Sun, 31 Jul 2005 08:24:27 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 13:51:06 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VBp3Dg013819 for ; Sun, 31 Jul 2005 13:51:03 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 13:51:02 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 13:51:02 +0200 Message-ID: <42ECBB25.4070607@cisco.com> Date: Sun, 31 Jul 2005 07:51:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 11:51:02.0639 (UTC) FILETIME=[2035D7F0:01C595C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-refer-feature-param X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > SIP Working Group O. Levin > Internet-Draft Microsoft Corporation > Updates: 3515 (if approved) A. Johnston I don't think this really updates 3515, in the same way we've not characterized any of the SIP extensions as updating RFC 3261. > Target capabilities and functionality to the REFER-Recipient by > including feature tags in the Refer-To header field in a REFER > request. s/feature tags/feature parameters Some other suggestions: * I think there should be some text up front that describes the ways in which the refer-issuer knows the capabilities of the refer-target * The security considerations section talks about including only useful feature parameters in the Refer-To; I think you need to spend some more time in the body of the document describing what this means, and how you figure out what is relevant -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 09:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzDle-0000R6-Rp; Sun, 31 Jul 2005 09:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzDld-0000Qz-Cc for sip@megatron.ietf.org; Sun, 31 Jul 2005 09:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23277 for ; Sun, 31 Jul 2005 09:22:11 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzEHg-0002bL-G0 for sip@ietf.org; Sun, 31 Jul 2005 09:55:22 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 15:22:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VDLuDi022533 for ; Sun, 31 Jul 2005 15:21:59 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 15:21:56 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 15:21:53 +0200 Message-ID: <42ECD070.7080102@cisco.com> Date: Sun, 31 Jul 2005 09:21:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 13:21:53.0543 (UTC) FILETIME=[D133C970:01C595D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: sip-target-dialog-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a good point, Cullen. I'll mention it in the next revision. Thanks, Jonathan R. Cullen Jennings wrote: > I like this and hope we can move forward with it. The lack of progress on > anyone securing REFER via the current mechanism is part of what makes me > believe in this. > > I think your security section on randomness needs a little more. 3261 only > requires things to be pseudo random in that collisions are avoid. However, > it allows for things to be predictable such that if I see the state of > several of your request is a row, I may be able to guess the state of your > random number generator and predict the next one. What we need here is not > just pseudo random but crypto random. The to and from tags and probably > call-id need to not be predictable. Right now, most implementations I have > seen are using pseudo random (not crypto random) numbers for things like to > and from tags. If they support this mechanism, then they need to start using > crypto random. This may be a little hard for large GWs as they don't have > many sources of randomness (such as disk drives etc) and they have to > produce lots of these numbers. I think it should be possible given that they > do have lots of somewhat random network events. > > If a UA only uses pseudo random, an attacker could send 100 calls to it, > look at the to tags, guess the state of the random number generator, then > try to "authorize" as the next logical call that comes to it. > > Anyways, I think you should add into the security section that the right > things needs to be crypto random and what that means. > > Cullen > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 09:40:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzE3L-0004ef-N4; Sun, 31 Jul 2005 09:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzE3J-0004eU-Rd for sip@megatron.ietf.org; Sun, 31 Jul 2005 09:40:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24186 for ; Sun, 31 Jul 2005 09:40:27 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzEZO-0003Gk-3v for sip@ietf.org; Sun, 31 Jul 2005 10:13:39 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 15:40:19 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VDeGDg024279 for ; Sun, 31 Jul 2005 15:40:16 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 15:40:15 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 15:40:15 +0200 Message-ID: <42ECD4BE.7090409@cisco.com> Date: Sun, 31 Jul 2005 09:40:14 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 13:40:15.0833 (UTC) FILETIME=[6237E490:01C595D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Re: sip-target-dialog-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org One more thing actually: Cullen Jennings wrote: > I like this and hope we can move forward with it. The lack of progress on > anyone securing REFER via the current mechanism is part of what makes me > believe in this. > > I think your security section on randomness needs a little more. 3261 only > requires things to be pseudo random in that collisions are avoid. Actually, that is not true. Quoting RFC 3261: When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection That said, I added some text to target-dialog emphasizing the importance of the cryptographic randomness, not just pseudorandom identifiers. However, > it allows for things to be predictable such that if I see the state of > several of your request is a row, I may be able to guess the state of your > random number generator and predict the next one. To be clear, when sips is used you can't observe them. But if you are a user of the system you can make/receive your own calls, and observe them by being a participant. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 09:52:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzEFD-0007n3-PM; Sun, 31 Jul 2005 09:52:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzEFB-0007lo-2U for sip@megatron.ietf.org; Sun, 31 Jul 2005 09:52:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24748 for ; Sun, 31 Jul 2005 09:52:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzElD-0003kB-Du for sip@ietf.org; Sun, 31 Jul 2005 10:25:54 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 15:52:29 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VDqHDk025398; Sun, 31 Jul 2005 15:52:25 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 15:52:21 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 15:52:20 +0200 Message-ID: <42ECD793.4000808@cisco.com> Date: Sun, 31 Jul 2005 09:52:19 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elwell John Subject: Re: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt References: <50B1CBA96870A34799A506B2313F26670602E93F@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670602E93F@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 13:52:20.0781 (UTC) FILETIME=[12522DD0:01C595D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the comments, John. Responses inline. Elwell John wrote: > Jonathan, > > Minor comments: > > 1. Section 3, item 2, "The user agent client believes that the request will > not be authorized by the user agent server unless the user agent client can > prove that it is aware of the dialog identifiers for some other dialog. > Call this dialog the target dialog." > > Should we change "will not" to "might not"? Even if the UAC does not know > for certain, use of target-dialog should be applicable. OK, changed. > > 2. Section 3, examples of use cases in which conditions are not met. There > seems to be a cut-and-paste error in the second bullet - the dialog package > does not show key presses. oops, fixed. > > 3. Typo "speific" after last bullet. > fixed. > 4. Section 4, penultimate paragraph: "and thus the authorization strength is > reduced to MAY". It is the strength of the requirement for authorization, > not the authorization strength, that is reduced. I would propose to say > instead "and thus authorization is optional". fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 11:10:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzFSU-0005wH-Rw; Sun, 31 Jul 2005 11:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzFST-0005w5-3m for sip@megatron.ietf.org; Sun, 31 Jul 2005 11:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00934 for ; Sun, 31 Jul 2005 11:10:30 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzFyU-0007Gh-Ac for sip@ietf.org; Sun, 31 Jul 2005 11:43:43 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAK9u014511; Mon, 1 Aug 2005 00:10:20 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAJLf009933; Mon, 1 Aug 2005 00:10:19 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAJpd009926; Mon, 1 Aug 2005 00:10:19 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAI7u009533; Mon, 1 Aug 2005 00:10:18 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAIgB009527; Mon, 1 Aug 2005 00:10:18 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAItf027430; Mon, 1 Aug 2005 00:10:18 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAH6H026049; Mon, 1 Aug 2005 00:10:17 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VFAHSk026046; Mon, 1 Aug 2005 00:10:17 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id AAA13127; Mon, 1 Aug 2005 00:10:15 +0900 (JST) From: Kumiko Ono To: "MARJOU Xavier RD-MAPS-LAN" , sip@ietf.org Date: Sun, 31 Jul 2005 11:10:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 4.14 (WinNT,501) In-Reply-To: References: Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: tachimoto.shinya@lab.ntt.co.jp Subject: [Sip] Re: Comments on draft-ietf-sip-e2m-sec-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Thank you for your close reading. Please see my comments inline. I'll fix the typos you pointed out in the next version. At 02:40 2005/07/26, "MARJOU Xavier RD-MAPS-LAN" wrote: >Hi, > >Here are some comments about your draft, which I find very good. > >Best Regards, >Xavier Marjou > > >Section 2.1: >- typo: replaces "if a UAC send" by "if a UAC sends" > >Section 2.1 >- is there a link to CEK and KEK mecanisms, explaining more in details >how it works? (I think the level in the draft is ok, but refering to >another document would help implementors) The reference, RFC2630, for S/MIME CMS EnvelopedData which covers CEK and KEK mechanisms has already included in the draft. >Section 2.2 >-typo: replace "a UA SHOULD generate either S/MIME CMS SignedData" by "a >UA SHOULD generate S/MIME CMS SignedData" >- in the next sentence, why mentioning "SIP Identity header", which >looks more related to "authentication" rather than to "data integrity". >If "authentication" topic is needed, why not modifying the Introduction >and add a 2.3 section? The SIP Identity mechanism provides the data integrity of the message body in addition to the authentication. I mentioned the SIP identity mechanism as one of mechanisms for data integrity. >Section 3 >- typo: replace "A UA needs a way to indicate content that it expects to >be viewed by a proxy server" > by "A UA needs a way to indicate that it expects the >content to be viewed by a proxy server". >- in this sentence, I would prefer "allows" rather than "expects", >because I would prefer "Proxy-Allow-Body" instead of >"Proxy-Required-Body". This would be in line with the text page 12 "it >allows a proxy server to view the SDP". I believe that the naming depends who has the initiative to request the use of the body. Although there is no way for a UA to confirm the proxy's compliance, from the SIP perspective, the initiaitve should reside on endpoints. Therefore, I believe, "Proxy-Required-Body" is prefered. This comment addresses a core issue of this mechanism. For e2m to function properly, end and middle both have to comply its execution. The "Proxy-Required" header was considered as one of the way to accomplish this, but it is only effective for the first proxy server. It can not be used for non-adjacent proxy server. I could think of proxy adding confirmation flag indicating its complicance. >Section 4 >- How can the Content-Type be in the Warning header if the Content-Type >is in the encrypted data, which can not be decrypted by Proxy. (cf also >example of page 12) This is used for a proxy to express what is desired to inspect in the decrypted data. >Section 3, 4 and 5 >- Personally, there are a lot of SHOULD in the documents. I prefer MUST >and MUST NOT, otherwise this leads to a lot of interop problems between >equipments. But I agree I can not discuss on them, as I do not know the >discussions which have leaded to these SHOULDs ;-) Could you be more specific? >Section 5.3 >- "If a proxy does not support this mecanism... The proxy MUST ignore >the herder and operate as usual" : A action is "required" to the proxy >(as suggested by the name of Proxy-Required-Body), and if the proxy can >not do it, this is ignored !? ;-). This would suggest again to rename >the header in Proxy-Allowed-Body I will delete this text, because it is redundant to the statement in RFC3261 which defines a proxy server to ignore unsupported headers. >- I have a very stupid question: if a UAC sends a SIP MESSAGE with >envelop with message1 for a UAS and another envelop with message2 for >its "allowed" proxy. Message2 could be a fake message for the proxy >logs, whereas message1 will not be logged. I have the impression that in >this case, the proxy can not respond a 493 undecipherable response. >Perhaps that another negative response is possible in case the proxy >would like to see decrypt. This could happen. But a proxy could enforce disclosure of the whole body in order to avoid such situation. I'll add some text to describe how this can be accomlished as follows: "If the proxy server reuqires disclosre of the whole body, the Warning header is not included." >Section 6 >- if there is SDP in an ACK message, why not require Proxy-Required-Body >on this request too? I'll fix this for ACK and PRACK. >Section 7.1 >- maybe remove the parameter "received" in 493 of MESSAGE, as it does >not help for the topic of this draft. > >Section 7.1 and 7.2 >- maybe remove Date header in examples, as it is not in relation with >this draft >- what is the CEKReference The CEKReference is used for the CEK reuse mechanism that I mentioned in Section 5.1. >Section 9 >- where does the header Content-ID come from? RFC2045. I'll add this in the references. -- Kumiko Ono _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 16:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzKrW-0006Ye-JH; Sun, 31 Jul 2005 16:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzKrV-0006XP-1G for sip@megatron.ietf.org; Sun, 31 Jul 2005 16:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18230 for ; Sun, 31 Jul 2005 16:56:42 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzLNe-0007Xx-3V for sip@ietf.org; Sun, 31 Jul 2005 17:29:58 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2005 13:56:36 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="201767881:sNHT28627788" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6VKuX6p022057 for ; Sun, 31 Jul 2005 13:56:33 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 13:56:33 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 13:56:32 -0700 Message-Id: <4.3.2.7.2.20050731151318.031d3918@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 31 Jul 2005 15:56:30 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jul 2005 20:56:32.0850 (UTC) FILETIME=[54EFB320:01C59612] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Sip] draft-cao-sip-response-auth-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Interesting idea, and I have a few comments: section 3.1 needs to number the requirements for clarity sake section 3.1 seems to be saying that the UAC shouldn't trust the UAS (it just contacted with a Request message, BTW) until the UAC has confirmed the UAS is really the UAS it contacted. Kinda a "before we can speak, I need to know you are you who you say you are without you speaking (because that would be an unchecked reply)." seems like a bit of catch-22, or am I missing something? In the example in section 3.1, why should Alice trust Proxy2? She has zero prior association with that proxy because all communication to Bob has gone through Proxy1, has it not? From how you've written this, if there are 10 proxies between proxy1 and proxy2, only proxy2 will send this responder verification 183 message, right? Wanting to know if Alice is going to receive a 183 per SIP hop her Request traverses? The 183 mentioned in secgtion 3.1 is absent from the flow example in section 3.2. Why? The flow on page 7 should be labeled. But, within that flow, say there are 10 SIP Hops between proxy1 and proxy2, is this ID suggesting there needs to be a SUB/NOT exchange between proxy1 and proxy2 anyway? If so, how would proxy1 learn about proxy2? What if there were/is a B2BUA in between proxy1 and proxy2? This example message flow needs to address a more complex scenario or two to learn how this proposal reacts. May I suggest both: alice <=> proxy1 <=> proxy3 <=> proxy4 <=> proxy2 <=> Bob and alice <=> proxy1 <=> proxy3 <=> b2bua1 <=> proxy4 <=> proxy2 <=> Bob to tease this proposal out? The 3rd paragraph talks about a 180 being the first time Biloxi Proxy needs to do "real" work, and this 180 was left out of the section 3.2 example. Why? Last paragraph on page 8 "UAC may receive the response code 431 Failed Responder Identity. UAC should choose to avoid the verification of the responder identity. UAC should treat it as a failure and may terminate the dialog." How is this done? With a normal ACK then a BYE? Wouldn't this give more information to this bad-guy proxy? section 6.1 - the Responder header is to give the first hop proxy (in the response direction) the address of the responder, just like the To: field? Is this level of redundancy necessary since Bob MUST have a shared secret between his UA and the Biloxi proxy2 server (as stated previously)? The Security Considerations section reads like a summary section advocating the doc, rather than a "if implemented badly, these are the bad results" type of text. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 17:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLh9-0008RL-IG; Sun, 31 Jul 2005 17:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLh7-0008RF-P8 for sip@megatron.ietf.org; Sun, 31 Jul 2005 17:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20039 for ; Sun, 31 Jul 2005 17:50:02 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzMDE-0001Xs-U9 for sip@ietf.org; Sun, 31 Jul 2005 18:23:19 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnxCk016840; Mon, 1 Aug 2005 06:49:59 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnx2q024316; Mon, 1 Aug 2005 06:49:59 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnwFm024306; Mon, 1 Aug 2005 06:49:58 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnwGF029491; Mon, 1 Aug 2005 06:49:58 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnwAc029488; Mon, 1 Aug 2005 06:49:58 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnvD6029329; Mon, 1 Aug 2005 06:49:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnv5V004655; Mon, 1 Aug 2005 06:49:57 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6VLnu8f004652; Mon, 1 Aug 2005 06:49:56 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id GAA08693; Mon, 1 Aug 2005 06:49:45 +0900 (JST) From: Kumiko Ono To: Jonathan Rosenberg , IETF SIP List Subject: Re: [Sip] comments on draft-ietf-sip-e2m-sec-00 Date: Sun, 31 Jul 2005 17:49:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 4.14 (WinNT,501) In-Reply-To: <42EC4794.7010606@cisco.com> References: <42EC4794.7010606@cisco.com> Message-Id: <14C59619BA3F07ono.kumiko@lab.ntt.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Thank you for the comments. See inline. At 22:37 2005/07/30, Jonathan Rosenberg wrote: >I'm not sure its such a good idea to reuse the 493 response code. Though >it is true that the error here is that the request is undecipherable, >the 493 response was defined in the context of it being undecipherable >by the UAS, not an intermediate proxy. Indeed, the UAC behavior in the >case where it is undecipherable for a UAS is different. There, the >response body contains a public key that is supposed to be used, and the >UAC re-encrypts with this public key as the only desired recipient. In >the e2m case, the client keeps the original public key, but adds a new >one to the set of recipients. This is a fundamentally different behavior >IMHO. I agree. As you pointed out, the UAC is expected to react differently when receiving the 493 response code from the proxy. In addition, the error response doesn't include who the sender is, so there is no way for the UAC to know whether it's the UAS or the proxy server. For the UAC to behave properly, we need a new error code (496 Proxy Undecipherable). >I'm also a bit puzzled about why a target needs to be specified for the >signatures. A signed body doesn't need to be targeted for a specific >proxy; any proxy can verify the signature if it likes. Perhaps I am >missing something... A motivation for this was the validation service at a specific proxy invocated by a UA, although any proxy on the signaling path can verify the signature. If there is no compelling usecase, we could drop this mechanism to simplify the mechanism. Thanks, Kumiko Ono _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 31 19:12:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzMzI-0007pC-4j; Sun, 31 Jul 2005 19:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzMzE-0007nv-S6 for sip@megatron.ietf.org; Sun, 31 Jul 2005 19:12:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24470 for ; Sun, 31 Jul 2005 19:12:49 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzNVO-0005JC-Js for sip@ietf.org; Sun, 31 Jul 2005 19:46:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2005 16:12:43 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="327708800:sNHT34137308" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6VNCgJL008247; Sun, 31 Jul 2005 16:12:42 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 16:17:17 -0700 From: "Cullen Jennings" To: "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] comments on draft-ietf-sip-outbound Date: Mon, 1 Aug 2005 01:12:48 +0200 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWVvKl/g/P8AUvdQdWLbFGVuF/mAwAXxEwA In-Reply-To: <42EC56DC.4090503@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 31 Jul 2005 23:17:19.0328 (UTC) FILETIME=[FF6DF600:01C59625] X-Spam-Score: 1.1 (+) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Many thanks for the comments - this I agree with you on this stuff. Will bring up the major items as slides for tomorrow. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Sunday, July 31, 2005 6:43 AM > To: IETF SIP List > Subject: [Sip] comments on draft-ietf-sip-outbound > > This draft is much improved from the previous version. Its an > essential > part of the SIP nat traversal story so I am glad to see that. > Comments > below, with big issues first. > > > Bigger issues > > * I still like STUN even over TCP. It has the advantage of > generating a > response, and allowing the client to correlate the response to the > request. See more below. I had a long discussion with several TCP experts today and now fully understand what is going on here. I agree and will recommend to the group that we switch to STUN over TCP. > > * the idea of a firewall between EP and registrar is something I'd > rather treat in Rohan's connect-reuse draft. Let this draft > focus on the > client to network connections. The case Dean wanted addressed was actually a NAT between the two proxies. Dean, are you ok with just having Rohan's draft address this? > > * I find the overview of opreations confusing; it describes many > different scenarios, and gives the impression that the draft is a > hodgepodge of techniques. I would prefer to cast the overview > and spec > overall in terms of the most genreal case - multiple edge > proxies and a > separate registrar - and then treat other scenarios as a > simplified case. I'm trying to balance this off against most implementers, and I suspect a large percentage of the WG is not familuar with the term edge proxy. But agree with general comment and will try to refine this. > > * There are definitely some terminology problems and inconsistencies > around the terms connection, flow and binding. Agreed - need to fix. May ask you for a detail NITS review some time after IETF. > > > With connection > > oriented transports such as TCP or TLS, the keep alive > will detect > > failure after a NAT reboot. Connection oriented > transport failures > > are detected by having the UA periodically sends a CRLF over the > > connection; if the connection has failed, a connection > level error > > will be reported to the UA. > > This is not always the case. I've run into deployments where the NATs > simply dropped bindings on the floor, and then dropped any subsequent > data packets without sending a reset or anything else. As such, these > took a very long time to get detected as connection failures. Using a > stun keepalive transaction over tcp allows these to be > detected rapidly. > > > A CRLF can be considered the beginning > > of the next message that will be sent, and therefore > this approach is > > backwards compatible with the core SIP specification. > > This is a non-issue. The client needs to know that the server is > supporting this mechanism in the first place before doing > anything. Its > just like sigcomp; you need to know the server does it before > you start. > The draft proposes the stun flag for that. What you really want is > something like "connection-management=stun", where you can specify > different connection management techniques. You'd use that > even if this > was going to be over tcp. yes, will switch to STUN over TCP, sorry it took me so long to understand why this was critical. I will do my best to explain to rest of WG why this change is needed. > > Another really important point - the presence of > "connection-management=stun" or whatever in the route header field of > the register also tells the proxy that the client is using the > mechanisms in this spec. As such, the proxy knows that it can > skip "bad > things" that servers sometimes do (like be an SBC) to deal > with clients > behind nat. Thats another reason why you want this connection > management > flag there even in the tcp case. > > * its not clear to me that the wait time in section 4.3 provides > sufficient avalanche restart protection, especially in a > major case like > a metropolitan power outage. You're still goint to see a huge > flood of > initial registrations, since the spec tells clients not to > delay their > initial registrations when they power up. Cleary deployments may want to change these. I will try and put some text to motivate these numbers. The number came very roughly from estimate of if load caused by registration is same as invite (huge approximation) and average non presence client does say peak hour calls of 2 bhca, then proxy farm cpu to support 2 calls per hour per client. This would imply that it had cpu power to do 2 registrations per hour per client implying that when the clients were attempting to register at steady rate or 2 per hour (or 30 minutes) they would all register. > > > Any time the registrar checks if a new contact matches an > > existing contact in the location database, it MUST also > check and see > > if both the instance-id and flow-id match. If they do not match, > > then the they are not the same contact. > > also, need to discuss the case where the contact URI do > match, but the > instance-id and flow-id don't. In this case, they are NOT the > same contact. Hmm, meant to have that - will fix > > >> The two algorithm for edge proxies are nearly identical with the > >> exception that one integrity protects the identifier so > it can not be > >> tampered with. It is not clear if this integrity protection is > >> needed. The WG should determine if this integrity is > need or not > >> then refine this specification. > > gruu has the same issue, and I am becoming convinced the encryption > doesnt help much. > > hash may be more appropriate than encryption but unless you are doing all the edge proxy to reg either inside a walled garden, or over sips, it seems like you need the integrity protection or an attacker can hijack calls. > > > Minor Did not comment but agree with most this - > > > capable of allowing new connections from the private address side to > > the public side. It is worth noting that most UAs in > the world are > > deployed behind firewalls or NATs. > > The last sentence is true today, but who knows what the > future brings. > Generally, since RFC text is burned in stone, its better to avoid > statements about current network deployment scenarios. will remove > > > However, these systems can still form TLS > > connections to a proxy or registrar such that the UA > authenticates > > the server certificate, and the server authenticates the > UA using a > > shared secret in a digest challenge. > > .. digest challenge over that TLS connection. > > > The key idea of this specification is that when a UA sends > a REGISTER > > request, the proxy can later use this same connection to > forward any > > requests that need to go to this UA. > > Since this spec applies to UDP also, I think you need to say > here that > "connection" doesnt just mean a tcp connection. will try to fix - I strugled many place with the words to describe what is basically connected UDP. > > > Generally, the introduction seems to dance around the main > point, which > should be stated bluntly I think: This specification allows SIP > registrations to be used to register clients behind a NAT or firewall. > > > flow: A Flow is a network protocol layer connection between > two hosts > > that is represented by the network address of both > ends and the > > protocol. For TCP and UDP this would include the IP > addresses and > > ports of both ends and the protocol (TCP or UDP). With TCP, a > > flow would often have to one to one correspondence > with a single > > file descriptor in the operating system. > > flow-id: This refers to the value of a new header > parameter value for > > the contact header. When UA register multiple times, each > > registration gets a unique flow-id value. > > One would think that a flow-id identifies a flow, but based > on the above > definitions it doesn't. The first definition implies that a flow is > identified by its 5-tuple. > > I think that there are really three things here. One is a > "flow", which > represents a logical association between a UA and a specific > EP host it > wishes to correspond with. A flow is identified by a flow ID. A flow > manifests itself by a "connection", which is a TCP connection > for TCP, > and a 5-tuple for UDP. The main point is that, as clienc connections > come and go, the connection IDs (the 5-tuples) change, but > they are all > the same flow and thus have the same flow ID. will try to fix up > > > The overall approach is fairly simple. Each UA has a unique > > instance-id that stays the same for this UA even if the > UA reboots or > > is power cycled. > > reference GRUU > > > The overall approach is fairly simple. Each UA has a unique > > instance-id that stays the same for this UA even if the > UA reboots or > > is power cycled. Each UA can register multiple times. > > Sure. But here, I think you mean it can do so multiple times > against the > same AOR, for the purposes of HA. > > > Each > > registration includes the instance-id for the UA and a > flow-id label > > that is different for each connection. > > So, if I re-register on a new tcp connection (because my old one > failed), this would seem to imply a new flow-id, but thats > not what you > want. > > > UAs use a keep alive mechanism to keep their flow to the proxy or > > registrar alive. For TCP, TLS, and other connection oriented > > protocols this is a burst containing a single CRLF. For > UDP it is a > > STUN request sent over the flow. > > I think you mean connection instead of flow as the last word here. > > > When a proxy goes to route a message to a UA for which it has a > > binding, > > you have not yet defined or used the term "binding". Also in this > sentence I think you are talking specifically about the > registrar proxy. > > > The flow-id parameter is used to allow the > > registrar to detect and avoid using invalid contacts when a UA > > reboots, as described later in this section. > > reboots or reconnects since its old connection failed for some reason > (like a nat reboot). > > > Implementors often ask why the value of the sip.instance is inside > > angle brackets. This is a requirement of RFC 3840 [8] which > > defines that media feature tags in SIP. Feature tags > which are > > strings are compared by case sensitive string comparison. To > > differentiate these tags from tokens (which are not case > > sensitive), case sensitive parameters such as the sip.instance > > media feature tag are placed inside angle brackets. > > this is discussed more thoroughly in gruu now, not sure it is > needed to > replicate that text here > > > If the proxy had > > multiple flows that all went to this UA, it could choose > any one of > > registration binding that it had for this AOR and had the same > > instance-id as the selected UA. > > this isnt just something a proxy "could" do - its almost > fundamental to > the operation of this spec. The set of registrations with differing > flows to the same isntance ID represent a logical bundle, of > which the > proxy only picks one when actually forwarding a request. > > > > Note: The STUN mechanism is very robust and allows the detection > > of a changed IP address. It may also be possible to > do this with > > OPTIONS messages and rport; although this approach has the > > advantage of being backwards compatible, it also increases the > > load on the proxy or registrar server. > > backwards compatibility is a red-herring; see above. > > OPTIONS "significantly* increases the load. > > > The UA MUST also add a distinct flow-id > > parameter to the contact header. > > header field > > > described in RFC 3261 and RFC 3263. In particular implementers > > should note that a 503 with a Retry-After is not > considered a failure > > to form the connection. The UA should wait the > indicated amount of > > time and retry the connection. > > these two sentences seem contradictory - its not a failure to > form the > connection, but you're supposed to retry the connection.. > > > 4.1.1 Instance-ID Selection > > this all belongs in gruu if needed. > > > User Agents that form flows with stream oriented protocols such as > > TCP, TLS, or SCTP SHOULD periodically send a CRLF over > the connection > > to detect liveness of the flow. If when sending the CRLF, the > > transport reports an error, then the connection is > considered to have > > failed. It is RECOMMENDED that a CRLF be sent if the > flow has not > > had any data sent or received in the previous 500 to 600 seconds. > > this time is way too long. Thing about existing IM clients > like AIM. I > find that AIM detects failed connections within about 30s, > indicating a > keepalive of around that amount of time. Remember, for the > duration that > a bad connection is not detected, there is a gap in availability for > incoming calls. Rapid detection is essential. > > > > User Agents that form flows with datagram oriented protocols such as > > UDP SHOULD check if the URI has the "stun" tag (defined in > > Section 10) and, if the tag is present, > > you need to specify what URI you are talking about here. > > > Any time a SIP message is sent and the proxy does not respond, this > > is also considered a failure, the flow is closed > > how does one close a UDP flow? > > > Any time a SIP message is sent and the proxy does not respond, this > > is also considered a failure, the flow is closed and the > procedures > > in Section 4.1 are followed to form a new flow. > > no - it doesnt follow the procedures in 4.1 yet. It has to > figure out if > it needs to wait. Generally, whenever section 4.2 concludes that a > connection failed, it should refer to 4.3 for determining when to > re-establish it. > > > however, if there > > is a failure in forming this flow, the UA needs to wait a certain > > amount of time before retrying to form a flow to this > particular URI > > in the proxy set. > > important to mention that this is to avoid avalanche restart > > > wait-time = min( 1800, (30 * (2 ^ consecutive-failures))) will fix > > this formula doesn't have the base-time in it; 30s is hard-coded. > > > These three times SHOULD be configurable in the UA. > > not clear which three you mean. You should explicitly define three > variables and use them in the equation above. Also, you should talk > about why they would ever be changed (its based on server capacity). > > > o The proxy MUST NOT populate the target set with more than one > > contact with the same AOR and instance-id at a time. > If a request > > for a particular AOR and instance-id fails with a 410 > response, > > the proxy SHOULD replace the failed branch with another target > > with the same AOR and instance-id, but a different flow-id. > > > you should discuss cases like sequential forking, which normally pick > contacts in q-value order; it won't do that now, and would rather > initially treat the ones with the same instance ID as a group > and pick > one of those. > > > > Proxies MUST Record-Route so that mid dialog requests are > routed over > > the correct flow. > > just edge proxies > > > If a proxy or registrar receives a network error when sending a SIP > > message over a particular flow, it MUST remove all the > bindings that > > use that flow (regardless of AOR). > > I thought a flow was specific to a single AOR? > > > Edge Proxies MUST Record-Route with the same URI that was > used in the > > path so that mid dialog requests still are routed over > the correct > > flow. > > The thing thats MUST strength is record-routing so that mid-dialog > requests go over the same flow. You can do that without using > the same > URI as in the Path. > > > When a URI is created that refers to a SIP device that supports STUN > > as described in this section, the URI parameter "stun", > as defined in > > Section 10 SHOULD be added to the URI. > > MUST I think > > > 9. Grammar > > > > This specification defines a new Contact header field parameter, > > flow-id. The grammar for DIGIT and EQUAL is obtained > from RFC 3261 > > [3]. > > what about the stun parameter (prefer connection-management > or something > similar, per above) > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip