From worley@shell01.TheWorld.com Fri Mar 1 13:19:17 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DAE1F0D0B for ; Fri, 1 Mar 2013 13:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCvt8oXoMvvs for ; Fri, 1 Mar 2013 13:19:16 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D7A6A1F0D0C for ; Fri, 1 Mar 2013 13:19:15 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r21LJ1TP022887 for ; Fri, 1 Mar 2013 16:19:03 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r21LJ0852855872 for ; Fri, 1 Mar 2013 16:19:00 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r21LJ0mg2857344; Fri, 1 Mar 2013 16:19:00 -0500 (EST) Date: Fri, 1 Mar 2013 16:19:00 -0500 (EST) Message-Id: <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> Subject: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 21:19:17 -0000 I've gone through draft-ietf-sipcore-rfc4244bis-callflows-02. I haven't examine everything in the SIP messages. Instead, I've concentrated on the History-Info headers in the "final" messages of the sequences. In each example, there is a final message that contains all of the information in all of the History-Info headers. I believe that the following amendments should be made in examles 3.1, 3.6, and 3.7. These amendments include a number of things that have been discussed on the Sipcore mailing list. 3.1. Sequentially Forking (History-Info in Response) Alice example.com Bob Office Home | | | | | | INVITE F1 | | | | |----------->| INVITE F2 | | | | |----------------->| | | | 100 Trying F3 | | | |<-----------| 302 Move Temporarily F4 | | | |<-----------------| | | | | ACK F5 | | | | |----------------->| | | | | INVITE F6 | | | |-------------------------->| | | | 180 Ringing F7 | | | |<--------------------------| | | 180 Ringing F8 | | |<-----------| retransmit INVITE | | | |-------------------------->| | | | ( timeout ) | | | | INVITE F9 | | |----------------------------------->| | | 100 Trying F10 | | |<-----------------------------------| | | 486 Busy Here F11 | | |<-----------------------------------| | 486 Busy Here F12 | |<-----------| ACK F13 | | |----------------------------------->| | ACK F14 | | |----------->| | In these examples, I have added Reason values to hi-entries that have effectively received failure responses due to the failure of their internally redirected targets. Doing so is optional per draft-4244bis but it seems to me to be the best practice. That is, I believe that the results of internal retargeting should be the same as if the second retargeting was done in a different proxy. F12 486 Busy Here example.com -> alice History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 - History-Info: ;index=1.2;mp=1 + History-Info: ;\ + index=1.2;mp=1 History-Info: ;\ - index=1.2.1;index=1.2.1;rc=1.2 + index=1.2.1;rc=1.2 History-Info: ;index=1.3;mp=1 History-Info: ;index=1.3.1;rc=1.3 3.6. PBX Voicemail Example Alice example.com Bob Carol VM | INVITE F1 | | | | |------------->| | | | | | INVITE F2 | | | | |------------->| | | | | | | | | 100 Trying | | | | |<-------------| 302 Moved Temporarily F3 | | | |<-------------| | | | | | | | | ACK | | | |---------------------------->| | | | | | | | | | INVITE F4 | | | | |--------------------------->| | | | | | | | | 180 Ringing F5 | | | |<---------------------------| | | | | | | | 180 Ringing | | | | |<-------------| | | | | | | | | | | (timeout) | | | | | | | | | INVITE F6 | | | | |-------------------------------------->| | | | | | | | 200 OK F7 | | |<--------------------------------------| | 200 OK | | | | |<-------------| | | | | | | | | | ACK | |----------------------------------------------------->| Here, I assume we are using the "cause" URI parameter to indicate redirection reasons per RFC 4458. The redirection from Bob to Carol is "Deflection immediate response", which is translated into the SIP cause 480. The redirection from Carol to VM is "No reply", which is translated into SIP cause 408. We assume the "cause" parameter is preserved when AORs are mapped to their contacts. Here, we choose the "cause" that is sent to VM to be 408, because the immediately preceeding INVITE failed due to 408. But the VM box is Bob's, and the call to Bob failed due to cause=480. The choice probably depends on the application logic rather than standards. (History-Info, however, captures the entire history of the call.) The Reason value for index 1.2.1 has been corrected to 408. F7 200 OK VM -> Example.com History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 - History-Info: ;index=1.2;mp=1 - History-Info: ;\ - index=1.2.1;rc=1.2 - History-Info: ;\ - index=1.3;mp=1 - History-Info: ;\ - index=1.3.1;rc=1.3 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;\ + index=1.3;mp=1 + History-Info: ;\ + index=1.3.1;rc=1.3 3.7. Consumer Voicemail Example Alice example.com Bob Carol VM | INVITE F1 | | | | |------------->| | | | | | INVITE F2 | | | | |------------->| | | | | | | | | 100 Trying | | | | |<-------------| 302 Moved Temporarily F3 | | | |<-------------| | | | | | | | | ACK | | | |---------------------------->| | | | | | | | | | INVITE F4 | | | | |--------------------------->| | | | | | | | | 180 Ringing F5 | | | |<---------------------------| | | | | | | | 180 Ringing | | | | |<-------------| | | | | | | | | | | (timeout) | | | | | | | | | INVITE F6 | | | | |-------------------------------------->| | | | | | | | 200 OK F7 | | |<--------------------------------------| | 200 OK | | | | |<-------------| | | | | | | | | | ACK | |----------------------------------------------------->| Here, hi-entry 1.2.1 should have a Reason value, but the Reason value on 1.2 is optional. Since is generated from (index 1.2), it should have index 1.2.2, not 1.3. F7 200 OK VM -> Example.com History-Info: ;index=1 History-Info: \ + %3Btext%3D%22Moved%20Temporarily%22>\ ;index=1.1;rc=1 History-Info: ;\ index=1.2;mp=1 - History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;\ + index=1.2.1;rc=1.2 History-Info: ;\ - index=1.3;mp=1.2 + index=1.2.2;mp=1.2 History-Info: ;\ - index=1.3.1;rc=1.3 + index=1.2.2.1;rc=1.2.1 Dale From wwwrun@rfc-editor.org Fri Mar 1 16:01:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0CA21E80CB; Fri, 1 Mar 2013 16:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXOCF15xHslR; Fri, 1 Mar 2013 16:01:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0170F21E810C; Fri, 1 Mar 2013 16:01:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9C219B1E00D; Fri, 1 Mar 2013 16:01:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130302000152.9C219B1E00D@rfc-editor.org> Date: Fri, 1 Mar 2013 16:01:52 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6878 on IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 00:01:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6878 Title: IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field Author: A.B. Roach Status: Standards Track Stream: IETF Date: March 2013 Mailbox: adam@nostrum.com Pages: 3 Characters: 4688 Updates: RFC3261 I-D Tag: draft-ietf-sipcore-priority-00.txt URL: http://www.rfc-editor.org/rfc/rfc6878.txt This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From rjsparks@nostrum.com Mon Mar 4 14:05:38 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66421F8C2A for ; Mon, 4 Mar 2013 14:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59xLUVpFJ0e2 for ; Mon, 4 Mar 2013 14:05:37 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 390FD21F8A94 for ; Mon, 4 Mar 2013 14:05:37 -0800 (PST) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r24M5aKd095351 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 4 Mar 2013 16:05:36 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <51351AB0.1080005@nostrum.com> Date: Mon, 04 Mar 2013 16:05:36 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <512E35D2.6080400@nostrum.com> <9BB7865E-2142-4FC3-B846-A8B03B158635@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:05:38 -0000 repeating a thought just to make sure it was seen in this context On 2/27/13 7:05 PM, DRAGE, Keith (Keith) wrote: > Brian wrote: >> I don't >> think Specification Required is adequate -- I want IETF experts to review. > If it is specification required then IETF experts will review. > > Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification, in sufficient detail so that interoperability > between independent implementations is possible. When used, > Specification Required also implies use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations. The intention behind > "permanent and readily available" is that a document can > reasonably be expected to be findable and retrievable long > after IANA assignment of the requested value. Publication > of an RFC is an ideal means of achieving this requirement, > but Specification Required is intended to also cover the > case of a document published outside of the RFC path. For > RFC publication, the normal RFC review process is expected > to provide the necessary review for interoperability, though > the Designated Expert may be a particularly well-qualified > person to perform such a review. > > So to be clear, it gets review as follows: > > - by the experts involved in the original public specification by some other organization > - by the designated expert > > I am not sure that the designated expert has to be a single expert - it could be several people - the ADs just need to put it in place. That means we have a small number of people that we could identify to delegate review to for the whole community, and the community would trust they would see all the potential issues a proposal brings. In this case, I think we're not there yet, and actually _do_ want full community review. As I said before, I think the right thing to do is take incremental steps with this one. Get some experience with IETF review, and shift to something that only required expert review later. > > Regards > > Keith > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: 27 February 2013 20:13 >> To: DRAGE, Keith (Keith) >> Cc: Adam Roach; SIPCORE; draft-rosen-rph-reg-policy@tools.ietf.org >> Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy- >> 00 >> >> We can fix 1 at AUTH48 if WGLC proceeds. >> >> The document doesn't have to say why a particular management policy was >> chosen. It has to be the appropriate policy that the IETF agrees on. In >> this case, we think an Informational RFC is adequate to add a new >> namespace but doesn't define new protocol behavior. We think IETF Review >> is appropriate, so that we get review by the rather distributed >> constituency that cares about this particular piece of stuff. I don't >> think Specification Required is adequate -- I want IETF experts to review. >> I don't even think Expert Review is adequate, because we do have several >> different classes of people who care about various aspects of this. >> >> While I somewhat agree that 4412 is light on text defining when a new >> namespace is appropriate, it isn't the purpose of this document to rewrite >> that text, but rather to fix a specific problem that holds up other RFCs. >> If the policy is left at Standards Track, it still doesn't define when a >> new namespace is appropriate. It still doesn't define whether an update >> to an existing namespace is required. >> >> We could start an effort to do a 4412-bis to address these issues, but I >> would prefer not to turn this document into that. >> >> Brian >> >> >> On Feb 27, 2013, at 2:48 PM, "DRAGE, Keith (Keith)" > lucent.com> wrote: >> >>> I do not have a problem with relaxing the criteria and therefore we will >> need an I-D to do that, and therefore a milestone to cover that task. >>> I have the following comments on the document. >>> >>> 1) Editorial. The document states internally that it updates RFC 4412 >> and this is correct. However that information also needs to appear in the >> top left of the document. >>> 2) The document gives no background material on why IETF review has >> been chosen, only that it no longer needs to be standards track (Note that >> I am not convinced "Standards Track" was selected in error). Personally I >> think "Specification Required" would be entirely appropriate, however if >> this is used see comment 3) below. >>> 3) As more relaxed criteria for IANA registration are defined, then >> material has to be defined to support those reviewing the registration; >> for a standards track defined protocol, this should be defined in a >> standards track document. For example RFC 4412 contains no information on >> when a new namespace is appropriate, as opposed to reuse of an existing >> namespaces. I have certainly been involved in discussions as to whether >> the "ETS" namespace is restricted only to usage of "US government >> telecommunications service" or whether another government body in a >> different country with identical requirements can reuse the same namespace, >> or whether they have to define a new namespace, and RFC 4412 does not >> answer this. So the proposed update currently contains no additional >> information (to RFC 4412) on: >>> - what information needs to be provided for a new namespace or >> priority level; >>> - what criteria need to be met for adopting a new namespace or >> priority level, versus reusing or modifying an existing one. >>> 4) Can a new document update an existing namespace with new priority >> levels or other functionality? I believe this would normally be bad >> practice for compatibility reasons, but the document does not cover this. >>> Keith >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf >>>> Of Adam Roach >>>> Sent: 27 February 2013 16:36 >>>> To: 'SIPCORE' >>>> Cc: draft-rosen-rph-reg-policy@tools.ietf.org >>>> Subject: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy- >> 00 >>>> [as chair] >>>> >>>> During the processing of draft-polk-local-emergency-rph-namespace, the >>>> IESG, authors, and WG chairs determined that the policy described in >>>> RFC4412, section 9 for defining a new namespace (Standards-Track RFC) >>>> was probably selected in error, and that "IETF Review" is likely more >>>> appropriate. The ECRIT working group has already been informed of this >>>> situation, and no parties have objected to a change in policy: >>>> >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html >>>> >>>> Since this is a policy change to a core SIP header, our Area Director >>>> has requested that the document that formally changes the policy be >>>> processed as a SIPCORE document. The current draft is available here: >>>> >>>> http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00 >>>> >>>> (Aside: ignoring the boilerplate, references, and table of contents, >> the >>>> document is about half as long as this email, and should take less time >>>> to read). >>>> >>>> This message starts a call for adoption in parallel with a working >> group >>>> last call. Both periods end in just over two weeks, on Friday, March >>>> 15th (the final Friday of the Orlando IETF meeting). Please reply to >> the >>>> mailing list indicating support or opposition to such adoption, and >> with >>>> any comments on the document contents themselves. >>>> >>>> /a >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Mon Mar 4 14:21:48 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607CA21F8CAC for ; Mon, 4 Mar 2013 14:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgf1c3sRGy9L for ; Mon, 4 Mar 2013 14:21:46 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id DB2A821F8CAE for ; Mon, 4 Mar 2013 14:21:45 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j8so1520256qah.20 for ; Mon, 04 Mar 2013 14:21:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=r6Q7y0Iu4IbzhaHOG8LkaxYYEDsciRJ0NanGfC6SkBg=; b=FPtrqgu9YDmZ5OON94KQoolIZewQ2ndmKe2ydauyaw5196l7jmWKp7tMsVBaYESNjK 3YYn8eJVF7KOH6JV4f9jQl98BeIEenUtbVxVH+z061ux3TpnOTquAdc+ajQ6eSvao300 K3jsMqvn4z7WTSC0vamHGd2iYmkMkiThlRaujWpTOuwsPLMt3rrg3lBbDLtpqeRGxf94 Qq/jGrywK/pP3ryG3afN111J7iHWg00Gdqt/iVB7sAkIdgZ7HpXHdU/YtXjHOSVXe0ej vnrrjq6WSg6UnamayBmnHAdrW/D+yTcJrHBKnZggi49NBFk3OZiLG1l/nDqA47iGpi4M ZWZQ== X-Received: by 10.229.76.37 with SMTP id a37mr6452115qck.130.1362435703272; Mon, 04 Mar 2013 14:21:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Mon, 4 Mar 2013 14:21:23 -0800 (PST) In-Reply-To: <512BDEED.9030706@nostrum.com> References: <50B5404A.20807@nostrum.com> <512BDEED.9030706@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 4 Mar 2013 23:21:23 +0100 Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm+iaLXzM9Wtac+UvO8xRK2be0buovUW1hUbzNisygD8awrSb9xw0HKbB6t+xNTpheZ4SjL Cc: "sipcore@ietf.org" , draft-ietf-sipcore-sip-websocket@tools.ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:21:48 -0000 Hi Robert, please read below: 2013/2/25 Robert Sparks : > Hi I=C3=B1aki (and SIPCORE participants): > > One thing from my initial review that I don't think I've seen a response = to > (nor do I see how the draft revision addressed it) - > apologies if we had discussed this and I've forgotten: > > > > On 11/27/12 4:35 PM, Robert Sparks wrote: >> >> * Should there be some additional discussion of what an element should d= o if someone clicks on "sip:foo.example.com;transport=3Dws" or receives tha= t in a contact in a 302 or in a Refer-To: header field? Taken to an extreme= , what's a proxy that understands sip over websockets supposed to do if it = gets a message containing Route header fields (think preloaded routes) wher= e the next route value is for a transport=3Dws hop that a connection doesn'= t yet exist for? I replied to this subject in a previous mail, let me write it again (I will extend it a bit more now): Typical WebSocket capable SIP proxies/servers won't be able to establish outgoing WS connections and, ever less, typical SIP WS clients (browsers and probably mobile apps) won't be able to receive incoming WS connections. Thus a SIP proxy receiving a request with a ;ws preloaded Route would fail due to "unsupported transport" when performing RFC 3263 rules, and the same for a UA that receives a 302 or a Refer-To pointing to a SIP URI with ;transport=3Dws. Which is the best SIP response code for that kind of "error"? Well, IMHO it does not exist so some existing proxies reply a custom 478 "Unsupported Transport" error when the request requires being routed via an unsupported transport. However I expect that SIP WebSocket clients should/will implement Outbound and GRUU and will work in enviroments in which proxies and registrars also implement Outbound and GRUU. Therefore the problem you mention would not occur since both Outbound and GRUU avoid it. The SIP WebSocket UA would provide a GRUU based Contact when establishing dialogs and thus the remote peer would send a GRUU URI in the Refer-To header. If this is ok I have the revision 08 ready to be submitted (which includes the new "SIP Transport Registry" as requested by the WG). Thanks a lot. --=20 I=C3=B1aki Baz Castillo From rjsparks@nostrum.com Mon Mar 4 14:32:47 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E49B11E80A2 for ; Mon, 4 Mar 2013 14:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IzCu3RWdOUu for ; Mon, 4 Mar 2013 14:32:47 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C219C21F868E for ; Mon, 4 Mar 2013 14:32:46 -0800 (PST) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r24MWfQm098243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 16:32:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <51352109.9020803@nostrum.com> Date: Mon, 04 Mar 2013 16:32:41 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <50B5404A.20807@nostrum.com> <512BDEED.9030706@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000507090503060809090000" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , draft-ietf-sipcore-sip-websocket@tools.ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:32:47 -0000 This is a multi-part message in MIME format. --------------000507090503060809090000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/4/13 4:21 PM, Iñaki Baz Castillo wrote: > Hi Robert, please read below: > > > 2013/2/25 Robert Sparks : >> Hi Iñaki (and SIPCORE participants): >> >> One thing from my initial review that I don't think I've seen a response to >> (nor do I see how the draft revision addressed it) - >> apologies if we had discussed this and I've forgotten: >> >> >> >> On 11/27/12 4:35 PM, Robert Sparks wrote: >>> * Should there be some additional discussion of what an element should do if someone clicks on "sip:foo.example.com;transport=ws" or receives that in a contact in a 302 or in a Refer-To: header field? Taken to an extreme, what's a proxy that understands sip over websockets supposed to do if it gets a message containing Route header fields (think preloaded routes) where the next route value is for a transport=ws hop that a connection doesn't yet exist for? > I replied to this subject in a previous mail, let me write it again (I > will extend it a bit more now): Thanks, and sorry I couldn't find your earlier response. > > Typical WebSocket capable SIP proxies/servers won't be able to > establish outgoing WS connections and, ever less, typical SIP WS > clients (browsers and probably mobile apps) won't be able to receive > incoming WS connections. Thus a SIP proxy receiving a request with a > ;ws preloaded Route would fail due to "unsupported transport" when > performing RFC 3263 rules, and the same for a UA that receives a 302 > or a Refer-To pointing to a SIP URI with ;transport=ws. > > Which is the best SIP response code for that kind of "error"? Well, > IMHO it does not exist so some existing proxies reply a custom 478 > "Unsupported Transport" error when the request requires being routed > via an unsupported transport. > > However I expect that SIP WebSocket clients should/will implement > Outbound and GRUU and will work in enviroments in which proxies and > registrars also implement Outbound and GRUU. Therefore the problem you > mention would not occur since both Outbound and GRUU avoid it. The SIP > WebSocket UA would provide a GRUU based Contact when establishing > dialogs and thus the remote peer would send a GRUU URI in the Refer-To > header. > > > > > If this is ok I have the revision 08 ready to be submitted (which > includes the new "SIP Transport Registry" as requested by the WG). Well, we've had some discussion here, but if I read what you're saying correctly, you're not adding any discussion to the draft. I think there's value in doing so, but we can keep talking about it during IETF LC. Please submit the revision you have when submissions open Monday. Please be sure to address Keith's concern: "The IANA considerations for the new registry needs to indicate it is grouped with the other SIP registries." if you haven't already. What he's asking for is that we make an adjustment like this one: OLD: This document adds a new registry, "SIP Transport". NEW: This document adds a new registry, "SIP Transport" to the "Session Initiation Protocol (SIP) Parameters" registry page. Thanks, RjS > > Thanks a lot. > > --------------000507090503060809090000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 3/4/13 4:21 PM, Iñaki Baz Castillo wrote:
Hi Robert, please read below:


