From wwwrun@rfc-editor.org Fri Oct 1 03:04:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042A13A69F9 for ; Fri, 1 Oct 2010 03:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5jZdLRkUp3o for ; Fri, 1 Oct 2010 03:04:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id F08B53A6D66 for ; Fri, 1 Oct 2010 03:04:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 294C9E066A; Fri, 1 Oct 2010 03:05:12 -0700 (PDT) To: RjS@nostrum.com, theo@crazygreek.co.uk, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, adam@nostrum.com, pkyzivat@cisco.com From: RFC Errata System Message-Id: <20101001100512.294C9E066A@rfc-editor.org> Date: Fri, 1 Oct 2010 03:05:12 -0700 (PDT) Cc: ah@TR-Sys.de, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] [Technical Errata Reported] RFC6026 (2539) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 10:04:25 -0000 The following errata report has been submitted for RFC6026, "Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6026&eid=2539 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 8.4, pg.12 Original Text ------------- |8.4. Pages 126 through 128 Section 17.1.1.2. Replace paragraph 7 (starting "When in either") through the end of the section with: Corrected Text -------------- |8.4. Pages 126 through 129 Section 17.1.1.2. Replace paragraph 7 (starting "When in either") through the end of the section with: Notes ----- Rationale: In RFC 3261, Section 17.1.1.2. extends to mid-page 129. So if the quoted text is correct, the section headline here is strongly misleading, contradicts the text, and hence needs adjustment. Since the textual scope of the change is at the heart of this RFC, this Errata note is classified as Technical. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6026 (draft-ietf-sipcore-invfix-01) -------------------------------------- Title : Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests Publication Date : September 2010 Author(s) : R. Sparks, T. Zourzouvillys Category : PROPOSED STANDARD Source : Session Initiation Protocol Core Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From dworley@avaya.com Fri Oct 1 10:08:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A693A6C38 for ; Fri, 1 Oct 2010 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGorwjcswszz for ; Fri, 1 Oct 2010 10:08:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3A29D3A6C32 for ; Fri, 1 Oct 2010 10:08:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="210108813" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Oct 2010 13:09:06 -0400 X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="522274884" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2010 13:09:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 1 Oct 2010 13:09:05 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Fri, 1 Oct 2010 13:07:54 -0400 Thread-Topic: 4244bis -- some examples Thread-Index: AQHLYYtaYnyss8b4ikW+oiKQOCM0AA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] 4244bis -- some examples X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:08:21 -0000 Four typical cases of redirection, showing the resulting History-Info entries in the generated requests, per draft-ietf-sipcore-rfc4244bis-01. The final case, which combines features of the first three cases, is typical for the sipXecs/SCS system. Incoming request has header: History-Info: hhh The final hi-entry in hhh has hi-index "xxx". Case 1: Request is forwarded to 3 destinations. Destinations are sip:A (rc), sip:B (mp), and sip:C. Outgoing request to A: History-Info: hhh, ;index=3Dxxx.1;rc Outgoing request to B: History-Info: hhh, ;index=3Dxxx.2;mp=3Dxxx Outgoing request to C: History-Info: hhh, ;index=3Dxxx.3 Case 2: Request is forwarded to 3 destinations due to 302 response from redirect server. Redirect server is sip:R. Outgoing request to redirect server: History-Info: hhh, ;index=3Dxxx.1 Incoming response from redirect server: [same] Destinations in 302 are , , and . Outgoing request to A: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.2;rc [%3b is ';'. %3d is '=3D'.] Outgoing request to B: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.3;mp=3Dxxx.1 Outgoing request to C: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.4 Case 3: Request forwarded to one destination due to failure of a fork to another destination. Destinations are sip:A (rc), falling back to sip:B. Outgoing request to A: History-Info: hhh, ;index=3Dxxx.1;rc Outgoing request to B: History-Info: hhh, ;index=3Dxxx.1;rc, ;index=3Dxxx.2 [%3b is ';'. %3d is '=3D'.] Case 4: Request is sent to redirect server which provides 3 destinations, one of which is low priority. Redirect server is sip:R. Outgoing request to redirect server: History-Info: hhh, ;index=3Dxxx.1 Incoming response from redirect server: [same] Destinations in 302 are , , and ;q= =3D0.1. Outgoing request to A: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.2;rc [%3b is ';'. %3d is '=3D'.] Outgoing request to B: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.3;mp=3Dxxx.1 Outgoing request to C: History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.2;rc, ;index=3Dxxx.3;mp= =3Dxxx.1, ;index=3Dxxx.4 From dworley@avaya.com Fri Oct 1 10:57:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3333A6CD1 for ; Fri, 1 Oct 2010 10:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4fGs2UndRFk for ; Fri, 1 Oct 2010 10:57:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 673483A6918 for ; Fri, 1 Oct 2010 10:57:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="210115775" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Oct 2010 13:57:47 -0400 X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="522292484" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2010 13:57:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 1 Oct 2010 13:57:46 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Fri, 1 Oct 2010 13:57:46 -0400 Thread-Topic: 4244bis -- some examples Thread-Index: AQHLYYtaYnyss8b4ikW+oiKQOCM0AJMsXqjv Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] 4244bis -- some examples X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:57:01 -0000 Some talking points regarding the recent examples: 1. It's not clear why the "rc" parameter does not have a value telling where the hi-targeted-uri is derived from, but the "mp" parameter does. (This is ticket 41.) 2. For hi-entry's that do not have either "rc" or "mp", there is no way to record where the hi-targeted-uri is derived from. It would seem desirable to move the mp-param to another parameter name that is independent of "rc" and "mp", or to define an "other" parameter to use in exactly the cases where "rc" and "mp" do not apply. 3. The "hit" URI-parameter on the Contact URIs in a 3xx response would seem to be better done as header parameters. This gives: Contact: ;hit=3Drc, ;hit=3Dmp, (This is, or is related to, ticket 4.) 4. As far as I can tell from the rules, the intention is that History-Info will contain sibling forks of the current request only if the sibling fork has already returned a response. There doesn't seem to be a strong reason not to always include all sibling forks, although if we retain the convention that the last hi-entry corresponds to the containing request, we can't always document all known sibling forks in History-Request (as some of them will have higher index numbers than the containing request). 5. The response to a request is encoded in a Reason 'header' in the hi-targeted-uri. It would seem more natural to encode the value in a header parameter. E.g.: History-Info: hhh, ;index=3Dxxx.1;reason=3DSIP%3bcause%3d302, ;index=3Dxxx.2;rc 6. In the fourth example, when the call falls over to voicemail (sip:C), the History-Info shows the derivation of the request-URI (if change 2 above is accepted): History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.2;rc, ;index=3Dxxx.3;mp= =3Dxxx.1, ;index=3Dxxx.4;other=3Dxxx.1 But it does not explicitly show which failed forks caused the fork to sip:C to be generated. (In this case, the call falls back to voicemail only after forks xxx.2 and xxx.3 do not answer.) It may be possible to deduce this information in many cases, but to solve the problem in all cases will probably require making this information explicit. E.g., History-Info: hhh, ;index=3Dxxx.1, ;index=3Dxxx.2;rc= =3Dxxx.1, ;index=3Dxxx.3;mp= =3Dxxx.1, ;index=3Dxxx.4;other=3Dxxx.1;after=3Dxxx.2/xxx= .3 The "after" parameter specifies the request(s) whose responses caused the sip:C fork to be generated. (I did not add "after" to xxx.2 and xxx.3 because the values of the rc and mp parameters make those dependencies explicit.) Dale From root@core3.amsl.com Tue Oct 5 07:15:05 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CFA2A3A6F7E; Tue, 5 Oct 2010 07:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101005141503.CFA2A3A6F7E@core3.amsl.com> Date: Tue, 5 Oct 2010 07:15:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-06.txt Pages : 25 Date : 2010-10-05 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-05071445.I-D@ietf.org> --NextPart-- From adam@nostrum.com Tue Oct 5 08:33:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638433A6AD2 for ; Tue, 5 Oct 2010 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15jwnnpUCAtD for ; Tue, 5 Oct 2010 08:32:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F18133A6C0F for ; Tue, 5 Oct 2010 08:32:42 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o95FXHNG071148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 10:33:17 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CAB453D.5020601@nostrum.com> Date: Tue, 05 Oct 2010 10:33:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------080106080601010709020805" Cc: simple-chairs@tools.ietf.org, "sipcore-chairs@tools.ietf.org" Subject: [sipcore] Call for consensus: draft-ietf-sipcore-presence-scaling-requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:33:24 -0000 This is a multi-part message in MIME format. --------------080106080601010709020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] As you can see below, the SIMPLE working group has decided to remove draft-ietf-simple-interdomain-scaling-analysis from its chartered milestones. SIPCORE has a closely related work item: draft-ietf-sipcore-presence-scaling-requirements. It has been evaluated by the IESG, but has not been approved for publication. The issue that is blocking its publication involves some security related issues, which were to be addressed in the interdomain-scaling-analysis. Further, the actual description of the driving factors for the presence-scaling-requirements work are present only in the interdomain-scaling-analysis work. With the interdomain-scaling-analysis work abandoned, the only path for publishing presence-scaling-requirements would be to bring it back to the working group, add the context that had been provided by the interdomain-scaling-analysis draft, and address the IESG concerns that have been raised around security and scaling. Given that the community of interest -- or disinterest, as the case may be -- for the abandoned interdomain-scaling-analysis document is almost certainly identical to that for the presence-scaling-requirements document, it is a safe assumption that SIPCORE can similarly remove the presence-scaling-requirements milestone from its charter. So, I am posing the same question as the SIMPLE chairs: with the interdomain-scaling-analysis work abandoned, is the presence-scaling-requirements work still relevant? Are people still interested in working on it? By that, I mean willing to spend time doing focused reviews, offering feedback and maybe even text? Silence will be interpreted in the negative. /a -------- Original Message -------- Subject: Re: [Simple] draft-ietf-simple-interdomain-scaling-analysis Date: Mon, 27 Sep 2010 14:55:48 -0500 From: Ben Campbell To: Simple WG Hi, We've had no expression of interest in continuing this effort. We will ask our ADs to remove the milestone. Thanks! Ben. On Sep 24, 2010, at 9:24 AM, Ben Campbell wrote: > It's been almost a week, and no one has responded. If we don't hear > otherwise from people who want to invest their time to work on this > draft by Monday, we will ask the ADs to remove this milestone from the > SIMPLE charter. > > Thanks! > > Ben. > > On Sep 19, 2010, at 9:09 AM, Ben Campbell wrote: > >> (as chair) >> >> draft-ietf-simple-interdomain-scaling-analysis has been stalled for a >> while now. We handed it over to the IESG some time ago, but received >> AD feedback indicating it needed significant work. It has been >> cycle starved since then. The author may be in a position to start >> working on it again. >> * >> * >> *My question to the working group is, is this work still relevant? >> Are people still interested in working on it? By that, I mean willing >> to spend time doing focused reviews, offering feedback and maybe even >> text?* >> * >> * >> *Silence will be interpreted in the negative. * >> * >> * >> *Thanks,* >> * >> * >> *Ben.* >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --------------080106080601010709020805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

As you can see below, the SIMPLE working group has decided to remove draft-ietf-simple-interdomain-scaling-analysis from its chartered milestones.

SIPCORE has a closely related work item: draft-ietf-sipcore-presence-scaling-requirements.
It has been evaluated by the IESG, but has not been approved for publication. The issue that is blocking its publication involves some security related issues, which were to be addressed in the interdomain-scaling-analysis. Further, the actual description of the driving factors for the presence-scaling-requirements work are present only in the interdomain-scaling-analysis work.

With the interdomain-scaling-analysis work abandoned, the only path for publishing presence-scaling-requirements would be to bring it back to the working group, add the context that had been provided by the interdomain-scaling-analysis draft, and address the IESG concerns that have been raised around security and scaling.

Given that the community of interest -- or disinterest, as the case may be -- for the abandoned interdomain-scaling-analysis document is almost certainly identical to that for the presence-scaling-requirements document, it is a safe assumption that SIPCORE can similarly remove the presence-scaling-requirements milestone from its charter.

So, I am posing the same question as the SIMPLE chairs: with the interdomain-scaling-analysis work abandoned, is the presence-scaling-requirements work still relevant? Are people still interested in working on it? By that, I mean willing to spend time doing focused reviews, offering feedback and maybe even text?

Silence will be interpreted in the negative.

/a


-------- Original Message --------
Subject: Re: [Simple] draft-ietf-simple-interdomain-scaling-analysis
Date: Mon, 27 Sep 2010 14:55:48 -0500
From: Ben Campbell <ben@nostrum.com>
To: Simple WG <simple@ietf.org>


Hi,

We've had no expression of interest in continuing this effort. We will ask our ADs to remove the milestone.

Thanks!

Ben.

On Sep 24, 2010, at 9:24 AM, Ben Campbell wrote:

It's been almost a week, and no one has responded. If we don't hear otherwise from people who want to invest their time to work on this draft by Monday, we will ask the ADs to remove this milestone from the SIMPLE charter.

Thanks!

Ben.

On Sep 19, 2010, at 9:09 AM, Ben Campbell wrote:

(as chair)

draft-ietf-simple-interdomain-scaling-analysis has been stalled for a while now. We handed it over to the IESG some time ago, but received AD feedback indicating it needed significant work.   It has been cycle starved since then. The author may be in a position to start working on it again.

My question to the working group is, is this work still relevant? Are people still interested in working on it? By that, I mean willing to spend time doing focused reviews, offering feedback and maybe even text?

Silence will be interpreted in the negative. 

Thanks,

Ben.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

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


--------------080106080601010709020805-- From gao.yang2@zte.com.cn Wed Oct 6 09:16:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F913A71A5 for ; Wed, 6 Oct 2010 09:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.236 X-Spam-Level: X-Spam-Status: No, score=-98.236 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUWG7uV5rqDO for ; Wed, 6 Oct 2010 09:16:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id BADE03A6F9D for ; Wed, 6 Oct 2010 09:16:01 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Thu, 7 Oct 2010 00:14:35 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 79135.3772637948; Thu, 7 Oct 2010 00:14:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o96GH7aC002939; Thu, 7 Oct 2010 00:17:07 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 7 Oct 2010 00:14:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-07 00:16:44, Serialize complete at 2010-10-07 00:16:44 Content-Type: multipart/alternative; boundary="=_alternative 00596B81482577B4_=" X-MAIL: mse2.zte.com.cn o96GH7aC002939 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:16:22 -0000 This is a multipart message in MIME format. --=_alternative 00596B81482577B4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSdkIGxpa2UgdG8gZW1waGFzaXplIHRoYXQgSSBhbHNvIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBu byANCmNvbmZlcmVuY2UvbWl4aW5nIHJlc291cmNlcyBmb3IgdGhlIHNob3dlZCB1c2UgY2FzZSwg YXMgSSBzYWlkIGluIHRoZSANCnByZXZpb3VzIG1haWwuDQoNCkJ1dCBJIHRoaW5rIHdoYXQgd2Ug c2FpZCB3YXMgbm90IGRlZmluZWQgY2xlYXJseSBpbiB0aGUgUkZDMzkxMS4gQW5kIEkgDQphbHNv IHRoaW5rIGl0IGlzIGhhcmRseSB0byBkbyBhbnkgZGVkdWN0aW9uIHRvIGdldCB0aGUgcnVsZXMg d2UgZGlzY3Vzc2VkLg0KDQpTbywgaXQgaXMgbm90IGEgcXVlc3Rpb24gbGlrZSAiaG93IHNob3Vs ZCBpdCBiZT8iLCBidXQgYSBxdWVzdGlvbiBsaWtlIA0KIndoZXJlIGlzIGl0IGRlZmluZWQiLg0K DQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K IFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4 NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KDQoNCiJXb3JsZXksIERhbGUgUiAoRGFsZSkiIDxkd29ybGV5 QGF2YXlhLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMTAt MDEgMDQ6MjMNCg0KytW8/sjLDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4sICJn YW8ueWFuZzJAenRlLmNvbS5jbiIgDQo8Z2FvLnlhbmcyQHp0ZS5jb20uY24+DQqzrcvNDQoic2lw Y29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSZTogW3NpcGNvcmVdIEFi b3V0IFJGQzM5MTEoSm9pbiBoZWFkZXIpJ3MgcG90ZW50aWFsIGVycm9yOg0KDQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2lwY29yZS1i b3VuY2VzQGlldGYub3JnIFtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN ClBhdWwgS3l6aXZhdCBbcGt5eml2YXRAY2lzY28uY29tXQ0KDQpJIHRoaW5rIHRoZSB3b3JrcyB5 b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBhbHJlYWR5IGFyZSBjb25zaXN0ZW50IHdpdGgNCnRoZSBz Y2VuYXJpbyB5b3UgcmFpc2UuIFNwZWNpZmljYWxseSwNCg0KPiBhbmQgYXNzaWduIGFueSBtaXhp bmcgb3IgY29uZmVyZW5jaW5nIHJlc291cmNlcyBuZWNlc3NhcnkgdG8gY29tcGxldGUgDQp0aGUg am9pbg0KDQppbmNsdWRlcyB0aGUgY2FzZSB3aGVyZSBubyBtaXhpbmcgb3IgY29uZmVyZW5jaW5n IHJlc291cmNlcyBhcmUgbmVjZXNzYXJ5Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KSSB0aGluayB0aGF0IFBhdWwgaXMgY29ycmVjdCBoZXJlLiAg SWYgdHdvIGRpYWxvZ3MgZ28gdG8gYSBzZXJ2ZXIgYW5kIGFyZSANCmpvaW5lZCBhdCB0aGUgc2Vy dmVyLCBhbmQgYm90aCBkaWFsb2dzIGFyZSBzZW5kb25seSBhdCB0aGUgc2VydmVyLCB0aGVuIA0K Im1peGluZyIgaXMgdmVyeSBzaW1wbGU6IHRoZSBvbmUgc291cmNlIChnZW5lcmF0ZWQgYnkgdGhl IHNlcnZlcikgaXMgDQpkdXBsaWNhdGVkIGFzIFJUUCB0byBlYWNoIGRpYWxvZydzIHJlbW90ZSBl bmQuDQoNCkluIHByYWN0aWNlLCBvbmUgbWlnaHQgc2F5IHRoYXQgdGhpcyAiZG9lcyBub3QgYWxs b2NhdGUgbWl4aW5nIHJlc291cmNlcyIuIA0KIE9UT0gsIGZvciBzb21lIGltcGxlbWVudGF0aW9u cywgdGhpcyBkdXBsaWNhdGlvbiBvZiB0aGUgbWVkaWEgc3RyZWFtIG1heSANCnJlcXVpcmUgdGhl IGFsbG9jYXRpb24gb2YgYSBtaXhpbmcgcmVzb3VyY2UsIGlmIG5vIG90aGVyIGNvbXBvbmVudCBv ZiB0aGUgDQpzZXJ2ZXIgY2FuIHBlcmZvcm0gdGhlIGR1cGxpY2F0aW9uLg0KDQpJIGRvIG5vdCBz ZWUgdGhpcyBhcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBzb2x2ZWQuDQoNCkRhbGUNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXBjb3JlDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00596B81482577B4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtlIHRvIGVtcGhhc2l6 ZSB0aGF0IEkgYWxzbyB0aGluaw0KdGhlcmUgc2hvdWxkIGJlIG5vIGNvbmZlcmVuY2UvbWl4aW5n IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPnJlc291cmNlcw0KPC9mb250PjwvdHQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvciB0aGUgc2hvd2VkIHVzZSBjYXNlLCBhcw0KSSBzYWlk IGluIHRoZSBwcmV2aW91cyBtYWlsLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+QnV0IEkgdGhpbmsgd2hhdCB3ZSBzYWlkIHdhcyBub3QgZGVmaW5lZA0K Y2xlYXJseSBpbiB0aGUgUkZDMzkxMS4gQW5kIEkgYWxzbyB0aGluayBpdCBpcyBoYXJkbHkgdG8g ZG8gYW55IGRlZHVjdGlvbg0KdG8gZ2V0IHRoZSBydWxlcyB3ZSBkaXNjdXNzZWQuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbywgaXQgaXMgbm90IGEg cXVlc3Rpb24gbGlrZSAmcXVvdDtob3cNCnNob3VsZCBpdCBiZT8mcXVvdDssIGJ1dCBhIHF1ZXN0 aW9uIGxpa2UgJnF1b3Q7d2hlcmUgaXMgaXQgZGVmaW5lZCZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7 ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4N CiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPiZxdW90O1dvcmxleSwgRGFsZSBSIChEYWxlKSZxdW90Ow0KJmx0O2R3b3Js ZXlAYXZheWEuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTEwLTAxIDA0OjIzPC9mb250Pg0K PHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBhdWwgS3l6 aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OywNCiZxdW90O2dhby55YW5nMkB6dGUuY29t LmNuJnF1b3Q7ICZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIEFib3V0IFJGQzM5MTEoSm9pbiBoZWFkZXIp J3MNCnBvdGVudGlhbCBlcnJvcjo8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW3NpcGNvcmUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQpQYXVsIEt5eml2YXQgW3BreXppdmF0QGNpc2NvLmNv bV08YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSB3b3JrcyB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBh bHJlYWR5IGFyZSBjb25zaXN0ZW50IHdpdGg8YnI+DQp0aGUgc2NlbmFyaW8geW91IHJhaXNlLiBT cGVjaWZpY2FsbHksPGJyPg0KPGJyPg0KJmd0OyBhbmQgYXNzaWduIGFueSBtaXhpbmcgb3IgY29u ZmVyZW5jaW5nIHJlc291cmNlcyBuZWNlc3NhcnkgdG8gY29tcGxldGUNCnRoZSBqb2luPGJyPg0K PGJyPg0KaW5jbHVkZXMgdGhlIGNhc2Ugd2hlcmUgbm8gbWl4aW5nIG9yIGNvbmZlcmVuY2luZyBy ZXNvdXJjZXMgYXJlIG5lY2Vzc2FyeS48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBQYXVsIGlzIGNvcnJl Y3QgaGVyZS4gJm5ic3A7SWYgdHdvIGRpYWxvZ3MgZ28gdG8gYSBzZXJ2ZXINCmFuZCBhcmUgam9p bmVkIGF0IHRoZSBzZXJ2ZXIsIGFuZCBib3RoIGRpYWxvZ3MgYXJlIHNlbmRvbmx5IGF0IHRoZSBz ZXJ2ZXIsDQp0aGVuICZxdW90O21peGluZyZxdW90OyBpcyB2ZXJ5IHNpbXBsZTogdGhlIG9uZSBz b3VyY2UgKGdlbmVyYXRlZCBieSB0aGUNCnNlcnZlcikgaXMgZHVwbGljYXRlZCBhcyBSVFAgdG8g ZWFjaCBkaWFsb2cncyByZW1vdGUgZW5kLjxicj4NCjxicj4NCkluIHByYWN0aWNlLCBvbmUgbWln aHQgc2F5IHRoYXQgdGhpcyAmcXVvdDtkb2VzIG5vdCBhbGxvY2F0ZSBtaXhpbmcgcmVzb3VyY2Vz JnF1b3Q7Lg0KJm5ic3A7T1RPSCwgZm9yIHNvbWUgaW1wbGVtZW50YXRpb25zLCB0aGlzIGR1cGxp Y2F0aW9uIG9mIHRoZSBtZWRpYSBzdHJlYW0NCm1heSByZXF1aXJlIHRoZSBhbGxvY2F0aW9uIG9m IGEgbWl4aW5nIHJlc291cmNlLCBpZiBubyBvdGhlciBjb21wb25lbnQNCm9mIHRoZSBzZXJ2ZXIg Y2FuIHBlcmZvcm0gdGhlIGR1cGxpY2F0aW9uLjxicj4NCjxicj4NCkkgZG8gbm90IHNlZSB0aGlz IGFzIGEgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZC48YnI+DQo8YnI+DQpEYWxlPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpz aXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90 dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNw O2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtj b25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZu YnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29y Jm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2Fk ZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3Ro aXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkm bmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZu YnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7 YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00596B81482577B4_=-- From gao.yang2@zte.com.cn Wed Oct 6 09:31:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2EC3A6F95 for ; Wed, 6 Oct 2010 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.435 X-Spam-Level: X-Spam-Status: No, score=-95.435 tagged_above=-999 required=5 tests=[AWL=-3.400, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqO+oDTxYlXi for ; Wed, 6 Oct 2010 09:31:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C182F3A6F72 for ; Wed, 6 Oct 2010 09:30:59 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 7 Oct 2010 00:30:44 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.3772637948; Thu, 7 Oct 2010 00:31:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o96GWIah006636; Thu, 7 Oct 2010 00:32:18 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 7 Oct 2010 00:29:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-07 00:31:54, Serialize complete at 2010-10-07 00:31:54 Content-Type: multipart/alternative; boundary="=_alternative 005ACF2A482577B4_=" X-MAIL: mse2.zte.com.cn o96GWIah006636 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:31:29 -0000 This is a multipart message in MIME format. --=_alternative 005ACF2A482577B4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VyZSwgdGhlIHR5cGUgb2YgdGhlIG1lZGlhIHN0cmVhbXMgaXMgZGVjaWRlZCBieSB0aGUgT2Zm ZXIsIHVzdWFsbHkgaXMgDQp0aGUgdXNlciBvZiB0aGUgVUEgc2VuZGluZyB0aGUgSU5WSVRFL1Jl cGxhY2VzLCBhcyB5b3Ugc2FpZC4NCg0KQnV0IEkgc2FpZCBpbiBteSBleGFtcGxlIGlzIHNvbWUg ZGlmZmVyZW50LiBQbGVhc2Ugc2VlIHRoZSBmbG93cyhJIGNvcGllZCANCnRoZW0gZnJvbSBQYXVs J3MgbWFpbCwgYW5kIEkgYWRkIHNvbWUgbmV3IG5vdGVzKToNCg0KDQpYIC0tLS0tLS0tLS0tLS0t LS0tLS0tIFkNCiAgICAgICB2b2ljZS92aWRlbw0KDQovL1kgc2VuZCB2b2ljZS92aWRlbyBzZXNz aW9uIHRvIFguIEFzIFkgZG9lcyBub3Qga25vdyBYIHN1cHBvcnQgSEQgdmlkZW8sIA0Kc28gaGUg c2VuZCB0aGUgY2FsbCBmcm9tIGEgbm9ybWFsIFVFLg0KDQptb3ZpbmcgdG8gKDIpOg0KDQogICBY IC0tLS0tLS0tLS0tLS0tLS0tLS0tIFkNCiAgIHwgICAgICAgdm9pY2UNCiAgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0gWg0KICAgICAgICAgSEQgdmlkZW8NCg0KLy9UaGVuLCBYIHRlbGwg WSB0aGF0IGhpcyBVRSBzdXBwb3J0IEhEIHZpZGVvIGFuZCB3YW50IHRvIGVzdGFibGlzaCB0aGUg SEQgDQp2aWRlbyBzdHJlYW0uIFBsZWFzZSBub3RlIHRoYXQsIFggdGVsbCBZIGJ5IHZvaWNlLCB3 aGlsZSBub3QgYnkgYW55IA0Kc2lnbmFsbGluZy4NCg0KLy9UaGVuLCBZIHVzZSBhIG5ldyBlcXVp cG1lbnQoWikgdG8gdHJhbnNmZXIgdGhlIHZpZGVvIHN0cmVhbSBmcm9tIHRoZSANCm9yaWduYWwg c2Vzc2lvbi4gVGhlIHZvaWNlIHN0cmVhbSBpcyBzdGlsbCBiZXR3ZWVuIFggYW5kIFkuDQogDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQog VGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K DQoNCg0KIldvcmxleSwgRGFsZSBSIChEYWxlKSIgPGR3b3JsZXlAYXZheWEuY29tPiANCreivP7I yzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0xMC0wMSAwNDowOA0KDQrK1bz+yMsN CiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPiwgUGF1bCBLeXpp dmF0IA0KPHBreXppdmF0QGNpc2NvLmNvbT4NCrOty80NCiJzaXBjb3JlQGlldGYub3JnIiA8c2lw Y29yZUBpZXRmLm9yZz4NCtb3zOINClJlOiBbc2lwY29yZV0gQWJvdXQgSm9pbiBhbmQgUmVwbGFj ZXMgSGVhZGVyczogLy9SZXBsYWNlcyBoZWFkZXIncyANCmV4dGVuc2lvbg0KDQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2lwY29yZS1i b3VuY2VzQGlldGYub3JnIFtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN Cmdhby55YW5nMkB6dGUuY29tLmNuIFtnYW8ueWFuZzJAenRlLmNvbS5jbl0NCg0KTm93YWRheXMs IEkgYW0gY29uc2lkZXJpbmcgcmVxdWlyZW1lbnRzIGFib3V0IG1lZGlhIHN0cmVhbXMgdHJhbmZl cmluZyANCmJldHdlZW4gdXNlcidzIFVFcywgc3VjaCBhcyB0cmFuc2ZlcmluZyBhY3RpdmUgdmlk ZW8gc3RyZWFtIGZyb20gb25lIA0Kbm9ybWFsIFVFIHRvIG9uZSBIRChIaWdoIERlZmluaXRpdmUp IGRldmljZS4NCg0KVGhpcyBmdW5jdGlvbiBpcyBzaW1pbGFyIHRvIDNHUFAncyBJVVQoSW50ZXIg VUUgVHJhbnNmZXIpLiBCdXQgSSdkIGxpa2UgdG8gDQpzZWVrIGEgZW5kIHRvIGVuZCBzb2x1dGlv biwgd2l0aCBvdXQgU0NDX0FTJ3MgM3BjYyBjYWxsIGNvbnRyb2wuDQoNCkkgdGhpbmsgd2UgY291 bGQgZG8gb25lIHBvdGVudGlhbCBleHRlbnNpb24gZm9yIFJlcGxhY2VzIGhlYWRlciwgYXM6DQoN ClRoZSBSZXBsYWNlcyBoZWFkZXIgY291bGQgYmUgYWRkZWQgd2l0aCBhIGluZGljYXRpb24uDQpG b3IgZXhhbWxlLCB0cmFuc2ZlciB2aWRlbyB0byBIRCBkZXZpY2UsIHdoaWxlIHNhdmUgdGhlIGF1 ZGlvIGF0IHRoZSANCm9yaWduYWwgZGV2aWNlOg0KVGhlIG5ldyBwYXJ0eShuZXcgZGV2aWNlKSBz ZW5kIGEgSU5WSVRFKHRoZSBPZmZlciB3aXRoIHZpZGVvIHN0cmVhbSkgd2l0aCANClJlcGxhY2Vz IGhlYWRlciwgd2l0aCB0aGUgaW5kaWNhdGlvbi4gVGhlbiB0aGUgVUFTIG9mIHRoaXMgSU5WSVRF IGNhbiBqdXN0IA0KdHJhbnNmZXIgdGhlIG1lZGlhIHN0cmVhbXModmlkZW8pIHRvIHRoZSBuZXcg c2Vzc2lvbiwgYW5kIHNhdmUgdGhlIG90aGVyIA0Kc3RyZWFtcyBpbiB0aGUgb3JpZ2lhbmwgc2Vz c2lvbiAoYnkgYSBuZXcgUmUtSU5WSVRFIHRvIGp1c3QgbXV0ZSB0aGUgDQp0cmFuc2ZlcmVkIG1l ZGlhIHN0cmVhbXMpLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpIb3dldmVyLCB5b3UgbXVzdCBiZXdhcmUgdGhhdCBpbiBTSVAgd2hpY2ggcmVuZGVyaW5nIGRl dmljZXMgb2YgYSBVQSBhcmUgDQp1c2VkIHRvIHJlbmRlciBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVh bXMgaXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIHVzZXIgDQpvZiB0aGUgVUEsIG5vdCBvZiB0 aGUgcmVtb3RlIFVBcyB0aGF0IGl0IGNvbW11bmljYXRlcyB3aXRoLiAgVGhlcmVmb3JlLCANCndo aWxlIGFuIGluY29taW5nIElOVklURS9SZXBsYWNlcyBtYXkgcHJvdmlkZSBIRCB2aWRlbywgaXQg aXMgbm90IHRoZSANCmNob2ljZSBvZiB0aGUgc2VuZGVyIG9mIHRoZSBJTlZJVEUvUmVwbGFjZXMg dGhhdCB0aGUgSEQgdmlkZW8gc3RyZWFtIGJlIA0KcmVuZGVyZWQgb24gdGhlIEhEIHZpZGVvIGRl dmljZS4gIChJbmRlZWQsIHRoZSBzZW5kZXIgb2YgdGhlIA0KSU5WSVRFL1JlcGxhY2VzIGhhcyBu byBjZXJ0YWluIGtub3dsZWRnZSB0aGF0IHRoZSByZWNpcGllbnQgVUEgcG9zc2Vzc2VzIA0KYW4g SEQgdmlkZW8gZGV2aWNlLikgIEl0IGlzIHRoZSBjaG9pY2Ugb2YgdGhlIHVzZXIgb2YgdGhlIHJl Y2lwaWVudCBVQSAob3IgDQptb3JlIGxpa2VseSwgaGlzIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFVB KSB0aGF0IGRldGVybWluZXMgdGhhdCB0aGUgb2ZmZXJlZCANCkhEIHZpZGVvIHN0cmVhbSBpcyB0 byBiZSByZW5kZXJlZCBvbiBhIHBhcnRpY3VsYXIgcmVuZGVyaW5nIGRldmljZS4NCg0KV2l0aGlu IHRoYXQgYXJjaGl0ZWN0dXJlLCB0aGVyZSBjYW4gYmUgbm8gdXNlIGZvciBzdWNoIGFuIGluZGlj YXRpb24gb24gDQp0aGUgUmVwbGFjZXMgaGVhZGVyLg0KDQpEYWxlDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNp cGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m IHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUg YWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 005ACF2A482577B4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cmUsIHRoZSB0eXBlIG9mIHRo ZSBtZWRpYSBzdHJlYW1zDQppcyBkZWNpZGVkIGJ5IHRoZSBPZmZlciwgdXN1YWxseSBpcyB0aGUg dXNlciBvZiB0aGUgVUEgc2VuZGluZyB0aGUgSU5WSVRFL1JlcGxhY2VzLA0KYXMgeW91IHNhaWQu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CdXQgSSBz YWlkIGluIG15IGV4YW1wbGUgaXMgc29tZSBkaWZmZXJlbnQuDQpQbGVhc2Ugc2VlIHRoZSBmbG93 cyhJIGNvcGllZCB0aGVtIGZyb20gUGF1bCdzIG1haWwsIGFuZCBJIGFkZCBzb21lIG5ldw0Kbm90 ZXMpOjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlggLS0tLS0tLS0t LS0tLS0tLS0tLS0gWTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2b2ljZS92aWRlbzxicj4N CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Ly9ZIHNlbmQgdm9pY2UvdmlkZW8g c2Vzc2lvbiB0byBYLiBBcyBZIGRvZXMgbm90IGtub3cNClggc3VwcG9ydCBIRCB2aWRlbywgc28g aGUgc2VuZCB0aGUgY2FsbCBmcm9tIGEgbm9ybWFsIFVFLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KbW92aW5nIHRvICgyKTo8YnI+DQo8YnI+DQogJm5ic3A7IFggLS0t LS0tLS0tLS0tLS0tLS0tLS0gWTxicj4NCiAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2 b2ljZTxicj4NCiAmbmJzcDsgfDxicj4NCiAmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSBa PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBIRCB2aWRlbzwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vL1RoZW4sIFggdGVsbCBZ IHRoYXQgaGlzIFVFIHN1cHBvcnQNCkhEIHZpZGVvIGFuZCB3YW50IHRvIGVzdGFibGlzaCB0aGUg SEQgdmlkZW8gc3RyZWFtLiBQbGVhc2Ugbm90ZSB0aGF0LCBYDQp0ZWxsIFkgYnkgdm9pY2UsIHdo aWxlIG5vdCBieSBhbnkgc2lnbmFsbGluZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPi8vVGhlbiwgWSB1c2UgYSBuZXcgZXF1aXBtZW50KFopIHRvDQp0 cmFuc2ZlciB0aGUgdmlkZW8gc3RyZWFtIGZyb20gdGhlIG9yaWduYWwgc2Vzc2lvbi4gVGhlIHZv aWNlIHN0cmVhbSBpcw0Kc3RpbGwgYmV0d2VlbiBYIGFuZCBZLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+JnF1b3Q7V29ybGV5LCBEYWxlIFIgKERhbGUpJnF1b3Q7DQombHQ7ZHdvcmxleUBhdmF5 YS5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMTAtMDEgMDQ6MDg8L2ZvbnQ+DQo8dGQgd2lk dGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Z2FvLnlhbmcy QHp0ZS5jb20uY24mcXVvdDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OywNClBhdWwgS3l6 aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 c2lwY29yZUBpZXRmLm9yZyZxdW90OyAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gQWJvdXQgSm9pbiBhbmQgUmVwbGFjZXMNCkhlYWRlcnM6 IC8vUmVwbGFjZXMgaGVhZGVyJ3MgZXh0ZW5zaW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24g W2dhby55YW5nMkB6dGUuY29tLmNuXTxicj4NCjxicj4NCk5vd2FkYXlzLCBJIGFtIGNvbnNpZGVy aW5nIHJlcXVpcmVtZW50cyBhYm91dCBtZWRpYSBzdHJlYW1zIHRyYW5mZXJpbmcNCmJldHdlZW4g dXNlcidzIFVFcywgc3VjaCBhcyB0cmFuc2ZlcmluZyBhY3RpdmUgdmlkZW8gc3RyZWFtIGZyb20g b25lIG5vcm1hbA0KVUUgdG8gb25lIEhEKEhpZ2ggRGVmaW5pdGl2ZSkgZGV2aWNlLjxicj4NCjxi cj4NClRoaXMgZnVuY3Rpb24gaXMgc2ltaWxhciB0byAzR1BQJ3MgSVVUKEludGVyIFVFIFRyYW5z ZmVyKS4gQnV0IEknZCBsaWtlDQp0byBzZWVrIGEgZW5kIHRvIGVuZCBzb2x1dGlvbiwgd2l0aCBv dXQgU0NDX0FTJ3MgM3BjYyBjYWxsIGNvbnRyb2wuPGJyPg0KPGJyPg0KSSB0aGluayB3ZSBjb3Vs ZCBkbyBvbmUgcG90ZW50aWFsIGV4dGVuc2lvbiBmb3IgUmVwbGFjZXMgaGVhZGVyLCBhczo8YnI+ DQo8YnI+DQpUaGUgUmVwbGFjZXMgaGVhZGVyIGNvdWxkIGJlIGFkZGVkIHdpdGggYSBpbmRpY2F0 aW9uLjxicj4NCkZvciBleGFtbGUsIHRyYW5zZmVyIHZpZGVvIHRvIEhEIGRldmljZSwgd2hpbGUg c2F2ZSB0aGUgYXVkaW8gYXQgdGhlIG9yaWduYWwNCmRldmljZTo8YnI+DQpUaGUgbmV3IHBhcnR5 KG5ldyBkZXZpY2UpIHNlbmQgYSBJTlZJVEUodGhlIE9mZmVyIHdpdGggdmlkZW8gc3RyZWFtKSB3 aXRoDQpSZXBsYWNlcyBoZWFkZXIsIHdpdGggdGhlIGluZGljYXRpb24uIFRoZW4gdGhlIFVBUyBv ZiB0aGlzIElOVklURSBjYW4ganVzdA0KdHJhbnNmZXIgdGhlIG1lZGlhIHN0cmVhbXModmlkZW8p IHRvIHRoZSBuZXcgc2Vzc2lvbiwgYW5kIHNhdmUgdGhlIG90aGVyDQpzdHJlYW1zIGluIHRoZSBv cmlnaWFubCBzZXNzaW9uIChieSBhIG5ldyBSZS1JTlZJVEUgdG8ganVzdCBtdXRlIHRoZSB0cmFu c2ZlcmVkDQptZWRpYSBzdHJlYW1zKS48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KPGJyPg0KSG93ZXZlciwgeW91IG11c3QgYmV3YXJlIHRoYXQgaW4g U0lQIHdoaWNoIHJlbmRlcmluZyBkZXZpY2VzIG9mIGEgVUEgYXJlDQp1c2VkIHRvIHJlbmRlciBw YXJ0aWN1bGFyIG1lZGlhIHN0cmVhbXMgaXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIHVzZXIN Cm9mIHRoZSBVQSwgbm90IG9mIHRoZSByZW1vdGUgVUFzIHRoYXQgaXQgY29tbXVuaWNhdGVzIHdp dGguICZuYnNwO1RoZXJlZm9yZSwNCndoaWxlIGFuIGluY29taW5nIElOVklURS9SZXBsYWNlcyBt YXkgcHJvdmlkZSBIRCB2aWRlbywgaXQgaXMgbm90IHRoZSBjaG9pY2UNCm9mIHRoZSBzZW5kZXIg b2YgdGhlIElOVklURS9SZXBsYWNlcyB0aGF0IHRoZSBIRCB2aWRlbyBzdHJlYW0gYmUgcmVuZGVy ZWQNCm9uIHRoZSBIRCB2aWRlbyBkZXZpY2UuICZuYnNwOyhJbmRlZWQsIHRoZSBzZW5kZXIgb2Yg dGhlIElOVklURS9SZXBsYWNlcw0KaGFzIG5vIGNlcnRhaW4ga25vd2xlZGdlIHRoYXQgdGhlIHJl Y2lwaWVudCBVQSBwb3NzZXNzZXMgYW4gSEQgdmlkZW8gZGV2aWNlLikNCiZuYnNwO0l0IGlzIHRo ZSBjaG9pY2Ugb2YgdGhlIHVzZXIgb2YgdGhlIHJlY2lwaWVudCBVQSAob3IgbW9yZSBsaWtlbHks DQpoaXMgY29uZmlndXJhdGlvbiBvZiB0aGUgVUEpIHRoYXQgZGV0ZXJtaW5lcyB0aGF0IHRoZSBv ZmZlcmVkIEhEIHZpZGVvDQpzdHJlYW0gaXMgdG8gYmUgcmVuZGVyZWQgb24gYSBwYXJ0aWN1bGFy IHJlbmRlcmluZyBkZXZpY2UuPGJyPg0KPGJyPg0KV2l0aGluIHRoYXQgYXJjaGl0ZWN0dXJlLCB0 aGVyZSBjYW4gYmUgbm8gdXNlIGZvciBzdWNoIGFuIGluZGljYXRpb24gb24NCnRoZSBSZXBsYWNl cyBoZWFkZXIuPGJyPg0KPGJyPg0KRGFsZTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBj b3JlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 005ACF2A482577B4_=-- From dworley@avaya.com Wed Oct 6 11:23:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4724F3A701E for ; Wed, 6 Oct 2010 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.613 X-Spam-Level: X-Spam-Status: No, score=-99.613 tagged_above=-999 required=5 tests=[AWL=-2.714, BAYES_00=-2.599, FR_DOT_FEVER_5=3.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYIQOhvOc5ma for ; Wed, 6 Oct 2010 11:23:41 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B6C7B3A6CB5 for ; Wed, 6 Oct 2010 11:23:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,292,1283745600"; d="scan'208";a="210785404" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Oct 2010 14:24:39 -0400 X-IronPort-AV: E=Sophos;i="4.57,292,1283745600"; d="scan'208";a="523889244" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Oct 2010 14:24:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 6 Oct 2010 14:24:38 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" , Robert Sparks Date: Wed, 6 Oct 2010 14:24:37 -0400 Thread-Topic: Errata report on errata 2268, 839, and 154 Thread-Index: AQHLZYO7WeUXg02rqkuMYfTWN0VlTQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Errata report on errata 2268, 839, and 154 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:23:43 -0000 This is a report on these RFC errata: errata 2268 for RFC 4235 errata 839 for RFC 4240 errata 154 for RFC 4240 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata ID: 2268 RFC4235, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)" Source of RFC: sipping (rai) Status: Reported Type: Technical Reported By: David Grant Date Reported: 2010-05-18 Section 4.2 says: It should say: Notes: The sessd type is a simple type, which allows text content, yet the RFC does not describe what content it should have, so it should be an empty type instead. ---------------------------------------------------------------------- Recommended status: Rejected The description of the session-description element in section 4.1.6.3 is not particularly clear, but it is unambiguous: 4.1.6.3. Session Description Element The session-description element contains the session description used by the observed user for its end of the dialog. This element should generally NOT be included in the notifications, unless it was explicitly requested by the subscriber. It has a single attribute, "type", which indicates the MIME media type of the session description. To avoid repeating session description information in each request, the subscriber can assume that the session description is the same as in previous notifications if no session description element is present in the corresponding local or remote element. Therefore, a typical usage would be: confirmed 274 sip:alice@example.com v=3D0 o=3Dalice 53655765 2353687637 IN IP4 pc33.atlanta.com s=3DSession SDP t=3D0 0 c=3DIN IP4 pc33.atlanta.com m=3Daudio 3456 RTP/AVP 0 1 3 99 a=3Drtpmap:0 PCMU/8000 sip:bob@example.org [SDP sent by remote U= A] That is, has a "type" attribute whose value is the MIME type of the session description, and it has content which is the session description. (Note that both the and elements have their own , as SDP is sent by both UAs. Presumably the of a participant is the SDP that was *sent* by that participant.) Within this understanding, the XML schema language in the RFC is correct. The '' specifies that the content of is a string, and the '' specifies that must have an attribute 'type'. (The situation could have been made much clearer if the RFC included an example of the use of .) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata ID: 839 RFC4240, "Basic Network Media Services with SIP" Source of RFC: IETF - NON WORKING GROUP Area Assignment: rai Status: Reported Type: Technical Reported By: Alfred Hoenes Date Reported: 2006-01-23 [Note that item (1) does not exist. -- DRW] (2) [ minor textual improvement ] In the final paragraph of section 3.3, on mid-page 11, perhaps the words "most anything" should be replaced by "almost anything". (3) [ textual improvement ] The last paragraph on page 12 (within Section 4.1.) apparently contains a plural/singular inconsistency. The text says: vvv vvv The media server presents the parameters as environment variables in the connection object. Specifically, the parameter appears in the connection.sip tree. ^^^ ^^^ It should better say: The media server presents the parameters as environment variables in | the connection object. Specifically, the parameters appear in the connection.sip tree. (4) [ inconsistent terminology ] I suspect that section 5 contains an unintentional inconsistency in the terminology used: The syntax element represented by the 'uniqueIdentifier' part of the example in the 9th line of Section 5 apparently is referred to as the "conf-id value" in various places (once on page 13, 11th text line from the bottom of the page, and 4 occurrences on page 14 (text lines 3, 9, 12, and 13). But in the 'Formal Syntax' Section 5.2., this syntactic element is named "instance-id" (see bottom of page 16). It certainly would be preferrable to always use the same terminology; you should decide which term should be used. (5) [ editorial artifact ] The call flow diagram on page 15 unnecessarily 'overflows' to page 16. The two first text lines on page 16, | | | | | | | | | | do not carry any useful information and might better have been suppressed. (6) [ mismatch between diagram and explanation ] Subsequently, near the top of page 16, the explanation of the call flow diagram on page 15 says: Note that the above call flow does not show any 100 TRYING messages that would typically flow from the Application Server to the UACs; nor does it show the ACKs from the UACs to the Application Server or from the Application Server to the Media Server. The latter is not true; the diagram in fact DOES show these ACKs ! Therefore, this paragraph should be shortened to just say: Note that the above call flow does not show any 100 TRYING messages that would typically flow from the Application Server to the UACs. (7) [ confusion between concrete and abstract parameter names ] In the 'IANA Considerations' Section 6., on page 17, the registered lines mix concrete (real) parameter names (like 'play') with the meta-parameter name 'extension' in a way that might mislead the reader to taking 'extension' as a concrete parameter name as well. >From Section 3.3., it can clearly be seen that this is merely a placeholder for any additional parameter that might be standardized in the future. I'm seriously in doubt whether it is a good idea to register this meta-parameter. Rather, future standards defining concrete instances for the 'extension-param' should register those concrete parameter names. I therefore propose to delete the final line from the list, Parameter Name Predefined Values Reference -------------- ----------------- --------- . . . . . . . . . | extension no RFC 4240 and from the actual IANA registration performed. (8) [ legacy left in text? ] The 3rd paragraph of Section 7, on page 17, says: This document explicitly addresses this issue. The user names described in the text (namely annc, ivr, dialog, and conf) are available for whatever local use a given SIP user agent or proxy wishes for them. [ ... ] The user name, 'ivr', does not appear in the remainder of the text. Admittedly omitting any detailed research, I suspect its occurrence to be an improper left-over from earlier drafts. Thus, this text should say: This document explicitly addresses this issue. The user names | described in the text (namely annc, dialog, and conf) are available for whatever local use a given SIP user agent or proxy wishes for them. [ ... ] It should say: [see above] Notes: from pending ---------------------------------------------------------------------- Recommended status: Verified, hold for document update, except needs correction of IANA registration. (1) [Item (1) does not exist.] (2) correct; hold for document update (3) correct; hold for document update (4) correct; hold for document update (5) correct; hold for document update (6) correct; hold for document update (However, it may be preferable to remote the ACKs from the diagram and not modify the text.) (7) correct In addition, the "parameter name" param[n] is a meta-parameter name for the set param1, param2, param3, param4, param5, param6, param7, param8, and param9, as stated in section 3 of the RFC. In regard to the RFC, this item can be held for document update, but the IANA registry "SIP/SIPS URI Parameters" (in http://www.iana.org/assignments/sip-parameters) should be corrected by: Remove: extension No [RFC4240] param[n] No [RFC4240] Add: param1 No [RFC4240] param2 No [RFC4240] param3 No [RFC4240] param4 No [RFC4240] param5 No [RFC4240] param6 No [RFC4240] param7 No [RFC4240] param8 No [RFC4240] param9 No [RFC4240] (8) correct; hold for document update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata ID: 154 RFC4240, "Basic Network Media Services with SIP" Source of RFC: IETF - NON WORKING GROUP Area Assignment: rai Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2006-01-23 Section 3.3 says: A number of MIME registrations, which could be used here, have parameters, for instance, video/DV. To accommodate this, and retain compatibility with the SIP URI structure, the MIME-type parameter separator (semicolon, %3b) and value separator (equal, %d3) MUST be escaped. For example: ^^^ sip:annc@ms.example.net; \ play=3Dfile://fs.example.net//clips/my-intro.dvi; \ content-type=3Dvideo/mpeg%3bencode%d3314M-25/625-50 It should say: A number of MIME registrations, which could be used here, have parameters, for instance, video/DV. To accommodate this, and retain compatibility with the SIP URI structure, the MIME-type parameter separator (semicolon, %3b) and value separator (equal, %3d) MUST be [ --------------------------------------------------------^^^ -- DRW] escaped. For example: sip:annc@ms.example.net; \ play=3Dfile://fs.example.net//clips/my-intro.dvi; \ content-type=3Dvideo/mpeg%3bencode%3d314M-25/625-50 [ Note this should be marked also:-----^^^ -- DRW] ---------------------------------------------------------------------- Recommended status: Verified, hold for document update The erratum is correct, but the nature of the error will be obvious to the serious reader. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From dworley@avaya.com Wed Oct 6 12:36:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A873A7239 for ; Wed, 6 Oct 2010 12:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWvGBPNGavsu for ; Wed, 6 Oct 2010 12:36:46 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 8AD773A719F for ; Wed, 6 Oct 2010 12:36:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,292,1283745600"; d="scan'208";a="37928052" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 06 Oct 2010 15:37:12 -0400 X-IronPort-AV: E=Sophos;i="4.57,292,1283745600"; d="scan'208";a="523951635" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Oct 2010 15:37:12 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 6 Oct 2010 15:37:11 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" Date: Wed, 6 Oct 2010 15:37:11 -0400 Thread-Topic: [sipcore] About Join and Replaces Headers: //Replaces header's extension Thread-Index: ActldAa3+RC9ddIjQrOuD2DrBUs3NwAGSBk3 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:36:49 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] X -------------------- Y voice/video //Y send voice/video session to X. As Y does not know X support HD video, s= o he send the call from a normal UE. moving to (2): X -------------------- Y | voice | +--------------------- Z HD video //Then, X tell Y that his UE support HD video and want to establish the HD = video stream. Please note that, X tell Y by voice, while not by any signall= ing. //Then, Y use a new equipment(Z) to transfer the video stream from the orig= nal session. The voice stream is still between X and Y. ________________________________________ (BTW, you are using the same symbols for the *users* and the *UAs* here, an= d that creates confusion.) If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the origina= l dialog (between UAs X and Y) *must* be terminated by X when it accepts th= e INVITE-with-Replaces. What UA Z should do is send an INVITE-with-Join to X (offering only video),= and then UA Y should do a re-INVITE to remove its video stream from its di= alog with X (leaving the audio stream). At that point, X is "mixing" two d= ialogs, but each media stream (audio and video) is used by only one leg of = the conference, so X doesn't need to do any actual mixing processing. Dale From pkyzivat@cisco.com Wed Oct 6 14:36:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF5B3A6FB2 for ; Wed, 6 Oct 2010 14:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpGyWYH+9CPH for ; Wed, 6 Oct 2010 14:36:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E64663A6C73 for ; Wed, 6 Oct 2010 14:36:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF2JrExAZnwN/2dsb2JhbACiUXGpZZxAhUcEikCDAg X-IronPort-AV: E=Sophos;i="4.57,293,1283731200"; d="scan'208";a="167597608" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2010 21:37:31 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96LbViv026868; Wed, 6 Oct 2010 21:37:31 GMT Message-ID: <4CACEC1A.1060909@cisco.com> Date: Wed, 06 Oct 2010 17:37:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:36:32 -0000 Why is Y inflicting issues with this equipment on X? This is better resolved by Y working with Z, while doing only ordinary things with X. Specifically, Y can invite Z, and then eventually do a reinvite to X with the mixture of streams from Y and Z that it prefers. Or if Z is smart enough, and Y isn't, I guess Z could do invite/Replaces to both X and Y, and fix things up. It really depends on where the devices with intelligence are located. But counting on X to help, when you don't control X, seems like a bad idea to me. Thanks, Paul On 10/6/2010 3:37 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] > > X -------------------- Y > voice/video > > //Y send voice/video session to X. As Y does not know X support HD video, so he send the call from a normal UE. > > moving to (2): > > X -------------------- Y > | voice > | > +--------------------- Z > HD video > > //Then, X tell Y that his UE support HD video and want to establish the HD video stream. Please note that, X tell Y by voice, while not by any signalling. > > //Then, Y use a new equipment(Z) to transfer the video stream from the orignal session. The voice stream is still between X and Y. > ________________________________________ > > (BTW, you are using the same symbols for the *users* and the *UAs* here, and that creates confusion.) > > If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the original dialog (between UAs X and Y) *must* be terminated by X when it accepts the INVITE-with-Replaces. > > What UA Z should do is send an INVITE-with-Join to X (offering only video), and then UA Y should do a re-INVITE to remove its video stream from its dialog with X (leaving the audio stream). At that point, X is "mixing" two dialogs, but each media stream (audio and video) is used by only one leg of the conference, so X doesn't need to do any actual mixing processing. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gao.yang2@zte.com.cn Thu Oct 7 01:03:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726373A6E0A for ; Thu, 7 Oct 2010 01:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.195 X-Spam-Level: X-Spam-Status: No, score=-100.195 tagged_above=-999 required=5 tests=[AWL=1.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWHvLoYSGFBF for ; Thu, 7 Oct 2010 01:03:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 908833A6DFA for ; Thu, 7 Oct 2010 01:03:48 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 7 Oct 2010 16:03:34 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 79135.1967002180; Thu, 7 Oct 2010 16:02:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9784up6078575; Thu, 7 Oct 2010 16:04:56 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 7 Oct 2010 16:01:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-07 16:04:44, Serialize complete at 2010-10-07 16:04:44 Content-Type: multipart/alternative; boundary="=_alternative 002C3D98482577B5_=" X-MAIL: mse3.zte.com.cn o9784up6078575 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 08:03:50 -0000 This is a multipart message in MIME format. --=_alternative 002C3D98482577B5_= Content-Type: text/plain; charset="US-ASCII" > If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the > original dialog (between UAs X and Y) *must* be terminated by X when > it accepts the INVITE-with-Replaces. I knew it. But my proposal here is to do extension for the Replaces header. And you may refer to the first mail of this thread for details. > What UA Z should do is send an INVITE-with-Join to X I MUST point out that Join header's semantics is not proper for this use case. > (offering only video), By my experience, INVITE-with-Join(only downlink video) *could* be treated as a video duplication request. But how about INVITE-with-Join(only bidirectional video)? In fact, no like audio stream, there's no physical meaning for video streams' mixing. So, if UA Z send an INVITE-with-Join, with only bidirectional video, UA X may not know how to handle it.(So, I feel that RFC3911 need clarification!) > and then UA Y should do a re-INVITE to remove its video > stream from its dialog with X (leaving the audio stream). Let's analyse what would happen after UA Y sending a re-INVITE to remove it's video stream from it's dialog. As the use case of "INVITE-with-Join(only bidirectional video)" is meaning, as I showed in the previous section, we may analyse a similar one: "INVITE-with-Join(only downlink video)" . Not like audio mixing, the session can be downgraded from three-party to two-party, when one leave the session. If the vedio between X and Y is over, I think the duplicated one between X and Z would lose it's vedio source. Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002C3D98482577B5_= Content-Type: text/html; charset="US-ASCII"

> If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the
> original dialog (between UAs X and Y) *must* be terminated by X when
> it accepts the INVITE-with-Replaces.

I knew it. But my proposal here is to do extension for the Replaces header. And you may refer to the first mail of this thread for details.
 
> What UA Z should do is send an INVITE-with-Join to X

I MUST point out that Join header's semantics is not proper for this use case.

> (offering only video),

By my experience, INVITE-with-Join(only downlink video) *could* be treated as a video duplication request. But how about INVITE-with-Join(only bidirectional video)?
In fact, no like audio stream, there's no physical meaning for video streams' mixing. So, if UA Z send an INVITE-with-Join, with only bidirectional video, UA X may not know how to handle it.(So, I feel that RFC3911 need clarification!)

> and then UA Y should do a re-INVITE to remove its video
> stream from its dialog with X (leaving the audio stream).  

Let's analyse what would happen after UA Y sending a re-INVITE to remove it's video stream from it's dialog. As the use case of "INVITE-with-Join(only bidirectional video)" is meaning, as I showed in the previous section, we may analyse a similar one: "INVITE-with-Join(only downlink video)" .

Not like audio mixing, the session can be downgraded from three-party to two-party, when one leave the session. If the vedio between X and Y is over, I think the duplicated one between X and Z would lose it's vedio source.

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002C3D98482577B5_=-- From gao.yang2@zte.com.cn Thu Oct 7 09:26:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE74F3A6F48 for ; Thu, 7 Oct 2010 09:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+7mynmXbUDO for ; Thu, 7 Oct 2010 09:26:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 42D163A6F2A for ; Thu, 7 Oct 2010 09:25:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Fri, 8 Oct 2010 00:24:21 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 79135.1967002180; Fri, 8 Oct 2010 00:24:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o97GR0GJ058532; Fri, 8 Oct 2010 00:27:00 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 00:24:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 00:26:39, Serialize complete at 2010-10-08 00:26:39 Content-Type: multipart/alternative; boundary="=_alternative 005A5442482577B5_=" X-MAIL: mse3.zte.com.cn o97GR0GJ058532 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:26:05 -0000 This is a multipart message in MIME format. --=_alternative 005A5442482577B5_= Content-Type: text/plain; charset="US-ASCII" One spelling mistake and it's correction, inlines(in blue color). Note: Here I talk a lot about RFC3911's potential clarification points. IMO it is more serious problem (than the Replaces header's extension). I request you evaluate it. Gao > If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the > original dialog (between UAs X and Y) *must* be terminated by X when > it accepts the INVITE-with-Replaces. I knew it. But my proposal here is to do extension for the Replaces header. And you may refer to the first mail of this thread for details. > What UA Z should do is send an INVITE-with-Join to X I MUST point out that Join header's semantics is not proper for this use case. > (offering only video), By my experience, INVITE-with-Join(only downlink video) *could* be treated as a video duplication request. But how about INVITE-with-Join(only bidirectional video)? In fact, no like audio stream, there's no physical meaning for video streams' mixing. So, if UA Z send an INVITE-with-Join, with only bidirectional video, UA X may not know how to handle it.(So, I feel that RFC3911 need clarification!) > and then UA Y should do a re-INVITE to remove its video > stream from its dialog with X (leaving the audio stream). Let's analyse what would happen after UA Y sending a re-INVITE to remove it's video stream from it's dialog. As the use case of "INVITE-with-Join(only bidirectional video)" is meaningless, as I showed in the previous section, we may analyse a similar one: "INVITE-with-Join(only downlink video)" . Not like audio mixing, the session can be downgraded from three-party to two-party, when one leave the session. If the vedio between X and Y is over, I think the duplicated one between X and Z would lose it's vedio source. Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005A5442482577B5_= Content-Type: text/html; charset="US-ASCII"
One spelling mistake and it's correction, inlines(in blue color).

Note: Here I talk a lot about RFC3911's potential clarification points. IMO it is more serious problem (than the Replaces header's extension). I request you evaluate it.

Gao

> If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the
> original dialog (between UAs X and Y) *must* be terminated by X when
> it accepts the INVITE-with-Replaces.

I knew it. But my proposal here is to do extension for the Replaces header. And you may refer to the first mail of this thread for details.
 
> What UA Z should do is send an INVITE-with-Join to X

I MUST point out that Join header's semantics is not proper for this use case.

> (offering only video),

By my experience, INVITE-with-Join(only downlink video) *could* be treated as a video duplication request. But how about INVITE-with-Join(only bidirectional video)?
In fact, no like audio stream, there's no physical meaning for video streams' mixing. So, if UA Z send an INVITE-with-Join, with only bidirectional video, UA X may not know how to handle it.(So, I feel that RFC3911 need clarification!)

> and then UA Y should do a re-INVITE to remove its video
> stream from its dialog with X (leaving the audio stream).  

Let's analyse what would happen after UA Y sending a re-INVITE to remove it's video stream from it's dialog. As the use case of "INVITE-with-Join(only bidirectional video)" is meaningless, as I showed in the previous section, we may analyse a similar one: "INVITE-with-Join(only downlink video)" .

Not like audio mixing, the session can be downgraded from three-party to two-party, when one leave the session. If the vedio between X and Y is over, I think the duplicated one between X and Z would lose it's vedio source.

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 005A5442482577B5_=-- From dworley@avaya.com Thu Oct 7 09:30:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7248D3A6F96 for ; Thu, 7 Oct 2010 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y23srzFpYcmx for ; Thu, 7 Oct 2010 09:30:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 561033A6FD0 for ; Thu, 7 Oct 2010 09:30:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,298,1283745600"; d="scan'208";a="241652638" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Oct 2010 12:31:04 -0400 X-IronPort-AV: E=Sophos;i="4.57,298,1283745600"; d="scan'208";a="524305227" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Oct 2010 12:31:04 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 7 Oct 2010 12:31:04 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" Date: Thu, 7 Oct 2010 12:28:45 -0400 Thread-Topic: [sipcore] About Join and Replaces Headers: //Replaces header's extension Thread-Index: Actl9lJLUYQM6tSHQyCjPHMQWci7uAARmO8i Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:30:03 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] > If user Y (using UA Z) sends an INVITE-with-Replaces to X, then the > original dialog (between UAs X and Y) *must* be terminated by X when > it accepts the INVITE-with-Replaces. I knew it. But my proposal here is to do extension for the Replaces header.= And you may refer to the first mail of this thread for details. ________________________________________ You are focusing on the fact that you want to replace the user's connection= to a particular media stream. But the Replaces header specifies whether o= r not a *dialog* is replaced by another *dialog*, not whether a particular = media rendering is replaced by another. The only way that you can associat= e two dialogs while keeping them both in existence is with Join. I think your usage would be helped by adding extension attributes to SDP so= that which media stream was to replace/be mixed with which other media str= eams (in a Join) could be specified. Dale From gao.yang2@zte.com.cn Thu Oct 7 09:40:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204A33A715C for ; Thu, 7 Oct 2010 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.671 X-Spam-Level: X-Spam-Status: No, score=-97.671 tagged_above=-999 required=5 tests=[AWL=-1.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SKXcL1A87a1 for ; Thu, 7 Oct 2010 09:40:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 322BD3A7140 for ; Thu, 7 Oct 2010 09:40:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Fri, 8 Oct 2010 00:38:50 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3772637948; Fri, 8 Oct 2010 00:41:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o97GfUrq061607; Fri, 8 Oct 2010 00:41:30 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CACEC1A.1060909@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 00:39:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 00:41:09, Serialize complete at 2010-10-08 00:41:09 Content-Type: multipart/alternative; boundary="=_alternative 005BA7E3482577B5_=" X-MAIL: mse3.zte.com.cn o97GfUrq061607 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:40:12 -0000 This is a multipart message in MIME format. --=_alternative 005BA7E3482577B5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UGF1bCwNCg0KQ3VycmVudGx5LCBJIGhhdmUgbW9yZSB0aGFuIHdheXMgdG8gc29sdmUgdGhpcyBw cm9ibGVtKHRoZSBSZXBsYWNlcyANCmhlYWRlcidzIGV4dGVuc2lvbiBpcyBqdXN0IG9uZSBjaG9p Y2UpLiBCdXQgbm8gbWF0dGVyIGhvdyB0byBhcnJhbmdlIHRoZSANCnNpZ25hbGxpbmcgZmxvd3Ms IHRoZSBrZXkgaXNzdWUgaGVyZSBpcyBzaG93IHRoZSAicmVwbGFjZSIgc2VtYW50aWNzIGFuZCAN CnJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSByZXBsYWNpbmcgdmVkaW8gc3RyZWFtKHRoZSBuZXcg b25lKSBhbmQgdGhlIA0KcmVwbGFjZWQgdmVkaW8gc3RyZWFtKHRoZSBvcmlnaW5hbCBvbmUpLg0K DQpBbmQgSU1PLCB0aGlzICJyZXBsYWNlIiBzZW1hbnRpY3MgaXMgbm90IGV4aXN0IGluIGFueSBj dXJyZW50IGRlZmluZWQgU0lQIA0KZmVhdHVyZXMsIGV2ZW4gdGhlIFJlcGxhY2VzIGhlYWRlci4g SSB0aGluayB3ZSBtaWdodCB0YWxrIGFib3V0IHRoaXMgDQpiYWNrZ3JvdW5kIGZpcnN0LiBUaGF0 IGlzLCBubyBtYXR0ZXIgaG93IHdlIHNvbHZlIGl0LCB3aGV0aGVyIHdlIG5lZWQgYW55IA0Ka2lu ZCBvZiAqbmV3IGZlYXR1cmVzKiB0byBzb2x2ZSB0aGlzIHVzZSBjYXNlLg0KDQpUaGFua3MsDQoN Ckdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIx MDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCg0Kc2lwY29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0xMC0wNyAwNTozNzoz MDoNCg0KPiBXaHkgaXMgWSBpbmZsaWN0aW5nIGlzc3VlcyB3aXRoIHRoaXMgZXF1aXBtZW50IG9u IFg/IFRoaXMgaXMgYmV0dGVyIA0KPiByZXNvbHZlZCBieSBZIHdvcmtpbmcgd2l0aCBaLCB3aGls ZSBkb2luZyBvbmx5IG9yZGluYXJ5IHRoaW5ncyB3aXRoIFguDQo+IA0KPiBTcGVjaWZpY2FsbHks IFkgY2FuIGludml0ZSBaLCBhbmQgdGhlbiBldmVudHVhbGx5IGRvIGEgcmVpbnZpdGUgdG8gWCAN Cj4gd2l0aCB0aGUgbWl4dHVyZSBvZiBzdHJlYW1zIGZyb20gWSBhbmQgWiB0aGF0IGl0IHByZWZl cnMuDQo+IA0KPiBPciBpZiBaIGlzIHNtYXJ0IGVub3VnaCwgYW5kIFkgaXNuJ3QsIEkgZ3Vlc3Mg WiBjb3VsZCBkbyBpbnZpdGUvUmVwbGFjZXMgDQoNCj4gdG8gYm90aCBYIGFuZCBZLCBhbmQgZml4 IHRoaW5ncyB1cC4NCj4gDQo+IEl0IHJlYWxseSBkZXBlbmRzIG9uIHdoZXJlIHRoZSBkZXZpY2Vz IHdpdGggaW50ZWxsaWdlbmNlIGFyZSBsb2NhdGVkLiANCj4gQnV0IGNvdW50aW5nIG9uIFggdG8g aGVscCwgd2hlbiB5b3UgZG9uJ3QgY29udHJvbCBYLCBzZWVtcyBsaWtlIGEgYmFkIA0KPiBpZGVh IHRvIG1lLg0KPiANCj4gICAgVGhhbmtzLA0KPiAgICBQYXVsDQo+IA0KPiBPbiAxMC82LzIwMTAg MzozNyBQTSwgV29ybGV5LCBEYWxlIFIgKERhbGUpIHdyb3RlOg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGcm9tOiBnYW8ueWFuZzJAenRlLmNvbS5j biBbZ2FvLnlhbmcyQHp0ZS5jb20uY25dDQo+ID4NCj4gPiBYIC0tLS0tLS0tLS0tLS0tLS0tLS0t IFkNCj4gPiAgICAgICAgdm9pY2UvdmlkZW8NCj4gPg0KPiA+IC8vWSBzZW5kIHZvaWNlL3ZpZGVv IHNlc3Npb24gdG8gWC4gQXMgWSBkb2VzIG5vdCBrbm93IFggc3VwcG9ydCBIRA0KPiB2aWRlbywg c28gaGUgc2VuZCB0aGUgY2FsbCBmcm9tIGEgbm9ybWFsIFVFLg0KPiA+DQo+ID4gbW92aW5nIHRv ICgyKToNCj4gPg0KPiA+ICAgIFggLS0tLS0tLS0tLS0tLS0tLS0tLS0gWQ0KPiA+ICAgIHwgICAg ICAgdm9pY2UNCj4gPiAgICB8DQo+ID4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSBaDQo+ID4g ICAgICAgICAgSEQgdmlkZW8NCj4gPg0KPiA+IC8vVGhlbiwgWCB0ZWxsIFkgdGhhdCBoaXMgVUUg c3VwcG9ydCBIRCB2aWRlbyBhbmQgd2FudCB0byANCj4gZXN0YWJsaXNoIHRoZSBIRCB2aWRlbyBz dHJlYW0uIFBsZWFzZSBub3RlIHRoYXQsIFggdGVsbCBZIGJ5IHZvaWNlLCANCj4gd2hpbGUgbm90 IGJ5IGFueSBzaWduYWxsaW5nLg0KPiA+DQo+ID4gLy9UaGVuLCBZIHVzZSBhIG5ldyBlcXVpcG1l bnQoWikgdG8gdHJhbnNmZXIgdGhlIHZpZGVvIHN0cmVhbSBmcm9tDQo+IHRoZSBvcmlnbmFsIHNl c3Npb24uIFRoZSB2b2ljZSBzdHJlYW0gaXMgc3RpbGwgYmV0d2VlbiBYIGFuZCBZLg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IChCVFcsIHlv dSBhcmUgdXNpbmcgdGhlIHNhbWUgc3ltYm9scyBmb3IgdGhlICp1c2VycyogYW5kIHRoZSAqVUFz Kg0KPiBoZXJlLCBhbmQgdGhhdCBjcmVhdGVzIGNvbmZ1c2lvbi4pDQo+ID4NCj4gPiBJZiB1c2Vy IFkgKHVzaW5nIFVBIFopIHNlbmRzIGFuIElOVklURS13aXRoLVJlcGxhY2VzIHRvIFgsIHRoZW4g DQo+IHRoZSBvcmlnaW5hbCBkaWFsb2cgKGJldHdlZW4gVUFzIFggYW5kIFkpICptdXN0KiBiZSB0 ZXJtaW5hdGVkIGJ5IFggDQo+IHdoZW4gaXQgYWNjZXB0cyB0aGUgSU5WSVRFLXdpdGgtUmVwbGFj ZXMuDQo+ID4NCj4gPiBXaGF0IFVBIFogc2hvdWxkIGRvIGlzIHNlbmQgYW4gSU5WSVRFLXdpdGgt Sm9pbiB0byBYIChvZmZlcmluZyANCj4gb25seSB2aWRlbyksIGFuZCB0aGVuIFVBIFkgc2hvdWxk IGRvIGEgcmUtSU5WSVRFIHRvIHJlbW92ZSBpdHMgdmlkZW8NCj4gc3RyZWFtIGZyb20gaXRzIGRp YWxvZyB3aXRoIFggKGxlYXZpbmcgdGhlIGF1ZGlvIHN0cmVhbSkuICBBdCB0aGF0IA0KPiBwb2lu dCwgWCBpcyAibWl4aW5nIiB0d28gZGlhbG9ncywgYnV0IGVhY2ggbWVkaWEgc3RyZWFtIChhdWRp byBhbmQgDQo+IHZpZGVvKSBpcyB1c2VkIGJ5IG9ubHkgb25lIGxlZyBvZiB0aGUgY29uZmVyZW5j ZSwgc28gWCBkb2Vzbid0IG5lZWQgDQo+IHRvIGRvIGFueSBhY3R1YWwgbWl4aW5nIHByb2Nlc3Np bmcuDQo+ID4NCj4gPiBEYWxlDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 005BA7E3482577B5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBhdWwsPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5DdXJyZW50bHksIEkgaGF2ZSBtb3Jl IHRoYW4gd2F5cyB0bw0Kc29sdmUgdGhpcyBwcm9ibGVtKHRoZSBSZXBsYWNlcyBoZWFkZXIncyBl eHRlbnNpb24gaXMganVzdCBvbmUgY2hvaWNlKS4NCkJ1dCBubyBtYXR0ZXIgaG93IHRvIGFycmFu Z2UgdGhlIHNpZ25hbGxpbmcgZmxvd3MsIHRoZSBrZXkgaXNzdWUgaGVyZSBpcw0Kc2hvdyB0aGUg JnF1b3Q7cmVwbGFjZSZxdW90OyBzZW1hbnRpY3MgYW5kIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZSByZXBsYWNpbmcNCnZlZGlvIHN0cmVhbSh0aGUgbmV3IG9uZSkgYW5kIHRoZSByZXBsYWNlZCB2 ZWRpbyBzdHJlYW0odGhlIG9yaWdpbmFsIG9uZSkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgSU1PLCB0aGlzICZxdW90O3JlcGxhY2UmcXVvdDsg c2VtYW50aWNzDQppcyBub3QgZXhpc3QgaW4gYW55IGN1cnJlbnQgZGVmaW5lZCBTSVAgZmVhdHVy ZXMsIGV2ZW4gdGhlIFJlcGxhY2VzIGhlYWRlci4NCkkgdGhpbmsgd2UgbWlnaHQgdGFsayBhYm91 dCB0aGlzIGJhY2tncm91bmQgZmlyc3QuIFRoYXQgaXMsIG5vIG1hdHRlciBob3cNCndlIHNvbHZl IGl0LCB3aGV0aGVyIHdlIG5lZWQgYW55IGtpbmQgb2YgKm5ldyBmZWF0dXJlcyogdG8gc29sdmUg dGhpcyB1c2UNCmNhc2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsg Jm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIg Jm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIw MTAtMTAtMDcgMDU6Mzc6MzA6PGJyPg0KPGJyPg0KJmd0OyBXaHkgaXMgWSBpbmZsaWN0aW5nIGlz c3VlcyB3aXRoIHRoaXMgZXF1aXBtZW50IG9uIFg/IFRoaXMgaXMgYmV0dGVyDQo8YnI+DQomZ3Q7 IHJlc29sdmVkIGJ5IFkgd29ya2luZyB3aXRoIFosIHdoaWxlIGRvaW5nIG9ubHkgb3JkaW5hcnkg dGhpbmdzIHdpdGgNClguPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNwZWNpZmljYWxseSwgWSBjYW4g aW52aXRlIFosIGFuZCB0aGVuIGV2ZW50dWFsbHkgZG8gYSByZWludml0ZSB0bw0KWCA8YnI+DQom Z3Q7IHdpdGggdGhlIG1peHR1cmUgb2Ygc3RyZWFtcyBmcm9tIFkgYW5kIFogdGhhdCBpdCBwcmVm ZXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPciBpZiBaIGlzIHNtYXJ0IGVub3VnaCwgYW5kIFkg aXNuJ3QsIEkgZ3Vlc3MgWiBjb3VsZCBkbyBpbnZpdGUvUmVwbGFjZXMNCjxicj4NCiZndDsgdG8g Ym90aCBYIGFuZCBZLCBhbmQgZml4IHRoaW5ncyB1cC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQg cmVhbGx5IGRlcGVuZHMgb24gd2hlcmUgdGhlIGRldmljZXMgd2l0aCBpbnRlbGxpZ2VuY2UgYXJl IGxvY2F0ZWQuDQo8YnI+DQomZ3Q7IEJ1dCBjb3VudGluZyBvbiBYIHRvIGhlbHAsIHdoZW4geW91 IGRvbid0IGNvbnRyb2wgWCwgc2VlbXMgbGlrZSBhDQpiYWQgPGJyPg0KJmd0OyBpZGVhIHRvIG1l Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhhbmtzLDxicj4NCiZndDsgJm5i c3A7ICZuYnNwO1BhdWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTAvNi8yMDEwIDM6MzcgUE0s IFdvcmxleSwgRGFsZSBSIChEYWxlKSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBGcm9tOiBnYW8ueWFu ZzJAenRlLmNvbS5jbiBbZ2FvLnlhbmcyQHp0ZS5jb20uY25dPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFggLS0tLS0tLS0tLS0tLS0tLS0tLS0gWTxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt2b2ljZS92aWRlbzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAvL1kgc2VuZCB2b2ljZS92aWRlbyBzZXNzaW9uIHRvIFguIEFzIFkgZG9lcyBub3Qga25v dyBYIHN1cHBvcnQNCkhEPGJyPg0KJmd0OyB2aWRlbywgc28gaGUgc2VuZCB0aGUgY2FsbCBmcm9t IGEgbm9ybWFsIFVFLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBtb3ZpbmcgdG8gKDIp Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7WCAtLS0tLS0tLS0t LS0tLS0tLS0tLSBZPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHZvaWNlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFo8YnI+DQomZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hEIHZpZGVvPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IC8vVGhlbiwgWCB0ZWxsIFkgdGhhdCBoaXMgVUUgc3VwcG9ydCBIRCB2aWRl byBhbmQgd2FudCB0byA8YnI+DQomZ3Q7IGVzdGFibGlzaCB0aGUgSEQgdmlkZW8gc3RyZWFtLiBQ bGVhc2Ugbm90ZSB0aGF0LCBYIHRlbGwgWSBieSB2b2ljZSwNCjxicj4NCiZndDsgd2hpbGUgbm90 IGJ5IGFueSBzaWduYWxsaW5nLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAvL1RoZW4s IFkgdXNlIGEgbmV3IGVxdWlwbWVudChaKSB0byB0cmFuc2ZlciB0aGUgdmlkZW8gc3RyZWFtDQpm cm9tPGJyPg0KJmd0OyB0aGUgb3JpZ25hbCBzZXNzaW9uLiBUaGUgdm9pY2Ugc3RyZWFtIGlzIHN0 aWxsIGJldHdlZW4gWCBhbmQgWS48YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAoQlRXLCB5 b3UgYXJlIHVzaW5nIHRoZSBzYW1lIHN5bWJvbHMgZm9yIHRoZSAqdXNlcnMqIGFuZCB0aGUNCipV QXMqPGJyPg0KJmd0OyBoZXJlLCBhbmQgdGhhdCBjcmVhdGVzIGNvbmZ1c2lvbi4pPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElmIHVzZXIgWSAodXNpbmcgVUEgWikgc2VuZHMgYW4gSU5W SVRFLXdpdGgtUmVwbGFjZXMgdG8gWCwgdGhlbg0KPGJyPg0KJmd0OyB0aGUgb3JpZ2luYWwgZGlh bG9nIChiZXR3ZWVuIFVBcyBYIGFuZCBZKSAqbXVzdCogYmUgdGVybWluYXRlZCBieQ0KWCA8YnI+ DQomZ3Q7IHdoZW4gaXQgYWNjZXB0cyB0aGUgSU5WSVRFLXdpdGgtUmVwbGFjZXMuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdoYXQgVUEgWiBzaG91bGQgZG8gaXMgc2VuZCBhbiBJTlZJ VEUtd2l0aC1Kb2luIHRvIFggKG9mZmVyaW5nDQo8YnI+DQomZ3Q7IG9ubHkgdmlkZW8pLCBhbmQg dGhlbiBVQSBZIHNob3VsZCBkbyBhIHJlLUlOVklURSB0byByZW1vdmUgaXRzIHZpZGVvPGJyPg0K Jmd0OyBzdHJlYW0gZnJvbSBpdHMgZGlhbG9nIHdpdGggWCAobGVhdmluZyB0aGUgYXVkaW8gc3Ry ZWFtKS4gJm5ic3A7QXQNCnRoYXQgPGJyPg0KJmd0OyBwb2ludCwgWCBpcyAmcXVvdDttaXhpbmcm cXVvdDsgdHdvIGRpYWxvZ3MsIGJ1dCBlYWNoIG1lZGlhIHN0cmVhbQ0KKGF1ZGlvIGFuZCA8YnI+ DQomZ3Q7IHZpZGVvKSBpcyB1c2VkIGJ5IG9ubHkgb25lIGxlZyBvZiB0aGUgY29uZmVyZW5jZSwg c28gWCBkb2Vzbid0IG5lZWQNCjxicj4NCiZndDsgdG8gZG8gYW55IGFjdHVhbCBtaXhpbmcgcHJv Y2Vzc2luZy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRGFsZTxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyBzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBzaXBjb3JlQGlldGYu b3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNpcGNvcmUgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJy PjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTom bmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFp bCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNp cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw O3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90 Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRl bnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3Ro ZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0 cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZu YnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkm bmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNw O0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWls Jm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNw O29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7 dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5k ZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5i c3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZu YnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 005BA7E3482577B5_=-- From gao.yang2@zte.com.cn Thu Oct 7 09:52:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B3D3A6F90 for ; Thu, 7 Oct 2010 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.26 X-Spam-Level: X-Spam-Status: No, score=-100.26 tagged_above=-999 required=5 tests=[AWL=1.578, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxKnWUBcoaZS for ; Thu, 7 Oct 2010 09:52:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 63ED13A6FA0 for ; Thu, 7 Oct 2010 09:52:52 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Fri, 8 Oct 2010 00:52:39 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 79135.1967002180; Fri, 8 Oct 2010 00:51:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o97GsClH063315; Fri, 8 Oct 2010 00:54:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 00:51:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 00:53:51, Serialize complete at 2010-10-08 00:53:51 Content-Type: multipart/alternative; boundary="=_alternative 005CD1A3482577B5_=" X-MAIL: mse3.zte.com.cn o97GsClH063315 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:52:55 -0000 This is a multipart message in MIME format. --=_alternative 005CD1A3482577B5_= Content-Type: text/plain; charset="US-ASCII" > You are focusing on the fact that you want to replace the user's > connection to a particular media stream. But the Replaces header > specifies whether or not a *dialog* is replaced by another *dialog*, > not whether a particular media rendering is replaced by another. > The only way that you can associate two dialogs while keeping them > both in existence is with Join. Yes. This is the current defintion for Replaces header and Join header. > > I think your usage would be helped by adding extension attributes to > SDP so that which media stream was to replace/be mixed with which > other media streams (in a Join) could be specified. > I once evaluated SDP extension. But the controlling semantics for the use case is about session control, while not session/streams attributes. So, I think the extension should be signalling control oriented, while not SDP(description) oriented. So, I think the potential extension should be located in SIP headers, while not SDP. Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005CD1A3482577B5_= Content-Type: text/html; charset="US-ASCII"

> You are focusing on the fact that you want to replace the user's
> connection to a particular media stream.  But the Replaces header
> specifies whether or not a *dialog* is replaced by another *dialog*,
> not whether a particular media rendering is replaced by another.  
> The only way that you can associate two dialogs while keeping them
> both in existence is with Join.

Yes. This is the current defintion for Replaces header and Join header.

>
> I think your usage would be helped by adding extension attributes to
> SDP so that which media stream was to replace/be mixed with which
> other media streams (in a Join) could be specified.
>

I once evaluated SDP extension. But the controlling semantics for the use case is about session control, while not session/streams attributes. So, I think the extension should be signalling control oriented, while not SDP(description) oriented.

So, I think the potential extension should be located in SIP headers, while not SDP.

Gao

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 005CD1A3482577B5_=-- From pkyzivat@cisco.com Thu Oct 7 11:03:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D38C3A714A for ; Thu, 7 Oct 2010 11:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvBuq4Nw4F-v for ; Thu, 7 Oct 2010 11:03:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E7C9D3A6FD6 for ; Thu, 7 Oct 2010 11:03:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+orUxAZnwN/2dsb2JhbACiRXGvNZxehUcEikCDAg X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="167947790" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Oct 2010 18:04:20 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o97I4K5N027673 for ; Thu, 7 Oct 2010 18:04:20 GMT Message-ID: <4CAE0BA4.1020906@cisco.com> Date: Thu, 07 Oct 2010 14:04:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:03:21 -0000 Gao, Sometimes there is value in strategic vagueness/ambiguity. To date that has been the case with sip around what media are used and what it means when they are used. And its especially the case with Replaces and Join. There is nothing in SIP that says where or how media are rendered. If a device has more than one potential device sip says nothing about which one. (E.g. using the handset or speaker on a speaker phone.) In the case of join, as Dale has said, it is really only about joining the *dialogs*. There is a presumption that this will result in something reasonable happening with the media streams, but its not specified. (An exception to this is, I think, conferencing, which does talk about this to some extent.) Going beyond just letting the UAs do what they think is right is a *big* step. (The conferencing stuff was a lot of work, and I don't know too much about it.) You might consider whether you could use conferencing controls to get the kind of result you want. Otherwise, I think you have a big task and had better investigate if anybody else wants to work on it. Thanks, Paul On 10/7/2010 12:51 PM, gao.yang2@zte.com.cn wrote: > > > > You are focusing on the fact that you want to replace the user's > > connection to a particular media stream. But the Replaces header > > specifies whether or not a *dialog* is replaced by another *dialog*, > > not whether a particular media rendering is replaced by another. > > The only way that you can associate two dialogs while keeping them > > both in existence is with Join. > > Yes. This is the current defintion for Replaces header and Join header. > > > > > I think your usage would be helped by adding extension attributes to > > SDP so that which media stream was to replace/be mixed with which > > other media streams (in a Join) could be specified. > > > > I once evaluated SDP extension. But the controlling semantics for the > use case is about session control, while not session/streams attributes. > So, I think the extension should be signalling control oriented, while > not SDP(description) oriented. > > So, I think the potential extension should be located in SIP headers, > while not SDP. > > Gao > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From iesg-secretary@ietf.org Thu Oct 7 15:00:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287AC3A6E69; Thu, 7 Oct 2010 15:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNqJ2EZZ9JVE; Thu, 7 Oct 2010 15:00:29 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FCF3A6E2C; Thu, 7 Oct 2010 15:00:29 -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 Message-ID: <20101007220029.15483.55557.idtracker@localhost> Date: Thu, 07 Oct 2010 15:00:29 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:00:30 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/ No IPR declarations were found that appear related to this I-D. From gao.yang2@zte.com.cn Thu Oct 7 18:06:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A453A63D3 for ; Thu, 7 Oct 2010 18:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.021 X-Spam-Level: X-Spam-Status: No, score=-100.021 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub2-W99SQMB5 for ; Thu, 7 Oct 2010 18:06:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E288D3A63CB for ; Thu, 7 Oct 2010 18:05:59 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Fri, 8 Oct 2010 09:05:46 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 79135.3533455949; Fri, 8 Oct 2010 09:04:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9815u5F079896; Fri, 8 Oct 2010 09:05:57 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CAE0BA4.1020906@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 09:03:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 09:05:52, Serialize complete at 2010-10-08 09:05:52 Content-Type: multipart/alternative; boundary="=_alternative 000606F2482577B6_=" X-MAIL: mse2.zte.com.cn o9815u5F079896 Cc: sipcore@ietf.org Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:06:02 -0000 This is a multipart message in MIME format. --=_alternative 000606F2482577B6_= Content-Type: text/plain; charset="US-ASCII" Paul, > Going beyond just letting the UAs do what they think is right is a *big* > step. (The conferencing stuff was a lot of work, and I don't know too > much about it.) > > You might consider whether you could use conferencing controls to get > the kind of result you want. Otherwise, I think you have a big task and > had better investigate if anybody else wants to work on it. Yes. I agree that it would be a *big* step, if we want to do such feature enhancement for SIP. To be honest, we have accomplished the conferencing controls way for this use case. But this is a little complex, as there should be a control focus(usually is the conference AS) and the media server. So, I try to find an end to end lightweight solution. As we found out, such e2e feature is not exist now. So, I'd like to know are there other people also interested in this work? Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000606F2482577B6_= Content-Type: text/html; charset="US-ASCII"
Paul,

> Going beyond just letting the UAs do what they think is right is a *big*
> step. (The conferencing stuff was a lot of work, and I don't know too
> much about it.)
>
> You might consider whether you could use conferencing controls to get
> the kind of result you want. Otherwise, I think you have a big task and
> had better investigate if anybody else wants to work on it.

Yes. I agree that it would be a *big* step, if we want to do such feature enhancement for SIP.

To be honest, we have accomplished the conferencing controls way for this use case. But this is a little complex, as there should be a control focus(usually is the conference AS) and the media server. So, I try to find an end to end lightweight solution.

As we found out, such e2e feature is not exist now. So, I'd like to know are there other people also interested in this work?

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000606F2482577B6_=-- From gao.yang2@zte.com.cn Thu Oct 7 18:15:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D47B3A63D3 for ; Thu, 7 Oct 2010 18:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.304 X-Spam-Level: X-Spam-Status: No, score=-100.304 tagged_above=-999 required=5 tests=[AWL=1.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOEGDG3yH7As for ; Thu, 7 Oct 2010 18:15:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id CF3DD3A677C for ; Thu, 7 Oct 2010 18:14:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Fri, 8 Oct 2010 09:13:29 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3772637948; Fri, 8 Oct 2010 09:15:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o981FqIR080797; Fri, 8 Oct 2010 09:15:52 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CAE0BA4.1020906@cisco.com> To: Paul Kyzivat , "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 09:13:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 09:15:47, Serialize complete at 2010-10-08 09:15:47 Content-Type: multipart/alternative; boundary="=_alternative 0006EF87482577B6_=" X-MAIL: mse3.zte.com.cn o981FqIR080797 Cc: sipcore@ietf.org Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:15:18 -0000 This is a multipart message in MIME format. --=_alternative 0006EF87482577B6_= Content-Type: text/plain; charset="US-ASCII" Paul and Dale, In fact, some of our new designed call flows for the IUT(inter-UEs transfering) use the Join header frequently. But I think the semantics of the Join header in a lot of use case is not clear now, as showed in the previous mails. Then, what about my comments on the "RFC3911's potential clarification"? And I think this work is relative urgent for me. Thanks, Gao > Gao, > > Sometimes there is value in strategic vagueness/ambiguity. > To date that has been the case with sip around what media are used and > what it means when they are used. And its especially the case with > Replaces and Join. > > There is nothing in SIP that says where or how media are rendered. If a > device has more than one potential device sip says nothing about which > one. (E.g. using the handset or speaker on a speaker phone.) > > In the case of join, as Dale has said, it is really only about joining > the *dialogs*. There is a presumption that this will result in something > reasonable happening with the media streams, but its not specified. (An > exception to this is, I think, conferencing, which does talk about this > to some extent.) > > Going beyond just letting the UAs do what they think is right is a *big* > step. (The conferencing stuff was a lot of work, and I don't know too > much about it.) > > You might consider whether you could use conferencing controls to get > the kind of result you want. Otherwise, I think you have a big task and > had better investigate if anybody else wants to work on it. > > Thanks, > Paul > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0006EF87482577B6_= Content-Type: text/html; charset="US-ASCII"
Paul and Dale,

In fact, some of our new designed call flows for the IUT(inter-UEs transfering) use the Join header frequently. But I think the semantics of the Join header in a lot of use case is not clear now, as showed in the previous mails.

Then, what about my comments on the "RFC3911's potential clarification"? And I think this work is relative urgent for me.

Thanks,

Gao

> Gao,
>
> Sometimes there is value in strategic vagueness/ambiguity.
> To date that has been the case with sip around what media are used and
> what it means when they are used. And its especially the case with
> Replaces and Join.
>
> There is nothing in SIP that says where or how media are rendered. If a
> device has more than one potential device sip says nothing about which
> one. (E.g. using the handset or speaker on a speaker phone.)
>
> In the case of join, as Dale has said, it is really only about joining
> the *dialogs*. There is a presumption that this will result in something
> reasonable happening with the media streams, but its not specified. (An
> exception to this is, I think, conferencing, which does talk about this
> to some extent.)
>
> Going beyond just letting the UAs do what they think is right is a *big*
> step. (The conferencing stuff was a lot of work, and I don't know too
> much about it.)
>
> You might consider whether you could use conferencing controls to get
> the kind of result you want. Otherwise, I think you have a big task and
> had better investigate if anybody else wants to work on it.
>
>    Thanks,
>    Paul
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0006EF87482577B6_=-- From pkyzivat@cisco.com Thu Oct 7 19:37:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B503A6782 for ; Thu, 7 Oct 2010 19:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.196 X-Spam-Level: X-Spam-Status: No, score=-110.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39OIdPGER-QC for ; Thu, 7 Oct 2010 19:37:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E11253A6774 for ; Thu, 7 Oct 2010 19:37:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFACIhrkxAZnwM/2dsb2JhbACURI1/caF3nEiFRwSKQIMC X-IronPort-AV: E=Sophos;i="4.57,300,1283731200"; d="scan'208";a="168115751" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2010 02:38:14 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o982cE94020196; Fri, 8 Oct 2010 02:38:14 GMT Message-ID: <4CAE8416.4020306@cisco.com> Date: Thu, 07 Oct 2010 22:38:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 02:37:13 -0000 Gao, I still don't understand one aspect here: Is this a case of - a smart device with a limited display wanting to bring in a dumb device with a good display into an existing call? - a smart device with a good diplay wanting to inject its capabilities into an existing call preempting a dumb device with limited capabilities? - something else? If its a smart device with limited display capabilities, I think it can just use 3pcc to control the device with the good display, as a slave media server to itself. In that case I think there are no unsolved issues. Thanks, Paul On 10/7/2010 9:03 PM, gao.yang2@zte.com.cn wrote: > > Paul, > > > Going beyond just letting the UAs do what they think is right is a *big* > > step. (The conferencing stuff was a lot of work, and I don't know too > > much about it.) > > > > You might consider whether you could use conferencing controls to get > > the kind of result you want. Otherwise, I think you have a big task and > > had better investigate if anybody else wants to work on it. > > Yes. I agree that it would be a *big* step, if we want to do such > feature enhancement for SIP. > > To be honest, we have accomplished the conferencing controls way for > this use case. But this is a little complex, as there should be a > control focus(usually is the conference AS) and the media server. So, I > try to find an end to end lightweight solution. > > As we found out, such e2e feature is not exist now. So, I'd like to know > are there other people also interested in this work? > > Thanks, > > Gao > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From gao.yang2@zte.com.cn Thu Oct 7 22:56:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A5B3A682D for ; Thu, 7 Oct 2010 22:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.085 X-Spam-Level: X-Spam-Status: No, score=-100.085 tagged_above=-999 required=5 tests=[AWL=1.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLHP2Nw0-iyg for ; Thu, 7 Oct 2010 22:56:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1279B3A682A for ; Thu, 7 Oct 2010 22:56:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Fri, 8 Oct 2010 13:54:50 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3533455949; Fri, 8 Oct 2010 13:57:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o985vV0A081712; Fri, 8 Oct 2010 13:57:31 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CAE8416.4020306@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 8 Oct 2010 13:55:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-08 13:57:21, Serialize complete at 2010-10-08 13:57:21 Content-Type: multipart/alternative; boundary="=_alternative 0020B6DB482577B6_=" X-MAIL: mse3.zte.com.cn o985vV0A081712 Cc: sipcore@ietf.org Subject: Re: [sipcore] About Join and Replaces Headers: //Replaces header's extension X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 05:56:28 -0000 This is a multipart message in MIME format. --=_alternative 0020B6DB482577B6_= Content-Type: text/plain; charset="US-ASCII" Paul, > I still don't understand one aspect here: > > Is this a case of > - a smart device with a limited display wanting to bring in > a dumb device with a good display into an existing call? > > - a smart device with a good diplay wanting to inject its > capabilities into an existing call preempting a dumb > device with limited capabilities? > Both of the two ways are working for its specific case. While, my intention is to find a more general solution, not depending on the capability of the UA(especially which UA). > > If its a smart device with limited display capabilities, I think it can > just use 3pcc to control the device with the good display, as a slave > media server to itself. In that case I think there are no unsolved issues. Yes, there's no need for extension using this way. But the way itself is not general enough. I'll evaluate do I really need a general way or just a way as you suggested. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0020B6DB482577B6_= Content-Type: text/html; charset="US-ASCII"
Paul,

> I still don't understand one aspect here:
>
> Is this a case of
> - a smart device with a limited display wanting to bring in
>    a dumb device with a good display into an existing call?
>
> - a smart device with a good diplay wanting to inject its
>    capabilities into an existing call preempting a dumb
>    device with limited capabilities?
>

Both of the two ways are working for its specific case.

While, my intention is to find a more general solution, not depending on the capability of the UA(especially which UA).

>
> If its a smart device with limited display capabilities, I think it can
> just use 3pcc to control the device with the good display, as a slave
> media server to itself. In that case I think there are no unsolved issues.

Yes, there's no need for extension using this way. But the way itself is not general enough.
I'll evaluate do I really need a general way or just a way as you suggested.

Thanks,

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0020B6DB482577B6_=-- From rjsparks@nostrum.com Fri Oct 8 07:52:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496373A687E for ; Fri, 8 Oct 2010 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imDcNdHOw2Rl for ; Fri, 8 Oct 2010 07:52:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 997223A68F0 for ; Fri, 8 Oct 2010 07:52:01 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o98EqRYr030887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Oct 2010 09:53:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-13--995262251 Date: Fri, 8 Oct 2010 09:53:02 -0500 Message-Id: <4788C5C9-F1BD-483C-B67B-2CBDF7116BC5@nostrum.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [sipcore] SIPit 27 registration closes in 3 weeks X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:52:03 -0000 --Apple-Mail-13--995262251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Registration for SIPit 27 closes in 3 weeks (October 29).=20 The event will take place November 15th through 19th in Taipei, Taiwan. This SIPit is being hosted by ETSI's Centre for Testing and = Interoperability (CTI) in cooperation with ITRI, Industrial Technology = Research Institute. More details are available at = See you in Taipei! RjS= --Apple-Mail-13--995262251 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Registration for SIPit 27 closes in 3 weeks (October 29). 

The event will take place November 15th through 19th in Taipei, Taiwan.
This SIPit is being hosted by ETSI's Centre for Testing and Interoperability (CTI) in cooperation with ITRI, Industrial Technology Research Institute.
More details are available at <http://www.etsi.org/plugtests/SIPit27/SIPit27.htm>

See you in Taipei!

RjS
--Apple-Mail-13--995262251-- From gao.yang2@zte.com.cn Sat Oct 9 04:14:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9FA3A69DC for ; Sat, 9 Oct 2010 04:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.741 X-Spam-Level: X-Spam-Status: No, score=-97.741 tagged_above=-999 required=5 tests=[AWL=-1.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzdpxPabun2T for ; Sat, 9 Oct 2010 04:14:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 92F4A3A69DA for ; Sat, 9 Oct 2010 04:14:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Sat, 9 Oct 2010 19:13:17 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 18621.3772637948; Sat, 9 Oct 2010 19:13:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o99BFqdI063170; Sat, 9 Oct 2010 19:15:52 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "sipcore@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Sat, 9 Oct 2010 19:13:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-09 19:15:37, Serialize complete at 2010-10-09 19:15:37 Content-Type: multipart/alternative; boundary="=_alternative 003DD70A482577B7_=" X-MAIL: mse3.zte.com.cn o99BFqdI063170 Cc: "Worley, Dale R \(Dale\)" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 11:14:41 -0000 This is a multipart message in MIME format. --=_alternative 003DD70A482577B7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBmaW5kIHNvbWUgdGltZSB0byBsaXN0IHNvbWUgb2YgdGhlIHBvaW50cyAqbWlnaHQqIG5lZWQg Y2xhcmlmaWNhdGlvbi4NCg0KMS4gQXMgd2Uga25vdyBpZiB0aGUgSU5WSVRFIHdpdGggSm9pbidz IHN0cmVhbXMgYXJlIGxlc3MgdGhhbiB0aGUgb3JpZ2luYWwgDQpzZXNzaW9uLCBvbmx5IHRoZSBy ZXF1ZXN0ZWQgc3RyZWFtcyBzaG91bGQgYmUgbWl4eGVkKGlmIHRoZXkgYXJlIHN1aXRhYmxlIA0K Zm9yIG1peHhpbmcsIHN1Y2ggYXMgYXVkaW8sIGluc3RhbnQgbWVzc2FnZSkuIEJ1dCBob3cgYWJv dXQgdGhlIEpvaW4gcGFydHkgDQp0aGVuIHNlbmQgYSBSZS1JTlZJVEUgdG8gYWRkIHN0cmVhbXMs IHdoaWxlIHRoZSBvcmlnaW5hbCBzZXNzaW9uIGhhcyBzdWNoIA0KYWRkZWQgc3RyZWFtcz8gDQov L1BlcnNvbmFsIHZpZXdwb2ludDogVGhlIFVBUyBzaG91bGQgZG8gbWl4IGZvciB0aGUgYWRkZWQg c3RyZWFtcy4gDQoNCjIuIEFuZCBob3cgYWJvdXQgdGhlIGFkZGVkIHN0cmVhbXMoY29uc2lkZXJp bmcgdGhlIFJlLUlOVklURSBjYW4gYmUgc2VudCANCmZyb20gdGhlIEpvaW4gcGFydHksIG9yIGJl dHdlZW4gdGhlIG9yaWdpbmFsIHR3byBwYXJ0aWVzKSBhcmUgbm90IGluIHRoZSANCm9yaWdpbmFs IHNlc3Npb24/IA0KLy9QZXJzb25hbCB2aWV3cG9pbnQ6IFRoZSBVQVMgc2hvdWxkIG5vdCBkbyBt aXggZm9yIHN1Y2ggc3RyZWFtcy4NCk9uZSBuZXcgcXVlc3Rpb246IFRoZW4sIGhvdyB3b3VsZCBi ZSB0aGUgc2lnbmFsbGluZyBvZiB0aGUgcmVxdWVzdCBmb3IgdGhlIA0KbWl4IGZvciBzdWNoIG5l dyBtZWRpYSB0eXBlIHN0cmVhbXM/DQoNCjMuIElmIHRoZSBzdHJlYW0gdHlwZXMgYmV0d2VlbiB0 aGUgSm9pbiBwYXJ0IGFuZCBVQVMgaXMgbW9yZSwgUmUtSU5WSVRFIA0KYmV0d2VlbiB0aGUgb3Jp Z2FubCB0d28gcGFydHkgc2hvdWxkIGFsc28gdHJpZ2dlciBtaXh4aW5nIGZvciB0aGUgYWRkZWQg DQpzdHJlYW1zLCBpZiB0aGUgYWRkZWQgc3RyZWFtcyBhcmUgaW4gdGhlIHN0cmVhbSB0eXBlcyBi ZXR3ZWVuIHRoZSBKb2luIA0KcGFydCBhbmQgVUFTLg0KDQo0LiBIb3cgYWJvdXQgdGhlIHN0cmVh bXMoc3VjaCBhcyB2aWRlbykgd2hpY2ggYXJlIG5vdCBwcm9wZXIgZm9yIG1peHhpbmcsIA0KaWYg dGhlIElOVklURSB3aXRoIEpvaW4gaGFzIHN1Y2ggc3RyZWFtcz8gDQoNCjUuIEZ1cnRoZXIsIGlz IHRoZSBiZWhhdmlvciBmb3IgVUFTIHJlbGF0ZWQgdG8gc3VjaCBzdHJlYW1zJ3MgDQpiaWRpcmVj dGlvbmFsIG9yIHVuaWRpcmVjdGlvbmFsIGF0dHJpYnV0ZXM/IA0KLy9JdCBzZWFtcyB0aGF0IHdl IGhhdmUgYWdyZWVkIHRoaXMgcG9pbnQgZm9yIHZpZGVvLiBCdXQgcG9pbnQgNCY1IHNob3VsZCAN CmJlIG1lZGlhIHR5cGUgc3BlY2lmaWMuDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcy MTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUu Y29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tLS0g16q3osjL ILjf0e8xNDAxOTcvdXNlci96dGVfbHRkIMqxvOQgMjAxMC0xMC0wOSAxODozNiAtLS0tLQ0KDQq4 39HvMTQwMTk3L3VzZXIvenRlX2x0ZA0KMjAxMC0xMC0wNyAwMDoxNA0KDQrK1bz+yMsNCiJXb3Js ZXksIERhbGUgUiAoRGFsZSkiIDxkd29ybGV5QGF2YXlhLmNvbT4NCrOty80NClBhdWwgS3l6aXZh dCA8cGt5eml2YXRAY2lzY28uY29tPiwgInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYu b3JnPg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBBYm91dCBSRkMzOTExKEpvaW4gaGVhZGVyKSdzIHBv dGVudGlhbCBlcnJvcjoNCg0KDQoNCg0KDQoNCkknZCBsaWtlIHRvIGVtcGhhc2l6ZSB0aGF0IEkg YWxzbyB0aGluayB0aGVyZSBzaG91bGQgYmUgbm8gDQpjb25mZXJlbmNlL21peGluZyByZXNvdXJj ZXMgZm9yIHRoZSBzaG93ZWQgdXNlIGNhc2UsIGFzIEkgc2FpZCBpbiB0aGUgDQpwcmV2aW91cyBt YWlsLg0KDQpCdXQgSSB0aGluayB3aGF0IHdlIHNhaWQgd2FzIG5vdCBkZWZpbmVkIGNsZWFybHkg aW4gdGhlIFJGQzM5MTEuIEFuZCBJIA0KYWxzbyB0aGluayBpdCBpcyBoYXJkbHkgdG8gZG8gYW55 IGRlZHVjdGlvbiB0byBnZXQgdGhlIHJ1bGVzIHdlIGRpc2N1c3NlZC4NCg0KU28sIGl0IGlzIG5v dCBhIHF1ZXN0aW9uIGxpa2UgImhvdyBzaG91bGQgaXQgYmU/IiwgYnV0IGEgcXVlc3Rpb24gbGlr ZSANCiJ3aGVyZSBpcyBpdCBkZWZpbmVkIi4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4 NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiV29y bGV5LCBEYWxlIFIgKERhbGUpIiA8ZHdvcmxleUBhdmF5YS5jb20+IA0Kt6K8/sjLOiAgc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTEwLTAxIDA0OjIzDQoNCsrVvP7Iyw0KUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBjaXNjby5jb20+LCAiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIA0KPGdhby55 YW5nMkB6dGUuY29tLmNuPg0Ks63LzQ0KInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYu b3JnPg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBBYm91dCBSRkMzOTExKEpvaW4gaGVhZGVyKSdzIHBv dGVudGlhbCBlcnJvcjoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbc2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpQYXVsIEt5eml2YXQgW3BreXppdmF0QGNpc2Nv LmNvbV0NCg0KSSB0aGluayB0aGUgd29ya3MgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgYWxyZWFk eSBhcmUgY29uc2lzdGVudCB3aXRoDQp0aGUgc2NlbmFyaW8geW91IHJhaXNlLiBTcGVjaWZpY2Fs bHksDQoNCj4gYW5kIGFzc2lnbiBhbnkgbWl4aW5nIG9yIGNvbmZlcmVuY2luZyByZXNvdXJjZXMg bmVjZXNzYXJ5IHRvIGNvbXBsZXRlIA0KdGhlIGpvaW4NCg0KaW5jbHVkZXMgdGhlIGNhc2Ugd2hl cmUgbm8gbWl4aW5nIG9yIGNvbmZlcmVuY2luZyByZXNvdXJjZXMgYXJlIG5lY2Vzc2FyeS4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkkgdGhpbmsg dGhhdCBQYXVsIGlzIGNvcnJlY3QgaGVyZS4gIElmIHR3byBkaWFsb2dzIGdvIHRvIGEgc2VydmVy IGFuZCBhcmUgDQpqb2luZWQgYXQgdGhlIHNlcnZlciwgYW5kIGJvdGggZGlhbG9ncyBhcmUgc2Vu ZG9ubHkgYXQgdGhlIHNlcnZlciwgdGhlbiANCiJtaXhpbmciIGlzIHZlcnkgc2ltcGxlOiB0aGUg b25lIHNvdXJjZSAoZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIpIGlzIA0KZHVwbGljYXRlZCBhcyBS VFAgdG8gZWFjaCBkaWFsb2cncyByZW1vdGUgZW5kLg0KDQpJbiBwcmFjdGljZSwgb25lIG1pZ2h0 IHNheSB0aGF0IHRoaXMgImRvZXMgbm90IGFsbG9jYXRlIG1peGluZyByZXNvdXJjZXMiLiANCiBP VE9ILCBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbnMsIHRoaXMgZHVwbGljYXRpb24gb2YgdGhlIG1l ZGlhIHN0cmVhbSBtYXkgDQpyZXF1aXJlIHRoZSBhbGxvY2F0aW9uIG9mIGEgbWl4aW5nIHJlc291 cmNlLCBpZiBubyBvdGhlciBjb21wb25lbnQgb2YgdGhlIA0Kc2VydmVyIGNhbiBwZXJmb3JtIHRo ZSBkdXBsaWNhdGlvbi4NCg0KSSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBwcm9ibGVtIHRoYXQgbmVl ZHMgdG8gYmUgc29sdmVkLg0KDQpEYWxlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3Rl bS4NCg== --=_alternative 003DD70A482577B7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZmluZCBzb21lIHRpbWUgdG8g bGlzdCBzb21lIG9mIHRoZQ0KcG9pbnRzICptaWdodCogbmVlZCBjbGFyaWZpY2F0aW9uLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gQXMgd2Uga25v dyBpZiB0aGUgSU5WSVRFIHdpdGggSm9pbidzDQpzdHJlYW1zIGFyZSBsZXNzIHRoYW4gdGhlIG9y aWdpbmFsIHNlc3Npb24sIG9ubHkgdGhlIHJlcXVlc3RlZCBzdHJlYW1zDQpzaG91bGQgYmUgbWl4 eGVkKGlmIHRoZXkgYXJlIHN1aXRhYmxlIGZvciBtaXh4aW5nLCBzdWNoIGFzIGF1ZGlvLCBpbnN0 YW50DQptZXNzYWdlKS4gQnV0IGhvdyBhYm91dCB0aGUgSm9pbiBwYXJ0eSB0aGVuIHNlbmQgYSBS ZS1JTlZJVEUgdG8gYWRkIHN0cmVhbXMsDQp3aGlsZSB0aGUgb3JpZ2luYWwgc2Vzc2lvbiBoYXMg c3VjaCBhZGRlZCBzdHJlYW1zPyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPi8vUGVyc29uYWwgdmlld3BvaW50OiBUaGUgVUFTIHNob3VsZA0KZG8gbWl4IGZvciB0 aGUgYWRkZWQgc3RyZWFtcy4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4yLiBBbmQgaG93IGFib3V0IHRoZSBhZGRlZCBzdHJlYW1zKGNvbnNpZGVyaW5n DQp0aGUgUmUtSU5WSVRFIGNhbiBiZSBzZW50IGZyb20gdGhlIEpvaW4gcGFydHksIG9yIGJldHdl ZW4gdGhlIG9yaWdpbmFsDQp0d28gcGFydGllcykgYXJlIG5vdCBpbiB0aGUgb3JpZ2luYWwgc2Vz c2lvbj8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vL1BlcnNv bmFsIHZpZXdwb2ludDogVGhlIFVBUyBzaG91bGQNCm5vdCBkbyBtaXggZm9yIHN1Y2ggc3RyZWFt cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9uZSBuZXcgcXVl c3Rpb246IFRoZW4sIGhvdyB3b3VsZCBiZQ0KdGhlIHNpZ25hbGxpbmcgb2YgdGhlIHJlcXVlc3Qg Zm9yIHRoZSBtaXggZm9yIHN1Y2ggbmV3IG1lZGlhIHR5cGUgc3RyZWFtcz88L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuIElmIHRoZSBzdHJlYW0gdHlw ZXMgYmV0d2VlbiB0aGUgSm9pbg0KcGFydCBhbmQgVUFTIGlzIG1vcmUsIFJlLUlOVklURSBiZXR3 ZWVuIHRoZSBvcmlnYW5sIHR3byBwYXJ0eSBzaG91bGQgYWxzbw0KdHJpZ2dlciBtaXh4aW5nIGZv ciB0aGUgYWRkZWQgc3RyZWFtcywgaWYgdGhlIGFkZGVkIHN0cmVhbXMgYXJlIGluIHRoZQ0Kc3Ry ZWFtIHR5cGVzIGJldHdlZW4gdGhlIEpvaW4gcGFydCBhbmQgVUFTLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NC4gSG93IGFib3V0IHRoZSBzdHJlYW1z KHN1Y2ggYXMgdmlkZW8pDQp3aGljaCBhcmUgbm90IHByb3BlciBmb3IgbWl4eGluZywgaWYgdGhl IElOVklURSB3aXRoIEpvaW4gaGFzIHN1Y2ggc3RyZWFtcz8NCjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NS4gRnVydGhlciwgaXMgdGhlIGJlaGF2aW9y IGZvciBVQVMNCnJlbGF0ZWQgdG8gc3VjaCBzdHJlYW1zJ3MgYmlkaXJlY3Rpb25hbCBvciB1bmlk aXJlY3Rpb25hbCBhdHRyaWJ1dGVzPyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPi8vSXQgc2VhbXMgdGhhdCB3ZSBoYXZlIGFncmVlZCB0aGlzDQpwb2lu dCBmb3IgdmlkZW8uIEJ1dCBwb2ludCA0JmFtcDs1IHNob3VsZCBiZSBtZWRpYSB0eXBlIHNwZWNp ZmljLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhh bmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2Fv PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEw MDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4 NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0xIGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0g16q3osjLILjf0e8xNDAx OTcvdXNlci96dGVfbHRkDQrKsbzkIDIwMTAtMTAtMDkgMTg6MzYgLS0tLS08L2ZvbnQ+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+uN/R7zE0MDE5Ny91c2VyL3p0ZV9sdGQ8L2I+ PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMTAtMDcgMDA6 MTQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7V29ybGV5LCBEYWxlIFIgKERhbGUpJnF1b3Q7ICZsdDtkd29ybGV5QGF2YXlhLmNv bSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28u Y29tJmd0OywNCiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5v cmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIEFib3V0IFJGQzM5MTEoSm9p biBoZWFkZXIpJ3MNCnBvdGVudGlhbCBlcnJvcjo8L2ZvbnQ+PGEgaHJlZj1Ob3RlczovL05KTUFJ TDAxLzQ4MjU3MTY5MDAyREY4RUUvREFCQTk3NUI5RkIxMTNFQjg1MjU2NEI1MDAxMjgzRUEvQjc5 OTk1QTg0OTE1MDg3NDQ4MjU3N0FFMDA3MDQ2QUQ+wbS90zwvYT48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JJ2QgbGlrZSB0 byBlbXBoYXNpemUgdGhhdCBJIGFsc28gdGhpbmsNCnRoZXJlIHNob3VsZCBiZSBubyBjb25mZXJl bmNlL21peGluZyA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5yZXNvdXJjZXMNCjwvZm9udD48L3R0 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5mb3IgdGhlIHNob3dlZCB1c2UgY2FzZSwg YXMNCkkgc2FpZCBpbiB0aGUgcHJldmlvdXMgbWFpbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBJIHRoaW5rIHdoYXQgd2Ugc2FpZCB3YXMgbm90 IGRlZmluZWQNCmNsZWFybHkgaW4gdGhlIFJGQzM5MTEuIEFuZCBJIGFsc28gdGhpbmsgaXQgaXMg aGFyZGx5IHRvIGRvIGFueSBkZWR1Y3Rpb24NCnRvIGdldCB0aGUgcnVsZXMgd2UgZGlzY3Vzc2Vk LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28sIGl0 IGlzIG5vdCBhIHF1ZXN0aW9uIGxpa2UgJnF1b3Q7aG93DQpzaG91bGQgaXQgYmU/JnF1b3Q7LCBi dXQgYSBxdWVzdGlvbiBsaWtlICZxdW90O3doZXJlIGlzIGl0IGRlZmluZWQmcXVvdDsuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQog VGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4 NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtXb3JsZXksIERhbGUgUiAoRGFsZSkmcXVvdDsN CiZsdDtkd29ybGV5QGF2YXlhLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0xMC0wMSAwNDoy MzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5QYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDssDQomcXVvdDtnYW8ueWFu ZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBBYm91dCBSRkMzOTExKEpv aW4gaGVhZGVyKSdzDQpwb3RlbnRpYWwgZXJyb3I6PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KUGF1bCBLeXppdmF0IFtwa3l6aXZh dEBjaXNjby5jb21dPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgd29ya3MgeW91IGFyZSBjb25jZXJu ZWQgYWJvdXQgYWxyZWFkeSBhcmUgY29uc2lzdGVudCB3aXRoPGJyPg0KdGhlIHNjZW5hcmlvIHlv dSByYWlzZS4gU3BlY2lmaWNhbGx5LDxicj4NCjxicj4NCiZndDsgYW5kIGFzc2lnbiBhbnkgbWl4 aW5nIG9yIGNvbmZlcmVuY2luZyByZXNvdXJjZXMgbmVjZXNzYXJ5IHRvIGNvbXBsZXRlDQp0aGUg am9pbjxicj4NCjxicj4NCmluY2x1ZGVzIHRoZSBjYXNlIHdoZXJlIG5vIG1peGluZyBvciBjb25m ZXJlbmNpbmcgcmVzb3VyY2VzIGFyZSBuZWNlc3NhcnkuPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgUGF1 bCBpcyBjb3JyZWN0IGhlcmUuICZuYnNwO0lmIHR3byBkaWFsb2dzIGdvIHRvIGEgc2VydmVyDQph bmQgYXJlIGpvaW5lZCBhdCB0aGUgc2VydmVyLCBhbmQgYm90aCBkaWFsb2dzIGFyZSBzZW5kb25s eSBhdCB0aGUgc2VydmVyLA0KdGhlbiAmcXVvdDttaXhpbmcmcXVvdDsgaXMgdmVyeSBzaW1wbGU6 IHRoZSBvbmUgc291cmNlIChnZW5lcmF0ZWQgYnkgdGhlDQpzZXJ2ZXIpIGlzIGR1cGxpY2F0ZWQg YXMgUlRQIHRvIGVhY2ggZGlhbG9nJ3MgcmVtb3RlIGVuZC48YnI+DQo8YnI+DQpJbiBwcmFjdGlj ZSwgb25lIG1pZ2h0IHNheSB0aGF0IHRoaXMgJnF1b3Q7ZG9lcyBub3QgYWxsb2NhdGUgbWl4aW5n IHJlc291cmNlcyZxdW90Oy4NCiZuYnNwO09UT0gsIGZvciBzb21lIGltcGxlbWVudGF0aW9ucywg dGhpcyBkdXBsaWNhdGlvbiBvZiB0aGUgbWVkaWEgc3RyZWFtDQptYXkgcmVxdWlyZSB0aGUgYWxs b2NhdGlvbiBvZiBhIG1peGluZyByZXNvdXJjZSwgaWYgbm8gb3RoZXIgY29tcG9uZW50DQpvZiB0 aGUgc2VydmVyIGNhbiBwZXJmb3JtIHRoZSBkdXBsaWNhdGlvbi48YnI+DQo8YnI+DQpJIGRvIG5v dCBzZWUgdGhpcyBhcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBzb2x2ZWQuPGJyPg0KPGJy Pg0KRGFsZTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPGJyPg0K PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 003DD70A482577B7_=-- From pkyzivat@cisco.com Sat Oct 9 09:04:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4833A68D8 for ; Sat, 9 Oct 2010 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.657 X-Spam-Level: X-Spam-Status: No, score=-108.657 tagged_above=-999 required=5 tests=[AWL=-1.708, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM3N5C05Okc5 for ; Sat, 9 Oct 2010 09:04:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0F4673A686A for ; Sat, 9 Oct 2010 09:04:42 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIovsExAZnwM/2dsb2JhbACDH58lcZ5MihMIkg+BHoMxeASENYYLgwI X-IronPort-AV: E=Sophos;i="4.57,308,1283731200"; d="scan'208";a="168645486" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2010 16:05:50 +0000 Received: from [10.86.254.238] ([10.86.254.238]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o99G5nRs002046; Sat, 9 Oct 2010 16:05:49 GMT Message-ID: <4CB092DD.5080307@cisco.com> Date: Sat, 09 Oct 2010 12:05:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 16:04:45 -0000 IMO all the things you mention *are* and *should be* out of scope for sip, at least in general. They all seem to be in the category of defining services and features on top of sip. If you want that then there should be some additional negotiation of such services/features. Thanks, Paul On 10/9/2010 7:13 AM, gao.yang2@zte.com.cn wrote: > > I find some time to list some of the points *might* need clarification. > > 1. As we know if the INVITE with Join's streams are less than the > original session, only the requested streams should be mixxed(if they > are suitable for mixxing, such as audio, instant message). But how about > the Join party then send a Re-INVITE to add streams, while the original > session has such added streams? > //Personal viewpoint: The UAS should do mix for the added streams. > > 2. And how about the added streams(considering the Re-INVITE can be sent > from the Join party, or between the original two parties) are not in the > original session? > //Personal viewpoint: The UAS should not do mix for such streams. > One new question: Then, how would be the signalling of the request for > the mix for such new media type streams? > > 3. If the stream types between the Join part and UAS is more, Re-INVITE > between the origanl two party should also trigger mixxing for the added > streams, if the added streams are in the stream types between the Join > part and UAS. > > 4. How about the streams(such as video) which are not proper for > mixxing, if the INVITE with Join has such streams? > > 5. Further, is the behavior for UAS related to such streams's > bidirectional or unidirectional attributes? > //It seams that we have agreed this point for video. But point 4&5 > should be media type specific. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > ----- ת·¢ÈË ¸ßÑï140197/user/zte_ltd ʱ¼ä 2010-10-09 18:36 ----- > *¸ßÑï140197/user/zte_ltd* > > 2010-10-07 00:14 > > > ÊÕ¼þÈË > "Worley, Dale R (Dale)" > ³­ËÍ > Paul Kyzivat , "sipcore@ietf.org" > Ö÷Ìâ > Re: [sipcore] About RFC3911(Join header)'s potential error:Á´½Ó > > > > > > > > > > I'd like to emphasize that I also think there should be no > conference/mixing resources for the showed use case, as I said in the > previous mail. > > But I think what we said was not defined clearly in the RFC3911. And I > also think it is hardly to do any deduction to get the rules we discussed. > > So, it is not a question like "how should it be?", but a question like > "where is it defined". > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *"Worley, Dale R (Dale)" * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-10-01 04:23 > > > ÊÕ¼þÈË > Paul Kyzivat , "gao.yang2@zte.com.cn" > > ³­ËÍ > "sipcore@ietf.org" > Ö÷Ìâ > Re: [sipcore] About RFC3911(Join header)'s potential error: > > > > > > > > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of > Paul Kyzivat [pkyzivat@cisco.com] > > I think the works you are concerned about already are consistent with > the scenario you raise. Specifically, > > > and assign any mixing or conferencing resources necessary to complete > the join > > includes the case where no mixing or conferencing resources are necessary. > _______________________________________________ > > I think that Paul is correct here. If two dialogs go to a server and are > joined at the server, and both dialogs are sendonly at the server, then > "mixing" is very simple: the one source (generated by the server) is > duplicated as RTP to each dialog's remote end. > > In practice, one might say that this "does not allocate mixing > resources". OTOH, for some implementations, this duplication of the > media stream may require the allocation of a mixing resource, if no > other component of the server can perform the duplication. > > I do not see this as a problem that needs to be solved. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From gao.yang2@zte.com.cn Sun Oct 10 17:54:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916A13A6874 for ; Sun, 10 Oct 2010 17:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.366 X-Spam-Level: X-Spam-Status: No, score=-100.366 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ64E6EmxAyu for ; Sun, 10 Oct 2010 17:54:57 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id ADCE93A67B8 for ; Sun, 10 Oct 2010 17:54:56 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Mon, 11 Oct 2010 08:54:50 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 18621.3772637948; Mon, 11 Oct 2010 08:53:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9B0tpmq041843; Mon, 11 Oct 2010 08:55:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CB092DD.5080307@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 11 Oct 2010 08:53:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-11 08:55:45, Serialize complete at 2010-10-11 08:55:45 Content-Type: multipart/alternative; boundary="=_alternative 0005190B482577B9_=" X-MAIL: mse2.zte.com.cn o9B0tpmq041843 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 00:54:58 -0000 This is a multipart message in MIME format. --=_alternative 0005190B482577B9_= Content-Type: text/plain; charset="US-ASCII" Paul, > IMO all the things you mention *are* and *should be* out of scope for > sip, at least in general. > > They all seem to be in the category of defining services and features on > top of sip. If you want that then there should be some additional > negotiation of such services/features. That's ture. It is services and features on top of the sip. But Join header itself is this kind of services and features on top of the sip. While it had not been clearly defined then, I guess there unclear points should be clarified. Meanwhile, which WG is the proper one for this kind of work? As Join header is not demanded for all SIP UA, so it seams that it is not proper to be defined in SIPCore. Could you give me some suggestion, Dispatch? Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0005190B482577B9_= Content-Type: text/html; charset="US-ASCII"
Paul,

> IMO all the things you mention *are* and *should be* out of scope for
> sip, at least in general.
>
> They all seem to be in the category of defining services and features on
> top of sip. If you want that then there should be some additional
> negotiation of such services/features.
That's ture. It is services and features on top of the sip.
But Join header itself is this kind of services and features on top of the sip. While it had not been clearly defined then, I guess there unclear points should be clarified.

Meanwhile, which WG is the proper one for this kind of work? As Join header is not demanded for all SIP UA, so it seams that it is not proper to be defined in SIPCore. Could you give me some suggestion, Dispatch?

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0005190B482577B9_=-- From gao.yang2@zte.com.cn Sun Oct 10 20:33:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F59E3A68B2 for ; Sun, 10 Oct 2010 20:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.468 X-Spam-Level: X-Spam-Status: No, score=-100.468 tagged_above=-999 required=5 tests=[AWL=1.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdTfr9eIexR2 for ; Sun, 10 Oct 2010 20:33:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C39AC3A63C9 for ; Sun, 10 Oct 2010 20:33:40 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Mon, 11 Oct 2010 11:33:15 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3533455949; Mon, 11 Oct 2010 11:34:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9B3YpFQ071949; Mon, 11 Oct 2010 11:34:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 11 Oct 2010 11:32:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-11 11:34:43, Serialize complete at 2010-10-11 11:34:43 Content-Type: multipart/alternative; boundary="=_alternative 0013A6B4482577B9_=" X-MAIL: mse3.zte.com.cn o9B3YpFQ071949 Cc: "sipcore@ietf.org" Subject: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 03:33:43 -0000 This is a multipart message in MIME format. --=_alternative 0013A6B4482577B9_= Content-Type: text/plain; charset="US-ASCII" Paul, By RFC3911, only INVITE is allowed to have the Join header. But I considered the use case, such as A want ask B to Join a current session, there might be the requirement for the Join header in REFER request. How do you think about it? Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0013A6B4482577B9_= Content-Type: text/html; charset="US-ASCII"
Paul,

By RFC3911, only INVITE is allowed to have the Join header. But I considered the use case, such as A want ask B to Join a current session, there might be the requirement for the Join header in REFER request. How do you think about it?

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0013A6B4482577B9_=-- From bcampen@estacado.net Mon Oct 11 10:42:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89AF3A6B34 for ; Mon, 11 Oct 2010 10:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTwoDHMDG+X0 for ; Mon, 11 Oct 2010 10:42:07 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C80DF3A6824 for ; Mon, 11 Oct 2010 10:42:04 -0700 (PDT) Received: from dn3-100.estacado.net (dn3-100.estacado.net [172.16.3.100]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9BHh7cL028024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Oct 2010 12:43:07 -0500 (CDT) (envelope-from bcampen@estacado.net) From: Byron Campen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 12:43:07 -0500 Message-Id: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> To: Paul Kyzivat , shinji.okumura@softfront.jp, Gonzalo Camarillo , "Christer Holmberg (JO/LMF)" , gao.yang2@zte.com.cn Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: SIPCORE Subject: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 17:42:10 -0000 Sending to the authors of the offeranswer and reinvite drafts, = since I am not sure which bucket this would fall in: Consider the following. In all cases, this is within a reINVITE = transaction, after an offer/answer exchange has completed using 100rel = (which kind is not important), that is being rejected by the server side = due to some unspecified error: A B |<---------| INVITE/500 | | | | UPDATE (offer) |--------->| | | |<---------| UPDATE/200 (answer) A B UPDATE (offer) |---\ /---| INVITE/500 | \/ | | /\ | |<--/ \-->| | | |<---------| UPDATE/200 (answer) A B | /-| INVITE/500 | / | UPDATE (offer) |------/-->| | / | |<---/-----| UPDATE/200 (answer) | / | |<-/ | All of these look identical to B; UPDATE offer/answer completes = after the end of the INVITE transaction. However, A sees them very = differently. B cannot know that something unusual has happened. Also = consider the following cases: A B UPDATE (offer) |--------->| | | |<---------| UPDATE/200 (answer) | | |<---------| INVITE/500 A B UPDATE (offer) |--------->| | | | /--| UPDATE/200 (answer) | / | |<----/----| INVITE/500 | / | |<--/ | Again, these look the same to B, but different to A. What is the = best approach to ensuring that session-state is consistent on both ends = in all of these cases? It seems to me that one way would be to specify = that rollback of a reINVITE does not invalidate session-state = established with an UPDATE, regardless of whether that UPDATE = transaction occurred (or appeared to have occurred) during the reINVITE = transaction. If we insist that session-state established with an = in-reINVITE UPDATE be rolled back (the current language says that both = sides must roll back to the session-state in use prior to the reINVITE), = then there is no way to ensure consistent rollback on both ends, even if = everything has the same rollback logic, because what appears to be an = in-reINVITE UPDATE on one end may appear to be after the reINVITE = transaction on the other end. If any portion of the UPDATE transaction = appeared to have happened within the reINVITE transaction, then the = observing UA must send a subsequent UPDATE to re-sync (since there is no = guarantee that the other end saw the UPDATE within the reINVITE = transaction). This is likely to cause glare, unless we put asymmetric = timers on the re-sync, and even then there will be a delay similar to = that caused by glare. My gut says that it would be better to not rollback = session-state established by an UPDATE, under any circumstances. But, = there may be situations where the session-state established in an UPDATE = is contingent on the reINVITE succeeding it. Would it be appropriate to = say that if a UA "feels" this way, it is responsible for re-syncing? Or = is there something I am missing here? Best regards, Byron Campen From dworley@avaya.com Mon Oct 11 13:17:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F703A6B7D for ; Mon, 11 Oct 2010 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBXPm+eb454X for ; Mon, 11 Oct 2010 13:17:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 56B073A6B7A for ; Mon, 11 Oct 2010 13:17:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,316,1283745600"; d="scan'208";a="242196991" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Oct 2010 16:17:09 -0400 X-IronPort-AV: E=Sophos;i="4.57,316,1283745600"; d="scan'208";a="521680631" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Oct 2010 16:17:09 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 11 Oct 2010 16:17:08 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" , Paul Kyzivat Date: Mon, 11 Oct 2010 16:14:31 -0400 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: Acto9UvnlosH/Q8/QDGZ4uUaAq3R9AAi528n Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:17:28 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of gao.= yang2@zte.com.cn [gao.yang2@zte.com.cn] By RFC3911, only INVITE is allowed to have the Join header. But I considere= d the use case, such as A want ask B to Join a current session, there might= be the requirement for the Join header in REFER request. How do you think = about it? ________________________________________ You do not use the Join header in the REFER request itself. However, the R= efer-To URI will have a 'header' specifying that the INVITE to be generated= will have a Join header: REFER sip:aaa SIP/2.0 Refer-To: sip:bbb?Join=3Dccc The recipient of this REFER will generate an INVITE: INVITE sip:bbb SIP/2.0 Join: ccc Dale From dworley@avaya.com Mon Oct 11 13:25:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1FC3A6B82 for ; Mon, 11 Oct 2010 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL72fEDAnkLZ for ; Mon, 11 Oct 2010 13:25:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 94ABA3A6B80 for ; Mon, 11 Oct 2010 13:25:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,316,1283745600"; d="scan'208";a="242198002" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Oct 2010 16:23:44 -0400 X-IronPort-AV: E=Sophos;i="4.57,316,1283745600"; d="scan'208";a="525467565" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Oct 2010 16:19:55 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 11 Oct 2010 16:19:55 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Date: Mon, 11 Oct 2010 16:17:26 -0400 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //some points Thread-Index: Actno1MhQBxxgzpvRbmXUSNtfoclHQB3f7xF Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:25:03 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] 4. How about the streams(such as video) which are not proper for mixxing, i= f the INVITE with Join has such streams? ________________________________________ It is not clear that video is not proper for mixing. For example, if UA A = is the join-point, and it is receiving 3 video streams (one generated by UA= A, one incoming from UA B, and one incoming from UA C), it can "mix" the s= treams from A and B by embedding their frames in a larger frame, and send t= he combined video frames to UA C. Many videoconferencing systems work this= way - each participant sees a single video stream containing small images = of each other participants. Dale From gao.yang2@zte.com.cn Mon Oct 11 17:37:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953613A6BAF; Mon, 11 Oct 2010 17:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.08 X-Spam-Level: X-Spam-Status: No, score=-100.08 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTik15vprSYC; Mon, 11 Oct 2010 17:37:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6DA443A6863; Mon, 11 Oct 2010 17:37:10 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952001811080; Tue, 12 Oct 2010 08:35:53 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 18621.4046628847; Tue, 12 Oct 2010 08:35:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9C0cBNF025582; Tue, 12 Oct 2010 08:38:11 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 08:36:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 08:38:06, Serialize complete at 2010-10-12 08:38:06 Content-Type: multipart/alternative; boundary="=_alternative 00037B05482577BA_=" X-MAIL: mse2.zte.com.cn o9C0cBNF025582 Cc: "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 00:37:20 -0000 This is a multipart message in MIME format. --=_alternative 00037B05482577BA_= Content-Type: text/plain; charset="US-ASCII" > You do not use the Join header in the REFER request itself. > However, the Refer-To URI will have a 'header' specifying that the > INVITE to be generated will have a Join header: > > REFER sip:aaa SIP/2.0 > Refer-To: sip:bbb?Join=ccc > > The recipient of this REFER will generate an INVITE: > > INVITE sip:bbb SIP/2.0 > Join: ccc This is similar to Replaces semantics in REFER(Refer-To) as defined in RFC3515 as: Refer-To: But I really did not see any normative defintion for Join semantics in REFER(Refer-To). If you saw it, please tell me the RFCs and relating sections. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00037B05482577BA_= Content-Type: text/html; charset="US-ASCII"

> You do not use the Join header in the REFER request itself.  
> However, the Refer-To URI will have a 'header' specifying that the
> INVITE to be generated will have a Join header:
>
> REFER sip:aaa SIP/2.0
> Refer-To:  sip:bbb?Join=ccc
>
> The recipient of this REFER will generate an INVITE:
>
> INVITE sip:bbb SIP/2.0
> Join: ccc
This is similar to Replaces semantics in REFER(Refer-To) as defined in RFC3515 as:

Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
          to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

But I really did not see any normative defintion for Join semantics in REFER(Refer-To). If you saw it, please tell me the RFCs and relating sections.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00037B05482577BA_=-- From gao.yang2@zte.com.cn Mon Oct 11 18:04:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3F83A6BB2 for ; Mon, 11 Oct 2010 18:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.337 X-Spam-Level: X-Spam-Status: No, score=-99.337 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylaEbxML+UWe for ; Mon, 11 Oct 2010 18:04:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 346213A6BAE for ; Mon, 11 Oct 2010 18:04:25 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Tue, 12 Oct 2010 09:04:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.1967002180; Tue, 12 Oct 2010 09:05:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9C13Z3J045217; Tue, 12 Oct 2010 09:03:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 09:01:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 09:03:31, Serialize complete at 2010-10-12 09:03:31 Content-Type: multipart/alternative; boundary="=_alternative 0005CE58482577BA_=" X-MAIL: mse2.zte.com.cn o9C13Z3J045217 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //some points X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 01:04:28 -0000 This is a multipart message in MIME format. --=_alternative 0005CE58482577BA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PiA0LiBIb3cgYWJvdXQgdGhlIHN0cmVhbXMoc3VjaCBhcyB2aWRlbykgd2hpY2ggYXJlIG5vdCBw cm9wZXIgZm9yIA0KPiBtaXh4aW5nLCBpZiB0aGUgSU5WSVRFIHdpdGggSm9pbiBoYXMgc3VjaCBz dHJlYW1zPw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0K PiBJdCBpcyBub3QgY2xlYXIgdGhhdCB2aWRlbyBpcyBub3QgcHJvcGVyIGZvciBtaXhpbmcuICBG b3IgZXhhbXBsZSwgDQo+IGlmIFVBIEEgaXMgdGhlIGpvaW4tcG9pbnQsIGFuZCBpdCBpcyByZWNl aXZpbmcgMyB2aWRlbyBzdHJlYW1zIChvbmUgDQo+IGdlbmVyYXRlZCBieSBVQSBBLCBvbmUgaW5j b21pbmcgZnJvbSBVQSBCLCBhbmQgb25lIGluY29taW5nIGZyb20gVUEgDQo+IEMpLCBpdCBjYW4g Im1peCIgdGhlIHN0cmVhbXMgZnJvbSBBIGFuZCBCIGJ5IGVtYmVkZGluZyB0aGVpciBmcmFtZXMg DQo+IGluIGEgbGFyZ2VyIGZyYW1lLCBhbmQgc2VuZCB0aGUgY29tYmluZWQgdmlkZW8gZnJhbWVz IHRvIFVBIEMuICBNYW55DQo+IHZpZGVvY29uZmVyZW5jaW5nIHN5c3RlbXMgd29yayB0aGlzIHdh eSAtIGVhY2ggcGFydGljaXBhbnQgc2VlcyBhIA0KPiBzaW5nbGUgdmlkZW8gc3RyZWFtIGNvbnRh aW5pbmcgc21hbGwgaW1hZ2VzIG9mIGVhY2ggb3RoZXIgcGFydGljaXBhbnRzLg0KPiANCg0KSSBn dWVzcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGxheW91dCBmZWF0dXJlcyBmb3IgdmlkZW8g Y29uZmVyZW5jZSANCnN5c3RlbXMuIEJ1dCBpdCdzIGNvbnRyb2wgc2VtYW50aWNzIGlzICBtb3Jl IGNvbXBsZXggdGhhbiB0aGUgIkpvaW4gDQpoZWFkZXIiKHN1Y2ggYXMgaG93IGxheW91dCwgdGhl IHNpemUsIHdoaWNoIG9uZSBpcyB0aGUgbWFpbiB3aW5kb3ejvykuIElmIA0Kd2Ugd2FudCB0byB1 c2UgIkpvaW4gaGVhZGVyIiBhcyB0aGUgdHJpZ2dlcmluZyBmb3IgdGhlIGxheW91dCBvZiB2aWRl byANCmNvbmZlcmVuY2UsIHRoZSAiSm9pbiBoZWFkZXIiIGl0c2VsZiBuZWVkIGV4dGVuc2lvbiBm b3IgbGF5b3V0IGZlYXR1cmVzLiANCkRvIHlvdSB0aGluayBzbz8NCg0KVGhhbmtzLA0KDQpHYW8N Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 0005CE58482577BA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDQuIEhvdyBhYm91dCB0aGUgc3RyZWFt cyhzdWNoIGFzIHZpZGVvKSB3aGljaCBhcmUgbm90IHByb3BlciBmb3IgPGJyPg0KJmd0OyBtaXh4 aW5nLCBpZiB0aGUgSU5WSVRFIHdpdGggSm9pbiBoYXMgc3VjaCBzdHJlYW1zPzxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgPGJyPg0K Jmd0OyBJdCBpcyBub3QgY2xlYXIgdGhhdCB2aWRlbyBpcyBub3QgcHJvcGVyIGZvciBtaXhpbmcu ICZuYnNwO0ZvciBleGFtcGxlLA0KPGJyPg0KJmd0OyBpZiBVQSBBIGlzIHRoZSBqb2luLXBvaW50 LCBhbmQgaXQgaXMgcmVjZWl2aW5nIDMgdmlkZW8gc3RyZWFtcyAob25lDQo8YnI+DQomZ3Q7IGdl bmVyYXRlZCBieSBVQSBBLCBvbmUgaW5jb21pbmcgZnJvbSBVQSBCLCBhbmQgb25lIGluY29taW5n IGZyb20gVUENCjxicj4NCiZndDsgQyksIGl0IGNhbiAmcXVvdDttaXgmcXVvdDsgdGhlIHN0cmVh bXMgZnJvbSBBIGFuZCBCIGJ5IGVtYmVkZGluZyB0aGVpcg0KZnJhbWVzIDxicj4NCiZndDsgaW4g YSBsYXJnZXIgZnJhbWUsIGFuZCBzZW5kIHRoZSBjb21iaW5lZCB2aWRlbyBmcmFtZXMgdG8gVUEg Qy4gJm5ic3A7TWFueTxicj4NCiZndDsgdmlkZW9jb25mZXJlbmNpbmcgc3lzdGVtcyB3b3JrIHRo aXMgd2F5IC0gZWFjaCBwYXJ0aWNpcGFudCBzZWVzIGENCjxicj4NCiZndDsgc2luZ2xlIHZpZGVv IHN0cmVhbSBjb250YWluaW5nIHNtYWxsIGltYWdlcyBvZiBlYWNoIG90aGVyIHBhcnRpY2lwYW50 cy48YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBn dWVzcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGxheW91dCBmZWF0dXJlcw0KZm9yIHZpZGVv IGNvbmZlcmVuY2Ugc3lzdGVtcy4gQnV0IGl0J3MgY29udHJvbCBzZW1hbnRpY3MgaXMgJm5ic3A7 bW9yZQ0KY29tcGxleCB0aGFuIHRoZSAmcXVvdDtKb2luIGhlYWRlciZxdW90OyhzdWNoIGFzIGhv dyBsYXlvdXQsIHRoZSBzaXplLA0Kd2hpY2ggb25lIGlzIHRoZSBtYWluIHdpbmRvd6O/KS4gSWYg d2Ugd2FudCB0byB1c2UgJnF1b3Q7Sm9pbiBoZWFkZXImcXVvdDsNCmFzIHRoZSB0cmlnZ2VyaW5n IGZvciB0aGUgbGF5b3V0IG9mIHZpZGVvIGNvbmZlcmVuY2UsIHRoZSAmcXVvdDtKb2luIGhlYWRl ciZxdW90Ow0KaXRzZWxmIG5lZWQgZXh0ZW5zaW9uIGZvciBsYXlvdXQgZmVhdHVyZXMuIERvIHlv dSB0aGluayBzbz88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoYW5r cyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhbzwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZu YnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5 Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtU aGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlh bC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29i bGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7 YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3Ro ZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7 ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2Nv bmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3Im bmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRk cmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZu YnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5i c3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDti eSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0005CE58482577BA_=-- From gao.yang2@zte.com.cn Tue Oct 12 01:53:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0373A6783 for ; Tue, 12 Oct 2010 01:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.102 X-Spam-Level: X-Spam-Status: No, score=-97.102 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZBTO9K5+QJh for ; Tue, 12 Oct 2010 01:53:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D1E473A67DB for ; Tue, 12 Oct 2010 01:53:26 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Tue, 12 Oct 2010 16:51:36 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.1967002180; Tue, 12 Oct 2010 16:54:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9C8rObj051176; Tue, 12 Oct 2010 16:53:44 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 16:51:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 16:53:31, Serialize complete at 2010-10-12 16:53:31 Content-Type: multipart/alternative; boundary="=_alternative 0030D4DF482577BA_=" X-MAIL: mse3.zte.com.cn o9C8rObj051176 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 08:53:30 -0000 This is a multipart message in MIME format. --=_alternative 0030D4DF482577BA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGFsZSwNCg0KSSdkIGxpa2UgdG8gZW1waGFzaXplIHRoYXQgdGhlIGluc3RydWN0aW9uIG9mIHRo ZSB3aGljaCBtZWRpYSBzdHJlYW1zIA0Kc2hvdWxkIGJlIGluIHRoZSBJTlZJVEVfd2l0aF9Kb2lu IGZyb20gdGhlIFJlZmVyLUJ5IHBhcnR5IHRvIHRoZSBSZWZlci1UbyANCnBhcnR5IGlzIHF1aXQg aW1wb3J0YW50Lg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDoo Kzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLS0tINeqt6LIyyC439HvMTQwMTk3L3Vz ZXIvenRlX2x0ZCDKsbzkIDIwMTAtMTAtMTIgMTY6NDEgLS0tLS0NCg0KuN/R7zE0MDE5Ny91c2Vy L3p0ZV9sdGQNCjIwMTAtMTAtMTIgMDg6MzYNCg0KytW8/sjLDQoiV29ybGV5LCBEYWxlIFIgKERh bGUpIiA8ZHdvcmxleUBhdmF5YS5jb20+DQqzrcvNDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNp c2NvLmNvbT4sICJzaXBjb3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4sIA0Kc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnDQrW98ziDQpSZTogW3NpcGNvcmVdIEFib3V0IFJGQzM5MTEoSm9p biBoZWFkZXIpJ3MgcG90ZW50aWFsIGVycm9yOiAvL0pvaW4gaGVhZGVyIA0KaW4gUkVGRVI/DQoN Cg0KDQoNCg0KDQo+IFlvdSBkbyBub3QgdXNlIHRoZSBKb2luIGhlYWRlciBpbiB0aGUgUkVGRVIg cmVxdWVzdCBpdHNlbGYuIA0KPiBIb3dldmVyLCB0aGUgUmVmZXItVG8gVVJJIHdpbGwgaGF2ZSBh ICdoZWFkZXInIHNwZWNpZnlpbmcgdGhhdCB0aGUgDQo+IElOVklURSB0byBiZSBnZW5lcmF0ZWQg d2lsbCBoYXZlIGEgSm9pbiBoZWFkZXI6DQo+IA0KPiBSRUZFUiBzaXA6YWFhIFNJUC8yLjANCj4g UmVmZXItVG86ICBzaXA6YmJiP0pvaW49Y2NjDQo+IA0KPiBUaGUgcmVjaXBpZW50IG9mIHRoaXMg UkVGRVIgd2lsbCBnZW5lcmF0ZSBhbiBJTlZJVEU6DQo+IA0KPiBJTlZJVEUgc2lwOmJiYiBTSVAv Mi4wDQo+IEpvaW46IGNjYw0KDQpUaGlzIGlzIHNpbWlsYXIgdG8gUmVwbGFjZXMgc2VtYW50aWNz IGluIFJFRkVSKFJlZmVyLVRvKSBhcyBkZWZpbmVkIGluIA0KUkZDMzUxNSBhczoNCg0KUmVmZXIt VG86IDxzaXA6ZGF2ZUBkZW52ZXIuZXhhbXBsZS5vcmc/UmVwbGFjZXM9MTIzNDUlNDAxOTIuMTY4 LjExOC4zJTNCDQogICAgICAgICAgdG8tdGFnJTNEMTIzNDUlM0Jmcm9tLXRhZyUzRDVGRkUtMzk5 ND4NCg0KQnV0IEkgcmVhbGx5IGRpZCBub3Qgc2VlIGFueSBub3JtYXRpdmUgZGVmaW50aW9uIGZv ciBKb2luIHNlbWFudGljcyBpbiANClJFRkVSKFJlZmVyLVRvKS4gSWYgeW91IHNhdyBpdCwgcGxl YXNlIHRlbGwgbWUgdGhlIFJGQ3MgYW5kIHJlbGF0aW5nIA0Kc2VjdGlvbnMuDQoNClRoYW5rcywN Cg0KR2FvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0030D4DF482577BA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRhbGUsPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JJ2QgbGlrZSB0byBlbXBoYXNpemUg dGhhdCB0aGUgaW5zdHJ1Y3Rpb24NCm9mIHRoZSB3aGljaCBtZWRpYSBzdHJlYW1zIHNob3VsZCBi ZSBpbiB0aGUgSU5WSVRFX3dpdGhfSm9pbiBmcm9tIHRoZSBSZWZlci1CeQ0KcGFydHkgdG8gdGhl IFJlZmVyLVRvIHBhcnR5IGlzIHF1aXQgaW1wb3J0YW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fu cy1zZXJpZiI+LS0tLS0g16q3osjLILjf0e8xNDAxOTcvdXNlci96dGVfbHRkDQrKsbzkIDIwMTAt MTAtMTIgMTY6NDEgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+uN/R7zE0MDE5Ny91c2VyL3p0ZV9sdGQ8L2I+PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTAtMTAtMTIgMDg6MzY8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7V29ybGV5LCBEYWxlIFIgKERh bGUpJnF1b3Q7ICZsdDtkd29ybGV5QGF2YXlhLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBh dWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OywNCiZxdW90O3NpcGNvcmVAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7LCBzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gQWJvdXQgUkZDMzkxMShKb2lu IGhlYWRlcikncw0KcG90ZW50aWFsIGVycm9yOiAvL0pvaW4gaGVhZGVyIGluIFJFRkVSPzwvZm9u dD48YSBocmVmPU5vdGVzOi8vTkpNQUlMMDEvNDgyNTcxNjkwMDJERjhFRS9EQUJBOTc1QjlGQjEx M0VCODUyNTY0QjUwMDEyODNFQS83NzEzN0RBNzhGQTlGM0QxNDgyNTc3QjkwMDZGOTQzOD7BtL3T PC9hPjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQom Z3Q7IFlvdSBkbyBub3QgdXNlIHRoZSBKb2luIGhlYWRlciBpbiB0aGUgUkVGRVIgcmVxdWVzdCBp dHNlbGYuICZuYnNwOzxicj4NCiZndDsgSG93ZXZlciwgdGhlIFJlZmVyLVRvIFVSSSB3aWxsIGhh dmUgYSAnaGVhZGVyJyBzcGVjaWZ5aW5nIHRoYXQgdGhlDQo8YnI+DQomZ3Q7IElOVklURSB0byBi ZSBnZW5lcmF0ZWQgd2lsbCBoYXZlIGEgSm9pbiBoZWFkZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFJFRkVSIHNpcDphYWEgU0lQLzIuMDxicj4NCiZndDsgUmVmZXItVG86ICZuYnNwO3NpcDpiYmI/ Sm9pbj1jY2M8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHJlY2lwaWVudCBvZiB0aGlzIFJFRkVS IHdpbGwgZ2VuZXJhdGUgYW4gSU5WSVRFOjxicj4NCiZndDsgPGJyPg0KJmd0OyBJTlZJVEUgc2lw OmJiYiBTSVAvMi4wPGJyPg0KJmd0OyBKb2luOiBjY2M8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPlRoaXMgaXMgc2ltaWxhciB0byBSZXBsYWNlcyBzZW1hbnRpY3MgaW4g UkVGRVIoUmVmZXItVG8pDQphcyBkZWZpbmVkIGluIFJGQzM1MTUgYXM6PC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5SZWZlci1UbzogJmx0O3Np cDpkYXZlQGRlbnZlci5leGFtcGxlLm9yZz9SZXBsYWNlcz0xMjM0NSU0MDE5Mi4xNjguMTE4LjMl M0I8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp0by10YWclM0QxMjM0NSUzQmZyb20tdGFnJTNENUZG RS0zOTk0Jmd0OzwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkJ1dCBJIHJlYWxs eSBkaWQgbm90IHNlZSBhbnkgbm9ybWF0aXZlIGRlZmludGlvbiBmb3INCkpvaW4gc2VtYW50aWNz IGluIFJFRkVSKFJlZmVyLVRvKS4gSWYgeW91IHNhdyBpdCwgcGxlYXNlIHRlbGwgbWUgdGhlIFJG Q3MNCmFuZCByZWxhdGluZyBzZWN0aW9ucy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPlRoYW5rcyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkdhbzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24m bmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVs eSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2Fu aXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZu YnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZu YnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5 Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5k Jm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZu YnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29s ZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRp dmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5i c3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Jl Y2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFz ZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZu YnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZu YnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwv cHJlPg== --=_alternative 0030D4DF482577BA_=-- From gao.yang2@zte.com.cn Tue Oct 12 02:25:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B943A67C2 for ; Tue, 12 Oct 2010 02:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.518 X-Spam-Level: X-Spam-Status: No, score=-100.518 tagged_above=-999 required=5 tests=[AWL=1.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp6vav9hAtdm for ; Tue, 12 Oct 2010 02:25:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BC7763A6784 for ; Tue, 12 Oct 2010 02:25:29 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Tue, 12 Oct 2010 17:25:24 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.9612350554; Tue, 12 Oct 2010 17:26:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9C9QglA003770; Tue, 12 Oct 2010 17:26:45 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> To: Byron Campen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 17:24:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 17:26:31, Serialize complete at 2010-10-12 17:26:31 Content-Type: multipart/alternative; boundary="=_alternative 0033DB87482577BA_=" X-MAIL: mse3.zte.com.cn o9C9QglA003770 Cc: shinji.okumura@softfront.jp, SIPCORE Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 09:25:31 -0000 This is a multipart message in MIME format. --=_alternative 0033DB87482577BA_= Content-Type: text/plain; charset="US-ASCII" Hi Byron Campen, Before getting into the details, I'd like to check does the "INVITE/500" just means the 5xx of INVITE? Thanks, Gao > Sending to the authors of the offeranswer and reinvite drafts, > since I am not sure which bucket this would fall in: > > Consider the following. In all cases, this is within a reINVITE > transaction, after an offer/answer exchange has completed using > 100rel (which kind is not important), that is being rejected by the > server side due to some unspecified error: > > A B > |<---------| INVITE/500 > | | > | | > UPDATE (offer) |--------->| > | | > |<---------| UPDATE/200 (answer) > > A B > UPDATE (offer) |---\ /---| INVITE/500 > | \/ | > | /\ | > |<--/ \-->| > | | > |<---------| UPDATE/200 (answer) > > A B > | /-| INVITE/500 > | / | > UPDATE (offer) |------/-->| > | / | > |<---/-----| UPDATE/200 (answer) > | / | > |<-/ | > > All of these look identical to B; UPDATE offer/answer completes > after the end of the INVITE transaction. However, A sees them very > differently. B cannot know that something unusual has happened. Also > consider the following cases: > > A B > UPDATE (offer) |--------->| > | | > |<---------| UPDATE/200 (answer) > | | > |<---------| INVITE/500 > > A B > UPDATE (offer) |--------->| > | | > | /--| UPDATE/200 (answer) > | / | > |<----/----| INVITE/500 > | / | > |<--/ | > > Again, these look the same to B, but different to A. What is the > best approach to ensuring that session-state is consistent on both > ends in all of these cases? It seems to me that one way would be to > specify that rollback of a reINVITE does not invalidate session- > state established with an UPDATE, regardless of whether that UPDATE > transaction occurred (or appeared to have occurred) during the > reINVITE transaction. If we insist that session-state established > with an in-reINVITE UPDATE be rolled back (the current language says > that both sides must roll back to the session-state in use prior to > the reINVITE), then there is no way to ensure consistent rollback on > both ends, even if everything has the same rollback logic, because > what appears to be an in-reINVITE UPDATE on one end may appear to be > after the reINVITE transaction on the other end. If any portion of > the UPDATE transaction appeared to have happened within the reINVITE > transaction, then the observing UA must send a sub > sequent UPDATE to re-sync (since there is no guarantee that the > other end saw the UPDATE within the reINVITE transaction). This is > likely to cause glare, unless we put asymmetric timers on the re- > sync, and even then there will be a delay similar to that caused by glare. > > My gut says that it would be better to not rollback session-state > established by an UPDATE, under any circumstances. But, there may be > situations where the session-state established in an UPDATE is > contingent on the reINVITE succeeding it. Would it be appropriate to > say that if a UA "feels" this way, it is responsible for re-syncing? > Or is there something I am missing here? > > Best regards, > Byron Campen > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0033DB87482577BA_= Content-Type: text/html; charset="US-ASCII"
Hi Byron Campen,

Before getting into the details, I'd like to check does the "INVITE/500" just means the 5xx of INVITE?

Thanks,

Gao

>    Sending to the authors of the offeranswer and reinvite drafts,
> since I am not sure which bucket this would fall in:
>
>    Consider the following. In all cases, this is within a reINVITE
> transaction, after an offer/answer exchange has completed using
> 100rel (which kind is not important), that is being rejected by the
> server side due to some unspecified error:
>
>                  A          B
>                  |<---------| INVITE/500
>                  |          |
>                  |          |
>   UPDATE (offer) |--------->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>
>                  A          B
>   UPDATE (offer) |---\  /---| INVITE/500
>                  |    \/    |
>                  |    /\    |
>                  |<--/  \-->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>
>                  A          B
>                  |        /-| INVITE/500
>                  |       /  |
>   UPDATE (offer) |------/-->|
>                  |     /    |
>                  |<---/-----| UPDATE/200 (answer)
>                  |   /      |
>                  |<-/       |
>
>    All of these look identical to B; UPDATE offer/answer completes
> after the end of the INVITE transaction. However, A sees them very
> differently. B cannot know that something unusual has happened. Also
> consider the following cases:
>
>                  A          B
>   UPDATE (offer) |--------->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>                  |          |
>                  |<---------| INVITE/500
>
>                  A          B
>   UPDATE (offer) |--------->|
>                  |          |
>                  |       /--| UPDATE/200 (answer)
>                  |      /   |
>                  |<----/----| INVITE/500
>                  |    /     |
>                  |<--/      |
>
>    Again, these look the same to B, but different to A. What is the
> best approach to ensuring that session-state is consistent on both
> ends in all of these cases? It seems to me that one way would be to
> specify that rollback of a reINVITE does not invalidate session-
> state established with an UPDATE, regardless of whether that UPDATE
> transaction occurred (or appeared to have occurred) during the
> reINVITE transaction. If we insist that session-state established
> with an in-reINVITE UPDATE be rolled back (the current language says
> that both sides must roll back to the session-state in use prior to
> the reINVITE), then there is no way to ensure consistent rollback on
> both ends, even if everything has the same rollback logic, because
> what appears to be an in-reINVITE UPDATE on one end may appear to be
> after the reINVITE transaction on the other end. If any portion of
> the UPDATE transaction appeared to have happened within the reINVITE
> transaction, then the observing UA must send a sub
>  sequent UPDATE to re-sync (since there is no guarantee that the
> other end saw the UPDATE within the reINVITE transaction). This is
> likely to cause glare, unless we put asymmetric timers on the re-
> sync, and even then there will be a delay similar to that caused by glare.
>
>    My gut says that it would be better to not rollback session-state
> established by an UPDATE, under any circumstances. But, there may be
> situations where the session-state established in an UPDATE is
> contingent on the reINVITE succeeding it. Would it be appropriate to
> say that if a UA "feels" this way, it is responsible for re-syncing?
> Or is there something I am missing here?
>
> Best regards,
> Byron Campen
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0033DB87482577BA_=-- From pkyzivat@cisco.com Tue Oct 12 05:50:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456CB3A696C; Tue, 12 Oct 2010 05:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.196 X-Spam-Level: X-Spam-Status: No, score=-110.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL+JqJSXx6a8; Tue, 12 Oct 2010 05:50:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2E6983A6969; Tue, 12 Oct 2010 05:50:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAFb2s0xAZnwN/2dsb2JhbACTU419caAcnHCFSASKQYMD X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="169531973" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2010 12:51:28 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9CCpSUs016846; Tue, 12 Oct 2010 12:51:28 GMT Message-ID: <4CB459CF.2000407@cisco.com> Date: Tue, 12 Oct 2010 08:51:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:50:15 -0000 On 10/11/2010 8:36 PM, gao.yang2@zte.com.cn wrote: > > > > You do not use the Join header in the REFER request itself. > > However, the Refer-To URI will have a 'header' specifying that the > > INVITE to be generated will have a Join header: > > > > REFER sip:aaa SIP/2.0 > > Refer-To: sip:bbb?Join=ccc > > > > The recipient of this REFER will generate an INVITE: > > > > INVITE sip:bbb SIP/2.0 > > Join: ccc > > This is similar to Replaces semantics in REFER(Refer-To) as defined in > RFC3515 as: > > Refer-To: to-tag%3D12345%3Bfrom-tag%3D5FFE-3994> > > But I really did not see any normative defintion for Join semantics in > REFER(Refer-To). If you saw it, please tell me the RFCs and relating > sections. Its because there are none. The semantics of Join apply to INVITE. If you use a REFER, with a Refer-To URI that has an embedded Join header, then the resulting INVITE will have a Join header. That's all. Thanks, Paul From gao.yang2@zte.com.cn Tue Oct 12 06:11:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEFB3A697A; Tue, 12 Oct 2010 06:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.024 X-Spam-Level: X-Spam-Status: No, score=-100.024 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLr--qxdIBjy; Tue, 12 Oct 2010 06:11:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 0A2E83A6961; Tue, 12 Oct 2010 06:11:40 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952001811080; Tue, 12 Oct 2010 21:10:26 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38058.4046628847; Tue, 12 Oct 2010 21:10:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9CDD5vZ088988; Tue, 12 Oct 2010 21:13:06 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CB459CF.2000407@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 21:10:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 21:12:46, Serialize complete at 2010-10-12 21:12:46 Content-Type: multipart/alternative; boundary="=_alternative 0048925C482577BA_=" X-MAIL: mse2.zte.com.cn o9CDD5vZ088988 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:11:52 -0000 This is a multipart message in MIME format. --=_alternative 0048925C482577BA_= Content-Type: text/plain; charset="US-ASCII" > > But I really did not see any normative defintion for Join semantics in > > REFER(Refer-To). If you saw it, please tell me the RFCs and relating > > sections. > > Its because there are none. > > The semantics of Join apply to INVITE. > > If you use a REFER, with a Refer-To URI that has an embedded Join > header, then the resulting INVITE will have a Join header. That's all. OK. And I admit that it's working in pure audio systems. But there's still two questions behind it: 1. Is this way(with a Refer-To URI that has an embedded Join header) normative? I admit that it looks like normative. But our system met interworking issue about this way. 2. Is this way has enough expression? Please refer to my comments in the previous mail: "the instruction of the which media streams should be in the INVITE_with_Join from the Refer-By party to the Refer-To party" It is quit important. And after I evaluated the second point, I doubt the first point more. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0048925C482577BA_= Content-Type: text/html; charset="US-ASCII"

> > But I really did not see any normative defintion for Join semantics in
> > REFER(Refer-To). If you saw it, please tell me the RFCs and relating
> > sections.
>
> Its because there are none.
>
> The semantics of Join apply to INVITE.
>
> If you use a REFER, with a Refer-To URI that has an embedded Join
> header, then the resulting INVITE will have a Join header. That's all.
OK. And I admit that it's working in pure audio systems.

But there's still two questions behind it:

1. Is this way(with a Refer-To URI that has an embedded Join header) normative?
I admit that it looks like normative. But our system met interworking issue about this way.

2. Is this way has enough expression?
Please refer to my comments in the previous mail:
"the instruction of the which media streams should be in the INVITE_with_Join from the Refer-By party to the Refer-To party"
It is quit important.
And after I evaluated the second point, I doubt the first point more.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0048925C482577BA_=-- From pkyzivat@cisco.com Tue Oct 12 07:08:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A563A6989; Tue, 12 Oct 2010 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.195 X-Spam-Level: X-Spam-Status: No, score=-110.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwCbKr0zI1ln; Tue, 12 Oct 2010 07:08:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E10173A696E; Tue, 12 Oct 2010 07:08:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAG0ItExAZnwN/2dsb2JhbACTVI19caEAnHWFSASJeUiDAw X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="169783266" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Oct 2010 14:09:20 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9CE9Jbn017342; Tue, 12 Oct 2010 14:09:19 GMT Message-ID: <4CB46C10.2010300@cisco.com> Date: Tue, 12 Oct 2010 10:09:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" , sipcore-bounces@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:08:10 -0000 On 10/12/2010 9:10 AM, gao.yang2@zte.com.cn wrote: > > > > > But I really did not see any normative defintion for Join semantics in > > > REFER(Refer-To). If you saw it, please tell me the RFCs and relating > > > sections. > > > > Its because there are none. > > > > The semantics of Join apply to INVITE. > > > > If you use a REFER, with a Refer-To URI that has an embedded Join > > header, then the resulting INVITE will have a Join header. That's all. > > OK. And I admit that it's working in pure audio systems. > > But there's still two questions behind it: > > 1. Is this way(with a Refer-To URI that has an embedded Join header) > normative? I don't know what you mean - "is it normative?". Its a mechanism you can use if you think it serves your needs. Or maybe you are asking if honoring the embedded headers in an R-URI is normative. Its not. And *that* is indeed a potential limitation to using Join with REFER. If the referred party doesn't honor the embedded Join header, then it will end up replacing the call rather than joining it. Thanks, Paul > I admit that it looks like normative. But our system met interworking > issue about this way. > > 2. Is this way has enough expression? > Please refer to my comments in the previous mail: > "the instruction of the which media streams should be in the > INVITE_with_Join from the Refer-By party to the Refer-To party" > It is quit important. > > And after I evaluated the second point, I doubt the first point more. > > Thanks, > > Gao > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From bcampen@estacado.net Tue Oct 12 07:18:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF413A695A for ; Tue, 12 Oct 2010 07:18:11 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cStI5mexD4lS for ; Tue, 12 Oct 2010 07:18:09 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 405AC3A697C for ; Tue, 12 Oct 2010 07:18:07 -0700 (PDT) Received: from dn3-100.estacado.net (dn3-100.estacado.net [172.16.3.100]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9CEJIfk055262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Oct 2010 09:19:18 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-12--651686877 From: Byron Campen In-Reply-To: Date: Tue, 12 Oct 2010 09:19:18 -0500 Message-Id: References: To: gao.yang2@zte.com.cn X-Mailer: Apple Mail (2.1081) Cc: shinji.okumura@softfront.jp, SIPCORE Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:18:11 -0000 --Apple-Mail-12--651686877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Any non-dialog-killing failure response will do here. My = suspicion is that a 500 will be the most commonly seen such response in = the wild, but I could be mistaken. Best regards, Byron Campen >=20 > Hi Byron Campen,=20 >=20 > Before getting into the details, I'd like to check does the = "INVITE/500" just means the 5xx of INVITE?=20 >=20 > Thanks,=20 >=20 > Gao=20 >=20 > > Sending to the authors of the offeranswer and reinvite drafts,=20 > > since I am not sure which bucket this would fall in: > >=20 > > Consider the following. In all cases, this is within a reINVITE=20= > > transaction, after an offer/answer exchange has completed using=20 > > 100rel (which kind is not important), that is being rejected by the=20= > > server side due to some unspecified error: > >=20 > > A B > > |<---------| INVITE/500 > > | | > > | | > > UPDATE (offer) |--------->| > > | | > > |<---------| UPDATE/200 (answer) > >=20 > > A B > > UPDATE (offer) |---\ /---| INVITE/500 > > | \/ | > > | /\ | > > |<--/ \-->| > > | | > > |<---------| UPDATE/200 (answer) > >=20 > > A B > > | /-| INVITE/500 > > | / | > > UPDATE (offer) |------/-->| > > | / | > > |<---/-----| UPDATE/200 (answer) > > | / | > > |<-/ | > >=20 > > All of these look identical to B; UPDATE offer/answer completes=20= > > after the end of the INVITE transaction. However, A sees them very=20= > > differently. B cannot know that something unusual has happened. Also > > consider the following cases: > >=20 > > A B > > UPDATE (offer) |--------->| > > | | > > |<---------| UPDATE/200 (answer) > > | | > > |<---------| INVITE/500 > >=20 > > A B > > UPDATE (offer) |--------->| > > | | > > | /--| UPDATE/200 (answer) > > | / | > > |<----/----| INVITE/500 > > | / | > > |<--/ | > >=20 > > Again, these look the same to B, but different to A. What is the=20= > > best approach to ensuring that session-state is consistent on both=20= > > ends in all of these cases? It seems to me that one way would be to=20= > > specify that rollback of a reINVITE does not invalidate session- > > state established with an UPDATE, regardless of whether that UPDATE=20= > > transaction occurred (or appeared to have occurred) during the=20 > > reINVITE transaction. If we insist that session-state established=20 > > with an in-reINVITE UPDATE be rolled back (the current language says > > that both sides must roll back to the session-state in use prior to=20= > > the reINVITE), then there is no way to ensure consistent rollback on > > both ends, even if everything has the same rollback logic, because=20= > > what appears to be an in-reINVITE UPDATE on one end may appear to be > > after the reINVITE transaction on the other end. If any portion of=20= > > the UPDATE transaction appeared to have happened within the reINVITE > > transaction, then the observing UA must send a sub > > sequent UPDATE to re-sync (since there is no guarantee that the=20 > > other end saw the UPDATE within the reINVITE transaction). This is=20= > > likely to cause glare, unless we put asymmetric timers on the re- > > sync, and even then there will be a delay similar to that caused by = glare. > >=20 > > My gut says that it would be better to not rollback session-state > > established by an UPDATE, under any circumstances. But, there may be > > situations where the session-state established in an UPDATE is=20 > > contingent on the reINVITE succeeding it. Would it be appropriate to > > say that if a UA "feels" this way, it is responsible for re-syncing? > > Or is there something I am missing here? > >=20 > > Best regards, > > Byron Campen > >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-12--651686877 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Any non-dialog-killing failure response will do here. My suspicion is that a 500 will be the most commonly seen such response in the wild, but I could be mistaken.

Best regards,
Byron Campen


Hi Byron Campen,

Before getting into the details, I'd like to check does the "INVITE/500" just means the 5xx of INVITE?

Thanks,

Gao

>    Sending to the authors of the offeranswer and reinvite drafts,
> since I am not sure which bucket this would fall in:
>
>    Consider the following. In all cases, this is within a reINVITE
> transaction, after an offer/answer exchange has completed using
> 100rel (which kind is not important), that is being rejected by the
> server side due to some unspecified error:
>
>                  A          B
>                  |<---------| INVITE/500
>                  |          |
>                  |          |
>   UPDATE (offer) |--------->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>
>                  A          B
>   UPDATE (offer) |---\  /---| INVITE/500
>                  |    \/    |
>                  |    /\    |
>                  |<--/  \-->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>
>                  A          B
>                  |        /-| INVITE/500
>                  |       /  |
>   UPDATE (offer) |------/-->|
>                  |     /    |
>                  |<---/-----| UPDATE/200 (answer)
>                  |   /      |
>                  |<-/       |
>
>    All of these look identical to B; UPDATE offer/answer completes
> after the end of the INVITE transaction. However, A sees them very
> differently. B cannot know that something unusual has happened. Also
> consider the following cases:
>
>                  A          B
>   UPDATE (offer) |--------->|
>                  |          |
>                  |<---------| UPDATE/200 (answer)
>                  |          |
>                  |<---------| INVITE/500
>
>                  A          B
>   UPDATE (offer) |--------->|
>                  |          |
>                  |       /--| UPDATE/200 (answer)
>                  |      /   |
>                  |<----/----| INVITE/500
>                  |    /     |
>                  |<--/      |
>
>    Again, these look the same to B, but different to A. What is the
> best approach to ensuring that session-state is consistent on both
> ends in all of these cases? It seems to me that one way would be to
> specify that rollback of a reINVITE does not invalidate session-
> state established with an UPDATE, regardless of whether that UPDATE
> transaction occurred (or appeared to have occurred) during the
> reINVITE transaction. If we insist that session-state established
> with an in-reINVITE UPDATE be rolled back (the current language says
> that both sides must roll back to the session-state in use prior to
> the reINVITE), then there is no way to ensure consistent rollback on
> both ends, even if everything has the same rollback logic, because
> what appears to be an in-reINVITE UPDATE on one end may appear to be
> after the reINVITE transaction on the other end. If any portion of
> the UPDATE transaction appeared to have happened within the reINVITE
> transaction, then the observing UA must send a sub
>  sequent UPDATE to re-sync (since there is no guarantee that the
> other end saw the UPDATE within the reINVITE transaction). This is
> likely to cause glare, unless we put asymmetric timers on the re-
> sync, and even then there will be a delay similar to that caused by glare.
>
>    My gut says that it would be better to not rollback session-state
> established by an UPDATE, under any circumstances. But, there may be
> situations where the session-state established in an UPDATE is
> contingent on the reINVITE succeeding it. Would it be appropriate to
> say that if a UA "feels" this way, it is responsible for re-syncing?
> Or is there something I am missing here?
>
> Best regards,
> Byron Campen
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--Apple-Mail-12--651686877-- From dworley@avaya.com Tue Oct 12 07:43:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E765A3A69AC for ; Tue, 12 Oct 2010 07:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9DwiTX5qbJJ for ; Tue, 12 Oct 2010 07:43:49 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E7D323A6823 for ; Tue, 12 Oct 2010 07:43:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="242316674" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2010 10:45:02 -0400 X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="521981480" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Oct 2010 10:45:02 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 12 Oct 2010 10:45:02 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" Date: Tue, 12 Oct 2010 10:45:02 -0400 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActppcfAjdo3qRgyQfqz1uUnQbY12wAdAn9m Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:43:54 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] This is similar to Replaces semantics in REFER(Refer-To) as defined in RFC3= 515 as: Refer-To: But I really did not see any normative defintion for Join semantics in REFE= R(Refer-To). If you saw it, please tell me the RFCs and relating sections. ________________________________________ The use of '?Join=3D...' and '?Replaces=3D...' in the Refer-To URI isn't de= fined in the REFER RFC because the semantics are a consequence of a general= rule about how 'headers' in a URI are to be interpreted when a request is = generated "to a URI". That is defined in RFC 3261 section 19.1.1. Dale From root@core3.amsl.com Tue Oct 12 07:45:04 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 424333A696F; Tue, 12 Oct 2010 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012144503.424333A696F@core3.amsl.com> Date: Tue, 12 Oct 2010 07:45:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-10.txt Pages : 39 Date : 2010-10-12 This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. The document obsoletes RFC 2976. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12073120.I-D@ietf.org> --NextPart-- From gao.yang2@zte.com.cn Tue Oct 12 08:33:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0D63A69C7 for ; Tue, 12 Oct 2010 08:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.559 X-Spam-Level: X-Spam-Status: No, score=-100.559 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na8dMqDKO7Y6 for ; Tue, 12 Oct 2010 08:33:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 652953A69AA for ; Tue, 12 Oct 2010 08:33:29 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Tue, 12 Oct 2010 23:33:25 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.1967002180; Tue, 12 Oct 2010 23:34:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9CFYuV1030862; Tue, 12 Oct 2010 23:34:56 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 23:32:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 23:34:36, Serialize complete at 2010-10-12 23:34:36 Content-Type: multipart/alternative; boundary="=_alternative 00558E6A482577BA_=" X-MAIL: mse3.zte.com.cn o9CFYuV1030862 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:33:31 -0000 This is a multipart message in MIME format. --=_alternative 00558E6A482577BA_= Content-Type: text/plain; charset="US-ASCII" > This is similar to Replaces semantics in REFER(Refer-To) as defined > in RFC3515 as: > > Refer-To: to-tag%3D12345%3Bfrom-tag%3D5FFE-3994> > > But I really did not see any normative defintion for Join semantics > in REFER(Refer-To). If you saw it, please tell me the RFCs and > relating sections. > ________________________________________ > > The use of '?Join=...' and '?Replaces=...' in the Refer-To URI isn't > defined in the REFER RFC because the semantics are a consequence of > a general rule about how 'headers' in a URI are to be interpreted > when a request is generated "to a URI". That is defined in RFC 3261 > section 19.1.1. > As we know, RFC3261 section 19.1.1 just define the basic format and syntax of embedded headers for URI. In other words, the sematics of the embedded headers and the behavior defintion should be defined in other RFCs clearly. About Replaces header embedded in URI, there's no detailed defintion for it. But a example in RFC3515 section 2.1. Refer-To: IMO, this could be treated as *some level* normative definition, or at least guidelines. But there's nothing about Join header embedded in URL, in any of RFCs. So, I can just treated it as something like a private extension, just like one vendor put a "XXX" header embedded. And the UAS's vendor would ask you how should they behaving and where is the specification/rule? (And this is usual in interworking testing). Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00558E6A482577BA_= Content-Type: text/html; charset="US-ASCII"

> This is similar to Replaces semantics in REFER(Refer-To) as defined
> in RFC3515 as:
>
> Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
>           to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
>
> But I really did not see any normative defintion for Join semantics
> in REFER(Refer-To). If you saw it, please tell me the RFCs and
> relating sections.
> ________________________________________
>
> The use of '?Join=...' and '?Replaces=...' in the Refer-To URI isn't
> defined in the REFER RFC because the semantics are a consequence of
> a general rule about how 'headers' in a URI are to be interpreted
> when a request is generated "to a URI".  That is defined in RFC 3261
> section 19.1.1.
>

As we know, RFC3261 section 19.1.1 just define the basic format and syntax of embedded headers for URI. In other words, the sematics of the embedded headers and the behavior defintion should be defined in other RFCs clearly.

About Replaces header embedded in URI, there's no detailed defintion for it. But a example in RFC3515 section 2.1.

Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
          to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

IMO, this could be treated as *some level* normative definition, or at least guidelines.

But there's nothing about Join header embedded in URL, in any of RFCs. So, I can just treated it as something like a private extension, just like one vendor put a "XXX" header embedded.

And the UAS's vendor would ask you how should they behaving and where is the specification/rule? (And this is usual in interworking testing).

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00558E6A482577BA_=-- From gao.yang2@zte.com.cn Tue Oct 12 08:41:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCC43A63EB for ; Tue, 12 Oct 2010 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiYwu2D++0dR for ; Tue, 12 Oct 2010 08:41:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4913F3A69A0 for ; Tue, 12 Oct 2010 08:41:02 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Tue, 12 Oct 2010 23:40:58 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 38058.3772637948; Tue, 12 Oct 2010 23:39:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9CFgVLD032762; Tue, 12 Oct 2010 23:42:32 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CB46C10.2010300@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 23:40:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 23:42:11, Serialize complete at 2010-10-12 23:42:11 Content-Type: multipart/alternative; boundary="=_alternative 00564063482577BA_=" X-MAIL: mse3.zte.com.cn o9CFgVLD032762 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:41:03 -0000 This is a multipart message in MIME format. --=_alternative 00564063482577BA_= Content-Type: text/plain; charset="US-ASCII" > > 1. Is this way(with a Refer-To URI that has an embedded Join header) > > normative? > > I don't know what you mean - "is it normative?". > Its a mechanism you can use if you think it serves your needs. As you can see, the header syntax(such as Join header with CallID and From/To Tags), semantics, behavior for UAS should be defined clearly. Otherwise, there would be no meaning in interworking for UAs from different vendors. In fact, this is not like any private sip extension. So, I think it should be defined in one RFC, at least as BCP. > > I admit that it looks like normative. But our system met interworking > > issue about this way. > > > > 2. Is this way has enough expression? > > Please refer to my comments in the previous mail: > > "the instruction of the which media streams should be in the > > INVITE_with_Join from the Refer-By party to the Refer-To party" > > It is quit important. > > > > And after I evaluated the second point, I doubt the first point more. What about the second one? Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00564063482577BA_= Content-Type: text/html; charset="US-ASCII"

> > 1. Is this way(with a Refer-To URI that has an embedded Join header)
> > normative?
>
> I don't know what you mean - "is it normative?".
> Its a mechanism you can use if you think it serves your needs.

As you can see, the header syntax(such as Join header with CallID and From/To Tags), semantics, behavior for UAS should be defined clearly. Otherwise, there would be no meaning in interworking for UAs from different vendors.

In fact, this is not like any private sip extension. So, I think it should be defined in one RFC, at least as BCP.


> > I admit that it looks like normative. But our system met interworking
> > issue about this way.
> >
> > 2. Is this way has enough expression?
> > Please refer to my comments in the previous mail:
> > "the instruction of the which media streams should be in the
> > INVITE_with_Join from the Refer-By party to the Refer-To party"
> > It is quit important.
> >
> > And after I evaluated the second point, I doubt the first point more.
What about the second one?

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00564063482577BA_=-- From gao.yang2@zte.com.cn Tue Oct 12 08:45:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD823A69E4 for ; Tue, 12 Oct 2010 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.771 X-Spam-Level: X-Spam-Status: No, score=-97.771 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0MCSR8OlCSr for ; Tue, 12 Oct 2010 08:45:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CC1B33A69D6 for ; Tue, 12 Oct 2010 08:45:47 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Tue, 12 Oct 2010 23:45:43 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 38058.5143419512; Tue, 12 Oct 2010 23:44:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9CFlGwv034157; Tue, 12 Oct 2010 23:47:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CA0AE61.7060003@cisco.com> To: Paul Kyzivat , Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Oct 2010 23:44:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-12 23:46:56, Serialize complete at 2010-10-12 23:46:56 Content-Type: multipart/alternative; boundary="=_alternative 0056AFA4482577BA_=" X-MAIL: mse3.zte.com.cn o9CFlGwv034157 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:45:53 -0000 This is a multipart message in MIME format. --=_alternative 0056AFA4482577BA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF1bCBhbmQgQ2hyaXN0ZXIsDQoNCldlIG5vdyB1c2UgdGhpcyBkcmFmdCBpbiBvdXIgSU1T KDNHUFAncyBTUlZDQyksIGN1cnJlbnRseSBpbiBzdGFuZGFyZCANCmxldmVsLg0KDQpTbywgd2Ug c3VwcG9ydCB0aGlzIG9uZS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRl bDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpQYXVsIEt5eml2YXQg PHBreXppdmF0QGNpc2NvLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcN CjIwMTAtMDktMjcgMjI6NDYNCg0KytW8/sjLDQpDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Ks63LzQ0KInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3Jl QGlldGYub3JnPg0K1vfM4g0KUmU6IFtzaXBjb3JlXSBEcmFmdCBuZXc6IGRyYWZ0LWhvbG1iZXJn LXNpcGNvcmUtcHJveHktZmVhdHVyZSBbd2FzOiANCkZlYXR1cmUtdGFncyBpbiB0aGUgUGF0aCBo ZWFkZXIgZmllbGRdDQoNCg0KDQoNCg0KDQpbYXMgY2hhaXJdDQoNClRvIGFsbCBzaXBjb3JlIHBh cnRpY2lwYW50czoNCg0KQ2hyaXN0ZXIgaGFzIGJlZW4gbG9va2luZyBmb3IgYSB3YXkgdG8gYWNj b21wbGlzaCBhIHBhcnRpY3VsYXIgZnVuY3Rpb24gDQp0aGF0IDNncHAgd2FudHMuIFRoaXMgcHJv cG9zYWwgc2VlbXMgYSBwbGF1c2libGUgd2F5IHRvIGRvIHRoYXQuIEJ1dCBpdCANCmlzIG9mIG5l Y2Vzc2l0eSBkZWZpbmluZyBhIG1vcmUgZ2VuZXJhbCBtZWNoYW5pc20uDQoNCkknZCByZWFsbHkg YXBwcmVjaWF0ZSBjb21tZW50cyBmcm9tIG90aGVycyAoaW5jbHVkaW5nIHBlb3BsZSBpbiBubyB3 YXkgDQppbnZvbHZlZCB3aXRoIDNncHApIHJlZ2FyZGluZyB0aGlzIG1lY2hhbmlzbS4gRm9yIGlu c3RhbmNlLCBkbyB5b3UgDQpjb25zaWRlciB0aGUgc2VtYW50aWNzIHRvIGJlIHdlbGwgZGVmaW5l ZD8gRG8geW91IHNlZSBuZWVkIGZvciBtb3JlIA0KYWJvdXQgc2VjdXJpdHkgaW1wbGljYXRpb25z Pw0KDQpIb3cgbWFueSB3b3VsZCBmaW5kIHRoaXMgdXNlZnVsIHRvIGhhdmU/DQoNCiAgICAgICAg ICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICBQYXVsDQoNCk9uIDkvMjQvMjAxMCA3 OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4NCj4gSGksDQo+DQo+IEkndmUgc3Vi bWl0dGVkIGEgZHJhZnQsIHdoaWNoIGV4dGVuZHMgdGhlIHJyLXBhcmFtIHJ1bGUsIGFsbG93aW5n IA0KcHJveGllcyB0byBpbmRpY2F0ZSBzdXBwb3J0ZWQgZmVhdHVyZXMgdXNpbmcgZmVhdHVyZSB0 YWdzIGluIFBhdGgsIA0KUmVjb3JkLVJvdXRlIGV0Yy4NCj4NCj4gVGhlIGRyYWZ0IGNhbiBhbHNv IGJlIGZvdW5kIGF0OiANCmh0dHA6Ly91c2Vycy5waXVoYS5uZXQvY2hvbG1iZXIvZHJhZnRzL2Ry YWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZS0wMC50eHQNCg0KPg0KPiBBcyBJIGlu ZGljYXRlZCBlYXJsaWVyIG9uIHRoZSBsaXN0LCBhbmQgYXMgeW91IGNhbiByZWFkIGluIHRoZSBk cmFmdCwgDQp0aGVyZSBpcyBhIDNHUFAgdXNlLWNhc2Ugd2hlcmUgd2UgYmVsaWV2ZSB0aGUgbWVj aGFuaXNtIGNvdWxkIGJlIHVzZWQuIA0KQnV0LCB0aGVyZSBpcyBub3RoaW5nIDNHUFAgc3BlY2lm aWMgYWJvdXQgdGhlIG1lY2hhbmlzbSBhcyBzdWNoLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJp c3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNp cGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0056AFA4482577BA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhdWwgYW5kIENocmlzdGVy LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2Ugbm93 IHVzZSB0aGlzIGRyYWZ0IGluIG91ciBJTVMoM0dQUCdzDQpTUlZDQyksIGN1cnJlbnRseSBpbiBz dGFuZGFyZCBsZXZlbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlNvLCB3ZSBzdXBwb3J0IHRoaXMgb25lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4 NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6 IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7PC9iPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3NpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4yMDEwLTA5LTI3IDIyOjQ2PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYu b3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFtzaXBjb3JlXSBEcmFmdCBuZXc6IGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVy ZQ0KW3dhczogRmVhdHVyZS10YWdzIGluIHRoZSBQYXRoIGhlYWRlciBmaWVsZF08L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlthcyBjaGFp cl08YnI+DQo8YnI+DQpUbyBhbGwgc2lwY29yZSBwYXJ0aWNpcGFudHM6PGJyPg0KPGJyPg0KQ2hy aXN0ZXIgaGFzIGJlZW4gbG9va2luZyBmb3IgYSB3YXkgdG8gYWNjb21wbGlzaCBhIHBhcnRpY3Vs YXIgZnVuY3Rpb24NCjxicj4NCnRoYXQgM2dwcCB3YW50cy4gVGhpcyBwcm9wb3NhbCBzZWVtcyBh IHBsYXVzaWJsZSB3YXkgdG8gZG8gdGhhdC4gQnV0IGl0DQo8YnI+DQppcyBvZiBuZWNlc3NpdHkg ZGVmaW5pbmcgYSBtb3JlIGdlbmVyYWwgbWVjaGFuaXNtLjxicj4NCjxicj4NCkknZCByZWFsbHkg YXBwcmVjaWF0ZSBjb21tZW50cyBmcm9tIG90aGVycyAoaW5jbHVkaW5nIHBlb3BsZSBpbiBubyB3 YXkNCjxicj4NCmludm9sdmVkIHdpdGggM2dwcCkgcmVnYXJkaW5nIHRoaXMgbWVjaGFuaXNtLiBG b3IgaW5zdGFuY2UsIGRvIHlvdSA8YnI+DQpjb25zaWRlciB0aGUgc2VtYW50aWNzIHRvIGJlIHdl bGwgZGVmaW5lZD8gRG8geW91IHNlZSBuZWVkIGZvciBtb3JlIDxicj4NCmFib3V0IHNlY3VyaXR5 IGltcGxpY2F0aW9ucz88YnI+DQo8YnI+DQpIb3cgbWFueSB3b3VsZCBmaW5kIHRoaXMgdXNlZnVs IHRvIGhhdmU/PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNClRoYW5rcyw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUGF1bDxicj4NCjxicj4NCk9uIDkv MjQvMjAxMCA3OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0LCB3aGlj aCBleHRlbmRzIHRoZSByci1wYXJhbSBydWxlLCBhbGxvd2luZw0KcHJveGllcyB0byBpbmRpY2F0 ZSBzdXBwb3J0ZWQgZmVhdHVyZXMgdXNpbmcgZmVhdHVyZSB0YWdzIGluIFBhdGgsIFJlY29yZC1S b3V0ZQ0KZXRjLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBkcmFmdCBjYW4gYWxzbyBiZSBmb3Vu ZCBhdDogaHR0cDovL3VzZXJzLnBpdWhhLm5ldC9jaG9sbWJlci9kcmFmdHMvZHJhZnQtaG9sbWJl cmctc2lwY29yZS1wcm94eS1mZWF0dXJlLTAwLnR4dDxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIEkg aW5kaWNhdGVkIGVhcmxpZXIgb24gdGhlIGxpc3QsIGFuZCBhcyB5b3UgY2FuIHJlYWQgaW4gdGhl IGRyYWZ0LA0KdGhlcmUgaXMgYSAzR1BQIHVzZS1jYXNlIHdoZXJlIHdlIGJlbGlldmUgdGhlIG1l Y2hhbmlzbSBjb3VsZCBiZSB1c2VkLg0KQnV0LCB0aGVyZSBpcyBub3RoaW5nIDNHUFAgc3BlY2lm aWMgYWJvdXQgdGhlIG1lY2hhbmlzbSBhcyBzdWNoLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJy Pg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21h aWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5i c3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7 bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVy bWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7 b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5i c3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGkt U3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0056AFA4482577BA_=-- From christer.holmberg@ericsson.com Tue Oct 12 08:48:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BD83A69D6 for ; Tue, 12 Oct 2010 08:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qwr71MK5JZ4 for ; Tue, 12 Oct 2010 08:48:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 77CF83A6944 for ; Tue, 12 Oct 2010 08:48:34 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-b0-4cb4839cbb81 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 03.A2.27351.C9384BC4; Tue, 12 Oct 2010 17:49:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 12 Oct 2010 17:49:47 +0200 From: Christer Holmberg To: "gao.yang2@zte.com.cn" , "Worley, Dale R (Dale)" Date: Tue, 12 Oct 2010 17:49:43 +0200 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActqI0y03f+CMtEJQmmFKvW2GelePwAAV4nQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DB6AE1@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058502DB6AE1ESESSCMS0356eem_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:48:36 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058502DB6AE1ESESSCMS0356eem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From a SIP protocol perspective, I don't think embedded headers have any se= mtantics - until they become "real headers" in the request triggered by the= REFER. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of gao.yang2@zte.com.cn Sent: 12. lokakuuta 2010 18:33 To: Worley, Dale R (Dale) Cc: sipcore@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join= header in REFER? > This is similar to Replaces semantics in REFER(Refer-To) as defined > in RFC3515 as: > > Refer-To: to-tag%3D12345%3Bfrom-tag%3D5FFE-3994> > > But I really did not see any normative defintion for Join semantics > in REFER(Refer-To). If you saw it, please tell me the RFCs and > relating sections. > ________________________________________ > > The use of '?Join=3D...' and '?Replaces=3D...' in the Refer-To URI isn't > defined in the REFER RFC because the semantics are a consequence of > a general rule about how 'headers' in a URI are to be interpreted > when a request is generated "to a URI". That is defined in RFC 3261 > section 19.1.1. > As we know, RFC3261 section 19.1.1 just define the basic format and syntax = of embedded headers for URI. In other words, the sematics of the embedded h= eaders and the behavior defintion should be defined in other RFCs clearly. About Replaces header embedded in URI, there's no detailed defintion for it= . But a example in RFC3515 section 2.1. Refer-To: IMO, this could be treated as *some level* normative definition, or at leas= t guidelines. But there's nothing about Join header embedded in URL, in any of RFCs. So, = I can just treated it as something like a private extension, just like one = vendor put a "XXX" header embedded. And the UAS's vendor would ask you how should they behaving and where is th= e specification/rule? (And this is usual in interworking testing). Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_7F2072F1E0DE894DA4B517B93C6A058502DB6AE1ESESSCMS0356eem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
From a SIP protocol perspective, I don't think emb= edded=20 headers have any semtantics - until they become "real headers" in= the=20 request triggered by the REFER.
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 gao.yang2@zte.com.cn
Sent: 12. lokakuuta 2010=20 18:33
To: Worley, Dale R (Dale)
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] About RFC3911(Join head= er)'s=20 potential error: //Join header in REFER?



> This is similar to Replaces se= mantics=20 in REFER(Refer-To) as defined
> in RFC3515 as:
>
>=20 Refer-To:=20 <sip:dave@denver.example.org?Replaces=3D12345%40192.168.118.3%3B
&g= t;=20          =20 to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
>
> But I really d= id=20 not see any normative defintion for Join semantics
> in=20 REFER(Refer-To). If you saw it, please tell me the RFCs and
> rela= ting=20 sections.
> ________________________________________
>
&g= t;=20 The use of '?Join=3D...' and '?Replaces=3D...' in the Refer-To URI isn't<= BR>>=20 defined in the REFER RFC because the semantics are a consequence of
&= gt; a=20 general rule about how 'headers' in a URI are to be interpreted
> = when=20 a request is generated "to a URI".  That is defined in RFC 3261
&= gt;=20 section 19.1.1.
>

As we know= ,=20 RFC3261 section 19.1.1 just define the basic format and syntax of embedde= d=20 headers for URI. In other words, the sematics of the embedded headers and= the=20 behavior defintion should be defined in other RFCs clearly.=20

About Replaces header embedded in URI, there's= no=20 detailed defintion for it. But a example in RFC3515 section 2.1.=20

Refer-To:=20 <sip:dave@denver.example.org?Replaces=3D12345%40192.168.118.3%3B=20
         = ;=20 to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

IMO,=20 this could be treated as *some level* normative definition, or at least=20 guidelines.

But there's nothing ab= out=20 Join header embedded in URL, in any of RFCs. So, I can just treated it as= =20 something like a private extension, just like one vendor put a "XXX" head= er=20 embedded.

And the UAS's vendor wou= ld ask=20 you how should they behaving and where is the specification/rule? (And th= is is=20 usual in interworking testing).

Thanks,

Gao <= BR>
--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_7F2072F1E0DE894DA4B517B93C6A058502DB6AE1ESESSCMS0356eem_-- From gao.yang2@zte.com.cn Tue Oct 12 09:57:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608933A69CE for ; Tue, 12 Oct 2010 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[AWL=1.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6hsj7SSC5ut for ; Tue, 12 Oct 2010 09:57:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A07FD3A6976 for ; Tue, 12 Oct 2010 09:57:29 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Wed, 13 Oct 2010 00:57:26 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38058.3576965743; Wed, 13 Oct 2010 00:56:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9CGx1Ji057006; Wed, 13 Oct 2010 00:59:01 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DB6AE1@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Oct 2010 00:56:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-13 00:58:38, Serialize complete at 2010-10-13 00:58:38 Content-Type: multipart/alternative; boundary="=_alternative 005D3FB1482577BA_=" X-MAIL: mse2.zte.com.cn o9CGx1Ji057006 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:57:31 -0000 This is a multipart message in MIME format. --=_alternative 005D3FB1482577BA_= Content-Type: text/plain; charset="US-ASCII" > From a SIP protocol perspective, I don't think embedded headers have > any semtantics - until they become "real headers" in the request > triggered by the REFER. Could one specific header be used as embedded header in the Refer-To header and the REFER method? Might we need something more than just character transformation(such as ?/=)? //please see my sencond point for streams type, streams direction indication. These things could be thought as the semantics for the embedded headers. To make thing clear, I'd like to split the question: 1. Do we need a Draft to define/clarify the Join header's embedded usage in Refer-To? 2. Does the Join header's embedded usage need extension, for streams type, streams direction indication? Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005D3FB1482577BA_= Content-Type: text/html; charset="US-ASCII"
> From a SIP protocol perspective, I don't think embedded headers have
> any semtantics - until they become "real headers" in the request
> triggered by the REFER.

Could one specific header be used as embedded header in the Refer-To header and the REFER method?
Might we need something more than just character transformation(such as ?/=)?  //please see my sencond point for streams type, streams direction indication.

These things could be thought as the semantics for the embedded headers.

To make thing clear, I'd like to split the question:

1. Do we need a Draft to define/clarify the Join header's embedded usage in Refer-To?

2. Does the Join header's embedded usage need extension, for streams type, streams direction indication?

Thanks,

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 005D3FB1482577BA_=-- From christer.holmberg@ericsson.com Tue Oct 12 10:09:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7623A691F for ; Tue, 12 Oct 2010 10:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvOqCQi0aD-u for ; Tue, 12 Oct 2010 10:09:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EBFC53A67FA for ; Tue, 12 Oct 2010 10:09:17 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-1d-4cb496870fa7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D4.BA.27351.78694BC4; Tue, 12 Oct 2010 19:10:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 12 Oct 2010 19:10:31 +0200 From: Christer Holmberg To: "gao.yang2@zte.com.cn" Date: Tue, 12 Oct 2010 19:10:30 +0200 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActqLrsXUNrcrsTFRj6DQPaTXCT12AAAFYfQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502DB6AE1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 17:09:19 -0000 Hi,=20 >>From a SIP protocol perspective, I don't think embedded headers have >>any semtantics - until they become "real headers" in the request=20 >>triggered by the REFER.=20 >=09 >Could one specific header be used as embedded header in the Refer-To heade= r and the REFER method? As far as I know, there are no explicit restrictions. One could, however, ask whether it's allowed to include headers that are no= t to be used in the triggered INVITE, but in later associated requests. For example, could I include an embedded RAck header, which will not be use= d by the triggered INVITE, but later for a PRACK associated with that INVIT= E? >Might we need something more than just character transformation(such as ?/= =3D)? //please see my sencond point for streams type, streams direction=20 >indication.=20 You CAN also embed SDP information. Regards, Christer >These things could be thought as the semantics for the embedded headers.=20 >=09 >To make thing clear, I'd like to split the question:=20 >=09 >1. Do we need a Draft to define/clarify the Join header's embedded usage i= n Refer-To?=20 >=09 >2. Does the Join header's embedded usage need extension, for streams type,= streams direction indication?=20 =09 Thanks,=20 =09 Gao =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= solely property of the sender's organization. This mail communication is c= onfidential. Recipients named above are obligated to maintain secrecy and a= re not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the originator of t= he message. Any views expressed in this message are those of the individual= sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . =09 From christer.holmberg@ericsson.com Tue Oct 12 10:18:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394063A681E for ; Tue, 12 Oct 2010 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1nA4repkIR0 for ; Tue, 12 Oct 2010 10:18:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D2F6C3A6867 for ; Tue, 12 Oct 2010 10:18:07 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-6c-4cb4989857e9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.4B.27351.89894BC4; Tue, 12 Oct 2010 19:19:20 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 12 Oct 2010 19:19:20 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 12 Oct 2010 19:19:19 +0200 From: Christer Holmberg To: Christer Holmberg , "gao.yang2@zte.com.cn" Date: Tue, 12 Oct 2010 19:19:17 +0200 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActqLrsXUNrcrsTFRj6DQPaTXCT12AAAFYfQAACcRsA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DB6B32@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058502DB6AE1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 17:18:09 -0000 Ok, RAck was a bad example, because it's genereated based on the RSeq in th= e provisional response.=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 12. lokakuuta 2010 20:11 > To: gao.yang2@zte.com.cn > Cc: Worley, Dale R (Dale); sipcore@ietf.org > Subject: Re: [sipcore] About RFC3911(Join header)'s potential=20 > error: //Join header in REFER? >=20 >=20 > Hi,=20 >=20 > >>From a SIP protocol perspective, I don't think embedded=20 > headers have=20 > >>any semtantics - until they become "real headers" in the request=20 > >>triggered by the REFER. > >=09 > >Could one specific header be used as embedded header in the=20 > Refer-To header and the REFER method? >=20 > As far as I know, there are no explicit restrictions. >=20 > One could, however, ask whether it's allowed to include=20 > headers that are not to be used in the triggered INVITE, but=20 > in later associated requests. >=20 > For example, could I include an embedded RAck header, which=20 > will not be used by the triggered INVITE, but later for a=20 > PRACK associated with that INVITE? >=20 > >Might we need something more than just character=20 > transformation(such as=20 > >?/=3D)? //please see my sencond point for streams type,=20 > streams direction indication. >=20 > You CAN also embed SDP information. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >These things could be thought as the semantics for the=20 > embedded headers.=20 > >=09 > >To make thing clear, I'd like to split the question:=20 > >=09 > >1. Do we need a Draft to define/clarify the Join header's=20 > embedded usage in Refer-To?=20 > >=09 > >2. Does the Join header's embedded usage need extension, for=20 > streams type, streams direction indication?=20 >=20 >=20 > =09 > Thanks,=20 > =09 > Gao > =09 > -------------------------------------------------------- > ZTE Information Security Notice: The information=20 > contained in this mail is solely property of the sender's=20 > organization. This mail communication is confidential.=20 > Recipients named above are obligated to maintain secrecy and=20 > are not permitted to disclose the contents of this=20 > communication to others. > This email and any files transmitted with it are=20 > confidential and intended solely for the use of the=20 > individual or entity to whom they are addressed. If you have=20 > received this email in error please notify the originator of=20 > the message. Any views expressed in this message are those of=20 > the individual sender. > This message has been scanned for viruses and Spam by=20 > ZTE Anti-Spam system. > =09 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From wwwrun@core3.amsl.com Tue Oct 12 11:15:42 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E9DFF3A6A35; Tue, 12 Oct 2010 11:15:42 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101012181542.E9DFF3A6A35@core3.amsl.com> Date: Tue, 12 Oct 2010 11:15:42 -0700 (PDT) Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'Session Initiation Protocol (SIP) INFO Method and Package Framework' to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 18:15:43 -0000 The IESG has approved the following document: - 'Session Initiation Protocol (SIP) INFO Method and Package Framework' 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: https://datatracker.ietf.org/doc/draft-ietf-sipcore-info-events/ Technical Summary This document defines a SIP method, INFO, along with a framework for the ways in which various applications can make use of this method. It obsoletes the previous definition of INFO, provided by RFC 2976, while including backwards-compatibility considerations that allow those applications based on RFC 2976 to continue to operate. Working Group Summary One of the recurring topics over the course of the development of a package mechanism for INFO was whether such a mechanism provides any true value. RFC 2976 originally defined the SIP INFO method in a scant 9 pages (including boilerplate). Over time, its use as a catch-all for non-standard user-to-user data became recognized as a key barrier to interoperability. For example, many vendors have defined their own, proprietary INFO-based mechanism for conveying DTMF ("TouchTone") information. However, none of these mechanisms have been published (in the IETF, in other standards bodies, or even in non-SDO documents), leading to severe fragmentation in the ability to convey this type of information. At the same time, many of the uses of INFO were recognized as being shortcuts to more appropriate and flexible mechanisms. For example, the conveyance of DTMF cited above is better suited to the mechanism defined in RFC 4733 when treated as an audio component, while the problem of general key-press conveyance is better handled by the mechanisms of RFC 4730. As a result of the foregoing, the working group spent significant discussion time over many years coming to agreement on whether it was more appropriate to fix INFO (by defining a registration mechanism for the ways in which it was used) or to deprecate it altogether (with the usage described in RFC 3398 being grandfathered as the sole legitimate usage). Although it required substantial consensus building and concessions by those more inclined to completely deprecate INFO, the eventual direction of the working group was to publish a framework for registration of INFO packages -- if for no other reason than to finally conclude the seven-year long argument and move on to other issues. Document Quality The document has been reviewed for quality by several SIPCORE participants during the Working Group Last Call period; an earlier version of the document received a particularly thorough review by Vijay Gurbani. It should be noted that the document itself does not directly describe a mechanism that can be implemented. It defines a framework that requires additional specification before it can be implemented. At the time of this publication request, no such specifications are under development within the IETF (even as individual documents); and the document shepherd is not aware of any such specifications under development outside the IETF. From pkyzivat@cisco.com Tue Oct 12 12:13:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE88A3A6A49 for ; Tue, 12 Oct 2010 12:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY3gHazyvzeq for ; Tue, 12 Oct 2010 12:13:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C58D23A69B6 for ; Tue, 12 Oct 2010 12:13:04 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAN5QtExAaMHG/2dsb2JhbACTYI19caJInH2FSASKQYMD X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="284249482" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2010 19:14:19 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9CJEHZf029796 for ; Tue, 12 Oct 2010 19:14:18 GMT Message-ID: <4CB4B388.4070304@cisco.com> Date: Tue, 12 Oct 2010 15:14:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058502DB6AE1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:13:06 -0000 On 10/12/2010 1:10 PM, Christer Holmberg wrote: > One could, however, ask whether it's allowed to include headers that are not to be used in the triggered INVITE, but in later associated requests. The semantics of headers embedded in a URI is defined by 3261, and only defined when the URI is used as an R-URI of a request. In that case they get added to the request. If you have some header you want used in a different way, I don't know how you would accomplish that. Thanks, Paul From dworley@avaya.com Tue Oct 12 12:22:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DBE3A6A49 for ; Tue, 12 Oct 2010 12:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRQhgyrmUT3I for ; Tue, 12 Oct 2010 12:21:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1BCB53A6A43 for ; Tue, 12 Oct 2010 12:21:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,321,1283745600"; d="scan'208";a="211621216" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Oct 2010 15:23:12 -0400 X-IronPort-AV: E=Sophos;i="4.57,321,1283745600"; d="scan'208";a="522093109" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Oct 2010 15:23:11 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 12 Oct 2010 15:23:11 -0400 From: "Worley, Dale R (Dale)" To: "gao.yang2@zte.com.cn" Date: Tue, 12 Oct 2010 15:23:10 -0400 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActqIwrn/mMPbWqHS8ud9RlDb38TmwAHwtcP Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:22:00 -0000 ________________________________________ From: gao.yang2@zte.com.cn [gao.yang2@zte.com.cn] As we know, RFC3261 section 19.1.1 just define the basic format and syntax = of embedded headers for URI. In other words, the sematics of the embedded h= eaders and the behavior defintion should be defined in other RFCs clearly. ________________________________________ In regard to how the recipient of the REFER is expected to see the embedded= header, the semantics are extremely well defined: The recipient is to use= the text provided to construct a Replaces header (or a Join header, or wha= tever). The recipient is *not* to have any other understanding of the embe= dded header. If additional information is to be conveyed to the recipient = of the REFER, some other method must be found for conveying that informatio= n. Of course, the recipient of the generated INVITE processes the Replaces hea= der in the manner provided in the definition of Replaces... ---- In regard to how an INVITE with Replaces or Join is to manipulate the vario= us media streams that are involved, if we pay attention to the protocol lay= ering of SIP vs. SDP, it's clear that any specification of handling the med= ia streams must be provided by the SDP (or some other contained protocol) r= ather than SIP itself, because the definition of the media streams is not v= isible to SIP. From SIP's point of view, it transports the bodies of INVIT= Es and does not care what those bodies mean. Indeed, one can use SIP witho= ut creating media streams at all. Dale From mary.ietf.barnes@gmail.com Tue Oct 12 15:36:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F743A6AB1 for ; Tue, 12 Oct 2010 15:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QVVjpO5hHTs for ; Tue, 12 Oct 2010 15:36:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id AEE4F3A6A87 for ; Tue, 12 Oct 2010 15:36:29 -0700 (PDT) Received: by gxk20 with SMTP id 20so1974702gxk.31 for ; Tue, 12 Oct 2010 15:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=cNN7QNLvwOE5oYKQ9bGGH5/al0NPXsRAHPkYUfjcxAk=; b=rNNMyUOgVIQioRUm8Q/y7UCj0leCbD1K9vul8bCpn/Q2Hqml6XOuqMuaLLf5UvW3Vb P66g2WElSa2sJHlOuYtvw35+WXubiwObuOsxLLtO63L2PWKMkaz/8YD9jlbrFcglrA9c 16qkp1pebtJS8VSM1Q5tXU7TYRZ6OUHCFR/Es= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d+3QuJ+f86pD1tB6PwvYM6QZ0zuJH3/EJQqhn97AD5RlfOnU0a97EpRu+K8ccZGcG8 c/WKD+qBqYG42BRVdS+MJf2gyEZc+RY5OVdlMlLcMhhU6hdSFpUfn+/lNX09GL9Mth3G ycUXjgE8TqiX+Vn1VdCiGp/ubGknBABhEfmTE= MIME-Version: 1.0 Received: by 10.150.198.2 with SMTP id v2mr9224303ybf.350.1286923063770; Tue, 12 Oct 2010 15:37:43 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:37:43 -0700 (PDT) Date: Tue, 12 Oct 2010 17:37:43 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu Subject: Re: [sipcore] #19/#20: Show Cancel messaging/Handling canceled forks X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:36:36 -0000 Note, I've merged these two issues into a single response since they are relevant to the same text/call flow. I have corrected #19 such that the 200 OK is sent before the Cancel. As you note, there is a general problem here in terms of how the 487 is reported. We cannot change basic SIP protocol processing. However, the hi-entry received in the response at the UAC is misleading if we don't include a reason. So, I think we have to do the "pre-emptive" addition of the reason. The parallel forking scenario also has the anomaly that the indices don't necessarily reflect (obviously) the sequence of events per se. But, I don't know a way around that one either and I think that's another parallel forking is evil side effect that we'll have to live with. The only hint the UAC would have that there was parallel forking is that the last hi-entry has a reason and the one prior doesn't. However, I think it would be better if the last entry is the successful one and is more reflective of where the INVITE was successfully received. This means that some indices might be out or order, but I do not think that should break anything since they are from the same branch (i.e., the tree looks the same). Thanks, Mary. On Tue, Aug 31, 2010 at 12:26 PM, sipcore issue tracker wrote: > #20: Handling canceled forks > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: =A0= milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0Concerning this part of section 3 figure 1: > > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 200 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |<---------------| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| History-Info: ;index=3D1 > =A0 =A0| History-Info: ;index=3D1.1 > =A0 =A0| History-Info: ;index=3D1.1.1;rc > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |<=3D=3D=3DProxy cancels INVITE=3D=3D>| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0487 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |<--------------------------| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 200 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| > =A0 =A0| History-Info: ;index=3D1 > =A0 =A0| History-Info: ;index=3D1.1 > =A0 =A0| History-Info: ;index=3D1.1.1;rc > =A0 =A0| History-Info: ;\ > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 index=3D1.1.2;rc > > =A0In principle, the second 200 response shown above should be sent > =A0immediately after the first 200 response shown above was received from > =A0downstream. =A0But the received 200 response triggered "Proxy cancels > =A0INVITE", which led to Bob@phone to send the 487 response which is > =A0documented in the 4th History-Info value in the sent 200, which should > =A0have been sent before the 487 was received. > > =A0One alternative is to put that 4th value in the upstream 200 > =A0"preemptively", that is, documenting that the proxy *intends* to cance= l > =A0the INVITE to Bob@phone. =A0But the proxy does not know that it will b= e > =A0successful in canceling the INVITE and receiving a 487 response -- the= re > =A0might already be a 200 en route from Bob@phone. =A0So the upstream 200= can't > =A0be sent until the 487 is received. > > =A0Another alternative is to delay sending the upstream 200 until after a= ll > =A0parallel forks have been disposed of. =A0But this would be complex and= might > =A0take a significant amount of time. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:38:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CF83A6A87 for ; Tue, 12 Oct 2010 15:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu5+1kT+Solz for ; Tue, 12 Oct 2010 15:38:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 386213A6AB3 for ; Tue, 12 Oct 2010 15:38:22 -0700 (PDT) Received: by gxk20 with SMTP id 20so1975152gxk.31 for ; Tue, 12 Oct 2010 15:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m0m6+C5b4q3R5TLAfU60PrQV0QH7OiHpa2LvzJGEWTs=; b=dymrv0JIw93c14Tbyp6/FseRW0WaEs4zqfzqyE/OYYznYX8oCJsGOLQ3glSeBkwot7 W34DW7O0ZXZgABJKI+N2exBX4APkwtOWBlMFV8OXoglRqY/udIuMQQByBflmM/h8yDNq 8fElk8DQnwQkmKHbLfCzz5NyMsAGycZK0yj6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cyE/PDC7hg6fsxBh4JQKzoqXRN4/Fk0uqyAPpz0cjg+/dDFYkZEdlNFq7WxQm7TCgN XRJc5GKtkzsfxn855HzfZge63izz1roKkYwB7/zLLfe0IqbWykJ8hFDSK0mzW+qAM9VP /qfCTthk8lhCa/VwPDsSZAd+0OZyI50KTxpYs= MIME-Version: 1.0 Received: by 10.236.95.138 with SMTP id p10mr16198089yhf.87.1286923175887; Tue, 12 Oct 2010 15:39:35 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:39:35 -0700 (PDT) In-Reply-To: <064.fb0d35ccf3f8bcb2cb825f12dfecf42e@tools.ietf.org> References: <064.fb0d35ccf3f8bcb2cb825f12dfecf42e@tools.ietf.org> Date: Tue, 12 Oct 2010 17:39:35 -0500 Message-ID: From: Mary Barnes To: sipcore issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] #15: Section 7 item 5 is wrong X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:38:24 -0000 Yep - see your point. Going back to the basic point of the tags (and making them very explicit), really the only entity that knows the original target for certain is the UAC. So, I wonder if we shouldn't add a unique tag for that? I think that's the only way to get it right. Mary. On Mon, Aug 30, 2010 at 2:20 PM, sipcore issue tracker wrote: > #15: Section 7 item 5 is wrong > ------------------------------------+------------------------------------= --- > =A0Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0S= tatus: =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= : =A0milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: = =A02.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > ------------------------------------+------------------------------------= --- > =A0Section 7 item 5 says: > =A0 =A0 =A0 =A05. =A0Entry with the index that matches the value of the f= irst entry > =A0 =A0 =A0 =A0with a "mp" hi-target parameter - i.e., the original targe= t of > =A0 =A0 =A0 =A0the request. > > =A0Nope. =A0The first "mp" tagged entry is the first of possibly multiple > =A0diverted-to users, not the original. =A0The original target of the req= uest > =A0never gets the "mp" tag, afaict. > > =A0Unfortunately, determining the original target is not trivial. =A0It's= not > =A0simply the entry before the first "mp" tagged one, since that could be= a > =A0"rc" registered contact, for example. =A0It's also not necessarily the= first > =A0non-"rc" tagged entry before the first "mp" tagged one, because that e= ntry > =A0could just be a intermediate routing operation. =A0And that's a big pr= oblem > =A0with H-I that I don't know how to solve. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:40:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1FA3A6AC4 for ; Tue, 12 Oct 2010 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFxHmdzcluPp for ; Tue, 12 Oct 2010 15:40:10 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3D06A3A6AB3 for ; Tue, 12 Oct 2010 15:40:08 -0700 (PDT) Received: by gyc15 with SMTP id 15so1092990gyc.31 for ; Tue, 12 Oct 2010 15:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Eh7xaQJhb6Ugb9y70ai4xCIbGYayPlQv+lOTRvOx3gI=; b=pfkZfzp10a/nGFid0KfqURHUY0GbxEBwn0HDpqDFhpAG4+55lrWuIgAO4xovu6QxGj 3HsG1fwz+IfTQrtvnogkKHybaRli1ZS1mfbS22wkVrpIMLRlLY2dImokxYgI590qN8uB ArDndM6hOe4dcPKo/+IDACSWFj3DMXit7O/Tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JgEOGkDAPM1+bqkZToX8W9phJz13alNe0K7mlIR0onAwVLGa3b7hNnoZO0lF04u6Oy BpXDSg6UI+Ki8bQ0Ew1X2iZfxrUhnjwbvdFV/bMdTCLGzh/NmG2fODMz6Br4GtUieaQ3 8ep4xp5QPOHTs+A0JIM0ctW9VJPjxVqiuu0XU= MIME-Version: 1.0 Received: by 10.236.108.139 with SMTP id q11mr16245372yhg.32.1286923277221; Tue, 12 Oct 2010 15:41:17 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:41:17 -0700 (PDT) In-Reply-To: <4EC292DB-2BC5-4538-9ABC-219E32217201@acmepacket.com> References: <061.2e221aa118698f4371250faae119a59b@tools.ietf.org> <4EC292DB-2BC5-4538-9ABC-219E32217201@acmepacket.com> Date: Tue, 12 Oct 2010 17:41:17 -0500 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "worley@alum.mit.edu" , "sipcore@ietf.org" Subject: Re: [sipcore] #41: Why does only "mp" have a value? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:40:20 -0000 I don't see what adding another level in the case of mp buys you. In the example (and the usual rule) is that you find the entry with "rc" and you know that the "origin" (as Dale calls it) is the entry just prior - that's why you don't need an additional index for "rc". I don't see that you would mistake this for Carol since the entry prior to the last entry labeled "rc" does not have a tag and thus you go up to the parent to find the original target of the request for that branch. However, I can see that it could facilitate things to add an index for the "rc" just so you can more easily find the entry. Does anyone have a problem with that. Mary. On Tue, Aug 31, 2010 at 7:50 PM, Hadriel Kaplan wr= ote: > > Uh oh... I think your example shows another problem too. > > Suppose atlanta proxy gets a request for Bob as you show, and for Bob it = internally has 2 potential routes. =A0It tries the first, and gets diverted= to Carol, as in your example... but Carol fails. =A0So the atlanta proxy r= ecurses the failure and tries the second route, which is still for *Bob*. = =A0The UAS will get this: > History-Info: ;index=3D1 > History-Info: ;index=3D1.1 > History-Info: ;index=3D1.2;mp=3D1.1 > History-Info: ;index=3D1.3;rc > History-Info: ;index=3D1.4 > History-Info: ;index=3D1.4.1;rc > > If you receive that as a UAS, you don't know whether it was diverted to C= arol and then reached you as being for Carol, or whether it's back to being= for Bob. > Ugh. > > It's a hack, but perhaps a diversion/"mp" should cause a new sub-level. = =A0Like this: > History-Info: ;index=3D1 > History-Info: ;index=3D1.1 > History-Info: ;index=3D1.1.1;mp=3D1.1 > History-Info: ;index=3D1.1.2;rc > History-Info: ;index=3D1.2 > History-Info: ;index=3D1.2.1;rc > > > -hadriel > > > On Aug 31, 2010, at 2:28 PM, sipcore issue tracker wrote: > >> #41: Why does only "mp" have a value? >> ---------------------------------+--------------------------------------= ---- >> Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: >> =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0= new >> Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0milest= one1 >> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: >> Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: >> ---------------------------------+--------------------------------------= ---- >> There seems to be no reason to restrict the "mp-value", the information >> regarding the predecessor request-URI to a newer request-URI, to only "m= p" >> mappings. =A0In particular, if a redirect server implements an "rc" mapp= ing, >> it could be difficult for the UAS to determine why it received the >> request: >> >> {{{ >> =A0 =A0Alice =A0 atlanta.example.com =A0biloxi.example.com =A0 Carol >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 INVITE sip:bob@example.com =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| >> =A0 =A0|--------------->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 INVITE sip:bob@example.com= =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.1 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 300 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Contact: ;mp >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.1 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 INVITE sip:carol@example.c= om >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.1 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.2;mp=3D1.1 >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 300 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Contact: ;rc >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.1 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.2;mp=3D1.1 >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 INVITE sip:carol@192.0.2.3= =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-------------------------------= ->| >> =A0 =A0| History-Info: ;index=3D1 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.1 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1.2;mp=3D1.1 >> =A0 =A0| History-Info: ;index=3D1.3;rc | >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> }}} >> >> (In this case, Carol might know to look for sip:carol@example.com and >> trace its origin, but if we add a further retargeting and registration >> lookup cycle for a different user in the middle, we can defeat that >> strategy.) >> >> It would seem useful to allow the "rc" parameter to have a value as well= . >> And given that some 3xx Contacts will have neither "mp" or "rc", but the >> "origin" value would still be useful for a UAS to see, it seems desirabl= e >> to split off the "origin" value to another parameter which would be >> applied regardless of whether "mp" or "rc" applies. >> >> -- >> Ticket URL: >> sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:40:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE833A6AB3 for ; Tue, 12 Oct 2010 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prQFH7A6R3Np for ; Tue, 12 Oct 2010 15:40:20 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id ABD0F3A6A87 for ; Tue, 12 Oct 2010 15:40:18 -0700 (PDT) Received: by gwb10 with SMTP id 10so43976gwb.31 for ; Tue, 12 Oct 2010 15:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+nh/N9OG5jlja4Urjvi08bWr32EjWypHnW00s59pKxU=; b=AbtDlF6yzvCXKzytdDpYjgtOFJnBQ+ZcgJWXTJ53vpdtwRDDXS6FQO8WjS8P6p3Q7d pXsurIFIeoonj39WtpQzp3pzLjEO7OA82GtTwFTBI0A9h64/8chWl7upJrY2wGEG1ZXs LlAURNACmOzqVxw8Exnr6ZzcdKzW8Bm9tUO5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CSON+4k3wdCLP4Jr9ec8y7foTYuUXp1uxWfmVdqr2IIGD6nuH2O1yRHM63p/rUugvE +gdGw8+VwBGOja+9tP3ap3OjYKOx8+/Sy4HfFMCGxQ9GwvQ+38qPzE6TvHxyE0vy/dgM n9GA1gD0eulbxxS083Yxe7+ZGxRG72FNkaGdE= MIME-Version: 1.0 Received: by 10.236.108.178 with SMTP id q38mr16256475yhg.9.1286923293570; Tue, 12 Oct 2010 15:41:33 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:41:33 -0700 (PDT) In-Reply-To: <064.6c32c8048648b3e859ada9acae1f68a3@tools.ietf.org> References: <064.6c32c8048648b3e859ada9acae1f68a3@tools.ietf.org> Date: Tue, 12 Oct 2010 17:41:33 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] #13: Section 7 item 2 is not complete X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:40:21 -0000 Note, that per my response on #41, if we add an index for the "rc" parameter, then I think this problem goes away. Item 2 in section 7 would then read: Entry with the index that matches the value of the last entry with a "rc" header parameter in the Request received by a UAS - i.e., the Request URI associated with the destination of the request was determined based on an AOR-to-contact binding in an abstract location service. On Mon, Aug 30, 2010 at 2:08 PM, sipcore issue tracker wrote: > #13: Section 7 item 2 is not complete > ------------------------------------+------------------------------------= --- > =A0Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0S= tatus: =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= : =A0milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: = =A02.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > ------------------------------------+------------------------------------= --- > =A0Section 7 item 2 says: > =A0 =A0 =A0 =A02. =A0Entry prior to last entry with hi-target of "rc" in = the Request > =A0 =A0 =A0 =A0received by a UAS - i.e., the Request URI associated with = the > =A0 =A0 =A0 =A0destination of the request was determined based on a Regis= tered > =A0 =A0 =A0 =A0Contact. > > =A0That is only true if no forking occurred, and the request wasn't conta= ct- > =A0routed multiple times in series (i.e., as an SBC might cause). > > =A0A more correct sentence (I think) would be: > =A0 =A0 =A0 2. =A0Last non-"rc" entry of the same branch, prior to last e= ntry with > =A0hi-target of "rc" in the Request > =A0 =A0 =A0 =A0received by a UAS - i.e., the Request URI associated with = the > =A0 =A0 =A0 =A0destination of the request was determined based on a Regis= tered > =A0 =A0 =A0 =A0Contact. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:41:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C793A6AB3 for ; Tue, 12 Oct 2010 15:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbrA9h8keJCh for ; Tue, 12 Oct 2010 15:41:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 4E9CF3A6A87 for ; Tue, 12 Oct 2010 15:41:44 -0700 (PDT) Received: by ywa6 with SMTP id 6so1965833ywa.31 for ; Tue, 12 Oct 2010 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XNv+yoF2EPtpJ0geD1AmRqN3ph7rCcsXr4uDqXzI0WU=; b=LNAsBQE0pz/NevM4JFyIuCvwF1pxr/bNSU5aztPKk+BBzM85aLrnD4fEb+MuqhHhQy lGePvB/Faz+7aBVYRrJ+SaPhp/RDKqJfLErQ/lBE4j74PEb1FP8tIMFYqi5vhe/aoghf Rt6bMQ06R1teEZP4XnHQo/wwsRCigiaFw13H4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=vtYAe1VU4ovNQYDrNpO6vXFVbjlnnj+BbnlqUgQ4ucjW2j4mJZrgnW9eyHJ6fpRGbW C1KjWYdUrCbgMN8Q0EmowNQOaJB0bxa37OFjotQ2yjtfytm9nLeRdqzGxjj5J3DAOLJ7 wB8Fa7SuIt2wH8JF01+ttQn9uYxah566GeH7U= MIME-Version: 1.0 Received: by 10.236.95.165 with SMTP id p25mr16250364yhf.24.1286923377901; Tue, 12 Oct 2010 15:42:57 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:42:57 -0700 (PDT) In-Reply-To: <064.8f061918bd52eb1ab703fa417c4932cd@tools.ietf.org> References: <064.8f061918bd52eb1ab703fa417c4932cd@tools.ietf.org> Date: Tue, 12 Oct 2010 17:42:57 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] #14: Section 7 item 4 is useless or misleading X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:41:45 -0000 That should really read - i.e., "the original AOR" as opposed to "the first registered contact". Also, per the response to #41, I'm proposing to add an index to "rc", so this would be changed to incorporate that as well. And, this might be useful in some situations - it's used in one of the voicemail examples in the callflows document. Mary. On Mon, Aug 30, 2010 at 2:14 PM, sipcore issue tracker wrote: > #14: Section 7 item 4 is useless or misleading > ------------------------------------+------------------------------------= --- > =A0Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0S= tatus: =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= : =A0milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: = =A02.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > ------------------------------------+------------------------------------= --- > =A0Section 7 item 4 says: > =A0 =A0 =A0 =A04. =A0Entry prior to first entry with hi-target of "rc" in= the > =A0Request > =A0 =A0 =A0 =A0received by a UAS - i.e., the first Registered Contact to = which > =A0 =A0 =A0 =A0the request was targeted. > > =A0The entry prior to the first "rc" is NOT the "Registered Contact" (tha= t > =A0would be the first "rc" entry, afaict). =A0But I'm also not sure what = use > =A0this has - if the request got diverted after that entry, or got forked= to > =A0multiple contacts, etc., then using it is useless. =A0More importantly= , it's > =A0dangerous to imply it's useful, because of those other possible > =A0conditions. =A0I recommend removing this item from Section 7. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:42:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0AC3A6AFA for ; Tue, 12 Oct 2010 15:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5PXfciYDP7X for ; Tue, 12 Oct 2010 15:42:38 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 449283A6A22 for ; Tue, 12 Oct 2010 15:42:38 -0700 (PDT) Received: by gwb10 with SMTP id 10so44573gwb.31 for ; Tue, 12 Oct 2010 15:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LSufC3tICnp4nFlxXNguKGaZHwC+q8CGfEEJ2hbKpA0=; b=Nkm5KYXjk0DX5GHNYFrK7hrU8/7CaAeoLuXUdlCmp4sEjVVY+HY2TfaXAS2hssm93d chMQ+TTNZKhNvRMW+BcGC14H8y7NQPrWgNrTch553Qskvra3rtSyiNcjDyeE6BquoOU0 GHldpE9AZdK7aUfasA8I0AnQoOs3Goe7Vd1js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xen35OW1LFymh8/mcV23p7yWgdi2PuY5/4D8c0VUssmx3zms8B2sACt5OEOfyDDtXL 5DSLAjIu+XN0okMBG5JnZLxQVQnqhC23ijosx1/K0r5frLIDXzJzqmqYwY18D9zmnawn fCbz+CD6EmzXSqNnQ5oGNFEGwdfUo39g7A6YI= MIME-Version: 1.0 Received: by 10.236.110.166 with SMTP id u26mr16199121yhg.49.1286923431849; Tue, 12 Oct 2010 15:43:51 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:43:51 -0700 (PDT) In-Reply-To: <061.41eb00508f1b9eea46bd9fec9077b704@tools.ietf.org> References: <061.41eb00508f1b9eea46bd9fec9077b704@tools.ietf.org> Date: Tue, 12 Oct 2010 17:43:51 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] #24: Redirect servers X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:42:39 -0000 Agreed. We'll fix this. On Tue, Aug 31, 2010 at 12:37 PM, sipcore issue tracker wrote: > #24: Redirect servers > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: =A0= milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0In section 4.3, I see: > > =A0 =A0A redirect server MUST NOT add any new History-Info entries. > > =A0How would we handle a situation where proxy A, thinking B is a redirec= t > =A0server, sends the request to B which is actually a proxy that sends th= e > =A0request to a redirect server C, which generates a 3xx response, which = B > =A0passes back to A? =A0From A's point of view, B looks like a redirect s= erver. > =A0But the 3xx that A receives is ultimately generated by C, and its Hist= ory- > =A0Info has one further entry beyond what proxy A would expect to see in = a > =A03xx coming from from proxy B (which it believes to be a redirect serve= r). > =A0So A would think that B is violating this rule. > > =A0I think the solution to this situation is straightforward: =A0Remove t= he > =A0above restriction. =A0The 3xx may have further hi-entry's than A would > =A0expect, but they will be labeled as children of the hi-entry represent= ing > =A0the request from A to B, and so will not confuse any element that is > =A0interpreting the History-Info. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:43:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A222D3A6A22 for ; Tue, 12 Oct 2010 15:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVmkAX1O90Pg for ; Tue, 12 Oct 2010 15:43:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8121F3A6AFA for ; Tue, 12 Oct 2010 15:43:16 -0700 (PDT) Received: by gyc15 with SMTP id 15so1093858gyc.31 for ; Tue, 12 Oct 2010 15:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1oVli1IZxJup6+PH3hae321Q0EgfEDN5nohfZ6t5EEE=; b=cF6iviXPo4tz0IJUgLi9RES19PqrpBlbs3KwbkoS+3BZDVYr9hDqzHzygD8u4M2dlG WAbrknqJClx+xf7TByYFFmBl/aYOkGd6RPAa4PuZnpMyKzrajllsV+Ym8p9aLXYMyJc3 l7fSi2RMtw2VLxBBAJmHLW497GLvOILGgf6sE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K5lK+ZHMv/oR/zpTXTKBK5m6k7udTAhK5ABBGwydGS2Eo19XlEWbktXJU+x1WSvKBr R+xOZwfsqXs2CROo9WcmCa76s8Cm7SPnnNqvVgasDw3DyO+SnqaePVSVDTrYaSjFX8/B GRYxIlhVPAHhwbNAvuN/0SFDFncd08iXSRtxY= MIME-Version: 1.0 Received: by 10.236.102.132 with SMTP id d4mr16243323yhg.45.1286923471597; Tue, 12 Oct 2010 15:44:31 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:44:31 -0700 (PDT) In-Reply-To: <061.84be79a31d19f112d867d818379a27a7@tools.ietf.org> References: <061.84be79a31d19f112d867d818379a27a7@tools.ietf.org> Date: Tue, 12 Oct 2010 17:44:31 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu Subject: Re: [sipcore] #23: Which elements a particular normative passage applies to X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:43:18 -0000 Responses inline below. On Tue, Aug 31, 2010 at 12:34 PM, sipcore issue tracker wrote: > #23: Which elements a particular normative passage applies to > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0n= ew > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0In regard to the general notes in section 4.1: > > =A0 =A0Prior to any application usage of the information by the UAC (e.g.= , > =A0debug), the validity SHOULD be ascertained. =A0The entries SHOULD be > =A0evaluated to determine gaps in indices, which could indicate that an e= ntry > =A0has been maliciously removed. =A0Either way, an application SHOULD be = aware > =A0of potentially missing information. =A0The interpretation of the infor= mation > =A0in the History-Info header by a UAC in a request depends upon the spec= ific > =A0applications supported by the UAC. =A0Application considerations and > =A0guidelines are provided in section 7. > > =A0It's not clear why this is phrased to refer only to UACs, as UASs seem= to > =A0be the most likely application, and in any case, there is no particula= r > =A0limitation the what SIP elements might want to examine History-Info. [MB] This doesn't apply only to UACs - similar text is in the UAS section. Per your suggestion below, we can remove the text in both the UAS can UAC sections and add that statement to section 7. [/MB] =A0A > =A0better phrasing would be: > > =A0 =A0Prior to any application usage of the information by a SIP element > =A0(e.g., debugging of request routing), the validity of the History-Info > =A0values SHOULD be ascertained. =A0An application SHOULD be aware of the > =A0possibility of missing or incorrect values. =A0The interpretation of t= he > =A0information in the History-Info header by a UAS in a request depends u= pon > =A0the specific applications supported by the UAS. =A0Application > =A0considerations and guidelines are provided in section 7. > > =A0This is an instance of a more general exposition problem: =A0Many norm= ative > =A0parts of the exposition specifically identify their target as UAS, UAC= , > =A0proxy, etc. even though the processing described applies to a larger c= lass > =A0of elements. [MB] Dividing the text to normatively describe UAC, UAS and Proxy behavior is standard - it facilitates implementation. And, I do not see alot of redundancy other than what you note above. I can agree that once we fix the redirect server behavior per issue #24 that there might be more common behavior that applies to both. The best way to handle that IMHO is to refer to the appropriate places in the Proxy section. [/MB] > > =A0For instance, there are behaviors that are specific to "any element th= at > =A0receives a request containing History-Info", but (IIRC), the same rule= s > =A0are stated separately for UASs and proxies. > > =A0Similarly, since both proxies and UACs can act on 3xx responses, the r= ules > =A0for handling redirection should be labeled as such. [MB] The behavior for the UAC upon receipt of a 3xx is slightly different than a proxy, so I do not think we can generalize the behavior here - i.e., a UAC may not want to include all the information previously received in the new INVITE. Although, I guess we can debate that. [/MB] > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:44:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3891C3A6A22 for ; Tue, 12 Oct 2010 15:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZfhDupwkJIb for ; Tue, 12 Oct 2010 15:44:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E222A3A6AB3 for ; Tue, 12 Oct 2010 15:44:15 -0700 (PDT) Received: by gyc15 with SMTP id 15so1094124gyc.31 for ; Tue, 12 Oct 2010 15:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FKKZ99BwIWnAcgBPj8i8fD8GGh5lVWCuiVughzTvrAU=; b=eXmzNg4lcbjI9AuJxFT6OxztMQOEoU5/BLtR40cBpUNla0BnRqg5yd7wY536GEIdzM LvrELxLx9p35bufJyjmneUC7erfUPHOkp1NDAAJnkbJEK2AliYyM8/JHSu3ufUdu7p4Z W2DUWisStmWiiMuBC1FmjY2xtobZgWlzzcXgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WmVQOetyVHtBsYY3oLuPrbuIWlq3SPS/i2yzsUdJD2QElZkdd4ztlAx66N9zP4DgrL 6SLqtoXBICrgyJSTmh06ExP67mguSsDSB3yKf0n5dbIWl+BRpu/ywWnRm48DWkzLCotJ Li79Ly/QDT3aijdfrqCY8h+z33EgX76xGgqV4= MIME-Version: 1.0 Received: by 10.236.109.18 with SMTP id r18mr16240508yhg.44.1286923530611; Tue, 12 Oct 2010 15:45:30 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:45:30 -0700 (PDT) In-Reply-To: <061.e906e64be6e4f8357d394097e87839e6@tools.ietf.org> References: <061.e906e64be6e4f8357d394097e87839e6@tools.ietf.org> Date: Tue, 12 Oct 2010 17:45:30 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu Subject: Re: [sipcore] #25: Proxy adding H-I must create element 1. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:44:18 -0000 I will add the MUST set the index to "1" in section 5.1.1., step 1. In addition, I will add that explicity in section 6.3.4. Per the discussion on issue #27, the adding of History-Info is not dependent upon the value of the histinfo option tag. Thanks, Mary. On Tue, Aug 31, 2010 at 12:39 PM, sipcore issue tracker wrote: > #25: Proxy adding H-I must create element 1. > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0In section 5.1.1 Step 1, this should specify that if History-Info is n= ot > =A0already present, the hi-entry that is added must have index "1". =A0Al= so, is > =A0this adding conditional on the presence of "Supported: histinfo"? > > =A0As a matter of definition, this action should be factored out, as it > =A0applies to UASs as well. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:45:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3D13A6B0E for ; Tue, 12 Oct 2010 15:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVT2mIjM7LrJ for ; Tue, 12 Oct 2010 15:45:03 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 70CC73A6B05 for ; Tue, 12 Oct 2010 15:45:03 -0700 (PDT) Received: by gwb10 with SMTP id 10so45354gwb.31 for ; Tue, 12 Oct 2010 15:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B3oA08w8OdBzMJyITLEbJbEDz+s98XzSM1itySQh0RA=; b=ldzmbsSgePmws0dNjoghGSN6zPZk60+8/6oHkPnmmT5Fje3+YmhALrLTvtnkNh76c8 +Ca3i8CWjeZQox/+JLiCGmHxN92Fmyrv5BgUic4C9h7wGVnyHIY0BMDvPDEAtzqEUBjd lZrMjxT7wrsaR4iOStXuSEkGTwddUp2fNgGrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tT7mvRmNXi096O9VX06M87n7RbZajeqHI2kcAgGxINL7IlM88geb4/76Q7N+jIKCHI ImfSs28TkF+3MEa+pBjlGCh16MqtNnSbWP53XBVKMriQ31WHkCckYHxjUl/STR/lV1Fe xSr5fdbMpKm76ovSZi03spr3edBruAhbGM4RY= MIME-Version: 1.0 Received: by 10.236.109.2 with SMTP id r2mr16195318yhg.70.1286923577280; Tue, 12 Oct 2010 15:46:17 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:46:17 -0700 (PDT) In-Reply-To: <061.4cd25bf35d9d11288c4354658a2f732e@tools.ietf.org> References: <061.4cd25bf35d9d11288c4354658a2f732e@tools.ietf.org> Date: Tue, 12 Oct 2010 17:46:17 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] #42: Backwards compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:45:05 -0000 There is text in the last paragraph of section 7 addressing this point - i.e., missing entries. And, both the UAC (4.1) and UAS(4.2.1) sections discuss the potential for missing entries. If you could please suggest additional text or detailed changes if you do not think that is clear. Thanks, Mary. On Tue, Aug 31, 2010 at 1:35 PM, sipcore issue tracker wrote: > #42: Backwards compatibility > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0mile= stone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0A particularly common backwards compatibility problem will be the pres= ence > =A0of proxies that do not implement H-I, and therefore cause H-I to not l= og > =A0some changes of request-URI. =A0This is to some degree mitigated by ha= ving > =A0downstream H-I-implementing elements insert hi-entry's on their behalf= . > > =A0But there should be a discussion of this situation and its effect on t= he > =A0H-I entry-tree. =A0This (1) allows us to verify that the problem has b= een > =A0thought through and won't cause any insurmountable problems and (2) wa= rns > =A0application developers of the abnormalities in the H-I entry-tree that > =A0might be caused by this situation. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:45:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D483A6A22 for ; Tue, 12 Oct 2010 15:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J9iHiGS5Xzr for ; Tue, 12 Oct 2010 15:45:21 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4004A3A6AB3 for ; Tue, 12 Oct 2010 15:45:21 -0700 (PDT) Received: by gxk20 with SMTP id 20so1977189gxk.31 for ; Tue, 12 Oct 2010 15:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wo+VtgYTRx5pnrumhweQzFAZqsavm9DqtrniZoWwnp4=; b=o9ytXh/9j24jWp/nDdcFg9Jw4QGl285dD5ezkjFil4jsA4jphUrUNUuNIaln5AQLWi xunE/QmKMEHmBJHc2jVCMVrIn9N1U0RLzGotcc8UibHriQO8TfS5TKPo29kC1J7R61q0 dg3NjJk83PEBFGTYxrnwFQgZISpF4az3ehTzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=yHfcjLSIzGlWu8hNUPvibIALIR5ijoSOHyR8DZlVfGA6kZ5kP9+pARfDQPhTcDpSyn vqStOrMyDBnsbHvdLbyRb4olc5kxt1TNloSjXXU9CUEt2iW6dPkqRCnGLC0IawV9KgFL L0tmcV50KyJiquIh8CxSok6u1bBPslk8Hl6Po= MIME-Version: 1.0 Received: by 10.236.95.138 with SMTP id p10mr16215924yhf.87.1286923594618; Tue, 12 Oct 2010 15:46:34 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:46:34 -0700 (PDT) In-Reply-To: <061.c9aa7ca46d7e5e9f56751b89fb04d433@tools.ietf.org> References: <061.c9aa7ca46d7e5e9f56751b89fb04d433@tools.ietf.org> Date: Tue, 12 Oct 2010 17:46:34 -0500 Message-ID: From: Mary Barnes To: sipcore issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu, sipcore@ietf.org Subject: Re: [sipcore] #35: "target parameter" is used but seems to have no meaning X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:45:22 -0000 This is referring to the "hi-target" parameter defined for the History-Info header that has values of either "rc" or "mp=3Dx". I can change the references to "target" to hi-target. Thanks, Mary. On Tue, Aug 31, 2010 at 1:10 PM, sipcore issue tracker wrote: > #35: "target parameter" is used but seems to have no meaning > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: =A0= milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0In various places reference is made to a "target parameter" for hi- > =A0entry's. =A0An extreme example is section 11.1, where "target" is quot= ed as > =A0if giving the actual name of the parameter. =A0But there is no "target= " > =A0parameter per se; there are two (mutually exclusive) parameters, "rc" = and > =A0"mp", that are collectively called "the target parameter". =A0This beg= s for > =A0better terminology. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:45:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B283A6B21 for ; Tue, 12 Oct 2010 15:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw2LqmkGrVEr for ; Tue, 12 Oct 2010 15:45:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D25653A6B1C for ; Tue, 12 Oct 2010 15:45:41 -0700 (PDT) Received: by gwb10 with SMTP id 10so45531gwb.31 for ; Tue, 12 Oct 2010 15:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2XncDWUrFsulIp6FjYwzddbPeHKgTRqHSkRjcmSHJ6c=; b=ee2pJrVJXNIA7163U2mg+HltEYlrC8JVrHi52r9bED+DLuWIOwzG7kDhkpV0mSaGGb 161ld994DXCiHKK0WmUkfduug9ovxgh50uLPeSY7a9a5+qD4MYWG8yIuoDv5tH+/KPYH DopnonJPk3cxiO3Hd1s5JBvw8ffDiJGRE2xtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mU8Lfos3HLfW5lUbNkrmGV5fEyHprxrI1A7qoscSy/RHU8Pem7bdmZ7hYmj4+Fa78n PKpVN7nwuheQ/0l1l+bCTMWqOBZHume0nU0bl0LeBF/y/OMx15SWOYFnN7MEKs9QVcOg K71TSskU7TFQ255/jDaBnoppfmaCHS6+mvIXI= MIME-Version: 1.0 Received: by 10.150.146.14 with SMTP id t14mr9291974ybd.421.1286923616850; Tue, 12 Oct 2010 15:46:56 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:46:56 -0700 (PDT) In-Reply-To: <061.a74db9472c31e13651a0ab46005b8128@tools.ietf.org> References: <061.a74db9472c31e13651a0ab46005b8128@tools.ietf.org> Date: Tue, 12 Oct 2010 17:46:56 -0500 Message-ID: From: Mary Barnes To: sipcore issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu, sipcore@ietf.org Subject: Re: [sipcore] #40: Clarify mp-value X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:45:48 -0000 The rules for the mp parameter are described in section 6.3.1. However, I can see that it adds some clarity if we include text something like you note below in section 6.3.5. Thanks, Mary. On Tue, Aug 31, 2010 at 1:22 PM, sipcore issue tracker wrote: > #40: Clarify mp-value > ---------------------------------+---------------------------------------= --- > =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: =A0= milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: > =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: > ---------------------------------+---------------------------------------= --- > =A0In section 6.3.5, the rules for the value part of the mp parameter of = an > =A0hi-entry aren't given very clearly, but the idea seems to be that the > =A0value is the index of the hi-entry that contains the URI which was map= ped > =A0into the request-URI of this hi-entry. =A0There seem to be two cases: > > =A0- The mapping was done by the proxy on its own authority, in which cas= e > =A0the mp-value is the parent index of the hi-entry's index. > > =A0- The mapping was done due to receiving a 3xx response, in which case = the > =A0mp-value is an earlier sibling of the hi-entry's index, that of the > =A0downstream request which received the 3xx response. > > -- > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 12 15:47:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1F83A6B13 for ; Tue, 12 Oct 2010 15:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4em23y3sdFdP for ; Tue, 12 Oct 2010 15:46:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 244953A6B0E for ; Tue, 12 Oct 2010 15:46:53 -0700 (PDT) Received: by gxk20 with SMTP id 20so1977586gxk.31 for ; Tue, 12 Oct 2010 15:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m11Rc5wLKUIXkzhIXBaSOjFjUNoGVbAVicr/pvlQpog=; b=mOMB5F2FwVQn69mn2m6Uo4N+AzHrphY2ByDeEL7vC1BrFHdr29jlEcR3h3HsuO0naX 0YOYtlNrCS2y5y9JVehQO5PxZEFwNVkiEJEjNr3eARyb2EfWBHYFAt7KjqJFptb1Tb0N IC5q7LbF4gu6QTCvsNXRfa4x6Thscz/MtO2t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uEsaXySzpZwlVIq8w2qysc13WuleryMFhHUcLchnwocKm63vR2HFoDzonS2BQUlz3c 4eBhpPOuvT6RQxVFYGtAix3psARZ8pT/a2XB+urbJJFxPsrBE/5Gwoae9WStkPEvbINg 6+yH97MC8PqxDP0z+BO7R4qOsrQ/T+ig6LPRg= MIME-Version: 1.0 Received: by 10.236.109.44 with SMTP id r32mr16258692yhg.16.1286923688219; Tue, 12 Oct 2010 15:48:08 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Tue, 12 Oct 2010 15:48:08 -0700 (PDT) In-Reply-To: References: <061.0a5978795ae778ef21b5c72dd4fd4248@tools.ietf.org> Date: Tue, 12 Oct 2010 17:48:08 -0500 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] #34: Semantics of History-Info values need to be documented explicitly X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:47:01 -0000 Dale, This text seems redundant for the most part and past criticisms of 4244 were that there was too much redundant text. This sounds something similar to Hadriel's issue 1 about there not really being an overview of operations - I am adding text to address that concern. However, if you an point me to another RFC that follows the model you are suggesting, then I can try to craft the appropriate text. ISTM though that to be completely accurate, you have to rewrite all the normative text in a different manner. Thanks, Mary. On Fri, Sep 3, 2010 at 1:16 PM, Worley, Dale R (Dale) w= rote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Ma= ry Barnes [mary.ietf.barnes@gmail.com] > > You'll have to send text on this one - it's not clear to me at all > what you are talking about. > _______________________________________________ > > Here's a start: > > The History-Info header field(s) of a request contain a sequence of > hi-entrys. > > Each hi-entry contains an 'index' parameter. =A0The values of the 'index' > parameters organize the hi-entrys into a tree, with each hi-entry > being a child of the hi-entry whose index is the same except for the > final ("." 1*DIGIT) being removed. =A0The hi-entrys whose 'index' value > is just 1*DIGIT are the children of an implicit root hi-entry. > > The child hi-entrys of an hi-entry have as their final 1*DIGIT > distinct consecutive integers starting with 1. [Question: =A0Are the > values required to be consecutive?] > > The hi-entrys appear in preorder, the lexicographic ordering of their > 'index' values. =A0[Question: Are the hi-entrys constrained to appear in > this order?] > > The hi-entrys correspond to requests that are derived from one initial > out-of-dialog request, that is requests that share their Call-Id and > CSeq values, and have no to-tag. =A0An hi-entry's parent hi-entry > corresponds to its immediate predecessor request, that is, the one > which contains all of its Vias except the topmost. =A0An hi-entry with > only one 1*DIGIT in its 'index' value corresponds to a request with > one Via, that is, one sent by the UAC. > > The last hi-entry corresponds to the request containing this > History-Info header field. =A0[Question: =A0Is this true? =A0Or is the > hi-entry that corresponds to the containing request marked in some > other way?] > > An hi-entry's name-addr contains as its URI either the request-URI of > the corresponding request, or "sip:anonymous@anonymous.invalid" (to > indicate that the request-URI is being hidden). =A0[Note that the actual > anonymous value is not specified in 4244bis.] > > If an hi-entry contains a *** or *** parameter, then the request-URI > of the corresponding request was derived by the proxy from the > request-URI of its parent by the corresponding process. > > If an hi-entry contains a *** or *** parameter, then the request-URI > of the corresponding request was obtained from a 3xx response to the > request corresponding to the hi-entry whose 'index' value is the value > of the parameter. =A0The parameter was obtained from the corresponding > header parameter of the Contact header field of the 3xx response, and > indicates that the generator of the 3xx response indicated that the > Contact URI was derived by the corresponding process. > > Dale > From gao.yang2@zte.com.cn Wed Oct 13 01:12:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FEF3A67D4 for ; Wed, 13 Oct 2010 01:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.072 X-Spam-Level: X-Spam-Status: No, score=-100.072 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrNRlT0JYZYq for ; Wed, 13 Oct 2010 01:12:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 80E383A67B6 for ; Wed, 13 Oct 2010 01:12:57 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Wed, 13 Oct 2010 16:11:43 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.3337783744; Wed, 13 Oct 2010 16:13:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9D8Ar7M013547; Wed, 13 Oct 2010 16:10:53 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DB6B2E@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Oct 2010 16:08:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-13 16:10:40, Serialize complete at 2010-10-13 16:10:40 Content-Type: multipart/alternative; boundary="=_alternative 002CE9FD482577BB_=" X-MAIL: mse3.zte.com.cn o9D8Ar7M013547 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 08:12:59 -0000 This is a multipart message in MIME format. --=_alternative 002CE9FD482577BB_= Content-Type: text/plain; charset="US-ASCII" > As far as I know, there are no explicit restrictions. > > One could, however, ask whether it's allowed to include headers that > are not to be used in the triggered INVITE, but in later associated requests. RFC3261 section 19.1.5 An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI. An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis. An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route. >From the above text, it seams that the rules for embedded headers is not as emphatic as transport, maddr, ttl and user parameter. So, I suggest that one specific embedded headers could have a specific usage guidelines, especially these headers with dangerous header fields. I'd like to point out that I am not going to say that people's understanding of embedded headers(for pure audio usage) is not correct. > You CAN also embed SDP information. Are there any defined rules for such embedded SDP information? If there are, could you show me. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002CE9FD482577BB_= Content-Type: text/html; charset="US-ASCII"

> As far as I know, there are no explicit restrictions.
>
> One could, however, ask whether it's allowed to include headers that
> are not to be used in the triggered INVITE, but in later associated requests.
RFC3261 section 19.1.5

An implementation MUST include any provided transport, maddr, ttl, or
   user parameter in the Request-URI of the formed request.  If the URI
   contains a method parameter, its value MUST be used as the method of
   the request.  The method parameter MUST NOT be placed in the
   Request-URI.  Unknown URI parameters MUST be placed in the message's
   Request-URI.

   An implementation SHOULD treat the presence of any headers or body
   parts in the URI as a desire to include them in the message, and
   choose to honor the request on a per-component basis.

An implementation SHOULD NOT honor these obviously dangerous header
   fields: From, Call-ID, CSeq, Via, and Record-Route.

From the above text, it seams that the rules for embedded headers is not as emphatic as transport, maddr, ttl and user parameter. So, I suggest that one specific embedded headers could have a specific usage guidelines, especially these headers with dangerous header fields.

I'd like to point out that I am not going to say that people's understanding of embedded headers(for pure audio usage) is not correct.

> You CAN also embed SDP information.
Are there any defined rules for such embedded SDP information? If there are, could you show me.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002CE9FD482577BB_=-- From gao.yang2@zte.com.cn Wed Oct 13 01:32:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF883A682B for ; Wed, 13 Oct 2010 01:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.417 X-Spam-Level: X-Spam-Status: No, score=-100.417 tagged_above=-999 required=5 tests=[AWL=1.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clJZfwkDqZtJ for ; Wed, 13 Oct 2010 01:32:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 5E96D3A6807 for ; Wed, 13 Oct 2010 01:32:30 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Wed, 13 Oct 2010 16:31:18 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 38058.1967002180; Wed, 13 Oct 2010 16:31:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9D8Xs5Z040559; Wed, 13 Oct 2010 16:33:56 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Worley, Dale R (Dale)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Oct 2010 16:31:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-13 16:33:43, Serialize complete at 2010-10-13 16:33:43 Content-Type: multipart/alternative; boundary="=_alternative 002F0599482577BB_=" X-MAIL: mse3.zte.com.cn o9D8Xs5Z040559 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 08:32:32 -0000 This is a multipart message in MIME format. --=_alternative 002F0599482577BB_= Content-Type: text/plain; charset="US-ASCII" > In regard to how the recipient of the REFER is expected to see the > embedded header, the semantics are extremely well defined: The > recipient is to use the text provided to construct a Replaces header > (or a Join header, or whatever). The recipient is *not* to have any > other understanding of the embedded header. If additional > information is to be conveyed to the recipient of the REFER, some > other method must be found for conveying that information. Please refer to my response to Christer. It seams that the rules for embedded headers is not as emphatic as transport, maddr, ttl and user parameter. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002F0599482577BB_= Content-Type: text/html; charset="US-ASCII"


> In regard to how the recipient of the REFER is expected to see the
> embedded header, the semantics are extremely well defined:  The
> recipient is to use the text provided to construct a Replaces header
> (or a Join header, or whatever).  The recipient is *not* to have any
> other understanding of the embedded header.  If additional
> information is to be conveyed to the recipient of the REFER, some
> other method must be found for conveying that information.
Please refer to my response to Christer. It seams that the rules for embedded headers is not as emphatic as transport, maddr, ttl and user parameter.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002F0599482577BB_=-- From keith.drage@alcatel-lucent.com Wed Oct 13 02:03:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFAC3A6917 for ; Wed, 13 Oct 2010 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-1.753, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtglDJbmG3md for ; Wed, 13 Oct 2010 02:03:22 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id A94A73A67A3 for ; Wed, 13 Oct 2010 02:03:21 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9D94EBh005061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Oct 2010 11:04:31 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 13 Oct 2010 11:04:25 +0200 From: "DRAGE, Keith (Keith)" To: "gao.yang2@zte.com.cn" , Paul Kyzivat , Christer Holmberg Date: Wed, 13 Oct 2010 11:04:26 +0200 Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] Thread-Index: ActqJNTxLiMwBwZRS7uah49ABoE32wAkJFow Message-ID: References: <4CA0AE61.7060003@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21748FFCDFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:03:23 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21748FFCDFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWN0dWFsbHkgM0dQUCBkb2VzIG5vdC4gSXQgaXMgdW5kZXIgZGlzY3Vzc2lvbiwgYnV0IG5vIENS IGhhcyB5ZXQgYmVlbiBhcHByb3ZlZC4gVGhhdCBtaWdodCB3ZWxsIGhhcHBlbiBieSBEZWNlbWJl ciwgYnV0IGl0IGhhcyBub3QgeWV0Lg0KDQpLZWl0aA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZ2FvLnlhbmcyQHp0ZS5jb20uY24NClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTIsIDIwMTAgNDo0NSBQTQ0KVG86IFBhdWwgS3l6aXZhdDsg Q2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Np cGNvcmVdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0dXJlIFt3 YXM6IEZlYXR1cmUtdGFncyBpbiB0aGUgUGF0aCBoZWFkZXIgZmllbGRdDQoNCg0KSGkgUGF1bCBh bmQgQ2hyaXN0ZXIsDQoNCldlIG5vdyB1c2UgdGhpcyBkcmFmdCBpbiBvdXIgSU1TKDNHUFAncyBT UlZDQyksIGN1cnJlbnRseSBpbiBzdGFuZGFyZCBsZXZlbC4NCg0KU28sIHdlIHN1cHBvcnQgdGhp cyBvbmUuDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpaaXAgICAgOiAyMTAwMTINClRlbCAgICA6IDg3MjExDQpUZWwyICAgOigrODYpLTAy NS01Mjg3NzIxMQ0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQoNCg0KUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBjaXNjby5j b20+DQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMC0wOS0yNyAyMjo0 Ng0KDQrK1bz+yMsNCkNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+DQqzrcvNDQoic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98zi DQpSZTogW3NpcGNvcmVdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1m ZWF0dXJlIFt3YXM6IEZlYXR1cmUtdGFncyBpbiB0aGUgUGF0aCBoZWFkZXIgZmllbGRdDQoNCg0K DQoNCg0KW2FzIGNoYWlyXQ0KDQpUbyBhbGwgc2lwY29yZSBwYXJ0aWNpcGFudHM6DQoNCkNocmlz dGVyIGhhcyBiZWVuIGxvb2tpbmcgZm9yIGEgd2F5IHRvIGFjY29tcGxpc2ggYSBwYXJ0aWN1bGFy IGZ1bmN0aW9uDQp0aGF0IDNncHAgd2FudHMuIFRoaXMgcHJvcG9zYWwgc2VlbXMgYSBwbGF1c2li bGUgd2F5IHRvIGRvIHRoYXQuIEJ1dCBpdA0KaXMgb2YgbmVjZXNzaXR5IGRlZmluaW5nIGEgbW9y ZSBnZW5lcmFsIG1lY2hhbmlzbS4NCg0KSSdkIHJlYWxseSBhcHByZWNpYXRlIGNvbW1lbnRzIGZy b20gb3RoZXJzIChpbmNsdWRpbmcgcGVvcGxlIGluIG5vIHdheQ0KaW52b2x2ZWQgd2l0aCAzZ3Bw KSByZWdhcmRpbmcgdGhpcyBtZWNoYW5pc20uIEZvciBpbnN0YW5jZSwgZG8geW91DQpjb25zaWRl ciB0aGUgc2VtYW50aWNzIHRvIGJlIHdlbGwgZGVmaW5lZD8gRG8geW91IHNlZSBuZWVkIGZvciBt b3JlDQphYm91dCBzZWN1cml0eSBpbXBsaWNhdGlvbnM/DQoNCkhvdyBtYW55IHdvdWxkIGZpbmQg dGhpcyB1c2VmdWwgdG8gaGF2ZT8NCg0KICAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAg ICAgICAgICBQYXVsDQoNCk9uIDkvMjQvMjAxMCA3OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3 cm90ZToNCj4NCj4gSGksDQo+DQo+IEkndmUgc3VibWl0dGVkIGEgZHJhZnQsIHdoaWNoIGV4dGVu ZHMgdGhlIHJyLXBhcmFtIHJ1bGUsIGFsbG93aW5nIHByb3hpZXMgdG8gaW5kaWNhdGUgc3VwcG9y dGVkIGZlYXR1cmVzIHVzaW5nIGZlYXR1cmUgdGFncyBpbiBQYXRoLCBSZWNvcmQtUm91dGUgZXRj Lg0KPg0KPiBUaGUgZHJhZnQgY2FuIGFsc28gYmUgZm91bmQgYXQ6IGh0dHA6Ly91c2Vycy5waXVo YS5uZXQvY2hvbG1iZXIvZHJhZnRzL2RyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVy ZS0wMC50eHQNCj4NCj4gQXMgSSBpbmRpY2F0ZWQgZWFybGllciBvbiB0aGUgbGlzdCwgYW5kIGFz IHlvdSBjYW4gcmVhZCBpbiB0aGUgZHJhZnQsIHRoZXJlIGlzIGEgM0dQUCB1c2UtY2FzZSB3aGVy ZSB3ZSBiZWxpZXZlIHRoZSBtZWNoYW5pc20gY291bGQgYmUgdXNlZC4gQnV0LCB0aGVyZSBpcyBu b3RoaW5nIDNHUFAgc3BlY2lmaWMgYWJvdXQgdGhlIG1lY2hhbmlzbSBhcyBzdWNoLg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K DQo= --_000_EDC0A1AE77C57744B664A310A0B23AE21748FFCDFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Actually 3GPP does not. It is under discussion, bu= t no CR=20 has yet been approved. That might well happen by December, but it has not=20 yet.
 
Keith

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 gao.yang2@zte.com.cn
Sent: Tuesday, October 12, 2010 4:45=20 PM
To: Paul Kyzivat; Christer Holmberg
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Draft new:=20 draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path heade= r=20 field]


Hi Paul and Christer,=20

We now use this draft in our IMS= (3GPP's=20 SRVCC), currently in standard level.

So, we support this one.

Thanks,

Gao=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
= Tel=20    : 87211
Tel2   :(+86)-025-52877211
e_mail :=20 gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20


Paul Kyzivat=20 <pkyzivat@cisco.com>
=B7=A2=BC=FE=C8=CB:  sipcore-bounces@ietf.org= =20

2010-09-27 22:46

=CA=D5=BC= =FE=C8=CB
Christer Holmberg=20 <christer.holmberg@ericsson.com>=20
=B3=AD=CB= =CD
"sipcore@ietf.org"=20 <sipcore@ietf.org>=20
=D6=F7=CC= =E2
Re: [sipcore] Draft new:=20 draft-holmberg-sipcore-proxy-feature [was: Feature-tags in th= e=20 Path header field]





<= TT>[as chair]

To all sipcore participants:

Christer h= as been=20 looking for a way to accomplish a particular function
that 3gpp wants= .=20 This proposal seems a plausible way to do that. But it
is of necessit= y=20 defining a more general mechanism.

I'd really appreciate comments = from=20 others (including people in no way
involved with 3gpp) regarding this= =20 mechanism. For instance, do you
consider the semantics to be well def= ined?=20 Do you see need for more
about security implications?

How many= =20 would find this useful to have?

         = =20       Thanks,
           = =20     Paul

On 9/24/2010 7:04 AM, Christer Holmberg=20 wrote:
>
> Hi,
>
> I've submitted a draft, which= =20 extends the rr-param rule, allowing proxies to indicate supported feature= s=20 using feature tags in Path, Record-Route etc.
>
> The draft c= an=20 also be found at:=20 http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-featu= re-00.txt
>
>=20 As I indicated earlier on the list, and as you can read in the draft, the= re is=20 a 3GPP use-case where we believe the mechanism could be used. But, there = is=20 nothing 3GPP specific about the mechanism as such.
>
>=20 Regards,
>
>=20 Christer
_______________________________________________
sipcore ma= iling=20 list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore= 



------------------------------------------=
--------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_EDC0A1AE77C57744B664A310A0B23AE21748FFCDFRMRSSXCHMBSC3d_-- From gao.yang2@zte.com.cn Wed Oct 13 02:31:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74983A69AF for ; Wed, 13 Oct 2010 02:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.368 X-Spam-Level: X-Spam-Status: No, score=-98.368 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+jaVmPyn71u for ; Wed, 13 Oct 2010 02:31:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D1AC73A696E for ; Wed, 13 Oct 2010 02:31:20 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Wed, 13 Oct 2010 17:30:01 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 38058.6983113649; Wed, 13 Oct 2010 17:29:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9D9Wb9n006146; Wed, 13 Oct 2010 17:32:37 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Oct 2010 17:30:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-13 17:32:23, Serialize complete at 2010-10-13 17:32:23 Content-Type: multipart/alternative; boundary="=_alternative 003464EA482577BB_=" X-MAIL: mse3.zte.com.cn o9D9Wb9n006146 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:31:28 -0000 This is a multipart message in MIME format. --=_alternative 003464EA482577BB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBqdXN0IHNob3dlZCB0aGUgdmVuZG9yJ3Mgdmlld3BvaW50LiANCg0KSXQgaXMgYmV0dGVyIHRv IHJlcGxhY2VzICJvdXIgSU1TKDNHUFAnIFNSVkNDKSIgYnkgIm91ciBJTVMoU1JWQ0MpIi4gU28s IEkgDQptZWFucyAiV2Ugbm93IHVzZSB0aGlzIGRyYWZ0IGluIG91ciBJTVMoU1JWQ0MpLCBjdXJy ZW50bHkgaW4gc3RhbmRhcmQgDQpsZXZlbC4iIA0KDQpBbmQgd2hhdCBJIG1lYW5zIGFib3V0ICJp biBzdGFuZGFyZCBsZXZlbCIsIGlzIHRoYXQgWlRFJ3MgM0dQUCBwZW9wbGUgDQpzdXBwb3J0IHRo aXMgb25lIG5vdy4gQW5kIGNvbnNpZGVyaW5nIHN5c3RlbSBsZXZlbCwgd2Ugd2lsbCBzdXBwb3J0 IHRoZSANCmZpbmFsIGFwcHJvdmVkIG9uZS4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4 NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiRFJB R0UsIEtlaXRoIChLZWl0aCkiIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+IA0KMjAx MC0xMC0xMyAxNzowNA0KDQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5n MkB6dGUuY29tLmNuPiwgUGF1bCBLeXppdmF0IA0KPHBreXppdmF0QGNpc2NvLmNvbT4sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQqzrcvNDQoic2lw Y29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSRTogW3NpcGNvcmVdIERy YWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0dXJlIFt3YXM6IA0KRmVh dHVyZS10YWdzIGluIHRoZSBQYXRoIGhlYWRlciBmaWVsZF0NCg0KDQoNCg0KDQoNCkFjdHVhbGx5 IDNHUFAgZG9lcyBub3QuIEl0IGlzIHVuZGVyIGRpc2N1c3Npb24sIGJ1dCBubyBDUiBoYXMgeWV0 IGJlZW4gDQphcHByb3ZlZC4gVGhhdCBtaWdodCB3ZWxsIGhhcHBlbiBieSBEZWNlbWJlciwgYnV0 IGl0IGhhcyBub3QgeWV0Lg0KIA0KS2VpdGgNCg0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiBnYW8u eWFuZzJAenRlLmNvbS5jbg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMiwgMjAxMCA0OjQ1IFBN DQpUbzogUGF1bCBLeXppdmF0OyBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IHNpcGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1zaXBj b3JlLXByb3h5LWZlYXR1cmUgDQpbd2FzOiBGZWF0dXJlLXRhZ3MgaW4gdGhlIFBhdGggaGVhZGVy IGZpZWxkXQ0KDQoNCkhpIFBhdWwgYW5kIENocmlzdGVyLCANCg0KV2Ugbm93IHVzZSB0aGlzIGRy YWZ0IGluIG91ciBJTVMoM0dQUCdzIFNSVkNDKSwgY3VycmVudGx5IGluIHN0YW5kYXJkIA0KbGV2 ZWwuIA0KDQpTbywgd2Ugc3VwcG9ydCB0aGlzIG9uZS4gDQoNClRoYW5rcywgDQoNCkdhbyANCg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClppcCAgICA6IDIxMDAxMg0KVGVs ICAgIDogODcyMTENClRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQplX21haWwgOiBnYW8ueWFu ZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQoNCg0K UGF1bCBLeXppdmF0IDxwa3l6aXZhdEBjaXNjby5jb20+IA0Kt6K8/sjLOiAgc2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnIA0KMjAxMC0wOS0yNyAyMjo0NiANCg0KDQrK1bz+yMsNCkNocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0Ks63LzQ0KInNpcGNvcmVA aWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPiANCtb3zOINClJlOiBbc2lwY29yZV0gRHJhZnQg bmV3OiBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUgW3dhczogDQpGZWF0dXJl LXRhZ3MgaW4gdGhlIFBhdGggaGVhZGVyIGZpZWxkXQ0KDQoNCg0KDQoNCg0KDQoNClthcyBjaGFp cl0NCg0KVG8gYWxsIHNpcGNvcmUgcGFydGljaXBhbnRzOg0KDQpDaHJpc3RlciBoYXMgYmVlbiBs b29raW5nIGZvciBhIHdheSB0byBhY2NvbXBsaXNoIGEgcGFydGljdWxhciBmdW5jdGlvbiANCnRo YXQgM2dwcCB3YW50cy4gVGhpcyBwcm9wb3NhbCBzZWVtcyBhIHBsYXVzaWJsZSB3YXkgdG8gZG8g dGhhdC4gQnV0IGl0IA0KaXMgb2YgbmVjZXNzaXR5IGRlZmluaW5nIGEgbW9yZSBnZW5lcmFsIG1l Y2hhbmlzbS4NCg0KSSdkIHJlYWxseSBhcHByZWNpYXRlIGNvbW1lbnRzIGZyb20gb3RoZXJzIChp bmNsdWRpbmcgcGVvcGxlIGluIG5vIHdheSANCmludm9sdmVkIHdpdGggM2dwcCkgcmVnYXJkaW5n IHRoaXMgbWVjaGFuaXNtLiBGb3IgaW5zdGFuY2UsIGRvIHlvdSANCmNvbnNpZGVyIHRoZSBzZW1h bnRpY3MgdG8gYmUgd2VsbCBkZWZpbmVkPyBEbyB5b3Ugc2VlIG5lZWQgZm9yIG1vcmUgDQphYm91 dCBzZWN1cml0eSBpbXBsaWNhdGlvbnM/DQoNCkhvdyBtYW55IHdvdWxkIGZpbmQgdGhpcyB1c2Vm dWwgdG8gaGF2ZT8NCg0KICAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICAgICAgICBQ YXVsDQoNCk9uIDkvMjQvMjAxMCA3OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4N Cj4gSGksDQo+DQo+IEkndmUgc3VibWl0dGVkIGEgZHJhZnQsIHdoaWNoIGV4dGVuZHMgdGhlIHJy LXBhcmFtIHJ1bGUsIGFsbG93aW5nIA0KcHJveGllcyB0byBpbmRpY2F0ZSBzdXBwb3J0ZWQgZmVh dHVyZXMgdXNpbmcgZmVhdHVyZSB0YWdzIGluIFBhdGgsIA0KUmVjb3JkLVJvdXRlIGV0Yy4NCj4N Cj4gVGhlIGRyYWZ0IGNhbiBhbHNvIGJlIGZvdW5kIGF0OiANCmh0dHA6Ly91c2Vycy5waXVoYS5u ZXQvY2hvbG1iZXIvZHJhZnRzL2RyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZS0w MC50eHQNCg0KPg0KPiBBcyBJIGluZGljYXRlZCBlYXJsaWVyIG9uIHRoZSBsaXN0LCBhbmQgYXMg eW91IGNhbiByZWFkIGluIHRoZSBkcmFmdCwgDQp0aGVyZSBpcyBhIDNHUFAgdXNlLWNhc2Ugd2hl cmUgd2UgYmVsaWV2ZSB0aGUgbWVjaGFuaXNtIGNvdWxkIGJlIHVzZWQuIA0KQnV0LCB0aGVyZSBp cyBub3RoaW5nIDNHUFAgc3BlY2lmaWMgYWJvdXQgdGhlIG1lY2hhbmlzbSBhcyBzdWNoLg0KPg0K PiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0K YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9w ZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlv biBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0 byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hv bSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZp ZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFs IHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003464EA482577BB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkganVzdCBzaG93ZWQgdGhlIHZl bmRvcidzIHZpZXdwb2ludC4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+SXQgaXMgYmV0dGVyIHRvIHJlcGxhY2VzICZxdW90O291ciBJTVMoM0dQUCcN ClNSVkNDKSZxdW90OyBieSAmcXVvdDtvdXIgSU1TKFNSVkNDKSZxdW90Oy4gU28sIEkgbWVhbnMg JnF1b3Q7V2Ugbm93IHVzZQ0KdGhpcyBkcmFmdCBpbiBvdXIgSU1TKFNSVkNDKSwgY3VycmVudGx5 IGluIHN0YW5kYXJkIGxldmVsLiZxdW90OyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkFuZCB3aGF0IEkgbWVhbnMgYWJvdXQgJnF1b3Q7aW4gc3RhbmRh cmQNCmxldmVsJnF1b3Q7LCBpcyB0aGF0IFpURSdzIDNHUFAgcGVvcGxlIHN1cHBvcnQgdGhpcyBv bmUgbm93LiBBbmQgY29uc2lkZXJpbmcNCnN5c3RlbSBsZXZlbCwgd2Ugd2lsbCBzdXBwb3J0IHRo ZSBmaW5hbCBhcHByb3ZlZCBvbmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAm bmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0K IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcy QHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtE UkFHRSwgS2VpdGggKEtlaXRoKSZxdW90Ow0KJmx0O2tlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50 LmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDEwLTEwLTEzIDE3OjA0PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O2dhby55YW5nMkB6dGUuY29tLmNuJnF1b3Q7ICZsdDtnYW8u eWFuZzJAenRlLmNvbS5jbiZndDssDQpQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNv bSZndDssIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZs dDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtzaXBjb3JlXSBE cmFmdCBuZXc6IGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZQ0KW3dhczogRmVh dHVyZS10YWdzIGluIHRoZSBQYXRoIGhlYWRlciBmaWVsZF08L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ QWN0dWFsbHkgM0dQUCBkb2VzIG5vdC4gSXQgaXMNCnVuZGVyIGRpc2N1c3Npb24sIGJ1dCBubyBD UiBoYXMgeWV0IGJlZW4gYXBwcm92ZWQuIFRoYXQgbWlnaHQgd2VsbCBoYXBwZW4NCmJ5IERlY2Vt YmVyLCBidXQgaXQgaGFzIG5vdCB5ZXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPktlaXRoPC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkZyb206PC9iPiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmdhby55YW5nMkB6 dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTIsIDIwMTAgNDo0 NSBQTTxiPjxicj4NClRvOjwvYj4gUGF1bCBLeXppdmF0OyBDaHJpc3RlciBIb2xtYmVyZzxiPjxi cj4NCkNjOjwvYj4gc2lwY29yZUBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3Np cGNvcmVdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0dXJlDQpb d2FzOiBGZWF0dXJlLXRhZ3MgaW4gdGhlIFBhdGggaGVhZGVyIGZpZWxkXTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBQYXVsIGFuZCBDaHJpc3Rlciw8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCldlIG5vdyB1c2UgdGhpcyBkcmFmdCBpbiBvdXIgSU1TKDNHUFAn cyBTUlZDQyksIGN1cnJlbnRseSBpbiBzdGFuZGFyZCBsZXZlbC48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpTbywgd2Ugc3VwcG9ydCB0aGlzIG9uZS48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkdhbzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQpaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KVGVsICZuYnNwOyAm bmJzcDs6IDg3MjExPGJyPg0KVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCmVf bWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0K PGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBhdWwgS3l6aXZhdCAm bHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OzwvYj4NCjxicj4NCreivP7IyzogJm5ic3A7c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA5LTI3IDIy OjQ2PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3 aWR0aD03MyU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTUlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTk0JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGll dGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1zaXBj b3JlLXByb3h5LWZlYXR1cmUNClt3YXM6IEZlYXR1cmUtdGFncyBpbiB0aGUgUGF0aCBoZWFkZXIg ZmllbGRdPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+ DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpbYXMgY2hhaXJdPGJyPg0KPGJyPg0KVG8g YWxsIHNpcGNvcmUgcGFydGljaXBhbnRzOjxicj4NCjxicj4NCkNocmlzdGVyIGhhcyBiZWVuIGxv b2tpbmcgZm9yIGEgd2F5IHRvIGFjY29tcGxpc2ggYSBwYXJ0aWN1bGFyIGZ1bmN0aW9uDQo8YnI+ DQp0aGF0IDNncHAgd2FudHMuIFRoaXMgcHJvcG9zYWwgc2VlbXMgYSBwbGF1c2libGUgd2F5IHRv IGRvIHRoYXQuIEJ1dCBpdA0KPGJyPg0KaXMgb2YgbmVjZXNzaXR5IGRlZmluaW5nIGEgbW9yZSBn ZW5lcmFsIG1lY2hhbmlzbS48YnI+DQo8YnI+DQpJJ2QgcmVhbGx5IGFwcHJlY2lhdGUgY29tbWVu dHMgZnJvbSBvdGhlcnMgKGluY2x1ZGluZyBwZW9wbGUgaW4gbm8gd2F5DQo8YnI+DQppbnZvbHZl ZCB3aXRoIDNncHApIHJlZ2FyZGluZyB0aGlzIG1lY2hhbmlzbS4gRm9yIGluc3RhbmNlLCBkbyB5 b3UgPGJyPg0KY29uc2lkZXIgdGhlIHNlbWFudGljcyB0byBiZSB3ZWxsIGRlZmluZWQ/IERvIHlv dSBzZWUgbmVlZCBmb3IgbW9yZSA8YnI+DQphYm91dCBzZWN1cml0eSBpbXBsaWNhdGlvbnM/PGJy Pg0KPGJyPg0KSG93IG1hbnkgd291bGQgZmluZCB0aGlzIHVzZWZ1bCB0byBoYXZlPzxicj4NCjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VGhhbmtzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7UGF1bDxicj4NCjxicj4NCk9uIDkvMjQvMjAxMCA3OjA0IEFNLCBDaHJp c3RlciBIb2xtYmVyZyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0LCB3aGljaCBleHRlbmRzIHRoZSByci1wYXJh bSBydWxlLCBhbGxvd2luZw0KcHJveGllcyB0byBpbmRpY2F0ZSBzdXBwb3J0ZWQgZmVhdHVyZXMg dXNpbmcgZmVhdHVyZSB0YWdzIGluIFBhdGgsIFJlY29yZC1Sb3V0ZQ0KZXRjLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoZSBkcmFmdCBjYW4gYWxzbyBiZSBmb3VuZCBhdDogaHR0cDovL3VzZXJzLnBp dWhhLm5ldC9jaG9sbWJlci9kcmFmdHMvZHJhZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0 dXJlLTAwLnR4dDxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIEkgaW5kaWNhdGVkIGVhcmxpZXIgb24g dGhlIGxpc3QsIGFuZCBhcyB5b3UgY2FuIHJlYWQgaW4gdGhlIGRyYWZ0LA0KdGhlcmUgaXMgYSAz R1BQIHVzZS1jYXNlIHdoZXJlIHdlIGJlbGlldmUgdGhlIG1lY2hhbmlzbSBjb3VsZCBiZSB1c2Vk Lg0KQnV0LCB0aGVyZSBpcyBub3RoaW5nIDNHUFAgc3BlY2lmaWMgYWJvdXQgdGhlIG1lY2hhbmlz bSBhcyBzdWNoLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZn dDsgQ2hyaXN0ZXI8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxi cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjwv Zm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2Zv bnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmlj YXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQNCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBt ZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2Yg dGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2Vj dXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWlu ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtw cm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24u Jm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25m aWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUm bmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2Fu ZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2Um bmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRp b24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2Fu eSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUm bmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNw O2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZu YnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZu YnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZu YnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtu b3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNz YWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFt Jm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 003464EA482577BB_=-- From pkyzivat@cisco.com Wed Oct 13 05:34:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A14F3A6A05 for ; Wed, 13 Oct 2010 05:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.894 X-Spam-Level: X-Spam-Status: No, score=-109.894 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbT7eMAM4JuG for ; Wed, 13 Oct 2010 05:34:17 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 232B23A68ED for ; Wed, 13 Oct 2010 05:34:17 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABZEtUxAZnwM/2dsb2JhbAChTHGeB5xshUgEikGDAw X-IronPort-AV: E=Sophos;i="4.57,325,1283731200"; d="scan'208";a="169978852" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2010 12:35:33 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9DCZXHr009396 for ; Wed, 13 Oct 2010 12:35:33 GMT Message-ID: <4CB5A795.1000809@cisco.com> Date: Wed, 13 Oct 2010 08:35:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 12:34:19 -0000 Gao, Some of us have talked from time to time about issues with REFER. (I think Dale wrote a draft about it once.) Specifically, there is an element of "do what I mean" to it that requires the recipient to be psychic about what is intended. E.g. I can send a REFER ... method=FOO to you. You may have no clue what method FOO is. Should you just construct a generic FOO method and send it? Or I could send an embedded header that says "Supported:BAR", when in fact you don't know about option BAR. Hence the latitude for the referred UA to pick and choose what it wants to honor. At least that way it can have some assurance that it understands how to process the resulting request. But of course that means the referring party doesn't know if the request followed its intentions. I don't have a good answer for that. Something that comes to mind is for a copy of the resulting request to be sent to the referring UA as part of the refer subscription. But it would be difficult to make good use of that. Thanks, Paul On 10/13/2010 4:08 AM, gao.yang2@zte.com.cn wrote: > > > > As far as I know, there are no explicit restrictions. > > > > One could, however, ask whether it's allowed to include headers that > > are not to be used in the triggered INVITE, but in later associated > requests. > > RFC3261 section 19.1.5 > > An implementation MUST include any provided transport, maddr, ttl, or > user parameter in the Request-URI of the formed request. If the URI > contains a method parameter, its value MUST be used as the method of > the request. The method parameter MUST NOT be placed in the > Request-URI. Unknown URI parameters MUST be placed in the message's > Request-URI. > > An implementation SHOULD treat the presence of any headers or body > parts in the URI as a desire to include them in the message, and > choose to honor the request on a per-component basis. > > An implementation SHOULD NOT honor these obviously dangerous header > fields: From, Call-ID, CSeq, Via, and Record-Route. > > From the above text, it seams that the rules for embedded headers is > not as emphatic as transport, maddr, ttl and user parameter. So, I > suggest that one specific embedded headers could have a specific usage > guidelines, especially these headers with dangerous header fields. > > I'd like to point out that I am not going to say that people's > understanding of embedded headers(for pure audio usage) is not correct. > > > You CAN also embed SDP information. > > Are there any defined rules for such embedded SDP information? If there > are, could you show me. > > Thanks, > > Gao > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Oct 13 05:40:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672ED3A68EE for ; Wed, 13 Oct 2010 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPElJAXVNiQL for ; Wed, 13 Oct 2010 05:40:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 692D03A68ED for ; Wed, 13 Oct 2010 05:40:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-84-4cb5a91d9635 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.23.02850.D19A5BC4; Wed, 13 Oct 2010 14:42:05 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 13 Oct 2010 14:42:01 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 13 Oct 2010 14:41:59 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 13 Oct 2010 14:41:57 +0200 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: Actq0yWFqQHHUrySR36sr1gYkv+MswAALbUg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DF34EB@ESESSCMS0356.eemea.ericsson.se> References: <4CB5A795.1000809@cisco.com> In-Reply-To: <4CB5A795.1000809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 12:40:51 -0000 Hi, IF one wants to define specific behavior for the receiver of the REFER, I g= uess one could define an option-tag, associated with that behavior, which i= s inserted in the Require/Supported header field of the REFER request. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13. lokakuuta 2010 15:36 > To: sipcore@ietf.org > Subject: Re: [sipcore] About RFC3911(Join header)'s potential=20 > error: //Join header in REFER? >=20 > Gao, >=20 > Some of us have talked from time to time about issues with REFER. > (I think Dale wrote a draft about it once.) >=20 > Specifically, there is an element of "do what I mean" to it=20 > that requires the recipient to be psychic about what is intended. >=20 > E.g. I can send a REFER ... method=3DFOO to you. You may have=20 > no clue what method FOO is. Should you just construct a=20 > generic FOO method and send it? Or I could send an embedded=20 > header that says "Supported:BAR", when in fact you don't know=20 > about option BAR. >=20 > Hence the latitude for the referred UA to pick and choose=20 > what it wants to honor. At least that way it can have some=20 > assurance that it understands how to process the resulting=20 > request. But of course that means the referring party doesn't=20 > know if the request followed its intentions. >=20 > I don't have a good answer for that. Something that comes to=20 > mind is for a copy of the resulting request to be sent to the=20 > referring UA as part of the refer subscription. But it would=20 > be difficult to make good use of that. >=20 > Thanks, > Paul >=20 > On 10/13/2010 4:08 AM, gao.yang2@zte.com.cn wrote: > > > > > > > As far as I know, there are no explicit restrictions. > > > > > > One could, however, ask whether it's allowed to include headers=20 > > that > are not to be used in the triggered INVITE, but in later=20 > > associated requests. > > > > RFC3261 section 19.1.5 > > > > An implementation MUST include any provided transport,=20 > maddr, ttl, or=20 > > user parameter in the Request-URI of the formed request. If the URI=20 > > contains a method parameter, its value MUST be used as the=20 > method of=20 > > the request. The method parameter MUST NOT be placed in the=20 > > Request-URI. Unknown URI parameters MUST be placed in the message's=20 > > Request-URI. > > > > An implementation SHOULD treat the presence of any headers or body=20 > > parts in the URI as a desire to include them in the message, and=20 > > choose to honor the request on a per-component basis. > > > > An implementation SHOULD NOT honor these obviously dangerous header > > fields: From, Call-ID, CSeq, Via, and Record-Route. > > > > From the above text, it seams that the rules for embedded=20 > headers is=20 > > not as emphatic as transport, maddr, ttl and user parameter. So, I=20 > > suggest that one specific embedded headers could have a=20 > specific usage=20 > > guidelines, especially these headers with dangerous header fields. > > > > I'd like to point out that I am not going to say that people's=20 > > understanding of embedded headers(for pure audio usage) is=20 > not correct. > > > > > You CAN also embed SDP information. > > > > Are there any defined rules for such embedded SDP information? If=20 > > there are, could you show me. > > > > Thanks, > > > > Gao > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information =20 > contained in this mail is solely property of the =20 > sender's organization. This mail communication is =20 > confidential. Recipients named above are obligated to =20 > maintain secrecy and are not permitted to disclose =20 > the contents of this communication to others. > > This email and any files transmitted with it are =20 > confidential and intended solely for the use of the =20 > individual or entity to whom they are addressed. If =20 > you have received this email in error please notify =20 > the originator of the message. Any views expressed in=20 > this message are those of the individual sender. > > This message has been scanned for viruses and Spam =20 > by ZTE Anti-Spam system. > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Wed Oct 13 06:49:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8203A6956 for ; Wed, 13 Oct 2010 06:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLTb3MRe0cTA for ; Wed, 13 Oct 2010 06:49:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3DE9A3A6951 for ; Wed, 13 Oct 2010 06:49:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-40-4cb5b93227f7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 59.DD.02850.239B5BC4; Wed, 13 Oct 2010 15:50:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 13 Oct 2010 15:50:41 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Wed, 13 Oct 2010 15:50:40 +0200 Thread-Topic: Comments on draft-ietf-sipcore-keep-05 Thread-Index: Acs/3Cyfefv2XMp4S+6a17CBnpJFJAq/ROww Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A926943819D1@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:49:28 -0000 Hi, I was informed that I hadn't address how/if Hadriel's comments have been ad= dressed in the -06 version of the draft.=20 ----------- >Technical: >1) What happens if the two nodes indicate keepalives, but the=20 >downstream doesn't receive them? In Outbound, it would cause=20 >a flow failure for the registration. My guess is vendors=20 >will do the same for draft-keep. (probably even for=20 >dialog-based keepalives) So to me that means (a) the=20 >indicated timer value is a maximum time which the sender must=20 >send them in, not just a "recommendation", and (b) failure to=20 >receive a response to the keepalive should trigger a=20 >re-Register, which needs to be indicated in text in the draft. No changes were done in -06 due to this. The draft uses the same terminology as the Outbound RFC, which talks about = a recommended value. Also, according to the procedures, a SIP entity must send keep-alives *at l= east* as often as the indicated recommended keep-alive frequency. In addition, the draft does not mandate procedures if keep-alives are not r= eceived. ----------- =20 >2) Just to be clear, even if there are multiple Registrations=20 >or dialogs on a given connection, only one keepalive=20 >"instance" would be active on that connection, right? I.e.,=20 >we're not talking about sending multiple keepalives, one per=20 >dialog/registration, on the same connection. So something=20 >like this should be added to section 4.1: >"Even though the keepalive negotiation is performed on a=20 >registration or dialog basis, the keepalive mechanism is per=20 >transport connection, meaning only one keepalive is sent from=20 >the upstream to the downstream entity per TCP connection or=20 >UDP port pairs, even if there are multiple dialogs and=20 >registrations across them. Since keepalive is negotiated in=20 >each REGISTER or dialog transaction, the most recently=20 >negotiated settings MUST be used for the whole connection." No changes were done in -06 due to this. Implementations can of course make sure that keep-alives are not negotiated= for registrations/dialogs sharing the same connection, but in order to kee= p the mechanism itself simple the draft does not mandate entities to make s= ure that only one "set" of keep-alives are sent per connection. =20 ----------- >There is, unfortunately, a complication around this stuff: a=20 >proxy can be stateful for some calls and stateless for=20 >others. This means you can send a INVITE request downstream=20 >and be told to do keepalives, while your next INVITE to it=20 >does not, but you still need to do keepalives. I'm not sure=20 >how to handle this in text. >=20 >=20 >3) Section 4.2.2 says: > Usage of keep-alives > can be negotiated when the registration is established, or later > during the lifetime of the registration. >=20 >I don't believe it's technically possible to re-negotiate it=20 >during the lifetime, because the "lifetime" is the expiry=20 >value of the Registration. Once you send another REGISTER to=20 >renegotiate it, it's a new "lifetime". No? =20 This was addressed in -06 by removing the "lifetime" terminology. ----------- > 4) Section 4.3 has: > A SIP entity that has negotiated sending of keep-alives associated > with a registration MUST be prepared to receive, from the=20 > receiver of the keep-alives, SIP messages (requests and responses) ass= ociated > with the registration on the same IP port:address from where the > keep-alives are sent. If the SIP entity sends the keep-alives over a > connection-oriented transport protocol, it MUST be prepared to > receive SIP messages associated with the registration over the same > connection. The same rules apply for SIP messages associated with a > dialog, if the SIP entity has negotiated sending of keep-alives > associated with a dialog. >=20 >Why is that in this draft?? (I don't understand how it relates) This was addressed in -06 by removing the text, and adding text saying that= connection reuse must be provided using another mechanism. --------- > 5) Security considerations. There are some security=20 > considerations which are not in 5626. Just off the top of my=20 > head they are: >=20 > a) Any downstream SIP entity, beyond the adjacent downstream=20 > peer node, can modify the Via header identifying the local=20 > node and thus cause the local node to send keepalives to its=20 > adjacent peer (at high rates) if the peer does not support=20 > this keepalive mechanism. >=20 > b) A man-in-the-middle between two SIP nodes can modify the=20 > Via header at will, and thus can prevent keepalive from being=20 > used, or can decrease the timer value to a very low value to=20 > consume resources, or can cause the downstream to expect=20 > keepalives while the upstream does not know to send them and=20 > thus cause a failure. This was addressed in -06, by adding the following text to the security con= siderations. "Unless SIP messages are integrity protected, a man-in-the-middle can modify Via header fields used by two entities to negotiate sending of keep-alives, e.g. by removing the indications used to indicate willingness to send and receive keep-alives, or by decreasing the timer value to a verly low value, which might trigger additional resource consumption due to the frequently sent keep-alives." That covers mostly b). Nothing was added regarding a),because entities can = always check that,=20 before forwarding responses, the the Via header field hasn't been tempered = with. --------- >Editorial: >- s/CRLF/double-CRLF/g Fixed in -06. --------- =20 >- Section 4.4 first para, change: > The SIP entity must support those aspects of STUN that are required in= order=20 > to apply the STUN keep-alive mechanism defined in [RFC5626], and it mu= st support > the CRLF keep-alive mechanism defined in [RFC5626]. > To: > The SIP entity must support those aspects of STUN that are required in= order=20 > to apply the STUN keep-alive mechanism defined in [RFC5626] for connec= tion-less > transports such as UDP, and it must support the CRLF keep-alive=20 > mechanism defined in [RFC5626] for connection-oriented transports=20 > such as TCP and TLS over TCP. This was addressed in -06 by inserting the text provided by John Elwell: "[RFC5626] defines when to use STUN, respectively double-CRLF, for kee= p-alives." --------- Regards, Christer= From adam@nostrum.com Wed Oct 13 07:27:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97C73A6983 for ; Wed, 13 Oct 2010 07:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeoHE09Nv0aa for ; Wed, 13 Oct 2010 07:27:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 69D4E3A6970 for ; Wed, 13 Oct 2010 07:27:30 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9DESgpo005803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 09:28:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CB5C21A.5080000@nostrum.com> Date: Wed, 13 Oct 2010 09:28:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Christer Holmberg References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 14:27:31 -0000 [as a participant] On 10/13/10 8:50 AM, Christer Holmberg wrote: > >> a) Any downstream SIP entity, beyond the adjacent downstream >> peer node, can modify the Via header identifying the local >> node and thus cause the local node to send keepalives to its >> adjacent peer (at high rates) if the peer does not support ... > Nothing was added regarding a),because entities can always check that, > before forwarding responses, the the Via header field hasn't been tempered with. The purpose of the "Security Considerations" section is to warn implementors about things they need to take into consideration to avoid security problems. Shouldn't the document at least suggest that implementations validate the Via header field to prevent this kind of attack? /a From christer.holmberg@ericsson.com Wed Oct 13 08:27:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDC43A6970 for ; Wed, 13 Oct 2010 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsi2OIwbhPYv for ; Wed, 13 Oct 2010 08:27:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 75F8A3A6956 for ; Wed, 13 Oct 2010 08:27:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-3f-4cb5d014f3b0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 72.5C.02850.410D5BC4; Wed, 13 Oct 2010 17:28:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 13 Oct 2010 17:28:20 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 13 Oct 2010 17:28:17 +0200 Thread-Topic: Comments on draft-ietf-sipcore-keep-05 Thread-Index: Actq4vH93WIRw0TJQVGgZc+XfAxxnQABnnpg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DF3684@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> <4CB5C21A.5080000@nostrum.com> In-Reply-To: <4CB5C21A.5080000@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 15:27:06 -0000 Hi,=20 >>>a) Any downstream SIP entity, beyond the adjacent downstream peer=20 >>>node, can modify the Via header identifying the local node=20 >>>and thus cause the local node to send keepalives to its adjacent=20 >>>peer (at high rates) if the peer does not support >> ... >>Nothing was added regarding a),because entities can always=20 >>check that, before forwarding responses, the the Via header field=20 >>hasn't been tempered with. >=20 >The purpose of the "Security Considerations" section is to=20 >warn implementors about things they need to take into=20 >consideration to avoid security problems. Shouldn't the=20 >document at least suggest that implementations validate the=20 >Via header field to prevent this kind of attack? Fair enough. I can add the following text: "Downstream SIP entities can modify Via header fields identifying other = SIP entities, and cause keepalives to be sent (at hight rates) to entities that do not= not support=20 the keepalive mechanism. SIP entities can prevent this, when a SIP respo= nse is received,=20 by validating that Via headers have not been modified in a way which wou= ld cause such=20 sending of keepalives." Regards, Christer From adam@nostrum.com Wed Oct 13 08:55:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FD13A6B8D for ; Wed, 13 Oct 2010 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5-dhUQpc-eI for ; Wed, 13 Oct 2010 08:55:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 17B1B3A6A9F for ; Wed, 13 Oct 2010 08:55:39 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9DFuqe1013138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 10:56:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CB5D6C3.2050100@nostrum.com> Date: Wed, 13 Oct 2010 10:56:51 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Christer Holmberg References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> <4CB5C21A.5080000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502DF3684@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DF3684@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 15:55:41 -0000 On 10/13/10 10:28 AM, Christer Holmberg wrote: > Hi, > >>>> a) Any downstream SIP entity, beyond the adjacent downstream peer >>>> node, can modify the Via header identifying the local node >>>> and thus cause the local node to send keepalives to its adjacent >>>> peer (at high rates) if the peer does not support >>> ... >>> Nothing was added regarding a),because entities can always >>> check that, before forwarding responses, the the Via header field >>> hasn't been tempered with. >> The purpose of the "Security Considerations" section is to >> warn implementors about things they need to take into >> consideration to avoid security problems. Shouldn't the >> document at least suggest that implementations validate the >> Via header field to prevent this kind of attack? > Fair enough. > > I can add the following text: > > "Downstream SIP entities can modify Via header fields identifying other SIP entities, > and cause keepalives to be sent (at hight rates) to entities that do not not support > the keepalive mechanism. SIP entities can prevent this, when a SIP response is received, > by validating that Via headers have not been modified in a way which would cause such > sending of keepalives." That's good, but I think we can improve it by more clearly calling out what the implementations need to look for: "Downstream SIP entities can modify Via header fields identifying other SIP entities, and cause keepalives to be sent (at high rates) to entities that do not not support the keepalive mechanism. SIP entities can prevent this, when a SIP response is received, by examining their own Via header field to determine that downstream entities have not added a 'keep' parameter or set an existing 'keep' parameter to a value not supported by the implementation." /a From christer.holmberg@ericsson.com Wed Oct 13 09:05:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3383A6B2E for ; Wed, 13 Oct 2010 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n++DCR8RAuQu for ; Wed, 13 Oct 2010 09:05:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C68423A67EA for ; Wed, 13 Oct 2010 09:05:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-42-4cb5d9236329 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.20.02850.329D5BC4; Wed, 13 Oct 2010 18:07:00 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 13 Oct 2010 18:06:59 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 13 Oct 2010 18:06:59 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 13 Oct 2010 18:06:57 +0200 Thread-Topic: Comments on draft-ietf-sipcore-keep-05 Thread-Index: Actq70S6l+pcjWuzSV6PuLDgLeJWbAAAVErw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DF36C2@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> <4CB5C21A.5080000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502DF3684@ESESSCMS0356.eemea.ericsson.se> <4CB5D6C3.2050100@nostrum.com> In-Reply-To: <4CB5D6C3.2050100@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:05:45 -0000 Your text proposal looks good. I can add it. Regards, Christer=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 13. lokakuuta 2010 18:57 > To: Christer Holmberg > Cc: sipcore@ietf.org; Hadriel Kaplan; rjsparks@nostrum.com;=20 > Gonzalo Camarillo > Subject: Re: Comments on draft-ietf-sipcore-keep-05 >=20 >=20 > On 10/13/10 10:28 AM, Christer Holmberg wrote: > > Hi, > > > >>>> a) Any downstream SIP entity, beyond the adjacent=20 > downstream peer=20 > >>>> node, can modify the Via header identifying the local=20 > node and thus=20 > >>>> cause the local node to send keepalives to its adjacent peer (at=20 > >>>> high rates) if the peer does not support > >>> ... > >>> Nothing was added regarding a),because entities can always check=20 > >>> that, before forwarding responses, the the Via header=20 > field hasn't=20 > >>> been tempered with. > >> The purpose of the "Security Considerations" section is to warn=20 > >> implementors about things they need to take into consideration to=20 > >> avoid security problems. Shouldn't the document at least=20 > suggest that=20 > >> implementations validate the Via header field to prevent=20 > this kind of=20 > >> attack? > > Fair enough. > > > > I can add the following text: > > > > "Downstream SIP entities can modify Via header fields=20 > identifying other SIP entities, > > and cause keepalives to be sent (at hight rates) to=20 > entities that do not not support > > the keepalive mechanism. SIP entities can prevent this,=20 > when a SIP response is received, > > by validating that Via headers have not been modified=20 > in a way which would cause such > > sending of keepalives." >=20 > That's good, but I think we can improve it by more clearly=20 > calling out what the implementations need to look for: >=20 > "Downstream SIP entities can modify Via header fields=20 > identifying other SIP entities, and cause keepalives to be=20 > sent (at high rates) to entities that do not not support the=20 > keepalive mechanism. SIP entities can prevent this, when a=20 > SIP response is received, by examining their own Via header=20 > field to determine that downstream entities have not added a=20 > 'keep' parameter or set an existing 'keep' parameter to a=20 > value not supported by the implementation." >=20 > /a >=20 > = From christer.holmberg@ericsson.com Wed Oct 13 09:59:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F373A67B7 for ; Wed, 13 Oct 2010 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqDbbkAJpwLF for ; Wed, 13 Oct 2010 09:59:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7C2863A68D5 for ; Wed, 13 Oct 2010 09:59:45 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-24-4cb5e5cd5178 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.32.27351.DC5E5BC4; Wed, 13 Oct 2010 19:01:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 13 Oct 2010 19:01:01 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach Date: Wed, 13 Oct 2010 19:00:57 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-keep-07 [was: Comments on draft-ietf-sipcore-keep-05] Thread-Index: Actq70S6l+pcjWuzSV6PuLDgLeJWbAAAVErwAAHMK8A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502DF36E7@ESESSCMS0356.eemea.ericsson.se> References: <430FC6BDED356B4C8498F634416644A926943819D1@mail> <7F2072F1E0DE894DA4B517B93C6A058502DF35BF@ESESSCMS0356.eemea.ericsson.se> <4CB5C21A.5080000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502DF3684@ESESSCMS0356.eemea.ericsson.se> <4CB5D6C3.2050100@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502DF36C2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DF36C2@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Gonzalo Camarillo , Hadriel Kaplan Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-07 [was: Comments on draft-ietf-sipcore-keep-05] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:59:48 -0000 =20 Hi, I've submitted a new version of the keep-alive draft. The changes are: - I added the text suggested by Adam to the security considerations section= . - Small minor change in the 4th paragraph of section 4.1, as suggested by P= aul earlier (after -06 had been submitted). Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 13. lokakuuta 2010 19:07 > To: Adam Roach > Cc: sipcore@ietf.org; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-keep-05 >=20 >=20 > Your text proposal looks good. I can add it. >=20 > Regards, >=20 > Christer=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 13. lokakuuta 2010 18:57 > > To: Christer Holmberg > > Cc: sipcore@ietf.org; Hadriel Kaplan; rjsparks@nostrum.com; Gonzalo=20 > > Camarillo > > Subject: Re: Comments on draft-ietf-sipcore-keep-05 > >=20 > >=20 > > On 10/13/10 10:28 AM, Christer Holmberg wrote: > > > Hi, > > > > > >>>> a) Any downstream SIP entity, beyond the adjacent > > downstream peer > > >>>> node, can modify the Via header identifying the local > > node and thus > > >>>> cause the local node to send keepalives to its=20 > adjacent peer (at=20 > > >>>> high rates) if the peer does not support > > >>> ... > > >>> Nothing was added regarding a),because entities can=20 > always check=20 > > >>> that, before forwarding responses, the the Via header > > field hasn't > > >>> been tempered with. > > >> The purpose of the "Security Considerations" section is to warn=20 > > >> implementors about things they need to take into=20 > consideration to=20 > > >> avoid security problems. Shouldn't the document at least > > suggest that > > >> implementations validate the Via header field to prevent > > this kind of > > >> attack? > > > Fair enough. > > > > > > I can add the following text: > > > > > > "Downstream SIP entities can modify Via header fields > > identifying other SIP entities, > > > and cause keepalives to be sent (at hight rates) to > > entities that do not not support > > > the keepalive mechanism. SIP entities can prevent this, > > when a SIP response is received, > > > by validating that Via headers have not been modified > > in a way which would cause such > > > sending of keepalives." > >=20 > > That's good, but I think we can improve it by more clearly=20 > calling out=20 > > what the implementations need to look for: > >=20 > > "Downstream SIP entities can modify Via header fields identifying=20 > > other SIP entities, and cause keepalives to be sent (at=20 > high rates) to=20 > > entities that do not not support the keepalive mechanism.=20 > SIP entities=20 > > can prevent this, when a SIP response is received, by=20 > examining their=20 > > own Via header field to determine that downstream entities have not=20 > > added a 'keep' parameter or set an existing 'keep' parameter to a=20 > > value not supported by the implementation." > >=20 > > /a > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From root@core3.amsl.com Wed Oct 13 10:00:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C5EAD3A68E5; Wed, 13 Oct 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013170001.C5EAD3A68E5@core3.amsl.com> Date: Wed, 13 Oct 2010 10:00:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 17:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-07.txt Pages : 17 Date : 2010-10-13 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13095604.I-D@ietf.org> --NextPart-- From marianne.mohali@orange-ftgroup.com Wed Oct 13 12:05:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E367D3A69D8 for ; Wed, 13 Oct 2010 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRF2sUIQU0KT for ; Wed, 13 Oct 2010 12:05:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 12D463A691F for ; Wed, 13 Oct 2010 12:05:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E541FC4003 for ; Wed, 13 Oct 2010 21:06:30 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 06196FC4001 for ; Wed, 13 Oct 2010 21:06:30 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Oct 2010 21:06:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 21:06:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New draft extending Reason header Thread-Index: Actq3tqMNWrJY51+QKWRKUogAELtkQAKTjUg From: To: X-OriginalArrivalTime: 13 Oct 2010 19:06:28.0466 (UTC) FILETIME=[BD47AD20:01CB6B09] Cc: bruno.chatras@orange-ftgroup.com Subject: [sipcore] New draft extending Reason header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:05:16 -0000 =20 Hi, We've submitted a draft, which extends the Reason header, allowing proxies to indicate an application-specific reason in the SIP message. The draft can be found at: http://www.ietf.org/id/draft-mohali-sipcore-reason-extension-application -00.txt We think that it would be usefull to have this kind of application-specific reasons especially in the History-Info header when a call has been retargeted by an Application. We would like to get some feedback on the proposed I-D and a confirmation of interest from the IETF community (SIPCORE). =20 Best Regards, Marianne Mohali From mary.ietf.barnes@gmail.com Wed Oct 13 12:08:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBF13A691F for ; Wed, 13 Oct 2010 12:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSjyI9oT4+4o for ; Wed, 13 Oct 2010 12:08:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 51C093A69D8 for ; Wed, 13 Oct 2010 12:08:16 -0700 (PDT) Received: by gyc15 with SMTP id 15so1589496gyc.31 for ; Wed, 13 Oct 2010 12:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nDcjF8cnIbjBWjlgIvVpnD2QTMw0009bz1fzSqlq68U=; b=i+EhTKl4fW4johBqbjmJhs9K1xHt+mvoWIcvpar1D82OKuSbdtxlVNthBjx6myGF7k mLdoYx9GnfPDeyBtwGXDe299oStQyH63MG74frTdAXYpT4mLefl6dgmPrcpD4MaUl8aN 9rxobs/XrJfgRsYHtEZUc7cwVM/o32N37yg+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XWFU63bMpxB2Dgda7ld0IBbi4H+RxSmb9+oME9V3bOYio1gB3b+HnPFdv7BKTJQ3YZ Pfp58/xbnlXlt/lqQe8GotVS82bJspEY9uDLT+k/NGtvpRD9z4WHlKKobGzlL7TqLz57 0dpepIjgb0Gzo6OZZ3xWLhdiVR/AI2UPSrUpw= MIME-Version: 1.0 Received: by 10.42.216.74 with SMTP id hh10mr4828643icb.246.1286996972871; Wed, 13 Oct 2010 12:09:32 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:09:32 -0700 (PDT) In-Reply-To: <42833A4B-F051-406B-9FFA-F9246C7D423A@acmepacket.com> References: <42833A4B-F051-406B-9FFA-F9246C7D423A@acmepacket.com> Date: Wed, 13 Oct 2010 14:09:32 -0500 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] #4: The new "hit" parameter is gonna cause problems X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:08:17 -0000 Hadriel, Okay, I see your point. So, rather than escaping a URI parameter in the Contact URI, you are suggesting to define a new header parameter for the Contact header and History-Info headers. That seems like a good ide= a, although not a small change. Per the response to issue #41, I also think it's a good idea to have the index for all the values. The Tel URIs are actually a separate concern because even with History-Info header as defined in 4244, we were escaping the privacy header and reason header in the targeted-to-URI to avoid redefining those, so you have the same issue there. We had some discussion at IETF-75 about Tel-URIs and the conclusion there was that they were considered out of scope, but if someone wanted to provide text, we could considering how to support. http://www.ietf.org/proceedings/75/minutes/sipcore.html#Tel-URIs My suggestion is that we document these restrictions with regards to History-Info and Tel-URIs - i.e., they'll be properly captured, but won't have the reaso= n or per-entry privacy attributes. I don't see the point in crafting a sub-optimal or complex solution just so that Tel-URIs can be supported. Thanks, Mary. On Mon, Aug 30, 2010 at 3:48 PM, Hadriel Kaplan wr= ote: > > On Aug 30, 2010, at 1:51 PM, Hadriel Kaplan wrote: > >>> >>> > Third, it should be a >>> > =A0header param not a URI param, I think (which would solve the previ= ous >>> > =A0issues). >>> >>> [MB] It's not at all clear to me why you think this needs to be a >>> header parameter or how such would solve the problems you anticipate >>> (although that's because I don't understand what problems you think >>> will happen with the current approach).[/MB] >>> >> If it's a header param, then it's not part of the URI in the contact tha= t becomes the request-uri of the recursed/new request, does not matter if i= t's SIP or TEL, and is ignored if not understood. > > And once we agree on it being a header param, the next thing I'll ask for= is to not make it a "hit=3D" but rather just the two params "rc" and "mp".= =A0Then all the proxy needs to do is copy the contact-URI to H-I, as it wo= uld have done with a request-URI. =A0It doesn't have to look for the "hit" = param and convert its value to a new param name. =A0Seems simpler to me. > > -hadriel > > From mary.ietf.barnes@gmail.com Wed Oct 13 12:12:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D853A69D8 for ; Wed, 13 Oct 2010 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhnCx0VdZ2GB for ; Wed, 13 Oct 2010 12:12:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1D59B3A69FB for ; Wed, 13 Oct 2010 12:12:00 -0700 (PDT) Received: by iwn10 with SMTP id 10so8233097iwn.31 for ; Wed, 13 Oct 2010 12:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a9bpsk5TPj0q3BkqdaVo4tzJHJVqkW/cpoQ/W2ZBuE0=; b=bB1uXm9Cy9Nea8AWflgPiOwWkoZEBZAKl8PZCt71QY2Bl/asd946Q3h8vTuiLp1xfp l22Z3AeaWGGIdQ+dm1RI68IHxvSirqld+fe+oF+9N//1kUuLF9qE2APbhOyazBvliVkq 6D7D2AUPBvI9CD4E1Iy3WOrH45Y/GT77DKXHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KbdmHNjM9Er+QMM5r6PLHFbeRa/wM75yWJn8r3rwvenUxuhMHNyXoVSsPgC3Lj73C/ UiyayNovrgSs+/ks15aQcJ41TenhCadXTYCNja+/fX2uN40681wM1scfEezBKjickjYr rRV4eykHg8ZYVqbKxmnmZKpAOYJZJYpNLaFXQ= MIME-Version: 1.0 Received: by 10.42.153.4 with SMTP id k4mr4279790icw.195.1286997195100; Wed, 13 Oct 2010 12:13:15 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:13:14 -0700 (PDT) In-Reply-To: References: <064.423b18aea4d865d80f1bed80de0120f0@tools.ietf.org> <4C7C0F6E.6000508@softarmor.com> <7796EC5A-2504-49A4-BA2A-BFEEC4076AF8@acmepacket.com> <4C7C1A70.8070807@cisco.com> <4C7C393A.5090707@cisco.com> Date: Wed, 13 Oct 2010 14:13:14 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" , sipcore issue tracker , Hadriel Kaplan Subject: Re: [sipcore] #10: Convert all SHOULDs to MUST X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:12:02 -0000 I didn't originally like this idea. However, as I've started making these changes, I do think it works quite well. We didn't always have the situation whereby the SHOULD would not apply documented, thus the MUST is often more appropriate. Mary. On Wed, Sep 1, 2010 at 2:01 AM, Elwell, John wrote: > =A0I tend to agree with Paul. If we say that whenever there are condition= s you should use SHOULD rather than MUST, you will end up with very few MUS= Ts, since nearly every normative statement has some conditions behind it (e= ither as part of the statement or implicit in what has gone before). I thin= k we can probably make a distinction on whether those conditions can be cle= arly specified, or whether they are by their nature vague. For example, "SH= OULD challenge for digest authentication, unless the recipient has other me= ans of ascertaining the source of the request", versus "MUST challenge for = digest authentication unless the request has been delivered over TLS". > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 31 August 2010 00:06 >> To: Mary Barnes >> Cc: sipcore@ietf.org; sipcore issue tracker; Hadriel Kaplan >> Subject: Re: [sipcore] #10: Convert all SHOULDs to MUST >> >> >> >> Mary Barnes wrote: >> > We ended up changing alot of 4244 SHOULDs to MUSTs. =A0However, my >> > understanding on the use of MUSTs was that they shouldn't have >> > qualifiers. It's the SHOULDs that should have the qualifiers that >> > describe the circumstances under which it's okay not to do >> the SHOULD. >> > =A0So, I would prefer to keep the SHOULDs where we have valid >> > circumstances for not doing the should, but otherwise they should be >> > MUSTs (with no "unless...") =A0[If that makes any sense at all]. I'm >> > basing this on the text straight from RFC 2119: >> >> "MUST foo unless condition" is semantically equivalent to "if >> !condition >> then MUST foo". I'm pretty sure there is nothing wrong with >> the latter. >> As a result there shouldn't be anything wrong with the former either, >> but we can choose the preferred wording just to avoid making waves. >> >> So, something like "Unless the SSP anonymizes all calls it >> MUST support >> temp GRUU". >> >> > 1. MUST =A0 This word, or the terms "REQUIRED" or "SHALL", >> mean that the >> > =A0 =A0definition is an absolute requirement of the specification. >> > ... >> > >> > 3. SHOULD =A0 This word, or the adjective "RECOMMENDED", mean >> that there >> > =A0 =A0may exist valid reasons in particular circumstances to ignore a >> > =A0 =A0particular item, but the full implications must be understood a= nd >> > =A0 =A0carefully weighed before choosing a different course. >> >> The distinction is understood, and still vague. Reasonable >> people differ >> greatly in what constitutes a "valid reason" even if they >> have carefully >> understood and weighed the full implications. >> >> In practice it seems that many implementors treat SHOULD the same as >> MAY. And if they do, how can they be proven wrong? >> >> I'm not quite ready (though tempted) to give up on SHOULD >> entirely. But >> I think the WG *SHOULD* have a *really* good reason for using SHOULD >> rather than MUST. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> > Mary. >> > >> > On Mon, Aug 30, 2010 at 3:54 PM, Paul Kyzivat >> wrote: >> >> [ as individual, for now ] >> >> >> >> Hadriel Kaplan wrote: >> >>> Right, I didn't mean just make them MUST without >> qualifiers - "MUST ... >> >>> unless ..." is fine. >> >> MUST ... unless >> >> >> >> is equivalent to using SHOULD and naming the only >> exceptions to conforming >> >> with the SHOULD. Using SHOULD ... unless would still run >> the risk that >> >> somebody would say the SHOULD still allows violation for >> arbitrary reasons. >> >> >> >> So I agree that MUST ... unless is preferable to SHOULD. >> >> >> >> =A0 =A0 =A0 =A0Thanks, >> >> =A0 =A0 =A0 =A0Paul >> >> >> >>> -hadriel >> >>> >> >>> On Aug 30, 2010, at 4:07 PM, Dean Willis wrote: >> >>> >> >>>> On 8/30/2010 1:33 PM, sipcore issue tracker wrote: >> >>>>> #10: Convert all SHOULDs to MUST >> >>>>> >> >>>>> >> ------------------------------------+------------------------- >> -------------- >> >>>>> =A0Reporter: =A0hkaplan@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner: >> >>>>> =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= Status: =A0new >> >>>>> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Mi= lestone: =A0milestone1 >> >>>>> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Vers= ion: =A02.0 >> >>>>> =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: >> >>>>> >> >>>>> >> ------------------------------------+------------------------- >> -------------- >> >>>>> =A0I know this isn't something we have a rule for, but >> ISTM that "SHOULD" >> >>>>> is >> >>>>> =A0a dirty word. =A0We get into trouble every time we have >> a SHOULD, and >> >>>>> this >> >>>>> =A0draft has a lot of them. =A0Either it's a MUST, or it's >> not. =A0I recommend >> >>>>> we >> >>>>> =A0change them all, or at least explain about why they're >> not MUST. >> >>>>> >> >>>> Better yet, every usage of RFC 2119 language (SHOULD, >> MUST, etc.) MUST >> >>>> contain an explanation of why that particular RFC 2119 >> keyword was used and >> >>>> and what the consequences of failing to implement >> according to the >> >>>> specification are. For example, in this case we selected >> MUST because of the >> >>>> well-known fact that failure to explain requirements in >> a protocol >> >>>> specification results in lazy implementations that >> ignore the requirements >> >>>> because the implementers do not understand the >> implications of having done >> >>>> so. This is exacerbated by having too many RFC 2119 >> requirements statements >> >>>> in general. If the requirements are hard to meet, they >> should be harder to >> >>>> make; that is, the task of creating such a requirement >> properly includes >> >>>> thoroughly documenting the requirement. >> >>>> >> >>>> There are places where a SHOULD is appropriate, and the >> semantic is "MUST >> >>>> except when a predicted but infrequent condition, as >> described herein, is >> >>>> detected". >> >>>> >> >>>> So, perhaps we could begin writing SHOULD requirements >> as "MUST, except >> >>>> when... because .... occurs or may occur if this >> requirement is not met." >> >>>> >> >>>> -- >> >>>> Dean >> >>> _______________________________________________ >> >>> sipcore mailing list >> >>> sipcore@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/sipcore >> >>> >> >> _______________________________________________ >> >> sipcore mailing list >> >> sipcore@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From mary.ietf.barnes@gmail.com Wed Oct 13 12:20:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2625D3A6983 for ; Wed, 13 Oct 2010 12:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2o7OElSoRPw for ; Wed, 13 Oct 2010 12:20:29 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1178A3A6916 for ; Wed, 13 Oct 2010 12:20:28 -0700 (PDT) Received: by gxk8 with SMTP id 8so169959gxk.31 for ; Wed, 13 Oct 2010 12:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CEjmRHKYujN4fMpd0FGv0kpDQSgYG/75wto4Ks4RrL0=; b=R7Ity9uVzrzvYuWVLgZEv1oGH9abQCV5FGMkRUk/gjEOKexK6Y/tr2pixGmJ/8zXOO /MypzZXH/w8PiF8TaAhPWCd8B3HXmlwPd5ylUbtq0p0cl8OtCJ6oPTRuL9/v6qBAF4I8 TeJEigs+a3HsbGJNoUSdrZDkXPSETOtD6Ck/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DPIVcEiWGnDy/gXKbr3wyHwNRmRAV/HkQhmq9/yrOVPrgp5QmEOeSR0lfXKQaAK8JH a1JsSzZhz9zKDX4Vbv7ImNnC+yMH2uQA38Vej0Ajo4g5Y8DTwTloMkhxo4QbIEynM8Mr CIMq64YZY4Ah+v9zONZ4iBQX8ySlee+FVzPXE= MIME-Version: 1.0 Received: by 10.42.15.12 with SMTP id j12mr4413429ica.382.1286997705647; Wed, 13 Oct 2010 12:21:45 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:21:45 -0700 (PDT) In-Reply-To: References: <061.57b8764c42d447c660e2242094ef9cb2@tools.ietf.org> Date: Wed, 13 Oct 2010 14:21:45 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "worley@alum.mit.edu" , "sipcore@ietf.org" , sipcore issue tracker Subject: Re: [sipcore] #28: UACs should add H-I if they implement it X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:20:30 -0000 Agreed. I've changed that text. On Wed, Sep 1, 2010 at 2:28 AM, Elwell, John wrote: > This makes sense to me. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of sipcore issue tracker >> Sent: 31 August 2010 18:49 >> To: worley@alum.mit.edu >> Cc: sipcore@ietf.org >> Subject: [sipcore] #28: UACs should add H-I if they implement it >> >> #28: UACs should add H-I if they implement it >> ---------------------------------+---------------------------- >> -------------- >> =A0Reporter: =A0worley@... =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: >> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Stat= us: =A0new >> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: = =A0milestone1 >> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: >> =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: >> ---------------------------------+---------------------------- >> -------------- >> =A0In section 4.1 is: >> >> =A0 =A0 =A0Normally, UACs are not expected to include a >> History-Info header in an >> =A0initial request as it is more of a Proxy function; the main >> reason it is >> =A0allowed is for B2BUAs who are performing proxy-like functions such as >> =A0routing. >> >> =A0This is not a good idea; a UAC that wants History-Info should add the >> =A0initial hi-entry. =A0The reason is that the UAC does not know >> that the next >> =A0proxy that will modify the request-URI implements H-I; if >> the UAC does not >> =A0provide an hi-entry, the UAS won't see the original request-URI. >> =A0Conversely, adding "History-Info: <[request-URI]>;index=3D1" >> is not much >> =A0more work than adding "Supported: histinfo", which we >> already assume the >> =A0UAC will do. >> >> -- >> Ticket URL: >> sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Wed Oct 13 12:20:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491533A6AA7 for ; Wed, 13 Oct 2010 12:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyQoc5jSUxDv for ; Wed, 13 Oct 2010 12:20:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 235D83A6916 for ; Wed, 13 Oct 2010 12:20:57 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9DJMDiK031143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 14:22:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CB606E5.3050701@nostrum.com> Date: Wed, 13 Oct 2010 14:22:13 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" , draft-ietf-sipcore-sec-flows@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] WGLC: draft-ietf-sipcore-sec-flows X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:20:59 -0000 [as chair] The editor of draft-ietf-sipcore-sec-flows believes that the document has no remaining open issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Wednesday, October 27th. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-sec-flows Any comments on the document should be sent to the SIPCORE mailing list. /a From mary.ietf.barnes@gmail.com Wed Oct 13 12:33:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A233A6A1D for ; Wed, 13 Oct 2010 12:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OjwOD6Gja5l for ; Wed, 13 Oct 2010 12:33:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C2CCC3A6911 for ; Wed, 13 Oct 2010 12:33:00 -0700 (PDT) Received: by gyc15 with SMTP id 15so1602879gyc.31 for ; Wed, 13 Oct 2010 12:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rMTfEodlGesPp5kbRiJVjfROKxh1xG5ZM6KMDatUdC4=; b=JD+UR9wzJTux8K8WYdXQpkLMNarsuyLQBVMElhf7jmNIAnWhrHkdTy6CSCscPBlv+H XFjRv2b5w6PXW+eF3gf3kX8MiZ43KnVdH95irGfy7dQQZuhyUhGJgvORYhv/DzGwzMu9 zyN0o8e4Sx2B/Qau/P0n72oXchCnjBeKXDNXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KvD8AYhxXSBmpSfGtLmBv9XpCwyVLwkm9UdYFFlAt43GqrpJGZX2ng2jIZowL7/Gy5 061oZJdTKXoqsHL3qVri7YPaWwv2FY0bPMv6vJuV4faHBjsdj281Q1XydHkuj3+Anh9R +oLaCNEGHfN/clm89gxEwXKC7MmGarfn0dInY= MIME-Version: 1.0 Received: by 10.236.110.43 with SMTP id t31mr3048111yhg.81.1286998456641; Wed, 13 Oct 2010 12:34:16 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:34:16 -0700 (PDT) In-Reply-To: References: <064.2fac1c1d9b3ab9e13c8bc32cb433819f@tools.ietf.org> Date: Wed, 13 Oct 2010 14:34:16 -0500 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:33:02 -0000 I agree that this should be clarified. We likely need to add appropriate normative text in the Index section on the calculation of the index for internal retargeting OR refer explicitly to the appropriate section in terms of how the indices are calculated. The best approach IMHO is that it looks like the 302 scenario - i.e., the second example below. Certainly, you won't be able to tell that this was internal to the proxy by the indices, but it does reflect the request was retargeted to another logical entity within the same domain. Mary. On Thu, Sep 2, 2010 at 4:11 PM, Worley, Dale R (Dale) w= rote: > ________________________________________ > From: Hadriel Kaplan [HKaplan@acmepacket.com] > > But they're NOT "Request-URIs". =A0Not yet. =A0They're abstract target UR= Is during the internal local policy stages of routing, until such point as = the request gets forwarded. =A0They're just memory blocks in a system, gett= ing munged based on transformation rules, lookup tables, or possibly non-SI= P database queries. > > For example, a common routing local policy procedure of originating proxi= es in North America is to perform the following for received request-URIs i= dentified as phone numbers: > 1) Normalize the number by removing visual separators, and possibly trans= form the number to an E.164, by adding a country-code, area-code, leading-p= lus, etc. > 2) Do a number portability dip for the called number. =A0That changes the= target URI to include a 'npdi' and possibly 'rn' param info. > 3) Determine whether the portability-corrected target is local or out of = region, or if it's out of the local domain altogether (and to which peer). = =A0That can change the target again, for example by changing the domain nam= e, adding trunk-group info, etc. > 4) Change the Request-URI to be the new target. > ________________________________________ > > Hmmm.... =A0In the sipX architecture, each of those steps would be done s= eparately, by the proxy sending the request to a redirect server which woul= d return a 302. =A0So yes, each stage of processing would be represented by= a separate hi-entry. > > But I see your point, What if a proxy does it all internally? > > I'd like to say that it can write hi-entry's *as if* each step was descri= bed separately by a 302 from a redirect server. =A0Or alternatively, as if = the request had a series of passes through proxies that performed each step= . =A0Those alternatives would lead to History-Info somewhat like these (whe= re I've changed the use of the tags a bit): > > History-Info: > =A0 =A0 =A0 =A0;index=3D1, > =A0 =A0 =A0 =A0;index=3D1.1, > =A0 =A0 =A0 =A0;index=3D1.1.1, > =A0 =A0 =A0 =A0;index=3D1.1.1.1, > =A0 =A0 =A0 =A0;index=3D1.1.1.1.1 > > History-Info: > =A0 =A0 =A0 =A0;index=3D1, > =A0 =A0 =A0 =A0;index=3D1.1, > =A0 =A0 =A0 =A0;index=3D1.2;from=3D1.= 1, > =A0 =A0 =A0 =A0;index=3D1.3;from=3D1.= 2, > =A0 =A0 =A0 =A0;index=3D1.4;from=3D1.= 3 > > In general, the recipient of a request containing such a faked H-I wouldn= 't be able to tell that it had been faked. =A0However, it would be desirabl= e to have text to explicitly approve such behavior. > > Going back to the text of the document, I see how I became misled. =A0The= text in section 5.1 is: > > =A0 Retargeting is an iterative process, i.e., a proxy may redirect > =A0 "internally " more than one time. =A0A typical example would be a pro= xy > =A0 that redirects a request first to a different user (i.e., it maps to > =A0 a different AOR), and then forwards to a registered contact bound to > =A0 that new AOR. =A0A proxy that uses such mechanism SHOULD add multiple > =A0 hi-entry fields (e.g., bob@example.com to office@example.com to > =A0 office@192.0.2.5) to provide a logical description of the retargeting > =A0 process. =A0A Reason MAY be associated with the hi-targeted-to-uri th= at > =A0 has been retargeted as shown in the example in Appendix B.1. > > Given that the word "internally" is not defined in any way, and that the = example described would be implemented in sipX through multiple redirect se= rver requests, I did not realize that the process described was performed e= ntirely within one SIP element. =A0This suggests that the text could stand = to be improved. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Wed Oct 13 12:39:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21FB3A6911 for ; Wed, 13 Oct 2010 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7uZMIujlg7x for ; Wed, 13 Oct 2010 12:39:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A311E3A69C2 for ; Wed, 13 Oct 2010 12:39:40 -0700 (PDT) Received: by ywa6 with SMTP id 6so2477047ywa.31 for ; Wed, 13 Oct 2010 12:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZUFkVhNCRkMX+xAkLjnAE5tdm5cdnsG3/3HcE+XHO0k=; b=OlcvT6e6/uuDdp6q/b+64eHtklNRUzNsGNfUnF9o0Sj7A8AM+vCzC+cWRf+BTa4gW2 6ikXOij9kjQSmf12s5UX6gaJPoTKnAVa3V/OQLqzdDPkxzMdY95i6yuJCGvB9Uv02f+U FRdMlECzGNs25/fj6i+8ZBYq/biNydlGTv9js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pleuzUikzdIC1t6HPkUh7CtkKSL21wG4HEcwm7CxWsJceOtd9F5Seae17XNaf/AP0L JWJ+8GGGuKKfgLnrXIDNUYsb3mvyEWRupPhbFOG8Ew5niJVbXehKc5WMJ/6NS1y006rE tySIfJNKVHd5ikmAhn4U28OFoOKBnuVbpMHhM= MIME-Version: 1.0 Received: by 10.236.109.19 with SMTP id r19mr19448345yhg.51.1286998856667; Wed, 13 Oct 2010 12:40:56 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:40:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 14:40:56 -0500 Message-ID: From: Mary Barnes To: marianne.mohali@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: bruno.chatras@orange-ftgroup.com, sipcore@ietf.org Subject: Re: [sipcore] New draft extending Reason header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:39:43 -0000 Hi Marianne, I haven't reviewed the draft in detail, however, I also had the same thought with regards to the usefulness of these Reasons for History-Info when I saw the draft earlier today. I think we might also be able to use this for the parallel forking issue ( #20 ) in that we could add these reasons to the hi-entries to which the request didn't terminate (i.e., the legs that are Canceled after the 200ok is sent for the request that successfully terminated) rather than leaving the entries with no Reason and having it be inferred. I will review the draft in detail later (once I finish all these 4244bis changes). Thanks, Mary. On Wed, Oct 13, 2010 at 2:06 PM, wrote: > > Hi, > > We've submitted a draft, which extends the Reason header, allowing > proxies to indicate an application-specific reason in the SIP message. > > The draft can be found at: > http://www.ietf.org/id/draft-mohali-sipcore-reason-extension-application > -00.txt > > We think that it would be usefull to have this kind of > application-specific reasons especially in the History-Info header when > a call has been retargeted by an Application. > > We would like to get some feedback on the proposed I-D and a > confirmation of interest from the IETF community (SIPCORE). > > Best Regards, > > Marianne Mohali > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Wed Oct 13 12:51:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39C23A6AA7 for ; Wed, 13 Oct 2010 12:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz+P3-L3sUoj for ; Wed, 13 Oct 2010 12:51:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5CE1C3A6A5B for ; Wed, 13 Oct 2010 12:51:25 -0700 (PDT) Received: by gxk8 with SMTP id 8so187529gxk.31 for ; Wed, 13 Oct 2010 12:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/LOZLaYhJOpFRSWA307LKggpV9nPDW12yCVFCjfrit0=; b=U22PMgQ5a7zCdm040UJ+BwRqHn4DTSPLtb0SuRW3ylEfhfkjwpr19AewBjlvTkU1dO JYKiOCo2Mj8vNj7fo3Q7YdjLFG4KkJhtldEV09cRuttYcWCvIYex7NegN4z1tWV5RqVa daAe+ZTkyhhbJFzF4n9ySC6WXUSPJLtl9HyIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HKbkNbUHkVjVTbqkqVfHr/Gu5FW9zLi0NuejgNm1ffaaMpbLGOKpgvtylD2emohDne /SENaY3+NB9qcGivT559zLIx8/YI0kDy2HKFBPjuzovSBfPxPF0BxOGn9j9OactXC+oj PMVvSe3LuGJR23Pc5pcVZ2Zl/6NwoefiUMk1k= MIME-Version: 1.0 Received: by 10.236.110.44 with SMTP id t32mr19402103yhg.60.1286999562074; Wed, 13 Oct 2010 12:52:42 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:52:42 -0700 (PDT) In-Reply-To: <4C7C1733.4050402@cisco.com> References: <064.095bc2caaa02e01e9bc1234e3c8941af@tools.ietf.org> <4C7BFAAA.4000409@cisco.com> <1C71FA27-29FA-41D4-90D2-FCECB4C8FEE7@acmepacket.com> <4C7C0B4F.8030406@cisco.com> <4C7C1733.4050402@cisco.com> Date: Wed, 13 Oct 2010 14:52:42 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" , sipcore issue tracker , Hadriel Kaplan Subject: Re: [sipcore] #9: What should an SBC do when it resolves registered contacts? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:51:26 -0000 I just replied to issue #8 on internal retargeting. I think we could consider this SBC behavior to fall into a similar category. In my response to #8, I suggested that the indices look the same as if the proxy retargeted to external entities (e.g., based on a 3xx). However, this proposal seems to be support Dale's first alternative where the indices are nested under the same branch, which makes alot of sense actually. So, I'll change the text resolving #8 to describe the behavior in that manner. However, the text on internal retargeting is in the Proxy section. Perhaps, we should qualify that section as applicable to Proxies or intermediaries that support SIP? Thanks, Mary. On Mon, Aug 30, 2010 at 3:40 PM, Paul Kyzivat wrote: > > > Hadriel Kaplan wrote: >> >> Ok, it's a rat-hole. :) >> But the point wasn't to stipulate in the draft what an SBC should do, bu= t >> rather what a UAS might receive and need to be ok with - i.e., "don't ex= pect >> only one "rc" tagged entry". =A0If you look at the use-cases draft, a lo= t of >> their "rules" for processing involve using entries with "rc" tags, or in >> relative positions to "rc" tagged ones in certain positions. =A0Those ru= les >> are based on assumptions that are very simplistic, which will not be the >> case in the wild. > > Sure, I think the point that there might be multiple rc entries is a good > one. It is probably a rat hole to describe how to discover various > interesting facts given that situation. But you aren't asking for that. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> -hadriel >> >> On Aug 30, 2010, at 3:49 PM, Paul Kyzivat wrote: >> >>> [ as individual ] >>> >>> Hadriel Kaplan wrote: >>>> >>>> Right, but the subtle difference is that in the SBC case what the UAS >>>> wants to find is the AoR it registered for, which is (probably) the fi= rst >>>> non-"rc" entry prior to the series of "rc" entries at the end. =A0Like= this: >>>> History-Info: >>>> History-Info: ;rc >>>> History-Info: ;rc >>>> >>>> Whereas in a chain of AoR's, it would be looking for the one it >>>> registered which *is* "rc" tagged, like this: >>>> History-Info: >>>> History-Info: ;rc >>>> History-Info: ;rc >>>> >>>> Right? >>> >>> !!! RAT HOLE ALERT !!! >>> >>> I think we are going to get into serious trouble if we start discussing >>> how an SBC should behave WRT HI. >>> >>> Given their frequent use to do topology hiding, I would expect to see >>> lots of entries to be removed, or altered. In *this* case the UAS is on= the >>> side the SBC is protecting, so maybe it would all still be there, but i= ts >>> hard to predict what some hypothetical SBC will do. >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> >>>> -hadriel >>>> >>>> On Aug 30, 2010, at 2:38 PM, Paul Kyzivat wrote: >>>> >>>>> [as individual] >>>>> >>>>> Note that an SBC is not required to get this behavior. >>>>> It can happen any time somebody REGISTERs a contact address that >>>>> happens to be an AOR serviced by another registrar. While AFAIK this = is not >>>>> a frequent occurrence in the wild, its certainly possible and permitt= ed. >>>>> >>>>> =A0 =A0 =A0 =A0Thanks, >>>>> =A0 =A0 =A0 =A0Paul >>>>> >>>>> sipcore issue tracker wrote: >>>>>> >>>>>> #9: What should an SBC do when it resolves registered contacts? >>>>>> >>>>>> ------------------------------------+-------------------------------= -------- >>>>>> Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 O= wner: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type: >>>>>> =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new = =A0 =A0 =A0 Priority: =A0minor >>>>>> =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0milestone1 >>>>>> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Versio= n: =A02.0 >>>>>> Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: >>>>>> =A0------------------------------------+----------------------------= ----------- >>>>>> In many deployments, SBC's perform a registration caching model, >>>>>> whereby >>>>>> they have a local registration cache which is used to replace reques= t- >>>>>> uri's for routing to endpoints. =A0The UA registers to the SBC using >>>>>> contact >>>>>> URI X, and the SBC sends contact URI Y to the full Registrar; so whe= n >>>>>> a >>>>>> request to Y comes to the SBC, it replaces it with X. >>>>>> >>>>>> Under that model, do we expect the SBC to add an H-I of type "rc"? = =A0If >>>>>> so, >>>>>> for the same fork branch, there will be two "rc" entries, one for Y >>>>>> and >>>>>> one for X. (if the SBC doesn't simply remove the Y entry) >>>>>> >>>>>> Therefore, I think there should be some text to make it clear that >>>>>> receiving a H-I list with multiple "rc" entries for the same branch >>>>>> tree >>>>>> is ok. =A0For example, receiving a index 1.1 of "rc" followed by a 1= .1.1 >>>>>> of >>>>>> "rc", and maybe even a 1.1.1.1 of "rc". >>>>>> >>>> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Wed Oct 13 12:52:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D8A3A69C1 for ; Wed, 13 Oct 2010 12:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pphWZWpqIr2r for ; Wed, 13 Oct 2010 12:52:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 18C423A6876 for ; Wed, 13 Oct 2010 12:52:53 -0700 (PDT) Received: by gyc15 with SMTP id 15so1614619gyc.31 for ; Wed, 13 Oct 2010 12:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y8CnHZgujcpBsURi9XwzPt+RNiXJ6M2M8xGcS0Tv7a0=; b=P5wFQftBlY1Glv+33WVcyIivFMe1MJFfL+U7len8cMsMp71iS9V0Q2lX0PAcKXsjxW YidzRUgAK9hTge12UbNL6gydayjcZe+zSzo5mtZKaQ593mAXmP87W4iYfnDx6vUOlPHf 2Wt3GUy01l+h83+8imQWzSylFA2Rlacewbr/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mCUQjH0r8e50RdG2OD/pQR5rZkb0SCghw2p2K7yXsxKY2k5J/cfCmNn5P+E09gozUu i4NOdNtmFnwBDGwyNs4MxNGZYP8O5x4toBnJSlrSlyG/yU4DEvrYzm6ZNV0GNDV1XBsl 5S+xYVRmD8sPWt1zOm8PST7qsDdqtirQ3u/7g= MIME-Version: 1.0 Received: by 10.236.108.131 with SMTP id q3mr19490254yhg.43.1286999649983; Wed, 13 Oct 2010 12:54:09 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 12:54:09 -0700 (PDT) In-Reply-To: References: <064.2fac1c1d9b3ab9e13c8bc32cb433819f@tools.ietf.org> Date: Wed, 13 Oct 2010 14:54:09 -0500 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" , sipcore issue tracker Subject: Re: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:52:55 -0000 Per my response to issue #9, I think the first option for indexing works be= tter. On Thu, Sep 2, 2010 at 3:03 PM, Mary Barnes wr= ote: > Dale, > > I'm not sure what you mean with regards to "historical accident". =A0One > of the original requirements was to capture the "complete" > information. Thus, each and every change of the Request-URI is > intended to be captured (including changes by a proxy internally). =A0I > would agree that the definition of retargeting in the terminology > section does not accurately reflect such, which adds to the confusion. > > But, I would agree the text needs improvements to make that clear and > it's possible some of the re-arrangement of the introductory sections, > etc. resulted in the lack of clarity. =A0And, most importantly, we need > to make sure the normative parts of this document accurately reflect > this. > > Mary. > > On Thu, Sep 2, 2010 at 2:26 PM, Worley, Dale R (Dale) = wrote: >> ________________________________________ >>> #8: It's not clear when a Proxy should/should-not add H-I for "internal= " stuff >>> ------------------------------------+----------------------------------= ----- >>> Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owne= r: >>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0Status: =A0new >>> Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:= =A0milestone1 >>> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: = =A02.0 >>> Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: >>> ------------------------------------+----------------------------------= ----- >>> Section 5.1 says: >>> =A0 =A0Retargeting is an iterative process, i.e., a proxy may redirect >>> =A0 =A0"internally " more than one time. =A0A typical example would be = a proxy >>> =A0 =A0that redirects a request first to a different user (i.e., it map= s to >>> =A0 =A0a different AOR), and then forwards to a registered contact boun= d to >>> =A0 =A0that new AOR. =A0A proxy that uses such mechanism SHOULD add mul= tiple >>> =A0 =A0hi-entry fields (e.g., bob@example.com to office@example.com to >>> =A0 =A0office@192.0.2.5) to provide a logical description of the retarg= eting >>> =A0 =A0process. >>> >>> This isn't clear enough. =A0Let's suppose you have an "alias", like >>> john.smith@ssp.com, but your real registered AoR is jsmith@ssp.com. =A0= When >>> the proxy receives a request for john.smith@ssp.com, it looks up the >>> location service database and ultimately gets a registered contact for >>> jsmith@ssp.com. =A0In some architectures, the proxy would internally go= from >>> john.smith@ssp.com to jsmith@ssp.com, and then to the registered contac= t. >>> So does it add a H-I for jsmith@ssp.com? >>> >>> The answer matters - both because it impacts the use-case rules describ= ed >>> in the use-cases draft, and because it means a UA will get two differen= t >>> sets of H-I entries depending on the internal implementation of the pro= xy >>> +location-service it uses. >> _______________________________________________ >> >> The problem is (IMHO) that the text doesn't clearly capture the intentio= n of H-I, due to a historical accident. >> >> The point of H-I is to capture (to the degree possible) the request-URIs= of the *entire* tree of INVITE messages that were generated. =A0If this is= done thoroughly, then all of the "regargeting" operations (all all other t= ypes of operations) will necessarily be captured. =A0But in the past, peopl= e have tended to think that the purpose was to document some specific set o= f request-URI transformations (e.g., the ones called "retargeting"), and th= e text tends to be written in ways that echo that previous understanding. = =A0The result is that we feel the need to debate exactly what is recorded i= n certain complex situations. >> >> The solution is to clarify at the beginning that all request-URIs are in= tended to be recorded. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From mary.ietf.barnes@gmail.com Wed Oct 13 13:02:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BBB3A69FF for ; Wed, 13 Oct 2010 13:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EofPH2VDVwEG for ; Wed, 13 Oct 2010 13:02:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5087F3A691F for ; Wed, 13 Oct 2010 13:02:27 -0700 (PDT) Received: by ywa6 with SMTP id 6so2490098ywa.31 for ; Wed, 13 Oct 2010 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EAiJfOurAW8qeDV/lOfcITZli4ye+wLQg4pS0FhuwWE=; b=KcyIQGUdObz5rPtzAi9AEtnA+GrQlZwOEcJK2mmIwBHjo1uz+h3q81eay+41p7yV5m IV/m0aPyciW//azbW3c5TAyCgVxd4kjKP0Z/eXqbFR1f2cVoErMLsUDpsgFSdDXc1dDz 5f1UuEDmXE6Hv19/e/I3omy0mhU51TdVrjM9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xPi9bcvGCOOSUa+34OxslE6uxfZ/GwOEcUk2oVA74p6NrPkZTjSfi7TQqve70SD7TZ IUeq9jZ7CSiCIoi59opgtm9ED4PfRkQwXldYpDvB+rV8C4ydGOY1vUDFTKx1tAlqLkiJ GGMOpBo6pPlDOXTUy5XmZvjeVPpgviGuvv1S0= MIME-Version: 1.0 Received: by 10.236.105.168 with SMTP id k28mr1796021yhg.78.1287000224379; Wed, 13 Oct 2010 13:03:44 -0700 (PDT) Received: by 10.236.108.172 with HTTP; Wed, 13 Oct 2010 13:03:44 -0700 (PDT) In-Reply-To: References: <061.f3e7a20653cdf403663b0bffba4c43b4@tools.ietf.org> <35ECC1DD-6DD6-4103-AC47-A2F9A0D69DAD@ntt-at.com> <4C80EF97.4090703@cisco.com> <2E92FEF2-DCBD-44A9-869B-CCE2BB98278F@ntt-at.com> <54579397-D4DC-4043-8D42-7E6F357E5F6F@ntt-at.com> Date: Wed, 13 Oct 2010 15:03:44 -0500 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] #38: How is the mapping of a GRUU into its UA Contact marked? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 20:02:28 -0000 Dale, So, then it seems you are advocating we add an additional "gr" tag. However, wouldn't the absence of "mp" or "rc" for a GRUU indicate that the GRUU wasn't mapped. I guess it is not harmful to add a unique tag for cases where a GRUU is used, but do you have a use case where this is relevant? Thanks, Mary. On Tue, Sep 7, 2010 at 12:32 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Shida Schubert [shida@ntt-at.com] > > I guess we could but is it really necessary when "gr" tag is present for = GRUU? > _______________________________________________ > > That's a possibility. =A0But just because the mapped-from URI is a GRUU d= oesn't mean that the mapped-to URI was done by looking up the GRUU's bindin= g -- there may be some other mapping mechanism that is involved. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gao.yang2@zte.com.cn Thu Oct 14 02:22:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81233A6965 for ; Thu, 14 Oct 2010 02:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.606 X-Spam-Level: X-Spam-Status: No, score=-100.606 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfgNjFVxnPqp for ; Thu, 14 Oct 2010 02:22:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3774B3A68C5 for ; Thu, 14 Oct 2010 02:22:57 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 14 Oct 2010 17:22:56 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38058.5143419512; Thu, 14 Oct 2010 17:21:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9E9Naxm026146; Thu, 14 Oct 2010 17:23:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502DF34EB@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 14 Oct 2010 17:21:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-14 17:23:21, Serialize complete at 2010-10-14 17:23:21 Content-Type: multipart/alternative; boundary="=_alternative 00339259482577BC_=" X-MAIL: mse2.zte.com.cn o9E9Naxm026146 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 09:22:59 -0000 This is a multipart message in MIME format. --=_alternative 00339259482577BC_= Content-Type: text/plain; charset="US-ASCII" Christer, > IF one wants to define specific behavior for the receiver of the > REFER, I guess one could define an option-tag, associated with that > behavior, which is inserted in the Require/Supported header field of > the REFER request. IMO, the UAC of REFER should show its function level demand for the session, which would be created by the UAS of REFER. If the function level demand have the inferation in signalling level, such as require/support some headers, the UAS could do it by it's judgement. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00339259482577BC_= Content-Type: text/html; charset="US-ASCII"
Christer,
 
> IF one wants to define specific behavior for the receiver of the
> REFER, I guess one could define an option-tag, associated with that
> behavior, which is inserted in the Require/Supported header field of
> the REFER request.
IMO, the UAC of REFER should show its function level demand for the session, which would be created by the UAS of REFER. If the function level demand have the inferation in signalling level, such as require/support some headers, the UAS could do it by it's judgement.

Thanks,

Gao
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00339259482577BC_=-- From gonzalo.camarillo@ericsson.com Thu Oct 14 04:53:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5F83A68FC for ; Thu, 14 Oct 2010 04:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytvvAh3QPE1t for ; Thu, 14 Oct 2010 04:53:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BDB5F3A679C for ; Thu, 14 Oct 2010 04:53:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c3aae000000b22-39-4cb6ef7b49ac Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.93.02850.B7FE6BC4; Thu, 14 Oct 2010 13:54:35 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 13:54:35 +0200 Received: from [131.160.126.182] ([131.160.126.182]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 13:54:34 +0200 Message-ID: <4CB6EF77.9040509@ericsson.com> Date: Thu, 14 Oct 2010 14:54:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Byron Campen References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> In-Reply-To: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2010 11:54:34.0144 (UTC) FILETIME=[918DB200:01CB6B96] X-Brightmail-Tracker: AAAAAA== Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 11:53:19 -0000 Hi Byron, > Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? yes, that is what the re-INVITE draft says: http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 Figure 5 shows a message flow with a race condition similar to the ones you are referring to: http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 Thanks, Gonzalo On 11/10/2010 8:43 PM, Byron Campen wrote: > > Sending to the authors of the offeranswer and reinvite drafts, since I am not sure which bucket this would fall in: > > Consider the following. In all cases, this is within a reINVITE transaction, after an offer/answer exchange has completed using 100rel (which kind is not important), that is being rejected by the server side due to some unspecified error: > > A B > |<---------| INVITE/500 > | | > | | > UPDATE (offer) |--------->| > | | > |<---------| UPDATE/200 (answer) > > A B > UPDATE (offer) |---\ /---| INVITE/500 > | \/ | > | /\ | > |<--/ \-->| > | | > |<---------| UPDATE/200 (answer) > > A B > | /-| INVITE/500 > | / | > UPDATE (offer) |------/-->| > | / | > |<---/-----| UPDATE/200 (answer) > | / | > |<-/ | > > All of these look identical to B; UPDATE offer/answer completes after the end of the INVITE transaction. However, A sees them very differently. B cannot know that something unusual has happened. Also consider the following cases: > > A B > UPDATE (offer) |--------->| > | | > |<---------| UPDATE/200 (answer) > | | > |<---------| INVITE/500 > > A B > UPDATE (offer) |--------->| > | | > | /--| UPDATE/200 (answer) > | / | > |<----/----| INVITE/500 > | / | > |<--/ | > > Again, these look the same to B, but different to A. What is the best approach to ensuring that session-state is consistent on both ends in all of these cases? It seems to me that one way would be to specify that rollback of a reINVITE does not invalidate session-state established with an UPDATE, regardless of whether that UPDATE transaction occurred (or appeared to have occurred) during the reINVITE transaction. If we insist that session-state established with an in-reINVITE UPDATE be rolled back (the current language says that both sides must roll back to the session-state in use prior to the reINVITE), then there is no way to ensure consistent rollback on both ends, even if everything has the same rollback logic, because what appears to be an in-reINVITE UPDATE on one end may appear to be after the reINVITE transaction on the other end. If any portion of the UPDATE transaction appeared to have happened within the reINVITE transaction, then the observing UA must send a subsequent UPDATE to re-sync (since there is no guarantee that the other end saw the UPDATE within the reINVITE transaction). This is likely to cause glare, unless we put asymmetric timers on the re-sync, and even then there will be a delay similar to that caused by glare. > > My gut says that it would be better to not rollback session-state established by an UPDATE, under any circumstances. But, there may be situations where the session-state established in an UPDATE is contingent on the reINVITE succeeding it. Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? Or is there something I am missing here? > > Best regards, > Byron Campen > > > From bcampen@estacado.net Thu Oct 14 06:45:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878633A6A3F for ; Thu, 14 Oct 2010 06:45:37 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r68-C5kPGXuZ for ; Thu, 14 Oct 2010 06:45:36 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id BA46D3A6AD0 for ; Thu, 14 Oct 2010 06:45:35 -0700 (PDT) Received: from dn3-100.estacado.net (dn3-100.estacado.net [172.16.3.100]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9EDk1wi079351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Oct 2010 08:46:02 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Byron Campen In-Reply-To: <4CB6EF77.9040509@ericsson.com> Date: Thu, 14 Oct 2010 08:46:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 13:45:37 -0000 Perhaps I phrased my question poorly. My question wasn't so much = about what a UA should do when it thinks the session is out of sync, but = whether it thinks the session is out of sync in the specific case I = posed. But, I suppose that any time we get a reINVITE that is rejected = after an offer/answer exchange has been completed, whether or not there = had been an UPDATE thrown into the mix, we should assume the worst and = re-sync. This will lead to glare fairly often, but we are already in a = relatively rare corner-case, so I can see this being acceptable. Best regards, Byron Campen > Hi Byron, >=20 >> Would it be appropriate to say that if a UA "feels" this way, it is = responsible for re-syncing? >=20 > yes, that is what the re-INVITE draft says: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >=20 > Figure 5 shows a message flow with a race condition similar to the = ones > you are referring to: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >=20 > Thanks, >=20 > Gonzalo >=20 > On 11/10/2010 8:43 PM, Byron Campen wrote: >>=20 >> Sending to the authors of the offeranswer and reinvite drafts, = since I am not sure which bucket this would fall in: >>=20 >> Consider the following. In all cases, this is within a reINVITE = transaction, after an offer/answer exchange has completed using 100rel = (which kind is not important), that is being rejected by the server side = due to some unspecified error: >>=20 >> A B >> |<---------| INVITE/500 >> | | >> | | >> UPDATE (offer) |--------->| >> | | >> |<---------| UPDATE/200 (answer) >>=20 >> A B >> UPDATE (offer) |---\ /---| INVITE/500 >> | \/ | >> | /\ | >> |<--/ \-->| >> | | >> |<---------| UPDATE/200 (answer) >>=20 >> A B >> | /-| INVITE/500 >> | / | >> UPDATE (offer) |------/-->| >> | / | >> |<---/-----| UPDATE/200 (answer) >> | / | >> |<-/ | >>=20 >> All of these look identical to B; UPDATE offer/answer completes = after the end of the INVITE transaction. However, A sees them very = differently. B cannot know that something unusual has happened. Also = consider the following cases: >>=20 >> A B >> UPDATE (offer) |--------->| >> | | >> |<---------| UPDATE/200 (answer) >> | | >> |<---------| INVITE/500 >>=20 >> A B >> UPDATE (offer) |--------->| >> | | >> | /--| UPDATE/200 (answer) >> | / | >> |<----/----| INVITE/500 >> | / | >> |<--/ | >>=20 >> Again, these look the same to B, but different to A. What is the = best approach to ensuring that session-state is consistent on both ends = in all of these cases? It seems to me that one way would be to specify = that rollback of a reINVITE does not invalidate session-state = established with an UPDATE, regardless of whether that UPDATE = transaction occurred (or appeared to have occurred) during the reINVITE = transaction. If we insist that session-state established with an = in-reINVITE UPDATE be rolled back (the current language says that both = sides must roll back to the session-state in use prior to the reINVITE), = then there is no way to ensure consistent rollback on both ends, even if = everything has the same rollback logic, because what appears to be an = in-reINVITE UPDATE on one end may appear to be after the reINVITE = transaction on the other end. If any portion of the UPDATE transaction = appeared to have happened within the reINVITE transaction, then the = observing UA must send a=20 > subsequent UPDATE to re-sync (since there is no guarantee that the = other end saw the UPDATE within the reINVITE transaction). This is = likely to cause glare, unless we put asymmetric timers on the re-sync, = and even then there will be a delay similar to that caused by glare. >>=20 >> My gut says that it would be better to not rollback = session-state established by an UPDATE, under any circumstances. But, = there may be situations where the session-state established in an UPDATE = is contingent on the reINVITE succeeding it. Would it be appropriate to = say that if a UA "feels" this way, it is responsible for re-syncing? Or = is there something I am missing here? >>=20 >> Best regards, >> Byron Campen >>=20 >>=20 >>=20 >=20 From gonzalo.camarillo@ericsson.com Thu Oct 14 06:53:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A9A3A6A0A for ; Thu, 14 Oct 2010 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.447 X-Spam-Level: X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RriUOuMp8-qk for ; Thu, 14 Oct 2010 06:53:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C64E63A68FA for ; Thu, 14 Oct 2010 06:53:17 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-54-4cb70b9bd83a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 67.D1.27351.B9B07BC4; Thu, 14 Oct 2010 15:54:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 15:54:35 +0200 Received: from [131.160.126.182] ([131.160.126.182]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 15:54:35 +0200 Message-ID: <4CB70B9A.9000309@ericsson.com> Date: Thu, 14 Oct 2010 16:54:34 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Byron Campen References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2010 13:54:35.0641 (UTC) FILETIME=[55FAEE90:01CB6BA7] X-Brightmail-Tracker: AAAAAA== Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 13:53:19 -0000 Hi, the condition for resynching given in the draft is when the UA "receives an error response to a re-INVITE that undoes already-executed changes within the re-INVITE". The draft talks about several situation where UAs can go out of synch. In any case, as you suggest in your email, we are talking about corner cases. Cheers, Gonzalo On 14/10/2010 4:46 PM, Byron Campen wrote: > > Perhaps I phrased my question poorly. My question wasn't so much about what a UA should do when it thinks the session is out of sync, but whether it thinks the session is out of sync in the specific case I posed. But, I suppose that any time we get a reINVITE that is rejected after an offer/answer exchange has been completed, whether or not there had been an UPDATE thrown into the mix, we should assume the worst and re-sync. This will lead to glare fairly often, but we are already in a relatively rare corner-case, so I can see this being acceptable. > > Best regards, > Byron Campen > >> Hi Byron, >> >>> Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? >> >> yes, that is what the re-INVITE draft says: >> >> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >> >> Figure 5 shows a message flow with a race condition similar to the ones >> you are referring to: >> >> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >> >> Thanks, >> >> Gonzalo >> >> On 11/10/2010 8:43 PM, Byron Campen wrote: >>> >>> Sending to the authors of the offeranswer and reinvite drafts, since I am not sure which bucket this would fall in: >>> >>> Consider the following. In all cases, this is within a reINVITE transaction, after an offer/answer exchange has completed using 100rel (which kind is not important), that is being rejected by the server side due to some unspecified error: >>> >>> A B >>> |<---------| INVITE/500 >>> | | >>> | | >>> UPDATE (offer) |--------->| >>> | | >>> |<---------| UPDATE/200 (answer) >>> >>> A B >>> UPDATE (offer) |---\ /---| INVITE/500 >>> | \/ | >>> | /\ | >>> |<--/ \-->| >>> | | >>> |<---------| UPDATE/200 (answer) >>> >>> A B >>> | /-| INVITE/500 >>> | / | >>> UPDATE (offer) |------/-->| >>> | / | >>> |<---/-----| UPDATE/200 (answer) >>> | / | >>> |<-/ | >>> >>> All of these look identical to B; UPDATE offer/answer completes after the end of the INVITE transaction. However, A sees them very differently. B cannot know that something unusual has happened. Also consider the following cases: >>> >>> A B >>> UPDATE (offer) |--------->| >>> | | >>> |<---------| UPDATE/200 (answer) >>> | | >>> |<---------| INVITE/500 >>> >>> A B >>> UPDATE (offer) |--------->| >>> | | >>> | /--| UPDATE/200 (answer) >>> | / | >>> |<----/----| INVITE/500 >>> | / | >>> |<--/ | >>> >>> Again, these look the same to B, but different to A. What is the best approach to ensuring that session-state is consistent on both ends in all of these cases? It seems to me that one way would be to specify that rollback of a reINVITE does not invalidate session-state established with an UPDATE, regardless of whether that UPDATE transaction occurred (or appeared to have occurred) during the reINVITE transaction. If we insist that session-state established with an in-reINVITE UPDATE be rolled back (the current language says that both sides must roll back to the session-state in use prior to the reINVITE), then there is no way to ensure consistent rollback on both ends, even if everything has the same rollback logic, because what appears to be an in-reINVITE UPDATE on one end may appear to be after the reINVITE transaction on the other end. If any portion of the UPDATE transaction appeared to have happened within the reINVITE transaction, then the observing UA must send a >> subsequent UPDATE to re-sync (since there is no guarantee that the other end saw the UPDATE within the reINVITE transaction). This is likely to cause glare, unless we put asymmetric timers on the re-sync, and even then there will be a delay similar to that caused by glare. >>> >>> My gut says that it would be better to not rollback session-state established by an UPDATE, under any circumstances. But, there may be situations where the session-state established in an UPDATE is contingent on the reINVITE succeeding it. Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? Or is there something I am missing here? >>> >>> Best regards, >>> Byron Campen >>> >>> >>> >> > From bcampen@estacado.net Thu Oct 14 07:05:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914823A6868 for ; Thu, 14 Oct 2010 07:05:46 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUlncKEpP9SS for ; Thu, 14 Oct 2010 07:05:45 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 7A35C3A6A05 for ; Thu, 14 Oct 2010 07:05:44 -0700 (PDT) Received: from dn3-100.estacado.net (dn3-100.estacado.net [172.16.3.100]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9EE6oEZ083060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Oct 2010 09:06:50 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Byron Campen In-Reply-To: <4CB70B9A.9000309@ericsson.com> Date: Thu, 14 Oct 2010 09:06:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB5C633-983E-4A11-AF23-4C6A862E49A0@estacado.net> References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> <4CB70B9A.9000309@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:05:46 -0000 Alright, that's pretty clear. Now, there is still the question = of what happens when the UAS is aware of the specification, but is = forced to send a 500 or similar anyway, and then the 500 crosses the = UPDATE on the wire, like so: | /-| INVITE/500 | / | |<-----/---| UPDATE (re-sync offer) | / | UPDATE/200 (answer) |----/---->|=20 | / | |<-/ | We cannot use the ACK for the 500, since it is hop-by-hop, and = if the UAC doesn't re-sync, UAS's attempt to re-sync fails. Are we = content with saying that the UAS cannot recover from this? We _could_ = avoid this problem by having a rule that says "If you're the UAS, and = you rejected the reINVITE with already executed offer/answer changes, = you MUST send your re-sync offer in an INVITE", since the other end will = reject our re-sync if it beats the 500. Best regards, Byron Campen > Hi, >=20 > the condition for resynching given in the draft is when the UA = "receives > an error response to a re-INVITE that undoes already-executed changes > within the re-INVITE". The draft talks about several situation where = UAs > can go out of synch. >=20 > In any case, as you suggest in your email, we are talking about corner > cases. >=20 > Cheers, >=20 > Gonzalo >=20 > On 14/10/2010 4:46 PM, Byron Campen wrote: >>=20 >> Perhaps I phrased my question poorly. My question wasn't so much = about what a UA should do when it thinks the session is out of sync, but = whether it thinks the session is out of sync in the specific case I = posed. But, I suppose that any time we get a reINVITE that is rejected = after an offer/answer exchange has been completed, whether or not there = had been an UPDATE thrown into the mix, we should assume the worst and = re-sync. This will lead to glare fairly often, but we are already in a = relatively rare corner-case, so I can see this being acceptable. >>=20 >> Best regards, >> Byron Campen >>=20 >>> Hi Byron, >>>=20 >>>> Would it be appropriate to say that if a UA "feels" this way, it is = responsible for re-syncing? >>>=20 >>> yes, that is what the re-INVITE draft says: >>>=20 >>> = http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >>>=20 >>> Figure 5 shows a message flow with a race condition similar to the = ones >>> you are referring to: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 >>> On 11/10/2010 8:43 PM, Byron Campen wrote: >>>>=20 >>>> Sending to the authors of the offeranswer and reinvite drafts, = since I am not sure which bucket this would fall in: >>>>=20 >>>> Consider the following. In all cases, this is within a reINVITE = transaction, after an offer/answer exchange has completed using 100rel = (which kind is not important), that is being rejected by the server side = due to some unspecified error: >>>>=20 >>>> A B >>>> |<---------| INVITE/500 >>>> | | >>>> | | >>>> UPDATE (offer) |--------->| >>>> | | >>>> |<---------| UPDATE/200 (answer) >>>>=20 >>>> A B >>>> UPDATE (offer) |---\ /---| INVITE/500 >>>> | \/ | >>>> | /\ | >>>> |<--/ \-->| >>>> | | >>>> |<---------| UPDATE/200 (answer) >>>>=20 >>>> A B >>>> | /-| INVITE/500 >>>> | / | >>>> UPDATE (offer) |------/-->| >>>> | / | >>>> |<---/-----| UPDATE/200 (answer) >>>> | / | >>>> |<-/ | >>>>=20 >>>> All of these look identical to B; UPDATE offer/answer completes = after the end of the INVITE transaction. However, A sees them very = differently. B cannot know that something unusual has happened. Also = consider the following cases: >>>>=20 >>>> A B >>>> UPDATE (offer) |--------->| >>>> | | >>>> |<---------| UPDATE/200 (answer) >>>> | | >>>> |<---------| INVITE/500 >>>>=20 >>>> A B >>>> UPDATE (offer) |--------->| >>>> | | >>>> | /--| UPDATE/200 (answer) >>>> | / | >>>> |<----/----| INVITE/500 >>>> | / | >>>> |<--/ | >>>>=20 >>>> Again, these look the same to B, but different to A. What is the = best approach to ensuring that session-state is consistent on both ends = in all of these cases? It seems to me that one way would be to specify = that rollback of a reINVITE does not invalidate session-state = established with an UPDATE, regardless of whether that UPDATE = transaction occurred (or appeared to have occurred) during the reINVITE = transaction. If we insist that session-state established with an = in-reINVITE UPDATE be rolled back (the current language says that both = sides must roll back to the session-state in use prior to the reINVITE), = then there is no way to ensure consistent rollback on both ends, even if = everything has the same rollback logic, because what appears to be an = in-reINVITE UPDATE on one end may appear to be after the reINVITE = transaction on the other end. If any portion of the UPDATE transaction = appeared to have happened within the reINVITE transaction, then the = observing UA must send=20 > a=20 >>> subsequent UPDATE to re-sync (since there is no guarantee that the = other end saw the UPDATE within the reINVITE transaction). This is = likely to cause glare, unless we put asymmetric timers on the re-sync, = and even then there will be a delay similar to that caused by glare. >>>>=20 >>>> My gut says that it would be better to not rollback = session-state established by an UPDATE, under any circumstances. But, = there may be situations where the session-state established in an UPDATE = is contingent on the reINVITE succeeding it. Would it be appropriate to = say that if a UA "feels" this way, it is responsible for re-syncing? Or = is there something I am missing here? >>>>=20 >>>> Best regards, >>>> Byron Campen >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 From gonzalo.camarillo@ericsson.com Thu Oct 14 08:16:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B279C3A6B0F for ; Thu, 14 Oct 2010 08:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blGh3rk6NHRA for ; Thu, 14 Oct 2010 08:16:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DF7AE3A6B3D for ; Thu, 14 Oct 2010 08:15:52 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-38-4cb71ef63213 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.ED.27351.6FE17BC4; Thu, 14 Oct 2010 17:17:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 17:17:10 +0200 Received: from [131.160.126.182] ([131.160.126.182]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Oct 2010 17:17:09 +0200 Message-ID: <4CB71EF5.90302@ericsson.com> Date: Thu, 14 Oct 2010 18:17:09 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Byron Campen References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> <4CB70B9A.9000309@ericsson.com> <4CB5C633-983E-4A11-AF23-4C6A862E49A0@estacado.net> In-Reply-To: <4CB5C633-983E-4A11-AF23-4C6A862E49A0@estacado.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2010 15:17:09.0596 (UTC) FILETIME=[DEC479C0:01CB6BB2] X-Brightmail-Tracker: AAAAAA== Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:16:24 -0000 Hi Byron, if the UAS is compliant with the new spec, it would not send the 500. It would send the UPDATE to get everything in synch and then send a 200 OK to the INVITE. If the UAS does not support the new spec but the UAC does, the UAC will notice the possible race condition and send an UPDATE to resynch. If none of them supports the new spec... well, there is nothing we can do in that case :o) Cheers, Gonzalo On 14/10/2010 5:06 PM, Byron Campen wrote: > > Alright, that's pretty clear. Now, there is still the question of what happens when the UAS is aware of the specification, but is forced to send a 500 or similar anyway, and then the 500 crosses the UPDATE on the wire, like so: > > | /-| INVITE/500 > | / | > |<-----/---| UPDATE (re-sync offer) > | / | > UPDATE/200 (answer) |----/---->| > | / | > |<-/ | > > > We cannot use the ACK for the 500, since it is hop-by-hop, and if the UAC doesn't re-sync, UAS's attempt to re-sync fails. Are we content with saying that the UAS cannot recover from this? We _could_ avoid this problem by having a rule that says "If you're the UAS, and you rejected the reINVITE with already executed offer/answer changes, you MUST send your re-sync offer in an INVITE", since the other end will reject our re-sync if it beats the 500. > > Best regards, > Byron Campen > > >> Hi, >> >> the condition for resynching given in the draft is when the UA "receives >> an error response to a re-INVITE that undoes already-executed changes >> within the re-INVITE". The draft talks about several situation where UAs >> can go out of synch. >> >> In any case, as you suggest in your email, we are talking about corner >> cases. >> >> Cheers, >> >> Gonzalo >> >> On 14/10/2010 4:46 PM, Byron Campen wrote: >>> >>> Perhaps I phrased my question poorly. My question wasn't so much about what a UA should do when it thinks the session is out of sync, but whether it thinks the session is out of sync in the specific case I posed. But, I suppose that any time we get a reINVITE that is rejected after an offer/answer exchange has been completed, whether or not there had been an UPDATE thrown into the mix, we should assume the worst and re-sync. This will lead to glare fairly often, but we are already in a relatively rare corner-case, so I can see this being acceptable. >>> >>> Best regards, >>> Byron Campen >>> >>>> Hi Byron, >>>> >>>>> Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? >>>> >>>> yes, that is what the re-INVITE draft says: >>>> >>>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >>>> >>>> Figure 5 shows a message flow with a race condition similar to the ones >>>> you are referring to: >>>> >>>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 11/10/2010 8:43 PM, Byron Campen wrote: >>>>> >>>>> Sending to the authors of the offeranswer and reinvite drafts, since I am not sure which bucket this would fall in: >>>>> >>>>> Consider the following. In all cases, this is within a reINVITE transaction, after an offer/answer exchange has completed using 100rel (which kind is not important), that is being rejected by the server side due to some unspecified error: >>>>> >>>>> A B >>>>> |<---------| INVITE/500 >>>>> | | >>>>> | | >>>>> UPDATE (offer) |--------->| >>>>> | | >>>>> |<---------| UPDATE/200 (answer) >>>>> >>>>> A B >>>>> UPDATE (offer) |---\ /---| INVITE/500 >>>>> | \/ | >>>>> | /\ | >>>>> |<--/ \-->| >>>>> | | >>>>> |<---------| UPDATE/200 (answer) >>>>> >>>>> A B >>>>> | /-| INVITE/500 >>>>> | / | >>>>> UPDATE (offer) |------/-->| >>>>> | / | >>>>> |<---/-----| UPDATE/200 (answer) >>>>> | / | >>>>> |<-/ | >>>>> >>>>> All of these look identical to B; UPDATE offer/answer completes after the end of the INVITE transaction. However, A sees them very differently. B cannot know that something unusual has happened. Also consider the following cases: >>>>> >>>>> A B >>>>> UPDATE (offer) |--------->| >>>>> | | >>>>> |<---------| UPDATE/200 (answer) >>>>> | | >>>>> |<---------| INVITE/500 >>>>> >>>>> A B >>>>> UPDATE (offer) |--------->| >>>>> | | >>>>> | /--| UPDATE/200 (answer) >>>>> | / | >>>>> |<----/----| INVITE/500 >>>>> | / | >>>>> |<--/ | >>>>> >>>>> Again, these look the same to B, but different to A. What is the best approach to ensuring that session-state is consistent on both ends in all of these cases? It seems to me that one way would be to specify that rollback of a reINVITE does not invalidate session-state established with an UPDATE, regardless of whether that UPDATE transaction occurred (or appeared to have occurred) during the reINVITE transaction. If we insist that session-state established with an in-reINVITE UPDATE be rolled back (the current language says that both sides must roll back to the session-state in use prior to the reINVITE), then there is no way to ensure consistent rollback on both ends, even if everything has the same rollback logic, because what appears to be an in-reINVITE UPDATE on one end may appear to be after the reINVITE transaction on the other end. If any portion of the UPDATE transaction appeared to have happened within the reINVITE transaction, then the observing UA must sen d >> a >>>> subsequent UPDATE to re-sync (since there is no guarantee that the other end saw the UPDATE within the reINVITE transaction). This is likely to cause glare, unless we put asymmetric timers on the re-sync, and even then there will be a delay similar to that caused by glare. >>>>> >>>>> My gut says that it would be better to not rollback session-state established by an UPDATE, under any circumstances. But, there may be situations where the session-state established in an UPDATE is contingent on the reINVITE succeeding it. Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? Or is there something I am missing here? >>>>> >>>>> Best regards, >>>>> Byron Campen >>>>> >>>>> >>>>> >>>> >>> >> > From gao.yang2@zte.com.cn Thu Oct 14 08:39:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C443A6A6E for ; Thu, 14 Oct 2010 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMB3IgIkdaUw for ; Thu, 14 Oct 2010 08:39:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 97C733A6A67 for ; Thu, 14 Oct 2010 08:39:22 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 14 Oct 2010 23:39:21 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38058.3533455949; Thu, 14 Oct 2010 23:37:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9EFeskG099518; Thu, 14 Oct 2010 23:40:54 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4CB5A795.1000809@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 14 Oct 2010 23:38:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-14 23:40:31, Serialize complete at 2010-10-14 23:40:31 Content-Type: multipart/alternative; boundary="=_alternative 00561B24482577BC_=" X-MAIL: mse2.zte.com.cn o9EFeskG099518 Cc: sipcore@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:39:25 -0000 This is a multipart message in MIME format. --=_alternative 00561B24482577BC_= Content-Type: text/plain; charset="US-ASCII" Paul, > I don't have a good answer for that. Something that comes to mind is for > a copy of the resulting request to be sent to the referring UA as part > of the refer subscription. But it would be difficult to make good use of > that. I have the same feeling as you for it, though we have opposite understanding(I think the UAS should do *semantic* check and *may* have the right to choose the headers to be honored, while you think it is just copy). But for the pure audio usage, the copy way is working. And there's no explicit use case to sustain more detailed discussion/analysis. So, I think that this issue can be closed, at least for now. While, there's another issue about indication for streams in the REFER_with_embedded_Join request. Dale and Christer suggested on it. And I will think it for details, and choose a proper WG to continue. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00561B24482577BC_= Content-Type: text/html; charset="US-ASCII"
Paul,
 
> I don't have a good answer for that. Something that comes to mind is for
> a copy of the resulting request to be sent to the referring UA as part
> of the refer subscription. But it would be difficult to make good use of
> that.
I have the same feeling as you for it, though we have opposite understanding(I think the UAS should do *semantic* check and *may* have the right to choose the headers to be honored, while you think it is just copy).

But for the pure audio usage, the copy way is working. And there's no explicit use case to sustain more detailed discussion/analysis. So, I think that this issue can be closed, at least for now.

While, there's another issue about indication for streams in the REFER_with_embedded_Join request. Dale and Christer suggested on it. And I will think it for details, and choose a proper WG to continue.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00561B24482577BC_=-- From dworley@avaya.com Thu Oct 14 08:55:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A063A6AC4 for ; Thu, 14 Oct 2010 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNTneehjr2os for ; Thu, 14 Oct 2010 08:55:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 869183A695D for ; Thu, 14 Oct 2010 08:55:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,330,1283745600"; d="scan'208";a="242716375" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Oct 2010 11:56:44 -0400 X-IronPort-AV: E=Sophos;i="4.57,330,1283745600"; d="scan'208";a="526546860" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Oct 2010 11:56:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 14 Oct 2010 11:56:44 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" , Robert Sparks Date: Thu, 14 Oct 2010 11:55:28 -0400 Thread-Topic: Errata report for Errata 2161 for RFC3398, "ISDN User Part (ISUP) to SIP Mapping" Thread-Index: AQHLa7hmrB5yHmenO0+9sp/sdCTkEA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Errata report for Errata 2161 for RFC3398, "ISDN User Part (ISUP) to SIP Mapping" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:55:26 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3398, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping" Source of RFC: sipping (rai) Errata ID: 2161 Status: Reported Type: Editorial Reported By: Andrew Miller Date Reported: 2010-04-13 Section 8.2.6.1 says: 504 Version Not Supported 127 Interworking (+) It should say: 505 Version Not Supported 127 Interworking (+) Notes: 504 appears twice with different text. From the context, it looks like the text in the second entry is correct, and the number is wrong. ---------------------------------------------------------------------- Recommended status: (correct) Verified (publish) The erratum is correct. The proposed correction is supported by: (1) the correlation between the list of 5xx response codes in 8.2.6.1 and the list in RFC 3261, (2) the definitions and "standard" texts for the 504 and 505 error responses in RFC 3261, (3) the meanings of the paired ISUP cause codes, and (4) footnote "(+)" of the entry "Version Not Supported". The error is relatively minor, but it would be wise to not require every implementer to solve this puzzle again. Therefore I am recommending that it be published (status Verified). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From bcampen@estacado.net Thu Oct 14 12:26:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7553A6B3D for ; Thu, 14 Oct 2010 12:26:49 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mId7GPag+lUj for ; Thu, 14 Oct 2010 12:26:48 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 351443A6A6E for ; Thu, 14 Oct 2010 12:26:46 -0700 (PDT) Received: from dn3-100.estacado.net (dn3-100.estacado.net [172.16.3.100]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9EJQwsO040949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Oct 2010 14:26:59 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Byron Campen In-Reply-To: <4CB71EF5.90302@ericsson.com> Date: Thu, 14 Oct 2010 14:26:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69AFA4CF-EF45-41C2-8464-3D374AB451A7@estacado.net> References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> <4CB70B9A.9000309@ericsson.com> <4CB5C633-983E-4A11-AF23-4C6A862E49A0@estacado.net> <4CB71EF5.90302@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 19:26:49 -0000 If it is possible to, then sure. But is it really appropriate to = just swallow all non-offer/answer-related errors in this case? Say an = exception gets thrown, or some extension decides that it needs to reject = the INVITE transaction for a very specific reason that the other end = absolutely needs to know about? I definitely agree that sending = something like a 488 (or other session-related errors) is something that = is both completely unnecessary and harmful, but I am less sure about = other error conditions. Best regards, Byron Campen > Hi Byron, >=20 > if the UAS is compliant with the new spec, it would not send the 500. = It > would send the UPDATE to get everything in synch and then send a 200 = OK > to the INVITE. If the UAS does not support the new spec but the UAC > does, the UAC will notice the possible race condition and send an = UPDATE > to resynch. If none of them supports the new spec... well, there is > nothing we can do in that case :o) >=20 > Cheers, >=20 > Gonzalo >=20 > On 14/10/2010 5:06 PM, Byron Campen wrote: >>=20 >> Alright, that's pretty clear. Now, there is still the question = of what happens when the UAS is aware of the specification, but is = forced to send a 500 or similar anyway, and then the 500 crosses the = UPDATE on the wire, like so: >>=20 >> | /-| INVITE/500 >> | / | >> |<-----/---| UPDATE (re-sync offer) >> | / | >> UPDATE/200 (answer) |----/---->|=20 >> | / | >> |<-/ | >>=20 >>=20 >> We cannot use the ACK for the 500, since it is hop-by-hop, and = if the UAC doesn't re-sync, UAS's attempt to re-sync fails. Are we = content with saying that the UAS cannot recover from this? We _could_ = avoid this problem by having a rule that says "If you're the UAS, and = you rejected the reINVITE with already executed offer/answer changes, = you MUST send your re-sync offer in an INVITE", since the other end will = reject our re-sync if it beats the 500. >>=20 >> Best regards, >> Byron Campen >>=20 >>=20 >>> Hi, >>>=20 >>> the condition for resynching given in the draft is when the UA = "receives >>> an error response to a re-INVITE that undoes already-executed = changes >>> within the re-INVITE". The draft talks about several situation where = UAs >>> can go out of synch. >>>=20 >>> In any case, as you suggest in your email, we are talking about = corner >>> cases. >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>> On 14/10/2010 4:46 PM, Byron Campen wrote: >>>>=20 >>>> Perhaps I phrased my question poorly. My question wasn't so much = about what a UA should do when it thinks the session is out of sync, but = whether it thinks the session is out of sync in the specific case I = posed. But, I suppose that any time we get a reINVITE that is rejected = after an offer/answer exchange has been completed, whether or not there = had been an UPDATE thrown into the mix, we should assume the worst and = re-sync. This will lead to glare fairly often, but we are already in a = relatively rare corner-case, so I can see this being acceptable. >>>>=20 >>>> Best regards, >>>> Byron Campen >>>>=20 >>>>> Hi Byron, >>>>>=20 >>>>>> Would it be appropriate to say that if a UA "feels" this way, it = is responsible for re-syncing? >>>>>=20 >>>>> yes, that is what the re-INVITE draft says: >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >>>>>=20 >>>>> Figure 5 shows a message flow with a race condition similar to the = ones >>>>> you are referring to: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>> On 11/10/2010 8:43 PM, Byron Campen wrote: >>>>>>=20 >>>>>> Sending to the authors of the offeranswer and reinvite drafts, = since I am not sure which bucket this would fall in: >>>>>>=20 >>>>>> Consider the following. In all cases, this is within a reINVITE = transaction, after an offer/answer exchange has completed using 100rel = (which kind is not important), that is being rejected by the server side = due to some unspecified error: >>>>>>=20 >>>>>> A B >>>>>> |<---------| INVITE/500 >>>>>> | | >>>>>> | | >>>>>> UPDATE (offer) |--------->| >>>>>> | | >>>>>> |<---------| UPDATE/200 (answer) >>>>>>=20 >>>>>> A B >>>>>> UPDATE (offer) |---\ /---| INVITE/500 >>>>>> | \/ | >>>>>> | /\ | >>>>>> |<--/ \-->| >>>>>> | | >>>>>> |<---------| UPDATE/200 (answer) >>>>>>=20 >>>>>> A B >>>>>> | /-| INVITE/500 >>>>>> | / | >>>>>> UPDATE (offer) |------/-->| >>>>>> | / | >>>>>> |<---/-----| UPDATE/200 (answer) >>>>>> | / | >>>>>> |<-/ | >>>>>>=20 >>>>>> All of these look identical to B; UPDATE offer/answer completes = after the end of the INVITE transaction. However, A sees them very = differently. B cannot know that something unusual has happened. Also = consider the following cases: >>>>>>=20 >>>>>> A B >>>>>> UPDATE (offer) |--------->| >>>>>> | | >>>>>> |<---------| UPDATE/200 (answer) >>>>>> | | >>>>>> |<---------| INVITE/500 >>>>>>=20 >>>>>> A B >>>>>> UPDATE (offer) |--------->| >>>>>> | | >>>>>> | /--| UPDATE/200 (answer) >>>>>> | / | >>>>>> |<----/----| INVITE/500 >>>>>> | / | >>>>>> |<--/ | >>>>>>=20 >>>>>> Again, these look the same to B, but different to A. What is the = best approach to ensuring that session-state is consistent on both ends = in all of these cases? It seems to me that one way would be to specify = that rollback of a reINVITE does not invalidate session-state = established with an UPDATE, regardless of whether that UPDATE = transaction occurred (or appeared to have occurred) during the reINVITE = transaction. If we insist that session-state established with an = in-reINVITE UPDATE be rolled back (the current language says that both = sides must roll back to the session-state in use prior to the reINVITE), = then there is no way to ensure consistent rollback on both ends, even if = everything has the same rollback logic, because what appears to be an = in-reINVITE UPDATE on one end may appear to be after the reINVITE = transaction on the other end. If any portion of the UPDATE transaction = appeared to have happened within the reINVITE transaction, then the = observing UA must sen > d=20 >>> a=20 >>>>> subsequent UPDATE to re-sync (since there is no guarantee that the = other end saw the UPDATE within the reINVITE transaction). This is = likely to cause glare, unless we put asymmetric timers on the re-sync, = and even then there will be a delay similar to that caused by glare. >>>>>>=20 >>>>>> My gut says that it would be better to not rollback = session-state established by an UPDATE, under any circumstances. But, = there may be situations where the session-state established in an UPDATE = is contingent on the reINVITE succeeding it. Would it be appropriate to = say that if a UA "feels" this way, it is responsible for re-syncing? Or = is there something I am missing here? >>>>>>=20 >>>>>> Best regards, >>>>>> Byron Campen >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From gonzalo.camarillo@ericsson.com Fri Oct 15 00:29:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201273A6774 for ; Fri, 15 Oct 2010 00:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ETSIkgU655 for ; Fri, 15 Oct 2010 00:29:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 51ED23A6A6D for ; Fri, 15 Oct 2010 00:29:06 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-0b-4cb80312e557 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.5A.27351.21308BC4; Fri, 15 Oct 2010 09:30:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 09:30:25 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 09:30:25 +0200 Message-ID: <4CB80311.9020805@ericsson.com> Date: Fri, 15 Oct 2010 10:30:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Byron Campen References: <4A3A728B-54C7-4E7D-B523-DC86D659A851@estacado.net> <4CB6EF77.9040509@ericsson.com> <4CB70B9A.9000309@ericsson.com> <4CB5C633-983E-4A11-AF23-4C6A862E49A0@estacado.net> <4CB71EF5.90302@ericsson.com> <69AFA4CF-EF45-41C2-8464-3D374AB451A7@estacado.net> In-Reply-To: <69AFA4CF-EF45-41C2-8464-3D374AB451A7@estacado.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2010 07:30:25.0471 (UTC) FILETIME=[D56BDCF0:01CB6C3A] X-Brightmail-Tracker: AAAAAA== Cc: "shinji.okumura@softfront.jp" , SIPCORE , "gao.yang2@zte.com.cn" Subject: Re: [sipcore] UPDATE, reINVITE rejections, and session-state rollback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 07:29:08 -0000 Hi Byron, you could use a Reason header field in the UPDATE request in order to communicate the error code to the UAC... but if you insist in sending the error response anyway, then the UAS needs to decide between sending the UPDATE immediately (the fastest way to resynch if it works, but it may collide with an UPDATE from the UAC if the UAC decided to resynch as well when it saw the error response) or implement a timer to wait for a 'short' time in case an UPDATE from the UAC arrives. Cheers, Gonzalo On 14/10/2010 10:26 PM, Byron Campen wrote: > > If it is possible to, then sure. But is it really appropriate to just swallow all non-offer/answer-related errors in this case? Say an exception gets thrown, or some extension decides that it needs to reject the INVITE transaction for a very specific reason that the other end absolutely needs to know about? I definitely agree that sending something like a 488 (or other session-related errors) is something that is both completely unnecessary and harmful, but I am less sure about other error conditions. > > Best regards, > Byron Campen > >> Hi Byron, >> >> if the UAS is compliant with the new spec, it would not send the 500. It >> would send the UPDATE to get everything in synch and then send a 200 OK >> to the INVITE. If the UAS does not support the new spec but the UAC >> does, the UAC will notice the possible race condition and send an UPDATE >> to resynch. If none of them supports the new spec... well, there is >> nothing we can do in that case :o) >> >> Cheers, >> >> Gonzalo >> >> On 14/10/2010 5:06 PM, Byron Campen wrote: >>> >>> Alright, that's pretty clear. Now, there is still the question of what happens when the UAS is aware of the specification, but is forced to send a 500 or similar anyway, and then the 500 crosses the UPDATE on the wire, like so: >>> >>> | /-| INVITE/500 >>> | / | >>> |<-----/---| UPDATE (re-sync offer) >>> | / | >>> UPDATE/200 (answer) |----/---->| >>> | / | >>> |<-/ | >>> >>> >>> We cannot use the ACK for the 500, since it is hop-by-hop, and if the UAC doesn't re-sync, UAS's attempt to re-sync fails. Are we content with saying that the UAS cannot recover from this? We _could_ avoid this problem by having a rule that says "If you're the UAS, and you rejected the reINVITE with already executed offer/answer changes, you MUST send your re-sync offer in an INVITE", since the other end will reject our re-sync if it beats the 500. >>> >>> Best regards, >>> Byron Campen >>> >>> >>>> Hi, >>>> >>>> the condition for resynching given in the draft is when the UA "receives >>>> an error response to a re-INVITE that undoes already-executed changes >>>> within the re-INVITE". The draft talks about several situation where UAs >>>> can go out of synch. >>>> >>>> In any case, as you suggest in your email, we are talking about corner >>>> cases. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 14/10/2010 4:46 PM, Byron Campen wrote: >>>>> >>>>> Perhaps I phrased my question poorly. My question wasn't so much about what a UA should do when it thinks the session is out of sync, but whether it thinks the session is out of sync in the specific case I posed. But, I suppose that any time we get a reINVITE that is rejected after an offer/answer exchange has been completed, whether or not there had been an UPDATE thrown into the mix, we should assume the worst and re-sync. This will lead to glare fairly often, but we are already in a relatively rare corner-case, so I can see this being acceptable. >>>>> >>>>> Best regards, >>>>> Byron Campen >>>>> >>>>>> Hi Byron, >>>>>> >>>>>>> Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? >>>>>> >>>>>> yes, that is what the re-INVITE draft says: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#section-3.4 >>>>>> >>>>>> Figure 5 shows a message flow with a race condition similar to the ones >>>>>> you are referring to: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-06#page-16 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 11/10/2010 8:43 PM, Byron Campen wrote: >>>>>>> >>>>>>> Sending to the authors of the offeranswer and reinvite drafts, since I am not sure which bucket this would fall in: >>>>>>> >>>>>>> Consider the following. In all cases, this is within a reINVITE transaction, after an offer/answer exchange has completed using 100rel (which kind is not important), that is being rejected by the server side due to some unspecified error: >>>>>>> >>>>>>> A B >>>>>>> |<---------| INVITE/500 >>>>>>> | | >>>>>>> | | >>>>>>> UPDATE (offer) |--------->| >>>>>>> | | >>>>>>> |<---------| UPDATE/200 (answer) >>>>>>> >>>>>>> A B >>>>>>> UPDATE (offer) |---\ /---| INVITE/500 >>>>>>> | \/ | >>>>>>> | /\ | >>>>>>> |<--/ \-->| >>>>>>> | | >>>>>>> |<---------| UPDATE/200 (answer) >>>>>>> >>>>>>> A B >>>>>>> | /-| INVITE/500 >>>>>>> | / | >>>>>>> UPDATE (offer) |------/-->| >>>>>>> | / | >>>>>>> |<---/-----| UPDATE/200 (answer) >>>>>>> | / | >>>>>>> |<-/ | >>>>>>> >>>>>>> All of these look identical to B; UPDATE offer/answer completes after the end of the INVITE transaction. However, A sees them very differently. B cannot know that something unusual has happened. Also consider the following cases: >>>>>>> >>>>>>> A B >>>>>>> UPDATE (offer) |--------->| >>>>>>> | | >>>>>>> |<---------| UPDATE/200 (answer) >>>>>>> | | >>>>>>> |<---------| INVITE/500 >>>>>>> >>>>>>> A B >>>>>>> UPDATE (offer) |--------->| >>>>>>> | | >>>>>>> | /--| UPDATE/200 (answer) >>>>>>> | / | >>>>>>> |<----/----| INVITE/500 >>>>>>> | / | >>>>>>> |<--/ | >>>>>>> >>>>>>> Again, these look the same to B, but different to A. What is the best approach to ensuring that session-state is consistent on both ends in all of these cases? It seems to me that one way would be to specify that rollback of a reINVITE does not invalidate session-state established with an UPDATE, regardless of whether that UPDATE transaction occurred (or appeared to have occurred) during the reINVITE transaction. If we insist that session-state established with an in-reINVITE UPDATE be rolled back (the current language says that both sides must roll back to the session-state in use prior to the reINVITE), then there is no way to ensure consistent rollback on both ends, even if everything has the same rollback logic, because what appears to be an in-reINVITE UPDATE on one end may appear to be after the reINVITE transaction on the other end. If any portion of the UPDATE transaction appeared to have happened within the reINVITE transaction, then the observing UA must s en >> d >>>> a >>>>>> subsequent UPDATE to re-sync (since there is no guarantee that the other end saw the UPDATE within the reINVITE transaction). This is likely to cause glare, unless we put asymmetric timers on the re-sync, and even then there will be a delay similar to that caused by glare. >>>>>>> >>>>>>> My gut says that it would be better to not rollback session-state established by an UPDATE, under any circumstances. But, there may be situations where the session-state established in an UPDATE is contingent on the reINVITE succeeding it. Would it be appropriate to say that if a UA "feels" this way, it is responsible for re-syncing? Or is there something I am missing here? >>>>>>> >>>>>>> Best regards, >>>>>>> Byron Campen >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From aallen@rim.com Fri Oct 15 02:56:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B6A3A6AA7 for ; Fri, 15 Oct 2010 02:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1uKV3pP0Pc5 for ; Fri, 15 Oct 2010 02:56:33 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id F14313A68AE for ; Fri, 15 Oct 2010 02:56:31 -0700 (PDT) X-AuditID: 0a666446-b7bf6ae000000af4-31-4cb8259f1e90 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 13.B2.02804.F9528BC4; Fri, 15 Oct 2010 05:57:51 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 05:57:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Oct 2010 04:57:48 -0500 Message-ID: In-Reply-To: <4CA0AE61.7060003@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] Thread-Index: ActeUuxJMS+ZZod8TG2NVYRnnZYJ4AN+cE2Q References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com> From: "Andrew Allen" To: "Paul Kyzivat" , "Christer Holmberg" X-OriginalArrivalTime: 15 Oct 2010 09:57:53.0949 (UTC) FILETIME=[6F8674D0:01CB6C4F] X-Brightmail-Tracker: AAAAAgAAAZEWVk1C Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 09:56:38 -0000 The general problem stated in this draft of the need to identify in the various SIP routing headers the presence of an intermediary that can perform particular features for the UA is I believe a problem worth working on. In SIP networks intermediaries (such as IP-PBXs and Application Servers) sometimes act as proxies but also as UAs (or B2BUAs). In order to initiate features provided by these intermediaries a UA may need to send them SIP requests. However in order to act as a proxy and provide transparency of the Contact header the intermediary should be passing the Contact header transparently. However this presents the problem that a UA may need to send this intermediary a SIP request (such as a REFER) but does not have a contact address of the intermediary to include in the Request-URI. If the intermediary can provide an indicator in a Record-Route header then this could enable the UA to identify the presence of the intermediary and the features supported by it and obtain from the Record-Route header the URI to address requests that are needed to be sent to that intermediary in order to initiate the features supported by the intermediary. I would like to see a generic solution for this. The details of the technical solution is a matter for the usual debate and discussion but I think the draft is a good starting point for initiating this discussion. Andrew -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, September 27, 2010 9:47 AM To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] [as chair] To all sipcore participants: Christer has been looking for a way to accomplish a particular function that 3gpp wants. This proposal seems a plausible way to do that. But it is of necessity defining a more general mechanism. I'd really appreciate comments from others (including people in no way involved with 3gpp) regarding this mechanism. For instance, do you consider the semantics to be well defined? Do you see need for more about security implications? How many would find this useful to have? Thanks, Paul On 9/24/2010 7:04 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a draft, which extends the rr-param rule, allowing proxies to indicate supported features using feature tags in Path, Record-Route etc. > > The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feat ure-00.txt > > As I indicated earlier on the list, and as you can read in the draft, there is a 3GPP use-case where we believe the mechanism could be used. But, there is nothing 3GPP specific about the mechanism as such. > > Regards, > > Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@cisco.com Fri Oct 15 05:48:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327F13A69A4 for ; Fri, 15 Oct 2010 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT57nWE0Uemf for ; Fri, 15 Oct 2010 05:48:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0B9A83A6A94 for ; Fri, 15 Oct 2010 05:48:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUFANfqt0xAZnwN/2dsb2JhbACTJo17caE2nECFSQSKSoME X-IronPort-AV: E=Sophos;i="4.57,336,1283731200"; d="scan'208";a="170844284" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Oct 2010 12:49:41 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9FCneKT005117; Fri, 15 Oct 2010 12:49:40 GMT Message-ID: <4CB84DE4.60707@cisco.com> Date: Fri, 15 Oct 2010 08:49:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 12:48:21 -0000 Gao, I presume you will be attending the meeting in Beijing? This might be a good topic for a hallway discussion. Thanks, Paul On 10/14/2010 11:38 AM, gao.yang2@zte.com.cn wrote: > > Paul, > > > I don't have a good answer for that. Something that comes to mind is for > > a copy of the resulting request to be sent to the referring UA as part > > of the refer subscription. But it would be difficult to make good use of > > that. > > I have the same feeling as you for it, though we have opposite > understanding(I think the UAS should do *semantic* check and *may* have > the right to choose the headers to be honored, while you think it is > just copy). > > But for the pure audio usage, the copy way is working. And there's no > explicit use case to sustain more detailed discussion/analysis. So, I > think that this issue can be closed, at least for now. > > While, there's another issue about indication for streams in the > REFER_with_embedded_Join request. Dale and Christer suggested on it. And > I will think it for details, and choose a proper WG to continue. > > Thanks, > > Gao > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From christer.holmberg@ericsson.com Fri Oct 15 05:52:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2AE3A69A4 for ; Fri, 15 Oct 2010 05:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNxzXVP0zRj2 for ; Fri, 15 Oct 2010 05:52:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 339C33A68F3 for ; Fri, 15 Oct 2010 05:52:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7b26ae00000638e-c4-4cb84eb972f9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.22.25486.9BE48BC4; Fri, 15 Oct 2010 14:53:13 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 15 Oct 2010 14:53:09 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 15 Oct 2010 14:53:07 +0200 From: Christer Holmberg To: Paul Kyzivat , "gao.yang2@zte.com.cn" Date: Fri, 15 Oct 2010 14:53:06 +0200 Thread-Topic: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? Thread-Index: ActsZ3OLMjOTL/vqQCSY2br7jVhCkwAAE7zw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502E26192@ESESSCMS0356.eemea.ericsson.se> References: <4CB84DE4.60707@cisco.com> In-Reply-To: <4CB84DE4.60707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 12:52:09 -0000 Hi, I think such discussion would be good, and I would like to participate. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 15. lokakuuta 2010 15:50 > To: gao.yang2@zte.com.cn > Cc: sipcore@ietf.org > Subject: Re: [sipcore] About RFC3911(Join header)'s potential=20 > error: //Join header in REFER? >=20 > Gao, >=20 > I presume you will be attending the meeting in Beijing? >=20 > This might be a good topic for a hallway discussion. >=20 > Thanks, > Paul >=20 > On 10/14/2010 11:38 AM, gao.yang2@zte.com.cn wrote: > > > > Paul, > > > > > I don't have a good answer for that. Something that=20 > comes to mind=20 > > is for > a copy of the resulting request to be sent to the=20 > referring=20 > > UA as part > of the refer subscription. But it would be=20 > difficult to=20 > > make good use of > that. > > > > I have the same feeling as you for it, though we have opposite=20 > > understanding(I think the UAS should do *semantic* check and *may*=20 > > have the right to choose the headers to be honored, while=20 > you think it=20 > > is just copy). > > > > But for the pure audio usage, the copy way is working. And=20 > there's no=20 > > explicit use case to sustain more detailed=20 > discussion/analysis. So, I=20 > > think that this issue can be closed, at least for now. > > > > While, there's another issue about indication for streams in the=20 > > REFER_with_embedded_Join request. Dale and Christer=20 > suggested on it.=20 > > And I will think it for details, and choose a proper WG to continue. > > > > Thanks, > > > > Gao > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information =20 > contained in this mail is solely property of the =20 > sender's organization. This mail communication is =20 > confidential. Recipients named above are obligated to =20 > maintain secrecy and are not permitted to disclose =20 > the contents of this communication to others. > > This email and any files transmitted with it are =20 > confidential and intended solely for the use of the =20 > individual or entity to whom they are addressed. If =20 > you have received this email in error please notify =20 > the originator of the message. Any views expressed in=20 > this message are those of the individual sender. > > This message has been scanned for viruses and Spam =20 > by ZTE Anti-Spam system. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From aallen@rim.com Fri Oct 15 06:58:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015733A6C81 for ; Fri, 15 Oct 2010 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO2a0xZGT5tZ for ; Fri, 15 Oct 2010 06:58:46 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D924D3A6C7E for ; Fri, 15 Oct 2010 06:58:45 -0700 (PDT) X-AuditID: 0a401fcb-b7b8cae000005c8c-8e-4cb85e64e2a0 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id E5.85.23692.46E58BC4; Fri, 15 Oct 2010 10:00:05 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 10:00:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Oct 2010 08:59:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] Thread-Index: ActfGZHyq0CAqF9USIuruRF+AoMFeANV09tg References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se><4C936714.2040808@cisco.com><7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se><4C936E79.3070906@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se><4C938ED5.10507@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se><4C93E4DE.9070802@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se><4CA0AE61.7060003@cisco.com> From: "Andrew Allen" To: "Hadriel Kaplan" , "Peter Musgrave" X-OriginalArrivalTime: 15 Oct 2010 14:00:05.0605 (UTC) FILETIME=[45113150:01CB6C71] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 13:58:51 -0000 Hadriel And there I was thinking that SBCs were these amazingly flexible devices that could remove, modify or add any SIP primitive to any message based on the service providers desires - but now it turns out that in reality that they can't even add a feature tag to a routing header! Andrew -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, September 28, 2010 9:29 AM To: Peter Musgrave Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] On Sep 27, 2010, at 7:14 PM, Peter Musgrave wrote: > Hi, > > I read the draft and I think the semantics are ok (although John's > point about multiple proxies with these tags is a good one). > > One use which occurred to me - but which is no doubt controversial - > is whether a proxy/B2B which is an SBC could provide a feature tag > indicating it is an SBC - so that UAs which register and call through > it could skip adding ICE candidates. (My point is merely that I > suspect other uses for this capability will be found - even if you > think this particular idea is mis-guided). > Right, that particular idea is mis-guided. :) What you'd really do for that is indicate whether or not the b2bua supports ICE (since some SBC's do, and some don't, indicating you're an SBC doesn't help). There already is a feature tag for ICE ("sip.ice"), but such a thing would break immediately - since ICE is a new thing, legacy SBC's wouldn't know to say they don't do it, and there is no "!(feature-tag)" anyway; and the UA doesn't know whether it's talking through SBC's or plain proxies to begin with, and if they're plain proxies they wouldn't say anything about ice ever... so the UA can never guess this right. If it gets back "sip.ice" then it knows for that one hop that said so it's ok, but it knows nothing about the rest. -hadriel _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From colin.pons@gmail.com Sat Oct 16 11:48:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1573A6ADF for ; Sat, 16 Oct 2010 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.821 X-Spam-Level: ** X-Spam-Status: No, score=2.821 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EMPTY_MESSAGE=1.439, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QACDpenlTB1 for ; Sat, 16 Oct 2010 11:48:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 66F6A3A6AD7 for ; Sat, 16 Oct 2010 11:48:25 -0700 (PDT) Received: by ewy6 with SMTP id 6so1356165ewy.31 for ; Sat, 16 Oct 2010 11:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:date:to :message-id:content-type:mime-version; bh=DUm7pjJSH1C7Yo05I+p3SN0tHTkqGv25DlyhQ4l4Aig=; b=C4TsZXCvBKMUEd+OfZXs+66P4v8o/918ynDDt7Db01+DmpF0J8tn078v+qfRHIgYKK G+tTbzBBgt8GDeAdF/98aM51N8C1qGey2ut7F4IxzYV5C36moC2ISvwZl36FEcsp8yDM ncGaoN7SuoLeHXNYguR3Y7RwSEeiOZq5sOs2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:date:to:message-id:content-type:mime-version; b=slobVpPWr3HLK4bV/5mHDts9qYffR2Degz5BebEFgqtEVciNVcZZ5RmYtp8qqJMNTY D/+cBcsyAPw9XMB8pxABsJHpg63nQ7W192zzINAgyve5S5tIUcttTj7ALUZVKrNRoqcb Jr3wZdHlOYfp21V+O/BuFRUuXVRsA69FPWIYs= Received: by 10.213.13.3 with SMTP id z3mr1523183ebz.28.1287254988882; Sat, 16 Oct 2010 11:49:48 -0700 (PDT) Received: from localhost (host066-001.kpn-gprs.nl [62.133.66.1]) by mx.google.com with ESMTPS id q54sm16218018eeh.12.2010.10.16.11.49.40 (version=SSLv3 cipher=RC4-MD5); Sat, 16 Oct 2010 11:49:44 -0700 (PDT) From: Colin Pons Date: Sat, 16 Oct 2010 20:49:28 +0200 To: sipcore@ietf.org Message-ID: Content-Type: multipart/mixed; boundary="----SFK6FTH5ST88CAPD1OYJSX7LYE4SDE" MIME-Version: 1.0 Subject: [sipcore] (no subject) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 18:48:26 -0000 ------SFK6FTH5ST88CAPD1OYJSX7LYE4SDE - ------SFK6FTH5ST88CAPD1OYJSX7LYE4SDE-- From jmpolk@cisco.com Mon Oct 18 12:10:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49D33A6D0B for ; Mon, 18 Oct 2010 12:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-ilf1rSebzh for ; Mon, 18 Oct 2010 12:10:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 364F33A69F0 for ; Mon, 18 Oct 2010 12:10:12 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKM4vEyrR7Ht/2dsb2JhbACTMI19caN4nEUCgwUIgjoEhFQ X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="285421213" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2010 19:11:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9IJBexL017690 for ; Mon, 18 Oct 2010 19:11:41 GMT Message-Id: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Oct 2010 14:11:38 -0500 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 19:10:14 -0000 I have several comments about http://www.ietf.org/id/draft-mohali-sipcore-reason-call-forwarding-00.txt Initially, I'm wondering why the Reason header protocol "SIP" isn't sufficient with a 181 reason code. I don't believe you account for that possibility (i.e., what different is supposed to happen when this occurs?). Then I get to the fact that in your example, you don't include a Reason header in any of your decoded SIP messages, so I'm wondering what your example is really showing us (especially that's different that a "Reason: SIP=181" with or without a text string saying something like "Call is (or has been) forwarded"). Then I get back to your 3rd para in the 1st section that states this as the main possibility for why this extension is proposed: " This might help other applications/entities invoked downstream to take appropriate decisions to avoid undesired service interactions or to take advantage of this information (eg. delivering the appropriate voicemail announcement). " And I ask myself, how are the 8 Reason codes justified in this sentence? Then I ask myself about the 8 Reason codes, and see how much actual information they reveal: 1 Unknown/not available 2 User Busy 3 No reply 4 Unconditional 5 Deflection during alerting 6 Deflection immediate response 7 Mobile subscriber not reachable 8 Not Logged-in ...and think, that for #1 - you wouldn't include that in a 302 (as in your example), as an unknown is probably not going to get retargeted, but rather a 4XX response that doesn't need a reason. #2 - that's probably telling the caller more that the called party wants them to know, and doesn't always play nice with a call-waiting function. #3 - why would you include this in the 181 or 302? #4 - again, this seems like more information that the called probably wants revealed, or this is just a matter of fact scenario that is normal, so why give this additional information. #5 - this is also probably more than the called wants to tell the callee. #6 - I can't tell why this is different from an "Unconditional" reason. #7 - do you really want the callee - every time that number is called - to know that this is a mobile phone? #8 - I don't believe you will want to inform the callee that the person they called is no-logged-in,but rather make this a Not-available Reason, which is similar to a "Reason: SIP=181", which is available now. James From dworley@avaya.com Mon Oct 18 14:11:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE923A6BE9 for ; Mon, 18 Oct 2010 14:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jtC2F+8Te8S for ; Mon, 18 Oct 2010 14:11:21 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9CCEF3A6A82 for ; Mon, 18 Oct 2010 14:11:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,346,1283745600"; d="scan'208";a="39571264" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Oct 2010 17:12:49 -0400 X-IronPort-AV: E=Sophos;i="4.57,346,1283745600"; d="scan'208";a="527654972" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Oct 2010 17:12:48 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 18 Oct 2010 17:12:48 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Mon, 18 Oct 2010 17:12:17 -0400 Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9 Message-ID: References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> In-Reply-To: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:11:25 -0000 Here are some more comments on this draft: The term "call diversion" sounds more inclusive to the naive ear than "call forwarding". If the two terms are used identically in the draft, it seems better to use only the former, especially because the abbreviation "CDIV" is being used. Section 3 does not give any BNF for CDIV, though it quotes all of the established BNF for the Reason header. Clearly, what is intended (but not stated) is: protocol =3D/ "CDIV" In regard to listing the CDIV cause values, it seems to me that there should be an existing encoding of call diversion reasons somewhere within the 3GPP specification, and it would be more effective for the draft to reference that table (which would be maintained by 3GPP) rather than defining a new IANA registry (which would be used almost exclusively by 3GPP). In the example, it appears that the 302 response F3 is informing the proxy that the call should be sent to Voicemail. In that case, the 302 would also carry the Reason header explaing why the diversion is being done, which the proxy would subsequently transcribe into the History-Info header of the new INVITE F5: F3: 302 Bob -> proxy.example.com SIP/2.0 302 Moved Temporarily Via: SIP/2.0/TCP 192.0.2.4:5060;branch=3Dz9hG4bK-ik80k7g-1 Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK-klj79f From: Alice ; tag=3D1234567 To: sip:+15551002@example.com;user=3Dphone;tag=3D765432 Call-ID: c3x842276298220188511 Contact: Reason: CDIV;cause=3D6;text=3D"Deflection immediate response" CSeq: 1 INVITE Content-Length: 0 In the example, F5 has two "Reason" headers attached to the URI at index 1. If you have more than one "header" attached to a URI, only the first is introduced with "?", the remainder are introduced with "&": History-Info: ;index= =3D1, ;index=3D1.1;mp=3D1 There are also some difficulties regarding the History-Info headers in the examle; they don't appear to be consistently applied to all the INVITEs. Dale From root@core3.amsl.com Mon Oct 18 23:30:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5DDF83A6A7A; Mon, 18 Oct 2010 23:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101019063002.5DDF83A6A7A@core3.amsl.com> Date: Mon, 18 Oct 2010 23:30:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-keep-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 06:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Indication of support for keep-alive Author(s) : C. Holmberg Filename : draft-ietf-sipcore-keep-08.txt Pages : 17 Date : 2010-10-18 This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-keep-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-keep-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18232311.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 19 12:15:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D4A043A690C; Tue, 19 Oct 2010 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101019191501.D4A043A690C@core3.amsl.com> Date: Tue, 19 Oct 2010 12:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-05.txt Pages : 24 Date : 2010-10-19 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-event-rate-control-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-19121236.I-D@ietf.org> --NextPart-- From marianne.mohali@orange-ftgroup.com Wed Oct 20 08:02:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117243A682F for ; Wed, 20 Oct 2010 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdV31Zl9E1Uh for ; Wed, 20 Oct 2010 08:02:24 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id C8AA73A6827 for ; Wed, 20 Oct 2010 08:02:23 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7E878B8004; Wed, 20 Oct 2010 17:04:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id E07858B8014; Wed, 20 Oct 2010 17:04:40 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 17:03:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 17:03:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New draft extending Reason header Thread-Index: ActrDqFed2GxkeNBTzCdoDr59q6yRQEZkblA References: From: To: X-OriginalArrivalTime: 20 Oct 2010 15:03:48.0970 (UTC) FILETIME=[000924A0:01CB7068] Cc: bruno.chatras@orange-ftgroup.com, sipcore@ietf.org Subject: Re: [sipcore] New draft extending Reason header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:02:25 -0000 Hi Mary, The need you describe is to add a Reason header without (actually = "before") receiving the explicit SIP response (so, the status code) from = the UA. This need is not exactly the same that the one I intend to address but = the common point is to use the Reason header without receiving an = explicit SIP response.=20 We could, may be, find a way to address both needs but I don't know how. = Let's think about it... Regards, Marianne =20 -----Message d'origine----- De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Envoy=E9 : mercredi 13 octobre 2010 21:41 =C0 : MOHALI Marianne RD-CORE-ISS Cc : sipcore@ietf.org; CHATRAS Bruno RD-CORE-ISS Objet : Re: [sipcore] New draft extending Reason header Hi Marianne, I haven't reviewed the draft in detail, however, I also had the same = thought with regards to the usefulness of these Reasons for History-Info = when I saw the draft earlier today. I think we might also be able to = use this for the parallel forking issue ( #20 ) in that we could add = these reasons to the hi-entries to which the request didn't terminate = (i.e., the legs that are Canceled after the 200ok is sent for the = request that successfully terminated) rather than leaving the entries = with no Reason and having it be inferred. I will review the draft in detail later (once I finish all these 4244bis = changes). Thanks, Mary. On Wed, Oct 13, 2010 at 2:06 PM, = wrote: > > Hi, > > We've submitted a draft, which extends the Reason header, allowing=20 > proxies to indicate an application-specific reason in the SIP message. > > The draft can be found at: > http://www.ietf.org/id/draft-mohali-sipcore-reason-extension-applicati > on > -00.txt > > We think that it would be usefull to have this kind of=20 > application-specific reasons especially in the History-Info header=20 > when a call has been retargeted by an Application. > > We would like to get some feedback on the proposed I-D and a=20 > confirmation of interest from the IETF community (SIPCORE). > > Best Regards, > > Marianne Mohali > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Wed Oct 20 14:02:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2A03A67FA for ; Wed, 20 Oct 2010 14:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlkeoL0wHwlG for ; Wed, 20 Oct 2010 14:02:57 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9832F3A67A7 for ; Wed, 20 Oct 2010 14:02:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,356,1283745600"; d="scan'208";a="212846602" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Oct 2010 17:04:29 -0400 X-IronPort-AV: E=Sophos;i="4.57,356,1283745600"; d="scan'208";a="528401257" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Oct 2010 17:04:28 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 20 Oct 2010 17:04:28 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Wed, 20 Oct 2010 17:02:42 -0400 Thread-Topic: reg event package Thread-Index: AQHLcJpiXRsDyUI5IUK6wZxEEGZE5g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:02:57 -0000 Are there extensions for the reg (registration) event package to report the= Path for the registration, or the reg-id for SIP Outbound? Dale From rjsparks@nostrum.com Wed Oct 20 14:03:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B442E3A6933 for ; Wed, 20 Oct 2010 14:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3CLtzg0o3PV for ; Wed, 20 Oct 2010 14:03:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 85DE33A6905 for ; Wed, 20 Oct 2010 14:03:57 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9KL5TRN029339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Oct 2010 16:05:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Robert Sparks In-Reply-To: <20101019191501.D4A043A690C@core3.amsl.com> Date: Wed, 20 Oct 2010 16:05:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4689C762-8926-483A-B8FE-65843F56DDC6@nostrum.com> References: <20101019191501.D4A043A690C@core3.amsl.com> To: SIPCORE X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:03:59 -0000 I've requested IETF last call on this version of the document. Watch for = its announcement shortly. RjS On Oct 19, 2010, at 2:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Session Initiation Protocol Core = Working Group of the IETF. >=20 >=20 > Title : Session Initiation Protocol (SIP) Event = Notification Extension for Notification Rate Control > Author(s) : A. Niemi, et al. > Filename : draft-ietf-sipcore-event-rate-control-05.txt > Pages : 24 > Date : 2010-10-19 >=20 > This document specifies mechanisms for adjusting the rate of Session > Initiation Protocol (SIP) event notifications. These mechanisms can > be applied in subscriptions to all SIP event packages. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-= 05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Oct 20 14:16:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D003A6826 for ; Wed, 20 Oct 2010 14:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huhQ81d+N8PT for ; Wed, 20 Oct 2010 14:16:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1BFF83A680C for ; Wed, 20 Oct 2010 14:16:07 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAGf5vkxAZnwM/2dsb2JhbACTZY1rcaMRnEKFSgSKS4ME X-IronPort-AV: E=Sophos;i="4.57,357,1283731200"; d="scan'208";a="173103563" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2010 21:17:39 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9KLHd1m016884 for ; Wed, 20 Oct 2010 21:17:39 GMT Message-ID: <4CBF5C73.8050705@cisco.com> Date: Wed, 20 Oct 2010 17:17:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:16:09 -0000 I don't believe so. On 10/20/2010 5:02 PM, Worley, Dale R (Dale) wrote: > Are there extensions for the reg (registration) event package to report the Path for the registration, or the reg-id for SIP Outbound? > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From iesg-secretary@ietf.org Wed Oct 20 14:25:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173CB3A68EA; Wed, 20 Oct 2010 14:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxvypbkfL-Ej; Wed, 20 Oct 2010 14:25:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EED03A67FB; Wed, 20 Oct 2010 14:25:08 -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 Message-ID: <20101020212508.11506.19148.idtracker@localhost> Date: Wed, 20 Oct 2010 14:25:08 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:25:09 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-11-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ No IPR declarations were found that appear related to this I-D. From marianne.mohali@orange-ftgroup.com Wed Oct 20 15:03:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6063A6990 for ; Wed, 20 Oct 2010 15:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxndl6quiQI0 for ; Wed, 20 Oct 2010 15:03:19 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id D89363A696B for ; Wed, 20 Oct 2010 15:03:18 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D92456C0006; Thu, 21 Oct 2010 00:05:12 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B91A96C0004; Thu, 21 Oct 2010 00:05:12 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 00:04:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 00:04:47 +0200 Message-ID: In-Reply-To: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actu+E/KdPL46k4IRfieWygqsd+9ugBnVDWA References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> From: To: , X-OriginalArrivalTime: 20 Oct 2010 22:04:52.0145 (UTC) FILETIME=[D20FBA10:01CB70A2] Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:03:23 -0000 Hi James, My answer inline [MM]. =20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de James M. Polk > Envoy=E9 : lundi 18 octobre 2010 21:12 > =C0 : sipcore@ietf.org > Objet : [sipcore] Comments on=20 > draft-mohali-sipcore-reason-call-forwarding-00 >=20 > I have several comments about > = http://www.ietf.org/id/draft-mohali-sipcore-reason-call-forwarding-00.txt= >=20 > Initially, I'm wondering why the Reason header protocol "SIP"=20 > isn't sufficient with a 181 reason code. I don't believe you=20 > account for that possibility (i.e., what different is=20 > supposed to happen when this occurs?). [MM] I'm not sure to get your point but the 181 is ok but not = sufficient. It delivers the information that the call is being forwarded = but not the reason why it has been forwarded. > Then I get to the fact that in your example, you don't=20 > include a Reason header in any of your decoded SIP messages,=20 > so I'm wondering what your example is really showing us=20 > (especially that's different that a "Reason: SIP=3D181" with or=20 > without a text string saying something like "Call is (or has=20 > been) forwarded"). [MM] You can find the Reason header escaped in the R-URI as parameter of = the History-Info header. My point is not focused on the "classic" Reason header, so that there is = no interest to add it. > Then I get back to your 3rd para in the 1st section that=20 > states this as the main possibility for why this extension is=20 > proposed: >=20 > " > This > might help other applications/entities invoked downstream to take > appropriate decisions to avoid undesired service=20 > interactions or to > take advantage of this information (eg. delivering the appropriate > voicemail announcement). > " >=20 > And I ask myself, how are the 8 Reason codes justified in=20 > this sentence? > Then I ask myself about the 8 Reason codes, and see how much=20 > actual information they reveal: >=20 > 1 Unknown/not available > 2 User Busy > 3 No reply > 4 Unconditional > 5 Deflection during alerting > 6 Deflection immediate response > 7 Mobile subscriber not reachable > 8 Not Logged-in >=20 > ...and think, that for >=20 > #1 - you wouldn't include that in a 302 (as in your example),=20 > as an unknown is probably not going to get retargeted, but=20 > rather a 4XX response that doesn't need a reason. [MM] Sorry, I didn't catch your point. > #2 - that's probably telling the caller more that the called=20 > party wants them to know, and doesn't always play nice with a=20 > call-waiting function. [MM] The relevant information is going to the called party (in the = INVITE request), not to the caller and if you want transparency for the = caller (same for call-waiting), just not send upstream the 181 answer. =20 > #3 - why would you include this in the 181 or 302? [MM] I propose to include it in the INVITE. > #4 - again, this seems like more information that the called=20 > probably wants revealed, or this is just a matter of fact=20 > scenario that is normal, so why give this additional information. [MM] Either the original called wants to provide this information = downstream, or the new destination rely on this information to adapt its = behavior before answering the call. > #5 - this is also probably more than the called wants to tell=20 > the callee. [MM] The calle is not necessarily informed of what is going on. > #6 - I can't tell why this is different from an=20 > "Unconditional" reason. [MM] What is different? > #7 - do you really want the callee - every time that number is called > - to know that this is a mobile phone? [MM] non, I DO NOT want the callee to be informed that it is not calling = me at my office but at my home. > #8 - I don't believe you will want to inform the callee that=20 > the person they called is no-logged-in,but rather make this a=20 > Not-available Reason, which is similar to a "Reason:=20 > SIP=3D181", which is available now. [MM]idem >=20 > James >=20 Best Regards, Marianne > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From marianne.mohali@orange-ftgroup.com Wed Oct 20 15:36:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E300C3A6900 for ; Wed, 20 Oct 2010 15:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntRtqLmBwVKG for ; Wed, 20 Oct 2010 15:36:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 7B8143A6927 for ; Wed, 20 Oct 2010 15:35:20 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2A90760002; Thu, 21 Oct 2010 00:40:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A9640760001; Thu, 21 Oct 2010 00:40:40 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 00:36:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 00:36:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9AGQS29A= References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> From: To: , X-OriginalArrivalTime: 20 Oct 2010 22:36:48.0430 (UTC) FILETIME=[48419CE0:01CB70A7] Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:36:30 -0000 Hi Dale, Thanks for your positive review. See my answer in your mail [MM]=20 Best Regards, Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Worley, Dale R (Dale) > Envoy=E9 : lundi 18 octobre 2010 23:12 > =C0 : sipcore@ietf.org > Objet : Re: [sipcore] Comments on=20 > draft-mohali-sipcore-reason-call-forwarding-00 >=20 > Here are some more comments on this draft: >=20 > The term "call diversion" sounds more inclusive to the naive=20 > ear than "call forwarding". If the two terms are used=20 > identically in the draft, it seems better to use only the=20 > former, especially because the abbreviation "CDIV" is being used. [MM] I agree with your statement, with call diversion no ambiguity is = possible. I thought that "call forwarding" was the original term and I = didn't wanted to change the habits but searching a simple acronym for = the protocol value, 'CDIV' sounds good to me.=20 > Section 3 does not give any BNF for CDIV, though it quotes=20 > all of the established BNF for the Reason header. Clearly,=20 > what is intended (but not stated) is: >=20 > protocol =3D/ "CDIV" [MM] What is just after the established BNF is not good? I've used = RFC4411 as a model. > In regard to listing the CDIV cause values, it seems to me=20 > that there should be an existing encoding of call diversion=20 > reasons somewhere within the 3GPP specification, and it would=20 > be more effective for the draft to reference that table=20 > (which would be maintained by 3GPP) rather than defining a=20 > new IANA registry (which would be used almost exclusively by 3GPP). [MM] Right, but the existing CDIV cause values (described in 3GPP) are a = corruption of SIP response codes and brings confusion. It is the initial = reason of this draft. Your idea of mixing both sound good to me: = register a new protocol value "CDIV" but keep the reasons values as in = 3GPP. The problem I see is that reason values are described in RFC4458 = not for the Reason header but for an URI parameter and I'me not sure it = is possible to re-use it. An other way could be to registering cause = values but with the same values as today instead of (1 to 8). Let's = think about it... =20 >=20 > In the example, it appears that the 302 response F3 is=20 > informing the proxy that the call should be sent to=20 > Voicemail. In that case, the > 302 would also carry the Reason header explaing why the=20 > diversion is being done, which the proxy would subsequently=20 > transcribe into the History-Info header of the new INVITE F5: >=20 > F3: 302 Bob -> proxy.example.com >=20 > SIP/2.0 302 Moved Temporarily > Via: SIP/2.0/TCP 192.0.2.4:5060;branch=3Dz9hG4bK-ik80k7g-1 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK-klj79f > From: Alice ; = tag=3D1234567 > To: sip:+15551002@example.com;user=3Dphone;tag=3D765432 > Call-ID: c3x842276298220188511 > Contact: > Reason: CDIV;cause=3D6;text=3D"Deflection immediate response" > CSeq: 1 INVITE > Content-Length: 0 [MM] Right, I will add it in the next version.=20 >=20 > In the example, F5 has two "Reason" headers attached to the=20 > URI at index 1. If you have more than one "header" attached=20 > to a URI, only the first is introduced with "?", the=20 > remainder are introduced with > "&": >=20 > History-Info: %3Bcause=3D302%3Btext=3D"Moved = Temporarily"&Reason=3DCDIV > %3Bcause=3D6%3Btext=3D"Deflection immediate=20 > response">;index=3D1, > ;index=3D1.1;mp=3D1 [MM]Exact, I noted this mistake just after I submitted the draft :-/ = Thanks. >=20 > There are also some difficulties regarding the History-Info=20 > headers in the examle; they don't appear to be consistently=20 > applied to all the INVITEs. [MM] ok, I will review it in detail. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Wed Oct 20 16:08:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEA83A657C for ; Wed, 20 Oct 2010 16:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.197 X-Spam-Level: X-Spam-Status: No, score=-110.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGF47qN1eogH for ; Wed, 20 Oct 2010 16:08:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8ED0C3A67FA for ; Wed, 20 Oct 2010 16:08:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOMTv0xAZnwN/2dsb2JhbAChUHGjI5xIAoVIBIpLgwQ X-IronPort-AV: E=Sophos;i="4.57,357,1283731200"; d="scan'208";a="172934298" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2010 23:09:58 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9KN9wpm021656 for ; Wed, 20 Oct 2010 23:09:58 GMT Message-ID: <4CBF76C6.5060608@cisco.com> Date: Wed, 20 Oct 2010 19:09:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sipcore@ietf.org References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 23:08:26 -0000 [as participant] I think I'm replying to an earlier message, not this one, but the point is the same: IIUC the intent of this work is to define new values for the Reason header, that can be used in a Reason header inserted into a URI in History-Info. And there is *no* expectation that these values would be used in a Reason header in a message that is actually sent. Is that right? If so, it at least sounds like an abuse - that some other mechanism should be used. OTOH, if there is some plausible reason to use this in an actual request then I find it much less troubling. Thanks, Paul On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote: > Hi Dale, > > Thanks for your positive review. > > See my answer in your mail [MM] > > Best Regards, > Marianne > >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] De la part de Worley, Dale R (Dale) >> Envoyé : lundi 18 octobre 2010 23:12 >> À : sipcore@ietf.org >> Objet : Re: [sipcore] Comments on >> draft-mohali-sipcore-reason-call-forwarding-00 >> >> Here are some more comments on this draft: >> >> The term "call diversion" sounds more inclusive to the naive >> ear than "call forwarding". If the two terms are used >> identically in the draft, it seems better to use only the >> former, especially because the abbreviation "CDIV" is being used. > [MM] I agree with your statement, with call diversion no ambiguity is possible. I thought that "call forwarding" was the original term and I didn't wanted to change the habits but searching a simple acronym for the protocol value, 'CDIV' sounds good to me. > >> Section 3 does not give any BNF for CDIV, though it quotes >> all of the established BNF for the Reason header. Clearly, >> what is intended (but not stated) is: >> >> protocol =/ "CDIV" > [MM] What is just after the established BNF is not good? I've used RFC4411 as a model. > >> In regard to listing the CDIV cause values, it seems to me >> that there should be an existing encoding of call diversion >> reasons somewhere within the 3GPP specification, and it would >> be more effective for the draft to reference that table >> (which would be maintained by 3GPP) rather than defining a >> new IANA registry (which would be used almost exclusively by 3GPP). > [MM] Right, but the existing CDIV cause values (described in 3GPP) are a corruption of SIP response codes and brings confusion. It is the initial reason of this draft. Your idea of mixing both sound good to me: register a new protocol value "CDIV" but keep the reasons values as in 3GPP. The problem I see is that reason values are described in RFC4458 not for the Reason header but for an URI parameter and I'me not sure it is possible to re-use it. An other way could be to registering cause values but with the same values as today instead of (1 to 8). Let's think about it... > >> >> In the example, it appears that the 302 response F3 is >> informing the proxy that the call should be sent to >> Voicemail. In that case, the >> 302 would also carry the Reason header explaing why the >> diversion is being done, which the proxy would subsequently >> transcribe into the History-Info header of the new INVITE F5: >> >> F3: 302 Bob -> proxy.example.com >> >> SIP/2.0 302 Moved Temporarily >> Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 >> Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK-klj79f >> From: Alice; tag=1234567 >> To: sip:+15551002@example.com;user=phone;tag=765432 >> Call-ID: c3x842276298220188511 >> Contact: >> Reason: CDIV;cause=6;text="Deflection immediate response" >> CSeq: 1 INVITE >> Content-Length: 0 > > [MM] Right, I will add it in the next version. >> >> In the example, F5 has two "Reason" headers attached to the >> URI at index 1. If you have more than one "header" attached >> to a URI, only the first is introduced with "?", the >> remainder are introduced with >> "&": >> >> History-Info:> %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV >> %3Bcause=6%3Btext="Deflection immediate >> response">;index=1, >> ;index=1.1;mp=1 > [MM]Exact, I noted this mistake just after I submitted the draft :-/ Thanks. >> >> There are also some difficulties regarding the History-Info >> headers in the examle; they don't appear to be consistently >> applied to all the INVITEs. > [MM] ok, I will review it in detail. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Thu Oct 21 10:45:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907F03A6866 for ; Thu, 21 Oct 2010 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dipzxnfzV5O6 for ; Thu, 21 Oct 2010 10:45:36 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 592A93A6A42 for ; Thu, 21 Oct 2010 10:45:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="40138912" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Oct 2010 13:47:11 -0400 X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="528800873" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 13:47:11 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 21 Oct 2010 13:47:10 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 21 Oct 2010 13:44:25 -0400 Thread-Topic: Extensions to the reg event package Thread-Index: AQHLcUf8Sp0tXjsxDUCXkVMqPZyJTA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Extensions to the reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:45:37 -0000 I've noticed that extensions to the reg event package are done by introduci= ng new namespaces. Since extensions usually add only one or two data items= to the package, the result can be an XML document with many namespaces, m= ost of which have a very few element types being used. It seems to me to b= e more natural for extensions to add elements to the original XML schema. = And since the interpreter of the XML document will ignore any elements that= it does not recognize, this practice would be upward-compatible. I suspec= t that there is some formal reason why extending an existing namespace is n= ot done. Dale From pkyzivat@cisco.com Thu Oct 21 10:51:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B63A6A51 for ; Thu, 21 Oct 2010 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAO5vfWyhMQ4 for ; Thu, 21 Oct 2010 10:51:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 01E3F3A6A43 for ; Thu, 21 Oct 2010 10:51:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FANoawExAZnwM/2dsb2JhbACTaY1ycaYwnDCFSgSKTYME X-IronPort-AV: E=Sophos;i="4.58,218,1286150400"; d="scan'208";a="173474788" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2010 17:53:19 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9LHrJdZ022277 for ; Thu, 21 Oct 2010 17:53:19 GMT Message-ID: <4CC07E0F.4030508@cisco.com> Date: Thu, 21 Oct 2010 13:53:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Extensions to the reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:51:45 -0000 My knowledge of XML schemas is limited to cutting and pasting from existing ones, and attempting to follow apparent conventions I see used. (Equivalent to implementing SIP based on wireshark output.) It would be great if somebody who knows better were to write a best practices document for applying XML to SIP stuff. And perhaps there should be some sort of official XML review of drafts. Thanks, Paul On 10/21/2010 1:44 PM, Worley, Dale R (Dale) wrote: > I've noticed that extensions to the reg event package are done by introducing new namespaces. Since extensions usually add only one or two data items to the package, the result can be an XML document with many namespaces, most of which have a very few element types being used. It seems to me to be more natural for extensions to add elements to the original XML schema. And since the interpreter of the XML document will ignore any elements that it does not recognize, this practice would be upward-compatible. I suspect that there is some formal reason why extending an existing namespace is not done. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Thu Oct 21 12:47:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9434F3A681F for ; Thu, 21 Oct 2010 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1io5tv6T5EI for ; Thu, 21 Oct 2010 12:47:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B04543A6802 for ; Thu, 21 Oct 2010 12:47:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="213076733" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Oct 2010 15:48:50 -0400 X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="528841682" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 15:48:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 21 Oct 2010 15:48:49 -0400 From: "Worley, Dale R (Dale)" To: "marianne.mohali@orange-ftgroup.com" , "sipcore@ietf.org" Date: Thu, 21 Oct 2010 15:47:26 -0400 Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9AGQS29AAL9Zyig== Message-ID: References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 19:47:17 -0000 >> From: Dale Worley > From: Marianne Mohali > > Section 3 does not give any BNF for CDIV, though it quotes > > all of the established BNF for the Reason header. Clearly, > > what is intended (but not stated) is: > > > > protocol =3D/ "CDIV" >=20 > [MM] What is just after the established BNF is not good? I've used > RFC4411 as a model. It is good to describe the change in words, but it is better to describe the change in both words and in BNF -- some people find one method easier to understand than the other method. And since the two methods are vulnerable to different kinds of errors, using both makes it easier to discover errors in the definition. As far as I can tell, RFC 4411 contains no BNF at all, so it is not a good model of how to update BNF. > > In regard to listing the CDIV cause values, it seems to me > > that there should be an existing encoding of call diversion > > reasons somewhere within the 3GPP specification, and it would > > be more effective for the draft to reference that table > > (which would be maintained by 3GPP) rather than defining a > > new IANA registry (which would be used almost exclusively by 3GPP). >=20 > [MM] Right, but the existing CDIV cause values (described in 3GPP) > are a corruption of SIP response codes and brings confusion. It is > the initial reason of this draft. Your idea of mixing both sound > good to me: register a new protocol value "CDIV" but keep the > reasons values as in 3GPP. The problem I see is that reason values > are described in RFC4458 not for the Reason header but for an URI > parameter and I'me not sure it is possible to re-use it. An other > way could be to registering cause values but with the same values > as today instead of (1 to 8). Let's think about it... The ideal situation would be if 3GPP had a clear taxonomy of diversion situations, and the CDIV cause values were an encoding of those categories. In particular, we expect CDIV to be generated by a 3GPP system, and so 3GPP would clearly specify the diversion situations which are described by the cause values. It is not ideal if Sipcore defines these cause values, because our understanding of call diversion services probably differs from the understanding of 3GPP. Dale From dworley@avaya.com Thu Oct 21 12:59:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7C43A67DF for ; Thu, 21 Oct 2010 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zed-7XC14Sa for ; Thu, 21 Oct 2010 12:58:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 744623A686A for ; Thu, 21 Oct 2010 12:58:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="243938920" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 16:00:16 -0400 X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="525455065" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Oct 2010 16:00:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 21 Oct 2010 16:00:16 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 21 Oct 2010 16:00:15 -0400 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHLcVqTV/CZQEsmuUSbuxTZrQzVUg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 19:59:00 -0000 I've written draft-worley-service-example to describe a music-on-hold techn= ique which has some advantages over the technique in RFC 5359. (The two ar= e mutually compatible, and both are compatible with almost all SIP UAs.) I= am advancing this as an AD-sponsored RFC. I think I've fixed the last wri= nkles and would like people to review the draft. The -05 changes describe that (as in other third-party situations) it is no= t possible to handle codec numbers exactly correctly in all situations. Bu= t following certain guidelines provides correct behavior in the vast majori= ty of cases. Session Initiation Protocol Service Example -- Music on Hold draft-worley-service-example-05 The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the method of RFC 5359. Thanks, Dale From dworley@avaya.com Thu Oct 21 13:10:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95EE3A683A for ; Thu, 21 Oct 2010 13:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH5hJdX14ULg for ; Thu, 21 Oct 2010 13:10:13 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1752A3A68E1 for ; Thu, 21 Oct 2010 13:10:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="243941204" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 16:11:49 -0400 X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="528849611" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 16:11:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 21 Oct 2010 16:11:48 -0400 From: "Worley, Dale R (Dale)" To: Mary Barnes Date: Thu, 21 Oct 2010 16:08:35 -0400 Thread-Topic: [sipcore] #38: How is the mapping of a GRUU into its UA Contact marked? Thread-Index: ActrEb62RGpdQk9wT4+f8qTM9PnV2wGSf9fZ Message-ID: References: <061.f3e7a20653cdf403663b0bffba4c43b4@tools.ietf.org> <35ECC1DD-6DD6-4103-AC47-A2F9A0D69DAD@ntt-at.com> <4C80EF97.4090703@cisco.com> <2E92FEF2-DCBD-44A9-869B-CCE2BB98278F@ntt-at.com> <54579397-D4DC-4043-8D42-7E6F357E5F6F@ntt-at.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] #38: How is the mapping of a GRUU into its UA Contact marked? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:10:14 -0000 ________________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] So, then it seems you are advocating we add an additional "gr" tag. However, wouldn't the absence of "mp" or "rc" for a GRUU indicate that the GRUU wasn't mapped. I guess it is not harmful to add a unique tag for cases where a GRUU is used, but do you have a use case where this is relevant? ________________________________________ I haven't thought through all the use cases. I've just been assuming that = the goal is for each conversion of one URI into another to describe the nat= ure of the conversion. I expect the case of a GRUU being converted into it= s registered contact to be frequent, and there is the possibility that in s= ome situations GRUUs will be converted into URIs some other way. So it see= ms to me to be reasonable that there is a tag meaning "the mapping of a GRU= U into its registered contact". Perhaps an explanation of the organizing principle of the set of tags would= make clearer why some conversions have tags and others do not. Dale From marianne.mohali@orange-ftgroup.com Thu Oct 21 14:04:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2643A6838 for ; Thu, 21 Oct 2010 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjKixkmxvfTY for ; Thu, 21 Oct 2010 14:04:24 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 769163A63CB for ; Thu, 21 Oct 2010 14:04:24 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 55E10760003; Thu, 21 Oct 2010 23:09:54 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4CAC5760002; Thu, 21 Oct 2010 23:09:54 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 23:05:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 23:05:57 +0200 Message-ID: In-Reply-To: <4CBF76C6.5060608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actwq+5YjC5xG7U9Q2Kpo7SxKjnX9QATOFCg References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> <4CBF76C6.5060608@cisco.com> From: To: , X-OriginalArrivalTime: 21 Oct 2010 21:05:59.0805 (UTC) FILETIME=[C3092AD0:01CB7163] Subject: Re: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 21:04:26 -0000 Hi Paul, My answer in your text [MM] Thanks, Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > Envoy=E9 : jeudi 21 octobre 2010 01:10 > =C0 : sipcore@ietf.org > Objet : Re: [sipcore] Commentson=20 > draft-mohali-sipcore-reason-call-forwarding-00 >=20 > [as participant] >=20 > I think I'm replying to an earlier message, not this one, but=20 > the point is the same: >=20 > IIUC the intent of this work is to define new values for the=20 > Reason header, that can be used in a Reason header inserted=20 > into a URI in History-Info. And there is *no* expectation=20 > that these values would be used in a Reason header in a=20 > message that is actually sent. Is that right? [MM] It is right for the draft in subject (reason for call diversion) = but not for the other draft (if it is what you mean by "an earlier = message") you seem to refer (Reason for applications) where new values = could be added "everywhere". >=20 > If so, it at least sounds like an abuse - that some other=20 > mechanism should be used. =20 >=20 > OTOH, if there is some plausible reason to use this in an=20 > actual request then I find it much less troubling. [MM] Answering only for the draft in subject; it's true that it has a = narrow scope but, at the end, the new values could be present everywhere = the History-Info header is. At this time, I described our need but I = could think about a larger use of those new values (eg. directly in a = SIP error response due to a UA retargeting). >=20 > Thanks, > Paul >=20 > On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote: > > Hi Dale, > > > > Thanks for your positive review. > > > > See my answer in your mail [MM] > > > > Best Regards, > > Marianne > > > >> -----Message d'origine----- > >> De : sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] De la part de Worley,=20 > Dale R (Dale)=20 > >> Envoy=E9 : lundi 18 octobre 2010 23:12 =C0 : sipcore@ietf.org=20 > Objet : Re:=20 > >> [sipcore] Comments on=20 > draft-mohali-sipcore-reason-call-forwarding-00 > >> > >> Here are some more comments on this draft: > >> > >> The term "call diversion" sounds more inclusive to the=20 > naive ear than=20 > >> "call forwarding". If the two terms are used identically in the=20 > >> draft, it seems better to use only the former, especially=20 > because the=20 > >> abbreviation "CDIV" is being used. > > [MM] I agree with your statement, with call diversion no=20 > ambiguity is possible. I thought that "call forwarding" was=20 > the original term and I didn't wanted to change the habits=20 > but searching a simple acronym for the protocol value, 'CDIV'=20 > sounds good to me. > > > >> Section 3 does not give any BNF for CDIV, though it quotes=20 > all of the=20 > >> established BNF for the Reason header. Clearly, what is=20 > intended (but=20 > >> not stated) is: > >> > >> protocol =3D/ "CDIV" > > [MM] What is just after the established BNF is not good?=20 > I've used RFC4411 as a model. > > > >> In regard to listing the CDIV cause values, it seems to me=20 > that there=20 > >> should be an existing encoding of call diversion reasons somewhere=20 > >> within the 3GPP specification, and it would be more=20 > effective for the=20 > >> draft to reference that table (which would be maintained by 3GPP)=20 > >> rather than defining a new IANA registry (which would be=20 > used almost=20 > >> exclusively by 3GPP). > > [MM] Right, but the existing CDIV cause values (described=20 > in 3GPP) are a corruption of SIP response codes and brings=20 > confusion. It is the initial reason of this draft. Your idea=20 > of mixing both sound good to me: register a new protocol=20 > value "CDIV" but keep the reasons values as in 3GPP. The=20 > problem I see is that reason values are described in RFC4458=20 > not for the Reason header but for an URI parameter and I'me=20 > not sure it is possible to re-use it. An other way could be=20 > to registering cause values but with the same values as today=20 > instead of (1 to 8). Let's think about it... > > > >> > >> In the example, it appears that the 302 response F3 is=20 > informing the=20 > >> proxy that the call should be sent to Voicemail. In that case, the > >> 302 would also carry the Reason header explaing why the=20 > diversion is=20 > >> being done, which the proxy would subsequently transcribe into the=20 > >> History-Info header of the new INVITE F5: > >> > >> F3: 302 Bob -> proxy.example.com > >> > >> SIP/2.0 302 Moved Temporarily > >> Via: SIP/2.0/TCP 192.0.2.4:5060;branch=3Dz9hG4bK-ik80k7g-1 > >> Via: SIP/2.0/TCP = proxy.example.com:5060;branch=3Dz9hG4bK-klj79f > >> From: Alice; = tag=3D1234567 > >> To: sip:+15551002@example.com;user=3Dphone;tag=3D765432 > >> Call-ID: c3x842276298220188511 > >> Contact: > >> Reason: CDIV;cause=3D6;text=3D"Deflection immediate response" > >> CSeq: 1 INVITE > >> Content-Length: 0 > > > > [MM] Right, I will add it in the next version. > >> > >> In the example, F5 has two "Reason" headers attached to the URI at=20 > >> index 1. If you have more than one "header" attached to a=20 > URI, only=20 > >> the first is introduced with "?", the remainder are introduced with > >> "&": > >> > >> = History-Info: >> %3Bcause=3D302%3Btext=3D"Moved = Temporarily"&Reason=3DCDIV > >> %3Bcause=3D6%3Btext=3D"Deflection immediate=20 > >> response">;index=3D1, > >> ;index=3D1.1;mp=3D1 > > [MM]Exact, I noted this mistake just after I submitted the=20 > draft :-/ Thanks. > >> > >> There are also some difficulties regarding the=20 > History-Info headers=20 > >> in the examle; they don't appear to be consistently applied to all=20 > >> the INVITEs. > > [MM] ok, I will review it in detail. > >> > >> Dale > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From Martin.Thomson@andrew.com Thu Oct 21 15:24:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FA33A63EC for ; Thu, 21 Oct 2010 15:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r87n5j893cyF for ; Thu, 21 Oct 2010 15:23:59 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 94CA23A63EB for ; Thu, 21 Oct 2010 15:23:59 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:7259 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S36140022Ab0JUWZf (ORCPT ); Thu, 21 Oct 2010 17:25:35 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 21 Oct 2010 17:25:35 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 22 Oct 2010 06:25:33 +0800 From: "Thomson, Martin" To: Paul Kyzivat , "sipcore@ietf.org" Date: Fri, 22 Oct 2010 06:25:31 +0800 Thread-Topic: [sipcore] Extensions to the reg event package Thread-Index: ActxSNxgv9N7FJTlQcWWShNQZ2FghQAJW4oQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EABA6@SISPE7MB1.commscope.com> References: <4CC07E0F.4030508@cisco.com> In-Reply-To: <4CC07E0F.4030508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Extensions to the reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 22:24:00 -0000 PiBPbiAxMC8yMS8yMDEwIDE6NDQgUE0sIFdvcmxleSwgRGFsZSBSIChEYWxlKSB3cm90ZToNCj4g cHJhY3RpY2Ugd291bGQgYmUgdXB3YXJkLWNvbXBhdGlibGUuICBJIHN1c3BlY3QgdGhhdCB0aGVy ZSBpcyBzb21lDQo+IGZvcm1hbCByZWFzb24gd2h5IGV4dGVuZGluZyBhbiBleGlzdGluZyBuYW1l c3BhY2UgaXMgbm90IGRvbmUuDQoNCkluIHByYWN0aWNlLCBhIHByb2Nlc3NvciB0aGF0IHVzZXMg dGhlIG9yaWdpbmFsIHNjaGVtYSBkZWZpbml0aW9ucyBpcyBsaWtlbHkgdG8gcmVqZWN0IGEgZG9j dW1lbnQgdGhhdCB1c2VzIHRoZSBtb2RpZmllZCBzdHJ1Y3R1cmUuDQoNCkZvciBpbnN0YW5jZSwg dGhlIG9yaWdpbmFsIG1pZ2h0IGRlZmluZSAoQSwgQiwgKikgd2hlcmUgKiBpcyBhbiBleHRlbnNp b24gcG9pbnQsIGFuZCB0aGUgZXh0ZW5zaW9uIGRlZmluZXMgKEEsIEIsIEMsICopLiAgQmVjYXVz ZSBpZiB0aGUgd2F5IHRoYXQgKiBpcyBkZWZpbmVkLCBpdCBtZWFucyBhbnl0aGluZyBub3QgaW4g dGhpcyBuYW1lc3BhY2UuICBJZiB0aGUgb3JpZ2luYWwgc2VlcyBDLCB3aGljaCBjbGFpbXMgdG8g YmUgaW4gdGhlIHNhbWUgbmFtZXNwYWNlLCBpdCByZWplY3RzIGl0Lg0KDQpUaGUgc2l6ZSBvZiBu YW1lc3BhY2UgZGVjbGFyYXRpb25zIGlzIGEgY29tbW9uIHNvdXJjZSBvZiBjb21wbGFpbnRzLiAg VGhlIHVzdWFsIHJlc3BvbnNlIGlzIHRvIHBvaW50IGZvbGtzIGF0IEFTTi4xKz9FUi4gIEkgd291 bGRuJ3QgZHJlYW0gb2YgYmVpbmcgc28gcnVkZS4NCg0KLS1NYXJ0aW4NCg== From pkyzivat@cisco.com Thu Oct 21 16:44:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426343A65A5 for ; Thu, 21 Oct 2010 16:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.198 X-Spam-Level: X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAW1w6HX9yHl for ; Thu, 21 Oct 2010 16:44:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 33FB43A6452 for ; Thu, 21 Oct 2010 16:44:52 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJZtwExAZnwN/2dsb2JhbAChX3GjF5wwAoVIBIpNgwQ X-IronPort-AV: E=Sophos;i="4.58,220,1286150400"; d="scan'208";a="173374049" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2010 23:46:28 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9LNkSIO025410; Thu, 21 Oct 2010 23:46:28 GMT Message-ID: <4CC0D0D4.7000802@cisco.com> Date: Thu, 21 Oct 2010 19:46:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> <4CBF76C6.5060608@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 23:44:56 -0000 [as individual] I think maybe you misunderstood me. IMO its already somewhat of an abuse to include a header in URI in the H-I header, in the URI that was captured for inclusion in the H-I. If a UA received a URI in a 3xx response, and it contained a Reason header, then it would make perfect sense to put that into the H-I. But taking an R-URI and grafting on a Reason header before putting it into H-I seems at best a hack. But maybe that is water over the dam. The hack is compounded if the reason in the Reason header is never intended to be used in a Reason header in a request that is sent - rather that it is only intended to be used in H-I in an already abusive way. BUT, I expect in fact that these reason values *could* actually be useful in requests. If so, you would do yourself a favor to point that out in the draft. In your example 4, as Dale already pointed out, the Reason header doesn't appear in INVITE F5. But it *could*, and it would make sense that it should. That tells the voicemail system *directly* the reason why it was contacted. It wouldn't necessarily need to consult the H-I in an attempt to figure that out. If that is *not* useful - if such values should be ignored in favor of analyzing the H-I entries - then I assert that Reason should not be used for this. Rather H-I should use its own header parameters to convey this sort of information. Thanks, Paul On 10/21/2010 5:05 PM, marianne.mohali@orange-ftgroup.com wrote: > Hi Paul, > > My answer in your text [MM] > > Thanks, > Marianne >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat >> Envoyé : jeudi 21 octobre 2010 01:10 >> À : sipcore@ietf.org >> Objet : Re: [sipcore] Commentson >> draft-mohali-sipcore-reason-call-forwarding-00 >> >> [as participant] >> >> I think I'm replying to an earlier message, not this one, but >> the point is the same: >> >> IIUC the intent of this work is to define new values for the >> Reason header, that can be used in a Reason header inserted >> into a URI in History-Info. And there is *no* expectation >> that these values would be used in a Reason header in a >> message that is actually sent. Is that right? > [MM] It is right for the draft in subject (reason for call diversion) but not for the other draft (if it is what you mean by "an earlier message") you seem to refer (Reason for applications) where new values could be added "everywhere". >> >> If so, it at least sounds like an abuse - that some other >> mechanism should be used. >> >> OTOH, if there is some plausible reason to use this in an >> actual request then I find it much less troubling. > [MM] Answering only for the draft in subject; it's true that it has a narrow scope but, at the end, the new values could be present everywhere the History-Info header is. At this time, I described our need but I could think about a larger use of those new values (eg. directly in a SIP error response due to a UA retargeting). >> >> Thanks, >> Paul >> >> On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote: >>> Hi Dale, >>> >>> Thanks for your positive review. >>> >>> See my answer in your mail [MM] >>> >>> Best Regards, >>> Marianne >>> >>>> -----Message d'origine----- >>>> De : sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] De la part de Worley, >> Dale R (Dale) >>>> Envoyé : lundi 18 octobre 2010 23:12 À : sipcore@ietf.org >> Objet : Re: >>>> [sipcore] Comments on >> draft-mohali-sipcore-reason-call-forwarding-00 >>>> >>>> Here are some more comments on this draft: >>>> >>>> The term "call diversion" sounds more inclusive to the >> naive ear than >>>> "call forwarding". If the two terms are used identically in the >>>> draft, it seems better to use only the former, especially >> because the >>>> abbreviation "CDIV" is being used. >>> [MM] I agree with your statement, with call diversion no >> ambiguity is possible. I thought that "call forwarding" was >> the original term and I didn't wanted to change the habits >> but searching a simple acronym for the protocol value, 'CDIV' >> sounds good to me. >>> >>>> Section 3 does not give any BNF for CDIV, though it quotes >> all of the >>>> established BNF for the Reason header. Clearly, what is >> intended (but >>>> not stated) is: >>>> >>>> protocol =/ "CDIV" >>> [MM] What is just after the established BNF is not good? >> I've used RFC4411 as a model. >>> >>>> In regard to listing the CDIV cause values, it seems to me >> that there >>>> should be an existing encoding of call diversion reasons somewhere >>>> within the 3GPP specification, and it would be more >> effective for the >>>> draft to reference that table (which would be maintained by 3GPP) >>>> rather than defining a new IANA registry (which would be >> used almost >>>> exclusively by 3GPP). >>> [MM] Right, but the existing CDIV cause values (described >> in 3GPP) are a corruption of SIP response codes and brings >> confusion. It is the initial reason of this draft. Your idea >> of mixing both sound good to me: register a new protocol >> value "CDIV" but keep the reasons values as in 3GPP. The >> problem I see is that reason values are described in RFC4458 >> not for the Reason header but for an URI parameter and I'me >> not sure it is possible to re-use it. An other way could be >> to registering cause values but with the same values as today >> instead of (1 to 8). Let's think about it... >>> >>>> >>>> In the example, it appears that the 302 response F3 is >> informing the >>>> proxy that the call should be sent to Voicemail. In that case, the >>>> 302 would also carry the Reason header explaing why the >> diversion is >>>> being done, which the proxy would subsequently transcribe into the >>>> History-Info header of the new INVITE F5: >>>> >>>> F3: 302 Bob -> proxy.example.com >>>> >>>> SIP/2.0 302 Moved Temporarily >>>> Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 >>>> Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK-klj79f >>>> From: Alice; tag=1234567 >>>> To: sip:+15551002@example.com;user=phone;tag=765432 >>>> Call-ID: c3x842276298220188511 >>>> Contact: >>>> Reason: CDIV;cause=6;text="Deflection immediate response" >>>> CSeq: 1 INVITE >>>> Content-Length: 0 >>> >>> [MM] Right, I will add it in the next version. >>>> >>>> In the example, F5 has two "Reason" headers attached to the URI at >>>> index 1. If you have more than one "header" attached to a >> URI, only >>>> the first is introduced with "?", the remainder are introduced with >>>> "&": >>>> >>>> History-Info:>>> %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV >>>> %3Bcause=6%3Btext="Deflection immediate >>>> response">;index=1, >>>> ;index=1.1;mp=1 >>> [MM]Exact, I noted this mistake just after I submitted the >> draft :-/ Thanks. >>>> >>>> There are also some difficulties regarding the >> History-Info headers >>>> in the examle; they don't appear to be consistently applied to all >>>> the INVITEs. >>> [MM] ok, I will review it in detail. >>>> >>>> Dale >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From pkyzivat@cisco.com Thu Oct 21 17:20:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B4D3A67D7 for ; Thu, 21 Oct 2010 17:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.497 X-Spam-Level: X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liWB+YShKFbG for ; Thu, 21 Oct 2010 17:20:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0463D3A67D0 for ; Thu, 21 Oct 2010 17:20:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEN2wExAZnwN/2dsb2JhbAChXnGjApwyhUoEik2DBA X-IronPort-AV: E=Sophos;i="4.58,220,1286150400"; d="scan'208";a="173588347" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2010 00:21:51 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9M0LpR6002311; Fri, 22 Oct 2010 00:21:51 GMT Message-ID: <4CC0D91F.7060304@cisco.com> Date: Thu, 21 Oct 2010 20:21:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dale Worley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 00:20:16 -0000 [as individual] Dale, This is quite nice. You have covered a lot of obscure cases. Obviously the constraint about reusing payload numbers is problematic. I think we should consider the possibility of relaxing it, though I don't know if we can get away with that after the fact or not. ISTM that the fundamental reason for such a constraint is transient. When you have an existing session and then modify it, the change in the signaling and the change in the media packets do not happen synchronously. So when you make the offer you must be ready to receive media based on the new offer while you are still receiving media on the old offer. Similarly for sending. If the codec associated with a payload type is changed then when a packet arrives it will be impossible to know which codec applies for it. So, for a particular o/a exchange I think this rule must hold. But once that is in effect, and we know all media according to the old o/a has cleared the system, those old payload numbers no longer need be reserved. In reasonable cases, things should stabilize from one o/a before another o/a begins. (Though we can probably contrive a case where this is not so.) Would such a change be sufficient to simplify the problems you have been dealing with in this draft? Thanks, Paul On 10/21/2010 4:00 PM, Worley, Dale R (Dale) wrote: > I've written draft-worley-service-example to describe a music-on-hold technique which has some advantages over the technique in RFC 5359. (The two are mutually compatible, and both are compatible with almost all SIP UAs.) I am advancing this as an AD-sponsored RFC. I think I've fixed the last wrinkles and would like people to review the draft. > > The -05 changes describe that (as in other third-party situations) it is not possible to handle codec numbers exactly correctly in all situations. But following certain guidelines provides correct behavior in the vast majority of cases. > > Session Initiation Protocol Service Example -- Music on Hold > draft-worley-service-example-05 > > The "music on hold" feature is one of the most desired features of > telephone systems in the business environment. "Music on hold" is > where, when one party to a call has the call "on hold", that party's > telephone provides an audio stream (often music) to be heard by the > other party. Architectural features of SIP make it difficult to > implement music-on-hold in a way that is fully compliant with the > standards. The implementation of music-on-hold described in this > document is fully effective and standards-compliant, and has a number > of advantages over the methods previously documented. In particular, > it is less likely to produce peculiar user interface effects and more > likely to work in systems which perform authentication than the > method of RFC 5359. > > Thanks, > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Oct 22 04:35:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9853A680D for ; Fri, 22 Oct 2010 04:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2i5vcefZHQd for ; Fri, 22 Oct 2010 04:35:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 58CED3A686A for ; Fri, 22 Oct 2010 04:35:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-12-4cc177793141 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.FB.13412.A7771CC4; Fri, 22 Oct 2010 13:37:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 22 Oct 2010 13:37:29 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 22 Oct 2010 13:37:28 +0200 Thread-Topic: Proxy feature tag use-case: capability to use Path header field information in both directions Thread-Index: Actx3YGO+cBNKGQcR3CDz5aaOmQMSA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502E8A90B@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_7F2072F1E0DE894DA4B517B93C6A058502E8A90BESESSCMS0356eem_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 11:35:55 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058502E8A90BESESSCMS0356eem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, PROBLEM: ----------------- Many of you may remember the discussions we've had every now and then regar= ding issues of building a Service-Route. The RFC recommends against intermediaries inserting themselves in the Servi= ce-Route of the REGISTER response. In addition, the registrar cannot assume that the Path header(s) received i= n the REGISTER request can be used by the registrar to build the Service-Ro= ute, so often the only instane in the Service-Route is the registrar itself= . In addition, the UA cannot assume that the Path header(s) received in the R= EGISTER response can be used to build a route for initial dialog or stand-a= lone SIP requests. The reasons is that Path by definition only provides rou= ting information for the registrar-to-UA direction. So, today, if initial dialog or stand-alone SIP requests are to be routed v= ia specific intermediaries, it has to be done by configuration, since neith= er the Service-Route or Path can be used to build the route. POSSIBLE SOLUTION: ----------------------------------- Some years ago Jonathan wrote a draft (http://tools.ietf.org/id/draft-rosen= berg-sip-route-construct-02.txt), which made it possible to indicate that a= Path header value can be used for routing in both directions, ie the regis= trar could insert it in the Service-Route, or the UA can use it to build a = route. At one point I agreed to take over the work with the draft, but for various= reasons it never moved forward. Recently, there has been some discussions that this would be another use-ca= se for draft-holmberg-sipcore-proxy-features: proxies could add a feature t= ag to Path, indicating a capability to receive request from both directions= using the Path information. The Path could then be used to genereate Servi= ce-Route or request route. Comments? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058502E8A90BESESSCMS0356eem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
PROBLEM:
-----------------
 
Many of you may remember the discussions we've had ev= ery now and then regarding issues of building a Service-Route.
 
The RFC recommends against intermediaries inserting t= hemselves in the Service-Route of the REGISTER response.
 
In addition, the registrar cannot assume that the Pat= h header(s) received in the REGISTER request can be used by the registrar t= o build the Service-Route, so often the only instane in the Service-Route i= s the registrar itself.
 
In addition, the UA cannot assume that the Path heade= r(s) received in the REGISTER response can be used to build a route for ini= tial dialog or stand-alone SIP requests. The reasons is that Path by defini= tion only provides routing information for the registrar-to-UA direction.
 
So, today, if initial dialog or stand-alone SIP reque= sts are to be routed via specific intermediaries, it has to be done by conf= iguration, since neither the Service-Route or Path can be used to build the= route.
 
 
POSSIBLE SOLUTION:
-----------------------------------
 
Some years ago Jonathan wrote a draft (http://tools.ietf.org/id/draft-rosenberg-sip-route-constr= uct-02.txt), which made it possible to indicate that a Path header value can be used for routing in= both directions, ie the registrar could insert it in the Service-Route, or= the UA can use it to build a route.
 
At one point I agreed to take over the work with the = draft, but for various reasons it never moved forward.
 
Recently, there has been some discussions that this w= ould be another use-case for draft-holmberg-sipcore-proxy-features: proxies= could add a feature tag to Path, indicating a capability to receive reques= t from both directions using the Path information. The Path could then be used to genereate Service-Route or requ= est route.
 
Comments?
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058502E8A90BESESSCMS0356eem_-- From marianne.mohali@orange-ftgroup.com Fri Oct 22 08:59:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544B23A6840 for ; Fri, 22 Oct 2010 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfq5qDf6ri6R for ; Fri, 22 Oct 2010 08:58:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 922F23A67B1 for ; Fri, 22 Oct 2010 08:58:58 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF773FC4021; Fri, 22 Oct 2010 17:55:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 53CFDFCC007; Fri, 22 Oct 2010 17:45:05 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 17:44:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 17:44:56 +0200 Message-ID: In-Reply-To: <4CC0D0D4.7000802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actxei98p5O+9lQSRb+7kZ1tdznhnwAOzsDw References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> <4CBF76C6.5060608@cisco.com> <4CC0D0D4.7000802@cisco.com> From: To: X-OriginalArrivalTime: 22 Oct 2010 15:44:57.0085 (UTC) FILETIME=[13F91AD0:01CB7200] Cc: sipcore@ietf.org Subject: Re: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 15:59:00 -0000 Ok, maybe I should show a *normal* case where the Reason header is = included in the UA response and then copied in the H-I. And also a = situation where thoses values can be used directly in request (I don't = know how). However, the voicemail case you mention is possible only for the last = retargeting reason (the call could have been diverted several times). It = could be usefull to store the previous reasons in the H-I for the case = where a unified voicemail wants to join the firt diverting user box.=20 You said also that it wouldn't need to consult the H-I but I think it = would be necessary to know the diverting user identity to find he's = mailbox (in H-I). Indeed, a dedicated H-I parameter could match the need but I already = done this proposal unsucessfully and this solution would be quite = different from the present. Marianne > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : vendredi 22 octobre 2010 01:46 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org > Objet : Re: [sipcore] Commentson=20 > draft-mohali-sipcore-reason-call-forwarding-00 >=20 > [as individual] >=20 > I think maybe you misunderstood me. >=20 > IMO its already somewhat of an abuse to include a header in=20 > URI in the H-I header, in the URI that was captured for=20 > inclusion in the H-I. If a UA received a URI in a 3xx=20 > response, and it contained a Reason header, then it would=20 > make perfect sense to put that into the H-I. But taking an=20 > R-URI and grafting on a Reason header before putting it into=20 > H-I seems at best a hack. But maybe that is water over the dam. >=20 > The hack is compounded if the reason in the Reason header is=20 > never intended to be used in a Reason header in a request=20 > that is sent - rather that it is only intended to be used in=20 > H-I in an already abusive way. >=20 > BUT, I expect in fact that these reason values *could*=20 > actually be useful in requests. If so, you would do yourself=20 > a favor to point that out in the draft. In your example 4, as=20 > Dale already pointed out, the Reason header doesn't appear in=20 > INVITE F5. But it *could*, and it would make sense that it=20 > should. That tells the voicemail system *directly* the reason=20 > why it was contacted. It wouldn't necessarily need to consult=20 > the H-I in an attempt to figure that out. >=20 > If that is *not* useful - if such values should be ignored in=20 > favor of analyzing the H-I entries - then I assert that=20 > Reason should not be used for this. Rather H-I should use its=20 > own header parameters to convey this sort of information. >=20 > Thanks, > Paul >=20 >=20 > On 10/21/2010 5:05 PM, marianne.mohali@orange-ftgroup.com wrote: > > Hi Paul, > > > > My answer in your text [MM] > > > > Thanks, > > Marianne > >> -----Message d'origine----- > >> De : sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] De la part de Paul=20 > Kyzivat Envoy=E9 :=20 > >> jeudi 21 octobre 2010 01:10 =C0 : sipcore@ietf.org Objet : Re:=20 > >> [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 > >> > >> [as participant] > >> > >> I think I'm replying to an earlier message, not this one, but the=20 > >> point is the same: > >> > >> IIUC the intent of this work is to define new values for=20 > the Reason=20 > >> header, that can be used in a Reason header inserted into a URI in=20 > >> History-Info. And there is *no* expectation that these=20 > values would=20 > >> be used in a Reason header in a message that is actually sent. Is=20 > >> that right? > > [MM] It is right for the draft in subject (reason for call=20 > diversion) but not for the other draft (if it is what you=20 > mean by "an earlier message") you seem to refer (Reason for=20 > applications) where new values could be added "everywhere". > >> > >> If so, it at least sounds like an abuse - that some other=20 > mechanism=20 > >> should be used. > >> > >> OTOH, if there is some plausible reason to use this in an actual=20 > >> request then I find it much less troubling. > > [MM] Answering only for the draft in subject; it's true=20 > that it has a narrow scope but, at the end, the new values=20 > could be present everywhere the History-Info header is. At=20 > this time, I described our need but I could think about a=20 > larger use of those new values (eg. directly in a SIP error=20 > response due to a UA retargeting). > >> > >> Thanks, > >> Paul > >> > >> On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote: > >>> Hi Dale, > >>> > >>> Thanks for your positive review. > >>> > >>> See my answer in your mail [MM] > >>> > >>> Best Regards, > >>> Marianne > >>> > >>>> -----Message d'origine----- > >>>> De : sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] De la part de Worley, > >> Dale R (Dale) > >>>> Envoy=E9 : lundi 18 octobre 2010 23:12 =C0 : sipcore@ietf.org > >> Objet : Re: > >>>> [sipcore] Comments on > >> draft-mohali-sipcore-reason-call-forwarding-00 > >>>> > >>>> Here are some more comments on this draft: > >>>> > >>>> The term "call diversion" sounds more inclusive to the > >> naive ear than > >>>> "call forwarding". If the two terms are used identically in the=20 > >>>> draft, it seems better to use only the former, especially > >> because the > >>>> abbreviation "CDIV" is being used. > >>> [MM] I agree with your statement, with call diversion no > >> ambiguity is possible. I thought that "call forwarding" was the=20 > >> original term and I didn't wanted to change the habits but=20 > searching=20 > >> a simple acronym for the protocol value, 'CDIV' > >> sounds good to me. > >>> > >>>> Section 3 does not give any BNF for CDIV, though it quotes > >> all of the > >>>> established BNF for the Reason header. Clearly, what is > >> intended (but > >>>> not stated) is: > >>>> > >>>> protocol =3D/ "CDIV" > >>> [MM] What is just after the established BNF is not good? > >> I've used RFC4411 as a model. > >>> > >>>> In regard to listing the CDIV cause values, it seems to me > >> that there > >>>> should be an existing encoding of call diversion reasons=20 > somewhere=20 > >>>> within the 3GPP specification, and it would be more > >> effective for the > >>>> draft to reference that table (which would be maintained=20 > by 3GPP)=20 > >>>> rather than defining a new IANA registry (which would be > >> used almost > >>>> exclusively by 3GPP). > >>> [MM] Right, but the existing CDIV cause values (described > >> in 3GPP) are a corruption of SIP response codes and brings=20 > confusion.=20 > >> It is the initial reason of this draft. Your idea of mixing both=20 > >> sound good to me: register a new protocol value "CDIV" but=20 > keep the=20 > >> reasons values as in 3GPP. The problem I see is that reason values=20 > >> are described in RFC4458 not for the Reason header but for an URI=20 > >> parameter and I'me not sure it is possible to re-use it.=20 > An other way=20 > >> could be to registering cause values but with the same values as=20 > >> today instead of (1 to 8). Let's think about it... > >>> > >>>> > >>>> In the example, it appears that the 302 response F3 is > >> informing the > >>>> proxy that the call should be sent to Voicemail. In=20 > that case, the > >>>> 302 would also carry the Reason header explaing why the > >> diversion is > >>>> being done, which the proxy would subsequently=20 > transcribe into the=20 > >>>> History-Info header of the new INVITE F5: > >>>> > >>>> F3: 302 Bob -> proxy.example.com > >>>> > >>>> SIP/2.0 302 Moved Temporarily > >>>> Via: SIP/2.0/TCP 192.0.2.4:5060;branch=3Dz9hG4bK-ik80k7g-1 > >>>> Via: SIP/2.0/TCP=20 > proxy.example.com:5060;branch=3Dz9hG4bK-klj79f > >>>> From: Alice;=20 > tag=3D1234567 > >>>> To: sip:+15551002@example.com;user=3Dphone;tag=3D765432 > >>>> Call-ID: c3x842276298220188511 > >>>> Contact: > >>>> Reason: CDIV;cause=3D6;text=3D"Deflection immediate = response" > >>>> CSeq: 1 INVITE > >>>> Content-Length: 0 > >>> > >>> [MM] Right, I will add it in the next version. > >>>> > >>>> In the example, F5 has two "Reason" headers attached to=20 > the URI at=20 > >>>> index 1. If you have more than one "header" attached to a > >> URI, only > >>>> the first is introduced with "?", the remainder are=20 > introduced with > >>>> "&": > >>>> > >>>> =20 > History-Info: >>>> %3Bcause=3D302%3Btext=3D"Moved=20 > Temporarily"&Reason=3DCDIV > >>>> %3Bcause=3D6%3Btext=3D"Deflection immediate=20 > >>>> response">;index=3D1, > >>>> ;index=3D1.1;mp=3D1 > >>> [MM]Exact, I noted this mistake just after I submitted the > >> draft :-/ Thanks. > >>>> > >>>> There are also some difficulties regarding the > >> History-Info headers > >>>> in the examle; they don't appear to be consistently=20 > applied to all=20 > >>>> the INVITEs. > >>> [MM] ok, I will review it in detail. > >>>> > >>>> Dale > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > >=20 From mary.ietf.barnes@gmail.com Fri Oct 22 11:53:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D723A682B for ; Fri, 22 Oct 2010 11:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUDOghoQSXVH for ; Fri, 22 Oct 2010 11:52:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 794173A6822 for ; Fri, 22 Oct 2010 11:52:59 -0700 (PDT) Received: by yxp4 with SMTP id 4so1004815yxp.31 for ; Fri, 22 Oct 2010 11:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iqYYmuRyrSYqz62/bHWfE38CY4/xj982acMlZE37pRo=; b=ahg2qjeYRRbCXaN3IR+k7VhWZVQfemBELeGkJoUEcopCpQQnUIfNeqqgxGPdCbslOS tURt96Cm1tLTX+o47zL1W9AHDPbT3tRzbQX48QQ1m6TN3LXIFBnZIKazmGn2Eba8nICW bV59gHMs0wrnvte0+RHwEYFGzoFw8SrkZs35U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A1XKlbrGhe07n5pYW+fXpl1m9eMAaBXjdXZV6Jrn6tuxhjH8v6QDLSkV6etkSTscpq GzTlYHDhVy6Gs0pWLH6AALN8Xb9BWC3qi6Bck+9Iz8qq2vB+yH8l16065AeyAioTvD/T cpT7FK8XVH5MACgmE/BXnyZPd6xChxY5rDRgY= MIME-Version: 1.0 Received: by 10.150.185.20 with SMTP id i20mr6753679ybf.371.1287773676360; Fri, 22 Oct 2010 11:54:36 -0700 (PDT) Received: by 10.236.110.51 with HTTP; Fri, 22 Oct 2010 11:54:36 -0700 (PDT) In-Reply-To: References: <061.f3e7a20653cdf403663b0bffba4c43b4@tools.ietf.org> <35ECC1DD-6DD6-4103-AC47-A2F9A0D69DAD@ntt-at.com> <4C80EF97.4090703@cisco.com> <2E92FEF2-DCBD-44A9-869B-CCE2BB98278F@ntt-at.com> <54579397-D4DC-4043-8D42-7E6F357E5F6F@ntt-at.com> Date: Fri, 22 Oct 2010 13:54:36 -0500 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] #38: How is the mapping of a GRUU into its UA Contact marked? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:53:00 -0000 Hi Dale, Responses inline below [MB]. Mary. On Thu, Oct 21, 2010 at 3:08 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Mary Barnes [mary.ietf.barnes@gmail.com] > > So, then it seems you are advocating we add an additional "gr" tag. > However, wouldn't the absence of "mp" or "rc" for a GRUU indicate that > the GRUU wasn't mapped. =A0I guess it is not harmful to add a unique tag > for cases where a GRUU is used, but do you have a use case where this > is relevant? > ________________________________________ > > I haven't thought through all the use cases. =A0I've just been assuming t= hat the goal is for each conversion of one URI into another to describe the= nature of the conversion. =A0I expect the case of a GRUU being converted i= nto its registered contact to be frequent, and there is the possibility tha= t in some situations GRUUs will be converted into URIs some other way. =A0S= o it seems to me to be reasonable that there is a tag meaning "the mapping = of a GRUU into its registered contact". > [MB] The question Shida raised earlier was why would you need this tag when you have the "gr" tag in the URI and you have the "rc" tag in the History-Info entry. The question to me is to whom does it matter that it was a GRUU that was mapped to a registered contact. There is a gruu use case in the call flows describing this. [/MB] > Perhaps an explanation of the organizing principle of the set of tags wou= ld make clearer why some conversions have tags and others do not. [MB] That might help. The reason there are just the two tags was because those were the ones that came out of the use cases. We originally had all entries tagged and the pushback was that the other tags were not necessary (at least for the use cases envisioned). For example, there was a "noop" for next hop forwarding, a "predetermined" for things like the Request-URI containing a maddr, strict routing, etc. and the "rc"s were divided into two categories - normal registered contacts and registered aliases. In the end, it was only the "rc" and "mp" that seemed to be relevant for most applications, although one could debate that the others might help with debug. [/MB] > > Dale > From mary.ietf.barnes@gmail.com Fri Oct 22 11:57:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FD73A68AD for ; Fri, 22 Oct 2010 11:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klJTSOdNQ2S8 for ; Fri, 22 Oct 2010 11:57:20 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DF7863A682B for ; Fri, 22 Oct 2010 11:57:19 -0700 (PDT) Received: by gwb17 with SMTP id 17so917988gwb.31 for ; Fri, 22 Oct 2010 11:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rXJ4VGbhXsw4ZwfA0tnoSEtyS9bTFZUHrbzd7Z1W2ng=; b=HyEnGBNQwL8cBAtIdjDw1JV+gKCC2cTKSTMdMEqtEbl47ZD7BylbZF914/ATlrrwI+ r+4KpvMejIx7ugV5wjuJiaQI7D/Xv2Gtq5Gai7FOM6InC7KHhOO7IDcJziVktw1nrVcJ njAURCqmPMzwOh77laNjLUgIJ660QEyc50du8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TxBKEicYC24EZhzYLjvsMrkSJfrWyIkcOskqC8I+dnJ1+s8WzuOwbrDqJdHKALzyrh 9Ku9IBe5GRT4+u+ST/MCTy/gJppMclWc6KdQLxH/R7uGCrCHAnr7L/Rrq7qsAHpSZchU 8Q89UUk9mazm0F1+41FXMTiDjSeUwALaoolrE= MIME-Version: 1.0 Received: by 10.151.85.18 with SMTP id n18mr6835645ybl.1.1287773938059; Fri, 22 Oct 2010 11:58:58 -0700 (PDT) Received: by 10.236.110.51 with HTTP; Fri, 22 Oct 2010 11:58:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Oct 2010 13:58:58 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: worley@alum.mit.edu Subject: Re: [sipcore] #19/#20: Show Cancel messaging/Handling canceled forks X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:57:21 -0000 In reconsidering this issue, I'm now of a mind that we should just not include the entry for the canceled fork in the response since it really doesn't add any value since it's undetermined at the time the response is sent what really happened to that leg. This is only in the case of parallel forking, which is always an anomaly. Unless someone strongly disagrees, I'll update the text appropriately (including bullet 6 in the indexing section). Mary. On Tue, Oct 12, 2010 at 5:37 PM, Mary Barnes w= rote: > Note, I've merged these two issues into a single response since they > are relevant to the same text/call flow. =A0I have corrected #19 such > that the 200 OK is sent before the Cancel. > > As you note, there is a general problem here in terms of how the 487 > is reported. =A0We cannot change basic SIP protocol processing. > However, the hi-entry received in the response at the UAC is > misleading =A0if we don't include a reason. =A0So, I think we have to do > the "pre-emptive" addition of the reason. > > The parallel forking scenario also has the anomaly that the indices > don't necessarily reflect (obviously) the sequence of events per se. > But, I don't know a way around that one either and I think that's > another parallel forking is evil side effect that we'll have to live > with. =A0The only hint the UAC would have that there was parallel > forking is that the last hi-entry has a reason and the one prior > doesn't. =A0However, I think it would be better if the last entry is the > successful one and is more reflective of where the INVITE was > successfully received. =A0This means that some indices might be out or > order, but I do not think that should break anything since they are > from the same branch (i.e., the tree looks the same). > > Thanks, > Mary. > > On Tue, Aug 31, 2010 at 12:26 PM, sipcore issue tracker > wrote: >> #20: Handling canceled forks >> ---------------------------------+--------------------------------------= ---- >> =A0Reporter: =A0worley@=85 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: >> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status:= =A0new >> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: = =A0milestone1 >> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: >> =A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0 =A0Keywords: >> ---------------------------------+--------------------------------------= ---- >> =A0Concerning this part of section 3 figure 1: >> >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 200 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|<---------------| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1 >> =A0 =A0| History-Info: ;index=3D1.1 >> =A0 =A0| History-Info: ;index=3D1.1.1;rc >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|<=3D=3D=3DProxy cancels INVITE=3D=3D>| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0487 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|<--------------------------| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 200 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0| >> =A0 =A0| History-Info: ;index=3D1 >> =A0 =A0| History-Info: ;index=3D1.1 >> =A0 =A0| History-Info: ;index=3D1.1.1;rc >> =A0 =A0| History-Info: ;\ >> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 index=3D1.1.2;rc >> >> =A0In principle, the second 200 response shown above should be sent >> =A0immediately after the first 200 response shown above was received fro= m >> =A0downstream. =A0But the received 200 response triggered "Proxy cancels >> =A0INVITE", which led to Bob@phone to send the 487 response which is >> =A0documented in the 4th History-Info value in the sent 200, which shoul= d >> =A0have been sent before the 487 was received. >> >> =A0One alternative is to put that 4th value in the upstream 200 >> =A0"preemptively", that is, documenting that the proxy *intends* to canc= el >> =A0the INVITE to Bob@phone. =A0But the proxy does not know that it will = be >> =A0successful in canceling the INVITE and receiving a 487 response -- th= ere >> =A0might already be a 200 en route from Bob@phone. =A0So the upstream 20= 0 can't >> =A0be sent until the 487 is received. >> >> =A0Another alternative is to delay sending the upstream 200 until after = all >> =A0parallel forks have been disposed of. =A0But this would be complex an= d might >> =A0take a significant amount of time. >> >> -- >> Ticket URL: >> sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From rjsparks@nostrum.com Fri Oct 22 13:02:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B1A3A694E; Fri, 22 Oct 2010 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfmj7PMvoUeO; Fri, 22 Oct 2010 13:02:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7D1F93A6818; Fri, 22 Oct 2010 13:02:15 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9MK3K5s061538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Oct 2010 15:03:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-101-232987719 Date: Fri, 22 Oct 2010 15:03:52 -0500 Message-Id: To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: rai@ietf.org Subject: [sipcore] SIPit registration closes in one week X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:02:17 -0000 --Apple-Mail-101-232987719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SIPit registration closes next Friday Oct 29. The event will take place November 15th through 19th in Taipei, Taiwan. This SIPit is being hosted by ETSI's Centre for Testing and = Interoperability (CTI) in cooperation with ITRI, Industrial Technology = Research Institute. More details are available at = If you plan to attend but have not yet registered, please do so today! See you in Taipei! RjS= --Apple-Mail-101-232987719 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii SIPit registration closes next Friday Oct 29.

The event will take place November 15th through 19th in Taipei, Taiwan.
This SIPit is being hosted by ETSI's Centre for Testing and Interoperability (CTI) in cooperation with ITRI, Industrial Technology Research Institute.
More details are available at <http://www.etsi.org/plugtests/SIPit27/SIPit27.htm>

If you plan to attend but have not yet registered, please do so today!

See you in Taipei!

RjS
--Apple-Mail-101-232987719-- From dean.willis@softarmor.com Fri Oct 22 13:52:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADF63A68BA for ; Fri, 22 Oct 2010 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uCDZ0-qCJor for ; Fri, 22 Oct 2010 13:52:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 42F9A3A6805 for ; Fri, 22 Oct 2010 13:52:18 -0700 (PDT) Received: by yxp4 with SMTP id 4so1106672yxp.31 for ; Fri, 22 Oct 2010 13:53:56 -0700 (PDT) Received: by 10.150.211.2 with SMTP id j2mr6944504ybg.201.1287780835184; Fri, 22 Oct 2010 13:53:55 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id j27sm2724797yha.30.2010.10.22.13.53.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 13:53:53 -0700 (PDT) Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4CA0AE61.7060003@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Oct 2010 15:53:51 -0500 References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:52:19 -0000 On Sep 27, 2010, at 9:46 AM, Paul Kyzivat wrote: > [as chair] > > To all sipcore participants: > > Christer has been looking for a way to accomplish a particular > function that 3gpp wants. This proposal seems a plausible way to do > that. But it is of necessity defining a more general mechanism. > > I'd really appreciate comments from others (including people in no > way involved with 3gpp) regarding this mechanism. For instance, do > you consider the semantics to be well defined? Do you see need for > more about security implications? > I think it's important to note that we're talking about a way of advertising "option tags" -- the same option tags that theoretically get added to the "Supported" headers in lots of messages, and that the "Options" request was particularly designed to collect. Specifically, Christer has identified a use case where it is important for other nodes to understand the options supported by a proxy in the registration path, when that proxy is reasonably expected to be on the request path for future requests using that registration. If, OTOH, we're really talking "feature tags" that refer to vendor- tree specific feature identification -- well, then we're back to the old service-identifier problem. -- Dean From dean.willis@softarmor.com Fri Oct 22 13:58:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF863A695A for ; Fri, 22 Oct 2010 13:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL+znFGGqGuP for ; Fri, 22 Oct 2010 13:58:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 17D4B3A68BA for ; Fri, 22 Oct 2010 13:58:39 -0700 (PDT) Received: by yxp4 with SMTP id 4so1112336yxp.31 for ; Fri, 22 Oct 2010 14:00:18 -0700 (PDT) Received: by 10.101.6.30 with SMTP id j30mr2542235ani.168.1287781218370; Fri, 22 Oct 2010 14:00:18 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id 13sm4019389anq.10.2010.10.22.14.00.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 14:00:17 -0700 (PDT) Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Oct 2010 16:00:15 -0500 References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se> <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se> <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se> <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:58:41 -0000 On Sep 28, 2010, at 9:29 AM, Hadriel Kaplan wrote: > > On Sep 27, 2010, at 7:14 PM, Peter Musgrave wrote: > >> Hi, >> >> I read the draft and I think the semantics are ok (although John's >> point about multiple proxies with these tags is a good one). >> >> One use which occurred to me - but which is no doubt controversial - >> is whether a proxy/B2B which is an SBC could provide a feature tag >> indicating it is an SBC - so that UAs which register and call through >> it could skip adding ICE candidates. (My point is merely that I >> suspect other uses for this capability will be found - even if you >> think this particular idea is mis-guided). >> > > Right, that particular idea is mis-guided. :) > > What you'd really do for that is indicate whether or not the b2bua > supports ICE (since some SBC's do, and some don't, indicating you're > an SBC doesn't help). Opposite: You want to know that the sbc masks (that is, breaks) ICE, so that (based on the presumption that if you don't have any information you should try ICE), you can choose not to ICE if you know it's going to fail. Option-tag: icebreaker. Semantic: a node that supports this extension is going to piddle in your ICE. Send traffic at room-temperature instead of iceing it unless you like yellow drinks. -- Dean From dean.willis@softarmor.com Fri Oct 22 14:01:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA113A6972 for ; Fri, 22 Oct 2010 14:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-0bYp6-Rfze for ; Fri, 22 Oct 2010 14:01:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 994573A6970 for ; Fri, 22 Oct 2010 14:01:30 -0700 (PDT) Received: by gxk3 with SMTP id 3so471993gxk.31 for ; Fri, 22 Oct 2010 14:03:09 -0700 (PDT) Received: by 10.100.171.10 with SMTP id t10mr2544552ane.26.1287781388911; Fri, 22 Oct 2010 14:03:08 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id r18sm2299250ann.29.2010.10.22.14.03.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 14:03:07 -0700 (PDT) Message-Id: From: Dean Willis To: "Worley, Dale R (Dale)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Oct 2010 16:03:06 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:01:31 -0000 On Oct 20, 2010, at 4:02 PM, Worley, Dale R (Dale) wrote: > Are there extensions for the reg (registration) event package to > report the Path for the registration, or the reg-id for SIP Outbound? There SHOULD be. Please start typing... -- Dean From christer.holmberg@ericsson.com Sun Oct 24 23:30:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBAD3A6936 for ; Sun, 24 Oct 2010 23:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX-5zCp5uIzz for ; Sun, 24 Oct 2010 23:30:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 198EB3A694A for ; Sun, 24 Oct 2010 23:30:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-bb-4cc5247753b3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.E3.04955.77425CC4; Mon, 25 Oct 2010 08:32:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 25 Oct 2010 08:32:23 +0200 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Mon, 25 Oct 2010 08:32:22 +0200 Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] Thread-Index: ActyKz9XBsvaszlvTdywAaHTG0Wc2gB4Zw+7 Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C717F5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 06:30:55 -0000 Hi, >> [as chair] >> >> To all sipcore participants: >> >> Christer has been looking for a way to accomplish a particular >> function that 3gpp wants. This proposal seems a plausible way to do >> that. But it is of necessity defining a more general mechanism. >> >> I'd really appreciate comments from others (including people in no >> way involved with 3gpp) regarding this mechanism. For instance, do >> you consider the semantics to be well defined? Do you see need for >> more about security implications? >> > >I think it's important to note that we're talking about a way of >advertising "option tags" -- the same option tags that theoretically >get added to the "Supported" headers in lots of messages, and that the >"Options" request was particularly designed to collect. > >Specifically, Christer has identified a use case where it is important >for other nodes to understand the options supported by a proxy in the >registration path, when that proxy is reasonably expected to be on the >request path for future requests using that registration. > >If, OTOH, we're really talking "feature tags" that refer to vendor- >tree specific feature identification -- well, then we're back to the >old service-identifier problem. Actually, the draft DOES talk about feature tags. And, yes, we could start to talk about service-ids again, but that is a muc= h wider topic, and is related to the usage of feature tags in general. UAs are already allowed to indicate capabilities using feature tags, and th= e draft allows intermediaries to do the same. But, of course, if one *requires* someone else to support something, option= -tags should be used, but insertion of option-tags by intermediaries is out= side the scope of the draft. Regards, Christer= From dworley@avaya.com Mon Oct 25 11:16:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FE43A68B0 for ; Mon, 25 Oct 2010 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIoSNqqK8l8o for ; Mon, 25 Oct 2010 11:16:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 88C5F3A692A for ; Mon, 25 Oct 2010 11:16:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="214054948" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Oct 2010 14:17:46 -0400 X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="528007435" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Oct 2010 14:17:46 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 25 Oct 2010 14:17:45 -0400 From: "Worley, Dale R (Dale)" To: Dean Willis Date: Mon, 25 Oct 2010 14:14:19 -0400 Thread-Topic: [sipcore] reg event package Thread-Index: ActyLIhhcbjAfh8gSyWThHzITX34sgCQ+iLC Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:16:04 -0000 ________________________________________ From: Dean Willis [dean.willis@softarmor.com] > Are there extensions for the reg (registration) event package to > report the Path for the registration, or the reg-id for SIP Outbound? There SHOULD be. Please start typing... ________________________________________ One can carry "reg-id" in an element. And I discovered tha= t our reg event server uses to carry the "path" value as we= ll, which is probably not kosher. Dale From root@core3.amsl.com Mon Oct 25 13:45:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BBEA83A63D3; Mon, 25 Oct 2010 13:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025204501.BBEA83A63D3@core3.amsl.com> Date: Mon, 25 Oct 2010 13:45:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen, J. Peterson Filename : draft-ietf-sipcore-location-conveyance-04.txt Pages : 26 Date : 2010-10-25 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the user agent client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-location-conveyance-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25133646.I-D@ietf.org> --NextPart-- From adam@nostrum.com Mon Oct 25 13:53:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2D73A67B3 for ; Mon, 25 Oct 2010 13:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PNkIAlKfwDO for ; Mon, 25 Oct 2010 13:53:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F23C63A6407 for ; Mon, 25 Oct 2010 13:53:00 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9PKsjvj010701 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 15:54:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CC5EE94.4090700@nostrum.com> Date: Mon, 25 Oct 2010 15:54:44 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: SIPCORE References: <4CAB453D.5020601@nostrum.com> In-Reply-To: <4CAB453D.5020601@nostrum.com> Content-Type: multipart/alternative; boundary="------------010900060203000305080307" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: simple-chairs@tools.ietf.org, "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] Call for consensus: draft-ietf-sipcore-presence-scaling-requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:53:04 -0000 This is a multi-part message in MIME format. --------------010900060203000305080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] It has been nearly three weeks, and there is been no expression of interest in continuing this work. We will ask the area directors to remove it from our charter and to mark the draft as "dead." /a On 10/5/10 10:33 AM, Adam Roach wrote: > [as chair] > > As you can see below, the SIMPLE working group has decided to remove > draft-ietf-simple-interdomain-scaling-analysis from its chartered > milestones. > > SIPCORE has a closely related work item: > draft-ietf-sipcore-presence-scaling-requirements. > It has been evaluated by the IESG, but has not been approved for > publication. The issue that is blocking its publication involves some > security related issues, which were to be addressed in the > interdomain-scaling-analysis. Further, the actual description of the > driving factors for the presence-scaling-requirements work are present > only in the interdomain-scaling-analysis work. > > With the interdomain-scaling-analysis work abandoned, the only path > for publishing presence-scaling-requirements would be to bring it back > to the working group, add the context that had been provided by the > interdomain-scaling-analysis draft, and address the IESG concerns that > have been raised around security and scaling. > > Given that the community of interest -- or disinterest, as the case > may be -- for the abandoned interdomain-scaling-analysis document is > almost certainly identical to that for the > presence-scaling-requirements document, it is a safe assumption that > SIPCORE can similarly remove the presence-scaling-requirements > milestone from its charter. > > So, I am posing the same question as the SIMPLE chairs: with the > interdomain-scaling-analysis work abandoned, is the > presence-scaling-requirements work still relevant? Are people still > interested in working on it? By that, I mean willing to spend time > doing focused reviews, offering feedback and maybe even text? > > Silence will be interpreted in the negative. > > /a > > > -------- Original Message -------- > Subject: Re: [Simple] draft-ietf-simple-interdomain-scaling-analysis > Date: Mon, 27 Sep 2010 14:55:48 -0500 > From: Ben Campbell > To: Simple WG > > > > Hi, > > We've had no expression of interest in continuing this effort. We will > ask our ADs to remove the milestone. > > Thanks! > > Ben. > > On Sep 24, 2010, at 9:24 AM, Ben Campbell wrote: > >> It's been almost a week, and no one has responded. If we don't hear >> otherwise from people who want to invest their time to work on this >> draft by Monday, we will ask the ADs to remove this milestone from >> the SIMPLE charter. >> >> Thanks! >> >> Ben. >> >> On Sep 19, 2010, at 9:09 AM, Ben Campbell wrote: >> >>> (as chair) >>> >>> draft-ietf-simple-interdomain-scaling-analysis has been stalled for >>> a while now. We handed it over to the IESG some time ago, but >>> received AD feedback indicating it needed significant work. It has >>> been cycle starved since then. The author may be in a position to >>> start working on it again. >>> * >>> * >>> *My question to the working group is, is this work still relevant? >>> Are people still interested in working on it? By that, I mean >>> willing to spend time doing focused reviews, offering feedback and >>> maybe even text?* >>> * >>> * >>> *Silence will be interpreted in the negative. * >>> * >>> * >>> *Thanks,* >>> * >>> * >>> *Ben.* >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > --------------010900060203000305080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

It has been nearly three weeks, and there is been no expression of interest in continuing this work. We will ask the area directors to remove it from our charter and to mark the draft as "dead."

/a

On 10/5/10 10:33 AM, Adam Roach wrote:
[as chair]

As you can see below, the SIMPLE working group has decided to remove draft-ietf-simple-interdomain-scaling-analysis from its chartered milestones.

SIPCORE has a closely related work item: draft-ietf-sipcore-presence-scaling-requirements.
It has been evaluated by the IESG, but has not been approved for publication. The issue that is blocking its publication involves some security related issues, which were to be addressed in the interdomain-scaling-analysis. Further, the actual description of the driving factors for the presence-scaling-requirements work are present only in the interdomain-scaling-analysis work.

With the interdomain-scaling-analysis work abandoned, the only path for publishing presence-scaling-requirements would be to bring it back to the working group, add the context that had been provided by the interdomain-scaling-analysis draft, and address the IESG concerns that have been raised around security and scaling.

Given that the community of interest -- or disinterest, as the case may be -- for the abandoned interdomain-scaling-analysis document is almost certainly identical to that for the presence-scaling-requirements document, it is a safe assumption that SIPCORE can similarly remove the presence-scaling-requirements milestone from its charter.

So, I am posing the same question as the SIMPLE chairs: with the interdomain-scaling-analysis work abandoned, is the presence-scaling-requirements work still relevant? Are people still interested in working on it? By that, I mean willing to spend time doing focused reviews, offering feedback and maybe even text?

Silence will be interpreted in the negative.

/a


-------- Original Message --------
Subject: Re: [Simple] draft-ietf-simple-interdomain-scaling-analysis
Date: Mon, 27 Sep 2010 14:55:48 -0500
From: Ben Campbell <ben@nostrum.com>
To: Simple WG <simple@ietf.org>


Hi,

We've had no expression of interest in continuing this effort. We will ask our ADs to remove the milestone.

Thanks!

Ben.

On Sep 24, 2010, at 9:24 AM, Ben Campbell wrote:

It's been almost a week, and no one has responded. If we don't hear otherwise from people who want to invest their time to work on this draft by Monday, we will ask the ADs to remove this milestone from the SIMPLE charter.

Thanks!

Ben.

On Sep 19, 2010, at 9:09 AM, Ben Campbell wrote:

(as chair)

draft-ietf-simple-interdomain-scaling-analysis has been stalled for a while now. We handed it over to the IESG some time ago, but received AD feedback indicating it needed significant work.   It has been cycle starved since then. The author may be in a position to start working on it again.

My question to the working group is, is this work still relevant? Are people still interested in working on it? By that, I mean willing to spend time doing focused reviews, offering feedback and maybe even text?

Silence will be interpreted in the negative. 

Thanks,

Ben.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

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



--------------010900060203000305080307-- From adam@nostrum.com Mon Oct 25 14:08:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C260D3A68DC for ; Mon, 25 Oct 2010 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCwE1aDq8Nla for ; Mon, 25 Oct 2010 14:08:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 362593A684C for ; Mon, 25 Oct 2010 14:08:02 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9PL9lHx011944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Oct 2010 16:09:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CC5F21B.6010208@nostrum.com> Date: Mon, 25 Oct 2010 16:09:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Call for agenda items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:08:04 -0000 [as chair] The chairs are aware of the following documents that would benefit from discussion at the upcoming SIPCORE meeting in Beijing: draft-ietf-sipcore-location-conveyance-04 - James Polk and/or Jon Peterson draft-mohali-sipcore-reason-extension-application-00 - Marianne Mohali draft-holmberg-sipcore-proxy-feature-00 - Christer Holmberg If you believe that there are items that should be added to this list, please send an email to the SIPCORE chairs (sipcore-chairs@tools.ietf.org) as soon as possible. Thank you. /a From dean.willis@softarmor.com Mon Oct 25 15:19:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2446D3A680F for ; Mon, 25 Oct 2010 15:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZXBfBFNmRVu for ; Mon, 25 Oct 2010 15:19:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 01E743A68A2 for ; Mon, 25 Oct 2010 15:19:45 -0700 (PDT) Received: by ywp6 with SMTP id 6so2050073ywp.31 for ; Mon, 25 Oct 2010 15:21:31 -0700 (PDT) Received: by 10.151.12.3 with SMTP id p3mr12385260ybi.237.1288045291527; Mon, 25 Oct 2010 15:21:31 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id v12sm7046605ybk.23.2010.10.25.15.21.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 15:21:30 -0700 (PDT) Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C717F5@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary=Apple-Mail-1-500442090 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Oct 2010 17:21:27 -0500 References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A058502C717F5@ESESSCMS0356.eemea.ericsson.se> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:19:47 -0000 --Apple-Mail-1-500442090 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 25, 2010, at 1:32 AM, Christer Holmberg wrote: >> >> >> Specifically, Christer has identified a use case where it is >> important >> for other nodes to understand the options supported by a proxy in the >> registration path, when that proxy is reasonably expected to be on >> the >> request path for future requests using that registration. >> >> If, OTOH, we're really talking "feature tags" that refer to vendor- >> tree specific feature identification -- well, then we're back to the >> old service-identifier problem. > > Actually, the draft DOES talk about feature tags. > So you mean "RFC 3840 media feature tags"? In your model, do they indicate that a particular feature is supported by the node, or do they indicate that a particular feature is being enforced by the node? Or do they indicate a request for delivery of functionality by other nodes -- that is, do they inform other nodes so that routing decisions can be made? The reason I ask is that I think we're talking about a family of "features" that are not really consistent with RFC 3840/41 media feature tags. That said, I'm fairly convinced that the whole capability negotiation model(s) in SIP is(are) an () ugly hack(s). -- Dean --Apple-Mail-1-500442090 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 25, 2010, = at 1:32 AM, Christer Holmberg wrote:


Specifically, = Christer has identified a use case where it is = important
for other nodes to = understand the options supported by a proxy in = the
registration path, when = that proxy is reasonably expected to be on = the
request path for future = requests using that registration.

If, OTOH, we're = really talking "feature tags" that refer to = vendor-
tree specific feature = identification -- well, then we're back to = the
old service-identifier = problem.

Actually, the draft DOES talk about feature = tags.


So you mean "RFC = 3840 media feature tags"? 

In your model, = do they indicate that a particular feature is supported by the node, or = do they indicate that a particular feature is being enforced by the = node? Or do they indicate a request for delivery of functionality by = other nodes -- that is, do they inform other nodes so that routing = decisions can be made?

The reason I ask is that = I think we're talking about a family of "features" that are not really = consistent with RFC 3840/41 media feature = tags.

That said, I'm fairly convinced = that the whole capability negotiation model(s) in SIP is(are) an () ugly = hack(s).

--
Dean
= --Apple-Mail-1-500442090-- From dean.willis@softarmor.com Mon Oct 25 15:22:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E633A6989 for ; Mon, 25 Oct 2010 15:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQnhJxwlHLJd for ; Mon, 25 Oct 2010 15:22:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 838613A680F for ; Mon, 25 Oct 2010 15:22:30 -0700 (PDT) Received: by gwb15 with SMTP id 15so143580gwb.31 for ; Mon, 25 Oct 2010 15:24:16 -0700 (PDT) Received: by 10.150.145.10 with SMTP id s10mr2582758ybd.416.1288045456148; Mon, 25 Oct 2010 15:24:16 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id k2sm3250379ybj.8.2010.10.25.15.24.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 15:24:15 -0700 (PDT) Message-Id: From: Dean Willis To: "Worley, Dale R (Dale)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Oct 2010 17:24:14 -0500 References: , X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] reg event package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:22:31 -0000 On Oct 25, 2010, at 1:14 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Dean Willis [dean.willis@softarmor.com] > >> Are there extensions for the reg (registration) event package to >> report the Path for the registration, or the reg-id for SIP Outbound? > > There SHOULD be. Please start typing... > ________________________________________ > > One can carry "reg-id" in an element. And I > discovered that our reg event server uses to carry > the "path" value as well, which is probably not kosher. Our continuing five-year mission: to explore strange new extensions; to make known the previously unknown params, and to boldy document what no previous developer has bothered to document. -- Dean From pkyzivat@cisco.com Mon Oct 25 15:33:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245523A6826 for ; Mon, 25 Oct 2010 15:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.2 X-Spam-Level: X-Spam-Status: No, score=-110.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeqPKc0c6h-k for ; Mon, 25 Oct 2010 15:33:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A64583A6C11 for ; Mon, 25 Oct 2010 15:33:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHuixUxAZnwM/2dsb2JhbAChU3GicpxRAoJyglQEik2DBg X-IronPort-AV: E=Sophos;i="4.58,238,1286150400"; d="scan'208";a="175120438" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2010 22:34:55 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9PMYtkR029333; Mon, 25 Oct 2010 22:34:55 GMT Message-ID: <4CC6060F.304@cisco.com> Date: Mon, 25 Oct 2010 18:34:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> <4CBF76C6.5060608@cisco.com> <4CC0D0D4.7000802@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:33:38 -0000 Marianne, Will you be attending the Beijing meeting? Given the email activity on this, I think it could use a bit of discussion there. Thanks, Paul On 10/22/2010 11:44 AM, marianne.mohali@orange-ftgroup.com wrote: > Ok, maybe I should show a *normal* case where the Reason header is included in the UA response and then copied in the H-I. And also a situation where thoses values can be used directly in request (I don't know how). > However, the voicemail case you mention is possible only for the last retargeting reason (the call could have been diverted several times). It could be usefull to store the previous reasons in the H-I for the case where a unified voicemail wants to join the firt diverting user box. > You said also that it wouldn't need to consult the H-I but I think it would be necessary to know the diverting user identity to find he's mailbox (in H-I). > > Indeed, a dedicated H-I parameter could match the need but I already done this proposal unsucessfully and this solution would be quite different from the present. > > Marianne > >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Envoyé : vendredi 22 octobre 2010 01:46 >> À : MOHALI Marianne RD-CORE-ISS >> Cc : sipcore@ietf.org >> Objet : Re: [sipcore] Commentson >> draft-mohali-sipcore-reason-call-forwarding-00 >> >> [as individual] >> >> I think maybe you misunderstood me. >> >> IMO its already somewhat of an abuse to include a header in >> URI in the H-I header, in the URI that was captured for >> inclusion in the H-I. If a UA received a URI in a 3xx >> response, and it contained a Reason header, then it would >> make perfect sense to put that into the H-I. But taking an >> R-URI and grafting on a Reason header before putting it into >> H-I seems at best a hack. But maybe that is water over the dam. >> >> The hack is compounded if the reason in the Reason header is >> never intended to be used in a Reason header in a request >> that is sent - rather that it is only intended to be used in >> H-I in an already abusive way. >> >> BUT, I expect in fact that these reason values *could* >> actually be useful in requests. If so, you would do yourself >> a favor to point that out in the draft. In your example 4, as >> Dale already pointed out, the Reason header doesn't appear in >> INVITE F5. But it *could*, and it would make sense that it >> should. That tells the voicemail system *directly* the reason >> why it was contacted. It wouldn't necessarily need to consult >> the H-I in an attempt to figure that out. >> >> If that is *not* useful - if such values should be ignored in >> favor of analyzing the H-I entries - then I assert that >> Reason should not be used for this. Rather H-I should use its >> own header parameters to convey this sort of information. >> >> Thanks, >> Paul >> >> >> On 10/21/2010 5:05 PM, marianne.mohali@orange-ftgroup.com wrote: >>> Hi Paul, >>> >>> My answer in your text [MM] >>> >>> Thanks, >>> Marianne >>>> -----Message d'origine----- >>>> De : sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] De la part de Paul >> Kyzivat Envoyé : >>>> jeudi 21 octobre 2010 01:10 À : sipcore@ietf.org Objet : Re: >>>> [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00 >>>> >>>> [as participant] >>>> >>>> I think I'm replying to an earlier message, not this one, but the >>>> point is the same: >>>> >>>> IIUC the intent of this work is to define new values for >> the Reason >>>> header, that can be used in a Reason header inserted into a URI in >>>> History-Info. And there is *no* expectation that these >> values would >>>> be used in a Reason header in a message that is actually sent. Is >>>> that right? >>> [MM] It is right for the draft in subject (reason for call >> diversion) but not for the other draft (if it is what you >> mean by "an earlier message") you seem to refer (Reason for >> applications) where new values could be added "everywhere". >>>> >>>> If so, it at least sounds like an abuse - that some other >> mechanism >>>> should be used. >>>> >>>> OTOH, if there is some plausible reason to use this in an actual >>>> request then I find it much less troubling. >>> [MM] Answering only for the draft in subject; it's true >> that it has a narrow scope but, at the end, the new values >> could be present everywhere the History-Info header is. At >> this time, I described our need but I could think about a >> larger use of those new values (eg. directly in a SIP error >> response due to a UA retargeting). >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote: >>>>> Hi Dale, >>>>> >>>>> Thanks for your positive review. >>>>> >>>>> See my answer in your mail [MM] >>>>> >>>>> Best Regards, >>>>> Marianne >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sipcore-bounces@ietf.org >>>>>> [mailto:sipcore-bounces@ietf.org] De la part de Worley, >>>> Dale R (Dale) >>>>>> Envoyé : lundi 18 octobre 2010 23:12 À : sipcore@ietf.org >>>> Objet : Re: >>>>>> [sipcore] Comments on >>>> draft-mohali-sipcore-reason-call-forwarding-00 >>>>>> >>>>>> Here are some more comments on this draft: >>>>>> >>>>>> The term "call diversion" sounds more inclusive to the >>>> naive ear than >>>>>> "call forwarding". If the two terms are used identically in the >>>>>> draft, it seems better to use only the former, especially >>>> because the >>>>>> abbreviation "CDIV" is being used. >>>>> [MM] I agree with your statement, with call diversion no >>>> ambiguity is possible. I thought that "call forwarding" was the >>>> original term and I didn't wanted to change the habits but >> searching >>>> a simple acronym for the protocol value, 'CDIV' >>>> sounds good to me. >>>>> >>>>>> Section 3 does not give any BNF for CDIV, though it quotes >>>> all of the >>>>>> established BNF for the Reason header. Clearly, what is >>>> intended (but >>>>>> not stated) is: >>>>>> >>>>>> protocol =/ "CDIV" >>>>> [MM] What is just after the established BNF is not good? >>>> I've used RFC4411 as a model. >>>>> >>>>>> In regard to listing the CDIV cause values, it seems to me >>>> that there >>>>>> should be an existing encoding of call diversion reasons >> somewhere >>>>>> within the 3GPP specification, and it would be more >>>> effective for the >>>>>> draft to reference that table (which would be maintained >> by 3GPP) >>>>>> rather than defining a new IANA registry (which would be >>>> used almost >>>>>> exclusively by 3GPP). >>>>> [MM] Right, but the existing CDIV cause values (described >>>> in 3GPP) are a corruption of SIP response codes and brings >> confusion. >>>> It is the initial reason of this draft. Your idea of mixing both >>>> sound good to me: register a new protocol value "CDIV" but >> keep the >>>> reasons values as in 3GPP. The problem I see is that reason values >>>> are described in RFC4458 not for the Reason header but for an URI >>>> parameter and I'me not sure it is possible to re-use it. >> An other way >>>> could be to registering cause values but with the same values as >>>> today instead of (1 to 8). Let's think about it... >>>>> >>>>>> >>>>>> In the example, it appears that the 302 response F3 is >>>> informing the >>>>>> proxy that the call should be sent to Voicemail. In >> that case, the >>>>>> 302 would also carry the Reason header explaing why the >>>> diversion is >>>>>> being done, which the proxy would subsequently >> transcribe into the >>>>>> History-Info header of the new INVITE F5: >>>>>> >>>>>> F3: 302 Bob -> proxy.example.com >>>>>> >>>>>> SIP/2.0 302 Moved Temporarily >>>>>> Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 >>>>>> Via: SIP/2.0/TCP >> proxy.example.com:5060;branch=z9hG4bK-klj79f >>>>>> From: Alice; >> tag=1234567 >>>>>> To: sip:+15551002@example.com;user=phone;tag=765432 >>>>>> Call-ID: c3x842276298220188511 >>>>>> Contact: >>>>>> Reason: CDIV;cause=6;text="Deflection immediate response" >>>>>> CSeq: 1 INVITE >>>>>> Content-Length: 0 >>>>> >>>>> [MM] Right, I will add it in the next version. >>>>>> >>>>>> In the example, F5 has two "Reason" headers attached to >> the URI at >>>>>> index 1. If you have more than one "header" attached to a >>>> URI, only >>>>>> the first is introduced with "?", the remainder are >> introduced with >>>>>> "&": >>>>>> >>>>>> >> History-Info:>>>>> %3Bcause=302%3Btext="Moved >> Temporarily"&Reason=CDIV >>>>>> %3Bcause=6%3Btext="Deflection immediate >>>>>> response">;index=1, >>>>>> ;index=1.1;mp=1 >>>>> [MM]Exact, I noted this mistake just after I submitted the >>>> draft :-/ Thanks. >>>>>> >>>>>> There are also some difficulties regarding the >>>> History-Info headers >>>>>> in the examle; they don't appear to be consistently >> applied to all >>>>>> the INVITEs. >>>>> [MM] ok, I will review it in detail. >>>>>> >>>>>> Dale >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> > From root@core3.amsl.com Mon Oct 25 17:00:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7E7BE3A6840; Mon, 25 Oct 2010 17:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101026000002.7E7BE3A6840@core3.amsl.com> Date: Mon, 25 Oct 2010 17:00:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 00:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al. Filename : draft-ietf-sipcore-rfc4244bis-02.txt Pages : 47 Date : 2010-10-25 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. SIP header field parameters are defined to tag the method by which the target of a request is determined. In addition, this document defines a value for the Privacy header specific to the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc4244bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25164930.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Mon Oct 25 22:49:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C934C3A67E4 for ; Mon, 25 Oct 2010 22:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d48grKOswBQN for ; Mon, 25 Oct 2010 22:49:09 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7005A3A67AB for ; Mon, 25 Oct 2010 22:49:09 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:54898 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S36570313Ab0JZFuz (ORCPT ); Tue, 26 Oct 2010 00:50:55 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 26 Oct 2010 00:50:55 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 26 Oct 2010 13:50:52 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Peterson, Jon" Date: Tue, 26 Oct 2010 13:50:50 +0800 Thread-Topic: location conveyance looks good Thread-Index: Act00b5kRhXX8ZY4TqSBlXpFWsid/g== Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAF78@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: [sipcore] location conveyance looks good X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 05:49:18 -0000 UmV2aWV3aW5nIHRoZSBjaGFuZ2VzIGluIGRyYWZ0LWlldGYtc2lwY29yZS1sb2NhdGlvbi1jb252 ZXlhbmNlLTA0LiAgTm90aGluZyBtdWNoIHRvIGFkZCBleGNlcHQgbml0cy4NCg0KSSBjb3VsZCBx dWliYmxlLiAgSSBzdGlsbCBkb24ndCBsaWtlIG9yIHdhbnQgdGhlIGVudGlyZXR5IG9mIFNlY3Rp b24gNC4zIGFuZCB0aGUgc2VyaWFsIG5hdHVyZSBGaWd1cmUgMiBpcyBhIGxpdHRsZSBteXN0ZXJp b3VzIHRvIG1lLCBidXQgaXQncyBkb3duIHRvIHN1YmplY3RpdmUgc3R1ZmYgbGlrZSB0aGF0LCB0 aGUgZWZmb3J0IGp1c3QgZG9lc24ndCBwYXkgb2ZmLg0KDQpTbywgc2hpcCBpdC4NCiANCi0tTWFy dGluDQoNCg0KTml0czoNCg0KVGhpcyBzZWVtcyBvZGQsIGVzcGVjaWFsbHkgc2luY2UgdGhlIHBh cmFtZXRlciBpcyBNVVNULXN0cmVuZ3RoIG1hbmRhdG9yeToNCg0KICAgLi4uICBJZiBubyByb3V0 aW5nLWFsbG93ZWQgcGFyYW1ldGVyCQ0KICAgaXMgcHJlc2VudCBpbiBhIFNJUCByZXF1ZXN0LCBh IFNJUCBpbnRlcm1lZGlhcnkgTUFZIGluc2VydCB0aGlzCQ0KICAgdmFsdWUgd2l0aCBhIFJFQ09N TUVOREVEIHZhbHVlIG9mICJubyIgYnkgZGVmYXVsdC4NCg0KQ3Jvc3MgcmVmZXJlbmNlcyBzaG91 bGQgY2FwaXRhbGl6ZSB0aGUgJ3MnIGluIFNlY3Rpb24gMy40Lg0KDQpUaGUgTUlNRSBtdWx0aXBh cnQgaGVhZGVycyBhcmUgc3RpbGwgaW4gdGhlIHdyb25nIHBsYWNlIChzZWUgU2VjdGlvbiA1IG9m IFJGQyAyMzg3IHRvIHNlZSBob3cgdGhpcyBpcyBkb25lKToNCg0KT0xEOg0KLS1ib3VuZGFyeQ0K DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BpZGYreG1sDQpDb250ZW50LUlEOiA8YmxhaGJs YWhAZXhhbXBsZS5jb20+DQo8P3htbCB2ZXJzaW9uPSIxLjAiIHN0YW5kYWxvbmU9InRydWUiPz4N CjxwcmVzZW5jZSAuLi4NCg0KTkVXOg0KLS1ib3VuZGFyeQ0KQ29udGVudC1UeXBlOiBhcHBsaWNh dGlvbi9waWRmK3htbA0KQ29udGVudC1JRDogPGJsYWhibGFoQGV4YW1wbGUuY29tPg0KDQo8P3ht bCB2ZXJzaW9uPSIxLjAiIHN0YW5kYWxvbmU9InRydWUiPz4NCjxwcmVzZW5jZSAuLi4NCg== From christer.holmberg@ericsson.com Tue Oct 26 00:12:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AF83A688D for ; Tue, 26 Oct 2010 00:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.068 X-Spam-Level: X-Spam-Status: No, score=-6.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz1xF87C6Qg7 for ; Tue, 26 Oct 2010 00:11:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6F4663A691C for ; Tue, 26 Oct 2010 00:11:47 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-32-4cc67f83450f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 92.F2.13412.38F76CC4; Tue, 26 Oct 2010 09:13:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 26 Oct 2010 09:13:07 +0200 From: Christer Holmberg To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Tue, 26 Oct 2010 09:12:00 +0200 Thread-Topic: [sipcore] Call for agenda items Thread-Index: Act0iPhgySCULHwbTXeiq1ra9Z3NyAAVByrh Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71813@ESESSCMS0356.eemea.ericsson.se> References: <4CC5F21B.6010208@nostrum.com> In-Reply-To: <4CC5F21B.6010208@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Call for agenda items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:12:17 -0000 Hi Adam, I can put together some slides about proxy-feature. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Tuesday, October 26, 2010 12:09 AM To: SIPCORE (Session Initiation Protocol Core) WG Subject: [sipcore] Call for agenda items [as chair] The chairs are aware of the following documents that would benefit from discussion at the upcoming SIPCORE meeting in Beijing: draft-ietf-sipcore-location-conveyance-04 - James Polk and/or Jon Peterson draft-mohali-sipcore-reason-extension-application-00 - Marianne Mohali draft-holmberg-sipcore-proxy-feature-00 - Christer Holmberg If you believe that there are items that should be added to this list, please send an email to the SIPCORE chairs (sipcore-chairs@tools.ietf.org) as soon as possible. Thank you. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From R.Jesske@telekom.de Tue Oct 26 00:40:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38823A67F1 for ; Tue, 26 Oct 2010 00:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+-mkQuxRIf7 for ; Tue, 26 Oct 2010 00:40:16 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 5F1213A67A6 for ; Tue, 26 Oct 2010 00:40:16 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail81.telekom.de with ESMTP; 26 Oct 2010 09:41:56 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 09:41:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 09:41:52 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD406CA4723@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] thread-index: ActWs609oi+YtkgWQkKnkN4ujn/rvgAAlrHLAUgz1CAGQjzQYA== References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se><4C936714.2040808@cisco.com><7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com><7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 26 Oct 2010 07:41:53.0205 (UTC) FILETIME=[41E2FE50:01CB74E1] Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:40:18 -0000 Hi Christer, Thank you for this draft. I think this delivers a useful mechanism for = some of our use-cases in our network. I'm also willing to participate in the work of the draft. Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Christer Holmberg Gesendet: Freitag, 24. September 2010 13:04 An: sipcore@ietf.org Betreff: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: = Feature-tags in the Path header field] =20 Hi, I've submitted a draft, which extends the rr-param rule, allowing = proxies to indicate supported features using feature tags in Path, = Record-Route etc. The draft can also be found at: = http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-featu= re-00.txt As I indicated earlier on the list, and as you can read in the draft, = there is a 3GPP use-case where we believe the mechanism could be used. = But, there is nothing 3GPP specific about the mechanism as such. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Oct 26 00:46:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D813A67A2 for ; Tue, 26 Oct 2010 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUJa8GRx8Ymx for ; Tue, 26 Oct 2010 00:46:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 045D63A6868 for ; Tue, 26 Oct 2010 00:46:42 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-0e-4cc687c8373e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.69.13412.8C786CC4; Tue, 26 Oct 2010 09:48:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 26 Oct 2010 09:48:20 +0200 From: Christer Holmberg To: Dean Willis Date: Tue, 26 Oct 2010 09:48:19 +0200 Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] Thread-Index: Act0kvqORwN6gICxTZCJ9Jsqp5u8ugAS/ZtR Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71817@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> <4CA0AE61.7060003@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A058502C717F5@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:46:44 -0000 Hi Dean, >>>Specifically, Christer has identified a use case where it is important f= or other nodes to understand the options supported by a proxy in the >>>registration path, when that proxy is reasonably expected to be on the r= equest path for future requests using that registration. >>> >>>If, OTOH, we're really talking "feature tags" that refer to vendor-tree = specific feature identification -- well, then we're back to the >>>old service-identifier problem. >> >>Actually, the draft DOES talk about feature tags. > >So you mean "RFC 3840 media feature tags"?=20 Correct. >In your model, do they indicate that a particular feature is supported by = the node, or do they indicate that a particular feature is being enforced b= y the node?=20 >Or do they indicate a request for delivery of functionality by other nodes= -- that is, do they inform other nodes so that routing decisions can be ma= de? Eventhough I guess one can make routing decissions based on whatever inform= ation, the basic purpose of a feature tag is NOT to indicate "routing polic= ies" - it's to indicate that a particulare feature is suppored by the node = that inserted the feature tag. Regards, Christer= From adam@nostrum.com Tue Oct 26 09:19:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95EB3A691E for ; Tue, 26 Oct 2010 09:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH8U2DaVm1TF for ; Tue, 26 Oct 2010 09:19:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8D7573A68B1 for ; Tue, 26 Oct 2010 09:18:59 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o9QGKjhq009518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Oct 2010 11:20:46 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4CC6FFDD.5050706@nostrum.com> Date: Tue, 26 Oct 2010 11:20:45 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Draft Agenda X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 16:19:00 -0000 [as chair] I have posted a draft agenda for the upcoming meeting in Beijing: http://www.ietf.org/proceedings/79/agenda/sipcore.html If you have any comments or requests regarding this proposed agenda, please send email to no later than Friday, October 29th. Thank you. /a From mary.ietf.barnes@gmail.com Tue Oct 26 13:37:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F333A688A for ; Tue, 26 Oct 2010 13:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxgVk0ih+VWs for ; Tue, 26 Oct 2010 13:37:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DF2C83A679C for ; Tue, 26 Oct 2010 13:37:56 -0700 (PDT) Received: by gya6 with SMTP id 6so3541364gya.31 for ; Tue, 26 Oct 2010 13:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Wl9KVQ1d4ToANUBpC+srYGo7ven6Oe7v7eNFp8CH3UM=; b=L/hHs4ZsVqAL5i9ipVA/LdQmIFjyeaaJF/fVdG9LJQ+K/vAPfTNCGN5y2Vn/iwnvwA cQKwSAcAG76FhLfiOpQX4eUvWCeIjqjVxNQcPPXgH+gGpqBU47gDOBDUbZv6ybKhe4sD /upIHxvP4gJmJ0e3ovpIulqnFfOUrwLJCIiOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Ecy2REBmP/YUPJ8Pmg4W5bZeMFwsvcbGRL+oCBHwSMqBeXHov84TmcgbcMx9ocispN BwcZpgLLiMT/D245hpgXuHxvUpzhSyYfqj1UvK0ghXleEZwRMPM/XrTsP6oLQUnxhGdd rsfM5KPnxrqHmSGPMQVBOyN7Cj+0g2sircg8I= MIME-Version: 1.0 Received: by 10.150.54.9 with SMTP id c9mr132160yba.396.1288125589585; Tue, 26 Oct 2010 13:39:49 -0700 (PDT) Received: by 10.236.110.51 with HTTP; Tue, 26 Oct 2010 13:39:44 -0700 (PDT) In-Reply-To: <20101026000002.7E7BE3A6840@core3.amsl.com> References: <20101026000002.7E7BE3A6840@core3.amsl.com> Date: Tue, 26 Oct 2010 15:39:44 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:37:59 -0000 Hi folks, We have updated the document to address the issues raised and discussed on the mailing list. The following summarizes the changes and lists the issues related to the change: 1. Editorial nits/clarifications. [Issues: 1,6,17,18,21- 23,25,26,30-33,35-37,39,40] 2. Removing extraneous 4244 text - e.g., errors in flows, "stronger" security, "session" privacy. [Issues: 3,5,7,11 ] 3. Updated definition of "retarget" to be all encompassing - i.e., also includes internal changes of target URI. Clarified text for "internal retarging" in proxy section. [Issues: 2,8,9] 4. Clarified that the processing for Proxies is equally applicable to other SIP intermediaries. [Issue: 9]. 5. Changed more SHOULDs to MUSTs. [Issue: 10] 6. Fixes to Application considerations section. [Issues: 12-15] 7. Changed language in the procedure for Indexing to normative language. 8. Clarifications for UAC processing: * SHOULD add hi-entry. [Issue: 28] * MUST add histinfo option tag. [Issue: 27 ] * Clarify applicability to B2BUA. [Issue: 29] * Fixed text for indexing for UAC in case of 3xx. 9. Changed "hit" URI parameter to header parameters: [Issues:4,40] * Added index to all target header parameters. [Issues: 41] * Updated all the relevant sections documenting setting and use of new header parameters. [Issue: 40] 10. Updated/clarified/simplified privacy handling. [Issue: 16] 11. Updated Redirect Server section to allow adding History-Info headers. [Issue: 24 ] 12. Added text around restrictions for Tel-URIs - i.e., no privacy or reason. [Issues: 4, 12] 13. Updated text for forking - what goes in response. [Issues: 19,20] I will respond and/or close the issues providing more detail as needed over the next few days. Please review and reply to the appropriate threads related to the already open issues rather than opening new issues unless there is something *really* new that is not related in any way to the current issues (which I don't think is possible due to the extent of the text impacted by the round of changes for these issues). And, please do NOT open issues for editorial nits, which I'm sure have been introduced with these changes despite my best efforts - either send a list of nits in a single email to the mailing list or better yet to me directly. The diff is quite useful for re-reviewing the changes: http://tools.ietf.org/wg/sipcore/draft-ietf-sipcore-rfc4244bis/draft-ietf-s= ipcore-rfc4244bis-02-from-01.diff.html Regards, Mary. On Mon, Oct 25, 2010 at 7:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core Working= Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session In= itiation Protocol (SIP) for Request History Information > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-02= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 47 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-25 > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. =A0This capability enables many enhanced services by providing > the information as to how and why a call arrives at a specific > application or user. =A0This document defines an optional SIP header, > History-Info, for capturing the history information in requests. =A0SIP > header field parameters are defined to tag the method by which the > target of a request is determined. =A0In addition, this document > defines a value for the Privacy header specific to the History-Info > header. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From pkyzivat@cisco.com Tue Oct 26 18:34:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866473A68F9 for ; Tue, 26 Oct 2010 18:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh5kwh76ASFB for ; Tue, 26 Oct 2010 18:34:17 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BD9F23A6907 for ; Tue, 26 Oct 2010 18:34:16 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,244,1286150400"; d="scan'208";a="175374971" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 01:36:03 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9R1a34N004674; Wed, 27 Oct 2010 01:36:03 GMT Message-ID: <4CC78202.6090700@cisco.com> Date: Tue, 26 Oct 2010 21:36:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "James M. Polk (E-mail)" , Jon Peterson References: <20101025195020.1DA5A3A68E5@core3.amsl.com> In-Reply-To: <20101025195020.1DA5A3A68E5@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 01:34:20 -0000 I took a quick look at the new version, and it seems to have cleanup a lot. But there *still* seems to be a problem with the syntax. (Interplay between ABNF and text.) From the text, I find: The placement of the "routing-allowed" header field parameter, strongly encouraged by [RFC5606], is outside the locationValue, and MUST always be last in the header field value. The routing-allowed parameter MUST be present, even when no locationValue is present. This is questionably supported by the ABNF: Geolocation-header = "Geolocation" HCOLON Geolocation-value Geolocation-value = ( locationValue [ COMMA locationValue ] ) / routing-param locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" It only works if you presume that there are separate occurrences of GeoLocation-header in the message, one with just locations, another with just the routing-param. The routing-param certainly can't be "last in the header field value" except in the degenerate sense, since it must be first and only in a Geolocation-header. Below are some specific cases - both valid and invalid. In each case I show some headers bracketed by "...". That is intended to mean other headers in a message, but all in the same message. (And when I show multiple headers, there could be other non-geoloc headers interleaved.) * The following are legal according to the above, and probably within expected usage: ... Geolocation: cid:foo@example.com Geolocation: routing-allowed=yes ... ... Geolocation: cid:foo@example.com,cid:bar@example.com Geolocation: routing-allowed=yes ... ... Geolocation: routing-allowed=no ... * IIUC the following are allowed by the above both syntactically and according to the text, but is presumably not *intended* to be valid. (Its legal because the in each instance of Geolocation-header its last.) ... Geolocation: routing-allowed=no Geolocation: routing-allowed=yes ... The following is also allowed - I don't know if its intended or not: ... Geolocation: routing-allowed=yes Geolocation: cid:foo@example.com,cid:bar@example.com ... * The following is allowed by the ABNF though disallowed by the text: ... Geolocation: cid:foo@example.com,cid:bar@example.com Geolocation: cid:baz@example.com ... * The following is *not* allowed by the ABNF. I suspect it might be intended to be valid, but I'm far from sure about it: ... Geolocation: cid:foo@example.com,routing-allowed=yes ... In addition to that, the text is very explicit that: The routing-allowed parameter MUST be present, even when no locationValue is present. but then it says: If no routing-allowed parameter is present in a SIP request, a SIP intermediary MAY insert this value with a RECOMMENDED value of "no" by default. So its required, but we have rules to follow if its missing. But I don't understand how it *can* be required, since the sender of the request may not understand/support Geolocation and so won't include it. ISTM that in reality its only *required* if the is a locationValue present, and is otherwise optional. In that case, an intermediary that adds a locationValue not only MAY, but presumably MUST add a missing routing-param if it adds a locationValue. I have never understood why the routing-param is required to be last. And as my examples show, its difficult/impossible to enforce this in ABNF. Thanks, Paul From Martin.Thomson@andrew.com Tue Oct 26 21:05:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734F53A698B for ; Tue, 26 Oct 2010 21:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSRFrWO4+Cy5 for ; Tue, 26 Oct 2010 21:05:13 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id A49BF3A698A for ; Tue, 26 Oct 2010 21:05:12 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:12730 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S36640124Ab0J0EHB (ORCPT ); Tue, 26 Oct 2010 23:07:01 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 26 Oct 2010 23:07:01 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 27 Oct 2010 12:06:58 +0800 From: "Thomson, Martin" To: Paul Kyzivat , "James M. Polk (E-mail)" , Jon Peterson Date: Wed, 27 Oct 2010 12:06:55 +0800 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-04 Thread-Index: Act1d1gRzKKJZTpVSZ+6dmPEC/dzQgAFGUYA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> In-Reply-To: <4CC78202.6090700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:05:18 -0000 T24gMjAxMC0xMC0yNyBhdCAxMjozNjowMiwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPiBJIGhhdmUg bmV2ZXIgdW5kZXJzdG9vZCB3aHkgdGhlIHJvdXRpbmctcGFyYW0gaXMgcmVxdWlyZWQgdG8gYmUg bGFzdC4NCj4gQW5kIGFzIG15IGV4YW1wbGVzIHNob3csIGl0cyBkaWZmaWN1bHQvaW1wb3NzaWJs ZSB0byBlbmZvcmNlIHRoaXMgaW4NCj4gQUJORi4JDQoNCklmICJyb3V0aW5nLWFsbG93ZWQiIGlz IG1hbmRhdG9yeSwgaXQgSVMgcG9zc2libGU6DQoNCiAgICBHZW9sb2NhdGlvbi1oZWFkZXIgPSAi R2VvbG9jYXRpb24iIEhDT0xPTiBHZW9sb2NhdGlvbi12YWx1ZQ0KICAgIEdlb2xvY2F0aW9uLXZh bHVlICA9IFsgbG9jYXRpb25WYWx1ZSBbIENPTU1BIGxvY2F0aW9uVmFsdWUgXSBDT01NQSBdDQog ICAgICAgICAgICAgICAgICAgICAgICAgcm91dGluZy1wYXJhbQ0KDQpJdCdzIGEgbGl0dGxlIHN0 cmFuZ2UsIGJ1dCBpdCBkb2VzIHdvcmsuICBFc3BlY2lhbGx5IGlmIHlvdSBhbHNvIGFkZCB0ZXh0 IHRoYXQgc3RhdGVzIHRoZXJlIGNhbiBiZSBvbmx5IG9uZSBHZW9Mb2NhdGlvbiBoZWFkZXI/DQoN CihUaGUgb3RoZXIgdGhpbmcgdGhhdCBJIGZpbmQgc3RyYW5nZSBpcyB0aGUgZmFjdCB0aGF0IHRo ZXJlIGNhbiBiZSB6ZXJvLCBvbmUgb3IgdHdvIGxvY2F0aW9uVmFsdWUgcGFydHMuICBUaGlzIGlz IGNvbmZ1c2luZyBmb3IgY29tcHV0ZXIgc2NpZW50aXN0cyB3aG8gY2FuIG9ubHkgY291bnQ6IHpl cm8sIG9uZSwgbWFueS4pDQoNCi0tTWFydGluDQo= From jmpolk@cisco.com Tue Oct 26 21:28:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4793A67D3 for ; Tue, 26 Oct 2010 21:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSqFW3oH9F-t for ; Tue, 26 Oct 2010 21:28:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D667B3A6992 for ; Tue, 26 Oct 2010 21:28:08 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,244,1286150400"; d="scan'208";a="610238443" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 04:29:57 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9R4TuCM027015; Wed, 27 Oct 2010 04:29:56 GMT Message-Id: <201010270429.o9R4TuCM027015@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Oct 2010 23:29:55 -0500 To: "Thomson, Martin" , "James M. Polk" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EAF78@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03F31EAF78@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location conveyance looks good X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:28:12 -0000 At 12:50 AM 10/26/2010, Thomson, Martin wrote: >Reviewing the changes in >draft-ietf-sipcore-location-conveyance-04. Nothing much to add except nits. > >I could quibble. I still don't like or want the entirety of Section 4.3 that would be quibbling, and we don't want that, now do we? >and the serial nature Figure 2 is a little mysterious to me if I send you a SIP request with a location URI, you need to be able to dereference it (or at least try) before you accept the SIP request. I know it'll add a bit of time to the 200 OK, but that will allow confirmation of location delievery - which isn't the location URI, but the location value itself (i.e., the PIDF-LO). If the dereference fails after you've sent me a 200 OK, how can you possibly tell me that there was something wrong with my delivery of location to you? >, but it's down to subjective stuff like that, the effort just >doesn't pay off. > >So, ship it. > >--Martin > > >Nits: > >This seems odd, especially since the parameter is MUST-strength mandatory: > > ... If no routing-allowed parameter > is present in a SIP request, a SIP intermediary MAY insert this > value with a RECOMMENDED value of "no" by default. > >Cross references should capitalize the 's' in Section 3.4. > >The MIME multipart headers are still in the wrong place (see Section >5 of RFC 2387 to see how this is done): > >OLD: >--boundary > >Content-Type: application/pidf+xml >Content-ID: > > >NEW: >--boundary >Content-Type: application/pidf+xml >Content-ID: > > > X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821AE3A68F7 for ; Tue, 26 Oct 2010 21:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poCtZheibgGX for ; Tue, 26 Oct 2010 21:30:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9BD083A698C for ; Tue, 26 Oct 2010 21:30:32 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZHx0yrR7Hu/2dsb2JhbAChVnGjM5wrgnOCVQSEVw X-IronPort-AV: E=Sophos;i="4.58,244,1286150400"; d="scan'208";a="276356693" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2010 04:32:21 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9R4WLe8013111 for ; Wed, 27 Oct 2010 04:32:21 GMT Message-Id: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Oct 2010 23:32:20 -0500 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:30:57 -0000 SIPCORE I've submitted the next version of Location Conveyance (-04) http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt and I believe this version has addressed each open item from the mailing list, as well as what was discussed and agreed to in the Maastricht meeting. I have attempted to identify each open issue with the specific resolution here (in no particular order): - Martin wanted Section 3 to be broken up into subsections, each revolving around each of the 4 diagrams. I have done this. - allowed a maximum of two (up from one) locationValues to be present in the Geolocation header value. The text however recommends against inserting a second value. This was agreed to in Maastricht. - Because we're allowing a max of two locationValues, they can be in separate Geolocation headers in the SIP request. This scenario necessitates bring a previous version's paragraph in stating that a 'SIP intermediary MUST inspect all instances of each Geolocation header before considering the routing-allowed parameter to be considered =yes', to ensure there isn't a conflict in the 'other' Geolocation header that states the policy is =no. - with the ability to add a second locationValue, it is necessary to warn against doing this (confusion at the LRs). - Added the "you break it you bought it" philosophy to SIP intermediaries that choose to insert a second location where one already existed, especially for inserting a location URI in the downstream SIP request. - Fixed the ABNF to handle zero, one or two (but no more) locationValues according to the agreement in Maastricht. There is a one-off use case which won't be in play very often, but is a WG item in ECRIT that several wanted to allow the possibility for (involving allowing one coarse and one highly accurate location in the same SIP request). - Paul K. wanted the use-case in which a SIP intermediary inserts a locationValue where one didn't exist previously, and received a 424 (Bad Location Information) to that inserted location, from having the 424 propagate towards the UAC (as the UAC might not know what to do with a 424). This is now covered in Section 4.3. - changed existing text to "MUST NOT" from "does not" about a 424 not terminating an existing dialog (just increased the strength of this. - I added the 424 to the table 2 entry in which the Geolocation header can be in only this response. - I added text stating the conditions for adding a Geolocation header value to the 424, to make it clear what is and what isn't allowed for this. - Martin wanted me to add back in the top level Geolocation-Error codes 100, 200, 300 and 400, which I did in section 4.3. - rejected the idea that the geolocation option-tag hasn't been justified. - Added RFCs 2616, 2818 and HELD Deref ID to the references section because I added the ability to include HTTP: and HTTPS: URIs, and stated if received, they should be dereferenced according to the HELD Deref doc. - changed the Section 5 examples how Martin wanted them. - Stated that GEO-URIs are not appropriate for the SIP Geolocation header, according to the discussion during the Maastricht Geopriv meeting. - we changed the privacy section, and included a ref to the Geopriv Arch doc, according to the agreement in Geopriv at Maastricht. Comments are encouraged We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing (to give folks a sense of our plans). James/Brian/Jon From Martin.Thomson@andrew.com Tue Oct 26 22:30:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841663A67E3 for ; Tue, 26 Oct 2010 22:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFEuNZ81wzGO for ; Tue, 26 Oct 2010 22:30:09 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 494483A67F6 for ; Tue, 26 Oct 2010 22:30:09 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:40776 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S36642325Ab0J0Fbv (ORCPT ); Wed, 27 Oct 2010 00:31:51 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 27 Oct 2010 00:31:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 27 Oct 2010 13:31:49 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Peterson, Jon" Date: Wed, 27 Oct 2010 13:31:47 +0800 Thread-Topic: location conveyance looks good Thread-Index: Act1j54rLbBDIWvSQ0Cp4HDqfVLtNwACGW+w Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EB10B@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F31EAF78@SISPE7MB1.commscope.com> <201010270429.o9R4TuCM027015@sj-core-2.cisco.com> In-Reply-To: <201010270429.o9R4TuCM027015@sj-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location conveyance looks good X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 05:30:18 -0000 T24gMjAxMC0xMC0yNyBhdCAxNToyOTo1NSwgSmFtZXMgTS4gUG9sayB3cm90ZToNCj4gPmFuZCB0 aGUgc2VyaWFsIG5hdHVyZSBGaWd1cmUgMiBpcyBhIGxpdHRsZSBteXN0ZXJpb3VzIHRvIG1lDQo+ IA0KPiBpZiBJIHNlbmQgeW91IGEgU0lQIHJlcXVlc3Qgd2l0aCBhIGxvY2F0aW9uIFVSSSwgeW91 IG5lZWQgdG8gYmUgYWJsZQ0KPiB0byBkZXJlZmVyZW5jZSBpdCAob3IgYXQgbGVhc3QgdHJ5KSBi ZWZvcmUgeW91IGFjY2VwdCB0aGUgU0lQDQo+IHJlcXVlc3QuIEkga25vdyBpdCdsbCBhZGQgYSBi aXQgb2YgdGltZSB0byB0aGUgMjAwIE9LLCBidXQgdGhhdCB3aWxsDQo+IGFsbG93IGNvbmZpcm1h dGlvbiBvZiBsb2NhdGlvbiBkZWxpZXZlcnkgLSB3aGljaCBpc24ndCB0aGUgbG9jYXRpb24NCj4g VVJJLCBidXQgdGhlIGxvY2F0aW9uIHZhbHVlIGl0c2VsZiAoaS5lLiwgdGhlIFBJREYtTE8pLiBJ ZiB0aGUNCj4gZGVyZWZlcmVuY2UgZmFpbHMgYWZ0ZXIgeW91J3ZlIHNlbnQgbWUgYSAyMDAgT0ss IGhvdyBjYW4geW91IHBvc3NpYmx5DQo+IHRlbGwgbWUgdGhhdCB0aGVyZSB3YXMgc29tZXRoaW5n IHdyb25nIHdpdGggbXkgZGVsaXZlcnkgb2YgbG9jYXRpb24gdG8NCj4geW91Pw0KDQpJIGNhbiBs aXZlIHdpdGggdGhhdC4gIEl0IGFsbCBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIDIwMCBpcyBjb250 aW5nZW50IG9uIGJlaW5nIGFibGUgdG8gZGVyZWZlcmVuY2UuICBJIGltYWdpbmUgdGhhdCBpZiB0 aGlzIGlzIGp1c3QgYSBNRVNTQUdFIGFuZCB0aGUgbG9jYXRpb24gaXNuJ3QgYWN0dWFsbHkgbmVl ZGVkIHRvIHByb2Nlc3MgdGhlIHJlcXVlc3QsIHlvdSBjb3VsZCBzZW5kIHRoZSAyMDAgYmVmb3Jl aGFuZCwgYnV0IHRoZW4geW91IHByb2JhYmx5IGRvbid0IG5lZWQgdGhlIEdlb2xvY2F0aW9uIGhl YWRlciBlaXRoZXIuDQoNCg0K From rbarnes@bbn.com Wed Oct 27 04:59:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611153A6882 for ; Wed, 27 Oct 2010 04:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2rcPI94wfhP for ; Wed, 27 Oct 2010 04:59:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A53233A67CF for ; Wed, 27 Oct 2010 04:59:40 -0700 (PDT) Received: from [128.89.253.125] (port=52636 helo=[192.168.1.15]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PB4h7-00053q-Mw; Wed, 27 Oct 2010 08:01:30 -0400 Message-Id: <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> From: "Richard L. Barnes" To: James M. Polk In-Reply-To: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Oct 2010 08:01:27 -0400 References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:59:42 -0000 Thanks a lot for revising this document. I'm pretty comfortable with the document at this point, but have just one minor question: Why are you still limiting the number of location values? Why are three values harmful, but not two? This still seems like pointless ABNF legislation. --Richard On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > SIPCORE > > I've submitted the next version of Location Conveyance (-04) > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt > and I believe this version has addressed each open item from the > mailing list, as well as what was discussed and agreed to in the > Maastricht meeting. > > I have attempted to identify each open issue with the specific > resolution here (in no particular order): > > - Martin wanted Section 3 to be broken up into subsections, each > revolving around each of the 4 diagrams. I have done this. > > - allowed a maximum of two (up from one) locationValues to be > present in the Geolocation header value. The text however recommends > against inserting a second value. This was agreed to in Maastricht. > > - Because we're allowing a max of two locationValues, they can be in > separate Geolocation headers in the SIP request. This scenario > necessitates bring a previous version's paragraph in stating that a > 'SIP intermediary MUST inspect all instances of each Geolocation > header before considering the routing-allowed parameter to be > considered =yes', to ensure there isn't a conflict in the 'other' > Geolocation header that states the policy is =no. > > - with the ability to add a second locationValue, it is necessary to > warn against doing this (confusion at the LRs). > > - Added the "you break it you bought it" philosophy to SIP > intermediaries that choose to insert a second location where one > already existed, especially for inserting a location URI in the > downstream SIP request. > > - Fixed the ABNF to handle zero, one or two (but no more) > locationValues according to the agreement in Maastricht. There is a > one-off use case which won't be in play very often, but is a WG item > in ECRIT that several wanted to allow the possibility for (involving > allowing one coarse and one highly accurate location in the same SIP > request). > > - Paul K. wanted the use-case in which a SIP intermediary inserts a > locationValue where one didn't exist previously, and received a 424 > (Bad Location Information) to that inserted location, from having > the 424 propagate towards the UAC (as the UAC might not know what to > do with a 424). This is now covered in Section 4.3. > > - changed existing text to "MUST NOT" from "does not" about a 424 > not terminating an existing dialog (just increased the strength of > this. > > - I added the 424 to the table 2 entry in which the Geolocation > header can be in only this response. > > - I added text stating the conditions for adding a Geolocation > header value to the 424, to make it clear what is and what isn't > allowed for this. > > - Martin wanted me to add back in the top level Geolocation-Error > codes 100, 200, 300 and 400, which I did in section 4.3. > > - rejected the idea that the geolocation option-tag hasn't been > justified. > > - Added RFCs 2616, 2818 and HELD Deref ID to the references section > because I added the ability to include HTTP: and HTTPS: URIs, and > stated if received, they should be dereferenced according to the > HELD Deref doc. > > - changed the Section 5 examples how Martin wanted them. > > - Stated that GEO-URIs are not appropriate for the SIP Geolocation > header, according to the discussion during the Maastricht Geopriv > meeting. > > - we changed the privacy section, and included a ref to the Geopriv > Arch doc, according to the agreement in Geopriv at Maastricht. > > > Comments are encouraged > > We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing > (to give folks a sense of our plans). > > James/Brian/Jon > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Oct 27 05:51:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9859D3A69D4 for ; Wed, 27 Oct 2010 05:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM1WAfSvnQSV for ; Wed, 27 Oct 2010 05:51:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 903273A694A for ; Wed, 27 Oct 2010 05:51:53 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,246,1286150400"; d="scan'208";a="175534889" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 12:53:43 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RCrgPC020262; Wed, 27 Oct 2010 12:53:43 GMT Message-ID: <4CC820D6.3090207@cisco.com> Date: Wed, 27 Oct 2010 08:53:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Thomson, Martin" References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:51:54 -0000 I was going to suggest alternative ABNF in my prior posting, but I ran out of time and wanted to send it. So here is a proposal: Geolocation-header = "Geolocation" HCOLON Geolocation-value *( COMMA Geolocation-value) Geolocation-value = locationValue / routing-param locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" This syntax is consistent with 3261 section 7.3: Specifically, any SIP header whose grammar is of the form header = "header-name" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. (That means there is an equivalence between multiple occurrences of the header, and a single header with multiple fields.) (I would prefer to have a separately named header for the routing-param, but I think we are too far down the river to make that change now.) The above is overly forgiving, in that it permits zero or more locationURIs and zero or more routing-params. That then needs to be tightened up with text. I think the text needs to say, more or less: - if there are any locationURIs in a sip request, then a routing-param MUST be present in the request - there MUST NOT be more than one routing-param present in a sip request. - there MUST NOT be more than two locationURIs in a sip request (if there is really a reason for such a restriction) Actually the MUST requirement on the routing-param also seems unmotivated to me. Why not just a default of routing-allowed=no? Thanks, Paul On 10/27/2010 12:06 AM, Thomson, Martin wrote: > On 2010-10-27 at 12:36:02, Paul Kyzivat wrote: >> I have never understood why the routing-param is required to be last. >> And as my examples show, its difficult/impossible to enforce this in >> ABNF. > > If "routing-allowed" is mandatory, it IS possible: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > Geolocation-value = [ locationValue [ COMMA locationValue ] COMMA ] > routing-param > > It's a little strange, but it does work. Especially if you also add text that states there can be only one GeoLocation header? > > (The other thing that I find strange is the fact that there can be zero, one or two locationValue parts. This is confusing for computer scientists who can only count: zero, one, many.) > > --Martin From john.elwell@siemens-enterprise.com Wed Oct 27 06:16:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A543A67FB for ; Wed, 27 Oct 2010 06:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PecL1eqUWS1 for ; Wed, 27 Oct 2010 06:16:07 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3E9AA3A6953 for ; Wed, 27 Oct 2010 06:16:06 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2061133; Wed, 27 Oct 2010 15:17:56 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0123F23F0278; Wed, 27 Oct 2010 15:17:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Oct 2010 15:17:55 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Wed, 27 Oct 2010 15:17:53 +0200 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act1kD0o+0NNpNoSRh6SAAZ/P6L7dwARU08g Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> In-Reply-To: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:16:10 -0000 I am happy to see that http and https are added as schemes in locationURI. = However, looking at 4.6, I am still uncomfortable that SIP-, SIPS- and PRES= -URI are recommended and but HTTP- and HTTPS-URI are not recommended (by vi= rtue of the fact they are only MAY strength, for use when one disregards th= e SHOULD for SIP-, SIPS- and PRES-). We had an earlier thread starting here: http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html in which questions were asked about what one must support. The text in 4.6 = says nothing about what a LR must support. The implication is that it eithe= r has two support all of the 5 schemes listed for sending in a request, or = it can choose which to support and reject any that it doesn't support. In practice, as pointed out on the thread, the schemes effectively boil dow= n to 2 mechanisms: SIP and HTTP (if we for now ignore the absoluteURI optio= n, which effectively leaves it open ended). So perhaps it is not unreasonab= le to mandate support for all 5 schemes (both mechanisms) by a recipient, a= lthough it does raise the bar somewhat for recipient implementations. I rec= all there was some interest on the thread in limiting to a single MUST supp= ort, and some interest in that scheme being HTTP(S). I am not sure we reach= ed consensus on this. I don't have a strong opinion, but we certainly need = some text to clarify things one way or the other. Furthermore, it is unclear which code to use in a 494 response when rejecti= ng an unsupported scheme - presumably the top level 400, but that says noth= ing about why dereference failed. Even if all the named schemes were MUST s= upport (so you would never reject these), there could be other schemes unde= r absoluteURI that you would want to reject. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 27 October 2010 05:32 > To: sipcore@ietf.org > Subject: [sipcore] Location Conveyance -04 submitted, here's=20 > the changes >=20 > SIPCORE >=20 > I've submitted the next version of Location Conveyance (-04) > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-04.txt > and I believe this version has addressed each open item from the=20 > mailing list, as well as what was discussed and agreed to in the=20 > Maastricht meeting. >=20 > I have attempted to identify each open issue with the specific=20 > resolution here (in no particular order): >=20 > - Martin wanted Section 3 to be broken up into subsections, each=20 > revolving around each of the 4 diagrams. I have done this. >=20 > - allowed a maximum of two (up from one) locationValues to be present=20 > in the Geolocation header value. The text however recommends against=20 > inserting a second value. This was agreed to in Maastricht. >=20 > - Because we're allowing a max of two locationValues, they can be in=20 > separate Geolocation headers in the SIP request. This scenario=20 > necessitates bring a previous version's paragraph in stating that a=20 > 'SIP intermediary MUST inspect all instances of each Geolocation=20 > header before considering the routing-allowed parameter to be=20 > considered =3Dyes', to ensure there isn't a conflict in the 'other'=20 > Geolocation header that states the policy is =3Dno. >=20 > - with the ability to add a second locationValue, it is necessary to=20 > warn against doing this (confusion at the LRs). >=20 > - Added the "you break it you bought it" philosophy to SIP=20 > intermediaries that choose to insert a second location where one=20 > already existed, especially for inserting a location URI in the=20 > downstream SIP request. >=20 > - Fixed the ABNF to handle zero, one or two (but no more)=20 > locationValues according to the agreement in Maastricht. There is a=20 > one-off use case which won't be in play very often, but is a WG item=20 > in ECRIT that several wanted to allow the possibility for (involving=20 > allowing one coarse and one highly accurate location in the=20 > same SIP request). >=20 > - Paul K. wanted the use-case in which a SIP intermediary inserts a=20 > locationValue where one didn't exist previously, and received a 424=20 > (Bad Location Information) to that inserted location, from having the=20 > 424 propagate towards the UAC (as the UAC might not know what to do=20 > with a 424). This is now covered in Section 4.3. >=20 > - changed existing text to "MUST NOT" from "does not" about a 424 not=20 > terminating an existing dialog (just increased the strength of this. >=20 > - I added the 424 to the table 2 entry in which the Geolocation=20 > header can be in only this response. >=20 > - I added text stating the conditions for adding a Geolocation header=20 > value to the 424, to make it clear what is and what isn't=20 > allowed for this. >=20 > - Martin wanted me to add back in the top level Geolocation-Error=20 > codes 100, 200, 300 and 400, which I did in section 4.3. >=20 > - rejected the idea that the geolocation option-tag hasn't=20 > been justified. >=20 > - Added RFCs 2616, 2818 and HELD Deref ID to the references section=20 > because I added the ability to include HTTP: and HTTPS: URIs, and=20 > stated if received, they should be dereferenced according to the HELD=20 > Deref doc. >=20 > - changed the Section 5 examples how Martin wanted them. >=20 > - Stated that GEO-URIs are not appropriate for the SIP Geolocation=20 > header, according to the discussion during the Maastricht=20 > Geopriv meeting. >=20 > - we changed the privacy section, and included a ref to the Geopriv=20 > Arch doc, according to the agreement in Geopriv at Maastricht. >=20 >=20 > Comments are encouraged >=20 > We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing=20 > (to give folks a sense of our plans). >=20 > James/Brian/Jon >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From jmpolk@cisco.com Wed Oct 27 11:30:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787793A6844 for ; Wed, 27 Oct 2010 11:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxoa1hJD2qgL for ; Wed, 27 Oct 2010 11:30:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C31F43A6828 for ; Wed, 27 Oct 2010 11:30:20 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="287416747" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2010 18:32:11 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9RIWAKi005558; Wed, 27 Oct 2010 18:32:10 GMT Message-Id: <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 13:32:09 -0500 To: Paul Kyzivat , "James M. Polk (E-mail)" , Jon Peterson From: "James M. Polk" In-Reply-To: <4CC78202.6090700@cisco.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:30:22 -0000 Paul in-line At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >I took a quick look at the new version, and it seems to have cleanup >a lot. But there *still* seems to be a problem with the syntax. >(Interplay between ABNF and text.) From the text, I find: > > The placement of the "routing-allowed" header field parameter, > strongly encouraged by [RFC5606], is outside the locationValue, and > MUST always be last in the header field value. The routing-allowed > parameter MUST be present, even when no locationValue is present. > >This is questionably supported by the ABNF: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > Geolocation-value = ( locationValue [ COMMA locationValue ] ) > / routing-param the above, I believe - but am open to be corrected by those better at ABNF syntax that I, says - the Geolocation header can optionally have one or more locationValues - which are where the location URIs go - but that the Geolocation header *will* have a routing-param - which is the "routing-allowed" paramter that RFC 5606 wanted included The text of the ID then says that only zero, one or two locationValues are allowed, which we all agreed to in Maastricht (in SIPCORE and ECRIT/GEOPRIV). > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" > >It only works if you presume that there are separate occurrences of >GeoLocation-header in the message, one with just locations, another >with just the routing-param. I don't get that part of your point, but I guess Martin's next message says I need to add a "COMMA" after the ']' but before the ')'. Would this satisfy your issue? >The routing-param certainly can't be "last in the header field >value" except in the degenerate sense, since it must be first and >only in a Geolocation-header. If the routing-param was intended to be first, wouldn't it appear first on this line? > Geolocation-value = ( locationValue [ COMMA locationValue ] ) > / routing-param but it doesn't, so I'm confused. >Below are some specific cases - both valid and invalid. In each case >I show some headers bracketed by "...". That is intended to mean >other headers in a message, but all in the same message. (And when I >show multiple headers, there could be other non-geoloc headers interleaved.) > >* The following are legal according to the above, and probably >within expected usage: > >... >Geolocation: cid:foo@example.com >Geolocation: routing-allowed=yes >... > >... >Geolocation: cid:foo@example.com,cid:bar@example.com >Geolocation: routing-allowed=yes >... > >... >Geolocation: routing-allowed=no >... > >* IIUC the following are allowed by the above both syntactically and >according to the text, but is presumably not *intended* to be valid. >(Its legal because the in each instance of Geolocation-header its last.) > >... >Geolocation: routing-allowed=no >Geolocation: routing-allowed=yes >... > >The following is also allowed - I don't know if its intended or not: > >... >Geolocation: routing-allowed=yes >Geolocation: cid:foo@example.com,cid:bar@example.com >... > >* The following is allowed by the ABNF though disallowed by the text: > >... >Geolocation: cid:foo@example.com,cid:bar@example.com >Geolocation: cid:baz@example.com >... > >* The following is *not* allowed by the ABNF. I suspect it might be >intended to be valid, but I'm far from sure about it: > >... >Geolocation: cid:foo@example.com,routing-allowed=yes >... to get this above example "allowed", would I correct the existing ABNF to be > Geolocation-value = ( locationValue [ COMMA locationValue ] COMMA ) > / routing-param ? >In addition to that, the text is very explicit that: > > The routing-allowed > parameter MUST be present, even when no locationValue is present. > >but then it says: > > If no routing-allowed parameter > is present in a SIP request, a SIP intermediary MAY insert this > value with a RECOMMENDED value of "no" by default. > >So its required, but we have rules to follow if its missing. But I >don't understand how it *can* be required, since the sender of the >request may not understand/support Geolocation and so won't include it. What we're trying to do here is explicitly give instructions to SIP intermediary implementers to include the routing-allowed parameter if one isn't present, with a default value of =no. >ISTM that in reality its only *required* if the is a locationValue >present, and is otherwise optional. which is how most would read it if ... > If no routing-allowed parameter > is present in a SIP request, a SIP intermediary MAY insert this > value with a RECOMMENDED value of "no" by default. ... weren't present in the document. But, there is no permission to allow SIP intermediaries to add the routing-allowed parameter, which we wanted to cover. >In that case, an intermediary that adds a locationValue not only >MAY, but presumably MUST add a missing routing-param if it adds a >locationValue. We can get there (i.e., allow this) without stating this is a MUST, can't we? >I have never understood why the routing-param is required to be last. maybe it doesn't need to be, but it certainly is easier for monitoring/reading human to find if it is last when looking at a decode. > And as my examples show, its difficult/impossible to enforce this in ABNF. > > Thanks, > Paul From jmpolk@cisco.com Wed Oct 27 11:34:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560093A6844 for ; Wed, 27 Oct 2010 11:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6pF7Lixk0LT for ; Wed, 27 Oct 2010 11:34:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4C66A3A6828 for ; Wed, 27 Oct 2010 11:34:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="276721575" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2010 18:35:53 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9RIZrDD021639; Wed, 27 Oct 2010 18:35:53 GMT Message-Id: <201010271835.o9RIZrDD021639@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 13:35:52 -0500 To: "Thomson, Martin" , "James M. Polk" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EB10B@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03F31EAF78@SISPE7MB1.commscope.com> <201010270429.o9R4TuCM027015@sj-core-2.cisco.com> <8B0A9FCBB9832F43971E38010638454F03F31EB10B@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location conveyance looks good X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:34:04 -0000 At 12:31 AM 10/27/2010, Thomson, Martin wrote: >On 2010-10-27 at 15:29:55, James M. Polk wrote: > > >and the serial nature Figure 2 is a little mysterious to me > > > > if I send you a SIP request with a location URI, you need to be able > > to dereference it (or at least try) before you accept the SIP > > request. I know it'll add a bit of time to the 200 OK, but that will > > allow confirmation of location delievery - which isn't the location > > URI, but the location value itself (i.e., the PIDF-LO). If the > > dereference fails after you've sent me a 200 OK, how can you possibly > > tell me that there was something wrong with my delivery of location to > > you? > >I can live with that. It all depends on whether the 200 is >contingent on being able to dereference. I imagine that if this is >just a MESSAGE and the location isn't actually needed to process the >request, you could send the 200 beforehand, but then you probably >don't need the Geolocation header either. I'm thinking that's all true james From jmpolk@cisco.com Wed Oct 27 11:34:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018733A6930 for ; Wed, 27 Oct 2010 11:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EgBBmtmaOWr for ; Wed, 27 Oct 2010 11:34:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D43323A6828 for ; Wed, 27 Oct 2010 11:34:04 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="207723811" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2010 18:35:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9RIZNdr021500; Wed, 27 Oct 2010 18:35:23 GMT Message-Id: <201010271835.o9RIZNdr021500@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 13:35:22 -0500 To: "Thomson, Martin" , Paul Kyzivat , "James M. Polk (E-mail)" , Jon Peterson From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.comms cope.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:34:06 -0000 At 11:06 PM 10/26/2010, Thomson, Martin wrote: >On 2010-10-27 at 12:36:02, Paul Kyzivat wrote: > > I have never understood why the routing-param is required to be last. > > And as my examples show, its difficult/impossible to enforce this in > > ABNF. > >If "routing-allowed" is mandatory, it IS possible: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > Geolocation-value = [ locationValue [ COMMA locationValue ] COMMA ] > routing-param > >It's a little strange, but it does work. Especially if you also add >text that states there can be only one GeoLocation header? > >(The other thing that I find strange is the fact that there can be >zero, one or two locationValue parts. The pre-Maastricht proposal was to limit to zero or one locationValue, but that blew up Richard's rough-loc ID (which defines a coarse location for routing, and accurate location for endsystems). This is why we made the compromise of allowing a second locationValue. If we allow 'many', we need to bloat the doc with all that "inserter=" and "inserted-by" crud, and we don't want that, do we? james >This is confusing for computer scientists who can only count: zero, >one, many.) > >--Martin From jmpolk@cisco.com Wed Oct 27 11:37:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EFA3A6910 for ; Wed, 27 Oct 2010 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjLuViYkNQTA for ; Wed, 27 Oct 2010 11:37:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3F4E33A6930 for ; Wed, 27 Oct 2010 11:36:55 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="276723885" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2010 18:38:45 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9RIcjgG008761; Wed, 27 Oct 2010 18:38:45 GMT Message-Id: <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 13:38:44 -0500 To: "Richard L. Barnes" , "James M. Polk" From: "James M. Polk" In-Reply-To: <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:37:09 -0000 At 07:01 AM 10/27/2010, Richard L. Barnes wrote: >Thanks a lot for revising this document. > >I'm pretty comfortable with the document at this point, but have just >one minor question: Why are you still limiting the number of location >values? Why are three values harmful, but not two? This still seems >like pointless ABNF legislation. we only added the ability to have a second locationValue because of your rough-loc ID. Before that, we were firm in not allowing more than one. Given that choice, which do you like? Remember, this was Jon's proposal in SIPCORE in Anaheim, which it seemed everyone and their brother was agreeable with, so ... james >--Richard > > > > >On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > >>SIPCORE >> >>I've submitted the next version of Location Conveyance (-04) >>http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt >>and I believe this version has addressed each open item from the >>mailing list, as well as what was discussed and agreed to in the >>Maastricht meeting. >> >>I have attempted to identify each open issue with the specific >>resolution here (in no particular order): >> >>- Martin wanted Section 3 to be broken up into subsections, each >>revolving around each of the 4 diagrams. I have done this. >> >>- allowed a maximum of two (up from one) locationValues to be >>present in the Geolocation header value. The text however recommends >>against inserting a second value. This was agreed to in Maastricht. >> >>- Because we're allowing a max of two locationValues, they can be in >>separate Geolocation headers in the SIP request. This scenario >>necessitates bring a previous version's paragraph in stating that a >>'SIP intermediary MUST inspect all instances of each Geolocation >>header before considering the routing-allowed parameter to be >>considered =yes', to ensure there isn't a conflict in the 'other' >>Geolocation header that states the policy is =no. >> >>- with the ability to add a second locationValue, it is necessary to >>warn against doing this (confusion at the LRs). >> >>- Added the "you break it you bought it" philosophy to SIP >>intermediaries that choose to insert a second location where one >>already existed, especially for inserting a location URI in the >>downstream SIP request. >> >>- Fixed the ABNF to handle zero, one or two (but no more) >>locationValues according to the agreement in Maastricht. There is a >>one-off use case which won't be in play very often, but is a WG item >>in ECRIT that several wanted to allow the possibility for (involving >>allowing one coarse and one highly accurate location in the same SIP >>request). >> >>- Paul K. wanted the use-case in which a SIP intermediary inserts a >>locationValue where one didn't exist previously, and received a 424 >>(Bad Location Information) to that inserted location, from having >>the 424 propagate towards the UAC (as the UAC might not know what to >>do with a 424). This is now covered in Section 4.3. >> >>- changed existing text to "MUST NOT" from "does not" about a 424 >>not terminating an existing dialog (just increased the strength of >>this. >> >>- I added the 424 to the table 2 entry in which the Geolocation >>header can be in only this response. >> >>- I added text stating the conditions for adding a Geolocation >>header value to the 424, to make it clear what is and what isn't >>allowed for this. >> >>- Martin wanted me to add back in the top level Geolocation-Error >>codes 100, 200, 300 and 400, which I did in section 4.3. >> >>- rejected the idea that the geolocation option-tag hasn't been >>justified. >> >>- Added RFCs 2616, 2818 and HELD Deref ID to the references section >>because I added the ability to include HTTP: and HTTPS: URIs, and >>stated if received, they should be dereferenced according to the >>HELD Deref doc. >> >>- changed the Section 5 examples how Martin wanted them. >> >>- Stated that GEO-URIs are not appropriate for the SIP Geolocation >>header, according to the discussion during the Maastricht Geopriv >>meeting. >> >>- we changed the privacy section, and included a ref to the Geopriv >>Arch doc, according to the agreement in Geopriv at Maastricht. >> >> >>Comments are encouraged >> >>We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing >>(to give folks a sense of our plans). >> >>James/Brian/Jon >> >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Wed Oct 27 11:47:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D583A6855 for ; Wed, 27 Oct 2010 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwRBPKLcJ-vF for ; Wed, 27 Oct 2010 11:47:37 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EA5013A6803 for ; Wed, 27 Oct 2010 11:47:37 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="244626774" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2010 18:49:28 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9RInRNI022354; Wed, 27 Oct 2010 18:49:27 GMT Message-Id: <201010271849.o9RInRNI022354@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 13:49:26 -0500 To: Paul Kyzivat , "Thomson, Martin" From: "James M. Polk" In-Reply-To: <4CC820D6.3090207@cisco.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <8B0A9FCBB9832F43971E38010638454F03F31EB0D7@SISPE7MB1.commscope.com> <4CC820D6.3090207@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:47:41 -0000 At 07:53 AM 10/27/2010, Paul Kyzivat wrote: >I was going to suggest alternative ABNF in my prior posting, but I >ran out of time and wanted to send it. So here is a proposal: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > *( COMMA Geolocation-value) > Geolocation-value = locationValue / routing-param > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" this is what I had before -04, and was told to correct it to what is in -04. I'm getting so many corrections (i.e., what I currently have is considered wrong by someone), I can't tell who's more knowledgeable about this. Paul, since you're WGC, I'm going to go with this until your (or Adam) tell me how to change it. In other words, it has to come through either of you before I change what's in the next version, no matter who tells me (other than my co-conspirators writting this). >This syntax is consistent with 3261 section 7.3: > > Specifically, any SIP header whose grammar is of the form > > header = "header-name" HCOLON header-value *(COMMA header-value) > > allows for combining header fields of the same name into a comma- > separated list. > >(That means there is an equivalence between multiple occurrences of >the header, and a single header with multiple fields.) > >(I would prefer to have a separately named header for the >routing-param, but I think we are too far down the river to make >that change now.) > >The above is overly forgiving, in that it permits zero or more >locationURIs and zero or more routing-params. That then needs to be >tightened up with text. I think the text needs to say, more or less: > >- if there are any locationURIs in a sip request, > then a routing-param MUST be present in the request >- there MUST NOT be more than one routing-param present in a > sip request. >- there MUST NOT be more than two locationURIs in a sip request > (if there is really a reason for such a restriction) > >Actually the MUST requirement on the routing-param also seems >unmotivated to me. Why not just a default of routing-allowed=no? that is the default value already in text, but we want to limit this to avoid any possible misinterpretation which allows a person's (i.e., Target's) location to inadvertently be advertised to any and possibly all 3rd parties. James > Thanks, > Paul > >On 10/27/2010 12:06 AM, Thomson, Martin wrote: >>On 2010-10-27 at 12:36:02, Paul Kyzivat wrote: >>>I have never understood why the routing-param is required to be last. >>>And as my examples show, its difficult/impossible to enforce this in >>>ABNF. >> >>If "routing-allowed" is mandatory, it IS possible: >> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> Geolocation-value = [ locationValue [ COMMA locationValue ] COMMA ] >> routing-param >> >>It's a little strange, but it does work. Especially if you also >>add text that states there can be only one GeoLocation header? >> >>(The other thing that I find strange is the fact that there can be >>zero, one or two locationValue parts. This is confusing for >>computer scientists who can only count: zero, one, many.) >> >>--Martin From jmpolk@cisco.com Wed Oct 27 12:02:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0CB3A682A for ; Wed, 27 Oct 2010 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxmgfRJbFdub for ; Wed, 27 Oct 2010 12:02:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E86AD3A67F9 for ; Wed, 27 Oct 2010 12:02:41 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="610578300" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 19:04:32 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9RJ4WM5009321; Wed, 27 Oct 2010 19:04:32 GMT Message-Id: <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 14:04:31 -0500 To: "Elwell, John" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:02:43 -0000 At 08:17 AM 10/27/2010, Elwell, John wrote: >I am happy to see that http and https are added as schemes in >locationURI. However, looking at 4.6, I am still uncomfortable that >SIP-, SIPS- and PRES-URI are recommended and but HTTP- and HTTPS-URI >are not recommended (by virtue of the fact they are only MAY >strength, for use when one disregards the SHOULD for SIP-, SIPS- and PRES-). well... this is a SIP document, why shouldn't a SIP-based URI be recommended? Do you want me to say HTTP:/HTTPS: is allowed in some other way? >We had an earlier thread starting here: >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html >in which questions were asked about what one must support. The text >in 4.6 says nothing about what a LR must support. The implication is >that it either has two support all of the 5 schemes listed for >sending in a request, or it can choose which to support and reject >any that it doesn't support. right now it is the latter, but I would - if I must - propose making SIP:/SIPS:/PRES: mandatory if there is any URI scheme that is (again, this is a SIP doc). >In practice, as pointed out on the thread, the schemes effectively >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the >absoluteURI option, which effectively leaves it open ended). So >perhaps it is not unreasonable to mandate support for all 5 schemes >(both mechanisms) by a recipient, although it does raise the bar >somewhat for recipient implementations. Several of us have and currently believe that is raising the bar a little too high. >I recall there was some interest on the thread in limiting to a >single MUST support, and some interest in that scheme being HTTP(S). >I am not sure we reached consensus on this. I don't have a strong >opinion, but we certainly need some text to clarify things one way >or the other. > >Furthermore, it is unclear which code to use in a 494 response when >rejecting an unsupported scheme - presumably the top level 400, but >that says nothing about why dereference failed. Even if all the >named schemes were MUST support (so you would never reject these), >there could be other schemes under absoluteURI that you would want to reject. The conclusion from the San Diego adhoc bof on this ID was to limit the number of error types to specific different actionable ones. At that adhoc, I had roughly 22 different error types, one set included the ability to indicate which URI scheme wasn't supported and which ones were. That idea was roundly rejected (most strongly by our newest co-author Jon Peterson). I believe it was Henning (and maybe Hannes) that wanted the error codes limited as well, and to allow this RFC-to-be to be extended with an XML body in the response that included a much more detailed error explanation and ways detailed in how to resolve the problem. No one has written that ID yet, so I don't know where that thought is now. That said, -04 doesn't have a 494 response articulated because location specific rejections are for the 424 (Bad Location Information) response. Jon and I talked just last week about what do we do when an LR supports one URI scheme and receives another URI scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an HTTP:/HTTPS: URI). We couldn't come up with anything that didn't have a lot of holes in it, so we left it for now. James >John > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > Sent: 27 October 2010 05:32 > > To: sipcore@ietf.org > > Subject: [sipcore] Location Conveyance -04 submitted, here's > > the changes > > > > SIPCORE > > > > I've submitted the next version of Location Conveyance (-04) > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > n-conveyance-04.txt > > and I believe this version has addressed each open item from the > > mailing list, as well as what was discussed and agreed to in the > > Maastricht meeting. > > > > I have attempted to identify each open issue with the specific > > resolution here (in no particular order): > > > > - Martin wanted Section 3 to be broken up into subsections, each > > revolving around each of the 4 diagrams. I have done this. > > > > - allowed a maximum of two (up from one) locationValues to be present > > in the Geolocation header value. The text however recommends against > > inserting a second value. This was agreed to in Maastricht. > > > > - Because we're allowing a max of two locationValues, they can be in > > separate Geolocation headers in the SIP request. This scenario > > necessitates bring a previous version's paragraph in stating that a > > 'SIP intermediary MUST inspect all instances of each Geolocation > > header before considering the routing-allowed parameter to be > > considered =yes', to ensure there isn't a conflict in the 'other' > > Geolocation header that states the policy is =no. > > > > - with the ability to add a second locationValue, it is necessary to > > warn against doing this (confusion at the LRs). > > > > - Added the "you break it you bought it" philosophy to SIP > > intermediaries that choose to insert a second location where one > > already existed, especially for inserting a location URI in the > > downstream SIP request. > > > > - Fixed the ABNF to handle zero, one or two (but no more) > > locationValues according to the agreement in Maastricht. There is a > > one-off use case which won't be in play very often, but is a WG item > > in ECRIT that several wanted to allow the possibility for (involving > > allowing one coarse and one highly accurate location in the > > same SIP request). > > > > - Paul K. wanted the use-case in which a SIP intermediary inserts a > > locationValue where one didn't exist previously, and received a 424 > > (Bad Location Information) to that inserted location, from having the > > 424 propagate towards the UAC (as the UAC might not know what to do > > with a 424). This is now covered in Section 4.3. > > > > - changed existing text to "MUST NOT" from "does not" about a 424 not > > terminating an existing dialog (just increased the strength of this. > > > > - I added the 424 to the table 2 entry in which the Geolocation > > header can be in only this response. > > > > - I added text stating the conditions for adding a Geolocation header > > value to the 424, to make it clear what is and what isn't > > allowed for this. > > > > - Martin wanted me to add back in the top level Geolocation-Error > > codes 100, 200, 300 and 400, which I did in section 4.3. > > > > - rejected the idea that the geolocation option-tag hasn't > > been justified. > > > > - Added RFCs 2616, 2818 and HELD Deref ID to the references section > > because I added the ability to include HTTP: and HTTPS: URIs, and > > stated if received, they should be dereferenced according to the HELD > > Deref doc. > > > > - changed the Section 5 examples how Martin wanted them. > > > > - Stated that GEO-URIs are not appropriate for the SIP Geolocation > > header, according to the discussion during the Maastricht > > Geopriv meeting. > > > > - we changed the privacy section, and included a ref to the Geopriv > > Arch doc, according to the agreement in Geopriv at Maastricht. > > > > > > Comments are encouraged > > > > We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing > > (to give folks a sense of our plans). > > > > James/Brian/Jon > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > From dworley@avaya.com Wed Oct 27 12:28:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A083A6912 for ; Wed, 27 Oct 2010 12:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdtjHQ6M4PTj for ; Wed, 27 Oct 2010 12:28:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A9E353A6902 for ; Wed, 27 Oct 2010 12:28:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="215200296" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2010 15:29:48 -0400 X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="533284814" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2010 13:03:43 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 27 Oct 2010 13:03:43 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , Dale Worley Date: Wed, 27 Oct 2010 13:03:42 -0400 Thread-Topic: [sipcore] Reviewers needed for new music-on-hold technique Thread-Index: ActxfyJo/BLSsIMMSF2xmeJDgfhkYwEZ5hb/ Message-ID: References: , <4CC0D91F.7060304@cisco.com> In-Reply-To: <4CC0D91F.7060304@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:28:45 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] [as individual] Obviously the constraint about reusing payload numbers is problematic. I think we should consider the possibility of relaxing it, though I don't know if we can get away with that after the fact or not. ISTM that the fundamental reason for such a constraint is transient. When you have an existing session and then modify it, the change in the signaling and the change in the media packets do not happen synchronously. So when you make the offer you must be ready to receive media based on the new offer while you are still receiving media on the old offer. Similarly for sending. _______________________________________________ You are quite correct about this. But re-reading my draft, I notice that t= he problem is remarkably theoretical: In this case, the UA that does not e= xecute the hold generates an offer to which the MOH server generates an ans= wer. The MOH server sends RTP using the codecs specified in the UA's offer= . Thus, there can be no confusion when the UA decodes the RTP, as the RTP = is being sent based on what the UA specified. The problem is the requireme= nt that the codecs that the MOH server lists in its answer must meet the no= n-reuse requirement (despite that no media will be sent to the MOH server).= In practice I am sure that the hold-executing phone does not need to worr= y about this problem at all. Dale From dworley@avaya.com Wed Oct 27 12:28:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0D23A6981 for ; Wed, 27 Oct 2010 12:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbTF0MLf1VsF for ; Wed, 27 Oct 2010 12:28:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 597AA3A695F for ; Wed, 27 Oct 2010 12:28:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="215200527" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2010 15:29:49 -0400 X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="533323691" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2010 14:16:39 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 27 Oct 2010 14:16:38 -0400 From: "Worley, Dale R (Dale)" To: "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Wed, 27 Oct 2010 14:15:39 -0400 Thread-Topic: [sipcore] Reviewers needed for new music-on-hold technique Thread-Index: AQHLdgMZZsczS6JR/U2+ZkUyPaDLGA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:28:49 -0000 [second attempt to send] ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] [as individual] Obviously the constraint about reusing payload numbers is problematic. I think we should consider the possibility of relaxing it, though I don't know if we can get away with that after the fact or not. ISTM that the fundamental reason for such a constraint is transient. When you have an existing session and then modify it, the change in the signaling and the change in the media packets do not happen synchronously. So when you make the offer you must be ready to receive media based on the new offer while you are still receiving media on the old offer. Similarly for sending. _______________________________________________ You are quite correct about this. But re-reading my draft, I notice that t= he problem is remarkably theoretical: In this case, the UA that does not e= xecute the hold generates an offer to which the MOH server generates an ans= wer. The MOH server sends RTP using the codecs specified in the UA's offer= . Thus, there can be no confusion when the UA decodes the RTP, as the RTP = is being sent based on what the UA specified. The problem is the requireme= nt that the codecs that the MOH server lists in its answer must meet the no= n-reuse requirement (despite that no media will be sent to the MOH server).= In practice I am sure that the hold-executing phone does not need to worr= y about this problem at all. Dale From john.elwell@siemens-enterprise.com Wed Oct 27 12:37:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C453A69C2 for ; Wed, 27 Oct 2010 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS1udD5I8gro for ; Wed, 27 Oct 2010 12:37:33 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 153743A69E2 for ; Wed, 27 Oct 2010 12:37:32 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2067889; Wed, 27 Oct 2010 21:37:38 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 841E41EB82AE; Wed, 27 Oct 2010 21:37:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 27 Oct 2010 21:37:39 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Wed, 27 Oct 2010 21:37:37 +0200 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2CcrUqy/1MXJsT52i31qhdnRsEwAAfKzg Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> In-Reply-To: <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:37:37 -0000 =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 27 October 2010 20:05 > To: Elwell, John; James M. Polk; sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > At 08:17 AM 10/27/2010, Elwell, John wrote: > >I am happy to see that http and https are added as schemes in=20 > >locationURI. However, looking at 4.6, I am still uncomfortable that=20 > >SIP-, SIPS- and PRES-URI are recommended and but HTTP- and HTTPS-URI=20 > >are not recommended (by virtue of the fact they are only MAY=20 > >strength, for use when one disregards the SHOULD for SIP-,=20 > SIPS- and PRES-). >=20 > well... this is a SIP document, why shouldn't a SIP-based URI be=20 > recommended? Do you want me to say HTTP:/HTTPS: is allowed in=20 > some other way? >=20 >=20 > >We had an earlier thread starting here: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html > >in which questions were asked about what one must support. The text=20 > >in 4.6 says nothing about what a LR must support. The implication is=20 > >that it either has two support all of the 5 schemes listed for=20 > >sending in a request, or it can choose which to support and reject=20 > >any that it doesn't support. >=20 > right now it is the latter, but I would - if I must - propose making=20 > SIP:/SIPS:/PRES: mandatory if there is any URI scheme that is (again,=20 > this is a SIP doc). [JRE] But the event package is [ID-GEO-FILTERS] and is based upon RFC 3856,= a SIMPLE document. Not all SIP implementations support SIMPLE. On the othe= r hand, I can see benefits in this (ability to receive notifications when l= ocation changes, plus filters). If the consensus is SIP/SIPS/PRES is the on= ly mandatory one, I can live with it. On re-reading 4.6, I see that, although the text "These schemes MUST be imp= lemented according to this document" is within the paragraph concerning wha= t you SHOULD place in a SIP request, perhaps it is intended to include what= MUST be supported on receipt too, so perhaps it is OK as is, or perhaps it= should say "A location recipient MUST implement these schemes". >=20 >=20 > >In practice, as pointed out on the thread, the schemes effectively=20 > >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the=20 > >absoluteURI option, which effectively leaves it open ended). So=20 > >perhaps it is not unreasonable to mandate support for all 5 schemes=20 > >(both mechanisms) by a recipient, although it does raise the bar=20 > >somewhat for recipient implementations. >=20 > Several of us have and currently believe that is raising the bar a=20 > little too high. >=20 > >I recall there was some interest on the thread in limiting to a=20 > >single MUST support, and some interest in that scheme being HTTP(S).=20 > >I am not sure we reached consensus on this. I don't have a strong=20 > >opinion, but we certainly need some text to clarify things one way=20 > >or the other. > > > >Furthermore, it is unclear which code to use in a 494 response when=20 > >rejecting an unsupported scheme - presumably the top level 400, but=20 > >that says nothing about why dereference failed. Even if all the=20 > >named schemes were MUST support (so you would never reject these),=20 > >there could be other schemes under absoluteURI that you=20 > would want to reject. >=20 > The conclusion from the San Diego adhoc bof on this ID was to limit=20 > the number of error types to specific different actionable ones. At=20 > that adhoc, I had roughly 22 different error types, one set included=20 > the ability to indicate which URI scheme wasn't supported and which=20 > ones were. That idea was roundly rejected (most strongly by our=20 > newest co-author Jon Peterson). I believe it was Henning (and maybe=20 > Hannes) that wanted the error codes limited as well, and to allow=20 > this RFC-to-be to be extended with an XML body in the response that=20 > included a much more detailed error explanation and ways detailed in=20 > how to resolve the problem. >=20 > No one has written that ID yet, so I don't know where that=20 > thought is now. >=20 > That said, -04 doesn't have a 494 response articulated because=20 > location specific rejections are for the 424 (Bad Location=20 > Information) response. Jon and I talked just last week about what do=20 > we do when an LR supports one URI scheme and receives another URI=20 > scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an HTTP:/HTTPS:=20 > URI). We couldn't come up with anything that didn't have a lot of=20 > holes in it, so we left it for now. [JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would you have= if you specified 401, say, as "URI scheme not supported"? I guess one difficulty is what does the UAC do about it, if it doesn't have= the means for obtaining a reference with a different URI. Was that the sor= t of hole you had in mind? John >=20 > James >=20 >=20 > >John > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > > Sent: 27 October 2010 05:32 > > > To: sipcore@ietf.org > > > Subject: [sipcore] Location Conveyance -04 submitted, here's > > > the changes > > > > > > SIPCORE > > > > > > I've submitted the next version of Location Conveyance (-04) > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > n-conveyance-04.txt > > > and I believe this version has addressed each open item from the > > > mailing list, as well as what was discussed and agreed to in the > > > Maastricht meeting. > > > > > > I have attempted to identify each open issue with the specific > > > resolution here (in no particular order): > > > > > > - Martin wanted Section 3 to be broken up into subsections, each > > > revolving around each of the 4 diagrams. I have done this. > > > > > > - allowed a maximum of two (up from one) locationValues=20 > to be present > > > in the Geolocation header value. The text however=20 > recommends against > > > inserting a second value. This was agreed to in Maastricht. > > > > > > - Because we're allowing a max of two locationValues,=20 > they can be in > > > separate Geolocation headers in the SIP request. This scenario > > > necessitates bring a previous version's paragraph in=20 > stating that a > > > 'SIP intermediary MUST inspect all instances of each Geolocation > > > header before considering the routing-allowed parameter to be > > > considered =3Dyes', to ensure there isn't a conflict in the 'other' > > > Geolocation header that states the policy is =3Dno. > > > > > > - with the ability to add a second locationValue, it is=20 > necessary to > > > warn against doing this (confusion at the LRs). > > > > > > - Added the "you break it you bought it" philosophy to SIP > > > intermediaries that choose to insert a second location where one > > > already existed, especially for inserting a location URI in the > > > downstream SIP request. > > > > > > - Fixed the ABNF to handle zero, one or two (but no more) > > > locationValues according to the agreement in Maastricht. =20 > There is a > > > one-off use case which won't be in play very often, but=20 > is a WG item > > > in ECRIT that several wanted to allow the possibility for=20 > (involving > > > allowing one coarse and one highly accurate location in the > > > same SIP request). > > > > > > - Paul K. wanted the use-case in which a SIP intermediary=20 > inserts a > > > locationValue where one didn't exist previously, and=20 > received a 424 > > > (Bad Location Information) to that inserted location,=20 > from having the > > > 424 propagate towards the UAC (as the UAC might not know=20 > what to do > > > with a 424). This is now covered in Section 4.3. > > > > > > - changed existing text to "MUST NOT" from "does not"=20 > about a 424 not > > > terminating an existing dialog (just increased the=20 > strength of this. > > > > > > - I added the 424 to the table 2 entry in which the Geolocation > > > header can be in only this response. > > > > > > - I added text stating the conditions for adding a=20 > Geolocation header > > > value to the 424, to make it clear what is and what isn't > > > allowed for this. > > > > > > - Martin wanted me to add back in the top level Geolocation-Error > > > codes 100, 200, 300 and 400, which I did in section 4.3. > > > > > > - rejected the idea that the geolocation option-tag hasn't > > > been justified. > > > > > > - Added RFCs 2616, 2818 and HELD Deref ID to the=20 > references section > > > because I added the ability to include HTTP: and HTTPS: URIs, and > > > stated if received, they should be dereferenced according=20 > to the HELD > > > Deref doc. > > > > > > - changed the Section 5 examples how Martin wanted them. > > > > > > - Stated that GEO-URIs are not appropriate for the SIP Geolocation > > > header, according to the discussion during the Maastricht > > > Geopriv meeting. > > > > > > - we changed the privacy section, and included a ref to=20 > the Geopriv > > > Arch doc, according to the agreement in Geopriv at Maastricht. > > > > > > > > > Comments are encouraged > > > > > > We plan to request (3rd?) WGLC during the SIPCORE meeting=20 > in Beijing > > > (to give folks a sense of our plans). > > > > > > James/Brian/Jon > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 > = From jmpolk@cisco.com Wed Oct 27 12:56:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCEA3A6981 for ; Wed, 27 Oct 2010 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9p1oaIpwrXq for ; Wed, 27 Oct 2010 12:56:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B85AB3A680A for ; Wed, 27 Oct 2010 12:56:51 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="375093194" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2010 19:58:42 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RJwfg7003382; Wed, 27 Oct 2010 19:58:41 GMT Message-Id: <201010271958.o9RJwfg7003382@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 14:58:40 -0500 To: "Elwell, John" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:56:53 -0000 At 02:37 PM 10/27/2010, Elwell, John wrote: > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 27 October 2010 20:05 > > To: Elwell, John; James M. Polk; sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > At 08:17 AM 10/27/2010, Elwell, John wrote: > > >I am happy to see that http and https are added as schemes in > > >locationURI. However, looking at 4.6, I am still uncomfortable that > > >SIP-, SIPS- and PRES-URI are recommended and but HTTP- and HTTPS-URI > > >are not recommended (by virtue of the fact they are only MAY > > >strength, for use when one disregards the SHOULD for SIP-, > > SIPS- and PRES-). > > > > well... this is a SIP document, why shouldn't a SIP-based URI be > > recommended? Do you want me to say HTTP:/HTTPS: is allowed in > > some other way? > > > > > > >We had an earlier thread starting here: > > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html > > >in which questions were asked about what one must support. The text > > >in 4.6 says nothing about what a LR must support. The implication is > > >that it either has two support all of the 5 schemes listed for > > >sending in a request, or it can choose which to support and reject > > >any that it doesn't support. > > > > right now it is the latter, but I would - if I must - propose making > > SIP:/SIPS:/PRES: mandatory if there is any URI scheme that is (again, > > this is a SIP doc). >[JRE] But the event package is [ID-GEO-FILTERS] and is based upon >RFC 3856, a SIMPLE document. Not all SIP implementations support SIMPLE. [jmp] Yes, but realistically - fewer will support HELD-Deref... >On the other hand, I can see benefits in this (ability to receive >notifications when location changes, plus filters). [jmp] I believe Brian wrote the Filters doc with that in mind (i.e., the benefits). >If the consensus is SIP/SIPS/PRES is the only mandatory one, I can >live with it. > >On re-reading 4.6, I see that, although the text "These schemes MUST >be implemented according to this document" is within the paragraph >concerning what you SHOULD place in a SIP request, perhaps it is >intended to include what MUST be supported on receipt too, so >perhaps it is OK as is, or perhaps it should say "A location >recipient MUST implement these schemes". [jmp] If we end up choosing a mandatory to implement scheme (or scheme set), then I think we can state that receivers MUST implement that scheme (set). [jmp] Do you (or others) believe this should be done regardless of any mandatory to implement sending scheme, or wait until there is a mandatory to implement sending scheme? > > > > > > >In practice, as pointed out on the thread, the schemes effectively > > >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the > > >absoluteURI option, which effectively leaves it open ended). So > > >perhaps it is not unreasonable to mandate support for all 5 schemes > > >(both mechanisms) by a recipient, although it does raise the bar > > >somewhat for recipient implementations. > > > > Several of us have and currently believe that is raising the bar a > > little too high. > > > > >I recall there was some interest on the thread in limiting to a > > >single MUST support, and some interest in that scheme being HTTP(S). > > >I am not sure we reached consensus on this. I don't have a strong > > >opinion, but we certainly need some text to clarify things one way > > >or the other. > > > > > >Furthermore, it is unclear which code to use in a 494 response when > > >rejecting an unsupported scheme - presumably the top level 400, but > > >that says nothing about why dereference failed. Even if all the > > >named schemes were MUST support (so you would never reject these), > > >there could be other schemes under absoluteURI that you > > would want to reject. > > > > The conclusion from the San Diego adhoc bof on this ID was to limit > > the number of error types to specific different actionable ones. At > > that adhoc, I had roughly 22 different error types, one set included > > the ability to indicate which URI scheme wasn't supported and which > > ones were. That idea was roundly rejected (most strongly by our > > newest co-author Jon Peterson). I believe it was Henning (and maybe > > Hannes) that wanted the error codes limited as well, and to allow > > this RFC-to-be to be extended with an XML body in the response that > > included a much more detailed error explanation and ways detailed in > > how to resolve the problem. > > > > No one has written that ID yet, so I don't know where that > > thought is now. > > > > That said, -04 doesn't have a 494 response articulated because > > location specific rejections are for the 424 (Bad Location > > Information) response. Jon and I talked just last week about what do > > we do when an LR supports one URI scheme and receives another URI > > scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an HTTP:/HTTPS: > > URI). We couldn't come up with anything that didn't have a lot of > > holes in it, so we left it for now. >[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would >you have if you specified 401, say, as "URI scheme not >supported"? I guess one difficulty is what does the UAC do about >it, if it doesn't have the means for obtaining a reference with a >different URI. Was that the sort of hole you had in mind? [jmp] Jon and I talked specifically about adding a 401 "URI scheme not supported", but his point was "what does that really tell you?" and I tried to plead that it would mean that this scheme (set) (i.e., SIP based or HTTP based) wasn't supported, and to send the other scheme (set). His counter was that what happens when there is more than one scheme set to choose from, then what does a 401 really mean that a 400 doesn't already? I didn't really have a good answer for that one. In other words, if we're only ever going to have a choice between SIP and HTTP, then the 401 would work. Once you have a 3rd (or more) choice, it all falls apart. The best way around this is to indicate which choice of scheme you want in the 424, perhaps this could become (Jon - don't hyperventilate!) 401 "URI scheme not supported - send SIP:URI" 402 "URI scheme not supported - send SIPS:URI" 403 "URI scheme not supported - send PRES:URI" 404 "URI scheme not supported - send HTTP:URI" 405 "URI scheme not supported - send HTTPS:URI" and just add to the list when someone wants a new URI scheme supported. James >John > > > > > > James > > > > > > >John > > > > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > > > Sent: 27 October 2010 05:32 > > > > To: sipcore@ietf.org > > > > Subject: [sipcore] Location Conveyance -04 submitted, here's > > > > the changes > > > > > > > > SIPCORE > > > > > > > > I've submitted the next version of Location Conveyance (-04) > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > n-conveyance-04.txt > > > > and I believe this version has addressed each open item from the > > > > mailing list, as well as what was discussed and agreed to in the > > > > Maastricht meeting. > > > > > > > > I have attempted to identify each open issue with the specific > > > > resolution here (in no particular order): > > > > > > > > - Martin wanted Section 3 to be broken up into subsections, each > > > > revolving around each of the 4 diagrams. I have done this. > > > > > > > > - allowed a maximum of two (up from one) locationValues > > to be present > > > > in the Geolocation header value. The text however > > recommends against > > > > inserting a second value. This was agreed to in Maastricht. > > > > > > > > - Because we're allowing a max of two locationValues, > > they can be in > > > > separate Geolocation headers in the SIP request. This scenario > > > > necessitates bring a previous version's paragraph in > > stating that a > > > > 'SIP intermediary MUST inspect all instances of each Geolocation > > > > header before considering the routing-allowed parameter to be > > > > considered =yes', to ensure there isn't a conflict in the 'other' > > > > Geolocation header that states the policy is =no. > > > > > > > > - with the ability to add a second locationValue, it is > > necessary to > > > > warn against doing this (confusion at the LRs). > > > > > > > > - Added the "you break it you bought it" philosophy to SIP > > > > intermediaries that choose to insert a second location where one > > > > already existed, especially for inserting a location URI in the > > > > downstream SIP request. > > > > > > > > - Fixed the ABNF to handle zero, one or two (but no more) > > > > locationValues according to the agreement in Maastricht. > > There is a > > > > one-off use case which won't be in play very often, but > > is a WG item > > > > in ECRIT that several wanted to allow the possibility for > > (involving > > > > allowing one coarse and one highly accurate location in the > > > > same SIP request). > > > > > > > > - Paul K. wanted the use-case in which a SIP intermediary > > inserts a > > > > locationValue where one didn't exist previously, and > > received a 424 > > > > (Bad Location Information) to that inserted location, > > from having the > > > > 424 propagate towards the UAC (as the UAC might not know > > what to do > > > > with a 424). This is now covered in Section 4.3. > > > > > > > > - changed existing text to "MUST NOT" from "does not" > > about a 424 not > > > > terminating an existing dialog (just increased the > > strength of this. > > > > > > > > - I added the 424 to the table 2 entry in which the Geolocation > > > > header can be in only this response. > > > > > > > > - I added text stating the conditions for adding a > > Geolocation header > > > > value to the 424, to make it clear what is and what isn't > > > > allowed for this. > > > > > > > > - Martin wanted me to add back in the top level Geolocation-Error > > > > codes 100, 200, 300 and 400, which I did in section 4.3. > > > > > > > > - rejected the idea that the geolocation option-tag hasn't > > > > been justified. > > > > > > > > - Added RFCs 2616, 2818 and HELD Deref ID to the > > references section > > > > because I added the ability to include HTTP: and HTTPS: URIs, and > > > > stated if received, they should be dereferenced according > > to the HELD > > > > Deref doc. > > > > > > > > - changed the Section 5 examples how Martin wanted them. > > > > > > > > - Stated that GEO-URIs are not appropriate for the SIP Geolocation > > > > header, according to the discussion during the Maastricht > > > > Geopriv meeting. > > > > > > > > - we changed the privacy section, and included a ref to > > the Geopriv > > > > Arch doc, according to the agreement in Geopriv at Maastricht. > > > > > > > > > > > > Comments are encouraged > > > > > > > > We plan to request (3rd?) WGLC during the SIPCORE meeting > > in Beijing > > > > (to give folks a sense of our plans). > > > > > > > > James/Brian/Jon > > > > > > > > > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > From pkyzivat@cisco.com Wed Oct 27 13:47:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101003A63D2 for ; Wed, 27 Oct 2010 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCHKfssmKp5Z for ; Wed, 27 Oct 2010 13:47:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FF2F3A63CB for ; Wed, 27 Oct 2010 13:47:26 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK0syEyrRN+J/2dsb2JhbAChRHGkQ5wyhUgEilODCA X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="610631188" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 20:49:16 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9RKnGX2015697; Wed, 27 Oct 2010 20:49:16 GMT Message-ID: <4CC8904B.2080307@cisco.com> Date: Wed, 27 Oct 2010 16:49:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:47:27 -0000 I'm quite sure the constraint isn't there for the pain or benefit of an MOH server. Its a constraint that applies on a single session between a single pair of UAs that are using reINVITE to renegotiate the codec they are using. In that context it makes sense, for one o/a cycle. What doesn't make sense is extending it for the life of the session. Thanks, Paul On 10/27/2010 2:15 PM, Worley, Dale R (Dale) wrote: > [second attempt to send] > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > > [as individual] > > Obviously the constraint about reusing payload numbers is problematic. I > think we should consider the possibility of relaxing it, though I don't > know if we can get away with that after the fact or not. > > ISTM that the fundamental reason for such a constraint is transient. > When you have an existing session and then modify it, the change in the > signaling and the change in the media packets do not happen > synchronously. So when you make the offer you must be ready to receive > media based on the new offer while you are still receiving media on the > old offer. Similarly for sending. > _______________________________________________ > > You are quite correct about this. But re-reading my draft, I notice that the problem is remarkably theoretical: In this case, the UA that does not execute the hold generates an offer to which the MOH server generates an answer. The MOH server sends RTP using the codecs specified in the UA's offer. Thus, there can be no confusion when the UA decodes the RTP, as the RTP is being sent based on what the UA specified. The problem is the requirement that the codecs that the MOH server lists in its answer must meet the non-reuse requirement (despite that no media will be sent to the MOH server). In practice I am sure that the hold-executing phone does not need to worry about this problem at all. > > Dale > From pkyzivat@cisco.com Wed Oct 27 16:48:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5F03A63EC for ; Wed, 27 Oct 2010 16:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmpALx+NatcK for ; Wed, 27 Oct 2010 16:48:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EBACA3A63D2 for ; Wed, 27 Oct 2010 16:48:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,248,1286150400"; d="scan'208";a="175768670" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2010 23:50:29 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9RNoTD6011160; Wed, 27 Oct 2010 23:50:29 GMT Message-ID: <4CC8BAC5.4030005@cisco.com> Date: Wed, 27 Oct 2010 19:50:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "James M. Polk" References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> In-Reply-To: <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 23:48:41 -0000 I have a bunch inline here. This supersedes my earlier suggested ABNF change. On 10/27/2010 2:32 PM, James M. Polk wrote: > Paul > > in-line > > At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >> I took a quick look at the new version, and it seems to have cleanup a >> lot. But there *still* seems to be a problem with the syntax. >> (Interplay between ABNF and text.) From the text, I find: >> >> The placement of the "routing-allowed" header field parameter, >> strongly encouraged by [RFC5606], is outside the locationValue, and >> MUST always be last in the header field value. The routing-allowed >> parameter MUST be present, even when no locationValue is present. >> >> This is questionably supported by the ABNF: >> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> / routing-param > > the above, I believe - but am open to be corrected by those better at > ABNF syntax that I, says > > - the Geolocation header can optionally have one or more locationValues > - which are where the location URIs go The above says *a* Geolocation header can have - one or two locationValues - OR one routing-param (The slash means OR) But it doesn't state that the Geolocation header itself can appear only once. And obviously if the goal is to have a locationValue AND a routing-param in the message, then with the above syntax at least TWO Geolocation headers will be required. > - but that the Geolocation header *will* have a routing-param > - which is the "routing-allowed" paramter that RFC 5606 wanted included Since the slash means OR, it doesn't mean it *will*. > The text of the ID then says that only zero, one or two locationValues > are allowed, which we all agreed to in Maastricht (in SIPCORE and > ECRIT/GEOPRIV). > >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> >> It only works if you presume that there are separate occurrences of >> GeoLocation-header in the message, one with just locations, another >> with just the routing-param. > > I don't get that part of your point, but I guess Martin's next message > says I need to add a "COMMA" after the ']' but before the ')'. Would > this satisfy your issue? Adding the COMMA and removing the slash would require the routing-param, and would separate it from the location-value. But then if you only wanted the routing-param without any locationValues you would have to write: Geolocation:,routing-allowed=no which is at least a bit weird, which I think is what Martin meant. >> The routing-param certainly can't be "last in the header field value" >> except in the degenerate sense, since it must be first and only in a >> Geolocation-header. > > If the routing-param was intended to be first, wouldn't it appear first > on this line? My point was that the syntax as written only allows routing-param by itself in a geolocation-header. E.g. Geolocation:routing-allowed=no It can't share a single Geolocation header with a locationValue. Hence it is *both* first and last in that header. >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> / routing-param > > but it doesn't, so I'm confused. Again, the slash means OR. So you have: Geolocation-value = ( locationValue [ COMMA locationValue ] ) OR Geolocation-value = routing-param (Though you can't write it that way in ABNF. >> Below are some specific cases - both valid and invalid. In each case I >> show some headers bracketed by "...". That is intended to mean other >> headers in a message, but all in the same message. (And when I show >> multiple headers, there could be other non-geoloc headers interleaved.) >> >> * The following are legal according to the above, and probably within >> expected usage: >> >> ... >> Geolocation: cid:foo@example.com >> Geolocation: routing-allowed=yes >> ... >> >> ... >> Geolocation: cid:foo@example.com,cid:bar@example.com >> Geolocation: routing-allowed=yes >> ... >> >> ... >> Geolocation: routing-allowed=no >> ... >> >> * IIUC the following are allowed by the above both syntactically and >> according to the text, but is presumably not *intended* to be valid. >> (Its legal because the in each instance of Geolocation-header its last.) >> >> ... >> Geolocation: routing-allowed=no >> Geolocation: routing-allowed=yes >> ... >> >> The following is also allowed - I don't know if its intended or not: >> >> ... >> Geolocation: routing-allowed=yes >> Geolocation: cid:foo@example.com,cid:bar@example.com >> ... >> >> * The following is allowed by the ABNF though disallowed by the text: >> >> ... >> Geolocation: cid:foo@example.com,cid:bar@example.com >> Geolocation: cid:baz@example.com >> ... >> >> * The following is *not* allowed by the ABNF. I suspect it might be >> intended to be valid, but I'm far from sure about it: >> >> ... >> Geolocation: cid:foo@example.com,routing-allowed=yes >> ... > > to get this above example "allowed", would I correct the existing ABNF > to be > >> Geolocation-value = ( locationValue [ COMMA locationValue ] COMMA ) >> / routing-param > > ? No. *That* would allow all of the following but not the example above: Geolocation: cid:foo@example.com, Geolocation: cid:foo@example.com,cid:bar@example.com, Geolocation: routing-allowed=yes >> In addition to that, the text is very explicit that: >> >> The routing-allowed >> parameter MUST be present, even when no locationValue is present. >> >> but then it says: >> >> If no routing-allowed parameter >> is present in a SIP request, a SIP intermediary MAY insert this >> value with a RECOMMENDED value of "no" by default. >> >> So its required, but we have rules to follow if its missing. But I >> don't understand how it *can* be required, since the sender of the >> request may not understand/support Geolocation and so won't include it. > > What we're trying to do here is explicitly give instructions to SIP > intermediary implementers to include the routing-allowed parameter if > one isn't present, with a default value of =no. I went back and reread the section containing this text. It is in a section explicitly about this header. So on reflection I suppose the "MUST be present" was intended to imply "in the Geolocation *header". I took it to mean "in the request". Requiring it to be in the header only makes sense if there can be at most one header. And then it only makes sense if the syntax is altered to allow both the routing-parameter and the locationValue in the same header. >> ISTM that in reality its only *required* if the is a locationValue >> present, and is otherwise optional. > > which is how most would read it if ... > >> If no routing-allowed parameter >> is present in a SIP request, a SIP intermediary MAY insert this >> value with a RECOMMENDED value of "no" by default. > > ... weren't present in the document. But, there is no permission to > allow SIP intermediaries to add the routing-allowed parameter, which we > wanted to cover. I'm still confused. Let me state what I think you are after: - a request may or may not contain a Geolocation header - a request may not contain more than one Geolocation header - a Geolocation header MUST contain a routing-param - a Geolocation header Must contain zero, one, or two locationValues - you prefer the routing-param to be the last field in the header - a proxy MAY add a Geolocation header if one is not present (in which case it MUST include a routing-param) - a proxy MAY add a locationValue to an existing Geolocation header if it doesn't already have two locationValues. (And I guess it could add two if there initially were none.) And you would like ABNF that is consistent with the above. I'm going to give you some alternatives that should all be syntactically correct. I'll give you one that meets the above, and some others that may be more appealing variations. Then we can see which people prefer. 1) The following tries to meet the requirements I spelled out above: Geolocation-header = "Geolocation" HCOLON Geolocation-value Geolocation-value = locationValue [ COMMA locationValue] COMMA routing-param / routing-param locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" This must be accompanied by text stating that there MUST be at most one Geolocation-header in a request. 2) The following is similar to (1), but allows more than two 'locationValue's Geolocation-header = "Geolocation" HCOLON Geolocation-value Geolocation-value = *(locationValue COMMA) routing-param locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" The same wording is required with it 3) The following is a copy from my earlier posting: Geolocation-header = "Geolocation" HCOLON Geolocation-value *( COMMA Geolocation-value) Geolocation-value = locationValue / routing-param locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" The above is overly forgiving, in that it permits zero or more locationURIs and zero or more routing-params. That then needs to be tightened up with text. I think the text needs to say, more or less: - if there are any locationURIs in a sip request, then a routing-param MUST be present in the request - there MUST NOT be more than one routing-param present in a sip request. - there MUST NOT be more than two locationURIs in a sip request (if there is really a reason for such a restriction) 4) The following is a more radical change: Geolocation-header = "Geolocation" HCOLON locationValue [ COMMA locationValue ] locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) Georouting-header = "Geolocation-Routing" HCOLON ( "yes" / "no" / gen-value ) This one needs to be accompanied by text stating that each of Geolocation-header and Georouting-header may appear at most once in a request, and that if Georouting-header is absent it defaults to "no". 5) A more lenient variant on (4): Geolocation-header = "Geolocation" HCOLON locationValue *( COMMA locationValue ) locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) Georouting-header = "Geolocation-Routing" HCOLON ( "yes" / "no" / gen-value ) This one needs to be accompanied by text stating that Georouting-header may appear at most once in a request, and that if Georouting-header is absent it defaults to "no". (The Geolocation-header can appear zero or more times.) This is only preferred to (4) if more than two locationValues are acceptable. ISTM that once we allowed two, allowing more makes sense, with the same limitations imposed with two - that its up to the recipient to figure out which to use. Of the above, I technically and esthetically prefer (5) - or (4) if the limitation to two URIs is important. I see no reason to *require* the routing-param if the default is understood to be "no". Pragmatically I think I prefer (1) - its the least variation from what has been recently discussed that, IMO, makes any sense. >> In that case, an intermediary that adds a locationValue not only MAY, >> but presumably MUST add a missing routing-param if it adds a >> locationValue. > > We can get there (i.e., allow this) without stating this is a MUST, > can't we? >> I have never understood why the routing-param is required to be last. > > maybe it doesn't need to be, but it certainly is easier for > monitoring/reading human to find if it is last when looking at a decode. > >> And as my examples show, its difficult/impossible to enforce this in >> ABNF. >> >> Thanks, >> Paul > > From jmpolk@cisco.com Wed Oct 27 21:09:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C643A684C for ; Wed, 27 Oct 2010 21:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn6PRPQL8O3O for ; Wed, 27 Oct 2010 21:09:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 27A373A683E for ; Wed, 27 Oct 2010 21:08:53 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,249,1286150400"; d="scan'208";a="276996155" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2010 04:10:44 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9S4AhY6012387; Thu, 28 Oct 2010 04:10:43 GMT Message-Id: <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Oct 2010 23:10:42 -0500 To: Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <4CC8BAC5.4030005@cisco.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 04:09:09 -0000 At 06:50 PM 10/27/2010, Paul Kyzivat wrote: >I have a bunch inline here. I'll say ;-) >This supersedes my earlier suggested ABNF change. ack >On 10/27/2010 2:32 PM, James M. Polk wrote: >>Paul >> >>in-line >> >>At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >>>I took a quick look at the new version, and it seems to have cleanup a >>>lot. But there *still* seems to be a problem with the syntax. >>>(Interplay between ABNF and text.) From the text, I find: >>> >>>The placement of the "routing-allowed" header field parameter, >>>strongly encouraged by [RFC5606], is outside the locationValue, and >>>MUST always be last in the header field value. The routing-allowed >>>parameter MUST be present, even when no locationValue is present. >>> >>>This is questionably supported by the ABNF: >>> >>>Geolocation-header = "Geolocation" HCOLON Geolocation-value >>>Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>>/ routing-param >> >>the above, I believe - but am open to be corrected by those better at >>ABNF syntax that I, says >> >>- the Geolocation header can optionally have one or more locationValues >>- which are where the location URIs go > >The above says *a* Geolocation header can have >- one or two locationValues >- OR one routing-param > >(The slash means OR) > >But it doesn't state that the Geolocation header itself can appear >only once. And obviously if the goal is to have a locationValue AND >a routing-param in the message, then with the above syntax at least >TWO Geolocation headers will be required. > >>- but that the Geolocation header *will* have a routing-param >>- which is the "routing-allowed" paramter that RFC 5606 wanted included > >Since the slash means OR, it doesn't mean it *will*. > >>The text of the ID then says that only zero, one or two locationValues >>are allowed, which we all agreed to in Maastricht (in SIPCORE and >>ECRIT/GEOPRIV). >> >>>locationValue = LAQUOT locationURI RAQUOT >>>*(SEMI geoloc-param) >>>locationURI = sip-URI / sips-URI / pres-URI >>>/ http-URI / HTTPS-URI >>>/ cid-url ; (from RFC 2392) >>>/ absoluteURI ; (from RFC 3261) >>>geoloc-param = generic-param; (from RFC 3261) >>>routing-param = "routing-allowed" EQUAL "yes" / "no" >>> >>>It only works if you presume that there are separate occurrences of >>>GeoLocation-header in the message, one with just locations, another >>>with just the routing-param. >> >>I don't get that part of your point, but I guess Martin's next message >>says I need to add a "COMMA" after the ']' but before the ')'. Would >>this satisfy your issue? > >Adding the COMMA and removing the slash would require the >routing-param, and would separate it from the location-value. But >then if you only wanted the routing-param without any locationValues >you would have to write: > >Geolocation:,routing-allowed=no > >which is at least a bit weird, which I think is what Martin meant. > >>>The routing-param certainly can't be "last in the header field value" >>>except in the degenerate sense, since it must be first and only in a >>>Geolocation-header. >> >>If the routing-param was intended to be first, wouldn't it appear first >>on this line? > >My point was that the syntax as written only allows routing-param by >itself in a geolocation-header. E.g. > >Geolocation:routing-allowed=no > >It can't share a single Geolocation header with a locationValue. >Hence it is *both* first and last in that header. > >>>Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>>/ routing-param >> >>but it doesn't, so I'm confused. > >Again, the slash means OR. So you have: > > Geolocation-value = ( locationValue [ COMMA locationValue ] ) >OR > Geolocation-value = routing-param > >(Though you can't write it that way in ABNF. > >>>Below are some specific cases - both valid and invalid. In each case I >>>show some headers bracketed by "...". That is intended to mean other >>>headers in a message, but all in the same message. (And when I show >>>multiple headers, there could be other non-geoloc headers interleaved.) >>> >>>* The following are legal according to the above, and probably within >>>expected usage: >>> >>>... >>>Geolocation: cid:foo@example.com >>>Geolocation: routing-allowed=yes >>>... >>> >>>... >>>Geolocation: cid:foo@example.com,cid:bar@example.com >>>Geolocation: routing-allowed=yes >>>... >>> >>>... >>>Geolocation: routing-allowed=no >>>... >>> >>>* IIUC the following are allowed by the above both syntactically and >>>according to the text, but is presumably not *intended* to be valid. >>>(Its legal because the in each instance of Geolocation-header its last.) >>> >>>... >>>Geolocation: routing-allowed=no >>>Geolocation: routing-allowed=yes >>>... >>> >>>The following is also allowed - I don't know if its intended or not: >>> >>>... >>>Geolocation: routing-allowed=yes >>>Geolocation: cid:foo@example.com,cid:bar@example.com >>>... >>> >>>* The following is allowed by the ABNF though disallowed by the text: >>> >>>... >>>Geolocation: cid:foo@example.com,cid:bar@example.com >>>Geolocation: cid:baz@example.com >>>... >>> >>>* The following is *not* allowed by the ABNF. I suspect it might be >>>intended to be valid, but I'm far from sure about it: >>> >>>... >>>Geolocation: cid:foo@example.com,routing-allowed=yes >>>... >> >>to get this above example "allowed", would I correct the existing ABNF >>to be >> >>>Geolocation-value = ( locationValue [ COMMA locationValue ] COMMA ) >>>/ routing-param >> >>? > >No. *That* would allow all of the following but not the example above: > > Geolocation: cid:foo@example.com, > Geolocation: cid:foo@example.com,cid:bar@example.com, > Geolocation: routing-allowed=yes > >>>In addition to that, the text is very explicit that: >>> >>>The routing-allowed >>>parameter MUST be present, even when no locationValue is present. >>> >>>but then it says: >>> >>>If no routing-allowed parameter >>>is present in a SIP request, a SIP intermediary MAY insert this >>>value with a RECOMMENDED value of "no" by default. >>> >>>So its required, but we have rules to follow if its missing. But I >>>don't understand how it *can* be required, since the sender of the >>>request may not understand/support Geolocation and so won't include it. >> >>What we're trying to do here is explicitly give instructions to SIP >>intermediary implementers to include the routing-allowed parameter if >>one isn't present, with a default value of =no. > >I went back and reread the section containing this text. It is in a >section explicitly about this header. So on reflection I suppose the >"MUST be present" was intended to imply "in the Geolocation >*header". I took it to mean "in the request". > >Requiring it to be in the header only makes sense if there can be at >most one header. And then it only makes sense if the syntax is >altered to allow both the routing-parameter and the locationValue in >the same header. > >>>ISTM that in reality its only *required* if the is a locationValue >>>present, and is otherwise optional. >> >>which is how most would read it if ... >> >>>If no routing-allowed parameter >>>is present in a SIP request, a SIP intermediary MAY insert this >>>value with a RECOMMENDED value of "no" by default. >> >>... weren't present in the document. But, there is no permission to >>allow SIP intermediaries to add the routing-allowed parameter, which we >>wanted to cover. > >I'm still confused. Let me state what I think you are after: > >- a request may or may not contain a Geolocation header >- a request may not contain more than one Geolocation header of what you have, this one is one I hadn't considered important, but if that gets everything aligned, then I'm all for adding it in. >- a Geolocation header MUST contain a routing-param >- a Geolocation header Must contain zero, one, or two locationValues >- you prefer the routing-param to be the last field in the header >- a proxy MAY add a Geolocation header if one is not present > (in which case it MUST include a routing-param) >- a proxy MAY add a locationValue to an existing Geolocation header > if it doesn't already have two locationValues. (And I guess it > could add two if there initially were none.) > >And you would like ABNF that is consistent with the above. with the one caveat, yes. >I'm going to give you some alternatives that should all be >syntactically correct. I'll give you one that meets the above, and >some others that may be more appealing variations. Then we can see >which people prefer. > >1) The following tries to meet the requirements I spelled out above: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > Geolocation-value = locationValue [ COMMA locationValue] > COMMA routing-param > / routing-param I hadn't even thought that was possible, but seeing it, I'm amazed I didn't try it (i.e., it's another classic "I could've had a v8" moment)... I'm not as smart as you, Paul <:-| > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" > > This must be accompanied by text stating that there MUST be at most > one Geolocation-header in a request. you've sold me on this one (and yes, I examined all the others before jumping on this first one!). Do others have strong opinions about why not #1? thank you for this! James >2) The following is similar to (1), but allows more than two > 'locationValue's > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > Geolocation-value = *(locationValue COMMA) routing-param > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" > > The same wording is required with it > >3) The following is a copy from my earlier posting: > > Geolocation-header = "Geolocation" HCOLON Geolocation-value > *( COMMA Geolocation-value) > Geolocation-value = locationValue / routing-param > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" > > The above is overly forgiving, in that it permits zero or more > locationURIs and zero or more routing-params. That then needs to be > tightened up with text. I think the text needs to say, more or less: > > - if there are any locationURIs in a sip request, > then a routing-param MUST be present in the request > - there MUST NOT be more than one routing-param present in a > sip request. > - there MUST NOT be more than two locationURIs in a sip request > (if there is really a reason for such a restriction) > >4) The following is a more radical change: > > Geolocation-header = "Geolocation" HCOLON locationValue > [ COMMA locationValue ] > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > > Georouting-header = "Geolocation-Routing" HCOLON > ( "yes" / "no" / gen-value ) > > This one needs to be accompanied by text stating that each of > Geolocation-header and Georouting-header may appear at most once > in a request, and that if Georouting-header is absent it defaults > to "no". > >5) A more lenient variant on (4): > > Geolocation-header = "Geolocation" HCOLON locationValue > *( COMMA locationValue ) > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > > Georouting-header = "Geolocation-Routing" HCOLON > ( "yes" / "no" / gen-value ) > > This one needs to be accompanied by text stating that > Georouting-header may appear at most once in a request, and that > if Georouting-header is absent it defaults to "no". > > (The Geolocation-header can appear zero or more times.) > > This is only preferred to (4) if more than two locationValues > are acceptable. ISTM that once we allowed two, allowing more > makes sense, with the same limitations imposed with two - that > its up to the recipient to figure out which to use. > >Of the above, I technically and esthetically prefer (5) - or (4) if >the limitation to two URIs is important. I see no reason to >*require* the routing-param if the default is understood to be "no". > >Pragmatically I think I prefer (1) - its the least variation from >what has been recently discussed that, IMO, makes any sense. > > >>>In that case, an intermediary that adds a locationValue not only MAY, >>>but presumably MUST add a missing routing-param if it adds a >>>locationValue. >> >>We can get there (i.e., allow this) without stating this is a MUST, >>can't we? > >>>I have never understood why the routing-param is required to be last. >> >>maybe it doesn't need to be, but it certainly is easier for >>monitoring/reading human to find if it is last when looking at a decode. >> >>>And as my examples show, its difficult/impossible to enforce this in >>>ABNF. >>> >>>Thanks, >>>Paul >> From ankriste@cisco.com Wed Oct 27 21:51:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADA53A6842 for ; Wed, 27 Oct 2010 21:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtBeX6lLUTRf for ; Wed, 27 Oct 2010 21:50:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AB1493A683B for ; Wed, 27 Oct 2010 21:50:46 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE+eyEyrR7Hu/2dsb2JhbAChRXGjOZwghUgEhFeFfIMI X-IronPort-AV: E=Sophos;i="4.58,249,1286150400"; d="scan'208";a="610757560" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2010 04:52:37 +0000 Received: from [10.21.64.117] (sjc-vpn3-117.cisco.com [10.21.64.117]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9S4qbFa015402 for ; Thu, 28 Oct 2010 04:52:37 GMT Message-ID: <4CC90195.2070203@cisco.com> Date: Wed, 27 Oct 2010 21:52:37 -0700 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> In-Reply-To: <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 04:51:06 -0000 I haven't really followed the discussion closely but I'll say this anyway. Many header fields are of a form similar to Geolocation, essentially lists of URI, and allow for parameters. But I think the parameters are pretty much always associated with individual entries in the list and may be present for more than one. From what I can tell, in the case of Geolocation, the routing-allowed param is not really attached to any particular entry in the list suggesting that maybe it doesn't belong in the same header field. I think that's the thinking that lead Paul to options 4 or 5 which seem much preferable to me. That allows Geolocation to fit the text in RFC 3261 that talks about combining header fields: Specifically, any SIP header whose grammar is of the form header = "header-name" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. Granted, there's no rule that says that header fields with comma-separated values *must* fit the above grammar but ISTM that it's a pretty established pattern which is worth observing. Thanks, Anders On 10/27/2010 9:10 PM, James M. Polk wrote: > At 06:50 PM 10/27/2010, Paul Kyzivat wrote: >> I have a bunch inline here. > > I'll say ;-) > >> This supersedes my earlier suggested ABNF change. > > ack > > >> On 10/27/2010 2:32 PM, James M. Polk wrote: >>> Paul >>> >>> in-line >>> >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >>>> I took a quick look at the new version, and it seems to have cleanup a >>>> lot. But there *still* seems to be a problem with the syntax. >>>> (Interplay between ABNF and text.) From the text, I find: >>>> >>>> The placement of the "routing-allowed" header field parameter, >>>> strongly encouraged by [RFC5606], is outside the locationValue, and >>>> MUST always be last in the header field value. The routing-allowed >>>> parameter MUST be present, even when no locationValue is present. >>>> >>>> This is questionably supported by the ABNF: >>>> >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>>> / routing-param >>> >>> the above, I believe - but am open to be corrected by those better at >>> ABNF syntax that I, says >>> >>> - the Geolocation header can optionally have one or more locationValues >>> - which are where the location URIs go >> >> The above says *a* Geolocation header can have >> - one or two locationValues >> - OR one routing-param >> >> (The slash means OR) >> >> But it doesn't state that the Geolocation header itself can appear >> only once. And obviously if the goal is to have a locationValue AND a >> routing-param in the message, then with the above syntax at least TWO >> Geolocation headers will be required. >> >>> - but that the Geolocation header *will* have a routing-param >>> - which is the "routing-allowed" paramter that RFC 5606 wanted included >> >> Since the slash means OR, it doesn't mean it *will*. >> >>> The text of the ID then says that only zero, one or two locationValues >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and >>> ECRIT/GEOPRIV). >>> >>>> locationValue = LAQUOT locationURI RAQUOT >>>> *(SEMI geoloc-param) >>>> locationURI = sip-URI / sips-URI / pres-URI >>>> / http-URI / HTTPS-URI >>>> / cid-url ; (from RFC 2392) >>>> / absoluteURI ; (from RFC 3261) >>>> geoloc-param = generic-param; (from RFC 3261) >>>> routing-param = "routing-allowed" EQUAL "yes" / "no" >>>> >>>> It only works if you presume that there are separate occurrences of >>>> GeoLocation-header in the message, one with just locations, another >>>> with just the routing-param. >>> >>> I don't get that part of your point, but I guess Martin's next message >>> says I need to add a "COMMA" after the ']' but before the ')'. Would >>> this satisfy your issue? >> >> Adding the COMMA and removing the slash would require the >> routing-param, and would separate it from the location-value. But then >> if you only wanted the routing-param without any locationValues you >> would have to write: >> >> Geolocation:,routing-allowed=no >> >> which is at least a bit weird, which I think is what Martin meant. >> >>>> The routing-param certainly can't be "last in the header field value" >>>> except in the degenerate sense, since it must be first and only in a >>>> Geolocation-header. >>> >>> If the routing-param was intended to be first, wouldn't it appear first >>> on this line? >> >> My point was that the syntax as written only allows routing-param by >> itself in a geolocation-header. E.g. >> >> Geolocation:routing-allowed=no >> >> It can't share a single Geolocation header with a locationValue. Hence >> it is *both* first and last in that header. >> >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>>> / routing-param >>> >>> but it doesn't, so I'm confused. >> >> Again, the slash means OR. So you have: >> >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> OR >> Geolocation-value = routing-param >> >> (Though you can't write it that way in ABNF. >> >>>> Below are some specific cases - both valid and invalid. In each case I >>>> show some headers bracketed by "...". That is intended to mean other >>>> headers in a message, but all in the same message. (And when I show >>>> multiple headers, there could be other non-geoloc headers interleaved.) >>>> >>>> * The following are legal according to the above, and probably within >>>> expected usage: >>>> >>>> ... >>>> Geolocation: cid:foo@example.com >>>> Geolocation: routing-allowed=yes >>>> ... >>>> >>>> ... >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>>> Geolocation: routing-allowed=yes >>>> ... >>>> >>>> ... >>>> Geolocation: routing-allowed=no >>>> ... >>>> >>>> * IIUC the following are allowed by the above both syntactically and >>>> according to the text, but is presumably not *intended* to be valid. >>>> (Its legal because the in each instance of Geolocation-header its >>>> last.) >>>> >>>> ... >>>> Geolocation: routing-allowed=no >>>> Geolocation: routing-allowed=yes >>>> ... >>>> >>>> The following is also allowed - I don't know if its intended or not: >>>> >>>> ... >>>> Geolocation: routing-allowed=yes >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>>> ... >>>> >>>> * The following is allowed by the ABNF though disallowed by the text: >>>> >>>> ... >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>>> Geolocation: cid:baz@example.com >>>> ... >>>> >>>> * The following is *not* allowed by the ABNF. I suspect it might be >>>> intended to be valid, but I'm far from sure about it: >>>> >>>> ... >>>> Geolocation: cid:foo@example.com,routing-allowed=yes >>>> ... >>> >>> to get this above example "allowed", would I correct the existing ABNF >>> to be >>> >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] COMMA ) >>>> / routing-param >>> >>> ? >> >> No. *That* would allow all of the following but not the example above: >> >> Geolocation: cid:foo@example.com, >> Geolocation: cid:foo@example.com,cid:bar@example.com, >> Geolocation: routing-allowed=yes >> >>>> In addition to that, the text is very explicit that: >>>> >>>> The routing-allowed >>>> parameter MUST be present, even when no locationValue is present. >>>> >>>> but then it says: >>>> >>>> If no routing-allowed parameter >>>> is present in a SIP request, a SIP intermediary MAY insert this >>>> value with a RECOMMENDED value of "no" by default. >>>> >>>> So its required, but we have rules to follow if its missing. But I >>>> don't understand how it *can* be required, since the sender of the >>>> request may not understand/support Geolocation and so won't include it. >>> >>> What we're trying to do here is explicitly give instructions to SIP >>> intermediary implementers to include the routing-allowed parameter if >>> one isn't present, with a default value of =no. >> >> I went back and reread the section containing this text. It is in a >> section explicitly about this header. So on reflection I suppose the >> "MUST be present" was intended to imply "in the Geolocation *header". >> I took it to mean "in the request". >> >> Requiring it to be in the header only makes sense if there can be at >> most one header. And then it only makes sense if the syntax is altered >> to allow both the routing-parameter and the locationValue in the same >> header. >> >>>> ISTM that in reality its only *required* if the is a locationValue >>>> present, and is otherwise optional. >>> >>> which is how most would read it if ... >>> >>>> If no routing-allowed parameter >>>> is present in a SIP request, a SIP intermediary MAY insert this >>>> value with a RECOMMENDED value of "no" by default. >>> >>> ... weren't present in the document. But, there is no permission to >>> allow SIP intermediaries to add the routing-allowed parameter, which we >>> wanted to cover. >> >> I'm still confused. Let me state what I think you are after: >> >> - a request may or may not contain a Geolocation header >> - a request may not contain more than one Geolocation header > > of what you have, this one is one I hadn't considered important, but if > that gets everything aligned, then I'm all for adding it in. > >> - a Geolocation header MUST contain a routing-param >> - a Geolocation header Must contain zero, one, or two locationValues >> - you prefer the routing-param to be the last field in the header >> - a proxy MAY add a Geolocation header if one is not present >> (in which case it MUST include a routing-param) >> - a proxy MAY add a locationValue to an existing Geolocation header >> if it doesn't already have two locationValues. (And I guess it >> could add two if there initially were none.) >> >> And you would like ABNF that is consistent with the above. > > with the one caveat, yes. > > >> I'm going to give you some alternatives that should all be >> syntactically correct. I'll give you one that meets the above, and >> some others that may be more appealing variations. Then we can see >> which people prefer. >> >> 1) The following tries to meet the requirements I spelled out above: >> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> Geolocation-value = locationValue [ COMMA locationValue] >> COMMA routing-param >> / routing-param > > I hadn't even thought that was possible, but seeing it, I'm amazed I > didn't try it > > (i.e., it's another classic "I could've had a v8" moment)... > > I'm not as smart as you, Paul <:-| > >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> >> This must be accompanied by text stating that there MUST be at most >> one Geolocation-header in a request. > > you've sold me on this one (and yes, I examined all the others before > jumping on this first one!). Do others have strong opinions about why > not #1? > > thank you for this! > > James > > >> 2) The following is similar to (1), but allows more than two >> 'locationValue's >> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> Geolocation-value = *(locationValue COMMA) routing-param >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> >> The same wording is required with it >> >> 3) The following is a copy from my earlier posting: >> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> *( COMMA Geolocation-value) >> Geolocation-value = locationValue / routing-param >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> >> The above is overly forgiving, in that it permits zero or more >> locationURIs and zero or more routing-params. That then needs to be >> tightened up with text. I think the text needs to say, more or less: >> >> - if there are any locationURIs in a sip request, >> then a routing-param MUST be present in the request >> - there MUST NOT be more than one routing-param present in a >> sip request. >> - there MUST NOT be more than two locationURIs in a sip request >> (if there is really a reason for such a restriction) >> >> 4) The following is a more radical change: >> >> Geolocation-header = "Geolocation" HCOLON locationValue >> [ COMMA locationValue ] >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> >> Georouting-header = "Geolocation-Routing" HCOLON >> ( "yes" / "no" / gen-value ) >> >> This one needs to be accompanied by text stating that each of >> Geolocation-header and Georouting-header may appear at most once >> in a request, and that if Georouting-header is absent it defaults >> to "no". >> >> 5) A more lenient variant on (4): >> >> Geolocation-header = "Geolocation" HCOLON locationValue >> *( COMMA locationValue ) >> locationValue = LAQUOT locationURI RAQUOT >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / http-URI / HTTPS-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> geoloc-param = generic-param; (from RFC 3261) >> >> Georouting-header = "Geolocation-Routing" HCOLON >> ( "yes" / "no" / gen-value ) >> >> This one needs to be accompanied by text stating that >> Georouting-header may appear at most once in a request, and that >> if Georouting-header is absent it defaults to "no". >> >> (The Geolocation-header can appear zero or more times.) >> >> This is only preferred to (4) if more than two locationValues >> are acceptable. ISTM that once we allowed two, allowing more >> makes sense, with the same limitations imposed with two - that >> its up to the recipient to figure out which to use. >> >> Of the above, I technically and esthetically prefer (5) - or (4) if >> the limitation to two URIs is important. I see no reason to *require* >> the routing-param if the default is understood to be "no". >> >> Pragmatically I think I prefer (1) - its the least variation from what >> has been recently discussed that, IMO, makes any sense. >> >> >>>> In that case, an intermediary that adds a locationValue not only MAY, >>>> but presumably MUST add a missing routing-param if it adds a >>>> locationValue. >>> >>> We can get there (i.e., allow this) without stating this is a MUST, >>> can't we? >> >>>> I have never understood why the routing-param is required to be last. >>> >>> maybe it doesn't need to be, but it certainly is easier for >>> monitoring/reading human to find if it is last when looking at a decode. >>> >>>> And as my examples show, its difficult/impossible to enforce this in >>>> ABNF. >>>> >>>> Thanks, >>>> Paul >>> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Wed Oct 27 23:22:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD773A6831 for ; Wed, 27 Oct 2010 23:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgdJvM5umEDo for ; Wed, 27 Oct 2010 23:22:39 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CD8B93A683C for ; Wed, 27 Oct 2010 23:21:50 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2070906; Thu, 28 Oct 2010 08:23:28 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9E03323F0278; Thu, 28 Oct 2010 08:23:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Oct 2010 08:23:28 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Thu, 28 Oct 2010 08:23:25 +0200 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2EWI/qR5WcNPRTPqwBH50e7AoYAAVTo6g Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> <201010271958.o9RJwfg7003382@sj-core-1.cisco.com> In-Reply-To: <201010271958.o9RJwfg7003382@sj-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 06:22:41 -0000 =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 27 October 2010 20:59 > To: Elwell, John; James M. Polk; sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > At 02:37 PM 10/27/2010, Elwell, John wrote: > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 27 October 2010 20:05 > > > To: Elwell, John; James M. Polk; sipcore@ietf.org > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > > here's the changes > > > > > > At 08:17 AM 10/27/2010, Elwell, John wrote: > > > >I am happy to see that http and https are added as schemes in > > > >locationURI. However, looking at 4.6, I am still=20 > uncomfortable that > > > >SIP-, SIPS- and PRES-URI are recommended and but HTTP-=20 > and HTTPS-URI > > > >are not recommended (by virtue of the fact they are only MAY > > > >strength, for use when one disregards the SHOULD for SIP-, > > > SIPS- and PRES-). > > > > > > well... this is a SIP document, why shouldn't a SIP-based URI be > > > recommended? Do you want me to say HTTP:/HTTPS: is allowed in > > > some other way? > > > > > > > > > >We had an earlier thread starting here: > > >=20 > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html > > > >in which questions were asked about what one must=20 > support. The text > > > >in 4.6 says nothing about what a LR must support. The=20 > implication is > > > >that it either has two support all of the 5 schemes listed for > > > >sending in a request, or it can choose which to support=20 > and reject > > > >any that it doesn't support. > > > > > > right now it is the latter, but I would - if I must -=20 > propose making > > > SIP:/SIPS:/PRES: mandatory if there is any URI scheme=20 > that is (again, > > > this is a SIP doc). > >[JRE] But the event package is [ID-GEO-FILTERS] and is based upon=20 > >RFC 3856, a SIMPLE document. Not all SIP implementations=20 > support SIMPLE. >=20 > [jmp] Yes, but realistically - fewer will support HELD-Deref... >=20 > >On the other hand, I can see benefits in this (ability to receive=20 > >notifications when location changes, plus filters). >=20 > [jmp] I believe Brian wrote the Filters doc with that in mind (i.e.,=20 > the benefits). >=20 > >If the consensus is SIP/SIPS/PRES is the only mandatory one, I can=20 > >live with it. > > > >On re-reading 4.6, I see that, although the text "These schemes MUST=20 > >be implemented according to this document" is within the paragraph=20 > >concerning what you SHOULD place in a SIP request, perhaps it is=20 > >intended to include what MUST be supported on receipt too, so=20 > >perhaps it is OK as is, or perhaps it should say "A location=20 > >recipient MUST implement these schemes". >=20 > [jmp] If we end up choosing a mandatory to implement scheme (or=20 > scheme set), then I think we can state that receivers MUST implement=20 > that scheme (set). >=20 > [jmp] Do you (or others) believe this should be done regardless of=20 > any mandatory to implement sending scheme, or wait until there is a=20 > mandatory to implement sending scheme? [JRE] What we want to achieve is that there is a certain group of schemes (= one or more) that, if sent by the sender, will be supported by any receiver= that supports location-conveyance. Assuming the WG settles on SIP/SIPS/PRE= S as that group of schemes, I think the present words get quite close to wh= at we require. However, as I mention above, the paragraph talks about schem= es to send in the request, so there is some ambiguity as to whether the "MU= ST be supported" includes receipt or not. Hence my proposed word change abo= ve. >=20 >=20 > > > > > > > > > >In practice, as pointed out on the thread, the schemes=20 > effectively > > > >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the > > > >absoluteURI option, which effectively leaves it open ended). So > > > >perhaps it is not unreasonable to mandate support for=20 > all 5 schemes > > > >(both mechanisms) by a recipient, although it does raise the bar > > > >somewhat for recipient implementations. > > > > > > Several of us have and currently believe that is raising the bar a > > > little too high. > > > > > > >I recall there was some interest on the thread in limiting to a > > > >single MUST support, and some interest in that scheme=20 > being HTTP(S). > > > >I am not sure we reached consensus on this. I don't have a strong > > > >opinion, but we certainly need some text to clarify=20 > things one way > > > >or the other. > > > > > > > >Furthermore, it is unclear which code to use in a 494=20 > response when > > > >rejecting an unsupported scheme - presumably the top=20 > level 400, but > > > >that says nothing about why dereference failed. Even if all the > > > >named schemes were MUST support (so you would never=20 > reject these), > > > >there could be other schemes under absoluteURI that you > > > would want to reject. > > > > > > The conclusion from the San Diego adhoc bof on this ID=20 > was to limit > > > the number of error types to specific different=20 > actionable ones. At > > > that adhoc, I had roughly 22 different error types, one=20 > set included > > > the ability to indicate which URI scheme wasn't supported=20 > and which > > > ones were. That idea was roundly rejected (most strongly by our > > > newest co-author Jon Peterson). I believe it was Henning=20 > (and maybe > > > Hannes) that wanted the error codes limited as well, and to allow > > > this RFC-to-be to be extended with an XML body in the=20 > response that > > > included a much more detailed error explanation and ways=20 > detailed in > > > how to resolve the problem. > > > > > > No one has written that ID yet, so I don't know where that > > > thought is now. > > > > > > That said, -04 doesn't have a 494 response articulated because > > > location specific rejections are for the 424 (Bad Location > > > Information) response. Jon and I talked just last week=20 > about what do > > > we do when an LR supports one URI scheme and receives another URI > > > scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an=20 > HTTP:/HTTPS: > > > URI). We couldn't come up with anything that didn't have a lot of > > > holes in it, so we left it for now. > >[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would=20 > >you have if you specified 401, say, as "URI scheme not=20 > >supported"? I guess one difficulty is what does the UAC do about=20 > >it, if it doesn't have the means for obtaining a reference with a=20 > >different URI. Was that the sort of hole you had in mind? >=20 > [jmp] Jon and I talked specifically about adding a 401 "URI scheme=20 > not supported", but his point was "what does that really tell you?"=20 > and I tried to plead that it would mean that this scheme (set) (i.e.,=20 > SIP based or HTTP based) wasn't supported, and to send the other=20 > scheme (set). His counter was that what happens when there is more=20 > than one scheme set to choose from, then what does a 401 really mean=20 > that a 400 doesn't already? I didn't really have a good answer for=20 > that one. In other words, if we're only ever going to have a choice=20 > between SIP and HTTP, then the 401 would work. Once you have a 3rd=20 > (or more) choice, it all falls apart. [JRE] I would say that there would be a distinction between 401 (I don't kn= ow how to deal with that scheme because I don't support it) and 400 (which = would include things like error response to the SIP/HTTP request, or derefe= rence yielded a location that I couldn't interpret (unless that is a 100), = etc.). John >=20 > The best way around this is to indicate which choice of scheme you=20 > want in the 424, perhaps this could become (Jon - don't=20 > hyperventilate!) >=20 > 401 "URI scheme not supported - send SIP:URI" > 402 "URI scheme not supported - send SIPS:URI" > 403 "URI scheme not supported - send PRES:URI" > 404 "URI scheme not supported - send HTTP:URI" > 405 "URI scheme not supported - send HTTPS:URI" >=20 > and just add to the list when someone wants a new URI scheme=20 > supported. >=20 > James >=20 >=20 > >John > > > > > > > > > > James > > > > > > > > > >John > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > > > > Sent: 27 October 2010 05:32 > > > > > To: sipcore@ietf.org > > > > > Subject: [sipcore] Location Conveyance -04 submitted, here's > > > > > the changes > > > > > > > > > > SIPCORE > > > > > > > > > > I've submitted the next version of Location Conveyance (-04) > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > > n-conveyance-04.txt > > > > > and I believe this version has addressed each open=20 > item from the > > > > > mailing list, as well as what was discussed and=20 > agreed to in the > > > > > Maastricht meeting. > > > > > > > > > > I have attempted to identify each open issue with the specific > > > > > resolution here (in no particular order): > > > > > > > > > > - Martin wanted Section 3 to be broken up into=20 > subsections, each > > > > > revolving around each of the 4 diagrams. I have done this. > > > > > > > > > > - allowed a maximum of two (up from one) locationValues > > > to be present > > > > > in the Geolocation header value. The text however > > > recommends against > > > > > inserting a second value. This was agreed to in Maastricht. > > > > > > > > > > - Because we're allowing a max of two locationValues, > > > they can be in > > > > > separate Geolocation headers in the SIP request. This scenario > > > > > necessitates bring a previous version's paragraph in > > > stating that a > > > > > 'SIP intermediary MUST inspect all instances of each=20 > Geolocation > > > > > header before considering the routing-allowed parameter to be > > > > > considered =3Dyes', to ensure there isn't a conflict in=20 > the 'other' > > > > > Geolocation header that states the policy is =3Dno. > > > > > > > > > > - with the ability to add a second locationValue, it is > > > necessary to > > > > > warn against doing this (confusion at the LRs). > > > > > > > > > > - Added the "you break it you bought it" philosophy to SIP > > > > > intermediaries that choose to insert a second=20 > location where one > > > > > already existed, especially for inserting a location=20 > URI in the > > > > > downstream SIP request. > > > > > > > > > > - Fixed the ABNF to handle zero, one or two (but no more) > > > > > locationValues according to the agreement in Maastricht. > > > There is a > > > > > one-off use case which won't be in play very often, but > > > is a WG item > > > > > in ECRIT that several wanted to allow the possibility for > > > (involving > > > > > allowing one coarse and one highly accurate location in the > > > > > same SIP request). > > > > > > > > > > - Paul K. wanted the use-case in which a SIP intermediary > > > inserts a > > > > > locationValue where one didn't exist previously, and > > > received a 424 > > > > > (Bad Location Information) to that inserted location, > > > from having the > > > > > 424 propagate towards the UAC (as the UAC might not know > > > what to do > > > > > with a 424). This is now covered in Section 4.3. > > > > > > > > > > - changed existing text to "MUST NOT" from "does not" > > > about a 424 not > > > > > terminating an existing dialog (just increased the > > > strength of this. > > > > > > > > > > - I added the 424 to the table 2 entry in which the=20 > Geolocation > > > > > header can be in only this response. > > > > > > > > > > - I added text stating the conditions for adding a > > > Geolocation header > > > > > value to the 424, to make it clear what is and what isn't > > > > > allowed for this. > > > > > > > > > > - Martin wanted me to add back in the top level=20 > Geolocation-Error > > > > > codes 100, 200, 300 and 400, which I did in section 4.3. > > > > > > > > > > - rejected the idea that the geolocation option-tag hasn't > > > > > been justified. > > > > > > > > > > - Added RFCs 2616, 2818 and HELD Deref ID to the > > > references section > > > > > because I added the ability to include HTTP: and=20 > HTTPS: URIs, and > > > > > stated if received, they should be dereferenced according > > > to the HELD > > > > > Deref doc. > > > > > > > > > > - changed the Section 5 examples how Martin wanted them. > > > > > > > > > > - Stated that GEO-URIs are not appropriate for the=20 > SIP Geolocation > > > > > header, according to the discussion during the Maastricht > > > > > Geopriv meeting. > > > > > > > > > > - we changed the privacy section, and included a ref to > > > the Geopriv > > > > > Arch doc, according to the agreement in Geopriv at Maastricht. > > > > > > > > > > > > > > > Comments are encouraged > > > > > > > > > > We plan to request (3rd?) WGLC during the SIPCORE meeting > > > in Beijing > > > > > (to give folks a sense of our plans). > > > > > > > > > > James/Brian/Jon > > > > > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > >=20 > = From john.elwell@siemens-enterprise.com Thu Oct 28 03:36:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78513A684D for ; Thu, 28 Oct 2010 03:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYGJ6uDbOYzH for ; Thu, 28 Oct 2010 03:36:28 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C997F3A6849 for ; Thu, 28 Oct 2010 03:36:27 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2073516; Thu, 28 Oct 2010 12:38:18 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 0FCB31EB82AE; Thu, 28 Oct 2010 12:38:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Oct 2010 12:38:17 +0200 From: "Elwell, John" To: Anders Kristensen , "sipcore@ietf.org" Date: Thu, 28 Oct 2010 12:38:16 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-04 Thread-Index: Act2XAJFxdRpBLt8R+uum2ClOd+jKgAL/5TQ Message-ID: References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> <4CC90195.2070203@cisco.com> In-Reply-To: <4CC90195.2070203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:36:31 -0000 Yes, 4 looks good, but I could live with 1. John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Anders Kristensen > Sent: 28 October 2010 05:53 > To: sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 > > I haven't really followed the discussion closely but I'll say this > anyway. Many header fields are of a form similar to Geolocation, > essentially lists of URI, and allow for parameters. But I think the > parameters are pretty much always associated with individual > entries in > the list and may be present for more than one. > > From what I can tell, in the case of Geolocation, the > routing-allowed > param is not really attached to any particular entry in the list > suggesting that maybe it doesn't belong in the same header field. I > think that's the thinking that lead Paul to options 4 or 5 which seem > much preferable to me. That allows Geolocation to fit the text in RFC > 3261 that talks about combining header fields: > > Specifically, any SIP > header whose grammar is of the form > > header =3D "header-name" HCOLON header-value *(COMMA > header-value) > > allows for combining header fields of the same name into a comma- > separated list. > > Granted, there's no rule that says that header fields with > comma-separated values *must* fit the above grammar but ISTM > that it's a > pretty established pattern which is worth observing. > > Thanks, > Anders > > On 10/27/2010 9:10 PM, James M. Polk wrote: > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote: > >> I have a bunch inline here. > > > > I'll say ;-) > > > >> This supersedes my earlier suggested ABNF change. > > > > ack > > > > > >> On 10/27/2010 2:32 PM, James M. Polk wrote: > >>> Paul > >>> > >>> in-line > >>> > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote: > >>>> I took a quick look at the new version, and it seems to > have cleanup a > >>>> lot. But there *still* seems to be a problem with the syntax. > >>>> (Interplay between ABNF and text.) From the text, I find: > >>>> > >>>> The placement of the "routing-allowed" header field parameter, > >>>> strongly encouraged by [RFC5606], is outside the > locationValue, and > >>>> MUST always be last in the header field value. The > routing-allowed > >>>> parameter MUST be present, even when no locationValue is present. > >>>> > >>>> This is questionably supported by the ABNF: > >>>> > >>>> Geolocation-header =3D "Geolocation" HCOLON Geolocation-value > >>>> Geolocation-value =3D ( locationValue [ COMMA locationValue ] ) > >>>> / routing-param > >>> > >>> the above, I believe - but am open to be corrected by > those better at > >>> ABNF syntax that I, says > >>> > >>> - the Geolocation header can optionally have one or more > locationValues > >>> - which are where the location URIs go > >> > >> The above says *a* Geolocation header can have > >> - one or two locationValues > >> - OR one routing-param > >> > >> (The slash means OR) > >> > >> But it doesn't state that the Geolocation header itself can appear > >> only once. And obviously if the goal is to have a > locationValue AND a > >> routing-param in the message, then with the above syntax > at least TWO > >> Geolocation headers will be required. > >> > >>> - but that the Geolocation header *will* have a routing-param > >>> - which is the "routing-allowed" paramter that RFC 5606 > wanted included > >> > >> Since the slash means OR, it doesn't mean it *will*. > >> > >>> The text of the ID then says that only zero, one or two > locationValues > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and > >>> ECRIT/GEOPRIV). > >>> > >>>> locationValue =3D LAQUOT locationURI RAQUOT > >>>> *(SEMI geoloc-param) > >>>> locationURI =3D sip-URI / sips-URI / pres-URI > >>>> / http-URI / HTTPS-URI > >>>> / cid-url ; (from RFC 2392) > >>>> / absoluteURI ; (from RFC 3261) > >>>> geoloc-param =3D generic-param; (from RFC 3261) > >>>> routing-param =3D "routing-allowed" EQUAL "yes" / "no" > >>>> > >>>> It only works if you presume that there are separate > occurrences of > >>>> GeoLocation-header in the message, one with just > locations, another > >>>> with just the routing-param. > >>> > >>> I don't get that part of your point, but I guess Martin's > next message > >>> says I need to add a "COMMA" after the ']' but before the > ')'. Would > >>> this satisfy your issue? > >> > >> Adding the COMMA and removing the slash would require the > >> routing-param, and would separate it from the > location-value. But then > >> if you only wanted the routing-param without any locationValues you > >> would have to write: > >> > >> Geolocation:,routing-allowed=3Dno > >> > >> which is at least a bit weird, which I think is what Martin meant. > >> > >>>> The routing-param certainly can't be "last in the header > field value" > >>>> except in the degenerate sense, since it must be first > and only in a > >>>> Geolocation-header. > >>> > >>> If the routing-param was intended to be first, wouldn't > it appear first > >>> on this line? > >> > >> My point was that the syntax as written only allows > routing-param by > >> itself in a geolocation-header. E.g. > >> > >> Geolocation:routing-allowed=3Dno > >> > >> It can't share a single Geolocation header with a > locationValue. Hence > >> it is *both* first and last in that header. > >> > >>>> Geolocation-value =3D ( locationValue [ COMMA locationValue ] ) > >>>> / routing-param > >>> > >>> but it doesn't, so I'm confused. > >> > >> Again, the slash means OR. So you have: > >> > >> Geolocation-value =3D ( locationValue [ COMMA locationValue ] ) > >> OR > >> Geolocation-value =3D routing-param > >> > >> (Though you can't write it that way in ABNF. > >> > >>>> Below are some specific cases - both valid and invalid. > In each case I > >>>> show some headers bracketed by "...". That is intended > to mean other > >>>> headers in a message, but all in the same message. (And > when I show > >>>> multiple headers, there could be other non-geoloc > headers interleaved.) > >>>> > >>>> * The following are legal according to the above, and > probably within > >>>> expected usage: > >>>> > >>>> ... > >>>> Geolocation: cid:foo@example.com > >>>> Geolocation: routing-allowed=3Dyes > >>>> ... > >>>> > >>>> ... > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > >>>> Geolocation: routing-allowed=3Dyes > >>>> ... > >>>> > >>>> ... > >>>> Geolocation: routing-allowed=3Dno > >>>> ... > >>>> > >>>> * IIUC the following are allowed by the above both > syntactically and > >>>> according to the text, but is presumably not *intended* > to be valid. > >>>> (Its legal because the in each instance of Geolocation-header its > >>>> last.) > >>>> > >>>> ... > >>>> Geolocation: routing-allowed=3Dno > >>>> Geolocation: routing-allowed=3Dyes > >>>> ... > >>>> > >>>> The following is also allowed - I don't know if its > intended or not: > >>>> > >>>> ... > >>>> Geolocation: routing-allowed=3Dyes > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > >>>> ... > >>>> > >>>> * The following is allowed by the ABNF though disallowed > by the text: > >>>> > >>>> ... > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > >>>> Geolocation: cid:baz@example.com > >>>> ... > >>>> > >>>> * The following is *not* allowed by the ABNF. I suspect > it might be > >>>> intended to be valid, but I'm far from sure about it: > >>>> > >>>> ... > >>>> Geolocation: cid:foo@example.com,routing-allowed=3Dyes > >>>> ... > >>> > >>> to get this above example "allowed", would I correct the > existing ABNF > >>> to be > >>> > >>>> Geolocation-value =3D ( locationValue [ COMMA > locationValue ] COMMA ) > >>>> / routing-param > >>> > >>> ? > >> > >> No. *That* would allow all of the following but not the > example above: > >> > >> Geolocation: cid:foo@example.com, > >> Geolocation: cid:foo@example.com,cid:bar@example.com, > >> Geolocation: routing-allowed=3Dyes > >> > >>>> In addition to that, the text is very explicit that: > >>>> > >>>> The routing-allowed > >>>> parameter MUST be present, even when no locationValue is present. > >>>> > >>>> but then it says: > >>>> > >>>> If no routing-allowed parameter > >>>> is present in a SIP request, a SIP intermediary MAY insert this > >>>> value with a RECOMMENDED value of "no" by default. > >>>> > >>>> So its required, but we have rules to follow if its > missing. But I > >>>> don't understand how it *can* be required, since the > sender of the > >>>> request may not understand/support Geolocation and so > won't include it. > >>> > >>> What we're trying to do here is explicitly give > instructions to SIP > >>> intermediary implementers to include the routing-allowed > parameter if > >>> one isn't present, with a default value of =3Dno. > >> > >> I went back and reread the section containing this text. It is in a > >> section explicitly about this header. So on reflection I > suppose the > >> "MUST be present" was intended to imply "in the > Geolocation *header". > >> I took it to mean "in the request". > >> > >> Requiring it to be in the header only makes sense if there > can be at > >> most one header. And then it only makes sense if the > syntax is altered > >> to allow both the routing-parameter and the locationValue > in the same > >> header. > >> > >>>> ISTM that in reality its only *required* if the is a > locationValue > >>>> present, and is otherwise optional. > >>> > >>> which is how most would read it if ... > >>> > >>>> If no routing-allowed parameter > >>>> is present in a SIP request, a SIP intermediary MAY insert this > >>>> value with a RECOMMENDED value of "no" by default. > >>> > >>> ... weren't present in the document. But, there is no > permission to > >>> allow SIP intermediaries to add the routing-allowed > parameter, which we > >>> wanted to cover. > >> > >> I'm still confused. Let me state what I think you are after: > >> > >> - a request may or may not contain a Geolocation header > >> - a request may not contain more than one Geolocation header > > > > of what you have, this one is one I hadn't considered > important, but if > > that gets everything aligned, then I'm all for adding it in. > > > >> - a Geolocation header MUST contain a routing-param > >> - a Geolocation header Must contain zero, one, or two > locationValues > >> - you prefer the routing-param to be the last field in the header > >> - a proxy MAY add a Geolocation header if one is not present > >> (in which case it MUST include a routing-param) > >> - a proxy MAY add a locationValue to an existing Geolocation header > >> if it doesn't already have two locationValues. (And I guess it > >> could add two if there initially were none.) > >> > >> And you would like ABNF that is consistent with the above. > > > > with the one caveat, yes. > > > > > >> I'm going to give you some alternatives that should all be > >> syntactically correct. I'll give you one that meets the above, and > >> some others that may be more appealing variations. Then we can see > >> which people prefer. > >> > >> 1) The following tries to meet the requirements I spelled > out above: > >> > >> Geolocation-header =3D "Geolocation" HCOLON Geolocation-value > >> Geolocation-value =3D locationValue [ COMMA locationValue] > >> COMMA routing-param > >> / routing-param > > > > I hadn't even thought that was possible, but seeing it, I'm amazed I > > didn't try it > > > > (i.e., it's another classic "I could've had a v8" moment)... > > > > I'm not as smart as you, Paul <:-| > > > >> locationValue =3D LAQUOT locationURI RAQUOT > >> *(SEMI geoloc-param) > >> locationURI =3D sip-URI / sips-URI / pres-URI > >> / http-URI / HTTPS-URI > >> / cid-url ; (from RFC 2392) > >> / absoluteURI ; (from RFC 3261) > >> geoloc-param =3D generic-param; (from RFC 3261) > >> routing-param =3D "routing-allowed" EQUAL "yes" / "no" > >> > >> This must be accompanied by text stating that there MUST be at most > >> one Geolocation-header in a request. > > > > you've sold me on this one (and yes, I examined all the > others before > > jumping on this first one!). Do others have strong opinions > about why > > not #1? > > > > thank you for this! > > > > James > > > > > >> 2) The following is similar to (1), but allows more than two > >> 'locationValue's > >> > >> Geolocation-header =3D "Geolocation" HCOLON Geolocation-value > >> Geolocation-value =3D *(locationValue COMMA) routing-param > >> locationValue =3D LAQUOT locationURI RAQUOT > >> *(SEMI geoloc-param) > >> locationURI =3D sip-URI / sips-URI / pres-URI > >> / http-URI / HTTPS-URI > >> / cid-url ; (from RFC 2392) > >> / absoluteURI ; (from RFC 3261) > >> geoloc-param =3D generic-param; (from RFC 3261) > >> routing-param =3D "routing-allowed" EQUAL "yes" / "no" > >> > >> The same wording is required with it > >> > >> 3) The following is a copy from my earlier posting: > >> > >> Geolocation-header =3D "Geolocation" HCOLON Geolocation-value > >> *( COMMA Geolocation-value) > >> Geolocation-value =3D locationValue / routing-param > >> locationValue =3D LAQUOT locationURI RAQUOT > >> *(SEMI geoloc-param) > >> locationURI =3D sip-URI / sips-URI / pres-URI > >> / http-URI / HTTPS-URI > >> / cid-url ; (from RFC 2392) > >> / absoluteURI ; (from RFC 3261) > >> geoloc-param =3D generic-param; (from RFC 3261) > >> routing-param =3D "routing-allowed" EQUAL "yes" / "no" > >> > >> The above is overly forgiving, in that it permits zero or more > >> locationURIs and zero or more routing-params. That then needs to be > >> tightened up with text. I think the text needs to say, > more or less: > >> > >> - if there are any locationURIs in a sip request, > >> then a routing-param MUST be present in the request > >> - there MUST NOT be more than one routing-param present in a > >> sip request. > >> - there MUST NOT be more than two locationURIs in a sip request > >> (if there is really a reason for such a restriction) > >> > >> 4) The following is a more radical change: > >> > >> Geolocation-header =3D "Geolocation" HCOLON locationValue > >> [ COMMA locationValue ] > >> locationValue =3D LAQUOT locationURI RAQUOT > >> *(SEMI geoloc-param) > >> locationURI =3D sip-URI / sips-URI / pres-URI > >> / http-URI / HTTPS-URI > >> / cid-url ; (from RFC 2392) > >> / absoluteURI ; (from RFC 3261) > >> geoloc-param =3D generic-param; (from RFC 3261) > >> > >> Georouting-header =3D "Geolocation-Routing" HCOLON > >> ( "yes" / "no" / gen-value ) > >> > >> This one needs to be accompanied by text stating that each of > >> Geolocation-header and Georouting-header may appear at most once > >> in a request, and that if Georouting-header is absent it defaults > >> to "no". > >> > >> 5) A more lenient variant on (4): > >> > >> Geolocation-header =3D "Geolocation" HCOLON locationValue > >> *( COMMA locationValue ) > >> locationValue =3D LAQUOT locationURI RAQUOT > >> *(SEMI geoloc-param) > >> locationURI =3D sip-URI / sips-URI / pres-URI > >> / http-URI / HTTPS-URI > >> / cid-url ; (from RFC 2392) > >> / absoluteURI ; (from RFC 3261) > >> geoloc-param =3D generic-param; (from RFC 3261) > >> > >> Georouting-header =3D "Geolocation-Routing" HCOLON > >> ( "yes" / "no" / gen-value ) > >> > >> This one needs to be accompanied by text stating that > >> Georouting-header may appear at most once in a request, and that > >> if Georouting-header is absent it defaults to "no". > >> > >> (The Geolocation-header can appear zero or more times.) > >> > >> This is only preferred to (4) if more than two locationValues > >> are acceptable. ISTM that once we allowed two, allowing more > >> makes sense, with the same limitations imposed with two - that > >> its up to the recipient to figure out which to use. > >> > >> Of the above, I technically and esthetically prefer (5) - or (4) if > >> the limitation to two URIs is important. I see no reason > to *require* > >> the routing-param if the default is understood to be "no". > >> > >> Pragmatically I think I prefer (1) - its the least > variation from what > >> has been recently discussed that, IMO, makes any sense. > >> > >> > >>>> In that case, an intermediary that adds a locationValue > not only MAY, > >>>> but presumably MUST add a missing routing-param if it adds a > >>>> locationValue. > >>> > >>> We can get there (i.e., allow this) without stating this > is a MUST, > >>> can't we? > >> > >>>> I have never understood why the routing-param is > required to be last. > >>> > >>> maybe it doesn't need to be, but it certainly is easier for > >>> monitoring/reading human to find if it is last when > looking at a decode. > >>> > >>>> And as my examples show, its difficult/impossible to > enforce this in > >>>> ABNF. > >>>> > >>>> Thanks, > >>>> Paul > >>> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rbarnes@bbn.com Thu Oct 28 05:17:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067423A6887 for ; Thu, 28 Oct 2010 05:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9z7Lf5IcUHe for ; Thu, 28 Oct 2010 05:16:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7FDFA3A689E for ; Thu, 28 Oct 2010 05:16:58 -0700 (PDT) Received: from [128.89.253.149] (port=54818 helo=[192.168.1.15]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PBRRR-0001Sg-HI; Thu, 28 Oct 2010 08:18:50 -0400 Message-Id: <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> From: "Richard L. Barnes" To: James M. Polk In-Reply-To: <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Oct 2010 08:18:48 -0400 References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 12:17:00 -0000 >> I'm pretty comfortable with the document at this point, but have just >> one minor question: Why are you still limiting the number of location >> values? Why are three values harmful, but not two? This still seems >> like pointless ABNF legislation. > > we only added the ability to have a second locationValue because of > your rough-loc ID. Before that, we were firm in not allowing more > than one. Given that choice, which do you like? > > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it > seemed everyone and their brother was agreeable with, so ... As I recall, the proposal was to just remove the limit on the number of locations values, not to bump it up by one. From the minutes: "Restore Geolocation header that has multiple URIs, even though we would not recommend it. Entities inserting persence are responsbile for any resulting errors. The header parameters distinguishing URIs would not be added back in." At least in my mind, multiple != 2. --Richard > james > > >> --Richard >> >> >> >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: >> >>> SIPCORE >>> >>> I've submitted the next version of Location Conveyance (-04) >>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt >>> and I believe this version has addressed each open item from the >>> mailing list, as well as what was discussed and agreed to in the >>> Maastricht meeting. >>> >>> I have attempted to identify each open issue with the specific >>> resolution here (in no particular order): >>> >>> - Martin wanted Section 3 to be broken up into subsections, each >>> revolving around each of the 4 diagrams. I have done this. >>> >>> - allowed a maximum of two (up from one) locationValues to be >>> present in the Geolocation header value. The text however recommends >>> against inserting a second value. This was agreed to in Maastricht. >>> >>> - Because we're allowing a max of two locationValues, they can be in >>> separate Geolocation headers in the SIP request. This scenario >>> necessitates bring a previous version's paragraph in stating that a >>> 'SIP intermediary MUST inspect all instances of each Geolocation >>> header before considering the routing-allowed parameter to be >>> considered =yes', to ensure there isn't a conflict in the 'other' >>> Geolocation header that states the policy is =no. >>> >>> - with the ability to add a second locationValue, it is necessary to >>> warn against doing this (confusion at the LRs). >>> >>> - Added the "you break it you bought it" philosophy to SIP >>> intermediaries that choose to insert a second location where one >>> already existed, especially for inserting a location URI in the >>> downstream SIP request. >>> >>> - Fixed the ABNF to handle zero, one or two (but no more) >>> locationValues according to the agreement in Maastricht. There is a >>> one-off use case which won't be in play very often, but is a WG item >>> in ECRIT that several wanted to allow the possibility for (involving >>> allowing one coarse and one highly accurate location in the same SIP >>> request). >>> >>> - Paul K. wanted the use-case in which a SIP intermediary inserts a >>> locationValue where one didn't exist previously, and received a 424 >>> (Bad Location Information) to that inserted location, from having >>> the 424 propagate towards the UAC (as the UAC might not know what to >>> do with a 424). This is now covered in Section 4.3. >>> >>> - changed existing text to "MUST NOT" from "does not" about a 424 >>> not terminating an existing dialog (just increased the strength of >>> this. >>> >>> - I added the 424 to the table 2 entry in which the Geolocation >>> header can be in only this response. >>> >>> - I added text stating the conditions for adding a Geolocation >>> header value to the 424, to make it clear what is and what isn't >>> allowed for this. >>> >>> - Martin wanted me to add back in the top level Geolocation-Error >>> codes 100, 200, 300 and 400, which I did in section 4.3. >>> >>> - rejected the idea that the geolocation option-tag hasn't been >>> justified. >>> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the references section >>> because I added the ability to include HTTP: and HTTPS: URIs, and >>> stated if received, they should be dereferenced according to the >>> HELD Deref doc. >>> >>> - changed the Section 5 examples how Martin wanted them. >>> >>> - Stated that GEO-URIs are not appropriate for the SIP Geolocation >>> header, according to the discussion during the Maastricht Geopriv >>> meeting. >>> >>> - we changed the privacy section, and included a ref to the Geopriv >>> Arch doc, according to the agreement in Geopriv at Maastricht. >>> >>> >>> Comments are encouraged >>> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing >>> (to give folks a sense of our plans). >>> >>> James/Brian/Jon >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Thu Oct 28 06:00:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356793A69CB for ; Thu, 28 Oct 2010 06:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.244 X-Spam-Level: X-Spam-Status: No, score=-105.244 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb8bhI71GbEY for ; Thu, 28 Oct 2010 06:00:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id A6CC33A69BF for ; Thu, 28 Oct 2010 06:00:14 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9SCtuB3007397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 15:01:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 28 Oct 2010 15:01:08 +0200 From: "DRAGE, Keith (Keith)" To: "Richard L. Barnes" , "James M. Polk" Date: Thu, 28 Oct 2010 15:01:07 +0200 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtw Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> In-Reply-To: <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 13:00:16 -0000 To be more specific - we had a document that allowed multiple locations. It= was reduced to one without any decision in that direction being made by th= e working group. It needs to go back to multiple values. In my view there are clear use cases where multiple values are required. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes > Sent: Thursday, October 28, 2010 1:19 PM > To: James M. Polk > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > >> I'm pretty comfortable with the document at this point,=20 > but have just=20 > >> one minor question: Why are you still limiting the number=20 > of location=20 > >> values? Why are three values harmful, but not two? This=20 > still seems=20 > >> like pointless ABNF legislation. > > > > we only added the ability to have a second locationValue because of=20 > > your rough-loc ID. Before that, we were firm in not=20 > allowing more than=20 > > one. Given that choice, which do you like? > > > > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it=20 > > seemed everyone and their brother was agreeable with, so ... >=20 >=20 > As I recall, the proposal was to just remove the limit on the number =20 > of locations values, not to bump it up by one. From the minutes: >=20 > "Restore Geolocation header that has multiple URIs, even though we =20 > would not recommend it. Entities inserting persence are responsbile =20 > for any resulting errors. The header parameters distinguishing URIs =20 > would not be added back in." >=20 > At least in my mind, multiple !=3D 2. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > james > > > > > >> --Richard > >> > >> > >> > >> > >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > >> > >>> SIPCORE > >>> > >>> I've submitted the next version of Location Conveyance (-04) > >>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-04.txt > >>> and I believe this version has addressed each open item from the > >>> mailing list, as well as what was discussed and agreed to in the > >>> Maastricht meeting. > >>> > >>> I have attempted to identify each open issue with the specific > >>> resolution here (in no particular order): > >>> > >>> - Martin wanted Section 3 to be broken up into subsections, each > >>> revolving around each of the 4 diagrams. I have done this. > >>> > >>> - allowed a maximum of two (up from one) locationValues to be > >>> present in the Geolocation header value. The text however=20 > recommends > >>> against inserting a second value. This was agreed to in=20 > Maastricht. > >>> > >>> - Because we're allowing a max of two locationValues,=20 > they can be in > >>> separate Geolocation headers in the SIP request. This scenario > >>> necessitates bring a previous version's paragraph in=20 > stating that a > >>> 'SIP intermediary MUST inspect all instances of each Geolocation > >>> header before considering the routing-allowed parameter to be > >>> considered =3Dyes', to ensure there isn't a conflict in the 'other' > >>> Geolocation header that states the policy is =3Dno. > >>> > >>> - with the ability to add a second locationValue, it is=20 > necessary to > >>> warn against doing this (confusion at the LRs). > >>> > >>> - Added the "you break it you bought it" philosophy to SIP > >>> intermediaries that choose to insert a second location where one > >>> already existed, especially for inserting a location URI in the > >>> downstream SIP request. > >>> > >>> - Fixed the ABNF to handle zero, one or two (but no more) > >>> locationValues according to the agreement in Maastricht. =20 > There is a > >>> one-off use case which won't be in play very often, but=20 > is a WG item > >>> in ECRIT that several wanted to allow the possibility for=20 > (involving > >>> allowing one coarse and one highly accurate location in=20 > the same SIP > >>> request). > >>> > >>> - Paul K. wanted the use-case in which a SIP intermediary=20 > inserts a > >>> locationValue where one didn't exist previously, and=20 > received a 424 > >>> (Bad Location Information) to that inserted location, from having > >>> the 424 propagate towards the UAC (as the UAC might not=20 > know what to > >>> do with a 424). This is now covered in Section 4.3. > >>> > >>> - changed existing text to "MUST NOT" from "does not" about a 424 > >>> not terminating an existing dialog (just increased the strength of > >>> this. > >>> > >>> - I added the 424 to the table 2 entry in which the Geolocation > >>> header can be in only this response. > >>> > >>> - I added text stating the conditions for adding a Geolocation > >>> header value to the 424, to make it clear what is and what isn't > >>> allowed for this. > >>> > >>> - Martin wanted me to add back in the top level Geolocation-Error > >>> codes 100, 200, 300 and 400, which I did in section 4.3. > >>> > >>> - rejected the idea that the geolocation option-tag hasn't been > >>> justified. > >>> > >>> - Added RFCs 2616, 2818 and HELD Deref ID to the=20 > references section > >>> because I added the ability to include HTTP: and HTTPS: URIs, and > >>> stated if received, they should be dereferenced according to the > >>> HELD Deref doc. > >>> > >>> - changed the Section 5 examples how Martin wanted them. > >>> > >>> - Stated that GEO-URIs are not appropriate for the SIP Geolocation > >>> header, according to the discussion during the Maastricht Geopriv > >>> meeting. > >>> > >>> - we changed the privacy section, and included a ref to=20 > the Geopriv > >>> Arch doc, according to the agreement in Geopriv at Maastricht. > >>> > >>> > >>> Comments are encouraged > >>> > >>> We plan to request (3rd?) WGLC during the SIPCORE meeting=20 > in Beijing > >>> (to give folks a sense of our plans). > >>> > >>> James/Brian/Jon > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From jon.peterson@neustar.biz Thu Oct 28 10:16:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129133A6855 for ; Thu, 28 Oct 2010 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjLffKwevg01 for ; Thu, 28 Oct 2010 10:15:52 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 4B0BC3A677C for ; Thu, 28 Oct 2010 10:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1288286178; x=1603633418; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=izV8G32GseALs1d9bqeRyPulTP+twzSX9hTsnOgyBG4=; b=dadxQr30YAF8zLc4oDW8DSOzf3ri/eg0RQ7/gFI2b1LeAPM9yKaA2tRyRjKcvb hO2QK/8MXySGKhtkIGWfdUEQ== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.31451583; Thu, 28 Oct 2010 13:16:16 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 28 Oct 2010 13:16:15 -0400 From: "Peterson, Jon" To: "DRAGE, Keith (Keith)" , "Richard L. Barnes" , "James M. Polk" Date: Thu, 28 Oct 2010 13:16:12 -0400 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAAmpfmM= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pX0zfVa8X8WX7CW/ysWJ5w== Content-Type: multipart/alternative; boundary="_000_C8EEFDEC4757Bjonpetersonneustarbiz_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:16:03 -0000 --_000_C8EEFDEC4757Bjonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reducing this issue to a process argument trivializes (as usual) any techni= cal question about what location means in a SIP request. At the last workin= g group meeting, I very reluctantly conceded to the (somewhat weak in my op= inion) backwards-compatibility argument for allowing more than one Geolocat= ion header field value. To be clear, the previous version of the draft neve= r took away the ability to have multiple locations in a request - you could= always put in multiple PIDF-LO MIME bodies with different or similar locat= ions in the last version of the draft (and yes, with Content-Indirection or= whatever if you wanted it by reference). You could also put multiple locat= ions in the same PIDF-LO body, as both the presence data model and the rele= vant GEOPRIV RFCs recommend even. The contention that the previous version = "reduced to one" the number of locations that a SIP request could carry is = simply false. The real issue is what semantic role we expect the Geolocation header to pl= ay when it points to more than one PIDF-LO body. While I think plenty of pe= ople have the intuition that this should be meaningful, I haven't heard a l= ot of people step up to explain what it should mean exactly. If you want to= stuff ten locations into multipart MIME bodies of a SIP request, this docu= ment does not prevent you from doing so. As I've said before, it's kind of = like stuffing ten SDP bodies into a SIP request, which RFC3261 also allows.= You may mean something by those ten SDP bodies, but I have no idea what it= is, and neither will anyone else who receives your request. The only argum= ent (aside from rough-loc) I've heard for multiple locations is that there = may be some application-specific agreement about their meaning. That's fine= , but that sort of statement simply has no place in standards, as it is com= pletely anathema to interoperability. If we seriously tried to design SIP i= n such a way that we relied on application-specific behavior to handle ten = SDP bodies in one request with no further guidance to the implementers, we'= d never set up a single call. The high-level argument of the previous version of the draft was that when = there were multiple PIDF-LO bodies associated with a SIP request, the job o= f the Geolocation header would be to designate one of them as the one the r= ecipient was supposed to act on as if it were coupled to the sender of the = request. If it indicated a PIDF-LO body with multiple locations within it, = presumably the consuming application would be able to tell from the data mo= del markup which location it should consume. I do understand the argument f= rom rough-loc, or the backwards-compatibility argument that some applicatio= ns today simply bandy these Geolocation values around in an application-spe= cific manner. I didn't, however, walk away from either discussion with the = impression that we ever needed the Geolocation header to indicate more than= two PIDF-LO bodies for any of the use cases in question. This draft is so tardy that I can't countenance delaying it over a deadlock= on an issue like this, so I won't be stubborn on the text that goes in the= re. Honestly, though, we're a long way from understanding what coupling mul= tiple locations to a SIP request is supposed to mean. Jon Peterson NeuStar, Inc. On 10/28/10 6:01 AM, "DRAGE, Keith (Keith)" wrote: To be more specific - we had a document that allowed multiple locations. It= was reduced to one without any decision in that direction being made by th= e working group. It needs to go back to multiple values. In my view there are clear use cases where multiple values are required. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes > Sent: Thursday, October 28, 2010 1:19 PM > To: James M. Polk > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance -04 submitted, > here's the changes > > >> I'm pretty comfortable with the document at this point, > but have just > >> one minor question: Why are you still limiting the number > of location > >> values? Why are three values harmful, but not two? This > still seems > >> like pointless ABNF legislation. > > > > we only added the ability to have a second locationValue because of > > your rough-loc ID. Before that, we were firm in not > allowing more than > > one. Given that choice, which do you like? > > > > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it > > seemed everyone and their brother was agreeable with, so ... > > > As I recall, the proposal was to just remove the limit on the number > of locations values, not to bump it up by one. From the minutes: > > "Restore Geolocation header that has multiple URIs, even though we > would not recommend it. Entities inserting persence are responsbile > for any resulting errors. The header parameters distinguishing URIs > would not be added back in." > > At least in my mind, multiple !=3D 2. > > --Richard > > > > > > > > > james > > > > > >> --Richard > >> > >> > >> > >> > >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > >> > >>> SIPCORE > >>> > >>> I've submitted the next version of Location Conveyance (-04) > >>> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-04.txt > >>> and I believe this version has addressed each open item from the > >>> mailing list, as well as what was discussed and agreed to in the > >>> Maastricht meeting. > >>> > >>> I have attempted to identify each open issue with the specific > >>> resolution here (in no particular order): > >>> > >>> - Martin wanted Section 3 to be broken up into subsections, each > >>> revolving around each of the 4 diagrams. I have done this. > >>> > >>> - allowed a maximum of two (up from one) locationValues to be > >>> present in the Geolocation header value. The text however > recommends > >>> against inserting a second value. This was agreed to in > Maastricht. > >>> > >>> - Because we're allowing a max of two locationValues, > they can be in > >>> separate Geolocation headers in the SIP request. This scenario > >>> necessitates bring a previous version's paragraph in > stating that a > >>> 'SIP intermediary MUST inspect all instances of each Geolocation > >>> header before considering the routing-allowed parameter to be > >>> considered =3Dyes', to ensure there isn't a conflict in the 'other' > >>> Geolocation header that states the policy is =3Dno. > >>> > >>> - with the ability to add a second locationValue, it is > necessary to > >>> warn against doing this (confusion at the LRs). > >>> > >>> - Added the "you break it you bought it" philosophy to SIP > >>> intermediaries that choose to insert a second location where one > >>> already existed, especially for inserting a location URI in the > >>> downstream SIP request. > >>> > >>> - Fixed the ABNF to handle zero, one or two (but no more) > >>> locationValues according to the agreement in Maastricht. > There is a > >>> one-off use case which won't be in play very often, but > is a WG item > >>> in ECRIT that several wanted to allow the possibility for > (involving > >>> allowing one coarse and one highly accurate location in > the same SIP > >>> request). > >>> > >>> - Paul K. wanted the use-case in which a SIP intermediary > inserts a > >>> locationValue where one didn't exist previously, and > received a 424 > >>> (Bad Location Information) to that inserted location, from having > >>> the 424 propagate towards the UAC (as the UAC might not > know what to > >>> do with a 424). This is now covered in Section 4.3. > >>> > >>> - changed existing text to "MUST NOT" from "does not" about a 424 > >>> not terminating an existing dialog (just increased the strength of > >>> this. > >>> > >>> - I added the 424 to the table 2 entry in which the Geolocation > >>> header can be in only this response. > >>> > >>> - I added text stating the conditions for adding a Geolocation > >>> header value to the 424, to make it clear what is and what isn't > >>> allowed for this. > >>> > >>> - Martin wanted me to add back in the top level Geolocation-Error > >>> codes 100, 200, 300 and 400, which I did in section 4.3. > >>> > >>> - rejected the idea that the geolocation option-tag hasn't been > >>> justified. > >>> > >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > references section > >>> because I added the ability to include HTTP: and HTTPS: URIs, and > >>> stated if received, they should be dereferenced according to the > >>> HELD Deref doc. > >>> > >>> - changed the Section 5 examples how Martin wanted them. > >>> > >>> - Stated that GEO-URIs are not appropriate for the SIP Geolocation > >>> header, according to the discussion during the Maastricht Geopriv > >>> meeting. > >>> > >>> - we changed the privacy section, and included a ref to > the Geopriv > >>> Arch doc, according to the agreement in Geopriv at Maastricht. > >>> > >>> > >>> Comments are encouraged > >>> > >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > in Beijing > >>> (to give folks a sense of our plans). > >>> > >>> James/Brian/Jon > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_C8EEFDEC4757Bjonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Location Conveyance -04 submitted, here's the  ch= anges
Reducing this issue to a process argument trivializes (as usual) any techni= cal question about what location means in a SIP request. At the last workin= g group meeting, I very reluctantly conceded to the (somewhat weak in my op= inion) backwards-compatibility argument for allowing more than one Geolocat= ion header field value. To be clear, the previous version of the draft neve= r took away the ability to have multiple locations in a request – you= could always put in multiple PIDF-LO MIME bodies with different or similar= locations in the last version of the draft (and yes, with Content-Indirect= ion or whatever if you wanted it by reference). You could also put multiple= locations in the same PIDF-LO body, as both the presence data model and th= e relevant GEOPRIV RFCs recommend even. The contention that the previous ve= rsion “reduced to one” the number of locations that a SIP reque= st could carry is simply false.

The real issue is what semantic role we expect the Geolocation header to pl= ay when it points to more than one PIDF-LO body. While I think plenty of pe= ople have the intuition that this should be meaningful, I haven’t hea= rd a lot of people step up to explain what it should mean exactly. If you w= ant to stuff ten locations into multipart MIME bodies of a SIP request, thi= s document does not prevent you from doing so. As I’ve said before, i= t’s kind of like stuffing ten SDP bodies into a SIP request, which RF= C3261 also allows. You may mean something by those ten SDP bodies, but I ha= ve no idea what it is, and neither will anyone else who receives your reque= st. The only argument (aside from rough-loc) I’ve heard for multiple = locations is that there may be some application-specific agreement about th= eir meaning. That’s fine, but that sort of statement simply has no pl= ace in standards, as it is completely anathema to interoperability. If we s= eriously tried to design SIP in such a way that we relied on application-sp= ecific behavior to handle ten SDP bodies in one request with no further gui= dance to the implementers, we’d never set up a single call.

The high-level argument of the previous version of the draft was that when = there were multiple PIDF-LO bodies associated with a SIP request, the job o= f the Geolocation header would be to designate one of them as the one the r= ecipient was supposed to act on as if it were coupled to the sender of the = request. If it indicated a PIDF-LO body with multiple locations within it, = presumably the consuming application would be able to tell from the data mo= del markup which location it should consume. I do understand the argument f= rom rough-loc, or the backwards-compatibility argument that some applicatio= ns today simply bandy these Geolocation values around in an application-spe= cific manner. I didn’t, however, walk away from either discussion wit= h the impression that we ever needed the Geolocation header to indicate mor= e than two PIDF-LO bodies for any of the use cases in question.

This draft is so tardy that I can’t countenance delaying it over a de= adlock on an issue like this, so I won’t be stubborn on the text that= goes in there. Honestly, though, we’re a long way from understanding= what coupling multiple locations to a SIP request is supposed to mean.

Jon Peterson
NeuStar, Inc.


On 10/28/10 6:01 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:

To be more specific - we had a document tha= t allowed multiple locations. It was reduced to one without any decision in= that direction being made by the working group. It needs to go back to mul= tiple values.

In my view there are clear use cases where multiple values are required.
regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Richard L. Barnes
> Sent: Thursday, October 28, 2010 1:19 PM
> To: James M. Polk
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Location Conveyance -04 submitted,
> here's the changes
>
> >> I'm pretty comfortable with the document at this point,
> but have just
> >> one minor question: Why are you still limiting the number
> of location
> >> values?  Why are three values harmful, but not two? &nbs= p;This
> still seems
> >> like pointless ABNF legislation.
> >
> > we only added the ability to have a second locationValue because = of
> > your rough-loc ID. Before that, we were firm in not
> allowing more than
> > one.  Given that choice, which do you like?
> >
> > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it=
> > seemed everyone and their brother was agreeable with, so ...
>
>
> As I recall, the proposal was to just remove the limit on the number <= BR> > of locations values, not to bump it up by one.  From the minutes:=
>
> "Restore Geolocation header that has multiple URIs, even though w= e
> would not recommend it. Entities inserting persence are responsbile > for any resulting errors. The header parameters distinguishing URIs > would not be added back in."
>
> At least in my mind, multiple !=3D 2.
>
> --Richard
>
>
>
>
>
>
>
> > james
> >
> >
> >> --Richard
> >>
> >>
> >>
> >>
> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:
> >>
> >>> SIPCORE
> >>>
> >>> I've submitted the next version of Location Conveyance (-= 04)
> >>>
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> n-conveyance-04.txt
> >>> and I believe this version has addressed each open item f= rom the
> >>> mailing list, as well as what was discussed and agreed to= in the
> >>> Maastricht meeting.
> >>>
> >>> I have attempted to identify each open issue with the spe= cific
> >>> resolution here (in no particular order):
> >>>
> >>> - Martin wanted Section 3 to be broken up into subsection= s, each
> >>> revolving around each of the 4 diagrams. I have done this= .
> >>>
> >>> - allowed a maximum of two (up from one) locationValues t= o be
> >>> present in the Geolocation header value. The text however=
> recommends
> >>> against inserting a second value. This was agreed to in > Maastricht.
> >>>
> >>> - Because we're allowing a max of two locationValues,
> they can be in
> >>> separate Geolocation headers in the SIP request. This sce= nario
> >>> necessitates bring a previous version's paragraph in
> stating that a
> >>> 'SIP intermediary MUST inspect all instances of each Geol= ocation
> >>> header before considering the routing-allowed parameter t= o be
> >>> considered =3Dyes', to ensure there isn't a conflict in t= he 'other'
> >>> Geolocation header that states the policy is =3Dno.
> >>>
> >>> - with the ability to add a second locationValue, it is > necessary to
> >>> warn against doing this (confusion at the LRs).
> >>>
> >>> - Added the "you break it you bought it" philos= ophy to SIP
> >>> intermediaries that choose to insert a second location wh= ere one
> >>> already existed, especially for inserting a location URI = in the
> >>> downstream SIP request.
> >>>
> >>> - Fixed the ABNF to handle zero, one or two (but no more)=
> >>> locationValues according to the agreement in Maastricht. =
> There is a
> >>> one-off use case which won't be in play very often, but > is a WG item
> >>> in ECRIT that several wanted to allow the possibility for=
> (involving
> >>> allowing one coarse and one highly accurate location in > the same SIP
> >>> request).
> >>>
> >>> - Paul K. wanted the use-case in which a SIP intermediary=
> inserts a
> >>> locationValue where one didn't exist previously, and
> received a 424
> >>> (Bad Location Information) to that inserted location, fro= m having
> >>> the 424 propagate towards the UAC (as the UAC might not > know what to
> >>> do with a 424). This is now covered in Section 4.3.
> >>>
> >>> - changed existing text to "MUST NOT" from &quo= t;does not" about a 424
> >>> not terminating an existing dialog (just increased the st= rength of
> >>> this.
> >>>
> >>> - I added the 424 to the table 2 entry in which the Geolo= cation
> >>> header can be in only this response.
> >>>
> >>> - I added text stating the conditions for adding a Geoloc= ation
> >>> header value to the 424, to make it clear what is and wha= t isn't
> >>> allowed for this.
> >>>
> >>> - Martin wanted me to add back in the top level Geolocati= on-Error
> >>> codes 100, 200, 300 and 400, which I did in section 4.3.<= BR> > >>>
> >>> - rejected the idea that the geolocation option-tag hasn'= t been
> >>> justified.
> >>>
> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the
> references section
> >>> because I added the ability to include HTTP: and HTTPS: U= RIs, and
> >>> stated if received, they should be dereferenced according= to the
> >>> HELD Deref doc.
> >>>
> >>> - changed the Section 5 examples how Martin wanted them.<= BR> > >>>
> >>> - Stated that GEO-URIs are not appropriate for the SIP Ge= olocation
> >>> header, according to the discussion during the Maastricht= Geopriv
> >>> meeting.
> >>>
> >>> - we changed the privacy section, and included a ref to > the Geopriv
> >>> Arch doc, according to the agreement in Geopriv at Maastr= icht.
> >>>
> >>>
> >>> Comments are encouraged
> >>>
> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting=
> in Beijing
> >>> (to give folks a sense of our plans).
> >>>
> >>> James/Brian/Jon
> >>>
> >>>
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> sipcore@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https:/= /www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

--_000_C8EEFDEC4757Bjonpetersonneustarbiz_-- From Martin.Thomson@andrew.com Thu Oct 28 16:58:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476AD3A6801 for ; Thu, 28 Oct 2010 16:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WFqdEPSUYSo for ; Thu, 28 Oct 2010 16:58:22 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 71DE53A679C for ; Thu, 28 Oct 2010 16:58:22 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:16427 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S477952Ab0J2AAP (ORCPT ); Thu, 28 Oct 2010 19:00:15 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 28 Oct 2010 19:00:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 29 Oct 2010 08:00:12 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , James M.Polk Date: Fri, 29 Oct 2010 08:00:10 +0800 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mmHk2a7nyekcQausJpnHtZqlewAYb2Jg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EB374@SISPE7MB1.commscope.com> References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> In-Reply-To: <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 23:58:23 -0000 T24gMjAxMC0xMC0yOCBhdCAyMzoxODo0OCwgUmljaGFyZCBMLiBCYXJuZXMgd3JvdGU6DQo+IEF0 IGxlYXN0IGluIG15IG1pbmQsIG11bHRpcGxlICE9IDIuDQoNCkluIHRlcm1zIG9mIGRhbWFnZSBk b25lLCBhbGxvd2luZyBtb3JlIGlzIGp1c3QgYSBtYXR0ZXIgb2YgZGVncmVlLiAgVGhlICJ5b3Ug YnJlYWsgaXQsIHlvdSBib3VnaHQgaXQiIHBoaWxvc29waHkgYXBwbGllcyByZWdhcmRsZXNzLg0K DQotLU1hcnRpbg0K From jmpolk@cisco.com Thu Oct 28 17:30:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AE93A67A4 for ; Thu, 28 Oct 2010 17:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXFk6VhLnQkk for ; Thu, 28 Oct 2010 17:30:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1947D3A67A3 for ; Thu, 28 Oct 2010 17:30:36 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="375555784" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2010 00:32:29 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9T0WS3p005579; Fri, 29 Oct 2010 00:32:29 GMT Message-Id: <201010290032.o9T0WS3p005579@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Oct 2010 19:32:27 -0500 To: "Thomson, Martin" , "Richard L. Barnes" , "James M.Polk" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EB374@SISPE7MB1.comms cope.com> References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <8B0A9FCBB9832F43971E38010638454F03F31EB374@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 00:30:37 -0000 At 07:00 PM 10/28/2010, Thomson, Martin wrote: >On 2010-10-28 at 23:18:48, Richard L. Barnes wrote: > > At least in my mind, multiple != 2. > >In terms of damage done, allowing more is just a matter of >degree. The "you break it, you bought it" philosophy applies regardless. I'll leave the warnings against more than one, but allow "many" in the next rev. Everyone cool with that? James >--Martin From jmpolk@cisco.com Thu Oct 28 17:45:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9893A6954 for ; Thu, 28 Oct 2010 17:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ-zcFhNe2Ag for ; Thu, 28 Oct 2010 17:45:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D8A323A67A3 for ; Thu, 28 Oct 2010 17:45:49 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="611266906" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2010 00:47:43 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9T0lgbq013785; Fri, 29 Oct 2010 00:47:42 GMT Message-Id: <201010290047.o9T0lgbq013785@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Oct 2010 19:47:41 -0500 To: "Elwell, John" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <201010271904.o9RJ4WM5009321@sj-core-3.cisco.com> <201010271958.o9RJwfg7003382@sj-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 00:45:55 -0000 At 01:23 AM 10/28/2010, Elwell, John wrote: > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 27 October 2010 20:59 > > To: Elwell, John; James M. Polk; sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > At 02:37 PM 10/27/2010, Elwell, John wrote: > > > > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: 27 October 2010 20:05 > > > > To: Elwell, John; James M. Polk; sipcore@ietf.org > > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > > > here's the changes > > > > > > > > At 08:17 AM 10/27/2010, Elwell, John wrote: > > > > >I am happy to see that http and https are added as schemes in > > > > >locationURI. However, looking at 4.6, I am still > > uncomfortable that > > > > >SIP-, SIPS- and PRES-URI are recommended and but HTTP- > > and HTTPS-URI > > > > >are not recommended (by virtue of the fact they are only MAY > > > > >strength, for use when one disregards the SHOULD for SIP-, > > > > SIPS- and PRES-). > > > > > > > > well... this is a SIP document, why shouldn't a SIP-based URI be > > > > recommended? Do you want me to say HTTP:/HTTPS: is allowed in > > > > some other way? > > > > > > > > > > > > >We had an earlier thread starting here: > > > > > > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html > > > > >in which questions were asked about what one must > > support. The text > > > > >in 4.6 says nothing about what a LR must support. The > > implication is > > > > >that it either has two support all of the 5 schemes listed for > > > > >sending in a request, or it can choose which to support > > and reject > > > > >any that it doesn't support. > > > > > > > > right now it is the latter, but I would - if I must - > > propose making > > > > SIP:/SIPS:/PRES: mandatory if there is any URI scheme > > that is (again, > > > > this is a SIP doc). > > >[JRE] But the event package is [ID-GEO-FILTERS] and is based upon > > >RFC 3856, a SIMPLE document. Not all SIP implementations > > support SIMPLE. > > > > [jmp] Yes, but realistically - fewer will support HELD-Deref... > > > > >On the other hand, I can see benefits in this (ability to receive > > >notifications when location changes, plus filters). > > > > [jmp] I believe Brian wrote the Filters doc with that in mind (i.e., > > the benefits). > > > > >If the consensus is SIP/SIPS/PRES is the only mandatory one, I can > > >live with it. > > > > > >On re-reading 4.6, I see that, although the text "These schemes MUST > > >be implemented according to this document" is within the paragraph > > >concerning what you SHOULD place in a SIP request, perhaps it is > > >intended to include what MUST be supported on receipt too, so > > >perhaps it is OK as is, or perhaps it should say "A location > > >recipient MUST implement these schemes". > > > > [jmp] If we end up choosing a mandatory to implement scheme (or > > scheme set), then I think we can state that receivers MUST implement > > that scheme (set). > > > > [jmp] Do you (or others) believe this should be done regardless of > > any mandatory to implement sending scheme, or wait until there is a > > mandatory to implement sending scheme? >[JRE] What we want to achieve is that there is a certain group of >schemes (one or more) that, if sent by the sender, will be supported >by any receiver that supports location-conveyance. Assuming the WG >settles on SIP/SIPS/PRES as that group of schemes, I think the >present words get quite close to what we require. However, as I >mention above, the paragraph talks about schemes to send in the >request, so there is some ambiguity as to whether the "MUST be >supported" includes receipt or not. Hence my proposed word change above. If others agree, I'm ok with making LRs supporting this spec have to support a or a group of schemes. I think this will easily get facetime during the preso in SIPCORE to get high BW feedback too. > > > > > > > > > > > > > > > > >In practice, as pointed out on the thread, the schemes > > effectively > > > > >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the > > > > >absoluteURI option, which effectively leaves it open ended). So > > > > >perhaps it is not unreasonable to mandate support for > > all 5 schemes > > > > >(both mechanisms) by a recipient, although it does raise the bar > > > > >somewhat for recipient implementations. > > > > > > > > Several of us have and currently believe that is raising the bar a > > > > little too high. > > > > > > > > >I recall there was some interest on the thread in limiting to a > > > > >single MUST support, and some interest in that scheme > > being HTTP(S). > > > > >I am not sure we reached consensus on this. I don't have a strong > > > > >opinion, but we certainly need some text to clarify > > things one way > > > > >or the other. > > > > > > > > > >Furthermore, it is unclear which code to use in a 494 > > response when > > > > >rejecting an unsupported scheme - presumably the top > > level 400, but > > > > >that says nothing about why dereference failed. Even if all the > > > > >named schemes were MUST support (so you would never > > reject these), > > > > >there could be other schemes under absoluteURI that you > > > > would want to reject. > > > > > > > > The conclusion from the San Diego adhoc bof on this ID > > was to limit > > > > the number of error types to specific different > > actionable ones. At > > > > that adhoc, I had roughly 22 different error types, one > > set included > > > > the ability to indicate which URI scheme wasn't supported > > and which > > > > ones were. That idea was roundly rejected (most strongly by our > > > > newest co-author Jon Peterson). I believe it was Henning > > (and maybe > > > > Hannes) that wanted the error codes limited as well, and to allow > > > > this RFC-to-be to be extended with an XML body in the > > response that > > > > included a much more detailed error explanation and ways > > detailed in > > > > how to resolve the problem. > > > > > > > > No one has written that ID yet, so I don't know where that > > > > thought is now. > > > > > > > > That said, -04 doesn't have a 494 response articulated because > > > > location specific rejections are for the 424 (Bad Location > > > > Information) response. Jon and I talked just last week > > about what do > > > > we do when an LR supports one URI scheme and receives another URI > > > > scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an > > HTTP:/HTTPS: > > > > URI). We couldn't come up with anything that didn't have a lot of > > > > holes in it, so we left it for now. > > >[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would > > >you have if you specified 401, say, as "URI scheme not > > >supported"? I guess one difficulty is what does the UAC do about > > >it, if it doesn't have the means for obtaining a reference with a > > >different URI. Was that the sort of hole you had in mind? > > > > [jmp] Jon and I talked specifically about adding a 401 "URI scheme > > not supported", but his point was "what does that really tell you?" > > and I tried to plead that it would mean that this scheme (set) (i.e., > > SIP based or HTTP based) wasn't supported, and to send the other > > scheme (set). His counter was that what happens when there is more > > than one scheme set to choose from, then what does a 401 really mean > > that a 400 doesn't already? I didn't really have a good answer for > > that one. In other words, if we're only ever going to have a choice > > between SIP and HTTP, then the 401 would work. Once you have a 3rd > > (or more) choice, it all falls apart. >[JRE] I would say that there would be a distinction between 401 (I >don't know how to deal with that scheme because I don't support it) >and 400 (which would include things like error response to the >SIP/HTTP request, or dereference yielded a location that I couldn't >interpret (unless that is a 100), etc.). I see the distinction, but to let you know, I'm not the one who really needs convincing among the editor team. Jon is fairly open about being opposed to have a bunch of error codes, but I personally think the list below is what I would do if it were up to me now. I think that is concise, has no ambiguity or room for error (pardon the pun). James >John > > > > > > The best way around this is to indicate which choice of scheme you > > want in the 424, perhaps this could become (Jon - don't > > hyperventilate!) > > > > 401 "URI scheme not supported - send SIP:URI" > > 402 "URI scheme not supported - send SIPS:URI" > > 403 "URI scheme not supported - send PRES:URI" > > 404 "URI scheme not supported - send HTTP:URI" > > 405 "URI scheme not supported - send HTTPS:URI" > > > > and just add to the list when someone wants a new URI scheme > > supported. > > > > James > > > > > > >John > > > > > > > > > > > > > > James > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > > > > > Sent: 27 October 2010 05:32 > > > > > > To: sipcore@ietf.org > > > > > > Subject: [sipcore] Location Conveyance -04 submitted, here's > > > > > > the changes > > > > > > > > > > > > SIPCORE > > > > > > > > > > > > I've submitted the next version of Location Conveyance (-04) > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > > > n-conveyance-04.txt > > > > > > and I believe this version has addressed each open > > item from the > > > > > > mailing list, as well as what was discussed and > > agreed to in the > > > > > > Maastricht meeting. > > > > > > > > > > > > I have attempted to identify each open issue with the specific > > > > > > resolution here (in no particular order): > > > > > > > > > > > > - Martin wanted Section 3 to be broken up into > > subsections, each > > > > > > revolving around each of the 4 diagrams. I have done this. > > > > > > > > > > > > - allowed a maximum of two (up from one) locationValues > > > > to be present > > > > > > in the Geolocation header value. The text however > > > > recommends against > > > > > > inserting a second value. This was agreed to in Maastricht. > > > > > > > > > > > > - Because we're allowing a max of two locationValues, > > > > they can be in > > > > > > separate Geolocation headers in the SIP request. This scenario > > > > > > necessitates bring a previous version's paragraph in > > > > stating that a > > > > > > 'SIP intermediary MUST inspect all instances of each > > Geolocation > > > > > > header before considering the routing-allowed parameter to be > > > > > > considered =yes', to ensure there isn't a conflict in > > the 'other' > > > > > > Geolocation header that states the policy is =no. > > > > > > > > > > > > - with the ability to add a second locationValue, it is > > > > necessary to > > > > > > warn against doing this (confusion at the LRs). > > > > > > > > > > > > - Added the "you break it you bought it" philosophy to SIP > > > > > > intermediaries that choose to insert a second > > location where one > > > > > > already existed, especially for inserting a location > > URI in the > > > > > > downstream SIP request. > > > > > > > > > > > > - Fixed the ABNF to handle zero, one or two (but no more) > > > > > > locationValues according to the agreement in Maastricht. > > > > There is a > > > > > > one-off use case which won't be in play very often, but > > > > is a WG item > > > > > > in ECRIT that several wanted to allow the possibility for > > > > (involving > > > > > > allowing one coarse and one highly accurate location in the > > > > > > same SIP request). > > > > > > > > > > > > - Paul K. wanted the use-case in which a SIP intermediary > > > > inserts a > > > > > > locationValue where one didn't exist previously, and > > > > received a 424 > > > > > > (Bad Location Information) to that inserted location, > > > > from having the > > > > > > 424 propagate towards the UAC (as the UAC might not know > > > > what to do > > > > > > with a 424). This is now covered in Section 4.3. > > > > > > > > > > > > - changed existing text to "MUST NOT" from "does not" > > > > about a 424 not > > > > > > terminating an existing dialog (just increased the > > > > strength of this. > > > > > > > > > > > > - I added the 424 to the table 2 entry in which the > > Geolocation > > > > > > header can be in only this response. > > > > > > > > > > > > - I added text stating the conditions for adding a > > > > Geolocation header > > > > > > value to the 424, to make it clear what is and what isn't > > > > > > allowed for this. > > > > > > > > > > > > - Martin wanted me to add back in the top level > > Geolocation-Error > > > > > > codes 100, 200, 300 and 400, which I did in section 4.3. > > > > > > > > > > > > - rejected the idea that the geolocation option-tag hasn't > > > > > > been justified. > > > > > > > > > > > > - Added RFCs 2616, 2818 and HELD Deref ID to the > > > > references section > > > > > > because I added the ability to include HTTP: and > > HTTPS: URIs, and > > > > > > stated if received, they should be dereferenced according > > > > to the HELD > > > > > > Deref doc. > > > > > > > > > > > > - changed the Section 5 examples how Martin wanted them. > > > > > > > > > > > > - Stated that GEO-URIs are not appropriate for the > > SIP Geolocation > > > > > > header, according to the discussion during the Maastricht > > > > > > Geopriv meeting. > > > > > > > > > > > > - we changed the privacy section, and included a ref to > > > > the Geopriv > > > > > > Arch doc, according to the agreement in Geopriv at Maastricht. > > > > > > > > > > > > > > > > > > Comments are encouraged > > > > > > > > > > > > We plan to request (3rd?) WGLC during the SIPCORE meeting > > > > in Beijing > > > > > > (to give folks a sense of our plans). > > > > > > > > > > > > James/Brian/Jon > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > From jmpolk@cisco.com Thu Oct 28 17:49:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B822B3A68B1 for ; Thu, 28 Oct 2010 17:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQmnRb078ihK for ; Thu, 28 Oct 2010 17:49:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B72CA3A6778 for ; Thu, 28 Oct 2010 17:49:51 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="611268426" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2010 00:51:45 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9T0piCd016052; Fri, 29 Oct 2010 00:51:44 GMT Message-Id: <201010290051.o9T0piCd016052@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Oct 2010 19:51:43 -0500 To: "Elwell, John" , Anders Kristensen , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> <4CC90195.2070203@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 00:49:56 -0000 At 05:38 AM 10/28/2010, Elwell, John wrote: >Yes, 4 looks good, but I could live with 1. I think this has become #1 of two major open issues to address in Beijing (along with the supported and unsupported URI schemes and their respective possible error codes, as 2a and 2b). James >John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Anders Kristensen > > Sent: 28 October 2010 05:53 > > To: sipcore@ietf.org > > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 > > > > I haven't really followed the discussion closely but I'll say this > > anyway. Many header fields are of a form similar to Geolocation, > > essentially lists of URI, and allow for parameters. But I think the > > parameters are pretty much always associated with individual > > entries in > > the list and may be present for more than one. > > > > From what I can tell, in the case of Geolocation, the > > routing-allowed > > param is not really attached to any particular entry in the list > > suggesting that maybe it doesn't belong in the same header field. I > > think that's the thinking that lead Paul to options 4 or 5 which seem > > much preferable to me. That allows Geolocation to fit the text in RFC > > 3261 that talks about combining header fields: > > > > Specifically, any SIP > > header whose grammar is of the form > > > > header = "header-name" HCOLON header-value *(COMMA > > header-value) > > > > allows for combining header fields of the same name into a comma- > > separated list. > > > > Granted, there's no rule that says that header fields with > > comma-separated values *must* fit the above grammar but ISTM > > that it's a > > pretty established pattern which is worth observing. > > > > Thanks, > > Anders > > > > On 10/27/2010 9:10 PM, James M. Polk wrote: > > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote: > > >> I have a bunch inline here. > > > > > > I'll say ;-) > > > > > >> This supersedes my earlier suggested ABNF change. > > > > > > ack > > > > > > > > >> On 10/27/2010 2:32 PM, James M. Polk wrote: > > >>> Paul > > >>> > > >>> in-line > > >>> > > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote: > > >>>> I took a quick look at the new version, and it seems to > > have cleanup a > > >>>> lot. But there *still* seems to be a problem with the syntax. > > >>>> (Interplay between ABNF and text.) From the text, I find: > > >>>> > > >>>> The placement of the "routing-allowed" header field parameter, > > >>>> strongly encouraged by [RFC5606], is outside the > > locationValue, and > > >>>> MUST always be last in the header field value. The > > routing-allowed > > >>>> parameter MUST be present, even when no locationValue is present. > > >>>> > > >>>> This is questionably supported by the ABNF: > > >>>> > > >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value > > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) > > >>>> / routing-param > > >>> > > >>> the above, I believe - but am open to be corrected by > > those better at > > >>> ABNF syntax that I, says > > >>> > > >>> - the Geolocation header can optionally have one or more > > locationValues > > >>> - which are where the location URIs go > > >> > > >> The above says *a* Geolocation header can have > > >> - one or two locationValues > > >> - OR one routing-param > > >> > > >> (The slash means OR) > > >> > > >> But it doesn't state that the Geolocation header itself can appear > > >> only once. And obviously if the goal is to have a > > locationValue AND a > > >> routing-param in the message, then with the above syntax > > at least TWO > > >> Geolocation headers will be required. > > >> > > >>> - but that the Geolocation header *will* have a routing-param > > >>> - which is the "routing-allowed" paramter that RFC 5606 > > wanted included > > >> > > >> Since the slash means OR, it doesn't mean it *will*. > > >> > > >>> The text of the ID then says that only zero, one or two > > locationValues > > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and > > >>> ECRIT/GEOPRIV). > > >>> > > >>>> locationValue = LAQUOT locationURI RAQUOT > > >>>> *(SEMI geoloc-param) > > >>>> locationURI = sip-URI / sips-URI / pres-URI > > >>>> / http-URI / HTTPS-URI > > >>>> / cid-url ; (from RFC 2392) > > >>>> / absoluteURI ; (from RFC 3261) > > >>>> geoloc-param = generic-param; (from RFC 3261) > > >>>> routing-param = "routing-allowed" EQUAL "yes" / "no" > > >>>> > > >>>> It only works if you presume that there are separate > > occurrences of > > >>>> GeoLocation-header in the message, one with just > > locations, another > > >>>> with just the routing-param. > > >>> > > >>> I don't get that part of your point, but I guess Martin's > > next message > > >>> says I need to add a "COMMA" after the ']' but before the > > ')'. Would > > >>> this satisfy your issue? > > >> > > >> Adding the COMMA and removing the slash would require the > > >> routing-param, and would separate it from the > > location-value. But then > > >> if you only wanted the routing-param without any locationValues you > > >> would have to write: > > >> > > >> Geolocation:,routing-allowed=no > > >> > > >> which is at least a bit weird, which I think is what Martin meant. > > >> > > >>>> The routing-param certainly can't be "last in the header > > field value" > > >>>> except in the degenerate sense, since it must be first > > and only in a > > >>>> Geolocation-header. > > >>> > > >>> If the routing-param was intended to be first, wouldn't > > it appear first > > >>> on this line? > > >> > > >> My point was that the syntax as written only allows > > routing-param by > > >> itself in a geolocation-header. E.g. > > >> > > >> Geolocation:routing-allowed=no > > >> > > >> It can't share a single Geolocation header with a > > locationValue. Hence > > >> it is *both* first and last in that header. > > >> > > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) > > >>>> / routing-param > > >>> > > >>> but it doesn't, so I'm confused. > > >> > > >> Again, the slash means OR. So you have: > > >> > > >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) > > >> OR > > >> Geolocation-value = routing-param > > >> > > >> (Though you can't write it that way in ABNF. > > >> > > >>>> Below are some specific cases - both valid and invalid. > > In each case I > > >>>> show some headers bracketed by "...". That is intended > > to mean other > > >>>> headers in a message, but all in the same message. (And > > when I show > > >>>> multiple headers, there could be other non-geoloc > > headers interleaved.) > > >>>> > > >>>> * The following are legal according to the above, and > > probably within > > >>>> expected usage: > > >>>> > > >>>> ... > > >>>> Geolocation: cid:foo@example.com > > >>>> Geolocation: routing-allowed=yes > > >>>> ... > > >>>> > > >>>> ... > > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > > >>>> Geolocation: routing-allowed=yes > > >>>> ... > > >>>> > > >>>> ... > > >>>> Geolocation: routing-allowed=no > > >>>> ... > > >>>> > > >>>> * IIUC the following are allowed by the above both > > syntactically and > > >>>> according to the text, but is presumably not *intended* > > to be valid. > > >>>> (Its legal because the in each instance of Geolocation-header its > > >>>> last.) > > >>>> > > >>>> ... > > >>>> Geolocation: routing-allowed=no > > >>>> Geolocation: routing-allowed=yes > > >>>> ... > > >>>> > > >>>> The following is also allowed - I don't know if its > > intended or not: > > >>>> > > >>>> ... > > >>>> Geolocation: routing-allowed=yes > > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > > >>>> ... > > >>>> > > >>>> * The following is allowed by the ABNF though disallowed > > by the text: > > >>>> > > >>>> ... > > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com > > >>>> Geolocation: cid:baz@example.com > > >>>> ... > > >>>> > > >>>> * The following is *not* allowed by the ABNF. I suspect > > it might be > > >>>> intended to be valid, but I'm far from sure about it: > > >>>> > > >>>> ... > > >>>> Geolocation: cid:foo@example.com,routing-allowed=yes > > >>>> ... > > >>> > > >>> to get this above example "allowed", would I correct the > > existing ABNF > > >>> to be > > >>> > > >>>> Geolocation-value = ( locationValue [ COMMA > > locationValue ] COMMA ) > > >>>> / routing-param > > >>> > > >>> ? > > >> > > >> No. *That* would allow all of the following but not the > > example above: > > >> > > >> Geolocation: cid:foo@example.com, > > >> Geolocation: cid:foo@example.com,cid:bar@example.com, > > >> Geolocation: routing-allowed=yes > > >> > > >>>> In addition to that, the text is very explicit that: > > >>>> > > >>>> The routing-allowed > > >>>> parameter MUST be present, even when no locationValue is present. > > >>>> > > >>>> but then it says: > > >>>> > > >>>> If no routing-allowed parameter > > >>>> is present in a SIP request, a SIP intermediary MAY insert this > > >>>> value with a RECOMMENDED value of "no" by default. > > >>>> > > >>>> So its required, but we have rules to follow if its > > missing. But I > > >>>> don't understand how it *can* be required, since the > > sender of the > > >>>> request may not understand/support Geolocation and so > > won't include it. > > >>> > > >>> What we're trying to do here is explicitly give > > instructions to SIP > > >>> intermediary implementers to include the routing-allowed > > parameter if > > >>> one isn't present, with a default value of =no. > > >> > > >> I went back and reread the section containing this text. It is in a > > >> section explicitly about this header. So on reflection I > > suppose the > > >> "MUST be present" was intended to imply "in the > > Geolocation *header". > > >> I took it to mean "in the request". > > >> > > >> Requiring it to be in the header only makes sense if there > > can be at > > >> most one header. And then it only makes sense if the > > syntax is altered > > >> to allow both the routing-parameter and the locationValue > > in the same > > >> header. > > >> > > >>>> ISTM that in reality its only *required* if the is a > > locationValue > > >>>> present, and is otherwise optional. > > >>> > > >>> which is how most would read it if ... > > >>> > > >>>> If no routing-allowed parameter > > >>>> is present in a SIP request, a SIP intermediary MAY insert this > > >>>> value with a RECOMMENDED value of "no" by default. > > >>> > > >>> ... weren't present in the document. But, there is no > > permission to > > >>> allow SIP intermediaries to add the routing-allowed > > parameter, which we > > >>> wanted to cover. > > >> > > >> I'm still confused. Let me state what I think you are after: > > >> > > >> - a request may or may not contain a Geolocation header > > >> - a request may not contain more than one Geolocation header > > > > > > of what you have, this one is one I hadn't considered > > important, but if > > > that gets everything aligned, then I'm all for adding it in. > > > > > >> - a Geolocation header MUST contain a routing-param > > >> - a Geolocation header Must contain zero, one, or two > > locationValues > > >> - you prefer the routing-param to be the last field in the header > > >> - a proxy MAY add a Geolocation header if one is not present > > >> (in which case it MUST include a routing-param) > > >> - a proxy MAY add a locationValue to an existing Geolocation header > > >> if it doesn't already have two locationValues. (And I guess it > > >> could add two if there initially were none.) > > >> > > >> And you would like ABNF that is consistent with the above. > > > > > > with the one caveat, yes. > > > > > > > > >> I'm going to give you some alternatives that should all be > > >> syntactically correct. I'll give you one that meets the above, and > > >> some others that may be more appealing variations. Then we can see > > >> which people prefer. > > >> > > >> 1) The following tries to meet the requirements I spelled > > out above: > > >> > > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value > > >> Geolocation-value = locationValue [ COMMA locationValue] > > >> COMMA routing-param > > >> / routing-param > > > > > > I hadn't even thought that was possible, but seeing it, I'm amazed I > > > didn't try it > > > > > > (i.e., it's another classic "I could've had a v8" moment)... > > > > > > I'm not as smart as you, Paul <:-| > > > > > >> locationValue = LAQUOT locationURI RAQUOT > > >> *(SEMI geoloc-param) > > >> locationURI = sip-URI / sips-URI / pres-URI > > >> / http-URI / HTTPS-URI > > >> / cid-url ; (from RFC 2392) > > >> / absoluteURI ; (from RFC 3261) > > >> geoloc-param = generic-param; (from RFC 3261) > > >> routing-param = "routing-allowed" EQUAL "yes" / "no" > > >> > > >> This must be accompanied by text stating that there MUST be at most > > >> one Geolocation-header in a request. > > > > > > you've sold me on this one (and yes, I examined all the > > others before > > > jumping on this first one!). Do others have strong opinions > > about why > > > not #1? > > > > > > thank you for this! > > > > > > James > > > > > > > > >> 2) The following is similar to (1), but allows more than two > > >> 'locationValue's > > >> > > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value > > >> Geolocation-value = *(locationValue COMMA) routing-param > > >> locationValue = LAQUOT locationURI RAQUOT > > >> *(SEMI geoloc-param) > > >> locationURI = sip-URI / sips-URI / pres-URI > > >> / http-URI / HTTPS-URI > > >> / cid-url ; (from RFC 2392) > > >> / absoluteURI ; (from RFC 3261) > > >> geoloc-param = generic-param; (from RFC 3261) > > >> routing-param = "routing-allowed" EQUAL "yes" / "no" > > >> > > >> The same wording is required with it > > >> > > >> 3) The following is a copy from my earlier posting: > > >> > > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value > > >> *( COMMA Geolocation-value) > > >> Geolocation-value = locationValue / routing-param > > >> locationValue = LAQUOT locationURI RAQUOT > > >> *(SEMI geoloc-param) > > >> locationURI = sip-URI / sips-URI / pres-URI > > >> / http-URI / HTTPS-URI > > >> / cid-url ; (from RFC 2392) > > >> / absoluteURI ; (from RFC 3261) > > >> geoloc-param = generic-param; (from RFC 3261) > > >> routing-param = "routing-allowed" EQUAL "yes" / "no" > > >> > > >> The above is overly forgiving, in that it permits zero or more > > >> locationURIs and zero or more routing-params. That then needs to be > > >> tightened up with text. I think the text needs to say, > > more or less: > > >> > > >> - if there are any locationURIs in a sip request, > > >> then a routing-param MUST be present in the request > > >> - there MUST NOT be more than one routing-param present in a > > >> sip request. > > >> - there MUST NOT be more than two locationURIs in a sip request > > >> (if there is really a reason for such a restriction) > > >> > > >> 4) The following is a more radical change: > > >> > > >> Geolocation-header = "Geolocation" HCOLON locationValue > > >> [ COMMA locationValue ] > > >> locationValue = LAQUOT locationURI RAQUOT > > >> *(SEMI geoloc-param) > > >> locationURI = sip-URI / sips-URI / pres-URI > > >> / http-URI / HTTPS-URI > > >> / cid-url ; (from RFC 2392) > > >> / absoluteURI ; (from RFC 3261) > > >> geoloc-param = generic-param; (from RFC 3261) > > >> > > >> Georouting-header = "Geolocation-Routing" HCOLON > > >> ( "yes" / "no" / gen-value ) > > >> > > >> This one needs to be accompanied by text stating that each of > > >> Geolocation-header and Georouting-header may appear at most once > > >> in a request, and that if Georouting-header is absent it defaults > > >> to "no". > > >> > > >> 5) A more lenient variant on (4): > > >> > > >> Geolocation-header = "Geolocation" HCOLON locationValue > > >> *( COMMA locationValue ) > > >> locationValue = LAQUOT locationURI RAQUOT > > >> *(SEMI geoloc-param) > > >> locationURI = sip-URI / sips-URI / pres-URI > > >> / http-URI / HTTPS-URI > > >> / cid-url ; (from RFC 2392) > > >> / absoluteURI ; (from RFC 3261) > > >> geoloc-param = generic-param; (from RFC 3261) > > >> > > >> Georouting-header = "Geolocation-Routing" HCOLON > > >> ( "yes" / "no" / gen-value ) > > >> > > >> This one needs to be accompanied by text stating that > > >> Georouting-header may appear at most once in a request, and that > > >> if Georouting-header is absent it defaults to "no". > > >> > > >> (The Geolocation-header can appear zero or more times.) > > >> > > >> This is only preferred to (4) if more than two locationValues > > >> are acceptable. ISTM that once we allowed two, allowing more > > >> makes sense, with the same limitations imposed with two - that > > >> its up to the recipient to figure out which to use. > > >> > > >> Of the above, I technically and esthetically prefer (5) - or (4) if > > >> the limitation to two URIs is important. I see no reason > > to *require* > > >> the routing-param if the default is understood to be "no". > > >> > > >> Pragmatically I think I prefer (1) - its the least > > variation from what > > >> has been recently discussed that, IMO, makes any sense. > > >> > > >> > > >>>> In that case, an intermediary that adds a locationValue > > not only MAY, > > >>>> but presumably MUST add a missing routing-param if it adds a > > >>>> locationValue. > > >>> > > >>> We can get there (i.e., allow this) without stating this > > is a MUST, > > >>> can't we? > > >> > > >>>> I have never understood why the routing-param is > > required to be last. > > >>> > > >>> maybe it doesn't need to be, but it certainly is easier for > > >>> monitoring/reading human to find if it is last when > > looking at a decode. > > >>> > > >>>> And as my examples show, its difficult/impossible to > > enforce this in > > >>>> ABNF. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>> > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Thu Oct 28 18:05:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15ED3A67FA for ; Thu, 28 Oct 2010 18:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ReUsS7D7En for ; Thu, 28 Oct 2010 18:05:21 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4F88D3A67D0 for ; Thu, 28 Oct 2010 18:05:21 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="277542054" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2010 01:07:14 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9T17Emd002024; Fri, 29 Oct 2010 01:07:14 GMT Message-Id: <201010290107.o9T17Emd002024@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Oct 2010 20:07:12 -0500 To: "DRAGE, Keith (Keith)" , "Richard L. Barnes" , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 01:05:23 -0000 Keith I know you know this, but I'm going to say it anyway for those that don't. Having multiple locations is different that having multiple locationValues. The text has limited all locations to be about a single target (that was first introduced in -03). Within a PIDF-LO, there can be multiple locations (this has always been allowed). Having multiple locationValues, there is most likely going to be multiple PIDF-LOs. The Text in version -03 said 1 PIDF-LO, that can have multiple locations describing where the same target is. I want to make sure whether you are or you are not asking for multiple locationValues which likely lead to multiple PIDF-LOs. Is that what you really are after? Most of the previous to version -03 versions of Location-conveyance allowed multiple locationValues. The Jon's preso in Anaheim, which I am well away you were not a fan of, suggested that we can remove a LOT of complexity within this doc if we took away the ability to have multiple locationValues (and he's right on that account). But this flew in the face of Richard's rough-loc ID that called for the ability multiple locationValues, with each having a different granularity of the same Target (one coarse and one highly accurate). rev -04, the current version, allowed zero, one or two locationValues just to satisfy this second type of location (i.e., the rough-loc locationValue). Richard agree to allow us in -04 state this isn't a good idea, and I don't believe he's asking us to change that part today. I'm trying to tease out (exactly) what you want in -05 (which is obviously needed now for the ABNF changes, if nothing else). James At 08:01 AM 10/28/2010, DRAGE, Keith (Keith) wrote: >To be more specific - we had a document that allowed multiple >locations. It was reduced to one without any decision in that >direction being made by the working group. It needs to go back to >multiple values. > >In my view there are clear use cases where multiple values are required. > >regards > >Keith > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes > > Sent: Thursday, October 28, 2010 1:19 PM > > To: James M. Polk > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > >> I'm pretty comfortable with the document at this point, > > but have just > > >> one minor question: Why are you still limiting the number > > of location > > >> values? Why are three values harmful, but not two? This > > still seems > > >> like pointless ABNF legislation. > > > > > > we only added the ability to have a second locationValue because of > > > your rough-loc ID. Before that, we were firm in not > > allowing more than > > > one. Given that choice, which do you like? > > > > > > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it > > > seemed everyone and their brother was agreeable with, so ... > > > > > > As I recall, the proposal was to just remove the limit on the number > > of locations values, not to bump it up by one. From the minutes: > > > > "Restore Geolocation header that has multiple URIs, even though we > > would not recommend it. Entities inserting persence are responsbile > > for any resulting errors. The header parameters distinguishing URIs > > would not be added back in." > > > > At least in my mind, multiple != 2. > > > > --Richard > > > > > > > > > > > > > > > > > james > > > > > > > > >> --Richard > > >> > > >> > > >> > > >> > > >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > >> > > >>> SIPCORE > > >>> > > >>> I've submitted the next version of Location Conveyance (-04) > > >>> > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > n-conveyance-04.txt > > >>> and I believe this version has addressed each open item from the > > >>> mailing list, as well as what was discussed and agreed to in the > > >>> Maastricht meeting. > > >>> > > >>> I have attempted to identify each open issue with the specific > > >>> resolution here (in no particular order): > > >>> > > >>> - Martin wanted Section 3 to be broken up into subsections, each > > >>> revolving around each of the 4 diagrams. I have done this. > > >>> > > >>> - allowed a maximum of two (up from one) locationValues to be > > >>> present in the Geolocation header value. The text however > > recommends > > >>> against inserting a second value. This was agreed to in > > Maastricht. > > >>> > > >>> - Because we're allowing a max of two locationValues, > > they can be in > > >>> separate Geolocation headers in the SIP request. This scenario > > >>> necessitates bring a previous version's paragraph in > > stating that a > > >>> 'SIP intermediary MUST inspect all instances of each Geolocation > > >>> header before considering the routing-allowed parameter to be > > >>> considered =yes', to ensure there isn't a conflict in the 'other' > > >>> Geolocation header that states the policy is =no. > > >>> > > >>> - with the ability to add a second locationValue, it is > > necessary to > > >>> warn against doing this (confusion at the LRs). > > >>> > > >>> - Added the "you break it you bought it" philosophy to SIP > > >>> intermediaries that choose to insert a second location where one > > >>> already existed, especially for inserting a location URI in the > > >>> downstream SIP request. > > >>> > > >>> - Fixed the ABNF to handle zero, one or two (but no more) > > >>> locationValues according to the agreement in Maastricht. > > There is a > > >>> one-off use case which won't be in play very often, but > > is a WG item > > >>> in ECRIT that several wanted to allow the possibility for > > (involving > > >>> allowing one coarse and one highly accurate location in > > the same SIP > > >>> request). > > >>> > > >>> - Paul K. wanted the use-case in which a SIP intermediary > > inserts a > > >>> locationValue where one didn't exist previously, and > > received a 424 > > >>> (Bad Location Information) to that inserted location, from having > > >>> the 424 propagate towards the UAC (as the UAC might not > > know what to > > >>> do with a 424). This is now covered in Section 4.3. > > >>> > > >>> - changed existing text to "MUST NOT" from "does not" about a 424 > > >>> not terminating an existing dialog (just increased the strength of > > >>> this. > > >>> > > >>> - I added the 424 to the table 2 entry in which the Geolocation > > >>> header can be in only this response. > > >>> > > >>> - I added text stating the conditions for adding a Geolocation > > >>> header value to the 424, to make it clear what is and what isn't > > >>> allowed for this. > > >>> > > >>> - Martin wanted me to add back in the top level Geolocation-Error > > >>> codes 100, 200, 300 and 400, which I did in section 4.3. > > >>> > > >>> - rejected the idea that the geolocation option-tag hasn't been > > >>> justified. > > >>> > > >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > > references section > > >>> because I added the ability to include HTTP: and HTTPS: URIs, and > > >>> stated if received, they should be dereferenced according to the > > >>> HELD Deref doc. > > >>> > > >>> - changed the Section 5 examples how Martin wanted them. > > >>> > > >>> - Stated that GEO-URIs are not appropriate for the SIP Geolocation > > >>> header, according to the discussion during the Maastricht Geopriv > > >>> meeting. > > >>> > > >>> - we changed the privacy section, and included a ref to > > the Geopriv > > >>> Arch doc, according to the agreement in Geopriv at Maastricht. > > >>> > > >>> > > >>> Comments are encouraged > > >>> > > >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > > in Beijing > > >>> (to give folks a sense of our plans). > > >>> > > >>> James/Brian/Jon > > >>> > > >>> > > >>> _______________________________________________ > > >>> sipcore mailing list > > >>> sipcore@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > From john.elwell@siemens-enterprise.com Fri Oct 29 04:03:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5DC83A6940 for ; Fri, 29 Oct 2010 04:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYVbRbcI72q5 for ; Fri, 29 Oct 2010 04:03:45 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 62BAC3A6810 for ; Fri, 29 Oct 2010 04:03:45 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2108369; Fri, 29 Oct 2010 13:05:38 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CB51E23F028E; Fri, 29 Oct 2010 13:05:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 29 Oct 2010 13:05:38 +0200 From: "Elwell, John" To: "Barnes, Mary" Date: Fri, 29 Oct 2010 13:05:36 +0200 Thread-Topic: Status of comments on RFC 4244bis WGLC Thread-Index: Act3WTcP8HcYm8DcQpS64WX+M0v19w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: [sipcore] Status of comments on RFC 4244bis WGLC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 11:03:48 -0000 Mary, I don't recall seeing a response to my WGLC comments: http://www.ietf.org/mail-archive/web/sipcore/current/msg03238.html The diffs from 01 to 02 are quite extensive, so some of the text concerned = has disappeared or been changed for other reasons, so I will need to read t= he entire document again to see whether some of my concerns are addressed. = However, I noticed that at least some of my minor/editorial concerns appear= ed not to have been addressed, which made me wonder whether my comments had= been lost in the noise. I would appreciate feedback on any comments you we= re unable to deal with. Thanks, John From pkyzivat@cisco.com Fri Oct 29 06:02:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A44C3A69A6 for ; Fri, 29 Oct 2010 06:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F22OzH06di5W for ; Fri, 29 Oct 2010 06:02:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 189A63A6944 for ; Fri, 29 Oct 2010 06:02:37 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZiykxAZnwN/2dsb2JhbAChVHGhVZwrhUgEilODCA X-IronPort-AV: E=Sophos;i="4.58,259,1286150400"; d="scan'208";a="176334500" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2010 13:04:30 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9TD4UYS013697 for ; Fri, 29 Oct 2010 13:04:30 GMT Message-ID: <4CCAC65D.1030204@cisco.com> Date: Fri, 29 Oct 2010 09:04:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> <4CC90195.2070203@cisco.com> <201010290051.o9T0piCd016052@sj-core-5.cisco.com> In-Reply-To: <201010290051.o9T0piCd016052@sj-core-5.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:02:39 -0000 Its unclear to me how many people have opinions on this. It certainly can be one of the discussion points. If you like, I can make up some slides on the alternatives for use at the meeting. But it will be good if we can reduce the number of alternatives between now and then. ISTM there are basically two decisions to make about the syntax: - at most two URIs, or an unlimited number - routing-param part of same header, or a separate header The first of those is a real functionality discussion. (Or a computer science discussion of whether there is a number bigger than one other than "many".) The second is partly esthetic, and partly a technical issue for those writing sip parsers. Making it all one header causes it to be a one-off from a parser perspective. Thanks, Paul On 10/28/2010 8:51 PM, James M. Polk wrote: > At 05:38 AM 10/28/2010, Elwell, John wrote: >> Yes, 4 looks good, but I could live with 1. > > I think this has become #1 of two major open issues to address in > Beijing (along with the supported and unsupported URI schemes and their > respective possible error codes, as 2a and 2b). > > James > > >> John >> >> > -----Original Message----- >> > From: sipcore-bounces@ietf.org >> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Anders Kristensen >> > Sent: 28 October 2010 05:53 >> > To: sipcore@ietf.org >> > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 >> > >> > I haven't really followed the discussion closely but I'll say this >> > anyway. Many header fields are of a form similar to Geolocation, >> > essentially lists of URI, and allow for parameters. But I think the >> > parameters are pretty much always associated with individual >> > entries in >> > the list and may be present for more than one. >> > >> > From what I can tell, in the case of Geolocation, the >> > routing-allowed >> > param is not really attached to any particular entry in the list >> > suggesting that maybe it doesn't belong in the same header field. I >> > think that's the thinking that lead Paul to options 4 or 5 which seem >> > much preferable to me. That allows Geolocation to fit the text in RFC >> > 3261 that talks about combining header fields: >> > >> > Specifically, any SIP >> > header whose grammar is of the form >> > >> > header = "header-name" HCOLON header-value *(COMMA >> > header-value) >> > >> > allows for combining header fields of the same name into a comma- >> > separated list. >> > >> > Granted, there's no rule that says that header fields with >> > comma-separated values *must* fit the above grammar but ISTM >> > that it's a >> > pretty established pattern which is worth observing. >> > >> > Thanks, >> > Anders >> > >> > On 10/27/2010 9:10 PM, James M. Polk wrote: >> > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote: >> > >> I have a bunch inline here. >> > > >> > > I'll say ;-) >> > > >> > >> This supersedes my earlier suggested ABNF change. >> > > >> > > ack >> > > >> > > >> > >> On 10/27/2010 2:32 PM, James M. Polk wrote: >> > >>> Paul >> > >>> >> > >>> in-line >> > >>> >> > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >> > >>>> I took a quick look at the new version, and it seems to >> > have cleanup a >> > >>>> lot. But there *still* seems to be a problem with the syntax. >> > >>>> (Interplay between ABNF and text.) From the text, I find: >> > >>>> >> > >>>> The placement of the "routing-allowed" header field parameter, >> > >>>> strongly encouraged by [RFC5606], is outside the >> > locationValue, and >> > >>>> MUST always be last in the header field value. The >> > routing-allowed >> > >>>> parameter MUST be present, even when no locationValue is present. >> > >>>> >> > >>>> This is questionably supported by the ABNF: >> > >>>> >> > >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> > >>>> / routing-param >> > >>> >> > >>> the above, I believe - but am open to be corrected by >> > those better at >> > >>> ABNF syntax that I, says >> > >>> >> > >>> - the Geolocation header can optionally have one or more >> > locationValues >> > >>> - which are where the location URIs go >> > >> >> > >> The above says *a* Geolocation header can have >> > >> - one or two locationValues >> > >> - OR one routing-param >> > >> >> > >> (The slash means OR) >> > >> >> > >> But it doesn't state that the Geolocation header itself can appear >> > >> only once. And obviously if the goal is to have a >> > locationValue AND a >> > >> routing-param in the message, then with the above syntax >> > at least TWO >> > >> Geolocation headers will be required. >> > >> >> > >>> - but that the Geolocation header *will* have a routing-param >> > >>> - which is the "routing-allowed" paramter that RFC 5606 >> > wanted included >> > >> >> > >> Since the slash means OR, it doesn't mean it *will*. >> > >> >> > >>> The text of the ID then says that only zero, one or two >> > locationValues >> > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and >> > >>> ECRIT/GEOPRIV). >> > >>> >> > >>>> locationValue = LAQUOT locationURI RAQUOT >> > >>>> *(SEMI geoloc-param) >> > >>>> locationURI = sip-URI / sips-URI / pres-URI >> > >>>> / http-URI / HTTPS-URI >> > >>>> / cid-url ; (from RFC 2392) >> > >>>> / absoluteURI ; (from RFC 3261) >> > >>>> geoloc-param = generic-param; (from RFC 3261) >> > >>>> routing-param = "routing-allowed" EQUAL "yes" / "no" >> > >>>> >> > >>>> It only works if you presume that there are separate >> > occurrences of >> > >>>> GeoLocation-header in the message, one with just >> > locations, another >> > >>>> with just the routing-param. >> > >>> >> > >>> I don't get that part of your point, but I guess Martin's >> > next message >> > >>> says I need to add a "COMMA" after the ']' but before the >> > ')'. Would >> > >>> this satisfy your issue? >> > >> >> > >> Adding the COMMA and removing the slash would require the >> > >> routing-param, and would separate it from the >> > location-value. But then >> > >> if you only wanted the routing-param without any locationValues you >> > >> would have to write: >> > >> >> > >> Geolocation:,routing-allowed=no >> > >> >> > >> which is at least a bit weird, which I think is what Martin meant. >> > >> >> > >>>> The routing-param certainly can't be "last in the header >> > field value" >> > >>>> except in the degenerate sense, since it must be first >> > and only in a >> > >>>> Geolocation-header. >> > >>> >> > >>> If the routing-param was intended to be first, wouldn't >> > it appear first >> > >>> on this line? >> > >> >> > >> My point was that the syntax as written only allows >> > routing-param by >> > >> itself in a geolocation-header. E.g. >> > >> >> > >> Geolocation:routing-allowed=no >> > >> >> > >> It can't share a single Geolocation header with a >> > locationValue. Hence >> > >> it is *both* first and last in that header. >> > >> >> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> > >>>> / routing-param >> > >>> >> > >>> but it doesn't, so I'm confused. >> > >> >> > >> Again, the slash means OR. So you have: >> > >> >> > >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >> > >> OR >> > >> Geolocation-value = routing-param >> > >> >> > >> (Though you can't write it that way in ABNF. >> > >> >> > >>>> Below are some specific cases - both valid and invalid. >> > In each case I >> > >>>> show some headers bracketed by "...". That is intended >> > to mean other >> > >>>> headers in a message, but all in the same message. (And >> > when I show >> > >>>> multiple headers, there could be other non-geoloc >> > headers interleaved.) >> > >>>> >> > >>>> * The following are legal according to the above, and >> > probably within >> > >>>> expected usage: >> > >>>> >> > >>>> ... >> > >>>> Geolocation: cid:foo@example.com >> > >>>> Geolocation: routing-allowed=yes >> > >>>> ... >> > >>>> >> > >>>> ... >> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >> > >>>> Geolocation: routing-allowed=yes >> > >>>> ... >> > >>>> >> > >>>> ... >> > >>>> Geolocation: routing-allowed=no >> > >>>> ... >> > >>>> >> > >>>> * IIUC the following are allowed by the above both >> > syntactically and >> > >>>> according to the text, but is presumably not *intended* >> > to be valid. >> > >>>> (Its legal because the in each instance of Geolocation-header its >> > >>>> last.) >> > >>>> >> > >>>> ... >> > >>>> Geolocation: routing-allowed=no >> > >>>> Geolocation: routing-allowed=yes >> > >>>> ... >> > >>>> >> > >>>> The following is also allowed - I don't know if its >> > intended or not: >> > >>>> >> > >>>> ... >> > >>>> Geolocation: routing-allowed=yes >> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >> > >>>> ... >> > >>>> >> > >>>> * The following is allowed by the ABNF though disallowed >> > by the text: >> > >>>> >> > >>>> ... >> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >> > >>>> Geolocation: cid:baz@example.com >> > >>>> ... >> > >>>> >> > >>>> * The following is *not* allowed by the ABNF. I suspect >> > it might be >> > >>>> intended to be valid, but I'm far from sure about it: >> > >>>> >> > >>>> ... >> > >>>> Geolocation: cid:foo@example.com,routing-allowed=yes >> > >>>> ... >> > >>> >> > >>> to get this above example "allowed", would I correct the >> > existing ABNF >> > >>> to be >> > >>> >> > >>>> Geolocation-value = ( locationValue [ COMMA >> > locationValue ] COMMA ) >> > >>>> / routing-param >> > >>> >> > >>> ? >> > >> >> > >> No. *That* would allow all of the following but not the >> > example above: >> > >> >> > >> Geolocation: cid:foo@example.com, >> > >> Geolocation: cid:foo@example.com,cid:bar@example.com, >> > >> Geolocation: routing-allowed=yes >> > >> >> > >>>> In addition to that, the text is very explicit that: >> > >>>> >> > >>>> The routing-allowed >> > >>>> parameter MUST be present, even when no locationValue is present. >> > >>>> >> > >>>> but then it says: >> > >>>> >> > >>>> If no routing-allowed parameter >> > >>>> is present in a SIP request, a SIP intermediary MAY insert this >> > >>>> value with a RECOMMENDED value of "no" by default. >> > >>>> >> > >>>> So its required, but we have rules to follow if its >> > missing. But I >> > >>>> don't understand how it *can* be required, since the >> > sender of the >> > >>>> request may not understand/support Geolocation and so >> > won't include it. >> > >>> >> > >>> What we're trying to do here is explicitly give >> > instructions to SIP >> > >>> intermediary implementers to include the routing-allowed >> > parameter if >> > >>> one isn't present, with a default value of =no. >> > >> >> > >> I went back and reread the section containing this text. It is in a >> > >> section explicitly about this header. So on reflection I >> > suppose the >> > >> "MUST be present" was intended to imply "in the >> > Geolocation *header". >> > >> I took it to mean "in the request". >> > >> >> > >> Requiring it to be in the header only makes sense if there >> > can be at >> > >> most one header. And then it only makes sense if the >> > syntax is altered >> > >> to allow both the routing-parameter and the locationValue >> > in the same >> > >> header. >> > >> >> > >>>> ISTM that in reality its only *required* if the is a >> > locationValue >> > >>>> present, and is otherwise optional. >> > >>> >> > >>> which is how most would read it if ... >> > >>> >> > >>>> If no routing-allowed parameter >> > >>>> is present in a SIP request, a SIP intermediary MAY insert this >> > >>>> value with a RECOMMENDED value of "no" by default. >> > >>> >> > >>> ... weren't present in the document. But, there is no >> > permission to >> > >>> allow SIP intermediaries to add the routing-allowed >> > parameter, which we >> > >>> wanted to cover. >> > >> >> > >> I'm still confused. Let me state what I think you are after: >> > >> >> > >> - a request may or may not contain a Geolocation header >> > >> - a request may not contain more than one Geolocation header >> > > >> > > of what you have, this one is one I hadn't considered >> > important, but if >> > > that gets everything aligned, then I'm all for adding it in. >> > > >> > >> - a Geolocation header MUST contain a routing-param >> > >> - a Geolocation header Must contain zero, one, or two >> > locationValues >> > >> - you prefer the routing-param to be the last field in the header >> > >> - a proxy MAY add a Geolocation header if one is not present >> > >> (in which case it MUST include a routing-param) >> > >> - a proxy MAY add a locationValue to an existing Geolocation header >> > >> if it doesn't already have two locationValues. (And I guess it >> > >> could add two if there initially were none.) >> > >> >> > >> And you would like ABNF that is consistent with the above. >> > > >> > > with the one caveat, yes. >> > > >> > > >> > >> I'm going to give you some alternatives that should all be >> > >> syntactically correct. I'll give you one that meets the above, and >> > >> some others that may be more appealing variations. Then we can see >> > >> which people prefer. >> > >> >> > >> 1) The following tries to meet the requirements I spelled >> > out above: >> > >> >> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> > >> Geolocation-value = locationValue [ COMMA locationValue] >> > >> COMMA routing-param >> > >> / routing-param >> > > >> > > I hadn't even thought that was possible, but seeing it, I'm amazed I >> > > didn't try it >> > > >> > > (i.e., it's another classic "I could've had a v8" moment)... >> > > >> > > I'm not as smart as you, Paul <:-| >> > > >> > >> locationValue = LAQUOT locationURI RAQUOT >> > >> *(SEMI geoloc-param) >> > >> locationURI = sip-URI / sips-URI / pres-URI >> > >> / http-URI / HTTPS-URI >> > >> / cid-url ; (from RFC 2392) >> > >> / absoluteURI ; (from RFC 3261) >> > >> geoloc-param = generic-param; (from RFC 3261) >> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> > >> >> > >> This must be accompanied by text stating that there MUST be at most >> > >> one Geolocation-header in a request. >> > > >> > > you've sold me on this one (and yes, I examined all the >> > others before >> > > jumping on this first one!). Do others have strong opinions >> > about why >> > > not #1? >> > > >> > > thank you for this! >> > > >> > > James >> > > >> > > >> > >> 2) The following is similar to (1), but allows more than two >> > >> 'locationValue's >> > >> >> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> > >> Geolocation-value = *(locationValue COMMA) routing-param >> > >> locationValue = LAQUOT locationURI RAQUOT >> > >> *(SEMI geoloc-param) >> > >> locationURI = sip-URI / sips-URI / pres-URI >> > >> / http-URI / HTTPS-URI >> > >> / cid-url ; (from RFC 2392) >> > >> / absoluteURI ; (from RFC 3261) >> > >> geoloc-param = generic-param; (from RFC 3261) >> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> > >> >> > >> The same wording is required with it >> > >> >> > >> 3) The following is a copy from my earlier posting: >> > >> >> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >> > >> *( COMMA Geolocation-value) >> > >> Geolocation-value = locationValue / routing-param >> > >> locationValue = LAQUOT locationURI RAQUOT >> > >> *(SEMI geoloc-param) >> > >> locationURI = sip-URI / sips-URI / pres-URI >> > >> / http-URI / HTTPS-URI >> > >> / cid-url ; (from RFC 2392) >> > >> / absoluteURI ; (from RFC 3261) >> > >> geoloc-param = generic-param; (from RFC 3261) >> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >> > >> >> > >> The above is overly forgiving, in that it permits zero or more >> > >> locationURIs and zero or more routing-params. That then needs to be >> > >> tightened up with text. I think the text needs to say, >> > more or less: >> > >> >> > >> - if there are any locationURIs in a sip request, >> > >> then a routing-param MUST be present in the request >> > >> - there MUST NOT be more than one routing-param present in a >> > >> sip request. >> > >> - there MUST NOT be more than two locationURIs in a sip request >> > >> (if there is really a reason for such a restriction) >> > >> >> > >> 4) The following is a more radical change: >> > >> >> > >> Geolocation-header = "Geolocation" HCOLON locationValue >> > >> [ COMMA locationValue ] >> > >> locationValue = LAQUOT locationURI RAQUOT >> > >> *(SEMI geoloc-param) >> > >> locationURI = sip-URI / sips-URI / pres-URI >> > >> / http-URI / HTTPS-URI >> > >> / cid-url ; (from RFC 2392) >> > >> / absoluteURI ; (from RFC 3261) >> > >> geoloc-param = generic-param; (from RFC 3261) >> > >> >> > >> Georouting-header = "Geolocation-Routing" HCOLON >> > >> ( "yes" / "no" / gen-value ) >> > >> >> > >> This one needs to be accompanied by text stating that each of >> > >> Geolocation-header and Georouting-header may appear at most once >> > >> in a request, and that if Georouting-header is absent it defaults >> > >> to "no". >> > >> >> > >> 5) A more lenient variant on (4): >> > >> >> > >> Geolocation-header = "Geolocation" HCOLON locationValue >> > >> *( COMMA locationValue ) >> > >> locationValue = LAQUOT locationURI RAQUOT >> > >> *(SEMI geoloc-param) >> > >> locationURI = sip-URI / sips-URI / pres-URI >> > >> / http-URI / HTTPS-URI >> > >> / cid-url ; (from RFC 2392) >> > >> / absoluteURI ; (from RFC 3261) >> > >> geoloc-param = generic-param; (from RFC 3261) >> > >> >> > >> Georouting-header = "Geolocation-Routing" HCOLON >> > >> ( "yes" / "no" / gen-value ) >> > >> >> > >> This one needs to be accompanied by text stating that >> > >> Georouting-header may appear at most once in a request, and that >> > >> if Georouting-header is absent it defaults to "no". >> > >> >> > >> (The Geolocation-header can appear zero or more times.) >> > >> >> > >> This is only preferred to (4) if more than two locationValues >> > >> are acceptable. ISTM that once we allowed two, allowing more >> > >> makes sense, with the same limitations imposed with two - that >> > >> its up to the recipient to figure out which to use. >> > >> >> > >> Of the above, I technically and esthetically prefer (5) - or (4) if >> > >> the limitation to two URIs is important. I see no reason >> > to *require* >> > >> the routing-param if the default is understood to be "no". >> > >> >> > >> Pragmatically I think I prefer (1) - its the least >> > variation from what >> > >> has been recently discussed that, IMO, makes any sense. >> > >> >> > >> >> > >>>> In that case, an intermediary that adds a locationValue >> > not only MAY, >> > >>>> but presumably MUST add a missing routing-param if it adds a >> > >>>> locationValue. >> > >>> >> > >>> We can get there (i.e., allow this) without stating this >> > is a MUST, >> > >>> can't we? >> > >> >> > >>>> I have never understood why the routing-param is >> > required to be last. >> > >>> >> > >>> maybe it doesn't need to be, but it certainly is easier for >> > >>> monitoring/reading human to find if it is last when >> > looking at a decode. >> > >>> >> > >>>> And as my examples show, its difficult/impossible to >> > enforce this in >> > >>>> ABNF. >> > >>>> >> > >>>> Thanks, >> > >>>> Paul >> > >>> >> > > >> > > _______________________________________________ >> > > sipcore mailing list >> > > sipcore@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sipcore >> > > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From youssef.chadli@orange-ftgroup.com Fri Oct 29 09:18:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1F43A65A5 for ; Fri, 29 Oct 2010 09:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN6dyL-Q--i7 for ; Fri, 29 Oct 2010 09:18:08 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 8890A3A6405 for ; Fri, 29 Oct 2010 09:18:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BAEF8B800C; Fri, 29 Oct 2010 18:20:47 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4B7AD8B8002; Fri, 29 Oct 2010 18:20:47 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 18:20:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7785.22D1D2BB" Date: Fri, 29 Oct 2010 18:19:28 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141020FD42F@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-shen-interaction-ind-07 Thread-Index: Act3hQ9/WduVCoSmSduo11QqzTsrSw== From: To: , X-OriginalArrivalTime: 29 Oct 2010 16:20:01.0575 (UTC) FILETIME=[233D0B70:01CB7785] Subject: [sipcore] draft-shen-interaction-ind-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:18:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7785.22D1D2BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all,=20 The proposal in this draft to create a new header to carry information between SIP Application Servers to handle interactions between services provided between different AS, (that may be in different domains) is very interesting.=20 In fact, there several cases where SIP Application Servers need to exchange information on the features/services that has been executed for the being established session and information on the feature/services that are not compatible with the previously executed features/services. Below some examples of such interactions: Example 1: "Service Phone Number" is a service that allows the user to dial a unique phone number to join a commercial or public service. The "Service Phone Number" Application Server determines to which destination the call should be routed based on service logic criteria (e.g. location of the calling user, wishes of the calling users obtained after voice interaction, etc.). =20 In some situations, the "Service Phone Number" Application Server needs to inhibit call diversion of the routed-to destination. Let's take the example of a service that allows the calling user to dial a unique number to join the nearest and appropriate doctor. When the "Service Phone Number" AS routes the call to a given doctor, it needs to indicate that the call must not be diverted so that if this doctor is not available it can re-route the call to another destination.=20 >From the above examples, it appears that in order to handle conflicting interactions between supplementary services, Application Servers need to exchange the following information: 1) Indication of services or actions that must not be performed, possibly under conditions. 2) Downstream Application Servers receive the list of previously activated services with which they may have conflicting interactions. This is needed in order to handle interactions where the upstream Application Servers cannot determine all the features that are incompatible with their service. Example 2: For interaction with voicemail: - Some applications may needs to inhibit diversion of the call to voicemail. - Other applications may need to enforce the call to be diverted to voicemail.=20 Best regards,=20 Youssef CHADLI Orange Labs ------_=_NextPart_001_01CB7785.22D1D2BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [sipcore] draft-shen-interaction-ind-07

Hello all,

The proposal in this draft to create a = new header to carry information between SIP Application Servers to = handle interactions between services provided between different AS, = (that may be in different domains) is very interesting.

In fact, there several cases where SIP = Application Servers need to exchange information on the = features/services that has been executed for the being established = session and information on the feature/services that are not compatible = with the previously executed features/services.  Below some = examples of such interactions:

Example 1:
"Service Phone Number" is a = service that allows the user to dial a unique phone number to join a = commercial or public service. The "Service  Phone Number" = Application Server determines to which destination the call should be = routed based on service logic criteria (e.g. location of the calling = user, wishes of the calling users obtained after voice interaction, = etc.). 

In some situations, the "Service = Phone Number" Application Server needs to inhibit call diversion of = the routed-to destination. Let's take the example of a service that = allows the calling user to dial a unique number to join the nearest and = appropriate doctor. When the "Service  Phone Number" AS = routes the call to a given doctor, it needs to indicate that the call = must not be diverted so that if this doctor is not available it can = re-route the call to another destination.

From the above examples, it appears = that in order to handle conflicting interactions between supplementary = services, Application Servers need to exchange the following = information:

1) Indication of services or actions = that must not be performed, possibly under conditions.
2) Downstream Application Servers = receive the list of previously activated services with which they may = have conflicting interactions.  This is needed in order to handle = interactions where the upstream Application Servers cannot determine all = the features that are incompatible with their service.

Example 2:
For interaction with voicemail:
- Some applications may needs to = inhibit diversion of the call to voicemail.
- Other applications may need to = enforce the call to be diverted to voicemail.

Best regards,

Youssef CHADLI
Orange Labs

------_=_NextPart_001_01CB7785.22D1D2BB-- From youssef.chadli@orange-ftgroup.com Fri Oct 29 10:44:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30843A694C for ; Fri, 29 Oct 2010 10:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGWPkzWg37CX for ; Fri, 29 Oct 2010 10:44:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E3D493A67FC for ; Fri, 29 Oct 2010 10:44:38 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 775F38B8005; Fri, 29 Oct 2010 19:47:18 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 6C9A28B8002; Fri, 29 Oct 2010 19:47:18 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 19:46:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7791.38F68DC2" Date: Fri, 29 Oct 2010 19:46:31 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C7FDBEE.6080305@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSA References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr> <4C7FDBEE.6080305@nostrum.com> From: To: X-OriginalArrivalTime: 29 Oct 2010 17:46:30.0864 (UTC) FILETIME=[384BB500:01CB7791] Cc: sipcore@ietf.org Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 17:44:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7791.38F68DC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for this answer. =20 I understand that the intention of this text in RFC 3261 is to fail over = to an alternate server that serves the same function. Though, it's not = explicitly stated. =20 However, I did not find any text in RFC 3261 that would make forbidden = failing over to a proxy further down the path. Moreover, I did not see = any problem to such behaviour. =20 Youssef=20 ________________________________ De : Adam Roach [mailto:adam@nostrum.com]=20 Envoy=E9 : jeudi 2 septembre 2010 19:17 =C0 : CHADLI Youssef RD-CORE-ISS Cc : sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy [as participant] This is talking about failing over to an alternate server that serves = the same function, not a proxy further down the path. This is a bit = clearer if you look at section 4.3 of RFC 3263. Trying to fail "around" the server by going to the next network element = in the route would *not* be compliant with RFC 3261 behavior. /a On 9/2/10 11:56 AM, youssef.chadli@orange-ftgroup.com wrote:=20 Hi all,=20 I have a question regarding routeing of SIP requests and usage of = ROUTE.=20 When a proxy or UA fails to send a SIP request to the next hop (because = this latter is not reachable) is it allowed to bypass this hop and send = the request to the hop whose URI is next in ROUTE header. According to section 21.5.4 of RFC 3261, this proxy behaviour seems = allowed. See text in bold below:=20 Any opinions on this?=20 21.5.4 503 Service Unavailable=20 The server is temporarily unable to process the request due to a = temporary overloading or maintenance of the server. The server MAY = indicate when the client should retry the request in a Retry-After = header field. If no Retry-After is given, the client MUST act as if it = had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD = attempt to forward the request to an alternate server. It SHOULD NOT = forward any other requests to that server for the duration specified in = the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of = responding with 503 (Service Unavailable).=20 Youssef CHADLI=20 Orange Labs=20 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ------_=_NextPart_001_01CB7791.38F68DC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bypassing out-of-service intermediate Proxy

Thanks=20 for this answer.

 

I=20 understand that the intention of this text in RFC 3261 is to fail = over to=20 an alternate server that serves the same function. Though, it's not = explicitly=20 stated.

 

However,=20 I did not find any text in RFC 3261 that would make forbidden failing = over=20 to a proxy further down the path. =20 Moreover, I did not see any problem to such=20 behaviour.

 

Youssef 
De : Adam Roach = [mailto:adam@nostrum.com]=20
Envoy=E9 : jeudi 2 septembre 2010 = 19:17
=C0 : CHADLI=20 Youssef RD-CORE-ISS
Cc : = sipcore@ietf.org
Objet :=20 Re: [sipcore] Bypassing out-of-service intermediate = Proxy

[as participant]

This is talking about failing over to = an=20 alternate server that serves the same function, not a proxy further down = the=20 path. This is a bit clearer if you look at section 4.3 of RFC=20 3263.

Trying to fail "around" the server by going to the next = network=20 element in the route would *not* be compliant with RFC 3261=20 behavior.

/a

On 9/2/10 11:56 AM, youssef.chadli@orange-f= tgroup.com=20 wrote:=20

Hi = all,

I have a question = regarding=20 routeing of SIP requests and usage of ROUTE.

When a proxy or UA = fails to send a=20 SIP request to the next hop (because this latter is not reachable) is = it=20 allowed to bypass this hop and send the request to the hop whose URI = is next=20 in ROUTE header.

According to section = 21.5.4 of RFC=20 3261, this proxy behaviour seems allowed. See text in bold=20 below:

Any opinions on=20 this?

21.5.4 503 = Service=20 Unavailable


The = server is=20 temporarily unable to process the request due to a temporary = overloading or=20 maintenance of the server.  The server MAY indicate when the = client=20 should retry the request in a Retry-After header field.  If no=20 Retry-After is given, the client MUST act as if it had received a 500 = (Server=20 Internal Error) response.

A client = (proxy or UAC)=20 receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate=20 server.  It SHOULD = NOT forward=20 any other requests to that server for the duration specified in the=20 Retry-After header field, if present.

Servers = MAY refuse the=20 connection or drop the request instead of responding with 503 (Service = Unavailable).


Youssef = CHADLI=20
Orange Labs=20 




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

------_=_NextPart_001_01CB7791.38F68DC2-- From dworley@avaya.com Fri Oct 29 11:20:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36D53A69FF for ; Fri, 29 Oct 2010 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3MqTHQkxajb for ; Fri, 29 Oct 2010 11:20:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9C2573A69C4 for ; Fri, 29 Oct 2010 11:20:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="215962274" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Oct 2010 14:22:06 -0400 X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="534432196" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Oct 2010 14:22:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 29 Oct 2010 14:22:05 -0400 From: "Worley, Dale R (Dale)" To: "youssef.chadli@orange-ftgroup.com" , "adam@nostrum.com" Date: Fri, 29 Oct 2010 14:22:04 -0400 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSAAAMmKZU= Message-ID: References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr> <4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 18:20:33 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of yous= sef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] I understand that the intention of this text in RFC 3261 is to fail over to= an alternate server that serves the same function. Though, it's not explic= itly stated. However, I did not find any text in RFC 3261 that would make forbidden fail= ing over to a proxy further down the path. Moreover, I did not see any pro= blem to such behaviour. ________________________________ If a particular URI is included in a Route header, then there is some impor= tant function the server with that URI is to perform. If one element ignor= es this URI and sends the request to the next URI in the Route header, pres= umably the function of the skipped server will not be performed. In all cases that I have heard about, the correct way to provide alternate = servers for a failed server is to construct a DNS SRV name which maps to th= e primary and alternate server as is desired. For instance, if functionA is to be serviced by serverA but in an emergency= the request can be routed to serverB, and if functionB is serviced by serv= erB, then we construct two SRV names: functionA SRV serverA priority=3D1 functionA SRV serverB priority=3D2 functionB SRV serverB priority=3D1 and use this Route header: Route: sip:functionA, sip:functionB If an element has a request with this Route header, it will send the reques= t to sp:functionA using the RFC 3263 rules, viz., attempt to send to server= A, and if that fails, attempt to send to serverB. Dale From jmpolk@cisco.com Fri Oct 29 12:42:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F2F3A69AF for ; Fri, 29 Oct 2010 12:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.512 X-Spam-Level: X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCoCK7DAllD6 for ; Fri, 29 Oct 2010 12:42:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A4C73A682A for ; Fri, 29 Oct 2010 12:42:50 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,261,1286150400"; d="scan'208";a="611616631" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2010 19:44:45 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9TJiiXp013986; Fri, 29 Oct 2010 19:44:45 GMT Message-Id: <201010291944.o9TJiiXp013986@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Oct 2010 14:44:44 -0500 To: Paul Kyzivat , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <4CCAC65D.1030204@cisco.com> References: <20101025195020.1DA5A3A68E5@core3.amsl.com> <4CC78202.6090700@cisco.com> <201010271832.o9RIWAKi005558@sj-core-2.cisco.com> <4CC8BAC5.4030005@cisco.com> <201010280410.o9S4AhY6012387@sj-core-1.cisco.com> <4CC90195.2070203@cisco.com> <201010290051.o9T0piCd016052@sj-core-5.cisco.com> <4CCAC65D.1030204@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 19:42:53 -0000 At 08:04 AM 10/29/2010, Paul Kyzivat wrote: >Its unclear to me how many people have opinions on this. what's clear to me is people want fixed what is not subjective, i.e., the ABNF. From that, we do need to determine which of the 5 proposals you put out is the way forward. >It certainly can be one of the discussion points. >If you like, I can make up some slides on the alternatives for use >at the meeting. > >But it will be good if we can reduce the number of alternatives >between now and then. ISTM there are basically two decisions to make >about the syntax: > >- at most two URIs, or an unlimited number >- routing-param part of same header, or a separate header I agree with distilling it down to these two points wrt to the syntax. The first point is fairly easy (I think) if we're focused on addressing that one (at a time). The second point you bring up is very new (i.e., the idea of separate headers for these two indications). Once we focus on that idea, I think we can come to a conclusion without much difficulty. A third (multipart) point to bring up is related to the first point, if there are multiple URIs, 3a - do all recipients have to implement one or both URI scheme sets (i.e., SIP-based and HTTP-based), or just to one mandatory (and one should or may), or do we not mandate anything here (which has interoperability and effective communications implications). 3b - aside from independent of 3a, do we specify a specific error code for "URI scheme not supported, send (a specific) other URI scheme". 3b is exactly what John Elwell and I have been discussing, and involves 5 new, very specific 4XX level errors with really no room for misinterpretation: > 401 "URI scheme not supported - send SIP:URI" > 402 "URI scheme not supported - send SIPS:URI" > 403 "URI scheme not supported - send PRES:URI" > 404 "URI scheme not supported - send HTTP:URI" > 405 "URI scheme not supported - send HTTPS:URI" I know my coauthor will hyperventilate on this possibility because he wants as few error codes as is possible, but I think these are rather hard to argue against due to their specific meaning, and their actionable result ( - the UAC either sends a new SIP request with the requested URI scheme, or location isn't sent because that URI scheme isn't available to send). The UAC knows exactly what to do with this error, and if it doesn't send a location URI in the subsequent request, the UAS knows that URI scheme wasn't in the UAC to send. If the UAC can send the requested URI scheme, all's fine. The UAC can also make the choice to send a PIDF-LO (if it can) as a fall-back. >The first of those is a real functionality discussion. >(Or a computer science discussion of whether there is a number >bigger than one other than "many".) > >The second is partly esthetic, and partly a technical issue for >those writing sip parsers. Making it all one header causes it to be >a one-off from a parser perspective. I wish I knew more about this during the RFC 5606 debate, as that doc would have said something about necessitating a new SIP header to accomplish what it suggested, and we wouldn't be getting into this topic so (stickin`) late in the game. That said, location-conveyance is still an ID, so it's changeable- if we have consensus that's what's best. I think it might not be so hard to include this new header, as it'll have a rule that if an LR receives a SIP request with a SIP Geolocation header, that LR MUST look for and obey the policy flag set by the Geolocation-routing header value (or whatever we call the header). James > Thanks, > Paul > >On 10/28/2010 8:51 PM, James M. Polk wrote: >>At 05:38 AM 10/28/2010, Elwell, John wrote: >>>Yes, 4 looks good, but I could live with 1. >> >>I think this has become #1 of two major open issues to address in >>Beijing (along with the supported and unsupported URI schemes and their >>respective possible error codes, as 2a and 2b). >> >>James >> >> >>>John >>> >>> > -----Original Message----- >>> > From: sipcore-bounces@ietf.org >>> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Anders Kristensen >>> > Sent: 28 October 2010 05:53 >>> > To: sipcore@ietf.org >>> > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04 >>> > >>> > I haven't really followed the discussion closely but I'll say this >>> > anyway. Many header fields are of a form similar to Geolocation, >>> > essentially lists of URI, and allow for parameters. But I think the >>> > parameters are pretty much always associated with individual >>> > entries in >>> > the list and may be present for more than one. >>> > >>> > From what I can tell, in the case of Geolocation, the >>> > routing-allowed >>> > param is not really attached to any particular entry in the list >>> > suggesting that maybe it doesn't belong in the same header field. I >>> > think that's the thinking that lead Paul to options 4 or 5 which seem >>> > much preferable to me. That allows Geolocation to fit the text in RFC >>> > 3261 that talks about combining header fields: >>> > >>> > Specifically, any SIP >>> > header whose grammar is of the form >>> > >>> > header = "header-name" HCOLON header-value *(COMMA >>> > header-value) >>> > >>> > allows for combining header fields of the same name into a comma- >>> > separated list. >>> > >>> > Granted, there's no rule that says that header fields with >>> > comma-separated values *must* fit the above grammar but ISTM >>> > that it's a >>> > pretty established pattern which is worth observing. >>> > >>> > Thanks, >>> > Anders >>> > >>> > On 10/27/2010 9:10 PM, James M. Polk wrote: >>> > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote: >>> > >> I have a bunch inline here. >>> > > >>> > > I'll say ;-) >>> > > >>> > >> This supersedes my earlier suggested ABNF change. >>> > > >>> > > ack >>> > > >>> > > >>> > >> On 10/27/2010 2:32 PM, James M. Polk wrote: >>> > >>> Paul >>> > >>> >>> > >>> in-line >>> > >>> >>> > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote: >>> > >>>> I took a quick look at the new version, and it seems to >>> > have cleanup a >>> > >>>> lot. But there *still* seems to be a problem with the syntax. >>> > >>>> (Interplay between ABNF and text.) From the text, I find: >>> > >>>> >>> > >>>> The placement of the "routing-allowed" header field parameter, >>> > >>>> strongly encouraged by [RFC5606], is outside the >>> > locationValue, and >>> > >>>> MUST always be last in the header field value. The >>> > routing-allowed >>> > >>>> parameter MUST be present, even when no locationValue is present. >>> > >>>> >>> > >>>> This is questionably supported by the ABNF: >>> > >>>> >>> > >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value >>> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>> > >>>> / routing-param >>> > >>> >>> > >>> the above, I believe - but am open to be corrected by >>> > those better at >>> > >>> ABNF syntax that I, says >>> > >>> >>> > >>> - the Geolocation header can optionally have one or more >>> > locationValues >>> > >>> - which are where the location URIs go >>> > >> >>> > >> The above says *a* Geolocation header can have >>> > >> - one or two locationValues >>> > >> - OR one routing-param >>> > >> >>> > >> (The slash means OR) >>> > >> >>> > >> But it doesn't state that the Geolocation header itself can appear >>> > >> only once. And obviously if the goal is to have a >>> > locationValue AND a >>> > >> routing-param in the message, then with the above syntax >>> > at least TWO >>> > >> Geolocation headers will be required. >>> > >> >>> > >>> - but that the Geolocation header *will* have a routing-param >>> > >>> - which is the "routing-allowed" paramter that RFC 5606 >>> > wanted included >>> > >> >>> > >> Since the slash means OR, it doesn't mean it *will*. >>> > >> >>> > >>> The text of the ID then says that only zero, one or two >>> > locationValues >>> > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and >>> > >>> ECRIT/GEOPRIV). >>> > >>> >>> > >>>> locationValue = LAQUOT locationURI RAQUOT >>> > >>>> *(SEMI geoloc-param) >>> > >>>> locationURI = sip-URI / sips-URI / pres-URI >>> > >>>> / http-URI / HTTPS-URI >>> > >>>> / cid-url ; (from RFC 2392) >>> > >>>> / absoluteURI ; (from RFC 3261) >>> > >>>> geoloc-param = generic-param; (from RFC 3261) >>> > >>>> routing-param = "routing-allowed" EQUAL "yes" / "no" >>> > >>>> >>> > >>>> It only works if you presume that there are separate >>> > occurrences of >>> > >>>> GeoLocation-header in the message, one with just >>> > locations, another >>> > >>>> with just the routing-param. >>> > >>> >>> > >>> I don't get that part of your point, but I guess Martin's >>> > next message >>> > >>> says I need to add a "COMMA" after the ']' but before the >>> > ')'. Would >>> > >>> this satisfy your issue? >>> > >> >>> > >> Adding the COMMA and removing the slash would require the >>> > >> routing-param, and would separate it from the >>> > location-value. But then >>> > >> if you only wanted the routing-param without any locationValues you >>> > >> would have to write: >>> > >> >>> > >> Geolocation:,routing-allowed=no >>> > >> >>> > >> which is at least a bit weird, which I think is what Martin meant. >>> > >> >>> > >>>> The routing-param certainly can't be "last in the header >>> > field value" >>> > >>>> except in the degenerate sense, since it must be first >>> > and only in a >>> > >>>> Geolocation-header. >>> > >>> >>> > >>> If the routing-param was intended to be first, wouldn't >>> > it appear first >>> > >>> on this line? >>> > >> >>> > >> My point was that the syntax as written only allows >>> > routing-param by >>> > >> itself in a geolocation-header. E.g. >>> > >> >>> > >> Geolocation:routing-allowed=no >>> > >> >>> > >> It can't share a single Geolocation header with a >>> > locationValue. Hence >>> > >> it is *both* first and last in that header. >>> > >> >>> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>> > >>>> / routing-param >>> > >>> >>> > >>> but it doesn't, so I'm confused. >>> > >> >>> > >> Again, the slash means OR. So you have: >>> > >> >>> > >> Geolocation-value = ( locationValue [ COMMA locationValue ] ) >>> > >> OR >>> > >> Geolocation-value = routing-param >>> > >> >>> > >> (Though you can't write it that way in ABNF. >>> > >> >>> > >>>> Below are some specific cases - both valid and invalid. >>> > In each case I >>> > >>>> show some headers bracketed by "...". That is intended >>> > to mean other >>> > >>>> headers in a message, but all in the same message. (And >>> > when I show >>> > >>>> multiple headers, there could be other non-geoloc >>> > headers interleaved.) >>> > >>>> >>> > >>>> * The following are legal according to the above, and >>> > probably within >>> > >>>> expected usage: >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: cid:foo@example.com >>> > >>>> Geolocation: routing-allowed=yes >>> > >>>> ... >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>> > >>>> Geolocation: routing-allowed=yes >>> > >>>> ... >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: routing-allowed=no >>> > >>>> ... >>> > >>>> >>> > >>>> * IIUC the following are allowed by the above both >>> > syntactically and >>> > >>>> according to the text, but is presumably not *intended* >>> > to be valid. >>> > >>>> (Its legal because the in each instance of Geolocation-header its >>> > >>>> last.) >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: routing-allowed=no >>> > >>>> Geolocation: routing-allowed=yes >>> > >>>> ... >>> > >>>> >>> > >>>> The following is also allowed - I don't know if its >>> > intended or not: >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: routing-allowed=yes >>> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>> > >>>> ... >>> > >>>> >>> > >>>> * The following is allowed by the ABNF though disallowed >>> > by the text: >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: cid:foo@example.com,cid:bar@example.com >>> > >>>> Geolocation: cid:baz@example.com >>> > >>>> ... >>> > >>>> >>> > >>>> * The following is *not* allowed by the ABNF. I suspect >>> > it might be >>> > >>>> intended to be valid, but I'm far from sure about it: >>> > >>>> >>> > >>>> ... >>> > >>>> Geolocation: cid:foo@example.com,routing-allowed=yes >>> > >>>> ... >>> > >>> >>> > >>> to get this above example "allowed", would I correct the >>> > existing ABNF >>> > >>> to be >>> > >>> >>> > >>>> Geolocation-value = ( locationValue [ COMMA >>> > locationValue ] COMMA ) >>> > >>>> / routing-param >>> > >>> >>> > >>> ? >>> > >> >>> > >> No. *That* would allow all of the following but not the >>> > example above: >>> > >> >>> > >> Geolocation: cid:foo@example.com, >>> > >> Geolocation: cid:foo@example.com,cid:bar@example.com, >>> > >> Geolocation: routing-allowed=yes >>> > >> >>> > >>>> In addition to that, the text is very explicit that: >>> > >>>> >>> > >>>> The routing-allowed >>> > >>>> parameter MUST be present, even when no locationValue is present. >>> > >>>> >>> > >>>> but then it says: >>> > >>>> >>> > >>>> If no routing-allowed parameter >>> > >>>> is present in a SIP request, a SIP intermediary MAY insert this >>> > >>>> value with a RECOMMENDED value of "no" by default. >>> > >>>> >>> > >>>> So its required, but we have rules to follow if its >>> > missing. But I >>> > >>>> don't understand how it *can* be required, since the >>> > sender of the >>> > >>>> request may not understand/support Geolocation and so >>> > won't include it. >>> > >>> >>> > >>> What we're trying to do here is explicitly give >>> > instructions to SIP >>> > >>> intermediary implementers to include the routing-allowed >>> > parameter if >>> > >>> one isn't present, with a default value of =no. >>> > >> >>> > >> I went back and reread the section containing this text. It is in a >>> > >> section explicitly about this header. So on reflection I >>> > suppose the >>> > >> "MUST be present" was intended to imply "in the >>> > Geolocation *header". >>> > >> I took it to mean "in the request". >>> > >> >>> > >> Requiring it to be in the header only makes sense if there >>> > can be at >>> > >> most one header. And then it only makes sense if the >>> > syntax is altered >>> > >> to allow both the routing-parameter and the locationValue >>> > in the same >>> > >> header. >>> > >> >>> > >>>> ISTM that in reality its only *required* if the is a >>> > locationValue >>> > >>>> present, and is otherwise optional. >>> > >>> >>> > >>> which is how most would read it if ... >>> > >>> >>> > >>>> If no routing-allowed parameter >>> > >>>> is present in a SIP request, a SIP intermediary MAY insert this >>> > >>>> value with a RECOMMENDED value of "no" by default. >>> > >>> >>> > >>> ... weren't present in the document. But, there is no >>> > permission to >>> > >>> allow SIP intermediaries to add the routing-allowed >>> > parameter, which we >>> > >>> wanted to cover. >>> > >> >>> > >> I'm still confused. Let me state what I think you are after: >>> > >> >>> > >> - a request may or may not contain a Geolocation header >>> > >> - a request may not contain more than one Geolocation header >>> > > >>> > > of what you have, this one is one I hadn't considered >>> > important, but if >>> > > that gets everything aligned, then I'm all for adding it in. >>> > > >>> > >> - a Geolocation header MUST contain a routing-param >>> > >> - a Geolocation header Must contain zero, one, or two >>> > locationValues >>> > >> - you prefer the routing-param to be the last field in the header >>> > >> - a proxy MAY add a Geolocation header if one is not present >>> > >> (in which case it MUST include a routing-param) >>> > >> - a proxy MAY add a locationValue to an existing Geolocation header >>> > >> if it doesn't already have two locationValues. (And I guess it >>> > >> could add two if there initially were none.) >>> > >> >>> > >> And you would like ABNF that is consistent with the above. >>> > > >>> > > with the one caveat, yes. >>> > > >>> > > >>> > >> I'm going to give you some alternatives that should all be >>> > >> syntactically correct. I'll give you one that meets the above, and >>> > >> some others that may be more appealing variations. Then we can see >>> > >> which people prefer. >>> > >> >>> > >> 1) The following tries to meet the requirements I spelled >>> > out above: >>> > >> >>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >>> > >> Geolocation-value = locationValue [ COMMA locationValue] >>> > >> COMMA routing-param >>> > >> / routing-param >>> > > >>> > > I hadn't even thought that was possible, but seeing it, I'm amazed I >>> > > didn't try it >>> > > >>> > > (i.e., it's another classic "I could've had a v8" moment)... >>> > > >>> > > I'm not as smart as you, Paul <:-| >>> > > >>> > >> locationValue = LAQUOT locationURI RAQUOT >>> > >> *(SEMI geoloc-param) >>> > >> locationURI = sip-URI / sips-URI / pres-URI >>> > >> / http-URI / HTTPS-URI >>> > >> / cid-url ; (from RFC 2392) >>> > >> / absoluteURI ; (from RFC 3261) >>> > >> geoloc-param = generic-param; (from RFC 3261) >>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >>> > >> >>> > >> This must be accompanied by text stating that there MUST be at most >>> > >> one Geolocation-header in a request. >>> > > >>> > > you've sold me on this one (and yes, I examined all the >>> > others before >>> > > jumping on this first one!). Do others have strong opinions >>> > about why >>> > > not #1? >>> > > >>> > > thank you for this! >>> > > >>> > > James >>> > > >>> > > >>> > >> 2) The following is similar to (1), but allows more than two >>> > >> 'locationValue's >>> > >> >>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >>> > >> Geolocation-value = *(locationValue COMMA) routing-param >>> > >> locationValue = LAQUOT locationURI RAQUOT >>> > >> *(SEMI geoloc-param) >>> > >> locationURI = sip-URI / sips-URI / pres-URI >>> > >> / http-URI / HTTPS-URI >>> > >> / cid-url ; (from RFC 2392) >>> > >> / absoluteURI ; (from RFC 3261) >>> > >> geoloc-param = generic-param; (from RFC 3261) >>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >>> > >> >>> > >> The same wording is required with it >>> > >> >>> > >> 3) The following is a copy from my earlier posting: >>> > >> >>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value >>> > >> *( COMMA Geolocation-value) >>> > >> Geolocation-value = locationValue / routing-param >>> > >> locationValue = LAQUOT locationURI RAQUOT >>> > >> *(SEMI geoloc-param) >>> > >> locationURI = sip-URI / sips-URI / pres-URI >>> > >> / http-URI / HTTPS-URI >>> > >> / cid-url ; (from RFC 2392) >>> > >> / absoluteURI ; (from RFC 3261) >>> > >> geoloc-param = generic-param; (from RFC 3261) >>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no" >>> > >> >>> > >> The above is overly forgiving, in that it permits zero or more >>> > >> locationURIs and zero or more routing-params. That then needs to be >>> > >> tightened up with text. I think the text needs to say, >>> > more or less: >>> > >> >>> > >> - if there are any locationURIs in a sip request, >>> > >> then a routing-param MUST be present in the request >>> > >> - there MUST NOT be more than one routing-param present in a >>> > >> sip request. >>> > >> - there MUST NOT be more than two locationURIs in a sip request >>> > >> (if there is really a reason for such a restriction) >>> > >> >>> > >> 4) The following is a more radical change: >>> > >> >>> > >> Geolocation-header = "Geolocation" HCOLON locationValue >>> > >> [ COMMA locationValue ] >>> > >> locationValue = LAQUOT locationURI RAQUOT >>> > >> *(SEMI geoloc-param) >>> > >> locationURI = sip-URI / sips-URI / pres-URI >>> > >> / http-URI / HTTPS-URI >>> > >> / cid-url ; (from RFC 2392) >>> > >> / absoluteURI ; (from RFC 3261) >>> > >> geoloc-param = generic-param; (from RFC 3261) >>> > >> >>> > >> Georouting-header = "Geolocation-Routing" HCOLON >>> > >> ( "yes" / "no" / gen-value ) >>> > >> >>> > >> This one needs to be accompanied by text stating that each of >>> > >> Geolocation-header and Georouting-header may appear at most once >>> > >> in a request, and that if Georouting-header is absent it defaults >>> > >> to "no". >>> > >> >>> > >> 5) A more lenient variant on (4): >>> > >> >>> > >> Geolocation-header = "Geolocation" HCOLON locationValue >>> > >> *( COMMA locationValue ) >>> > >> locationValue = LAQUOT locationURI RAQUOT >>> > >> *(SEMI geoloc-param) >>> > >> locationURI = sip-URI / sips-URI / pres-URI >>> > >> / http-URI / HTTPS-URI >>> > >> / cid-url ; (from RFC 2392) >>> > >> / absoluteURI ; (from RFC 3261) >>> > >> geoloc-param = generic-param; (from RFC 3261) >>> > >> >>> > >> Georouting-header = "Geolocation-Routing" HCOLON >>> > >> ( "yes" / "no" / gen-value ) >>> > >> >>> > >> This one needs to be accompanied by text stating that >>> > >> Georouting-header may appear at most once in a request, and that >>> > >> if Georouting-header is absent it defaults to "no". >>> > >> >>> > >> (The Geolocation-header can appear zero or more times.) >>> > >> >>> > >> This is only preferred to (4) if more than two locationValues >>> > >> are acceptable. ISTM that once we allowed two, allowing more >>> > >> makes sense, with the same limitations imposed with two - that >>> > >> its up to the recipient to figure out which to use. >>> > >> >>> > >> Of the above, I technically and esthetically prefer (5) - or (4) if >>> > >> the limitation to two URIs is important. I see no reason >>> > to *require* >>> > >> the routing-param if the default is understood to be "no". >>> > >> >>> > >> Pragmatically I think I prefer (1) - its the least >>> > variation from what >>> > >> has been recently discussed that, IMO, makes any sense. >>> > >> >>> > >> >>> > >>>> In that case, an intermediary that adds a locationValue >>> > not only MAY, >>> > >>>> but presumably MUST add a missing routing-param if it adds a >>> > >>>> locationValue. >>> > >>> >>> > >>> We can get there (i.e., allow this) without stating this >>> > is a MUST, >>> > >>> can't we? >>> > >> >>> > >>>> I have never understood why the routing-param is >>> > required to be last. >>> > >>> >>> > >>> maybe it doesn't need to be, but it certainly is easier for >>> > >>> monitoring/reading human to find if it is last when >>> > looking at a decode. >>> > >>> >>> > >>>> And as my examples show, its difficult/impossible to >>> > enforce this in >>> > >>>> ABNF. >>> > >>>> >>> > >>>> Thanks, >>> > >>>> Paul >>> > >>> >>> > > >>> > > _______________________________________________ >>> > > sipcore mailing list >>> > > sipcore@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/sipcore >>> > > >>> > _______________________________________________ >>> > sipcore mailing list >>> > sipcore@ietf.org >>> > https://www.ietf.org/mailman/listinfo/sipcore >>> > >>>_______________________________________________ >>>sipcore mailing list >>>sipcore@ietf.org >>>https://www.ietf.org/mailman/listinfo/sipcore >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore