From internet-drafts@ietf.org Sun Sep 4 18:32:20 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37E21F8745; Sun, 4 Sep 2011 18:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wORdcpSnvwX; Sun, 4 Sep 2011 18:32:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230EE21F85B1; Sun, 4 Sep 2011 18:32:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110905013220.23780.69871.idtracker@ietfa.amsl.com> Date: Sun, 04 Sep 2011 18:32:20 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-location-conveyance-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 01:32:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : James Polk Brian Rosen Jon Peterson Filename : draft-ietf-sipcore-location-conveyance-09.txt Pages : 32 Date : 2011-09-04 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-= 09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-0= 9.txt From ivo.sedlacek@ericsson.com Thu Sep 8 03:13:37 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A74B21F8AFA for ; Thu, 8 Sep 2011 03:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0Bd3UcJBgFE for ; Thu, 8 Sep 2011 03:13:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D183D21F8ACC for ; Thu, 8 Sep 2011 03:13:35 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c3-4e6895beee7c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.F2.20773.EB5986E4; Thu, 8 Sep 2011 12:15:26 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.84]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Sep 2011 12:15:26 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Date: Thu, 8 Sep 2011 12:15:25 +0200 Thread-Topic: RFC5626, reg-id usage after power up Thread-Index: AcxuEDm6DNuEMNa4TzWBNAbvd+ob+g== Message-ID: <3A324A65CCACC64289667DFAC0B88E120CD4F05D55@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E120CD4F05D55ESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] RFC5626, reg-id usage after power up X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 10:13:37 -0000 --_000_3A324A65CCACC64289667DFAC0B88E120CD4F05D55ESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can anyone please help me with the following RFC5626 related question? Suppose a UA registers with registrar over two flows. A Contact with featur= e tag X is registered over one flow and a Contact with feature tag Y is reg= istered over other flow. Whenever the UA registers the Contact with the feature tag X, the reg-id=3D= 987 is used. Whenever the UA registers the Contact with the feature tag Y, the reg-id=3D= 654 is used. When the UA is powered up for the first time, the UA uses reg-id=3D987 when= registering over the first flow and uses reg-id=3D654 when registering ove= r the second flow later on. Then the UA is switched off. When the UA is powered up again: A) must the UA use reg-id=3D987 when registering over the first flow and= reg-id=3D654 when registering over the second flow later on? or B) can the UA use reg-id=3D654 when registering over the first flow and= reg-id=3D987 when registering over the second flow later on? RFC5626, section 4.2.1 talks about "the same sequence of reg-id values", bu= t it is a little unclear. ---- 4.2.1. Initial Registrations ... A UAC conforming to this specification MUST include in the Contact header field, a "reg-id" parameter that is distinct from other "reg-id" parameters used in other registrations that use the same "+sip.instance" Contact header field parameter and AOR. Each one of these registrations will form a new flow from the UA to the proxy. >>> The sequence of reg-id values does not have to be sequential but MUST be exactly the same sequence of reg-id values each time the UA instance power cycles or reboots, so that the reg-id values will collide with the previously used reg-id values. <<< This is so the registrar can replace the older registrations. ... ---- Thanks for clarification. Kind regards Ivo Sedlacek --_000_3A324A65CCACC64289667DFAC0B88E120CD4F05D55ESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
can anyone please help me with the followi= ng=20 RFC5626 related question?
 
Suppose a UA registers with registrar over= two=20 flows. A Contact with feature tag X is registered over one flow and a Conta= ct=20 with feature tag Y is registered over other flow.
Whenever the UA regist= ers=20 the Contact with the feature tag X, the reg-id=3D987 is used.
Whenever t= he UA=20 registers the Contact with the feature tag Y, the reg-id=3D654 is=20 used.
 
When the UA is powered up for the fi= rst time,=20 the UA uses reg-id=3D987 when registering over the first flow and uses reg-= id=3D654=20 when registering over the second flow later on.
Then the UA is switched= =20 off.
When the UA is powered up again:
A)    must the U= A use=20 reg-id=3D987 when registering over the first flow and reg-id=3D654 when reg= istering=20 over the second flow later on?
or
B)    can  the = UA=20 use reg-id=3D654 when registering over the first flow and reg-id=3D987 when= =20 registering over the second flow later on?
 
RFC5626, section 4.2.1 talks about "the sa= me=20 sequence of reg-id values", but it is a little unclear.
 