2013/2/25 Robert Sparks <rjsparks@nostrum.com>:

Hi Iñaki (and SIPCORE participants):

One thing from my initial review that I don't think I've seen a response to
(nor do I see how the draft revision addressed it) -
apologies if we had discussed this and I've forgotten:



On 11/27/12 4:35 PM, Robert Sparks wrote:

* Should there be some additional discussion of what an element should do if someone clicks on "sip:foo.example.com;transport=ws" or receives that in a contact in a 302 or in a Refer-To: header field? Taken to an extreme, what's a proxy that understands sip over websockets supposed to do if it gets a message containing Route header fields (think preloaded routes) where the next route value is for a transport=ws hop that a connection doesn't yet exist for?

I replied to this subject in a previous mail, let me write it again (I
will extend it a bit more now):
Thanks, and sorry I couldn't find your earlier response.

Typical WebSocket capable SIP proxies/servers won't be able to
establish outgoing WS connections and, ever less, typical SIP WS
clients (browsers and probably mobile apps) won't be able to receive
incoming WS connections. Thus a SIP proxy receiving a request with a
;ws preloaded Route would fail due to "unsupported transport" when
performing RFC 3263 rules, and the same for a UA that receives a 302
or a Refer-To pointing to a SIP URI with ;transport=ws.

Which is the best SIP response code for that kind of "error"? Well,
IMHO it does not exist so some existing proxies reply a custom 478
"Unsupported Transport" error when the request requires being routed
via an unsupported transport.

However I expect that SIP WebSocket clients should/will implement
Outbound and GRUU and will work in enviroments in which proxies and
registrars also implement Outbound and GRUU. Therefore the problem you
mention would not occur since both Outbound and GRUU avoid it. The SIP
WebSocket UA would provide a GRUU based Contact when establishing
dialogs and thus the remote peer would send a GRUU URI in the Refer-To
header.




If this is ok I have the revision 08 ready to be submitted (which
includes the new "SIP Transport Registry" as requested by the WG).
Well, we've had some discussion here, but if I read what you're saying correctly,
you're not adding any discussion to the draft. I think there's value in doing so,
but we can keep talking about it during IETF LC.

Please submit the revision you have when submissions open Monday. Please be sure to address Keith's
concern: "The IANA considerations for the new registry needs to indicate it is grouped with the other SIP registries."
if you haven't already. What he's asking for is that we make an adjustment like this one:
OLD:
This document adds a new registry, "SIP Transport".
NEW:
This document adds a new registry, "SIP Transport" to the "Session Initiation Protocol (SIP) Parameters" registry page.

Thanks,

RjS

Thanks a lot.