----
4.2.1.  Initial=20 Registrations
...
   A UAC conforming to this specification= MUST=20 include in the Contact
   header field, a "reg-id" parameter t= hat=20 is distinct from other
   "reg-id" parameters used in other=20 registrations that use the same
   "+sip.instance" Contact hea= der=20 field parameter and AOR.  Each one of
   these registrati= ons=20 will form a new flow from the UA to the proxy.
>>>
 &nb= sp;=20 The sequence of reg-id values does not have to be sequential but=20 MUST
   be exactly the same sequence of reg-id values each tim= e the=20 UA
   instance power cycles or reboots, so that the reg-id val= ues=20 will
   collide with the previously used reg-id=20 values.
<<<
This is so the
   registrar can rep= lace=20 the older registrations.
...
----
 
Thanks for clarification.
 
Kind regards
 
Ivo Sedlacek
 

 
--_000_3A324A65CCACC64289667DFAC0B88E120CD4F05D55ESESSCMS0360e_-- From dworley@avaya.com Thu Sep 8 08:18:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783B021F85F1 for ; Thu, 8 Sep 2011 08:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZI3Y3YDNsqw for ; Thu, 8 Sep 2011 08:18:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id EEBF021F85EF for ; Thu, 8 Sep 2011 08:18:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAH7caE6HCzI1/2dsb2JhbABDqAJ4gUYBAQEBAgESKEQLAgEIDQghEDIlAQEEARIIGodTnD0Cm0mGDWAEmGOMAg X-IronPort-AV: E=Sophos;i="4.68,351,1312171200"; d="scan'208";a="302348308" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Sep 2011 11:20:16 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Sep 2011 11:11:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 8 Sep 2011 11:20:15 -0400 From: "Worley, Dale R (Dale)" To: Ivo Sedlacek , "sipcore@ietf.org" Date: Thu, 8 Sep 2011 11:20:15 -0400 Thread-Topic: RFC5626, reg-id usage after power up Thread-Index: AcxuEDm6DNuEMNa4TzWBNAbvd+ob+gAKcmJp Message-ID: References: <3A324A65CCACC64289667DFAC0B88E120CD4F05D55@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E120CD4F05D55@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC5626, reg-id usage after power up X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:18:25 -0000 > From: Ivo Sedlacek [ivo.sedlacek@ericsson.com] >=20 > When the UA is powered up again: > A) must the UA use reg-id=3D987 when registering over the first flow > and reg-id=3D654 when registering over the second flow later on? > or > B) can the UA use reg-id=3D654 when registering over the first flow > and reg-id=3D987 when registering over the second flow later on? >=20 > RFC5626, section 4.2.1 talks about "the same sequence of reg-id > values", but it is a little unclear. The important aspect is: so that the reg-id values will collide with the previously used reg-id values. This is so the registrar can replace the older registrations. Strictly, the registrar/proxy doesn't depend on the UA repeating values of reg-id in order to operate correctly. But the system operates much better if, when a later registration is intended to be the successor of an earlier registration, it uses the same reg-id. In your case, it appears that the feature tags are important, so you would want to use reg-id 987 when registering with feature tag X, and reg-id 654 when registering with feature tag Y. Dale From internet-drafts@ietf.org Fri Sep 9 04:41:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78E521F8AE6; Fri, 9 Sep 2011 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsqU278sTwWX; Fri, 9 Sep 2011 04:41:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFA21F8581; Fri, 9 Sep 2011 04:41:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909114157.28060.14225.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 04:41:57 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 11:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Requirements for indication of features supported by a S= IP proxy Author(s) : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-proxy-feature-reqs-01.txt Pages : 8 Date : 2011-09-09 The Session Initiation Protocol (SIP) "Caller Preferences" ext= ension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-0= 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-01= .txt From christer.holmberg@ericsson.com Fri Sep 9 04:44:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBF721F8B08 for ; Fri, 9 Sep 2011 04:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBl18EaoDsV3 for ; Fri, 9 Sep 2011 04:44:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEA421F8AD6 for ; Fri, 9 Sep 2011 04:44:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e9-4e69fc730cd0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.16.20773.37CF96E4; Fri, 9 Sep 2011 13:45:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 9 Sep 2011 13:45:55 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 9 Sep 2011 13:45:53 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-proxy-feature-reqs-01 Thread-Index: Acxu5geZ0V/MXZlYSZOxXPdictIH9A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E85E15@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233E85E15ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 11:44:02 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233E85E15ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-01) of the proxy-feature reqs draft. Based on feedback, I've added a couple of requirements, and done some edito= rial modifications in the requirements, and some editorial clarifications i= n the use-cases. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852233E85E15ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new version (-01) of the proxy-featu= re reqs draft.
 