--------------000507090503060809090000-- From ibc@aliax.net Mon Mar 4 15:08:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7141D11E80A4 for ; Mon, 4 Mar 2013 15:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+VA8wC69bK1 for ; Mon, 4 Mar 2013 15:08:26 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id D36B121F8915 for ; Mon, 4 Mar 2013 15:08:25 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dx4so1542170qab.2 for ; Mon, 04 Mar 2013 15:08:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ZPAGOqP3uU/MwdT7Kh2gaRfwC/TkR7dM5Fl5XfEv/PM=; b=MtPcmdxoy1JR9wSD79cCifo0LKBnATDs7v10lmTj5mTYAtl8rjeEfsjScHFEzlvZoz JawcpKhYDfxs8jHutZsRVb/PzXP15SQyUsYEuvF+1+nUVla/7LAMXvSvICxq8xvK+SS7 MEZ+oKEP1/T6RS/vMCkn2+IAE+c+RwQJeaLUFaxciuuCqtC2jGRRQgYrsJe8PfMd7P0X nAvqv03hphznWeAZTzaMRf6xpjOfqQ+af19n/yX9FpxEhmohArbTr2ZDNXjWhhSl/KIv 6qfsWfOb8IGYG177AE3zGj4tdnDeawSNw26V25qAyCq7wnb8J2VSjlwgoJAAFsLDwWDp cYsQ== X-Received: by 10.224.180.212 with SMTP id bv20mr36165472qab.6.1362438505348; Mon, 04 Mar 2013 15:08:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Mon, 4 Mar 2013 15:08:04 -0800 (PST) In-Reply-To: <51352109.9020803@nostrum.com> References: <50B5404A.20807@nostrum.com> <512BDEED.9030706@nostrum.com> <51352109.9020803@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Mar 2013 00:08:04 +0100 Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkpFV6wEkkT7VqoIJwXXgeQ7ai7YQNFUwwzfNCE0xCG7PasEc/5jfmmYQHZsh2Y46fNAQUf Cc: "sipcore@ietf.org" , draft-ietf-sipcore-sip-websocket@tools.ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 23:08:26 -0000 2013/3/4 Robert Sparks : > Well, we've had some discussion here, but if I read what you're saying > correctly, > you're not adding any discussion to the draft. I think there's value in > doing so, > but we can keep talking about it during IETF LC. I think that the same issue would occur in other cases as when a UA establishes a dialog using SCTP as Contact URI transport. The remote could use such a Contact into a Refer-To or 302 and same problem would occur if the destination does not support SCTP transport. Using an Outbound proxy (so hopefully RFC 5626) and GRUU mitigates this problem. Even more, IMHO both Outbound and GRUU are the required and standarized solution for all those scenarios which cover more than just the new WS transport defined in the draft. > Please submit the revision you have when submissions open Monday. Please = be > sure to address Keith's > concern: "The IANA considerations for the new registry needs to indicate = it > is grouped with the other SIP registries." > if you haven't already. What he's asking for is that we make an adjustmen= t > like this one: > OLD: > > This document adds a new registry, "SIP Transport". > NEW: > This document adds a new registry, "SIP Transport" to the "Session > Initiation Protocol (SIP) Parameters" registry page. Thanks for pointing it. So I will submit the new revision 08 on Monday. Thanks a lot. Best regards. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Tue Mar 5 12:43:05 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAF21F8937 for ; Tue, 5 Mar 2013 12:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WLeDoVLWmPA for ; Tue, 5 Mar 2013 12:43:05 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B8D4021F89DC for ; Tue, 5 Mar 2013 12:43:04 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r25KgiCC032739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 5 Mar 2013 21:43:00 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 5 Mar 2013 21:42:57 +0100 From: "DRAGE, Keith (Keith)" To: SIPCORE Date: Tue, 5 Mar 2013 21:42:56 +0100 Thread-Topic: IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 4028 Thread-Index: Ac4Zab2wL6clu1mdQSeV4wK+cFYUjQAU7ivA 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [sipcore] FW: IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 4028 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:43:05 -0000 Forwarding to the SIPCORE list, rather than condemning it to the old SIP li= st. Regards Keith -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 Sent: 05 March 2013 06:22 To: jdrosen@dynamicsoft.com; sdonovan@dynamicsoft.com Cc: gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; DRAGE, Keith (Kei= th); dean.willis@softarmor.com; sip@ietf.org; ipr-announce@ietf.org Subject: IPR Disclosure: SSH Communications Security Corporation's Statemen= t about IPR related to RFC 4028 Dear Jonathan Rosenberg, Steven Donovan: An IPR disclosure that pertains to your RFC entitled "Session Timers in th= e Session Initiation Protocol (SIP)" (RFC4028) was submitted to the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1979/). The = title of the IPR disclosure is "SSH Communications Security Corporation's Stateme= nt about IPR related to RFC 4028.""); The IETF Secretariat From keith.drage@alcatel-lucent.com Tue Mar 5 12:43:18 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8289F21F8A05 for ; Tue, 5 Mar 2013 12:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPAxO933Bf3d for ; Tue, 5 Mar 2013 12:43:18 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id AC87821F8A00 for ; Tue, 5 Mar 2013 12:43:17 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r25KgfEH032724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 5 Mar 2013 21:43:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 5 Mar 2013 21:42:57 +0100 From: "DRAGE, Keith (Keith)" To: SIPCORE Date: Tue, 5 Mar 2013 21:42:56 +0100 Thread-Topic: IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 5626 Thread-Index: Ac4ZajSiev+9Ke4ITc2C48U/2mezbwAUyqYA 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [sipcore] FW: IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 5626 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:43:18 -0000 Forwarding to the SIPCORE list, rather than condemning it to the old SIP li= st. Regards Keith -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 Sent: 05 March 2013 06:25 To: fluffy@cisco.com Cc: gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; DRAGE, Keith (Kei= th); dean.willis@softarmor.com; sip@ietf.org; ipr-announce@ietf.org Subject: IPR Disclosure: SSH Communications Security Corporation's Statemen= t about IPR related to RFC 5626 Dear Cullen Jennings: An IPR disclosure that pertains to your RFC entitled "Managing Client-Init= iated Connections in the Session Initiation Protocol (SIP)" (RFC5626) was submitt= ed to the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1992/). The title of the IPR disclosure i= s "SSH Communications Security Corporation's Statement about IPR related to R= FC 5626.""); The IETF Secretariat From oferg@avaya.com Thu Mar 7 01:22:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1421F8AA6 for ; Thu, 7 Mar 2013 01:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ax-wxRoCEAC for ; Thu, 7 Mar 2013 01:22:25 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1C21F8A51 for ; Thu, 7 Mar 2013 01:22:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHpXMFGHCzI1/2dsb2JhbABEgkO/cX8Wc4IhAQEDEhteAQwJFVYmAQQbGodxoDiEKpxDjmODF2EDnFqKUYMIgic X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208,217";a="911675" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Mar 2013 04:21:09 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Mar 2013 04:19:41 -0500 Received: from RVIL-MAIL2010.RADVISION.com ([172.20.2.20]) by rvil-mail2010 ([172.20.2.20]) with mapi id 14.01.0421.002; Thu, 7 Mar 2013 11:20:07 +0200 From: Ofer Goren To: "sipcore@ietf.org" Thread-Topic: Question on RFC 5407 (crossover of BYE and UPDATE) Thread-Index: Ac4bFCZJoEunDd07Rd+FdHFYonFvOQ== Date: Thu, 7 Mar 2013 09:20:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.70.131] Content-Type: multipart/alternative; boundary="_000_D9AD3D1627F52341B829F32E6DDE089149E25848rvilmail2010_" MIME-Version: 1.0 Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:22:26 -0000 --_000_D9AD3D1627F52341B829F32E6DDE089149E25848rvilmail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I checked RFC 5407 for race condition in various scenarios but I failed to = find any indication of crossover between BYE and UPDATE. So I have a connected callLeg, and I send an UPDATE transaction from A to B= . At the same time, I send BYE from B to A. Should A re-transmit the UPDATE in case B did not answer even after A repli= ed with 200OK for the BYE? What about other general transactions (such as OPTION)? Is UPDATE special i= n this case and should be treated differently than other general transactio= ns on that call? Thanks, Ofer --_000_D9AD3D1627F52341B829F32E6DDE089149E25848rvilmail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I checked RFC 5407 for race condition in various sce= narios but I failed to find any indication of crossover between BYE and UPD= ATE.

So I have a connected callLeg, and I send an UPDATE = transaction from A to B. At the same time, I send BYE from B to A.

Should A re-transmit the UPDATE in case B did not an= swer even after A replied with 200OK for the BYE?

What about other general transactions (such as OPTIO= N)? Is UPDATE special in this case and should be treated differently than o= ther general transactions on that call?

 

Thanks,

Ofer

 

--_000_D9AD3D1627F52341B829F32E6DDE089149E25848rvilmail2010_-- From shinji.okumura@softfront.jp Thu Mar 7 03:11:59 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7970921F8D30 for ; Thu, 7 Mar 2013 03:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.454 X-Spam-Level: X-Spam-Status: No, score=-95.454 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-HHkVg8Ce9d for ; Thu, 7 Mar 2013 03:11:59 -0800 (PST) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 3267D21F8D2F for ; Thu, 7 Mar 2013 03:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from softfront.jp (sf-pc-111.softfront.local [172.16.25.90]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 5896F428014 for ; Thu, 7 Mar 2013 20:11:54 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 07 Mar 2013 20:11:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> Message-Id: <29CE1B24928B3Ashinji.okumura@softfront.jp> Subject: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 11:11:59 -0000 one point. worley@ariadne.com (Dale R. Worley) Fri, 1 Mar 2013 16:19:00 -0500 (EST) >3.7. Consumer Voicemail Example > History-Info: ;\ >- index=1.3.1;rc=1.3 >+ index=1.2.2.1;rc=1.2.1 ^^^^^ 1.2.2 Shinji. From christer.holmberg@ericsson.com Thu Mar 7 03:26:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3270D21F8CAF for ; Thu, 7 Mar 2013 03:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk6zC4Z2xrXZ for ; Thu, 7 Mar 2013 03:26:42 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AA7C021F8CAE for ; Thu, 7 Mar 2013 03:26:39 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-37-5138796ea46d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B8.C6.32353.E6978315; Thu, 7 Mar 2013 12:26:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 12:26:38 +0100 From: Christer Holmberg To: Ofer Goren , "sipcore@ietf.org" Thread-Topic: Question on RFC 5407 (crossover of BYE and UPDATE) Thread-Index: Ac4bFCZJoEunDd07Rd+FdHFYonFvOQAEjI9Q Date: Thu, 7 Mar 2013 11:26:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B11496BESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW5epUWgwcz1hhYztnSzW3z9sYnN gcnj4Mo57B5LlvxkCmCK4rJJSc3JLEst0rdL4Mro38Ne8E+v4uuNxYwNjO2aXYycHBICJhJX rrYyQthiEhfurWfrYuTiEBI4xCixeOpLJghnEaPEtG1tQBkODjYBC4nuf9ogDSIC7hJbbqxl AgkLC9hLnD6QARF2kLj/8jsrhG0k8XLbQTYQm0VAReLI4uUsIDavgLdE0+qHYHEhAReJtR13 2UFsTgFXiWWPm8BsRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwFSWuTl8O VZ8vcWnnAkaIXYISJ2c+YZnAKDILyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTx BYzsqxjZcxMzc9LLzTcxAuPm4JbfBjsYN90XO8QozcGiJM4b7nohQEggPbEkNTs1tSC1KL6o NCe1+BAjEwenVANjWYiEzpyKnnq3Zqtk3bXJyxdJ6QRGis3+KcWz1Km9ZPLmL9z1HRaL/xw4 bxhVxd7vODWG2y3/FsfBE5KCf3SX6RtfliqwWtm671FtwIMTH27ue77zpnv7V3WlyAxd6wj+ f7k/zqV8nCAbc7D6kP5qGek329aGq+4PPL57vfGU/VIZ4mb+0Q5KLMUZiYZazEXFiQAAju9X aQIAAA== Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 11:26:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B11496BESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As the BYE terminates the dialog, I see no reason why you should re-transit= the UPDATE, or any other mid-dialog requests associated with that dialog, = as the dialog doesn't exist anymore. Regards, Christer From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ofer Goren Sent: 7. maaliskuuta 2013 11:20 To: sipcore@ietf.org Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) Hi I checked RFC 5407 for race condition in various scenarios but I failed to = find any indication of crossover between BYE and UPDATE. So I have a connected callLeg, and I send an UPDATE transaction from A to B= . At the same time, I send BYE from B to A. Should A re-transmit the UPDATE in case B did not answer even after A repli= ed with 200OK for the BYE? What about other general transactions (such as OPTION)? Is UPDATE special i= n this case and should be treated differently than other general transactio= ns on that call? Thanks, Ofer --_000_7594FB04B1934943A5C02806D1A2204B11496BESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

As the BYE terminates = the dialog, I see no reason why you should re-transit the UPDATE, or any ot= her mid-dialog requests associated with that dialog, as the dialog doesn= 217;t exist anymore.

 

Regards,

 

Christer

 

From: sipcore-= bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: sipcore@ietf.org
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE= )

 

Hi

 

I checked RFC 5407 for race condition in various sce= narios but I failed to find any indication of crossover between BYE and UPD= ATE.

So I have a connected callLeg, and I send an UPDATE = transaction from A to B. At the same time, I send BYE from B to A.

Should A re-transmit the UPDATE in case B did not an= swer even after A replied with 200OK for the BYE?

What about other general transactions (such as OPTIO= N)? Is UPDATE special in this case and should be treated differently than o= ther general transactions on that call?

 

Thanks,

Ofer

 

--_000_7594FB04B1934943A5C02806D1A2204B11496BESESSMB209ericsso_-- From rjsparks@nostrum.com Thu Mar 7 06:42:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7590821F8D71 for ; Thu, 7 Mar 2013 06:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMenMteK7y+R for ; Thu, 7 Mar 2013 06:42:21 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D505C21F8D6E for ; Thu, 7 Mar 2013 06:42:20 -0800 (PST) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r27EgGP2041326 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Mar 2013 08:42:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <5138A749.80202@nostrum.com> Date: Thu, 07 Mar 2013 08:42:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------000507070706070502070100" Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , Ofer Goren Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:42:22 -0000 This is a multi-part message in MIME format. --------------000507070706070502070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/7/13 5:26 AM, Christer Holmberg wrote: > > Hi, > > As the BYE terminates the dialog, I see no reason why you should > re-transit the UPDATE, or any other mid-dialog requests associated > with that dialog, as the dialog doesn't exist anymore. > Transactions complete independently. If you were to follow the specifications, you will retransmit the UPDATE until it gets a final response or the appropriate timer fires ending the transaction. The real problem is that the request may actually have gotten to the UAS before the BYE was processed, but the response to it is what got lost. Your retransmission will stimulate retransmission of that response, and you need to receive that response in order to have a consistent view of state at both endpoints. Christer - it's not hard to imagine an applicaitons use of an INFO package that you would break with the optimization you propose. RjS > > Regards, > > Christer > > *From:*sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Ofer Goren > *Sent:* 7. maaliskuuta 2013 11:20 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) > > Hi > > I checked RFC 5407 for race condition in various scenarios but I > failed to find any indication of crossover between BYE and UPDATE. > > So I have a connected callLeg, and I send an UPDATE transaction from A > to B. At the same time, I send BYE from B to A. > > Should A re-transmit the UPDATE in case B did not answer even after A > replied with 200OK for the BYE? > > What about other general transactions (such as OPTION)? Is UPDATE > special in this case and should be treated differently than other > general transactions on that call? > > Thanks, > > Ofer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------000507070706070502070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/7/13 5:26 AM, Christer Holmberg wrote:

Hi,

 

As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests associated with that dialog, as the dialog doesn’t exist anymore.

Transactions complete independently. If you were to follow the specifications, you will retransmit the UPDATE until it gets a final response or the appropriate timer fires ending the transaction.

The real problem is that the request may actually have gotten to the UAS before the BYE was processed, but the response to it is what got lost. Your retransmission will stimulate retransmission of that response, and you need to receive that response in order to have a consistent view of state at both endpoints.

Christer - it's not hard to imagine an applicaitons use of an INFO package that you would break with the optimization you propose.

RjS

 

Regards,

 

Christer

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: sipcore@ietf.org
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

 

Hi

 

I checked RFC 5407 for race condition in various scenarios but I failed to find any indication of crossover between BYE and UPDATE.

So I have a connected callLeg, and I send an UPDATE transaction from A to B. At the same time, I send BYE from B to A.

Should A re-transmit the UPDATE in case B did not answer even after A replied with 200OK for the BYE?

What about other general transactions (such as OPTION)? Is UPDATE special in this case and should be treated differently than other general transactions on that call?

 

Thanks,

Ofer

 



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