Based on feedback, I've added a couple of requirement= s, and done some editorial modifications in the requirements, and some edit= orial clarifications in the use-cases.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852233E85E15ESESSCMS0356e_-- From iesg-secretary@ietf.org Mon Sep 12 08:02:59 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1BE21F8BBC; Mon, 12 Sep 2011 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOx8cYwsLeKC; Mon, 12 Sep 2011 08:02:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DBC21F8BB7; Mon, 12 Sep 2011 08:02:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912150258.1148.26349.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 08:02:58 -0700 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'Location Conveyance for the Session Initiation Protocol' to Proposed Standard (draft-ietf-sipcore-location-conveyance-09.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 15:03:00 -0000 The IESG has approved the following document: - 'Location Conveyance for the Session Initiation Protocol' (draft-ietf-sipcore-location-conveyance-09.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ Technical Summary This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. Working Group Summary This work began in the (now concluded) SIPPING working group back in 2003, and progressed through the (also concluded) SIP working group before being finalized in the SIPCORE working group. The protocol mechanism underwent significant simplification in early 2010 to reflect a better understanding of the core requirements underpinning the work. Although this simplification was initially controversial, the working group did manage to achieve a rather strong consensus around the new mechanism after some additional changes. Document Quality This protocol mechanism is described in the 3GPP document 24.229 as a component of certain emergency calling scenarios in IMS-based networks. It was developed in the SIP and SIPCORE working groups with input from GEOPRIV working group participants. RFC Editor Note: (updated to apply to -09) 1) In Section 4.4 OLD There is no guidance given in this document as to which locationValue, when more than one was present in the SIP request, is related to the Geolocation-Error code; meaning that, somehow not defined here, the LR just picks one to error. NEW When more than one locationValue is present in a SIP request, this mechanism provides no indication which one the Geolocation- Error code corresponds to. If multiple errors are present, the LR applies local policy to select one. 2) Section 4.6, fourth paragraph, first sentence: OLD location information via an HTTP NEW location information via HTTP 3) Section 8.3, registration of geolocation-http: OLD via an HTTP NEW via HTTP 4) Please change the current inclusion of TLP 3.0 section 6.b to use the TLP 4.0 section 6.b. From brett@broadsoft.com Wed Sep 14 05:15:41 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6521F8B84 for ; Wed, 14 Sep 2011 05:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9hTkRUgyR-E for ; Wed, 14 Sep 2011 05:15:35 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpedge01.chinookhosting.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 80BB121F8B7C for ; Wed, 14 Sep 2011 05:15:35 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 14 Sep 2011 05:19:15 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 14 Sep 2011 05:19:15 -0700 From: Brett Tate To: "adam@nostrum.com" , "sipcore@ietf.org" Date: Wed, 14 Sep 2011 05:17:33 -0700 Thread-Topic: draft-ietf-sipcore-rfc3265bis-03: comments concerning RFC 5057 Thread-Index: Acxy2EfXxTYmgYXOR4SjNcgef/iikg== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C087ECC59@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc3265bis-03: comments concerning RFC 5057 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 12:15:41 -0000 Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 s= nippet indicating subscriber "MUST consider the subscription terminated", t= he draft should potentially better indicate that the MUST does not preempt = the RFC 5057 notes (such as for 482 and 483) which indicate situations wher= e the dialog would not be terminated. Section 4.1.2.2: "If a SUBSCRIBE request to refresh a subscription receives= a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber M= UST consider the subscription terminated. (See [RFC5057] for further detai= ls and notes about the effect of error codes on dialogs and usages within d= ialog, such as subscriptions)." Do the RFC 5057 notes for 482 edge condition still apply? It indicates an = RFC 3263 advancing situation which might trigger a 482 response and allow t= he subscription to remain. If the RFC 5057 notes for 482 edge condition st= ill apply, is it adequately indicated within the above snippet? Thanks, Brett From ibc@aliax.net Fri Sep 16 07:37:13 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F54A21F8B19 for ; Fri, 16 Sep 2011 07:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr7Vn6qH04VW for ; Fri, 16 Sep 2011 07:37:13 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E572121F8781 for ; Fri, 16 Sep 2011 07:37:12 -0700 (PDT) Received: by qyk33 with SMTP id 33so3972684qyk.10 for ; Fri, 16 Sep 2011 07:39:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.166 with SMTP id r38mr1947969qci.254.1316183967284; Fri, 16 Sep 2011 07:39:27 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 07:39:27 -0700 (PDT) Date: Fri, 16 Sep 2011 16:39:27 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] About draft-gurbani-sip-sipsec X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 14:37:13 -0000 Hi all, I would like to comment about draft-gurbani-sip-sipsec "The SIPSEC Uniform Resource Identifier (URI)". I like the idea proposed there. Even more taking into account that it is based on the same mechanism for HTTP/CONNECT (widely deployed). One of the drawback of this mechanism is that it mandates creating multiple TCP connections between two proxies, this is: P1 P2 Alice --CONNECT---->------------------> ---------------------> Bob Carol --CONNECT---->------------------> ---------------------> Adam Tomy --CONNECT---->------------------> ---------------------> Mark In a normal SIP scenario, if communication between P1 and P2 was TCP or TLS, P1 would just mantain a single connection with P2. But using CONNECT as stated in the draft, P1 needs to open 3 TCP connections with P2 (as neither P1 or P2 can inspect the data transported). I don't think this "limitation" is a showstopper, but just something to take into account. Another "issue": The draft requires that the TLS negotiation is made by both endpoints (let's say two phones), so the UAS MUST have a TLS certificate, which is uncommon, am I right? And the last comment: proxies in the path cannot inspect the SIP traffic through the established connection so they know nothing about what's happening in the call or transactions. Proxies cannot do accounting or whatever other action as they are not SIP proxies now, but just TCP proxies. How does that fit with current SIP deployments? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From vkg@bell-labs.com Fri Sep 16 09:04:03 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B773D21F8C41 for ; Fri, 16 Sep 2011 09:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQwSs8hSuzpg for ; Fri, 16 Sep 2011 09:04:03 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6E21F8C32 for ; Fri, 16 Sep 2011 09:04:03 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p8GG6HB7011166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Sep 2011 11:06:17 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8GG6HNP001285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Sep 2011 11:06:17 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8GG6HC4021608 for ; Fri, 16 Sep 2011 11:06:17 -0500 (CDT) Message-ID: <4E73748B.6020908@bell-labs.com> Date: Fri, 16 Sep 2011 11:08:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sipcore] About draft-gurbani-sip-sipsec X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 16:04:03 -0000 On 09/16/2011 09:39 AM, Iñaki Baz Castillo wrote: > Hi all, > > I would like to comment about draft-gurbani-sip-sipsec "The SIPSEC > Uniform Resource Identifier (URI)". > I like the idea proposed there. Even more taking into account that it > is based on the same mechanism for HTTP/CONNECT (widely deployed). Thanks! > Another "issue": The draft requires that the TLS negotiation is made > by both endpoints (let's say two phones), so the UAS MUST have a TLS > certificate, which is uncommon, am I right? Uncommon, yes. However, self-signed certificates would work (as long as the fingerprint was exchanged by some other means). > And the last comment: proxies in the path cannot inspect the SIP > traffic through the established connection so they know nothing about > what's happening in the call or transactions. Proxies cannot do > accounting or whatever other action as they are not SIP proxies now, > but just TCP proxies. How does that fit with current SIP deployments? It does not. Understandably, the rub against this work back then, and I presume now as well, will be that the value proposition of turning all the intermediaries into simple byte forwarders is hard to justify. However, if you are Mick O'Malley [1], then you'd be happy if such a scheme was provided :-) [1] "Counting from Zero", Alan Johnston, 2011. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ibc@aliax.net Fri Sep 16 09:09:26 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2F021F8CBE for ; Fri, 16 Sep 2011 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+mkBwFnAXA9 for ; Fri, 16 Sep 2011 09:09:26 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0B21F8CA1 for ; Fri, 16 Sep 2011 09:09:25 -0700 (PDT) Received: by qyk32 with SMTP id 32so613602qyk.10 for ; Fri, 16 Sep 2011 09:11:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr1898678qaz.278.1316189500383; Fri, 16 Sep 2011 09:11:40 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 09:11:40 -0700 (PDT) In-Reply-To: <4E73748B.6020908@bell-labs.com> References: <4E73748B.6020908@bell-labs.com> Date: Fri, 16 Sep 2011 18:11:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Vijay K. Gurbani" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] About draft-gurbani-sip-sipsec X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 16:09:26 -0000 2011/9/16 Vijay K. Gurbani : > It does not. =C2=A0Understandably, the rub against this work back then, > and I presume now as well, will be that the value proposition of > turning all the intermediaries into simple byte forwarders is > hard to justify. > > However, if you are Mick O'Malley [1], then you'd be happy if > such a scheme was provided :-) :) --=20 I=C3=B1aki Baz Castillo From dean.willis@softarmor.com Tue Sep 27 17:34:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2803821F8C6F for ; Tue, 27 Sep 2011 17:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SXLIFE=1.07, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLR2jZj5ia0L for ; Tue, 27 Sep 2011 17:34:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87A0E21F8CE7 for ; Tue, 27 Sep 2011 17:34:27 -0700 (PDT) Received: by gyd12 with SMTP id 12so7139283gyd.31 for ; Tue, 27 Sep 2011 17:37:14 -0700 (PDT) Received: by 10.151.101.2 with SMTP id d2mr7317148ybm.9.1317170234212; Tue, 27 Sep 2011 17:37:14 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id s8sm83530240ani.3.2011.09.27.17.37.12 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 17:37:13 -0700 (PDT) Message-ID: <4E826C37.5070501@softarmor.com> Date: Tue, 27 Sep 2011 19:37:11 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] About draft-gurbani-sip-sipsec X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 00:34:28 -0000 On 9/16/11 9:39 AM, Iñaki Baz Castillo wrote: > Hi all, > > I would like to comment about draft-gurbani-sip-sipsec "The SIPSEC > Uniform Resource Identifier (URI)". > I like the idea proposed there. Even more taking into account that it > is based on the same mechanism for HTTP/CONNECT (widely deployed). > Thanks! > > Another "issue": The draft requires that the TLS negotiation is made > by both endpoints (let's say two phones), so the UAS MUST have a TLS > certificate, which is uncommon, am I right? I understand that comodohacker has made certs widely available. You wanna be gmail for a day? Seriously, yes, you're right. And this is a major "design feature", not unintended. It gives us real "end to end" authentication and privacy, subject to the strength of the certificate issuance process (see: comodohacker). As Vijay pointed out, you can issue your own certificates if you and your partner work out the trust relationships outside of the usual CA process. The certificate used can also be dynamically varied with the target identity. This works nicely in the enterprise space, for example. Let's say as a consultant working for many clients, each gives me a cert to use when talking with them. My UA can key off the remote domain identifier in order to know which cert to present during handshake. However, nothing about the protocol really demands mutual cert-auth. It should be possible to use HTTP-style cert-auth of the UAS and digest auth of the UAC. On the other hand, you're going to need a cert to answer the phone, so you might as well use it when making calls, too. > And the last comment: proxies in the path cannot inspect the SIP > traffic through the established connection so they know nothing about > what's happening in the call or transactions. Proxies cannot do > accounting or whatever other action as they are not SIP proxies now, > but just TCP proxies. How does that fit with current SIP deployments? That's another feature, not a bug. Current SIP deployments are mostly MITM attacks waiting to happen. Where this becomes incredibly important is P2PSIP (aka SIP/RELOAD). When some other bozo's box is acting as your proxy, do you really want it doing "accounting or whatever other action" on your SIP messages? Further, the processing load on the proxies is hugely decreased. Not only can they stop worrying about wiretapping every SIP message (as such would be pointless), they no longer require the overhead of having to decrypt each message before logging it and then re-encrypting it before resending it. This makes them hundreds of times more scalable. It's a win-win for everybody who matters. Of course, this also works well for criminal conspiracies that have a good IT department and can mint and share their own certs out-of-band. I'm OK with that. Note that the presence of a communication between the two endpoints is still revealed; it's just the text of the signaling between them that is protected by the protocol, so snoops could still get a "pen register", which in the US is typically a warrantless request anyhow. True anonymity is much harder; what is needed is a TOR-ified version of the protocol, and that still reveals two half-calls. -- Dean -- Dean -- Dean