--------------000507070706070502070100-- From christer.holmberg@ericsson.com Thu Mar 7 06:52:42 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C809E21F8CCB for ; Thu, 7 Mar 2013 06:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jslY7UC1BmxN for ; Thu, 7 Mar 2013 06:52:41 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E7A0221F8934 for ; Thu, 7 Mar 2013 06:52:38 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-57-5138a9b50c62 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 32.0D.19728.5B9A8315; Thu, 7 Mar 2013 15:52:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 15:52:37 +0100 From: Christer Holmberg To: Robert Sparks Thread-Topic: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) Thread-Index: Ac4bFCZJoEunDd07Rd+FdHFYonFvOQAEjI9QAATPKYAAAlzVYA== Date: Thu, 7 Mar 2013 14:52:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B114D5F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> <5138A749.80202@nostrum.com> In-Reply-To: <5138A749.80202@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B114D5FESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7WlRaBBhte6FrM2NLNbnFtTiOb xdcfm9gcmD0OrpzD7rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZbw9N5u5oCWm4kaXdgPj moAuRk4OCQETibl/W9khbDGJC/fWs3UxcnEICRxilPh8eiEThLOIUaLjSC9LFyMHB5uAhUT3 P22QBhEBDYlrS5aANTMLuEtcfn2fEaREWMBT4uaCLBBTRMBLYsWCeIhqJ4kTR1eADWERUJH4 tjQHJMwr4C2xsnkbI8SipYwSC7dvYAKp4RTQlJi0QhqkhhHosu+n1jBBLBKXuPVkPhPExQIS S/acZ4awRSVePv7HCmErSlydvhyqPl9i67ot7BC7BCVOznzCMoFRdBaSUbOQlM1CUgYR15FY sPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMbLnJmbmpJcbbWIExtfBLb9VdzDeOSdyiFGag0VJ nDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbZKllKbZzTmcIC59asu1G4zDXhzZHv +5+KptyMufL3ZfF5c6UjT46FHtZ5vZtRZ1L11AQVf6dbqw7H3Z2irzpPi/mb8vPnDwqKb7ov yeWeMcP786RqR592zZWtn6t7bdQlu4RXXr7VsX6eQ5BgvO/dr5qsZzTzy1++6a3Z1LX5h4vX Z9sdaguUWIozEg21mIuKEwHvK7z4fQIAAA== Cc: "sipcore@ietf.org" , Ofer Goren Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:52:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B114D5FESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My point was more that any state synchronization etc shouldn't matter, as t= he dialog is anyway terminated. But, Robert is correct, if you follow the specification (lots of implementa= tions don't :), and re-transmitting until you get a response will make sure= you're on the "safe side". Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 7. maaliskuuta 2013 16:42 To: Christer Holmberg Cc: Ofer Goren; sipcore@ietf.org Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) On 3/7/13 5:26 AM, Christer Holmberg wrote: Hi, As the BYE terminates the dialog, I see no reason why you should re-transit= the UPDATE, or any other mid-dialog requests associated with that dialog, = as the dialog doesn't exist anymore. Transactions complete independently. If you were to follow the specificatio= ns, you will retransmit the UPDATE until it gets a final response or the ap= propriate timer fires ending the transaction. The real problem is that the request may actually have gotten to the UAS be= fore the BYE was processed, but the response to it is what got lost. Your r= etransmission will stimulate retransmission of that response, and you need = to receive that response in order to have a consistent view of state at bot= h endpoints. Christer - it's not hard to imagine an applicaitons use of an INFO package = that you would break with the optimization you propose. RjS Regards, Christer From: sipcore-bounces@ietf.org [mailto:sip= core-bounces@ietf.org] On Behalf Of Ofer Goren Sent: 7. maaliskuuta 2013 11:20 To: sipcore@ietf.org Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) Hi I checked RFC 5407 for race condition in various scenarios but I failed to = find any indication of crossover between BYE and UPDATE. So I have a connected callLeg, and I send an UPDATE transaction from A to B= . At the same time, I send BYE from B to A. Should A re-transmit the UPDATE in case B did not answer even after A repli= ed with 200OK for the BYE? What about other general transactions (such as OPTION)? Is UPDATE special i= n this case and should be treated differently than other general transactio= ns on that call? Thanks, Ofer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B114D5FESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

My point was more that= any state synchronization etc shouldn’t matter, as the dialog is any= way terminated.

 

But, Robert is correct= , if you follow the specification (lots of implementations don’t :), = and re-transmitting until you get a response will make sure you’re on= the “safe side”.

 

Regards,

 

Christer

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 7. maaliskuuta 2013 16:42
To: Christer Holmberg
Cc: Ofer Goren; sipcore@ietf.org
Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UP= DATE)

 

On 3/7/13 5:26 AM, Christer Holmberg wrote:

Hi,<= /p>

 

As the BYE terminates = the dialog, I see no reason why you should re-transit the UPDATE, or any ot= her mid-dialog requests associated with that dialog, as the dialog doesn= 217;t exist anymore.

Transactions complete independently.= If you were to follow the specifications, you will retransmit the UPDATE u= ntil it gets a final response or the appropriate timer fires ending the transaction.

The real problem is that the request may actually have gotten to the UAS be= fore the BYE was processed, but the response to it is what got lost. Your r= etransmission will stimulate retransmission of that response, and you need = to receive that response in order to have a consistent view of state at both endpoints.

Christer - it's not hard to imagine an applicaitons use of an INFO package = that you would break with the optimization you propose.

RjS

 

Regards,

 

Christer

 

From: sipcore-bounces@ietf.org [<= a href=3D"mailto:sipcore-bounces@ietf.org">mailto:sipcore-bounces@ietf.org<= /a>] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: sipcore@ietf.org
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE= )

 

Hi

 

I checked RFC 5407 for race condition in various sce= narios but I failed to find any indication of crossover between BYE and UPD= ATE.

So I have a connected callLeg, and I send an UPDATE = transaction from A to B. At the same time, I send BYE from B to A.

Should A re-transmit the UPDATE in case B did not an= swer even after A replied with 200OK for the BYE?

What about other general transactions (such as OPTIO= N)? Is UPDATE special in this case and should be treated differently than o= ther general transactions on that call?

 

Thanks,

Ofer

 




_______________________________________________
sipcore mailing list
sipcore@ietf.org

https://www.=
ietf.org/mailman/listinfo/sipcore


 
--_000_7594FB04B1934943A5C02806D1A2204B114D5FESESSMB209ericsso_-- From rjsparks@nostrum.com Thu Mar 7 08:03:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC21F21F8BEF for ; Thu, 7 Mar 2013 08:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkEKwPTqTW4b for ; Thu, 7 Mar 2013 08:03:03 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3C21F8BF8 for ; Thu, 7 Mar 2013 08:03:02 -0800 (PST) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r27G2uss050477 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Mar 2013 10:02:57 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <5138BA30.2060008@nostrum.com> Date: Thu, 07 Mar 2013 10:02:56 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> <5138A749.80202@nostrum.com> <7594FB04B1934943A5C02806D1A2204B114D5F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B114D5F@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------000608080604020105010402" Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , Ofer Goren Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:03:05 -0000 This is a multi-part message in MIME format. --------------000608080604020105010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/7/13 8:52 AM, Christer Holmberg wrote: > > Hi, > > My point was more that any state synchronization etc shouldn't matter, > as the dialog is anyway terminated. > I think you are assuming that the state you are synchronizing is limited to dialog state. There are application side-effects of processing many of these messages that you can't predict, and the applications really do care about the result of that transaction at the other end. > > But, Robert is correct, if you follow the specification (lots of > implementations don't :), > And risk causing grief for doing so. > > and re-transmitting until you get a response will make sure you're on > the "safe side". > > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 7. maaliskuuta 2013 16:42 > *To:* Christer Holmberg > *Cc:* Ofer Goren; sipcore@ietf.org > *Subject:* Re: [sipcore] Question on RFC 5407 (crossover of BYE and > UPDATE) > > On 3/7/13 5:26 AM, Christer Holmberg wrote: > > Hi, > > As the BYE terminates the dialog, I see no reason why you should > re-transit the UPDATE, or any other mid-dialog requests associated > with that dialog, as the dialog doesn't exist anymore. > > Transactions complete independently. If you were to follow the > specifications, you will retransmit the UPDATE until it gets a final > response or the appropriate timer fires ending the transaction. > > The real problem is that the request may actually have gotten to the > UAS before the BYE was processed, but the response to it is what got > lost. Your retransmission will stimulate retransmission of that > response, and you need to receive that response in order to have a > consistent view of state at both endpoints. > > Christer - it's not hard to imagine an applicaitons use of an INFO > package that you would break with the optimization you propose. > > RjS > > Regards, > > Christer > > *From:*sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Ofer Goren > *Sent:* 7. maaliskuuta 2013 11:20 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) > > Hi > > I checked RFC 5407 for race condition in various scenarios but I > failed to find any indication of crossover between BYE and UPDATE. > > So I have a connected callLeg, and I send an UPDATE transaction from A > to B. At the same time, I send BYE from B to A. > > Should A re-transmit the UPDATE in case B did not answer even after A > replied with 200OK for the BYE? > > What about other general transactions (such as OPTION)? Is UPDATE > special in this case and should be treated differently than other > general transactions on that call? > > Thanks, > > Ofer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------000608080604020105010402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/7/13 8:52 AM, Christer Holmberg wrote:

Hi,

 

My point was more that any state synchronization etc shouldn’t matter, as the dialog is anyway terminated.

I think you are assuming that the state you are synchronizing is limited to dialog state.
There are application side-effects of processing many of these messages that you can't predict,
and the applications really do care about the result of that transaction at the other end.

 

But, Robert is correct, if you follow the specification (lots of implementations don’t :),

And risk causing grief for doing so.

and re-transmitting until you get a response will make sure you’re on the “safe side”.

 

Regards,

 

Christer

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 7. maaliskuuta 2013 16:42
To: Christer Holmberg
Cc: Ofer Goren; sipcore@ietf.org
Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

 

On 3/7/13 5:26 AM, Christer Holmberg wrote:

Hi,

 

As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests associated with that dialog, as the dialog doesn’t exist anymore.

Transactions complete independently. If you were to follow the specifications, you will retransmit the UPDATE until it gets a final response or the appropriate timer fires ending the transaction.

The real problem is that the request may actually have gotten to the UAS before the BYE was processed, but the response to it is what got lost. Your retransmission will stimulate retransmission of that response, and you need to receive that response in order to have a consistent view of state at both endpoints.

Christer - it's not hard to imagine an applicaitons use of an INFO package that you would break with the optimization you propose.

RjS

 

Regards,

 

Christer

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: sipcore@ietf.org
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

 

Hi

 

I checked RFC 5407 for race condition in various scenarios but I failed to find any indication of crossover between BYE and UPDATE.

So I have a connected callLeg, and I send an UPDATE transaction from A to B. At the same time, I send BYE from B to A.

Should A re-transmit the UPDATE in case B did not answer even after A replied with 200OK for the BYE?

What about other general transactions (such as OPTION)? Is UPDATE special in this case and should be treated differently than other general transactions on that call?

 

Thanks,

Ofer

 




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

 


--------------000608080604020105010402-- From shida@ntt-at.com Thu Mar 7 17:02:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62821F8727 for ; Thu, 7 Mar 2013 17:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h0R6oO1zpFc for ; Thu, 7 Mar 2013 17:02:40 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 448F021F8717 for ; Thu, 7 Mar 2013 17:02:40 -0800 (PST) Received: from [76.14.57.116] (port=58909 helo=[192.168.1.118]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UDlhn-0006Sb-C0; Thu, 07 Mar 2013 19:02:39 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> Date: Thu, 7 Mar 2013 17:02:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: yes X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.118]) [76.14.57.116]:58909 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 01:02:41 -0000 Thanks Dale and Shinji; I will reflect these in the upcoming update.=20 Thanks Shida On Mar 1, 2013, at 1:19 PM, Dale R. Worley wrote: > I've gone through draft-ietf-sipcore-rfc4244bis-callflows-02. I > haven't examine everything in the SIP messages. Instead, I've > concentrated on the History-Info headers in the "final" messages of > the sequences. In each example, there is a final message that > contains all of the information in all of the History-Info headers. I > believe that the following amendments should be made in examles 3.1, > 3.6, and 3.7. >=20 > These amendments include a number of things that have been discussed > on the Sipcore mailing list. >=20 > 3.1. Sequentially Forking (History-Info in Response) >=20 > Alice example.com Bob Office Home > | | | | | > | INVITE F1 | | | | > |----------->| INVITE F2 | | | > | |----------------->| | | > | 100 Trying F3 | | | > |<-----------| 302 Move Temporarily F4 | | > | |<-----------------| | | > | | ACK F5 | | | > | |----------------->| | | > | | INVITE F6 | | > | |-------------------------->| | > | | 180 Ringing F7 | | > | |<--------------------------| | > | 180 Ringing F8 | | > |<-----------| retransmit INVITE | | > | |-------------------------->| | > | | ( timeout ) | | > | | INVITE F9 | > | |----------------------------------->| > | | 100 Trying F10 | > | |<-----------------------------------| > | | 486 Busy Here F11 | > | |<-----------------------------------| > | 486 Busy Here F12 | > |<-----------| ACK F13 | > | |----------------------------------->| > | ACK F14 | | > |----------->| | >=20 > In these examples, I have added Reason values to hi-entries that have > effectively received failure responses due to the failure of their > internally redirected targets. Doing so is optional per draft-4244bis > but it seems to me to be the best practice. >=20 > That is, I believe that the results of internal retargeting should be > the same as if the second retargeting was done in a different proxy. >=20 > F12 486 Busy Here example.com -> alice >=20 > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > - History-Info: ;index=3D1.2;mp=3D1 > + History-Info: ;\ > + index=3D1.2;mp=3D1 > History-Info: ;\ > - index=3D1.2.1;index=3D1.2.1;rc=3D1.2 > + index=3D1.2.1;rc=3D1.2 > History-Info: ;index=3D1.3;mp=3D1 > History-Info: ;index=3D1.3.1;rc=3D1.3 >=20 > 3.6. PBX Voicemail Example >=20 > Alice example.com Bob Carol VM >=20 > | INVITE F1 | | | | > |------------->| | | | > | | INVITE F2 | | | > | |------------->| | | > | | | | | > | 100 Trying | | | | > |<-------------| 302 Moved Temporarily F3 | | > | |<-------------| | | > | | | | | > | ACK | | | > |---------------------------->| | | > | | | | | > | | INVITE F4 | | | > | |--------------------------->| | > | | | | | > | | 180 Ringing F5 | | > | |<---------------------------| | > | | | | | > | 180 Ringing | | | | > |<-------------| | | | > | | | | | > | | (timeout) | | > | | | | | > | | INVITE F6 | | | > | |-------------------------------------->| > | | | | | > | | 200 OK F7 | > | |<--------------------------------------| > | 200 OK | | | | > |<-------------| | | | > | | | | | > | ACK | > |----------------------------------------------------->| >=20 > Here, I assume we are using the "cause" URI parameter to indicate > redirection reasons per RFC 4458. The redirection from Bob to Carol > is "Deflection immediate response", which is translated into the SIP > cause 480. The redirection from Carol to VM is "No reply", which is > translated into SIP cause 408. We assume the "cause" parameter is > preserved when AORs are mapped to their contacts. >=20 > Here, we choose the "cause" that is sent to VM to be 408, because the > immediately preceeding INVITE failed due to 408. But the VM box is > Bob's, and the call to Bob failed due to cause=3D480. The choice > probably depends on the application logic rather than standards. > (History-Info, however, captures the entire history of the call.) >=20 > The Reason value for index 1.2.1 has been corrected to 408. >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > - History-Info: ;index=3D1.2;mp=3D1 > - History-Info: ;\ > - index=3D1.2.1;rc=3D1.2 > - History-Info: - target=3Dsip:bob%40example.com>;\ > - index=3D1.3;mp=3D1 > - History-Info: - target=3Dsip:bob%40example.com>;\ > - index=3D1.3.1;rc=3D1.3 > + History-Info: = ;\ > + index=3D1.2;mp=3D1 > + History-Info: = ;\ > + index=3D1.2.1;rc=3D1.2 > + History-Info: + target=3Dsip:bob%40example.com;cause=3D408>;\ > + index=3D1.3;mp=3D1 > + History-Info: + target=3Dsip:bob%40example.com;cause=3D408>;\ > + index=3D1.3.1;rc=3D1.3 >=20 > 3.7. Consumer Voicemail Example >=20 > Alice example.com Bob Carol VM >=20 > | INVITE F1 | | | | > |------------->| | | | > | | INVITE F2 | | | > | |------------->| | | > | | | | | > | 100 Trying | | | | > |<-------------| 302 Moved Temporarily F3 | | > | |<-------------| | | > | | | | | > | ACK | | | > |---------------------------->| | | > | | | | | > | | INVITE F4 | | | > | |--------------------------->| | > | | | | | > | | 180 Ringing F5 | | > | |<---------------------------| | > | | | | | > | 180 Ringing | | | | > |<-------------| | | | > | | | | | > | | (timeout) | | > | | | | | > | | INVITE F6 | | | > | |-------------------------------------->| > | | | | | > | | 200 OK F7 | > | |<--------------------------------------| > | 200 OK | | | | > |<-------------| | | | > | | | | | > | ACK | > |----------------------------------------------------->| >=20 > Here, hi-entry 1.2.1 should have a Reason value, but the Reason value > on 1.2 is optional. >=20 > Since is generated from > (index 1.2), it should have index 1.2.2, not > 1.3. >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: ;index=3D1 > History-Info: - = ;text=3D"Moved Temporarily">\ > + %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 > History-Info: ;\ > index=3D1.2;mp=3D1 > - History-Info: ;index=3D1.2.1;rc=3D1.2 > + History-Info: ;\ > + index=3D1.2.1;rc=3D1.2 > History-Info: ;\ > - index=3D1.3;mp=3D1.2 > + index=3D1.2.2;mp=3D1.2 > History-Info: ;\ > - index=3D1.3.1;rc=3D1.3 > + index=3D1.2.2.1;rc=3D1.2.1 >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shinji.okumura@softfront.jp Thu Mar 7 23:16:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEC21F862A for ; Thu, 7 Mar 2013 23:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.661 X-Spam-Level: X-Spam-Status: No, score=-96.661 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiK-4WJiK3Xc for ; Thu, 7 Mar 2013 23:16:10 -0800 (PST) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id CE64121F8629 for ; Thu, 7 Mar 2013 23:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from softfront.jp (sf-pc-111.softfront.local [172.16.25.90]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 42AD94280D7; Fri, 8 Mar 2013 16:16:04 +0900 (JST) From: OKUMURA Shinji To: Christer Holmberg Date: Fri, 08 Mar 2013 16:16:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se> Message-Id: <32CE1BCCCAD4EDshinji.okumura@softfront.jp> Cc: "sipcore@ietf.org" , Ofer Goren Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 07:16:10 -0000 Hi, Additionally, if any subscription exist, the dialog does not terminate. Shinji. Christer Holmberg Thu, 7 Mar 2013 11:26:37 +0000 >Hi, > >As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests >associated with that dialog, as the dialog doesn't exist anymore. > >Regards, > >Christer > > >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren >Sent: 7. maaliskuuta 2013 11:20 >To: sipcore@ietf.org >Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) > > >Hi > >I checked RFC 5407 for race condition in various scenarios but I failed to find any indication of crossover between BYE and >UPDATE. >So I have a connected callLeg, and I send an UPDATE transaction from A to B. At the same time, I send BYE from B to A. >Should A re-transmit the UPDATE in case B did not answer even after A replied with 200OK for the BYE? >What about other general transactions (such as OPTION)? Is UPDATE special in this case and should be treated differently than >other general transactions on that call? > >Thanks, >Ofer From oferg@avaya.com Fri Mar 8 15:44:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4021F85A2 for ; Fri, 8 Mar 2013 15:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXv7rCC1DLEE for ; Fri, 8 Mar 2013 15:44:50 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C942321F858E for ; Fri, 8 Mar 2013 15:44:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFupNVHGmAcF/2dsb2JhbABEiS63VoFQgQQWc4IfAQEBAQMBAQEPXAsQAgEGAg0EBAEBDhoHJwsUCQgBAQQOBSKHcQyQcpBYnRwEjwgEB4JfYQOWSoYailSBMIFY X-IronPort-AV: E=Sophos;i="4.84,786,1355115600"; d="scan'208,217";a="622045" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Mar 2013 18:44:45 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Mar 2013 18:43:48 -0500 Received: from RVIL-MAIL2010.RADVISION.com ([172.20.2.20]) by rvil-mail2010 ([172.20.2.20]) with mapi id 14.01.0421.002; Sat, 9 Mar 2013 01:43:41 +0200 From: Ofer Goren To: OKUMURA Shinji Thread-Topic: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) Thread-Index: Ac4bFCZJoEunDd07Rd+FdHFYonFvOQAEjI9QACVrr4AAJq74/g== Date: Fri, 8 Mar 2013 23:43:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B11496B@ESESSMB209.ericsson.se>, <32CE1BCCCAD4EDshinji.okumura@softfront.jp> In-Reply-To: <32CE1BCCCAD4EDshinji.okumura@softfront.jp> Accept-Language: en-US Content-Language: he-IL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D885B128C85C4AC292F21D8A2352F2AEavayacom_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:44:54 -0000 --_000_D885B128C85C4AC292F21D8A2352F2AEavayacom_ Content-Type: text/plain; charset="iso-8859-8-i" Content-Transfer-Encoding: quoted-printable Thank you all for the clear answers. Sent from IPhone 7 =E1-8 =E1=EE=F8=F5 2013, =E1=F9=F2=E4 09:15, "OKUMURA Shinji" > =EB=FA=E1/=E4: Hi, Additionally, if any subscription exist, the dialog does not terminate. Shinji. Christer Holmberg > Thu, 7 Mar 2013 11:26:37 +0000 Hi, As the BYE terminates the dialog, I see no reason why you should re-transit= the UPDATE, or any other mid-dialog requests associated with that dialog, as the dialog doesn't exist anymore. Regards, Christer From: sipcore-bounces@ietf.org [mailto:sip= core-bounces@ietf.org] On Behalf Of Ofer Goren Sent: 7. maaliskuuta 2013 11:20 To: sipcore@ietf.org Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE) Hi I checked RFC 5407 for race condition in various scenarios but I failed to = find any indication of crossover between BYE and UPDATE. So I have a connected callLeg, and I send an UPDATE transaction from A to B= . At the same time, I send BYE from B to A. Should A re-transmit the UPDATE in case B did not answer even after A repli= ed with 200OK for the BYE? What about other general transactions (such as OPTION)? Is UPDATE special i= n this case and should be treated differently than other general transactions on that call? Thanks, Ofer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_D885B128C85C4AC292F21D8A2352F2AEavayacom_ Content-Type: text/html; charset="iso-8859-8-i" Content-Transfer-Encoding: quoted-printable
Thank you all for the clear answers.

Sent from IPhone 7


=E1-8 =E1=EE=F8=F5 2013, =E1=F9=F2=E4 09:15, "OKUMURA Shinji" <= ;shinji.okumura@softfront.jp= > =EB=FA=E1/=E4:

Hi,

Additionally, if any subscription exist, the dialog does not terminat= e.

Shinji.

Christer Holmberg <christer.holmberg@ericsson.com>
Thu, 7 Mar 2013 11:26:37 +0000
Hi,

As the BYE terminates the dialog, I see no = reason why you should re-transit the UPDATE, or any other mid-dialog reques= ts
associated with that dialog, as the dialog = doesn't exist anymore.

Regards,

Christer


From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: sip= core@ietf.org
Subject: [sipcore] Question on RFC 5407 (cr= ossover of BYE and UPDATE)


Hi

I checked RFC 5407 for race condition in va= rious scenarios but I failed to find any indication of crossover between BY= E and
UPDATE.
So I have a connected callLeg, and I send a= n UPDATE transaction from A to B. At the same time, I send BYE from B to A.=
Should A re-transmit the UPDATE in case B d= id not answer even after A replied with 200OK for the BYE?
What about other general transactions (such= as OPTION)? Is UPDATE special in this case and should be treated different= ly than
other general transactions on that call?

Thanks,
Ofer
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_D885B128C85C4AC292F21D8A2352F2AEavayacom_-- From internet-drafts@ietf.org Mon Mar 11 03:35:08 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A5421F86BE; Mon, 11 Mar 2013 03:35:08 -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.093, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYc681iFSbiH; Mon, 11 Mar 2013 03:35:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2A821F86C4; Mon, 11 Mar 2013 03:35:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311103507.17782.99152.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2013 03:35:07 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 10:35:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : The WebSocket Protocol as a Transport for the Session In= itiation Protocol (SIP) Author(s) : Inaki Baz Castillo Jose Luis Millan Villegas Victor Pascual Filename : draft-ietf-sipcore-sip-websocket-08.txt Pages : 22 Date : 2013-03-11 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document normatively updates RFC 3261. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Mon Mar 11 03:40:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8FB21F86DE for ; Mon, 11 Mar 2013 03:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjXUm1+yrZmu for ; Mon, 11 Mar 2013 03:40:21 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 752BC21F86D4 for ; Mon, 11 Mar 2013 03:40:21 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id b4so2180616qen.32 for ; Mon, 11 Mar 2013 03:40:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=sjMu1DoTnjSpaRV5cP7GUWjqFBiiySVS4fboSm6DHdc=; b=AAEF61VA+awRgCaL/mDLYtTeeolmLrlc6P3L1ia8QJTEX19y93S47SV5itjsFRoPh/ VmcTdIlyt9v8EQnsz3yHuEWnHB4YBMv8q1k0OceCiWesAXsaJimgHeOSOBFRnk+UVnFV 5+OlGxQ9GzjlAzPyQ/VMCIhzQPiiiXpLGZnD+6OQuSDnL0A1I4A+bs9FlUDHAOcdK3+f 5ryqSNdxmC9RDYdSg5MvMmAhKFsfvwNzAKV2m0LqOITIBzGoJbqx2z5qucLIXq6vKpsu K5eijgsoX/7naRNGsnq8YWq8QezSDyp93L1bWU3EYO0thgnFkfSA2pyEYOHoYOGqwKBe AnNA== X-Received: by 10.229.76.37 with SMTP id a37mr2272243qck.130.1362998420864; Mon, 11 Mar 2013 03:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Mon, 11 Mar 2013 03:40:00 -0700 (PDT) In-Reply-To: <20130311103507.17782.99152.idtracker@ietfa.amsl.com> References: <20130311103507.17782.99152.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Mar 2013 11:40:00 +0100 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYezJMq22ase82y39cXSNdagxyNjBOCHULdeslCJkMrCvgOtWHNSnLEqMWXbPvMeFBQjIB Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 10:40:22 -0000 2013/3/11 : > > 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 Workin= g Group of the IETF. > > Title : The WebSocket Protocol as a Transport for the S= ession Initiation Protocol (SIP) > Author(s) : Inaki Baz Castillo > Jose Luis Millan Villegas > Victor Pascual > Filename : draft-ietf-sipcore-sip-websocket-08.txt > Pages : 22 > Date : 2013-03-11 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers in web-based applications. This document > specifies a WebSocket sub-protocol as a reliable transport mechanism > between SIP (Session Initiation Protocol) entities to enable usage of > SIP in web-oriented deployments. This document normatively updates > RFC 3261. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-08 Hi all. The changelog in this new revision is the following: - Added a "SIP Transport Registry" under "IANA Considerations" section (thanks to Robert Sparks and Paul Kyzivat). Best regards. --=20 I=C3=B1aki Baz Castillo From Internet-Drafts@ietf.org Tue Mar 19 09:04:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3A921F8DD9; Tue, 19 Mar 2013 09:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwGKpYnoq0ek; Tue, 19 Mar 2013 09:04:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B128421F8D8B; Tue, 19 Mar 2013 09:04:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130319160440.32665.76074.idtracker@ietfa.amsl.com> Date: Tue, 19 Mar 2013 09:04:40 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-rfc4244bis-callflows-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:04:41 -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) History-Info Header Call Flow Examples Author(s) : M. Barnes, et al Filename : draft-ietf-sipcore-rfc4244bis-callflows Pages : 46 Date : March 19, 2013 This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-callflows-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc4244bis-callflows"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-03-19090440.I-D@ietf.org> --NextPart-- From worley@shell01.TheWorld.com Thu Mar 21 15:03:24 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B148221F8C66 for ; Thu, 21 Mar 2013 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SASt2SryeRdE for ; Thu, 21 Mar 2013 15:03:23 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5219921F8B97 for ; Thu, 21 Mar 2013 15:03:20 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2LM2c3P018993; Thu, 21 Mar 2013 18:02:40 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2LM2Z81898873; Thu, 21 Mar 2013 17:02:35 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2LM2YPn898084; Thu, 21 Mar 2013 18:02:34 -0400 (EDT) Date: Thu, 21 Mar 2013 18:02:34 -0400 (EDT) Message-Id: <201303212202.r2LM2YPn898084@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: OKUMURA Shinji In-reply-to: <29CE1B24928B3Ashinji.okumura@softfront.jp> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> <201303012119.r21LJ0mg2857344@shell01.TheWorld.com> <29CE1B24928B3Ashinji.okumura@softfront.jp> Cc: sipcore@ietf.org Subject: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:03:24 -0000 > From: OKUMURA Shinji > Date: Thu, 07 Mar 2013 20:11:53 +0900 > > one point. > > worley@ariadne.com (Dale R. Worley) > Fri, 1 Mar 2013 16:19:00 -0500 (EST) > > >3.7. Consumer Voicemail Example > > > History-Info: ;\ > >- index=1.3.1;rc=1.3 > >+ index=1.2.2.1;rc=1.2.1 > ^^^^^ > 1.2.2 Yes, you are right about that. Dale From worley@shell01.TheWorld.com Fri Mar 22 08:57:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDD021F855C for ; Fri, 22 Mar 2013 08:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NDEwR1v6uvt for ; Fri, 22 Mar 2013 08:57:12 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1B21F84B5 for ; Fri, 22 Mar 2013 08:57:11 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2MFv2GL023599 for ; Fri, 22 Mar 2013 11:57:05 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2MFv2em951825 for ; Fri, 22 Mar 2013 10:57:02 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2MFv0wt939514; Fri, 22 Mar 2013 11:57:00 -0400 (EDT) Date: Fri, 22 Mar 2013 11:57:00 -0400 (EDT) Message-Id: <201303221557.r2MFv0wt939514@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] Copy edits for draft-ietf-sipcore-rfc4244bis-callflows-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:57:13 -0000 This is a bunch of copy-edits to draft-ietf-sipcore-rfc4244bis-callflows-03. Section pointers are marked with "*" at the left margin. Individual items are marked with "." at the left margin. (Finding the inconsistencies between the various History-Info values was made infinitely easier by a Perl script, "hi-consistency", which is appended. If you give that script the -03 draft, the output flags inconsistent values of the H-I headers within each section of the draft. The output it generates from -03 is also appended.) * All of the figure headings have the "figure N" part doubled: Figure 1: Figure 1: Example with Sequential Forking Figure 2: Figure 2: Example with Privacy Header Fields Figure 3: Figure 3: Example with Privacy Header Field for Specific Figure 4: Figure 4: Example for Automatic Call Distribution Figure 5: Figure 5: Alias Example Figure 6: Figure 6: Enterprise Voivemail Example Figure 7: Figure 7: Consumer Voivemail Example Figure 8: Figure 8: GRUU Example Figure 9: Figure 9: Limited Use Address Example Figure 10: Figure 10: Service Number Example (I expect the RFC Editor can correct this.) * Section 3.1 . From F8, I see that the rule is to record 1xx responses as well as final failure responses: History-Info: ;\ index=1.2.1;rc=1.2 (If recording 1xx responses with Reason is not intended, please modify the following items by removing any Reason header-value that specifies a 1xx cause value.) . Correct the punctuation: F8 180 Ringing example.com -> alice - History-Info: ;\ + History-Info: ;\ index=1.2.1;rc=1.2 . Remove duplicate index parameter: F9 INVITE example.com -> home History-Info: ;\ - index=1.2.1;index=1.2.1;rc=1.2 + index=1.2.1;rc=1.2 . The handling of the Reason on index=1.2 seems to be inconsistent: Branch 1.2 is first seen in INVITE F6. (INVITE F6 itself is index=1.2.1, generated by internal forking from branch 1.2.) F6 INVITE example.com -> office History-Info: ;index=1.2;mp=1 INVITE F9 is branch 1.3.1, generated by internal forking from branch 1.3, which was generated due to the failure of INVITE F6 (by the timeout between F8 and F9). In F9, index=1.2.1 is shown with a Reason value (which is mandatory), but index=1.2 is not (which is allowed, but not best practice). F9 INVITE example.com -> home History-Info: ;index=1.2;mp=1 History-Info: ;\ index=1.2.1;index=1.2.1;rc=1.2 INVITE F11 follows the pattern of F9. F11 486 Busy Here home -> example.com History-Info: ;index=1.2;mp=1 But response F12 shows the Reason value on index=1.2 that is best practice. F12 486 Busy Here example.com -> alice History-Info: ;\ index=1.2;mp=1 I think what is intended is for F8, F9 and F11 to have the Reason value on index=1.2 as well. F8 180 Ringing example.com -> alice - History-Info: ;index=1.2;mp=1 + History-Info: ;\ + index=1.2;mp=1 F9 INVITE example.com -> home - History-Info: ;index=1.2;mp=1 + History-Info: ;\ + index=1.2;mp=1 F11 486 Busy Here home -> example.com - History-Info: ;index=1.2;mp=1 + History-Info: ;\ + index=1.2;mp=1 * Section 3.4 . Make F5 consistent with preceding messages: F5 INVITE Silver.Example.com -> Agent History-Info: ;\ - index=1.1 + rc=1;index=1.1 Same for F6, F7, and F8. * Section 3.6 . URIs for 1.2 and 1.2.1 are not consistent: F4 INVITE Example.com -> Carol History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 F5 180 Ringing Carol -> Example.com History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 F6 INVITE Example.com -> VM History-Info: ;index=1.2;mp=1 History-Info: ;\ index=1.2.1;rc=1.2 F7 200 OK VM -> Example.com History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 My understanding is that the intention is to show use of the cause URI parameter (not the cause value in Reason!) per RFC 4458. (See Marianne Mohali's explanation of the situation at http://www.ietf.org/mail-archive/web/sipcore/current/msg05514.html.) If that is so, the URI for branch 1.2 would be generated as shown in F7, , and presumably the parameter would be carried into the URI for branch 1.2.1. That requires the changes shown below. . Also, in INVITE F6, the timeout (408) response to branches 1.2 and 1.2.1 would already be recorded, as they are in response F7 (which is generated from INVITE F6!). Those changes are also included below. . Also, in response F7, the cause URI parameter recorded in branches 1.3 and 1.3.1 is not the same as in INVITE F6: F6 has "cause=480" and F7 has "cause=408". Which code to choose depends on the application logic (see the discussion around Marianne Mohali's message referenced above), and I have no particular opinion one way or the other, but the two messages must be consistent. No change for that is included below. F4 INVITE Example.com -> Carol - History-Info: ;index=1.2;mp=1 - History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2;mp=1 + History-Info: - ;index=1.2.1;rc=1.2 F5 180 Ringing Carol -> Example.com - History-Info: ;index=1.2;mp=1 - History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2;mp=1 + History-Info: - ;index=1.2.1;rc=1.2 F6 INVITE Example.com -> VM - History-Info: ;index=1.2;mp=1 - History-Info: ;\ - index=1.2.1;rc=1.2 + History-Info: - ;index=1.2;mp=1 + History-Info: - ;index=1.2.1;rc=1.2 F7 200 OK VM -> Example.com History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 * Section 3.7 . There are a number of H-I entries that want to encode a cause text "Moved Temporarily". More exactly, they encode a URI header parameter which represents the header field: Reason: SIP;cause=302;text="Moved Temporarily" Since space, double-quote, semicolon, and equals are reserved in URI header-parameter values, they must all be escaped. There is also a consistent problem with excessive indenting (but the RFC Editor will clean that up). The first three instances of the 1.1 H-I entry need to have the marked line amended to match the final instance (which is correct). F4 INVITE Example.com -> Carol History-Info: \ ;index=1.1;rc=1 F5 180 Ringing Carol -> Example.com History-Info: \ ;index=1.1;rc=1 F6 INVITE Example.com -> VM History-Info: \ ;index=1.1;rc=1 F7 200 OK VM -> Example.com History-Info: \ ;index=1.1;rc=1 . There are inconsistencies between INVITE F6 and response F7. Given the changes from -02 to -03, the I believe the intention is that the branch 1.2.2 to is to be a child of the branch 1.2 to . (Which seems to be the best practice.) But the change has not been made in F6. There is also a ";cause=408" in F6 index 1.3.1 which seems to be extraneous. (If it were intended, it would be part of the URI, and also part of the URI for index 1.3.) The index value of in F7 should be 1.2.2.1. F6 INVITE Example.com -> VM History-Info: ;\ - index=1.3;mp=1.2 + index=1.2.2;mp=1.2 History-Info: \ - ;cause=408;index=1.3.1;rc=1.3 + ;index=1.2.2.1;rc=1.2.2 F7 200 OK VM -> Example.com History-Info: ;\ index=1.2.2;mp=1.2 History-Info: ;\ - index=1.2.2;rc=1.2.1 + index=1.2.2.1;rc=1.2.2 ---------------------------------------------------------------------- #! /bin/perl # Check consistency of History-Info headers. use strict; my($section, $section_full); my($message, $message_full); my($hi); my(%history); my(@input) = <>; while ($_ = shift(@input)) { chomp; if (($section_full, $section) = /^\s*((\d|\d[.\d]*\d)\. .*?)\s*$/) { # This picks up the table of contents lines as well as the # section headers. print "\n"; print "Section $section_full\n"; $message = '(none)'; # Clear the known history. %history = (); } elsif (($message_full, $message) = /^\s*((F\d+) .*?)\s*$/) { # This picks up the headers for individual messages print "Message $message_full\n"; } elsif (($hi) = /^\s*(history-info:.*)$/i) { # Pick up a History-Info header. # Check for continuation lines. while ($hi =~ /\\\s*$/) { # Grab the next input line. $_ = shift(@input); chomp; # Check for page break lines and ignore them. if (/^\s*$/ || /^Barnes, et al/ || /^\014/ || /^Internet-Draft/) { # Ignore all these. } else { # Append this line to the History-Info header. $hi .= "\n" . $_; } } # Now remove the continuations. $hi =~ s/\s*\\\s*\n\s*//g; # Check to see if the H-I entry has changed. my($index) = ($hi =~ /index=([\d.]+)/); my($previous) = $history{$index}; if ($previous && $previous ne $hi) { # Add "!" if the change isn't adding a Reason header value. my($x) = $hi; $x =~ s/\?reason=[^>&]*//i; # print "A $hi\n$x\n$previous\n"; print "! " unless $x eq $previous; print "Changed $index\nfrom: $previous\nto: $hi\n"; } $history{$index} = $hi; } } ---------------------------------------------------------------------- Section 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Section 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 Section 3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3 Section 3.1. Sequentially Forking (History-Info in Response) . . . . . 3 Section 3.2. History-Info with Privacy Header Field . . . . . . . . . . 11 Section 3.3. Privacy for a Specific History-Info Entry . . . . . . . . 14 Section 3.4. Automatic Call Distribution . . . . . . . . . . . . . . . 18 Section 3.5. Determining the Alias used. . . . . . . . . . . . . . . . 23 Section 3.6. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 26 Section 3.7. Consumer Voicemail Example . . . . . . . . . . . . . . . . 31 Section 3.8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Section 3.9. Limited Use Address . . . . . . . . . . . . . . . . . . . 38 Section 3.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 41 Section 3.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 41 Section 4. Security Considerations . . . . . . . . . . . . . . . . . . . 44 Section 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 Section 5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 44 Section 6. Informative References . . . . . . . . . . . . . . . . . . . . 44 Section 1. Overview Section 2. Conventions and Terminology Section 3. Detailed call flows Section 3.1. Sequentially Forking (History-Info in Response) Message F1 INVITE alice -> example.com Message F2 INVITE example.com -> Bob Message F3 100 Trying example.com -> alice Message F4 302 Moved Temporarily Bob -> example.com Message F5 ACK example.com -> Bob Message F6 INVITE example.com -> office Changed 1.1 from: History-Info: ;index=1.1;rc=1 to: History-Info: ;index=1.1;rc=1 Message F7 180 Ringing office -> example.com Message F8 180 Ringing example.com -> alice ! Changed 1.2.1 from: History-Info: ;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;rc=1.2 Message F9 INVITE example.com -> home ! Changed 1.2.1 from: History-Info: ;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;index=1.2.1;rc=1.2 Message F10 100 Trying home -> example.com Message F11 486 Busy Here home -> example.com Message F12 486 Busy Here example.com -> alice Changed 1.2 from: History-Info: ;index=1.2;mp=1 to: History-Info: ;index=1.2;mp=1 ! Changed 1.2.1 from: History-Info: ;index=1.2.1;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;rc=1.2 Message F13 ACK example.com -> home Message F14 ACK alice -> example.com Section 3.2. History-Info with Privacy Header Field Message F1 INVITE alice -> atlanta.example.com Message F2 INVITE atlanta.example.com -> biloxi.example.com ! Changed 1 from: History-Info: ;index=1 to: History-Info: ;index=1 Message F3 INVITE biloxi.example.com -> Bob Message F4 200 OK Bob -> biloxi.example.com Message F5 200 OK biloxi.example.com -> atlanta.example.com ! Changed 1.1.1 from: History-Info: ;index=1.1.1;rc=1.1 to: History-Info: ;index=1.1.1;rc=1.1 Message F6 200 OK atlanta.example.com -> Alice Section 3.3. Privacy for a Specific History-Info Entry Message F1 INVITE alice -> atlanta.example.com Message F2 INVITE atlanta.example.com -> biloxi.example.com Message F3 INVITE biloxi.example.com -> Bob Message F4 200 OK Bob -> biloxi.example.com Message F5 200 OK biloxi.example.com -> atlanta.example.com ! Changed 1.1.1 from: History-Info: ;index=1.1.1;rc=1.1 to: History-Info: ;index=1.1.1;rc=1.1 Message F6 200 OK atlanta.example.com -> Alice Section 3.4. Automatic Call Distribution Message F1 INVITE Alice -> Example.com Message F2 INVITE Example.com -> Gold.Example.com Message F3 302 Moved Temporarily Gold.Example.com -> Example.com Message F4 INVITE Example.com -> Silver.Example.com Changed 1.1 from: History-Info: ;rc=1;index=1.1 to: History-Info: ;rc=1;index=1.1 Message F5 INVITE Silver.Example.com -> Agent ! Changed 1.1 from: History-Info: ;rc=1;index=1.1 to: History-Info: ;index=1.1 Message F6 200 OK Agent -> Silver.Example.com Message F7 200 OK Silver.Example.com -> Example.com Message F8 200 OK Example.com -> Alice Message F9 ACK Alice -> Agent Section 3.5. Determining the Alias used. Message F1 REGISTER John -> Example.com Message F2 200 OK Example.com -> John Message F3 INVITE Alice -> Example.com Message F4 INVITE Example.com -> John Section 3.6. PBX Voicemail Example Message F1 INVITE Alice -> Example.com Message F2 INVITE Example.com -> Bob Message F3 302 Moved Temporarily Bob -> Example.com Message F4 INVITE Example.com -> Carol Changed 1.1 from: History-Info: ;index=1.1;rc=1 to: History-Info: ;index=1.1;rc=1 Message F5 180 Ringing Carol -> Example.com Message F6 INVITE Example.com -> VM ! Changed 1.2.1 from: History-Info: ;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;rc=1.2 Message F7 200 OK VM -> Example.com ! Changed 1.2 from: History-Info: ;index=1.2;mp=1 to: History-Info: ;index=1.2;mp=1 Changed 1.2.1 from: History-Info: ;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;rc=1.2 ! Changed 1.3 from: History-Info: ;index=1.3;mp=1 to: History-Info: ;index=1.3;mp=1 ! Changed 1.3.1 from: History-Info: ;index=1.3.1;rc=1.3 to: History-Info: ;index=1.3.1;rc=1.3 Section 3.7. Consumer Voicemail Example Message F1 INVITE Alice -> Example.com Message F2 INVITE Example.com -> Bob Message F3 302 Moved Temporarily Bob -> Example.com Message F4 INVITE Example.com -> Carol Changed 1.1 from: History-Info: ;index=1.1;rc=1 to: History-Info: ;index=1.1;rc=1 Message F5 180 Ringing Carol -> Example.com ! Changed 1.1 from: History-Info: ;index=1.1;rc=1 to: History-Info: ;index=1.1;rc=1 Message F6 INVITE Example.com -> VM Changed 1.2 from: History-Info: ;index=1.2;mp=1 to: History-Info: ;index=1.2;mp=1 Message F7 200 OK VM -> Example.com ! Changed 1.1 from: History-Info: ;index=1.1;rc=1 to: History-Info: ;index=1.1;rc=1 Changed 1.2.1 from: History-Info: ;index=1.2.1;rc=1.2 to: History-Info: ;index=1.2.1;rc=1.2 ! Changed 1.2.2 from: History-Info: ;index=1.2.2;mp=1.2 to: History-Info: ;index=1.2.2;rc=1.2.1 Section 3.8. GRUU Message F1 REGISTER John -> Example.com Message F2 200 OK Example.com -> John Message F3 INVITE Alice -> Example.com Message F4 INVITE Example.com -> John Section 3.9. Limited Use Address Message F1 REGISTER John -> Example.com Message F2 200 OK Example.com -> John Message F3 INVITE Alice -> Example.com Message F4 INVITE Example.com -> John Section 3.10. Service Invocation Section 3.11. Toll Free Number Section 4. Security Considerations Section 5. IANA Considerations Section 5.1. Acknowledgements Section 6. Informative References ---------------------------------------------------------------------- Dale From shida@ntt-at.com Fri Mar 22 13:48:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8959621F88A2 for ; Fri, 22 Mar 2013 13:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6oilNtwgE1d for ; Fri, 22 Mar 2013 13:48:42 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D288B21F8A6F for ; Fri, 22 Mar 2013 13:48:41 -0700 (PDT) Received: from [50.152.169.249] (port=56751 helo=[192.168.11.11]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UJ8tB-0004sp-D9; Fri, 22 Mar 2013 15:48:37 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201303221557.r2MFv0wt939514@shell01.TheWorld.com> Date: Fri, 22 Mar 2013 13:48:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201303221557.r2MFv0wt939514@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.11.11]) [50.152.169.249]:56751 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] Copy edits for draft-ietf-sipcore-rfc4244bis-callflows-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 20:48:43 -0000 Hi Dale; Thanks for going through the draft once again.=20 I will reflect these and update the draft shortly.=20 Many Thanks Shida On Mar 22, 2013, at 8:57 AM, Dale R. Worley wrote: > This is a bunch of copy-edits to > draft-ietf-sipcore-rfc4244bis-callflows-03. Section pointers are > marked with "*" at the left margin. Individual items are marked with > "." at the left margin. >=20 > (Finding the inconsistencies between the various History-Info values > was made infinitely easier by a Perl script, "hi-consistency", which > is appended. If you give that script the -03 draft, the output > flags inconsistent values of the H-I headers within each section of > the draft. The output it generates from -03 is also appended.) >=20 > * All of the figure headings have the "figure N" part doubled: >=20 > Figure 1: Figure 1: Example with Sequential Forking > Figure 2: Figure 2: Example with Privacy Header Fields > Figure 3: Figure 3: Example with Privacy Header Field for Specific > Figure 4: Figure 4: Example for Automatic Call Distribution > Figure 5: Figure 5: Alias Example > Figure 6: Figure 6: Enterprise Voivemail Example > Figure 7: Figure 7: Consumer Voivemail Example > Figure 8: Figure 8: GRUU Example > Figure 9: Figure 9: Limited Use Address Example > Figure 10: Figure 10: Service Number Example >=20 > (I expect the RFC Editor can correct this.) >=20 > * Section 3.1 >=20 > . =46rom F8, I see that the rule is to record 1xx responses as well as > final failure responses: >=20 > History-Info: ;\ > = index=3D1.2.1;rc=3D1.2 >=20 > (If recording 1xx responses with Reason is not intended, please modify > the following items by removing any Reason header-value that specifies > a 1xx cause value.) >=20 > . Correct the punctuation: >=20 > F8 180 Ringing example.com -> alice >=20 > - History-Info: ;\ > + History-Info: ;\ > = index=3D1.2.1;rc=3D1.2 >=20 > . Remove duplicate index parameter: >=20 > F9 INVITE example.com -> home >=20 > History-Info: ;\ > - index=3D1.2.1;index=3D1.2.1;rc=3D1.2 > + index=3D1.2.1;rc=3D1.2 >=20 > . The handling of the Reason on index=3D1.2 seems to be inconsistent: >=20 > Branch 1.2 is first seen in INVITE F6. (INVITE F6 itself is > index=3D1.2.1, generated by internal forking from branch 1.2.) >=20 > F6 INVITE example.com -> office >=20 > History-Info: ;index=3D1.2;mp=3D1 >=20 > INVITE F9 is branch 1.3.1, generated by internal forking from branch > 1.3, which was generated due to the failure of INVITE F6 (by the > timeout between F8 and F9). In F9, index=3D1.2.1 is shown with a = Reason > value (which is mandatory), but index=3D1.2 is not (which is allowed, > but not best practice). >=20 > F9 INVITE example.com -> home >=20 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;\ > index=3D1.2.1;index=3D1.2.1;rc=3D1.2 >=20 > INVITE F11 follows the pattern of F9. >=20 > F11 486 Busy Here home -> example.com >=20 > History-Info: ;index=3D1.2;mp=3D1 >=20 > But response F12 shows the Reason value on index=3D1.2 that is best > practice. >=20 > F12 486 Busy Here example.com -> alice >=20 > History-Info: ;\ > = index=3D1.2;mp=3D1 >=20 > I think what is intended is for F8, F9 and F11 to have the Reason > value on > index=3D1.2 as well. >=20 > F8 180 Ringing example.com -> alice >=20 > - History-Info: ;index=3D1.2;mp=3D1 > + History-Info: > ;\ > + index=3D1.2;mp=3D1= >=20 > F9 INVITE example.com -> home >=20 > - History-Info: ;index=3D1.2;mp=3D1 > + History-Info: > ;\ > + index=3D1.2;mp=3D1= >=20 > F11 486 Busy Here home -> example.com >=20 > - History-Info: ;index=3D1.2;mp=3D1 > + History-Info: > ;\ > + index=3D1.2;mp=3D1= >=20 > * Section 3.4 >=20 > . Make F5 consistent with preceding messages: >=20 > F5 INVITE Silver.Example.com -> Agent >=20 > History-Info: > ;\ > - index=3D1.1 > + rc=3D1;index=3D1.1 >=20 > Same for F6, F7, and F8. >=20 > * Section 3.6 >=20 > . URIs for 1.2 and 1.2.1 are not consistent: >=20 > F4 INVITE Example.com -> Carol >=20 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1;rc=3D1.2 >=20 > F5 180 Ringing Carol -> Example.com >=20 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1;rc=3D1.2 >=20 > F6 INVITE Example.com -> VM >=20 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;\ > index=3D1.2.1;rc=3D1.2 >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: > 408>;index=3D1.2;mp=3D1 > History-Info: 408>;index=3D1.2.1;rc=3D1.2 >=20 > My understanding is that the intention is to show use of the cause URI > parameter (not the cause value in Reason!) per RFC 4458. (See > Marianne Mohali's explanation of the situation at > http://www.ietf.org/mail-archive/web/sipcore/current/msg05514.html.) > If that is so, the URI for branch 1.2 would be generated as shown in > F7, , and presumably the parameter > would be carried into the URI for branch 1.2.1. That requires the > changes shown below. >=20 > . Also, in INVITE F6, the timeout (408) response to branches 1.2 > and 1.2.1 would already be recorded, as they are in response F7 (which > is generated from INVITE F6!). Those changes are also included below. >=20 > . Also, in response F7, the cause URI parameter recorded in branches > 1.3 and 1.3.1 is not the same as in INVITE F6: F6 has "cause=3D480" = and > F7 has "cause=3D408". Which code to choose depends on the application > logic (see the discussion around Marianne Mohali's message referenced > above), and I have no particular opinion one way or the other, but the > two messages must be consistent. No change for that is included > below. >=20 > F4 INVITE Example.com -> Carol >=20 > - History-Info: ;index=3D1.2;mp=3D1 > - History-Info: ;index=3D1.2.1;rc=3D1.2 > + History-Info: ;index=3D1.2;mp=3D= 1 > + History-Info: > - ;index=3D1.2.1;rc=3D1.2 >=20 > F5 180 Ringing Carol -> Example.com >=20 > - History-Info: ;index=3D1.2;mp=3D1 > - History-Info: ;index=3D1.2.1;rc=3D1.2 > + History-Info: ;index=3D1.2;mp=3D= 1 > + History-Info: > - ;index=3D1.2.1;rc=3D1.2 >=20 > F6 INVITE Example.com -> VM >=20 > - History-Info: ;index=3D1.2;mp=3D1 > - History-Info: ;\ > - index=3D1.2.1;rc=3D1.2 > + History-Info: > - + 408>;index=3D1.2;mp=3D1 > + History-Info: > - + 408>;index=3D1.2.1;rc=3D1.2 >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: > 408>;index=3D1.2;mp=3D1 > History-Info: > 408>;index=3D1.2.1;rc=3D1.2 >=20 > * Section 3.7 >=20 > . There are a number of H-I entries that want to encode a cause text > "Moved Temporarily". More exactly, they encode a URI header parameter > which represents the header field: >=20 > Reason: SIP;cause=3D302;text=3D"Moved Temporarily" >=20 > Since space, double-quote, semicolon, and equals are reserved in URI > header-parameter values, they must all be escaped. There is also a > consistent problem with excessive indenting (but the RFC Editor will > clean that up). >=20 > The first three instances of the 1.1 H-I entry need to have the marked > line amended to match the final instance (which is correct). >=20 > F4 INVITE Example.com -> Carol >=20 > History-Info: + > %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 >=20 >=20 > F5 180 Ringing Carol -> Example.com >=20 > History-Info: + > %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 >=20 >=20 > F6 INVITE Example.com -> VM >=20 > History-Info: + > %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 >=20 >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: = %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 >=20 > . There are inconsistencies between INVITE F6 and response F7. Given > the changes from -02 to -03, the I believe the intention is that the > branch 1.2.2 to = is > to be a child of the branch 1.2 to . (Which > seems to be the best practice.) But the change has not been made in > F6. >=20 > There is also a ";cause=3D408" in F6 index 1.3.1 which seems to be > extraneous. (If it were intended, it would be part of the URI, and > also part of the URI for index 1.3.) >=20 > The index value of in F7 should be 1.2.2.1. >=20 > F6 INVITE Example.com -> VM >=20 > History-Info: ;\ > - index=3D1.3;mp=3D1.2 > + index=3D1.2.2;mp=3D1.2 > History-Info: \ > - ;cause=3D408;index=3D1.3.1;rc=3D1.3 > + ;index=3D1.2.2.1;rc=3D1.2.2 >=20 > F7 200 OK VM -> Example.com >=20 > History-Info: ;\ > index=3D1.2.2;mp=3D1.2 > History-Info: ;\ > - index=3D1.2.2;rc=3D1.2.1 > + index=3D1.2.2.1;rc=3D1.2.2 >=20 > ---------------------------------------------------------------------- >=20 > #! /bin/perl >=20 > # Check consistency of History-Info headers. >=20 > use strict; >=20 > my($section, $section_full); > my($message, $message_full); > my($hi); > my(%history); >=20 > my(@input) =3D <>; >=20 > while ($_ =3D shift(@input)) { > chomp; > if (($section_full, $section) =3D /^\s*((\d|\d[.\d]*\d)\. = .*?)\s*$/) > { > # This picks up the table of contents lines as well as the > # section headers. > print "\n"; > print "Section $section_full\n"; > $message =3D '(none)'; > # Clear the known history. > %history =3D (); > } elsif (($message_full, $message) =3D /^\s*((F\d+) .*?)\s*$/) { > # This picks up the headers for individual messages > print "Message $message_full\n"; > } elsif (($hi) =3D /^\s*(history-info:.*)$/i) { > # Pick up a History-Info header. > # Check for continuation lines. > while ($hi =3D~ /\\\s*$/) { > # Grab the next input line. > $_ =3D shift(@input); > chomp; > # Check for page break lines and ignore them. > if (/^\s*$/ || > /^Barnes, et al/ || > /^\014/ || > /^Internet-Draft/) { > # Ignore all these. > } else { > # Append this line to the History-Info header. > $hi .=3D "\n" . $_; > } > } > # Now remove the continuations. > $hi =3D~ s/\s*\\\s*\n\s*//g; > # Check to see if the H-I entry has changed. > my($index) =3D ($hi =3D~ /index=3D([\d.]+)/); > my($previous) =3D $history{$index}; > if ($previous && $previous ne $hi) { > # Add "!" if the change isn't adding a Reason header > value. > my($x) =3D $hi; > $x =3D~ s/\?reason=3D[^>&]*//i; > # print "A $hi\n$x\n$previous\n"; > print "! " unless $x eq $previous; > print "Changed $index\nfrom: $previous\nto: $hi\n"; > } > $history{$index} =3D $hi; > } > } >=20 > ---------------------------------------------------------------------- >=20 >=20 > Section 1. Overview > . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >=20 > Section 2. Conventions and Terminology > . . . . . . . . . . . . . . . . . 3 >=20 > Section 3. Detailed call flows > . . . . . . . . . . . . . . . . . . . . . 3 >=20 > Section 3.1. Sequentially Forking (History-Info in Response) > . . . . . 3 >=20 > Section 3.2. History-Info with Privacy Header Field > . . . . . . . . . . 11 >=20 > Section 3.3. Privacy for a Specific History-Info Entry > . . . . . . . . 14 >=20 > Section 3.4. Automatic Call Distribution > . . . . . . . . . . . . . . . 18 >=20 > Section 3.5. Determining the Alias used. > . . . . . . . . . . . . . . . 23 >=20 > Section 3.6. PBX Voicemail Example > . . . . . . . . . . . . . . . . . . 26 >=20 > Section 3.7. Consumer Voicemail Example > . . . . . . . . . . . . . . . . 31 >=20 > Section 3.8. GRUU > . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 >=20 > Section 3.9. Limited Use Address > . . . . . . . . . . . . . . . . . . . 38 >=20 > Section 3.10. Service Invocation > . . . . . . . . . . . . . . . . . . . . 41 >=20 > Section 3.11. Toll Free Number > . . . . . . . . . . . . . . . . . . . . . 41 >=20 > Section 4. Security Considerations > . . . . . . . . . . . . . . . . . . . 44 >=20 > Section 5. IANA Considerations > . . . . . . . . . . . . . . . . . . . . . 44 >=20 > Section 5.1. Acknowledgements > . . . . . . . . . . . . . . . . . . . . . 44 >=20 > Section 6. Informative References > . . . . . . . . . . . . . . . . . . . . 44 >=20 > Section 1. Overview >=20 > Section 2. Conventions and Terminology >=20 > Section 3. Detailed call flows >=20 > Section 3.1. Sequentially Forking (History-Info in Response) > Message F1 INVITE alice -> example.com > Message F2 INVITE example.com -> Bob > Message F3 100 Trying example.com -> alice > Message F4 302 Moved Temporarily Bob -> example.com > Message F5 ACK example.com -> Bob > Message F6 INVITE example.com -> office > Changed 1.1 > from: History-Info: ;index=3D1.1;rc=3D1 > to: History-Info: > ;index=3D1.1;rc=3D1 > Message F7 180 Ringing office -> example.com > Message F8 180 Ringing example.com -> alice > ! Changed 1.2.1 > from: History-Info: ;index=3D1.2.1;rc=3D1.2 > to: History-Info: > ;index=3D1.2.1;rc=3D1.2= > Message F9 INVITE example.com -> home > ! Changed 1.2.1 > from: History-Info: > ;index=3D1.2.1;rc=3D1.2= > to: History-Info: > = ;index=3D1.2.1;index=3D1.= 2.1;rc=3D1.2 > Message F10 100 Trying home -> example.com > Message F11 486 Busy Here home -> example.com > Message F12 486 Busy Here example.com -> alice > Changed 1.2 > from: History-Info: ;index=3D1.2;mp=3D1 > to: History-Info: > ;index=3D1.2;mp=3D1 > ! Changed 1.2.1 > from: History-Info: > = ;index=3D1.2.1;index=3D1.= 2.1;rc=3D1.2 > to: History-Info: > ;index=3D1.2.1;rc=3D1.2= > Message F13 ACK example.com -> home > Message F14 ACK alice -> example.com >=20 > Section 3.2. History-Info with Privacy Header Field > Message F1 INVITE alice -> atlanta.example.com > Message F2 INVITE atlanta.example.com -> biloxi.example.com > ! Changed 1 > from: History-Info: ;index=3D1 > to: History-Info: ;index=3D1 > Message F3 INVITE biloxi.example.com -> Bob > Message F4 200 OK Bob -> biloxi.example.com > Message F5 200 OK biloxi.example.com -> atlanta.example.com > ! Changed 1.1.1 > from: History-Info: > ;index=3D1.1.1;rc=3D1.1 > to: History-Info: ;index=3D1.1.1;rc=3D1= .1 > Message F6 200 OK atlanta.example.com -> Alice >=20 > Section 3.3. Privacy for a Specific History-Info Entry > Message F1 INVITE alice -> atlanta.example.com > Message F2 INVITE atlanta.example.com -> biloxi.example.com > Message F3 INVITE biloxi.example.com -> Bob > Message F4 200 OK Bob -> biloxi.example.com > Message F5 200 OK biloxi.example.com -> atlanta.example.com > ! Changed 1.1.1 > from: History-Info: > ;index=3D1.1.1;rc=3D1.1 > to: History-Info: ;index=3D1.1.1;rc=3D1= .1 > Message F6 200 OK atlanta.example.com -> Alice >=20 > Section 3.4. Automatic Call Distribution > Message F1 INVITE Alice -> Example.com > Message F2 INVITE Example.com -> Gold.Example.com > Message F3 302 Moved Temporarily Gold.Example.com -> Example.com > Message F4 INVITE Example.com -> Silver.Example.com > Changed 1.1 > from: History-Info: ;rc=3D1;index=3D1.1 > to: History-Info: > ;rc=3D1;index=3D1.= 1 > Message F5 INVITE Silver.Example.com -> Agent > ! Changed 1.1 > from: History-Info: > ;rc=3D1;index=3D1.= 1 > to: History-Info: > ;index=3D1.1 > Message F6 200 OK Agent -> Silver.Example.com > Message F7 200 OK Silver.Example.com -> Example.com > Message F8 200 OK Example.com -> Alice > Message F9 ACK Alice -> Agent >=20 > Section 3.5. Determining the Alias used. > Message F1 REGISTER John -> Example.com > Message F2 200 OK Example.com -> John > Message F3 INVITE Alice -> Example.com > Message F4 INVITE Example.com -> John >=20 > Section 3.6. PBX Voicemail Example > Message F1 INVITE Alice -> Example.com > Message F2 INVITE Example.com -> Bob > Message F3 302 Moved Temporarily Bob -> Example.com > Message F4 INVITE Example.com -> Carol > Changed 1.1 > from: History-Info: ;index=3D1.1;rc=3D1 > to: History-Info: > ;index=3D1.1;rc=3D1 > Message F5 180 Ringing Carol -> Example.com > Message F6 INVITE Example.com -> VM > ! Changed 1.2.1 > from: History-Info: ;index=3D1.2.1;rc=3D1.2 > to: History-Info: ;index=3D1.2.1;rc=3D1= .2 > Message F7 200 OK VM -> Example.com > ! Changed 1.2 > from: History-Info: ;index=3D1.2;mp=3D1 > to: History-Info: > = ;index=3D1.2= ;mp=3D1 > Changed 1.2.1 > from: History-Info: ;index=3D1.2.1;rc=3D= 1.2 > to: History-Info: > = ;index=3D1.2.1= ;rc=3D1.2 > ! Changed 1.3 > from: History-Info: > = ;index=3D1.= 3;mp=3D1 > to: History-Info: > = ;index=3D1.= 3;mp=3D1 > ! Changed 1.3.1 > from: History-Info: > = ;index=3D1.3.= 1;rc=3D1.3 > to: History-Info: > = ;index=3D1.3.= 1;rc=3D1.3 >=20 > Section 3.7. Consumer Voicemail Example > Message F1 INVITE Alice -> Example.com > Message F2 INVITE Example.com -> Bob > Message F3 302 Moved Temporarily Bob -> Example.com > Message F4 INVITE Example.com -> Carol > Changed 1.1 > from: History-Info: ;index=3D1.1;rc=3D1 > to: History-Info: > Temporarily">;index=3D1.1;rc=3D1 > Message F5 180 Ringing Carol -> Example.com > ! Changed 1.1 > from: History-Info: > Temporarily">;index=3D1.1;rc=3D1 > to: History-Info: > Temporarily">;index=3D1.1;rc=3D1 > Message F6 INVITE Example.com -> VM > Changed 1.2 > from: History-Info: ;index=3D1.2;mp=3D1 > to: History-Info: > ;index=3D1.2;mp=3D1 > Message F7 200 OK VM -> Example.com > ! Changed 1.1 > from: History-Info: > Temporarily">;index=3D1.1;rc=3D1 > to: History-Info: > = ;index=3D1.1;rc=3D1 > Changed 1.2.1 > from: History-Info: ;index=3D1.2.1;rc=3D1.2 > to: History-Info: > ;index=3D1.2.1;rc=3D1.2 > ! Changed 1.2.2 > from: History-Info: > ;index=3D1.2.2;mp=3D= 1.2 > to: History-Info: > ;index=3D1.2.2;rc=3D1= .2.1 >=20 > Section 3.8. GRUU > Message F1 REGISTER John -> Example.com > Message F2 200 OK Example.com -> John > Message F3 INVITE Alice -> Example.com > Message F4 INVITE Example.com -> John >=20 > Section 3.9. Limited Use Address > Message F1 REGISTER John -> Example.com > Message F2 200 OK Example.com -> John > Message F3 INVITE Alice -> Example.com > Message F4 INVITE Example.com -> John >=20 > Section 3.10. Service Invocation >=20 > Section 3.11. Toll Free Number >=20 > Section 4. Security Considerations >=20 > Section 5. IANA Considerations >=20 > Section 5.1. Acknowledgements >=20 > Section 6. Informative References >=20 > ---------------------------------------------------------------------- >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore