From pkyzivat@alum.mit.edu Fri Feb 1 14:36:35 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 1E2DC21E8063 for ; Fri, 1 Feb 2013 14:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 ny5f+Ar2a0an for ; Fri, 1 Feb 2013 14:36:34 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 046B521E8082 for ; Fri, 1 Feb 2013 14:36:33 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta15.westchester.pa.mail.comcast.net with comcast id v4ht1k00316LCl05FAcZjr; Fri, 01 Feb 2013 22:36:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id vAcY1k00l3ZTu2S3SAcYJe; Fri, 01 Feb 2013 22:36:33 +0000 Message-ID: <510C4370.6020306@alum.mit.edu> Date: Fri, 01 Feb 2013 17:36:32 -0500 From: Paul Kyzivat 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: "R.Jesske@telekom.de" , Laura Liess , "marianne.mohali@orange-ftgroup.com" , Brett Tate , "Dale R. Worley" References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> In-Reply-To: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359758193; bh=w6+UnTKGEqjrtaHMWn8JP6A+CBr5Va2sF33SdN4kQ8U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c+2CZNjcrvbF8zJipMZPsW4OpdHzIU5nkubnu9XoEXEhCsQPz4yeJ0DnUiNe4wnmw sD/xfsSgiLPrDY/dtGnV7m+EIK4UPM0chCoJC8zD+RJ+nTB2Nsbe0kwp2HVNqL6F97 ABiq6V0fRmoBcdZ3u80fKSPA6RBlWz328BfxqnUUOiusqJ4KQpDLoIIm6zoVgSy93o sVo/7Xj/NQKVoMLdxfhsqA3bWQ4nXej+lh1TEN5ed9ox1mGKPpzkc976BTyczgCEZg LqeblEAnMU0NhbU1e6oALxVIAQ8r4xlLFyWKDw6iwHqCZ/qmtJIOB7K8qlH7lwhGxI xji9KE46BgRPQ== Cc: SIPCORE Subject: [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 Feb 2013 22:36:35 -0000 A new version of 4244bis-callflows has been published, to address the comments we received in the WGLC review at the end of last year. I've sent this *To* the people who provided comments. I would appreciate your verifying that your comments were properly addressed. (Please comment back one way or the other.) This is *not* a new WGLC. So please don't bring up *new* issues now. We are past that. I just want to verify that the comments already raised have been handled. We are holding the bis to publish concurrently with the callflows, so is the last thing holding them up. Thanks, Paul -------- Original Message -------- Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-02.txt Date: Tue, 29 Jan 2013 12:49:12 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: sipcore@ietf.org 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) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt Pages : 46 Date : 2013-01-29 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-callflows-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From rjsparks@nostrum.com Mon Feb 4 07:49:44 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 7ABE621F88B1 for ; Mon, 4 Feb 2013 07:49:44 -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=[BAYES_00=-2.599, SPF_PASS=-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 C+I4GzXF24aC for ; Mon, 4 Feb 2013 07:49:44 -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 ED52321F892C for ; Mon, 4 Feb 2013 07:49:43 -0800 (PST) Received: from unnumerable.local (ip-64-134-55-19.public.wayport.net [64.134.55.19]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r14FngBk064078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 4 Feb 2013 09:49:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <510FD893.80405@nostrum.com> Date: Mon, 04 Feb 2013 09:49:39 -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: <50B38C22.9080307@nostrum.com> <50F6FD4E.7010806@nostrum.com> In-Reply-To: <50F6FD4E.7010806@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 64.134.55.19 is authenticated by a trusted mechanism) Subject: [sipcore] Registration for SIPit30 extended to Feb 10 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 Feb 2013 15:49:44 -0000 We are set for a great SIPit, but we still have room for more folks. The host is extending the registration deadline through Feb 10. RjS On 1/16/13 1:19 PM, Robert Sparks wrote: > The registration deadline for SIPit 30 is February 4, just over two > weeks away. > If you plan to attend, but have not yet registered, please do so today. > > Note that we will be testing against RTCWeb implementations during > Tuesdays multiparty test. > See www.sipit.net for more info. > > RjS > > On 11/26/12 9:34 AM, Robert Sparks wrote: >> Registration for SIPit 30 is open at http://www.regonline.com/sipit30 >> >> SIPit 30 will be hosted by Cisco in Raleigh-Durham, North Carolina, >> February 18-22 2013. >> >> Additional details are available at http://www.sipit.net. >> >> See you there! >> >> RjS >> > From worley@shell01.TheWorld.com Mon Feb 4 12:53: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 E347321F85DC for ; Mon, 4 Feb 2013 12:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.382, 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 9LZvMvJFFUm3 for ; Mon, 4 Feb 2013 12:53:41 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 435F821F86E6 for ; Mon, 4 Feb 2013 12:53:40 -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 r14KraEL007913 for ; Mon, 4 Feb 2013 15:53:38 -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 r14KrZch1200284 for ; Mon, 4 Feb 2013 15:53:35 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r14KrZ9j1204625; Mon, 4 Feb 2013 15:53:35 -0500 (EST) Date: Mon, 4 Feb 2013 15:53:35 -0500 (EST) Message-Id: <201302042053.r14KrZ9j1204625@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <510C4370.6020306@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> 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: Mon, 04 Feb 2013 20:53:42 -0000 My previous comments have been addressed acceptably. But there are a few new nits that I've spotted: ** General * On page 19 Alice example.com Gold Silver Agent | | | | | | INVITE F1 | | | | |------------->| | | | | | | | | | | INVITE F2 | | | | |------------->| | | | | | | | | | 302 Moved Temporarily F3 | | | |<-------------| | | | | | | | | ACK | | | |---------------------------->| | | | | | | | The ACK should be shown thus: | | | | | | | ACK | | | | |------------->| | | | | | | | * On page 27, the top ACK should be shown thus: | | | | | | | ACK | | | | |------------->| | | | | | | | * On page 31, the top ACK should be shown thus: | | | | | | | ACK | | | | |------------->| | | | | | | | * On page 40, there are two occurrences of: To: "sip:sip:" should be replaced with "sip:". ** http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html * "5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 do not show the History-Info value in the final 200 response to the UAC. This final value would be useful, in particular, because they give further examples of how proxies process History-Info." In neither of these examples is the final 200 response shown. I assume that this is the authors' intention. ** http://www.ietf.org/mail-archive/web/sipcore/current/msg05429.html * "But in draft-ietf-sipcore-rfc4244bis-callflows-01, Reason header values for 1xx responses are not generated. See message F8 in section 3.1." rfc4244bis-callflows-02 does not show Reason headers with 1xx values. I expect this is because the authors intend for this to be how History-Info operates. But that does mean we are committed to updating rfc4244bis to state that (because it currently says that 1xx responses set Reason headers). Dale From brett@broadsoft.com Sat Feb 9 11:49:31 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 1366921F861F for ; Sat, 9 Feb 2013 11:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cWZjxkCZ8be for ; Sat, 9 Feb 2013 11:49:29 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9650421F8630 for ; Sat, 9 Feb 2013 11:49:29 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 9 Feb 2013 11:50:41 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Sat, 9 Feb 2013 11:50:41 -0800 From: Brett Tate To: SIPCORE Thread-Topic: Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt Thread-Index: AQHOAMzPtSYBCoYfdUm0c80tzCmYLphx583Q Date: Sat, 9 Feb 2013 19:50:40 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88035C71@MBX06.citservers.local> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> In-Reply-To: <510C4370.6020306@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sat, 09 Feb 2013 19:49:31 -0000 Howdy, Most of my comments have been adequately addressed. Thanks, Brett ----- Concerning my various comments to include Max-Forwards, the values are good= enough for me; however I was surprised to see some of the decrementing and= initial values. For instance, section 3.1 F5 and F13 contain initial valu= es within ACK reflecting the related INVITE instead of 70. And for instanc= e, section 3.1 F6 and F9 reflect the proxy decrementing the value again for= INVITE sent to new location because of 302 or timeout. If not intentional, the figure labels are of the format "Figure 1: Figure 1= ." and not consistently located (i.e. before or after detailed messages). Section 3.2 F3: top Via received should be on the second via. Section 3.4 picture: 302 ACK arrow reflection wrong source. The same appli= es to sections 3.6 and 3.7. Concerning http://www.ietf.org/mail-archive/web/sipcore/current/msg05265.ht= ml comment 2, section 3.5 was not modified; thus I'll assume that the trans= port switch from UDP to TCP was intentional (i.e. registered UDP Contact bu= t INVITE sent over TCP). Section 3.9 F2: Added Max-Forwards to response. New comment (if want to address): figure 1 indicates a "retransmit INVITE" = with arrow after having received a 180. From marianne.mohali@orange.com Thu Feb 14 05:11: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 23EF321F868F for ; Thu, 14 Feb 2013 05:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 MkWzPCmVqBeG for ; Thu, 14 Feb 2013 05:11:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0917621F868E for ; Thu, 14 Feb 2013 05:11:37 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1DA06264366; Thu, 14 Feb 2013 14:11:37 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F07724C024; Thu, 14 Feb 2013 14:11:36 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 14:11:36 +0100 From: To: Paul Kyzivat , "R.Jesske@telekom.de" , Laura Liess , "Brett Tate" , "Dale R. Worley" Thread-Topic: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt Thread-Index: AQHOAMyZ06RJPrxNn0imU//2fV42V5h4a0gw Date: Thu, 14 Feb 2013 13:11:36 +0000 Message-ID: <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> In-Reply-To: <510C4370.6020306@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.14.121218 Cc: SIPCORE 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, 14 Feb 2013 13:11:41 -0000 Hello, Most of my comments have been perfectly addressed but I have still some con= cerns with the following changes: MM#1 =A73.6 in F3: there is an "mp" tag in a Contact header; I guess it's a= mistake and it should be a History-Info header (as in F4). MM#2 =A73.6 in F6: The History-Info header is History-Info: ;index=3D1 [MM] ok [/MM] History-Info: ;\ index=3D1.1;rc=3D1 [MM] ok [/MM] History-Info: ;index=3D1.2;mp=3D1 [MM] ok [/MM] History-Info: ;\ index=3D1.2.1;rc=3D1.2 [MM] nok, it is a cause URI= parameter that should be set to "480" (call deflection) following RFC4458.= The Reason header is escaped in the SIP URI only when it is a real receive= d respond (it is the case with the 302) [/MM] History-Info: ;\ index=3D1.3;mp=3D1 [MM] nok, The hi-entry with the= voicemail should be a copy of the R-URI so with the cause=3D480 URI parame= ter. Additionally, the vm is finally reached because Carol does not reply, = so the no reply reason (cause=3D408) should also be reflected in a cause UR= I parameter following RFC4458. Hence, the hi-entry should be History-Info: = = ; index=3D1.3;mp=3D1 =3D> Oops, I think we have a probl= em... This is due to the fact that at the same time we have successive forw= arding (1 after the other) with Carol at the second-to-last position and we= try to join B's vm (1st diverting user). IMO, we should add some text stat= ing that depending on which voicemail is reached (Bob or Carol), the call f= orwarding reason (Bob or Carol's diverting reason) in the cause URI paramet= er should be set accordingly (to be consistent). Here the target vm is Bob = so only cause=3D480 should be used and Carol's reason for not answering the= call is lost. [/MM] [MM]If someone have a better/other idea, please don't hesitate... [/MM] History-Info: ;\ index=3D1.3.1;rc=3D1.3 [MM] nok, same comment But IMO it should be: History-Info: ;index=3D1=20 History-Info: ;\=20 index=3D1.1;rc=3D1=20=20=20=20=20=20=20=20=20 History-Info: ;index=3D1.2;mp=3D1=20 History-Info: ;\ index=3D1.2.1;rc=3D1.2=20 History-Info: ;\ index=3D1.3;mp=3D1 History-Info: ;\ index=3D1.3.1;rc=3D1.3 MM#3 =A73.7 in F4 and followings:=20 In the hi-entry the reason-text has been added.=20 I have 2 comments:=20 1. why adding the reason-text? (and why not ;)=3D> ok for me=20 2. if the reason-text is added, it should be "escaped" in the same way as t= he cause parameter.=20=20 So that, the hi-entry: History-Info: \ ;index=3D1.1;rc=3D1 Should be: History-Info: \ ;index=3D1.1;rc=3D1 Here is my feedback. Best Regards, Marianne -----Message d'origine----- De=A0: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la par= t de Paul Kyzivat Envoy=E9=A0: vendredi 1 f=E9vrier 2013 23:37 =C0=A0: R.Jesske@telekom.de; Laura Liess; MOHALI Marianne OLNC/OLN; Brett T= ate; Dale R. Worley Cc=A0: SIPCORE Objet=A0: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt A new version of 4244bis-callflows has been published, to address the comme= nts we received in the WGLC review at the end of last year. I've sent this *To* the people who provided comments. I would appreciate your verifying that your comments were properly addresse= d. (Please comment back one way or the other.) This is *not* a new WGLC. So please don't bring up *new* issues now. We are= past that. I just want to verify that the comments already raised have bee= n handled. We are holding the bis to publish concurrently with the callflow= s, so is the last thing holding them up. Thanks, Paul -------- Original Message -------- Subject: [sipcore] I-D Action:=20 draft-ietf-sipcore-rfc4244bis-callflows-02.txt Date: Tue, 29 Jan 2013 12:49:12 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: sipcore@ietf.org 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 : Session Initiation Protocol (SIP) History-Info Header=20 Call Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt Pages : 46 Date : 2013-01-29 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From oferg@avaya.com Sun Feb 17 08:24:01 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 5E56421F8B0F for ; Sun, 17 Feb 2013 08:23:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJzQsClFKQfa for ; Sun, 17 Feb 2013 08:23:50 -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 2ED6321F8AC2 for ; Sun, 17 Feb 2013 08:23:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN5hHFGHCzI1/2dsb2JhbABEgkO+KxZzgiEBAQMSG14BFRVWJgEEGxqHcJ8DhCicXpEjYQOcN4pAgwaCJw X-IronPort-AV: E=Sophos;i="4.84,662,1355115600"; d="scan'208,217";a="389125983" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2013 11:22:48 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Feb 2013 11:22:56 -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; Sun, 17 Feb 2013 18:23:05 +0200 From: Ofer Goren To: "sipcore@ietf.org" Thread-Topic: question about B2B and Forking Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpw== Date: Sun, 17 Feb 2013 16:23:04 +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_D9AD3D1627F52341B829F32E6DDE089149E014C0rvilmail2010_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 17 Feb 2013 09:04:12 -0800 Subject: [sipcore] question about B2B and Forking 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: Sun, 17 Feb 2013 16:24:45 -0000 --_000_D9AD3D1627F52341B829F32E6DDE089149E014C0rvilmail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it f= orward downstream all the provisional responses to the generating UAC? Or, = should it forward only one," absorbing" the rest? Should it even wait for p= rovisional responses, or should it generates its own toward the UAC, indepe= ndent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creat= es several early dialogs for which it should also handle transactions such = as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer _______________________________________________________________ If you lend someone $20, and never see that person again, it was probably w= orth the investment. --_000_D9AD3D1627F52341B829F32E6DDE089149E014C0rvilmail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All.

I know B2B behavior is not defined with too much det= ails in the relevant SIP RFCs. I do ask for your opinion:

In forking scenarios, if B2B forks an INVITE to seve= ral UAS-es, should it forward downstream all the provisional responses to t= he generating UAC? Or, should it forward only one,” absorbing” = the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to t= he upstream side of the session?

If it should forward all provisional responses downs= tream, it in fact creates several early dialogs for which it should also ha= ndle transactions such as PRACK (in case of reliable provisional responses)= , or UPDATEs and such.

 

So what do you think a B2B should do?

 

Thanks!

Ofer

 <= /span>

 <= /span>

______________________= _________________________________________

If you lend someone $2= 0, and never see that person again, it was probably worth the investment.

 

 

--_000_D9AD3D1627F52341B829F32E6DDE089149E014C0rvilmail2010_-- From brett@broadsoft.com Sun Feb 17 09:28:31 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 55F4C21F89D2 for ; Sun, 17 Feb 2013 09:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDD5X9V5Y8X4 for ; Sun, 17 Feb 2013 09:28:30 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8A21F89CC for ; Sun, 17 Feb 2013 09:28:30 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 17 Feb 2013 09:30:14 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Sun, 17 Feb 2013 09:30:14 -0800 From: Brett Tate To: Ofer Goren , "sipcore@ietf.org" Thread-Topic: question about B2B and Forking Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpwAB6S5A Date: Sun, 17 Feb 2013 17:30:13 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B8819697E23@MBX06.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: multipart/alternative; boundary="_000_576A8B541C219D4E9CEB1DF8C19C7B8819697E23MBX06citservers_" MIME-Version: 1.0 Subject: Re: [sipcore] question about B2B and Forking 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: Sun, 17 Feb 2013 17:28:31 -0000 --_000_576A8B541C219D4E9CEB1DF8C19C7B8819697E23MBX06citservers_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ofer, The appropriate behavior depends upon the functionality that the B2BUA is p= roviding. Within normal call originations with devices compliant to RFC 3261, RFC 326= 2, and RFC 3311, it is typically best to act more like a proxy. However since there are still devices that don't support RFC 3262, RFC 3311= , or forking proxies, the B2BUA might have to act differently for interoper= ability reasons. Similarly, the B2BUA may need to act differently for serv= ice reasons. From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ofer Goren Sent: Sunday, February 17, 2013 11:23 AM To: sipcore@ietf.org Subject: [sipcore] question about B2B and Forking Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it f= orward downstream all the provisional responses to the generating UAC? Or, = should it forward only one," absorbing" the rest? Should it even wait for p= rovisional responses, or should it generates its own toward the UAC, indepe= ndent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creat= es several early dialogs for which it should also handle transactions such = as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer --_000_576A8B541C219D4E9CEB1DF8C19C7B8819697E23MBX06citservers_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ofer,

 

The appropriate behavi= or depends upon the functionality that the B2BUA is providing.

 

Within normal call ori= ginations with devices compliant to RFC 3261, RFC 3262, and RFC 3311, it is= typically best to act more like a proxy.

 

However since there ar= e still devices that don’t support RFC 3262, RFC 3311, or forking pro= xies, the B2BUA might have to act differently for interoperability reasons.=   Similarly, the B2BUA may need to act differently for service reasons.

 

 

From: sipcore-= bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren
Sent: Sunday, February 17, 2013 11:23 AM
To: sipcore@ietf.org
Subject: [sipcore] question about B2B and Forking<= /p>

 

Hi All.

I know B2B behavior is not defined with too much det= ails in the relevant SIP RFCs. I do ask for your opinion:

In forking scenarios, if B2B forks an INVITE to seve= ral UAS-es, should it forward downstream all the provisional responses to t= he generating UAC? Or, should it forward only one,” absorbing” = the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to t= he upstream side of the session?

If it should forward all provisional responses downs= tream, it in fact creates several early dialogs for which it should also ha= ndle transactions such as PRACK (in case of reliable provisional responses)= , or UPDATEs and such.

 

So what do you think a B2B should do?

 

Thanks!

Ofer

 

--_000_576A8B541C219D4E9CEB1DF8C19C7B8819697E23MBX06citservers_-- From internet-drafts@ietf.org Sun Feb 17 17:26:03 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 AC8AE21F8B60; Sun, 17 Feb 2013 17:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 e0r36dqCAsRE; Sun, 17 Feb 2013 17:26:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3621F8B48; Sun, 17 Feb 2013 17:26:02 -0800 (PST) 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.40 Message-ID: <20130218012602.25027.52663.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2013 17:26:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-07.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, 18 Feb 2013 01:26:03 -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-07.txt Pages : 21 Date : 2013-02-17 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Sun Feb 17 17:31:49 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 C022B21F8B75 for ; Sun, 17 Feb 2013 17:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 a9TCeumCofal for ; Sun, 17 Feb 2013 17:31:49 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8AC21F8B71 for ; Sun, 17 Feb 2013 17:31:48 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id j34so1875148qco.37 for ; Sun, 17 Feb 2013 17:31:48 -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:content-type:content-transfer-encoding :x-gm-message-state; bh=d9c0o2P34Dcm5FI37DjGTL86K6bGtwBfh6aiQiGvwFw=; b=Aelb0IHHGwHRdtOcrF/CvIsUWBlPHmSMNw4JtHEr8z1AbCUvx3aUg8XNJZXzxCyQyn bTyYdnQK07mhDrr1a+01vKlJhs9TofRiM4JlnqU5Bs9J77ETtbbkRS76c9qBE0qabEMp n+xHU5iazDuofkZRmGSrnt4rPe/L3znGxVDVO/X3hLekTlzwUmJy0TilGSQRhOsRRG1i o/WjzaWV7rVze3vfY6M0jPtIGSHLNvE6glwumGGZQtrp7ej0CgbbADEuy7LHB2sJZlLG z6Vcm3wiIckwQe3M7lRIIF1/+j4+17tBUIN8S6IO5SqzhqRZraJ4yTiwHn+TNOFGGrjF orWQ== X-Received: by 10.49.71.178 with SMTP id w18mr4337836qeu.11.1361151108206; Sun, 17 Feb 2013 17:31:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Sun, 17 Feb 2013 17:31:28 -0800 (PST) In-Reply-To: <20130218012602.25027.52663.idtracker@ietfa.amsl.com> References: <20130218012602.25027.52663.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 18 Feb 2013 02:31:28 +0100 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlXcQMdqjsl+ffsl4BQOAsnHdU3bTVgf01c8UbsZ9JHpoZQ+o0Clv4I+uUV1FItkpoMQFlk Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-07.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, 18 Feb 2013 01:31:49 -0000 Hi all, First of all I'm really sorry for the delay in submitting this new revision 07 of draft-ietf-sipcore-sip-websocket. This new revision of the document includes the following changes based on feedback received in the SIPCORE WG maillist: - Removed mention to RFC 4168 "SIP STCP" in section "SIP URI Transport Parameter" (thanks to Martin Vopatek). - Section 6 "Connection Keep Alive" improved and normative statements (RFC 2119) removed (thanks to Robert Sparks). - Section 7 "Authentication" fixed and improved (thanks to Robert Sparks). - Section 9.1 "Secure WebSocket Connection" (under "Security Considerations") now mentions that SIP TLS certificate checks specified in RFC 3261 or RFC 5922 don't apply when using SIP over WebSocket transport (and RFC 5922 "Domain Certificates in SIP" added to "Informative References"). - "Abstract" and "Introduction" improved by removing "new" keyword (not good for RFCs) (thanks to Robert Sparks). - ABNF in 5.2.1 and 5.2.2 (Via Transport Parameter and SIP URI Transport Parameter) improved by using =3D/ syntax (thanks to Robert Sparks and Paul Kyzivat). - RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication" removed from "References" since it is no longer mentioned in the document. Instead the document points to the RFC 3261 section describing Digest usage in SIP protocol. Thanks a lot to all and best regards. 2013/2/18 : > > 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-07.txt > Pages : 21 > Date : 2013-02-17 > > 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-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sun Feb 17 17:31:53 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 31B2121F8B7C for ; Sun, 17 Feb 2013 17:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6gGXeVmB+Zo for ; Sun, 17 Feb 2013 17:31:52 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 406AB21F8B78 for ; Sun, 17 Feb 2013 17:31:52 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so2203853qec.19 for ; Sun, 17 Feb 2013 17:31:51 -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=crqG+iBzf5yTbEYNSBdeYU5NDjywrGUd3qZUGj/f5Po=; b=eTcEPu/IJ+gYJM6ewfK9I9yqVgyTArZ+7xkfxX8qDuVGWExqcPu1GrD3aQdh8udfws ta4b/CLtzK8YVJwwW7XouBkrPWwOtURfEFjWcLQVpQMMfffnK0R48leA9xaQ3WY5loQD iTE4ZvLlzF9jL7hw/aGIJMJptFjqIrTkhO7yACpWBLgUtK+rr5Z3MhQcp5tAQKBk32E6 ES8u9ojjgt/qYKsdhVM8KqR5QnZIWLZvjBqqqorEWiJuE65s71IHtlWxlaIpTV26RlMM OG89iIjLfIdIvLjgYhwnfuBKLe2EYZFjmLPsxN9+tOSw1dUfc0NRyuLJMLtjQlH4abHz aSEQ== X-Received: by 10.224.33.140 with SMTP id h12mr4937008qad.73.1361151111745; Sun, 17 Feb 2013 17:31:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Sun, 17 Feb 2013 17:31:31 -0800 (PST) In-Reply-To: <50B5404A.20807@nostrum.com> References: <50B5404A.20807@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 18 Feb 2013 02:31:31 +0100 Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQko+ZRAfAEEP5g8KIToifNBPPl+V7cN3o5TEzSPSQ/cAuPANXBfuaoOkVsyVY09vzdAqwK5 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, 18 Feb 2013 01:31:53 -0000 Hi Robert, I've submited a new revision 07 of draft-ietf-sipcote-sip-websocket, some comments inline: 2012/11/27 Robert Sparks : > AD Review: draft-ietf-sipcore-sip-websocket-06.txt > > Summary: There are a few issues to address with a revised ID before > progressing to IETF LC > > Overall, this is a very well written, easy to read draft. Thank you for > making it this clear. > There are a couple of small problems to correct, and a few issues to > consider before moving > forward: > > * Section 6 starts with "_This section is non-normative_", but then conta= ins > normative statements. RECOMMENDED is the same as SHOULD. This is a > stronger > requirement for Ping than RFC 6455 places on websockets. If it was the > intent > to restate what RFC 6455 required, the language should be "RFC 6455 say= s > to...". > If it was the intent to make a stronger requirement, then this section > _is_ > normative. > > To avoid the appearance of placing a new normative requirement on the > implementation > of keep-alives, I suggest replacing the next to last paragraph of this > section with > "The indication and use of the CRLF NAT keep-alive mechanism defined fo= r > SIP > connection-oriented transports in RFC5626 section 3.5.1 or RFC6223 are= , > of course, > usable over the transport defined in this specification." Done in rev 07. > * Section 7 starts with "_This section is non-normative_" but then > contain normative statements. > > Section 7 could be rewritten to not use 2119, but that would take more > than > changing the words to lower case. The gist is 'the SIP and WebSocket sp= ecs > tell you these things.' > > It also currently confuses SIP Digest with HTTP Digest, and incorrectly > suggests > that SIP Digest is a SHOULD strength requirement in 3261 (it is a MUST > there). > > It would be better to say "This section describes how authentication is > acheived through the requirements in RFCs 6445, 6265, and 3261." > The MAY in paragraph 3 can be changed to "is allowed to". > The last paragraph can say > ...", authentication can be requested at the SIP protocol level. Note > that RFC3261 requires that all SIP implementations (which includes > implementations of this specification) implement Digest Authorization > (see RFC3261, Section 26.3.1)." Done in rev 07. > * The document should more explicitly call out that none of SIP TLS > certificate > checks specified in RFC3261 or RFC5922 will be made when using this > transport. > Instead, only the checks specified by RFC6455 will be made. The > certificates > that are appropriate for SIP over TLS over TCP will probably not be > appropriate > for SIP over secure websockets (it would only be coincidence if the sam= e > cert > worked - the two checks will look in different places in the certificat= e). Done in rev 07 within the "Secure WebSocket Connection" subsection under "Security Considerations" section. > * Should there be some additional discussion of what an element should do= if > someone clicks on "sip:foo.example.com;transport=3Dws" or receives that= in a > contact in a 302 or in a Refer-To: header field? To: header field? > Taken to an extreme, what's a proxy that understands sip over websocket= s > supposed to do if it gets a message containing Route header fields (thi= nk > preloaded routes) where the next route value is for a transport=3Dws ho= p > that > a connection doesn't yet exist for? Typicall WebSocket capable SIP proxies/servers won't be able to establish outgoing WS connections and, ever less, typical SIP WS clients (browsers) 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. However I expect that SIP WebSocket clients should/will implement Outbound and GRUU and 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. > * I'm ok proceeding with the IANA Considerations sections as they current= ly > stand, but I wonder if instead of what's in 10.3 and 10.4, this documen= t > should create a new registry for the transport values. That way someone > could search the registry for the strings "WS" or "WSS" and find someth= ing > meaningful. I'm ok with what you suggest, but I don't think I can start such a new registry. If you consider that the document requires a new registry please let me know how to help with it. > Nits: > > - RFCs never change. Years from now, this won't be "new". Please conside= r > removing "new" from the abstract and the Introduction. The abstract wo= uld > be stronger if you replaced "enable usage of SIP in new scenarios" wit= h > "enable usage of SIP in web-oriented deployments." Done in rev 07. > - In the introduction, you say "a [new] reliable and message boundary > transport". > Did you mean "a reliable, and message-boundary preserving, transport" = ? Done in rev 07. > - At the end of 5.2.3, s/regardless the Via/regardless of whether the Vi= a/ Fixed in rev 07. > - In A.1, to further avoid this section appearing to be normative, I > suggest > changing "Therefore the SIP WebSocket Client constructs" to "A SIP > WebSocket > client running in such an environment can construct". Done in rev 07. > - In section 6, what is the value of the sentence "A future WebSocket > protocol > extension providing a similar keep alive mechanism could also be used"= ? > This > specification says the same thing if the sentence is removed, and I > suggest > removing it. You are right. Done in rev 07. > - (no change suggested - just pointing something out for future work) > The ABNF in 5.2.1 could have used =3D/ and not have restated the other > values. > It would have been nice if 5.2.2 could have as well, but the way > transport-param > is defined in RFC3261 prevents it. It's probably better to keep the fo= rm > of 5.2.1 > and 5.2.2 the same. I've rewritten it as Paul and you suggest: transport =3D/ "WS" / "WSS" transport-param =3D/ "transport=3D" "ws" Thanks a lot for you useful feedback and improvements. Best regards. --=20 I=C3=B1aki Baz Castillo From worley@shell01.TheWorld.com Mon Feb 18 13:06:29 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 AD7EF21F8CC7 for ; Mon, 18 Feb 2013 13:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.339, 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 EXgrv8q-M5Rh for ; Mon, 18 Feb 2013 13:06:29 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D748521F8CC2 for ; Mon, 18 Feb 2013 13:06:28 -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 r1IL5unZ007266; Mon, 18 Feb 2013 16:05:58 -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 r1IL5uCa2081744; Mon, 18 Feb 2013 16:05:56 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IL5tD22082001; Mon, 18 Feb 2013 16:05:55 -0500 (EST) Date: Mon, 18 Feb 2013 16:05:55 -0500 (EST) Message-Id: <201302182105.r1IL5tD22082001@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: In-reply-to: <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> Cc: sipcore@ietf.org, R.Jesske@telekom.de, laura.liess.dt@googlemail.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: Mon, 18 Feb 2013 21:06:29 -0000 > From: > Subject: RE: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > MM#1 B'3.6 in F3: there is an "mp" tag in a Contact header; I guess > it's a mistake and it should be a History-Info header (as in F4). No, that's to show that the contact was generated by "mapping" from the URI with index 1, . This is described in 4244bis section 8. (There are a number of such Contact headers in the callflows.) > MM#2 B'3.6 in F6: The History-Info header is > History-Info: ;index=1 [MM] ok [/MM] > History-Info: ;\ > index=1.1;rc=1 [MM] ok [/MM] > History-Info: ;index=1.2;mp=1 [MM] ok [/MM] > History-Info: ;\ > index=1.2.1;rc=1.2 > [MM] nok, it is a cause URI parameter that should be set to "480" > (call deflection) following RFC4458. The Reason header is escaped in > the SIP URI only when it is a real received respond (it is the case > with the 302) [/MM] I believe the cause is supposed to be 408 (Timeout) rather than 480, and it is correct for the proxy to synthesize a 408 cause here because of 4244bis section 10.2 paragraph 2. (And many SIP systems treat timing out while waiting for a response as if they received an explicit 408 response.) This mistake of 480 for 408 is also present in the request-line of F6 and the History-Info of F7. (Confusion can easily arise because 480 (Temporarily Unavailable) is also a plausible cause for diversion to VM.) > History-Info: target=sip:bob%40example.com>;\ > index=1.3;mp=1 > [MM] nok, The hi-entry with the voicemail should be a copy of the > R-URI so with the cause=480 URI parameter. Additionally, the vm is > finally reached because Carol does not reply, so the no reply reason > (cause=408) should also be reflected in a cause URI parameter > following RFC4458. Hence, the hi-entry should be History-Info: > ; > index=1.3;mp=1 => Oops, I think we have a problem... This is due to > the fact that at the same time we have successive forwarding (1 after > the other) with Carol at the second-to-last position and we try to > join B's vm (1st diverting user). IMO, we should add some text stating > that depending on which voicemail is reached (Bob or Carol), the call > forwarding reason (Bob or Carol's diverting reason) in the cause URI > parameter should be set accordingly (to be consistent). Here the > target vm is Bob so only cause=480 should be used and Carol's reason > for not answering the call is lost. [/MM] > [MM]If someone have a better/other idea, please don't hesitate... [/MM] Beware that message F6 does not correspond to entry 1.3 but rather to entry 1.3.1, which is derived from 1.3 by internal redirection. (It might be worth adding a note in the text to warn the reader!) So it is entry 1.3.1 that must have the cause parameter, to match the request-URI. However, since the 1.3.1 request-URI has a cause parameter, it is likely that 1.3 request-URI has the same cause parameter. The messier problem is not really present. There is only one cause at this point, the implicit 408 response from Carol. And there may be complexities concerning what the diversion URI should be, but that is the proxy's problem, not a problem in designing 4244bis, and we do not have to solve it here, we only have to show the History-Info that comes from this particular proxy's decisions. > History-Info: target=sip:bob%40example.com>;\ > index=1.3.1;rc=1.3 > [MM] nok, same comment > > But IMO it should be: > > 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: target=sip:bob%40example.com;cause=480>;\ > index=1.3;mp=1 > History-Info: target=sip:bob%40example.com;cause=480>;\ > index=1.3.1;rc=1.3 > > MM#3 B'3.7 in F4 and followings: > In the hi-entry the reason-text has been added. > I have 2 comments: > 1. why adding the reason-text? (and why not ;)=> ok for me > 2. if the reason-text is added, it should be "escaped" in the same way > as the cause parameter. > So that, the hi-entry: > History-Info: ;text="Moved Temporarily">\ > ;index=1.1;rc=1 > > Should be: > History-Info: %3Btext%3D"Moved Temporarily">\ > ;index=1.1;rc=1 The header field as it stands is: History-Info: \ ;index=1.1;rc=1 but the escaping is incorrect. The Reason header would be: Reason: SIP;cause=302;text="Moved Temporarily" so the 'hname' is 'Reason' and the 'hvalue' is 'SIP;cause=302;text="Moved Temporarily"', so the URI should be There are 4 instances of this problem, in 3.7 F4, F5, F6, and F7 Dale From pkyzivat@alum.mit.edu Mon Feb 18 15:10:21 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 59E9E21E8030 for ; Mon, 18 Feb 2013 15:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 iyuuC09gc-3A for ; Mon, 18 Feb 2013 15:10:19 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id ED89B21F89B3 for ; Mon, 18 Feb 2013 15:10:12 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id 1yr31l0031swQuc57zA973; Mon, 18 Feb 2013 23:10:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 1zA81l01W3ZTu2S3bzA9UN; Mon, 18 Feb 2013 23:10:09 +0000 Message-ID: <5122B4D0.3020509@alum.mit.edu> Date: Mon, 18 Feb 2013 18:10:08 -0500 From: Paul Kyzivat 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: Robert Sparks References: <50B5404A.20807@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361229009; bh=+sQgROGSyUKIyFbW3njM78uZIROX06nEWhW0tk7Hd0I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZBVgO6xS5y+Qgv4F3i8yh6mdWi683mn8n35OY1miPRZR9tZcrIAeKSK06tnxnIId3 g6Dd7caIt4bkygZ0VodYclgIFlKeC+Nct67h6xCTWNGRJLOZk2uUSC6szrCgVQcLxZ fF6dHPwUh9HJGow7TLHxhosDGSZZ+vMKy6zn1vpeoZdquaYxeGXo5PCIj45OjST0rZ i1TeHFwU0uFDO7NdNVwinEzrCEHMcUdjVmPmWKMNn2RuTRxFT941xiEd3BtIJfuje9 neevPxzg7nsXCLU7axwO6718/ucDthaWVJPUdnlGDi9fVqX0TK9Lon4zD3l1UUpUP6 uiGenUkPZtGVA== Cc: sipcore@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, 18 Feb 2013 23:10:21 -0000 On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote: >> * I'm ok proceeding with the IANA Considerations sections as they currently >> stand, but I wonder if instead of what's in 10.3 and 10.4, this document >> should create a new registry for the transport values. That way someone >> could search the registry for the strings "WS" or "WSS" and find something >> meaningful. > > I'm ok with what you suggest, but I don't think I can start such a new > registry. If you consider that the document requires a new registry > please let me know how to help with it. We just went through this by establishing a new registry for the priority header field. But in that case, the draft that provoked the creation of the new registry was in a different WG, and we thought it weird for that draft to establish a new registry for a sip header field. In this case everything is within sipcore, so I don't see any reason why we couldn't do everything within this draft. Robert, what do you think? Paul From oferg@avaya.com Tue Feb 19 05:04:56 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 70F6821F8A89 for ; Tue, 19 Feb 2013 05:04:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZhl641TJqq4 for ; Tue, 19 Feb 2013 05:04:55 -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 5969421F8A6C for ; Tue, 19 Feb 2013 05:04:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN5hHFGHCzI1/2dsb2JhbABEgkO+KxZzgiEBAQMSG14BFRVWJgEEGxqHcJ8DhCiMa49zkSNhA5w3ikCDBoIn X-IronPort-AV: E=Sophos;i="4.84,662,1355115600"; d="scan'208,217";a="389354467" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Feb 2013 08:03:52 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Feb 2013 08:03:59 -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; Tue, 19 Feb 2013 15:02:23 +0200 From: Ofer Goren To: "sipcore@ietf.org" Thread-Topic: question about B2B and Forking Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpw== Date: Tue, 19 Feb 2013 13:02:23 +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_D9AD3D1627F52341B829F32E6DDE089149E03318rvilmail2010_" MIME-Version: 1.0 Subject: [sipcore] question about B2B and Forking 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 Feb 2013 13:04:56 -0000 --_000_D9AD3D1627F52341B829F32E6DDE089149E03318rvilmail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it f= orward downstream all the provisional responses to the generating UAC? Or, = should it forward only one," absorbing" the rest? Should it even wait for p= rovisional responses, or should it generates its own toward the UAC, indepe= ndent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creat= es several early dialogs for which it should also handle transactions such = as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer _______________________________________________________________ If you lend someone $20, and never see that person again, it was probably w= orth the investment. --_000_D9AD3D1627F52341B829F32E6DDE089149E03318rvilmail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All.

I know B2B behavior is not defined with too much det= ails in the relevant SIP RFCs. I do ask for your opinion:

In forking scenarios, if B2B forks an INVITE to seve= ral UAS-es, should it forward downstream all the provisional responses to t= he generating UAC? Or, should it forward only one,” absorbing” = the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to t= he upstream side of the session?

If it should forward all provisional responses downs= tream, it in fact creates several early dialogs for which it should also ha= ndle transactions such as PRACK (in case of reliable provisional responses)= , or UPDATEs and such.

 

So what do you think a B2B should do?

 

Thanks!

Ofer

 <= /span>

 <= /span>

______________________= _________________________________________

If you lend someone $2= 0, and never see that person again, it was probably worth the investment.

 

 

--_000_D9AD3D1627F52341B829F32E6DDE089149E03318rvilmail2010_-- From radhika.r.roy.civ@mail.mil Tue Feb 19 07:17: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 7308121F880F for ; Tue, 19 Feb 2013 07:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXnteK7EjQQ6 for ; Tue, 19 Feb 2013 07:17:59 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id B462221F8790 for ; Tue, 19 Feb 2013 07:17:58 -0800 (PST) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 19 Feb 2013 15:17:46 +0000 Received: from UCOLHP9L.easf.csd.disa.mil ([169.254.2.27]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.02.0309.003; Tue, 19 Feb 2013 15:17:46 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Ofer Goren Thread-Topic: question about B2B and Forking (UNCLASSIFIED) Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpwBiXDCw Date: Tue, 19 Feb 2013 15:17:46 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF490A18E1@ucolhp9l.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01CE0E8A.5B0E42A0" MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] question about B2B and Forking (UNCLASSIFIED) 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 Feb 2013 15:17:59 -0000 ------=_NextPart_000_0029_01CE0E8A.5B0E42A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Ofer: In this case it not B2BUA spec per se. It will be rather specific to "Forking Specifications using B2BUA." If we want to have a interoperable implementation of forking using B2BUA. Is it really needed? BR/Radhika -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren Sent: Tuesday, February 19, 2013 8:02 AM To: sipcore@ietf.org Subject: [sipcore] question about B2B and Forking Hi All. I know B2B behavior is not defined with too much details in the relevant SIP RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it forward downstream all the provisional responses to the generating UAC? Or, should it forward only one," absorbing" the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creates several early dialogs for which it should also handle transactions such as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer _______________________________________________________________ If you lend someone $20, and never see that person again, it was probably worth the investment. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0029_01CE0E8A.5B0E42A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzAyMTkxNTE3NDNaMCMGCSqGSIb3DQEJBDEWBBTSqtRa+fcgc9Atf5TBJYEV TtVinDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAG8ze4MhFmwY6koaLQThqYoUI098HQvUp2sKDhsfz9zOAYIfj/CJsJbQ7HHd/YYLpgPF zfHUZE89cBxq6TuABAfP7NX/0hOTQk5bom3hhsqlmS4fgCsbNuQJ8Q7MiJ0Ie3gC6F16ancItR6U kedQZ4AlGratzQtU6VdtwoAx++Xopv/6/3Um2+BdwE+xR7IkfPyJwTzyx/vZaOspZ076lB2A+8Hy hxUCixsBTlAcyjQ1dgc9zw1wmceqGwsuQhyJKkJQJ4Ou86B6+A6INcR3aOdae6dHp6PU+f3tMOqg q/xwBftKfPPrX9VyXyXRksyDLVi8ySfWV9qM1zyGjmUd/mAAAAAAAAA= ------=_NextPart_000_0029_01CE0E8A.5B0E42A0-- From mary.ietf.barnes@gmail.com Tue Feb 19 08:17:00 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 05BAB21F8DD7 for ; Tue, 19 Feb 2013 08:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 uWrMwedIPMDW for ; Tue, 19 Feb 2013 08:16:55 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7F121F8DBB for ; Tue, 19 Feb 2013 08:16:55 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so2601107qcm.39 for ; Tue, 19 Feb 2013 08:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aVTMzfCPa3h/0IGu7B883rF/WVT6Z6ST7y2SDnnAe80=; b=NC+XUpGAP2A321ljf0lmXAmean2y7Zy7KLe2RzFfIEO7QVxoyTzwbf1mdtdqaAKeDW IRYZu3DCHaL7loUQGU03/BnEc12fOrJTGOsPzhMWtXujOmrbKPr7b4prpkk7ASbHAmxA 375CaHEUANKWhFc+Vzy8Nd49c7q5wjwGVXllIhNvEMpX2F25C6qhuXLJLAdYUkE/rVh6 dAKISaWp+lClscr2/sFU1LZr9hj1wA6vDVAqZcfraf5cFz6nBxzW5/E2d87qWVFQ7BjX 13JJKBrhHrOGExuVLaM4QiWoJ5RJK+i5rc7c5v1F/J1HwDMxdm6LHg+vHF5gK28Dh4hF a1mA== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr6900053qac.63.1361290614610; Tue, 19 Feb 2013 08:16:54 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 19 Feb 2013 08:16:54 -0800 (PST) In-Reply-To: References: <201302061509.r16F90sh016532@freeze.ariadne.com> Date: Tue, 19 Feb 2013 10:16:54 -0600 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: text/plain; charset=ISO-8859-1 Cc: SIPCORE Subject: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. 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 Feb 2013 16:17:00 -0000 Hi all, This is a set of suggested changes from Dale based upon the comments he sent to the list previously: http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html Responses are inline below [MB]. Based upon my responses, I do not believe any of the changes impact normative behavior (as intended) thus another WG and/or IETF LC should not be necessary, but I will leave that decision to the chairs/AD. Mary. ---------- Forwarded message ---------- From: Dale R. Worley Date: Wed, Feb 6, 2013 at 9:09 AM Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. To: mary.h.barnes@gmail.com, pkyzivat@alum.mit.edu Here are my proposed fixes to the -11 version. I believe that all of these changes are non-controverisial, in that they adjust the document to express what we all agree it ought to mean. But in a number of places, the prescribed procedures are actually different from the current text. Please review this and get back to us with your thoughts. Thanks, Dale ====================================================================== Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. This document is organized as a series of responses to the points in my e-mail of 18 Jan (http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html). ========== > From: worley@ariadne.com (Dale R. Worley) > To: SIPCORE > Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt > Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST) > > I've got a few questions about 4244bis. I think that there are > understood answers to most of them, but we might have to update the > wording to remove ambiguity. ========== > 1. When an entity receives a (non-100) provisional response to a > request, should it modify the hi-entry by adding a Reason value > carrying the status of the response? The current text (section 10.2) > clearly requires it. If the request eventually receives a failure > response, the 1xx Reason will (probably) later be replaced by the > failure code. (But not necessarily: see section 10.2 paragraph 3.) > > The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this > situation is section 3.1 message F8, and the 180 status is not > reported in a Reason header-value for (which > thus contradicts section 10.2). > > The alternative is that 1xx responses do not set the Reason value > (although they do add to the cache any new hi-entries they carry). > This would require changing the text in section 9.3 step 2 and section > 10.2. NOTE: I am assuming that non-100 provisional responses are intended to carry hi-entries upstream, and that proxies that see those responses are intended to cache the hi-entries carried in them. (Those cached hi-entries can later be updated by a final response which adds a Reason header value to them.) If this is not so, these changes need to be revised. As far as I can tell, we have never intended for receipt of a provisional (1xx) response to an INVITE to set a Reason header on the corresponding cached hi-entry. The only example in 4244bis-callflows of this situation is message F6 of section 3.1, in which there would be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not. And RFC 4244, which also has the Reason header value mechanism, does not specify that 1xx responses set Reason header values. So I propose that we all agree that 1xx responses should not generate Reason headers and we edit the text accordingly. [MB] Correct. That's been the intent for both 4244 and 4244bis. It's mentioned in 9.4 that the HI is not sent in 100 responses (since those do not result in retargeting), thus there would be no reason to add a Reason header to anything. [/MB] The changes are: section 9.3 step 2 Step 2: Add Reason header field The SIP entity adds one or more Reason header fields to the hi- ------^ change "The" to "If the response code is not 1xx, the" targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 response, per the procedures of ---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete(?) Section 10.2. This change results in: If the response code is not 1xx, the SIP entity adds one or more Reason header fields to the hi-targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response, per the procedures of Section 10.2. [MB] Note that the section is specific to non-100 responses, which is why it is written as it currently is. I don't see that your suggested text adds any more information - i.e., the IF isn't necessary. We are stating specific behavior for that specific step and an "IF" isn't necessary. I do not think this change is necessary. [/MB] 10.2. Reason in the History-Info Header Field A Reason header field is added to the "headers" component in an hi- targeted-to-uri when the hi-entry is added to the cache based upon the receipt of a non-100 or non-2xx SIP response, as described in Section 9.3. If the Reason header field is being added due to receipt of an explicit SIP response and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. If the SIP response does not contain a Reason header field, the SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. The changes to this paragraph are extensive enough that I am not showing the individual differences. Note I have changed "the last hi-entry added to the cache" to "the corresponding hi-entry". The latter makes more sense to me, and specifies the same hi-entry. But others may prefer the current description, in which case we can retain it. The new version of this paragraph is: A Reason header field is added to the "headers" component in an hi- targeted-to-uri when a non-100, non-2xx SIP response is received to the corresponding INVITE, or when a response is received containing the hi-entry with a Reason header value, as described in Section 9.3. [MB] You have dropped the reference to the cache here and that very important. I think it's obvious that we are dealing with the corresponding INVITE. When we talk about SIP responses, we do not qualify it as "the SIP response received to the corresponding INVITE". But, it certainly causes no harm. I would suggest that sentence read: A Reason header field is added to the "headers" component in an hi- targeted-to-uri when the hi-entry is added to the cache based upon the receipt of a non-100 or non-2xx SIP response to the corresponding INVITE, as described in Section 9.3. [/MB] If the Reason header value is being added to an hi-targeted-to-uri due to receipt of an explicit SIP response to the corresponding INVITE and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST also include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the corresponding cached hi-entry, unless the hi-targeted-to-uri is a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Tel-URI. If the SIP response does not contain a Reason header field with a protocol of "SIP", the SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the corresponding cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI. [MB] Note, you dropped "field" from the "Reason header value above, which is not correct. So the real changes I see above are with regards to highlighting that it's the corresponding cached hi-entry (rather than the last. I have annotated above that that is the only change (AFAICT). I can make that change as follows: OLD: If the Reason header field is being added due to receipt of an explicit SIP response and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. NEW: If the Reason header field is being added due to receipt of an explicit SIP response to the corresponding INVITE ^^^^^^^^^^^^^^^^^^^^^^ and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the corresponding cached hi-entry, unless ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the hi-targeted-to-uri is a Tel-URI. [/MB] There is a slight change here in that if the response contains "Reason: Q.850;cause=14", then both the Q.850 response code and the SIP response code will be recorded in the cached hi-entry. The previous text caused only the Q.850 response code to be recorded. [MB] I don't see that the previous text said that only the Q.850 response code was recorded. The text says that "Reason header fields" as in plural fields are added. [/MB] If a Reason header includes a reason-value with protocol "SIP", that reason-value is recorded instead of the response code in the response. (This is the same as the previous text.) ========== > 2. During the life of the document, there was confusion about how > hi-entries were to be organized. The intention of the original writer > and the current draft is that hi-entries are accumulated in a cache in > the order the entity receives them (in requests and responses), > allowing hi-entries that have the *same* index but *different* URIs, > and (implicitly) eliminating duplicates. [MB] It wasn't just the original author and the current author, this has been the intent of the document and the approach was agreed by the WG. Certainly, there were some errors that might have lead one to believe otherwise, but that was never the intent. [/MB] > > But some people who have worked on the draft (including myself) were > for a while mistaken in believing that the hi-entries were to be > organized into a tree, and hence the index values needed to be unique, > and the History-Info header would list the hi-entries in tree-walking > order (technically, "preorder"). The confusion was abetted by there > being no examples that distinguish the two techniques. [MB] I think the confusion is that if everyone supported HI, you would get a tree. You can still get a somewhat pruned tree using the indices. I think the confusion is that the RFC never had any intention of defining application behavior. It is merely recording what happens at the SIP protocol level. That's it. How an application uses the information (whether to build a tree or whatever) is out of scope. [/MB] > Unfortunately, the -11 draft doesn't eliminate all the remnants of the > mistake. I haven't gone through -11 in detail, but "preorder" appears > in section 9.2 and section 10.3, so at least those sections describe > the accumulation of hi-entries incorrectly. The fix to this issue overlaps the fix for issue #4: > 4. If a downstream entity that does not support History-Info forks a > request to entities that do support History-Info, an entity can > receive two hi-entries with the same index that were not generated for > the same fork of the request. Conversely, an entity will receive > responses that contain hi-entries that are duplicates of entries that > are already in the cache. > > These facts imply that there is a process by which an entity > determines whether a received hi-entry is "the same" as an hi-entry > already in the cache (and so doesn't need to be added again). Since > index values cannot be depended upon to be unique, we really ought to > state what the comparison rule is. > > I think it is sufficient to use the rule "the same index value and the > URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the > Reason header fields)". This won't always give the result one would > want (if a non-supporting downstream element forks the request to two > target URIs that ultimately arrive at the same element, two hi-entries > could be generated with the same index and URI), but this rule is > simple, well-defined, and should work well in almost all situations. In addition, when a response is received, it may contain hi-entries that are duplicates of hi-entries already in the cache, except they contain Reason header values that are not in the cached hi-entries. I believe we intend that the cached hi-entries be updated to include the received Reason header values. The edits to fix these three issues are: 9.2. Sending a Request with History-Info When sending a request, a SIP entity MUST include all the hi-entries from the cache that was created per Section 9.1. In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the cache at this time. The --------------------------------------------------------------------^ Change this sentence to: "The hi-entries in the outgoing request's History-Info header are in the order of the hi-entries in the cache, which is the order in which they were added to the cache." [MB] That's fine. And, just for clarification, the statement below is the OLD and the one above is the NEW [/MB] hi-entries in the outgoing request's History-Info header field is the preorder of the tree of hi-entries, that is, by the lexicographic ordering of the hi-indexes. The new hi-entry is populated as follows: 9.3. Receiving a Response with History-Info or Request Timeouts Step 1: Add hi-entry to cache The SIP entity MUST add the hi-entry that was added to the request -----------------------------^ For clarity insert "to the cache" here, and... that received the non-100 response or timed out to the cache, if ------------------------------------------------------^^^^^^^^^^^^ ... remove "to the cache" here. it was not already cached. The hi-entry MUST be added to the ----------------------------------^ Change this sentence to "If so, the hi-entry MUST be added to the end of the cache." cache in ascending order as indicated by the values in the hi- index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3). [MB] I can't decipher the changes you are suggesting above. I think I see your point. However, there is something very subtle here. This is dealing with responses and we add the hi-entries once we get the response. However, the value of the hi-index actually does reflect a chronological order in terms of generating requests. As discussed previously, you lose that chronological ordering across entities, but for a specific SIP entity they do reflect the chronological processing at that entity. So, I don't think this is broken. With the cache model, we aren't adding them to the cache until we get the response even though they were added to the request (in both chronological and lexicographical order). [/MB] 9.3. Receiving a Response with History-Info or Request Timeouts Step 3: Add additional hi-entries The SIP entity MUST also add to the cache any hi-entries received in the response that are not already in the cache. This situation can occur when the entity that generated the non-100 response retargeted the request before generating the response. As per Step 1, the hi-entries MUST be added to the cache in ascending order as indicated by the values in the hi-index parameters of the hi-entries This paragraph needs more extensive changes: [MB] It's not clear to me why you think it needs to be done this way. This is still mapping back to the original request sent by a specific entity (e.g., Proxy A). I think you are confused by the scenario being described. The retargeting was not done by Proxy A that is caching the hi-entries. It was done by Proxy B that received the request and it retargeted before returning the 1xx response thus there is an additional hi-entry that Proxy A should add to its cache. [/MB] Step 3: Add and update additional hi-entries The SIP entity MUST also add to the cache any hi-entries received in the response that are not already in the cache. This can occur when the entity that generated the non-100 response retargeted the request before generating the response. Such hi-entries MUST be added to the end of the cache in the order they appear in the History-Info header field of the response. If an hi-entry in the response contains Reason header value(s) and the matching hi-entry in the cache does not, the Reason header value(s) MUST be added to the cached hi-entry. This can occur when the hi-entry was added to the cache by a provisional response to an INVITE that was further retargeted, and later a final response to that INVITE is received. In these cases, an hi-entry in a response's History-Info header field and an hi-entry in the cache are considered matching when they have the same index value and the hi-targeted-to-uris are equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason header fields). 10.2. Reason in the History-Info Header Field A Reason header field is added to the "headers" component in an hi- targeted-to-uri when the hi-entry is added to the cache based upon ----------------------------------------^^^^^^^^ change to "added to, or updated within," the receipt of a non-100 or non-2xx SIP response, as described in Section 9.3. [...] [MB] Why "updated within"? [/MB] 10.3. Indexing in the History-Info Header Field In order to maintain ordering and accurately reflect the retargeting of the request, the SIP entity MUST add a hi-index to each hi-entry. Per the syntax in Section 5, the hi-index consists of a series of nonnegative integer separated by dots (e.g., 1.1.2). Each dot reflects a SIP forwarding hop. The nonnegative integer following each dot reflects the order in which a request was retargeted at the hop. The highest nonnegative integer at each hop reflects the number of entities to which the request has been retargeted at the specific hop (i.e., the number of branches) at the time that the request represented by this hi-entry was generated. Thus, the indexing results in a logical tree representation for the history of the request and the hi-entries are given in the preorder of the tree. -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete this clause [MB] Okay. [/MB] ========== > 3. Due to the confusion discussed in #2, we have to consider whether > consensus was actually found in the WGLC. [MB] We had consensus in WGLC. Your comments came well after WG last call and after IETF LC. >We thought we had > consensus, but people did not have the same understanding of this > aspect of the draft. (Ugh.) This is a procedural issue, not a technical one. I don't see any objection to correcting the normative text if everyone who cares agrees that the changes express what we intended. (We should check this point with the AD.) [MB] I do not see that we are changing any of the intended normative behavior but rather fixing things that didn't quite reflect the normative behavior as stated elsewhere (i.e., inconsistencies). [/MB] ========== > 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 > do not show the History-Info value in the final 200 response to the > UAC. This final value would be useful, in particular, because they > give further examples of how proxies process History-Info. I was mistaken here: The final 200 response from the example.com proxy to the UAC in these examples has the same History-Info as the 200 response arriving at the example.com proxy, because there is no History-Info information that the proxy knows that is not known to the UAS that generated the 200 response. Thus there is nothing interesting to document. ========== > 6. Interestingly, despite the fact that there can be duplicate index > values, when a request is received by a UAS, there is no ambiguity in > the history when tracing *back* from the last hi-entry (the one that > denotes the UAS). This is because even if this UAS is "down one fork" > from a forking non-supporting proxy, none of the hi-entries generated > "down the other fork" will be present in the request the UAS sees. > > This is in contrast to the situation at the UAC, which may see > hi-entries with duplicate indexes, and the interpretation of "rc", > "mp", and "np" parameters can be ambiguous. This is an interesting observation, but it does not require documentation in the RFCs. ========== > 7. In example 3.6 message F6 in > draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is: > > 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: target=sip:bob%40example.com;cause=408>;\ > index=1.3;mp=1.2 > History-Info: target=sip:bob%40example.com;cause=408>;\ > index=1.3.1;rc=1.3 > > This is what we intend, as it shows both where the index=1.3 URI came > from (sip:bob@example.com) as well as why the index=1.3 fork was > generated (because sip:carol@example.com failed). But it points out > that we need to improve the description in rfc4244bis section 5 of > what the values of the "rc" (etc.) parameters are. A naive reader > might think "rc=1.2" in the 1.3 entry means that > was > generated as a contact for . Instead, it means > that the 1.3 fork was generated *because* the 1.2 fork returned a > response; it was generated *from* the index=1 URI. > > Actually, the real rules for interpreting "rc" (etc.) are not simple: [MB] The above is an example, thus the description is not complete. [/MB] > > 1) If the index-val in the param points to an entry with a Reason > header-param whose value is "SIP;cause=3xx" (after removing > escaping!), then: > - the URI was one of the Contact values in the 3xx response > - that response was why the new fork was generated. > > 2) If the index-val in the param points to the parent of this > hi-entry, then: > - the URI was generated from the URI of the parent hi-entry > - the fork was not generated due to the response from any other fork. > > 3) If the index-val in the param points to an hi-entry that is not the > parent, and that hi-entry does not contain a Reason header-param > containing a 3xx status, then: > - the URI was generated from the URI of the parent hi-entry > - the fork was generated due to the response from the hi-entry with > the specified index-val. > > And this doesn't match the section 5 definition of the value of "rc" > (etc.), which is: > > The "rc" header field parameter contains the value of the > hi-index in the hi-entry with an hi-targeted-to-uri that > reflects the Request-URI that was retargeted In section 5, these paragraphs need to be revised: o hi-target-param: An optional parameter reflecting the mechanism by which the Request URI captured in the hi-targeted-to-uri in the History-Info header field value (hi-entry) was determined. This parameter is either an "rc", "mp" or "np" header field parameter, which is interpreted as follows: "rc": The hi-targeted-to-URI represents a change in Request-URI while the target user remains the same. This occurs for example when user has multiple AoRs as an alias. The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted "mp": The hi-targeted-to-URI represents a user other than the target user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user represented by an AoR unassociated with the AoR of the original target user. The "mp" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to- uri that reflects the Request-URI that was retargeted, thus identifying the "mapped from" target. "np": The hi-targeted-to-URI represents that there was no change in Request-URI. This would apply for example when a proxy merely forwards a request to a next hop proxy and loose routing is used. The "np" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to- uri that reflects the Request-URI that was copied unchanged into the request represented by this hi-entry. That value will usually be the hi-index of the parent hi-entry of this hi- entry. The revised paragraphs are: [MB] I don't agree with this proposal - that's way too much detail for this section. I believe that the normative sections describe how/when you add the "rc" tag which should match what you are describing in your new bullets. I will note that this section has been updated several times both adding more text and reducing the text in this section. What you have proposed for the bullets below (i.e., the "rc", "mp" etc.) is some of the level of detail we had previously (in the -02). I believe the text you suggest is application logic - note that items 2 & 4 describe the "rc" scenarios and this wasn't intended to be comprehensive. If you can highlight what's missing in those 2 bullets, we can perhaps make some changes there. I will note if these suggestions had been made much earlier in the process, it would have been much more helpful - much of the text you mention has been in the document since around the -02. We did several rounds of major edits while developing this document both while it was an individual and as a WG document. Note that this document became a WG document literally 3 years ago. It's quite disruptive to be raising this issues at this stage. [/MB] [This first paragraph is unchanged:] o hi-target-param: An optional parameter reflecting the mechanism by which the Request URI captured in the hi-targeted-to-uri in the History-Info header field value (hi-entry) was determined. This parameter is either an "rc", "mp" or "np" header field parameter, which is interpreted as follows: "rc": The hi-targeted-to-URI represents a change in Request-URI while the target user remains the same. This occurs for example when user has multiple AoRs as an alias or when forwarding the request to a registered contact of an AoR. "mp": The hi-targeted-to-URI represents a user other than the target user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user represented by an AoR unassociated with the AoR of the original target user. "np": The hi-targeted-to-URI represents that there was no change in Request-URI. This would apply for example when a proxy merely forwards a request to a next hop proxy and loose routing is used. The "np" header field parameter contains the value of the hi-index in the parent hi-entry of this hi-entry. If the index-val in the parameter points to the parent hi-entry of this hi-entry, then: - the URI was generated from the URI of the parent hi-entry - the fork was not generated due to the response from any other fork. If the index-val in the parameter points to an hi-entry with a Reason header value whose protocol is "SIP" and whose cause begins with "3", then: - the URI was one of the Contact values in the 3xx response - the fork was generated due to the 3xx response from the hi-entry with the specified index-val. If the index-val in the param points to an hi-entry that is not the parent, and that hi-entry does not contain a Reason header value containing a SIP 3xx cause, then: - the URI was generated from the URI of the parent hi-entry - the fork was generated due to the response from the hi-entry with the specified index-val. ====================================================================== I believe that is everything to be done. Dale From pkyzivat@alum.mit.edu Tue Feb 19 08:23: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 297ED21F8E04 for ; Tue, 19 Feb 2013 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 kbORIrMCJ205 for ; Tue, 19 Feb 2013 08:23:41 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA121F8E00 for ; Tue, 19 Feb 2013 08:23:41 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2BnC1l0040ldTLk53GPgDb; Tue, 19 Feb 2013 16:23:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 2GPg1l0083ZTu2S3QGPgSh; Tue, 19 Feb 2013 16:23:40 +0000 Message-ID: <5123A70C.9020208@alum.mit.edu> Date: Tue, 19 Feb 2013 11:23:40 -0500 From: Paul Kyzivat 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: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361291020; bh=nVQsSzrXqOMhUjBzIYn9paRbYZJa2RseBxoUO4UTXaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N65Ouv7ZBNmRYUfJj8gCy9HH/XDQdoF3kdJ0F9cwgZKw/plDN9JzAHdSuLpOUDvKE SSMcNo71Cm9bRL9JRnJs/F8kN35UCZS/Ld8uaG0Xk4GtpNc93ayCT2PyWoR30xeHEz Bftv6ZuvaK/Qj7HIKhfYbX2fBFn6c/p6agqFLJ0TlEX+9ckNF8jrypz2eQ85DF4v54 aDl6giTqnoojC0Bz/5adBzWtcmlotBykQFlDejLK+q1Z4yYLNVXdvaTBhDt5Ah8l/N 8pjTYe041Dc/54GKrRFeGk38iwOiJ4XmOC6gwf93bHSWoaKrK9y+yrWpqM1Lk+B5Y2 6Rq+wIwPMJ2Lg== Subject: Re: [sipcore] question about B2B and Forking 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 Feb 2013 16:23:42 -0000 On 2/19/13 8:02 AM, Ofer Goren wrote: > Hi All. > > I know B2B behavior is not defined with too much details in the relevant > SIP RFCs. I do ask for your opinion: > > In forking scenarios, if B2B forks an INVITE to several UAS-es, should > it forward downstream all the provisional responses to the generating > UAC? Or, should it forward only one,” absorbing” the rest? Should it > even wait for provisional responses, or should it generates its own > toward the UAC, independent to the upstream side of the session? > > If it should forward all provisional responses downstream, it in fact > creates several early dialogs for which it should also handle > transactions such as PRACK (in case of reliable provisional responses), > or UPDATEs and such. > > So what do you think a B2B should do? These are all design decisions for you when building your B2BUA. The answers depend upon your goals/objectives. Good Luck, Paul From pkyzivat@alum.mit.edu Tue Feb 19 08:50:20 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 6DF3621F8CD3 for ; Tue, 19 Feb 2013 08:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 I-Cpiumq5RFA for ; Tue, 19 Feb 2013 08:50:18 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id DF1F921F853C for ; Tue, 19 Feb 2013 08:50:12 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2BW31l0070cZkys53GqCyG; Tue, 19 Feb 2013 16:50:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 2GqC1l0013ZTu2S3WGqCjk; Tue, 19 Feb 2013 16:50:12 +0000 Message-ID: <5123AD43.2080400@alum.mit.edu> Date: Tue, 19 Feb 2013 11:50:11 -0500 From: Paul Kyzivat 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: <201302061509.r16F90sh016532@freeze.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361292612; bh=ZNzHr51eYFXbw3FPvmDtGj7AFEI5J9PODV7wOApPErg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KKoknV38of+hBjF8I+CtGluo1JwmQnUbcrEp5rLZn6h0pLbE5+PrWRI8DsoCy0BiO N3LM3k15LyuW056PAJRdfqFq30NSFyBcX3MmUsWW3I8M0V0pKCp/Iqbo4tvyak/+fV eU8w+ZDtFciU9IJNF8AY3FXBU5ahQGAtM1AppICU244voQDXxgsncQgpWCR3VCqp97 WkitzMX6x8PQJHrd9n1lfiAtxA7coCb25yUa7soqq/QrcAWoCmaNgeXoPEQjgpy5lw h/CRfRQY/77V/K+Vflg9VAFEezSuIAOSOa2evxcH1XQwoRdDTrqsMr3v45Gfg6EeGr NANzsJ91UWrRQ== Subject: Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. 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 Feb 2013 16:50:20 -0000 Mary & Dale, This is very hard to follow. But I do get it that the two of you are getting closer but still not in total agreement. Can the two of you reach a mutually satisfactory conclusion? I'd love to have a new version with a direct diff to evaluate it all. I must say that I am surprised that so much effort was put into the hierarchical numbering scheme for entries and yet the conclusion is that the entries are not sorted in accord with this hierarchy. (Or did I get that wrong?) Thanks, Paul On 2/19/13 11:16 AM, Mary Barnes wrote: > Hi all, > > This is a set of suggested changes from Dale based upon the comments > he sent to the list previously: > http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html > > Responses are inline below [MB]. Based upon my responses, I do not > believe any of the changes impact normative behavior (as intended) > thus another WG and/or IETF LC should not be necessary, but I will > leave that decision to the chairs/AD. > > Mary. > > > ---------- Forwarded message ---------- > From: Dale R. Worley > Date: Wed, Feb 6, 2013 at 9:09 AM > Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. > To: mary.h.barnes@gmail.com, pkyzivat@alum.mit.edu > > > Here are my proposed fixes to the -11 version. I believe that all of > these changes are non-controverisial, in that they adjust the document > to express what we all agree it ought to mean. But in a number of > places, the prescribed procedures are actually different from the > current text. Please review this and get back to us with your > thoughts. > > Thanks, > > Dale > > ====================================================================== > > Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. > > This document is organized as a series of responses to the points in > my e-mail of 18 Jan > (http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html). > > ========== > >> From: worley@ariadne.com (Dale R. Worley) >> To: SIPCORE >> Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt >> Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST) >> >> I've got a few questions about 4244bis. I think that there are >> understood answers to most of them, but we might have to update the >> wording to remove ambiguity. > > ========== > >> 1. When an entity receives a (non-100) provisional response to a >> request, should it modify the hi-entry by adding a Reason value >> carrying the status of the response? The current text (section 10.2) >> clearly requires it. If the request eventually receives a failure >> response, the 1xx Reason will (probably) later be replaced by the >> failure code. (But not necessarily: see section 10.2 paragraph 3.) >> >> The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this >> situation is section 3.1 message F8, and the 180 status is not >> reported in a Reason header-value for (which >> thus contradicts section 10.2). >> >> The alternative is that 1xx responses do not set the Reason value >> (although they do add to the cache any new hi-entries they carry). >> This would require changing the text in section 9.3 step 2 and section >> 10.2. > > NOTE: I am assuming that non-100 provisional responses are intended > to carry hi-entries upstream, and that proxies that see those > responses are intended to cache the hi-entries carried in them. > (Those cached hi-entries can later be updated by a final response > which adds a Reason header value to them.) If this is not so, these > changes need to be revised. > > As far as I can tell, we have never intended for receipt of a > provisional (1xx) response to an INVITE to set a Reason header on the > corresponding cached hi-entry. The only example in 4244bis-callflows > of this situation is message F6 of section 3.1, in which there would > be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not. > And RFC 4244, which also has the Reason header value mechanism, does > not specify that 1xx responses set Reason header values. > > So I propose that we all agree that 1xx responses should not generate > Reason headers and we edit the text accordingly. > [MB] Correct. That's been the intent for both 4244 and 4244bis. > It's mentioned in 9.4 that the HI is not sent in 100 responses (since > those do not result in retargeting), thus there would be no reason to > add a Reason header to anything. [/MB] > > The changes are: > > section 9.3 step 2 > > Step 2: Add Reason header field > > The SIP entity adds one or more Reason header fields to the hi- > ------^ > change "The" to "If the response code is not 1xx, the" > targeted-to-uri in the (newly) cached hi-entry reflecting the SIP > response code in the non-100 response, per the procedures of > ---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > delete(?) > Section 10.2. > > This change results in: > > If the response code is not 1xx, the SIP entity adds one or more > Reason header fields to the hi-targeted-to-uri in the (newly) > cached hi-entry reflecting the SIP response, per the procedures > of Section 10.2. > > [MB] Note that the section is specific to non-100 responses, which is > why it is written as it currently is. > I don't see that your suggested text adds any more information - i.e., > the IF isn't necessary. We are stating specific behavior for that > specific step and an "IF" isn't necessary. I do not think this change > is necessary. [/MB] > > 10.2. Reason in the History-Info Header Field > > A Reason header field is added to the "headers" component in an hi- > targeted-to-uri when the hi-entry is added to the cache based upon > the receipt of a non-100 or non-2xx SIP response, as described in > Section 9.3. If the Reason header field is being added due to > receipt of an explicit SIP response and the response contains any > Reason header fields (see [RFC3326]), then the SIP entity MUST > include the Reason header fields in the "headers" component of the > hi-targeted-to-uri in the last hi-entry added to the cache, unless > the hi-targeted-to-uri is a Tel-URI. If the SIP response does not > contain a Reason header field, the SIP entity MUST include a Reason > header field, containing the SIP Response Code, in the "headers" > component of the hi-targeted-to-uri in the last hi-entry added to the > cache, unless the hi-targeted-to-uri is a Tel-URI. > > The changes to this paragraph are extensive enough that I am not > showing the individual differences. Note I have changed "the last > hi-entry added to the cache" to "the corresponding hi-entry". The > latter makes more sense to me, and specifies the same hi-entry. But > others may prefer the current description, in which case we can retain > it. > > The new version of this paragraph is: > > A Reason header field is added to the "headers" component in an hi- > targeted-to-uri when a non-100, non-2xx SIP response is received to > the corresponding INVITE, or when a response is received containing > the hi-entry with a Reason header value, as described in Section > 9.3. > [MB] You have dropped the reference to the cache here and that very > important. I think it's obvious that we > are dealing with the corresponding INVITE. When we talk about SIP > responses, we do not qualify it as "the SIP response received to the > corresponding INVITE". But, it certainly causes no harm. I would > suggest that sentence read: > A Reason header field is added to the "headers" component in an hi- > targeted-to-uri when the hi-entry is added to the cache based upon > the receipt of a non-100 or non-2xx SIP response to the > corresponding INVITE, as described in > Section 9.3. > > [/MB] > > If the Reason header value is being added to an hi-targeted-to-uri > due to receipt of an explicit SIP response to the corresponding > INVITE and the response contains any Reason header fields (see > [RFC3326]), then the SIP entity MUST also include the Reason header > fields in the "headers" component of the hi-targeted-to-uri in the > corresponding cached hi-entry, unless the hi-targeted-to-uri is a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Tel-URI. If the SIP response does not contain a Reason header > field with a protocol of "SIP", the SIP entity MUST include a > Reason header field, containing the SIP Response Code, in the > "headers" component of the hi-targeted-to-uri in the corresponding > cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI. > > [MB] Note, you dropped "field" from the "Reason header value above, > which is not correct. So the real changes I see above are with regards > to highlighting that it's the corresponding cached hi-entry (rather > than the last. I have annotated above that that is the only change > (AFAICT). I can make that change as follows: > OLD: > If the Reason header field is being added due to receipt of an explicit > SIP response and the response contains any > Reason header fields (see [RFC3326]), then the SIP entity MUST > include the Reason header fields in the "headers" component of the > hi-targeted-to-uri in the last hi-entry added to the cache, unless > the hi-targeted-to-uri is a Tel-URI. > > NEW: > If the Reason header field is being added due to receipt of an explicit > SIP response to the corresponding INVITE > ^^^^^^^^^^^^^^^^^^^^^^ > and the response contains any > Reason header fields (see [RFC3326]), then the SIP entity MUST > include the Reason header fields in the "headers" component of the > hi-targeted-to-uri in the corresponding cached hi-entry, unless > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the hi-targeted-to-uri is a Tel-URI. > [/MB] > > There is a slight change here in that if the response contains > "Reason: Q.850;cause=14", then both the Q.850 response code and the > SIP response code will be recorded in the cached hi-entry. The > previous text caused only the Q.850 response code to be recorded. > [MB] I don't see that the previous text said that only the Q.850 > response code was recorded. > The text says that "Reason header fields" as in plural fields are added. [/MB] > > If a Reason header includes a reason-value with protocol "SIP", that > reason-value is recorded instead of the response code in the response. > (This is the same as the previous text.) > > ========== > >> 2. During the life of the document, there was confusion about how >> hi-entries were to be organized. The intention of the original writer >> and the current draft is that hi-entries are accumulated in a cache in >> the order the entity receives them (in requests and responses), >> allowing hi-entries that have the *same* index but *different* URIs, >> and (implicitly) eliminating duplicates. > [MB] It wasn't just the original author and the current author, this > has been the intent of > the document and the approach was agreed by the WG. Certainly, there were some > errors that might have lead one to believe otherwise, but that was > never the intent. [/MB] >> >> But some people who have worked on the draft (including myself) were >> for a while mistaken in believing that the hi-entries were to be >> organized into a tree, and hence the index values needed to be unique, >> and the History-Info header would list the hi-entries in tree-walking >> order (technically, "preorder"). The confusion was abetted by there >> being no examples that distinguish the two techniques. > [MB] I think the confusion is that if everyone supported HI, you would > get a tree. > You can still get a somewhat pruned tree using the indices. I think > the confusion is that the RFC never > had any intention of defining application behavior. It is merely > recording what happens at the SIP protocol level. That's it. How an > application uses the information (whether to build a tree or whatever) > is out of scope. [/MB] >> Unfortunately, the -11 draft doesn't eliminate all the remnants of the >> mistake. I haven't gone through -11 in detail, but "preorder" appears >> in section 9.2 and section 10.3, so at least those sections describe >> the accumulation of hi-entries incorrectly. > > The fix to this issue overlaps the fix for issue #4: > >> 4. If a downstream entity that does not support History-Info forks a >> request to entities that do support History-Info, an entity can >> receive two hi-entries with the same index that were not generated for >> the same fork of the request. Conversely, an entity will receive >> responses that contain hi-entries that are duplicates of entries that >> are already in the cache. >> >> These facts imply that there is a process by which an entity >> determines whether a received hi-entry is "the same" as an hi-entry >> already in the cache (and so doesn't need to be added again). Since >> index values cannot be depended upon to be unique, we really ought to >> state what the comparison rule is. >> >> I think it is sufficient to use the rule "the same index value and the >> URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the >> Reason header fields)". This won't always give the result one would >> want (if a non-supporting downstream element forks the request to two >> target URIs that ultimately arrive at the same element, two hi-entries >> could be generated with the same index and URI), but this rule is >> simple, well-defined, and should work well in almost all situations. > > In addition, when a response is received, it may contain hi-entries > that are duplicates of hi-entries already in the cache, except they > contain Reason header values that are not in the cached hi-entries. I > believe we intend that the cached hi-entries be updated to include the > received Reason header values. > > The edits to fix these three issues are: > > 9.2. Sending a Request with History-Info > > When sending a request, a SIP entity MUST include all the hi-entries > from the cache that was created per Section 9.1. In addition, the > SIP entity MUST add a new hi-entry to the outgoing request, but the > SIP entity MUST NOT add the hi-entry to the cache at this time. The > --------------------------------------------------------------------^ > Change this sentence to: "The hi-entries in the outgoing request's > History-Info header are in the order of the hi-entries in the cache, > which is the order in which they were added to the cache." > > [MB] That's fine. And, just for clarification, the statement below is > the OLD and the one above is the NEW [/MB] > > hi-entries in the outgoing request's History-Info header field is the > preorder of the tree of hi-entries, that is, by the lexicographic > ordering of the hi-indexes. The new hi-entry is populated as > follows: > > 9.3. Receiving a Response with History-Info or Request Timeouts > > Step 1: Add hi-entry to cache > > The SIP entity MUST add the hi-entry that was added to the request > -----------------------------^ > For clarity insert "to the cache" here, and... > that received the non-100 response or timed out to the cache, if > ------------------------------------------------------^^^^^^^^^^^^ > ... remove "to the cache" here. > it was not already cached. The hi-entry MUST be added to the > ----------------------------------^ > Change this sentence to "If so, the hi-entry MUST be added to the end > of the cache." > > cache in ascending order as indicated by the values in the hi- > index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 > but before 1.2.2 or 1.3). > > [MB] I can't decipher the changes you are suggesting above. I think I > see your point. However, > there is something very subtle here. This is dealing with responses > and we add the hi-entries once we > get the response. However, the value of the hi-index actually does > reflect a chronological order in terms of generating requests. As > discussed previously, you lose that chronological ordering across > entities, but for a specific > SIP entity they do reflect the chronological processing at that > entity. So, I don't think this is broken. With the cache > model, we aren't adding them to the cache until we get the response > even though they were added to the request (in both chronological and > lexicographical order). > [/MB] > > > 9.3. Receiving a Response with History-Info or Request Timeouts > > Step 3: Add additional hi-entries > > The SIP entity MUST also add to the cache any hi-entries received > in the response that are not already in the cache. This situation > can occur when the entity that generated the non-100 response > retargeted the request before generating the response. As per > Step 1, the hi-entries MUST be added to the cache in ascending > order as indicated by the values in the hi-index parameters of the > hi-entries > > This paragraph needs more extensive changes: > [MB] It's not clear to me why you think it needs to be done this way. > This is still mapping back to the original request sent by a specific > entity (e.g., Proxy A). I think you are confused by the scenario > being described. The retargeting was not done by Proxy A that is > caching the hi-entries. It was done by Proxy B that received the > request and it retargeted before returning the 1xx response thus there > is an additional hi-entry that Proxy A should add to its cache. [/MB] > > Step 3: Add and update additional hi-entries > > The SIP entity MUST also add to the cache any hi-entries received > in the response that are not already in the cache. This > can occur when the entity that generated the non-100 response > retargeted the request before generating the response. Such > hi-entries MUST be added to the end of the cache in the order > they appear in the History-Info header field of the response. > > If an hi-entry in the response contains Reason header value(s) > and the matching hi-entry in the cache does not, the Reason > header value(s) MUST be added to the cached hi-entry. This can > occur when the hi-entry was added to the cache by a provisional > response to an INVITE that was further retargeted, and later a > final response to that INVITE is received. > > In these cases, an hi-entry in a response's History-Info header > field and an hi-entry in the cache are considered matching when > they have the same index value and the hi-targeted-to-uris are > equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason > header fields). > > 10.2. Reason in the History-Info Header Field > > A Reason header field is added to the "headers" component in an hi- > targeted-to-uri when the hi-entry is added to the cache based upon > ----------------------------------------^^^^^^^^ > change to "added to, or updated within," > > the receipt of a non-100 or non-2xx SIP response, as described in > Section 9.3. [...] > [MB] Why "updated within"? [/MB] > > 10.3. Indexing in the History-Info Header Field > > In order to maintain ordering and accurately reflect the retargeting > of the request, the SIP entity MUST add a hi-index to each hi-entry. > Per the syntax in Section 5, the hi-index consists of a series of > nonnegative integer separated by dots (e.g., 1.1.2). Each dot > reflects a SIP forwarding hop. The nonnegative integer following > each dot reflects the order in which a request was retargeted at the > hop. The highest nonnegative integer at each hop reflects the number > of entities to which the request has been retargeted at the specific > hop (i.e., the number of branches) at the time that the request > represented by this hi-entry was generated. Thus, the indexing > results in a logical tree representation for the history of the > request and the hi-entries are given in the preorder of the tree. > -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > delete this clause > [MB] Okay. [/MB] > > ========== > >> 3. Due to the confusion discussed in #2, we have to consider whether >> consensus was actually found in the WGLC. > [MB] We had consensus in WGLC. Your comments came well after WG last call > and after IETF LC. > >> We thought we had >> consensus, but people did not have the same understanding of this >> aspect of the draft. (Ugh.) > > This is a procedural issue, not a technical one. I don't see any > objection to correcting the normative text if everyone who cares > agrees that the changes express what we intended. (We should check > this point with the AD.) > > [MB] I do not see that we are changing any of the intended normative > behavior but rather fixing things that didn't quite reflect the > normative behavior as stated elsewhere (i.e., inconsistencies). [/MB] > > ========== > >> 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 >> do not show the History-Info value in the final 200 response to the >> UAC. This final value would be useful, in particular, because they >> give further examples of how proxies process History-Info. > > I was mistaken here: The final 200 response from the example.com > proxy to the UAC in these examples has the same History-Info as the > 200 response arriving at the example.com proxy, because there is no > History-Info information that the proxy knows that is not known to the > UAS that generated the 200 response. Thus there is nothing > interesting to document. > > ========== > >> 6. Interestingly, despite the fact that there can be duplicate index >> values, when a request is received by a UAS, there is no ambiguity in >> the history when tracing *back* from the last hi-entry (the one that >> denotes the UAS). This is because even if this UAS is "down one fork" >> from a forking non-supporting proxy, none of the hi-entries generated >> "down the other fork" will be present in the request the UAS sees. >> >> This is in contrast to the situation at the UAC, which may see >> hi-entries with duplicate indexes, and the interpretation of "rc", >> "mp", and "np" parameters can be ambiguous. > > This is an interesting observation, but it does not require > documentation in the RFCs. > > ========== > >> 7. In example 3.6 message F6 in >> draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is: >> >> 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: > target=sip:bob%40example.com;cause=408>;\ >> index=1.3;mp=1.2 >> History-Info: > target=sip:bob%40example.com;cause=408>;\ >> index=1.3.1;rc=1.3 >> >> This is what we intend, as it shows both where the index=1.3 URI came >> from (sip:bob@example.com) as well as why the index=1.3 fork was >> generated (because sip:carol@example.com failed). But it points out >> that we need to improve the description in rfc4244bis section 5 of >> what the values of the "rc" (etc.) parameters are. A naive reader >> might think "rc=1.2" in the 1.3 entry means that >> was >> generated as a contact for . Instead, it means >> that the 1.3 fork was generated *because* the 1.2 fork returned a >> response; it was generated *from* the index=1 URI. >> >> Actually, the real rules for interpreting "rc" (etc.) are not simple: > [MB] The above is an example, thus the description is not complete. [/MB] >> >> 1) If the index-val in the param points to an entry with a Reason >> header-param whose value is "SIP;cause=3xx" (after removing >> escaping!), then: >> - the URI was one of the Contact values in the 3xx response >> - that response was why the new fork was generated. >> >> 2) If the index-val in the param points to the parent of this >> hi-entry, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was not generated due to the response from any other fork. >> >> 3) If the index-val in the param points to an hi-entry that is not the >> parent, and that hi-entry does not contain a Reason header-param >> containing a 3xx status, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was generated due to the response from the hi-entry with >> the specified index-val. >> >> And this doesn't match the section 5 definition of the value of "rc" >> (etc.), which is: >> >> The "rc" header field parameter contains the value of the >> hi-index in the hi-entry with an hi-targeted-to-uri that >> reflects the Request-URI that was retargeted > > In section 5, these paragraphs need to be revised: > > o hi-target-param: An optional parameter reflecting the mechanism by > which the Request URI captured in the hi-targeted-to-uri in the > History-Info header field value (hi-entry) was determined. This > parameter is either an "rc", "mp" or "np" header field parameter, > which is interpreted as follows: > > "rc": The hi-targeted-to-URI represents a change in Request-URI > while the target user remains the same. This occurs for > example when user has multiple AoRs as an alias. The "rc" > header field parameter contains the value of the hi-index in > the hi-entry with an hi-targeted-to-uri that reflects the > Request-URI that was retargeted > > "mp": The hi-targeted-to-URI represents a user other than the > target user associated with the Request-URI in the incoming > request that was retargeted. This occurs when a request is > statically or dynamically retargeted to another user > represented by an AoR unassociated with the AoR of the original > target user. The "mp" header field parameter contains the > value of the hi-index in the hi-entry with an hi-targeted-to- > uri that reflects the Request-URI that was retargeted, thus > identifying the "mapped from" target. > > "np": The hi-targeted-to-URI represents that there was no > change in Request-URI. This would apply for example when a > proxy merely forwards a request to a next hop proxy and loose > routing is used. The "np" header field parameter contains the > value of the hi-index in the hi-entry with an hi-targeted-to- > uri that reflects the Request-URI that was copied unchanged > into the request represented by this hi-entry. That value will > usually be the hi-index of the parent hi-entry of this hi- > entry. > > The revised paragraphs are: > > [MB] I don't agree with this proposal - that's way too much detail for > this section. I believe that the normative > sections describe how/when you add the "rc" tag which should match > what you are describing in your new bullets. I will note that this > section has been updated several times both adding more text and > reducing the text in this section. What you have proposed for the > bullets below (i.e., the "rc", "mp" etc.) is some of the level of > detail we had previously (in the -02). I believe the text you > suggest is application logic - note that items 2 & 4 describe the "rc" > scenarios and this wasn't intended to be comprehensive. If you can > highlight what's missing in those 2 bullets, we can perhaps make some > changes there. I will note if these suggestions had been made much > earlier in the process, it would have been much more helpful - much of > the text you mention has been in the document since around the -02. > We did several rounds of major edits while developing this document > both while it was an individual and as a WG document. Note that this > document became a WG document literally 3 years ago. It's quite > disruptive to be raising this issues at this stage. [/MB] > > [This first paragraph is unchanged:] > o hi-target-param: An optional parameter reflecting the mechanism by > which the Request URI captured in the hi-targeted-to-uri in the > History-Info header field value (hi-entry) was determined. This > parameter is either an "rc", "mp" or "np" header field parameter, > which is interpreted as follows: > > "rc": The hi-targeted-to-URI represents a change in Request-URI > while the target user remains the same. This occurs for > example when user has multiple AoRs as an alias or when > forwarding the request to a registered contact of an AoR. > > "mp": The hi-targeted-to-URI represents a user other than the > target user associated with the Request-URI in the incoming > request that was retargeted. This occurs when a request is > statically or dynamically retargeted to another user > represented by an AoR unassociated with the AoR of the original > target user. > > "np": The hi-targeted-to-URI represents that there was no > change in Request-URI. This would apply for example when a > proxy merely forwards a request to a next hop proxy and loose > routing is used. The "np" header field parameter contains the > value of the hi-index in the parent hi-entry of this hi-entry. > > If the index-val in the parameter points to the parent hi-entry of this > hi-entry, then: > - the URI was generated from the URI of the parent hi-entry > - the fork was not generated due to the response from any other fork. > > If the index-val in the parameter points to an hi-entry with a Reason > header value whose protocol is "SIP" and whose cause begins with "3", > then: > - the URI was one of the Contact values in the 3xx response > - the fork was generated due to the 3xx response from the hi-entry with > the specified index-val. > > If the index-val in the param points to an hi-entry that is not the > parent, and that hi-entry does not contain a Reason header value > containing a SIP 3xx cause, then: > - the URI was generated from the URI of the parent hi-entry > - the fork was generated due to the response from the hi-entry with > the specified index-val. > > ====================================================================== > > I believe that is everything to be done. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Feb 19 08:55:51 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 9EA3D21F893E for ; Tue, 19 Feb 2013 08:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 LIEB7M1zZ3Ev for ; Tue, 19 Feb 2013 08:55:49 -0800 (PST) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 366AF21F89B2 for ; Tue, 19 Feb 2013 08:55:49 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id 1so3168877qeb.13 for ; Tue, 19 Feb 2013 08:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Kpr52bFx9YgDtZL9q18oHeCTjSlHmVuvNYnVWv2WYXQ=; b=zv6YhhvS10m+Vhq0/GL0nV+khAsZdDCut6KrobzDlRxr5tFSbNl+TkoC+UMqQjuQPP qW4suzLSazMmbUyI04qY7oW+aQC1912n3hCtQd9LeV2E7BfTmVoOTId9FMSVsAaiUGbV BEczWLRWK7Imz/JoZYgYmZc8zSFixUcSjjs/rgC6bKPkaC68M0SeJhhw8Jb65gZ6TjE0 A2nVwwGcQ0Kj6KSNH8wASp81ohewyugnyg14QBMqc8ZejAGAHZguKBWqakSKDSxRGTI2 Q6vai57kE4zh8Jo6oF2LWKZJPryO2EAUj2sHcYtAYFh2V+ztov9U0Hu8/GPh325QfgQH KwJw== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr7377899qab.43.1361292948655; Tue, 19 Feb 2013 08:55:48 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 19 Feb 2013 08:55:48 -0800 (PST) In-Reply-To: <5123AD43.2080400@alum.mit.edu> References: <201302061509.r16F90sh016532@freeze.ariadne.com> <5123AD43.2080400@alum.mit.edu> Date: Tue, 19 Feb 2013 10:55:48 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: SIPCORE Subject: Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. 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 Feb 2013 16:55:51 -0000 On Tue, Feb 19, 2013 at 10:50 AM, Paul Kyzivat wrote: > Mary & Dale, > > This is very hard to follow. > But I do get it that the two of you are getting closer but still not in > total agreement. Can the two of you reach a mutually satisfactory > conclusion? > > I'd love to have a new version with a direct diff to evaluate it all. > > I must say that I am surprised that so much effort was put into the > hierarchical numbering scheme for entries and yet the conclusion is that the > entries are not sorted in accord with this hierarchy. (Or did I get that > wrong?) [MB] As I highlighted to Dale, within an entity they are in order. The issue is due to the fact that not all entities will support HI, thus you cannot guarantee that the lexicographical order is meaningful (amongst all the entities). Since we do require an entity to add the entries in chronological order using the indexing scheme as specifed they are in order for that entity. When the request is forwarded and a response contains additional hi-entires (due to retargeting at the next hop), the ordering is guaranteed for the entity to which the request was forwarded. The issue comes when you get a reset to 0 indicating an entity did not support HI, then you lose any ordering. [/MB] > > Thanks, > Paul > > > On 2/19/13 11:16 AM, Mary Barnes wrote: >> >> Hi all, >> >> This is a set of suggested changes from Dale based upon the comments >> he sent to the list previously: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html >> >> Responses are inline below [MB]. Based upon my responses, I do not >> believe any of the changes impact normative behavior (as intended) >> thus another WG and/or IETF LC should not be necessary, but I will >> leave that decision to the chairs/AD. >> >> Mary. >> >> >> ---------- Forwarded message ---------- >> From: Dale R. Worley >> Date: Wed, Feb 6, 2013 at 9:09 AM >> Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. >> To: mary.h.barnes@gmail.com, pkyzivat@alum.mit.edu >> >> >> Here are my proposed fixes to the -11 version. I believe that all of >> these changes are non-controverisial, in that they adjust the document >> to express what we all agree it ought to mean. But in a number of >> places, the prescribed procedures are actually different from the >> current text. Please review this and get back to us with your >> thoughts. >> >> Thanks, >> >> Dale >> >> ====================================================================== >> >> Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. >> >> This document is organized as a series of responses to the points in >> my e-mail of 18 Jan >> (http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html). >> >> ========== >> >>> From: worley@ariadne.com (Dale R. Worley) >>> To: SIPCORE >>> Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt >>> Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST) >>> >>> I've got a few questions about 4244bis. I think that there are >>> understood answers to most of them, but we might have to update the >>> wording to remove ambiguity. >> >> >> ========== >> >>> 1. When an entity receives a (non-100) provisional response to a >>> request, should it modify the hi-entry by adding a Reason value >>> carrying the status of the response? The current text (section 10.2) >>> clearly requires it. If the request eventually receives a failure >>> response, the 1xx Reason will (probably) later be replaced by the >>> failure code. (But not necessarily: see section 10.2 paragraph 3.) >>> >>> The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this >>> situation is section 3.1 message F8, and the 180 status is not >>> reported in a Reason header-value for (which >>> thus contradicts section 10.2). >>> >>> The alternative is that 1xx responses do not set the Reason value >>> (although they do add to the cache any new hi-entries they carry). >>> This would require changing the text in section 9.3 step 2 and section >>> 10.2. >> >> >> NOTE: I am assuming that non-100 provisional responses are intended >> to carry hi-entries upstream, and that proxies that see those >> responses are intended to cache the hi-entries carried in them. >> (Those cached hi-entries can later be updated by a final response >> which adds a Reason header value to them.) If this is not so, these >> changes need to be revised. >> >> As far as I can tell, we have never intended for receipt of a >> provisional (1xx) response to an INVITE to set a Reason header on the >> corresponding cached hi-entry. The only example in 4244bis-callflows >> of this situation is message F6 of section 3.1, in which there would >> be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not. >> And RFC 4244, which also has the Reason header value mechanism, does >> not specify that 1xx responses set Reason header values. >> >> So I propose that we all agree that 1xx responses should not generate >> Reason headers and we edit the text accordingly. >> [MB] Correct. That's been the intent for both 4244 and 4244bis. >> It's mentioned in 9.4 that the HI is not sent in 100 responses (since >> those do not result in retargeting), thus there would be no reason to >> add a Reason header to anything. [/MB] >> >> The changes are: >> >> section 9.3 step 2 >> >> Step 2: Add Reason header field >> >> The SIP entity adds one or more Reason header fields to the hi- >> ------^ >> change "The" to "If the response code is not 1xx, the" >> targeted-to-uri in the (newly) cached hi-entry reflecting the SIP >> response code in the non-100 response, per the procedures of >> ---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> delete(?) >> Section 10.2. >> >> This change results in: >> >> If the response code is not 1xx, the SIP entity adds one or more >> Reason header fields to the hi-targeted-to-uri in the (newly) >> cached hi-entry reflecting the SIP response, per the procedures >> of Section 10.2. >> >> [MB] Note that the section is specific to non-100 responses, which is >> why it is written as it currently is. >> I don't see that your suggested text adds any more information - i.e., >> the IF isn't necessary. We are stating specific behavior for that >> specific step and an "IF" isn't necessary. I do not think this change >> is necessary. [/MB] >> >> 10.2. Reason in the History-Info Header Field >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> the receipt of a non-100 or non-2xx SIP response, as described in >> Section 9.3. If the Reason header field is being added due to >> receipt of an explicit SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. If the SIP response does not >> contain a Reason header field, the SIP entity MUST include a Reason >> header field, containing the SIP Response Code, in the "headers" >> component of the hi-targeted-to-uri in the last hi-entry added to the >> cache, unless the hi-targeted-to-uri is a Tel-URI. >> >> The changes to this paragraph are extensive enough that I am not >> showing the individual differences. Note I have changed "the last >> hi-entry added to the cache" to "the corresponding hi-entry". The >> latter makes more sense to me, and specifies the same hi-entry. But >> others may prefer the current description, in which case we can retain >> it. >> >> The new version of this paragraph is: >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when a non-100, non-2xx SIP response is received to >> the corresponding INVITE, or when a response is received containing >> the hi-entry with a Reason header value, as described in Section >> 9.3. >> [MB] You have dropped the reference to the cache here and that very >> important. I think it's obvious that we >> are dealing with the corresponding INVITE. When we talk about SIP >> responses, we do not qualify it as "the SIP response received to the >> corresponding INVITE". But, it certainly causes no harm. I would >> suggest that sentence read: >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> the receipt of a non-100 or non-2xx SIP response to the >> corresponding INVITE, as described in >> Section 9.3. >> >> [/MB] >> >> If the Reason header value is being added to an hi-targeted-to-uri >> due to receipt of an explicit SIP response to the corresponding >> INVITE and the response contains any Reason header fields (see >> [RFC3326]), then the SIP entity MUST also include the Reason header >> fields in the "headers" component of the hi-targeted-to-uri in the >> corresponding cached hi-entry, unless the hi-targeted-to-uri is a >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Tel-URI. If the SIP response does not contain a Reason header >> field with a protocol of "SIP", the SIP entity MUST include a >> Reason header field, containing the SIP Response Code, in the >> "headers" component of the hi-targeted-to-uri in the corresponding >> cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI. >> >> [MB] Note, you dropped "field" from the "Reason header value above, >> which is not correct. So the real changes I see above are with regards >> to highlighting that it's the corresponding cached hi-entry (rather >> than the last. I have annotated above that that is the only change >> (AFAICT). I can make that change as follows: >> OLD: >> If the Reason header field is being added due to receipt of an >> explicit >> SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. >> >> NEW: >> If the Reason header field is being added due to receipt of an >> explicit >> SIP response to the corresponding INVITE >> ^^^^^^^^^^^^^^^^^^^^^^ >> and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the corresponding cached hi-entry, unless >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> the hi-targeted-to-uri is a Tel-URI. >> [/MB] >> >> There is a slight change here in that if the response contains >> "Reason: Q.850;cause=14", then both the Q.850 response code and the >> SIP response code will be recorded in the cached hi-entry. The >> previous text caused only the Q.850 response code to be recorded. >> [MB] I don't see that the previous text said that only the Q.850 >> response code was recorded. >> The text says that "Reason header fields" as in plural fields are added. >> [/MB] >> >> If a Reason header includes a reason-value with protocol "SIP", that >> reason-value is recorded instead of the response code in the response. >> (This is the same as the previous text.) >> >> ========== >> >>> 2. During the life of the document, there was confusion about how >>> hi-entries were to be organized. The intention of the original writer >>> and the current draft is that hi-entries are accumulated in a cache in >>> the order the entity receives them (in requests and responses), >>> allowing hi-entries that have the *same* index but *different* URIs, >>> and (implicitly) eliminating duplicates. >> >> [MB] It wasn't just the original author and the current author, this >> has been the intent of >> the document and the approach was agreed by the WG. Certainly, there were >> some >> errors that might have lead one to believe otherwise, but that was >> never the intent. [/MB] >>> >>> >>> But some people who have worked on the draft (including myself) were >>> for a while mistaken in believing that the hi-entries were to be >>> organized into a tree, and hence the index values needed to be unique, >>> and the History-Info header would list the hi-entries in tree-walking >>> order (technically, "preorder"). The confusion was abetted by there >>> being no examples that distinguish the two techniques. >> >> [MB] I think the confusion is that if everyone supported HI, you would >> get a tree. >> You can still get a somewhat pruned tree using the indices. I think >> the confusion is that the RFC never >> had any intention of defining application behavior. It is merely >> recording what happens at the SIP protocol level. That's it. How an >> application uses the information (whether to build a tree or whatever) >> is out of scope. [/MB] >>> >>> Unfortunately, the -11 draft doesn't eliminate all the remnants of the >>> mistake. I haven't gone through -11 in detail, but "preorder" appears >>> in section 9.2 and section 10.3, so at least those sections describe >>> the accumulation of hi-entries incorrectly. >> >> >> The fix to this issue overlaps the fix for issue #4: >> >>> 4. If a downstream entity that does not support History-Info forks a >>> request to entities that do support History-Info, an entity can >>> receive two hi-entries with the same index that were not generated for >>> the same fork of the request. Conversely, an entity will receive >>> responses that contain hi-entries that are duplicates of entries that >>> are already in the cache. >>> >>> These facts imply that there is a process by which an entity >>> determines whether a received hi-entry is "the same" as an hi-entry >>> already in the cache (and so doesn't need to be added again). Since >>> index values cannot be depended upon to be unique, we really ought to >>> state what the comparison rule is. >>> >>> I think it is sufficient to use the rule "the same index value and the >>> URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the >>> Reason header fields)". This won't always give the result one would >>> want (if a non-supporting downstream element forks the request to two >>> target URIs that ultimately arrive at the same element, two hi-entries >>> could be generated with the same index and URI), but this rule is >>> simple, well-defined, and should work well in almost all situations. >> >> >> In addition, when a response is received, it may contain hi-entries >> that are duplicates of hi-entries already in the cache, except they >> contain Reason header values that are not in the cached hi-entries. I >> believe we intend that the cached hi-entries be updated to include the >> received Reason header values. >> >> The edits to fix these three issues are: >> >> 9.2. Sending a Request with History-Info >> >> When sending a request, a SIP entity MUST include all the hi-entries >> from the cache that was created per Section 9.1. In addition, the >> SIP entity MUST add a new hi-entry to the outgoing request, but the >> SIP entity MUST NOT add the hi-entry to the cache at this time. The >> --------------------------------------------------------------------^ >> Change this sentence to: "The hi-entries in the outgoing request's >> History-Info header are in the order of the hi-entries in the cache, >> which is the order in which they were added to the cache." >> >> [MB] That's fine. And, just for clarification, the statement below is >> the OLD and the one above is the NEW [/MB] >> >> hi-entries in the outgoing request's History-Info header field is the >> preorder of the tree of hi-entries, that is, by the lexicographic >> ordering of the hi-indexes. The new hi-entry is populated as >> follows: >> >> 9.3. Receiving a Response with History-Info or Request Timeouts >> >> Step 1: Add hi-entry to cache >> >> The SIP entity MUST add the hi-entry that was added to the request >> -----------------------------^ >> For clarity insert "to the cache" here, and... >> that received the non-100 response or timed out to the cache, if >> ------------------------------------------------------^^^^^^^^^^^^ >> ... remove "to the cache" here. >> it was not already cached. The hi-entry MUST be added to the >> ----------------------------------^ >> Change this sentence to "If so, the hi-entry MUST be added to the end >> of the cache." >> >> cache in ascending order as indicated by the values in the hi- >> index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 >> but before 1.2.2 or 1.3). >> >> [MB] I can't decipher the changes you are suggesting above. I think I >> see your point. However, >> there is something very subtle here. This is dealing with responses >> and we add the hi-entries once we >> get the response. However, the value of the hi-index actually does >> reflect a chronological order in terms of generating requests. As >> discussed previously, you lose that chronological ordering across >> entities, but for a specific >> SIP entity they do reflect the chronological processing at that >> entity. So, I don't think this is broken. With the cache >> model, we aren't adding them to the cache until we get the response >> even though they were added to the request (in both chronological and >> lexicographical order). >> [/MB] >> >> >> 9.3. Receiving a Response with History-Info or Request Timeouts >> >> Step 3: Add additional hi-entries >> >> The SIP entity MUST also add to the cache any hi-entries received >> in the response that are not already in the cache. This situation >> can occur when the entity that generated the non-100 response >> retargeted the request before generating the response. As per >> Step 1, the hi-entries MUST be added to the cache in ascending >> order as indicated by the values in the hi-index parameters of the >> hi-entries >> >> This paragraph needs more extensive changes: >> [MB] It's not clear to me why you think it needs to be done this way. >> This is still mapping back to the original request sent by a specific >> entity (e.g., Proxy A). I think you are confused by the scenario >> being described. The retargeting was not done by Proxy A that is >> caching the hi-entries. It was done by Proxy B that received the >> request and it retargeted before returning the 1xx response thus there >> is an additional hi-entry that Proxy A should add to its cache. [/MB] >> >> Step 3: Add and update additional hi-entries >> >> The SIP entity MUST also add to the cache any hi-entries received >> in the response that are not already in the cache. This >> can occur when the entity that generated the non-100 response >> retargeted the request before generating the response. Such >> hi-entries MUST be added to the end of the cache in the order >> they appear in the History-Info header field of the response. >> >> If an hi-entry in the response contains Reason header value(s) >> and the matching hi-entry in the cache does not, the Reason >> header value(s) MUST be added to the cached hi-entry. This can >> occur when the hi-entry was added to the cache by a provisional >> response to an INVITE that was further retargeted, and later a >> final response to that INVITE is received. >> >> In these cases, an hi-entry in a response's History-Info header >> field and an hi-entry in the cache are considered matching when >> they have the same index value and the hi-targeted-to-uris are >> equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason >> header fields). >> >> 10.2. Reason in the History-Info Header Field >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> ----------------------------------------^^^^^^^^ >> change to "added to, or updated within," >> >> the receipt of a non-100 or non-2xx SIP response, as described in >> Section 9.3. [...] >> [MB] Why "updated within"? [/MB] >> >> 10.3. Indexing in the History-Info Header Field >> >> In order to maintain ordering and accurately reflect the retargeting >> of the request, the SIP entity MUST add a hi-index to each hi-entry. >> Per the syntax in Section 5, the hi-index consists of a series of >> nonnegative integer separated by dots (e.g., 1.1.2). Each dot >> reflects a SIP forwarding hop. The nonnegative integer following >> each dot reflects the order in which a request was retargeted at the >> hop. The highest nonnegative integer at each hop reflects the number >> of entities to which the request has been retargeted at the specific >> hop (i.e., the number of branches) at the time that the request >> represented by this hi-entry was generated. Thus, the indexing >> results in a logical tree representation for the history of the >> request and the hi-entries are given in the preorder of the tree. >> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> delete this clause >> [MB] Okay. [/MB] >> >> ========== >> >>> 3. Due to the confusion discussed in #2, we have to consider whether >>> consensus was actually found in the WGLC. >> >> [MB] We had consensus in WGLC. Your comments came well after WG last call >> and after IETF LC. >> >>> We thought we had >>> consensus, but people did not have the same understanding of this >>> aspect of the draft. (Ugh.) >> >> >> This is a procedural issue, not a technical one. I don't see any >> objection to correcting the normative text if everyone who cares >> agrees that the changes express what we intended. (We should check >> this point with the AD.) >> >> [MB] I do not see that we are changing any of the intended normative >> behavior but rather fixing things that didn't quite reflect the >> normative behavior as stated elsewhere (i.e., inconsistencies). [/MB] >> >> ========== >> >>> 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 >>> do not show the History-Info value in the final 200 response to the >>> UAC. This final value would be useful, in particular, because they >>> give further examples of how proxies process History-Info. >> >> >> I was mistaken here: The final 200 response from the example.com >> proxy to the UAC in these examples has the same History-Info as the >> 200 response arriving at the example.com proxy, because there is no >> History-Info information that the proxy knows that is not known to the >> UAS that generated the 200 response. Thus there is nothing >> interesting to document. >> >> ========== >> >>> 6. Interestingly, despite the fact that there can be duplicate index >>> values, when a request is received by a UAS, there is no ambiguity in >>> the history when tracing *back* from the last hi-entry (the one that >>> denotes the UAS). This is because even if this UAS is "down one fork" >>> from a forking non-supporting proxy, none of the hi-entries generated >>> "down the other fork" will be present in the request the UAS sees. >>> >>> This is in contrast to the situation at the UAC, which may see >>> hi-entries with duplicate indexes, and the interpretation of "rc", >>> "mp", and "np" parameters can be ambiguous. >> >> >> This is an interesting observation, but it does not require >> documentation in the RFCs. >> >> ========== >> >>> 7. In example 3.6 message F6 in >>> draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is: >>> >>> 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: >> target=sip:bob%40example.com;cause=408>;\ >>> index=1.3;mp=1.2 >>> History-Info: >> target=sip:bob%40example.com;cause=408>;\ >>> index=1.3.1;rc=1.3 >>> >>> This is what we intend, as it shows both where the index=1.3 URI came >>> from (sip:bob@example.com) as well as why the index=1.3 fork was >>> generated (because sip:carol@example.com failed). But it points out >>> that we need to improve the description in rfc4244bis section 5 of >>> what the values of the "rc" (etc.) parameters are. A naive reader >>> might think "rc=1.2" in the 1.3 entry means that >>> was >>> generated as a contact for . Instead, it means >>> that the 1.3 fork was generated *because* the 1.2 fork returned a >>> response; it was generated *from* the index=1 URI. >>> >>> Actually, the real rules for interpreting "rc" (etc.) are not simple: >> >> [MB] The above is an example, thus the description is not complete. [/MB] >>> >>> >>> 1) If the index-val in the param points to an entry with a Reason >>> header-param whose value is "SIP;cause=3xx" (after removing >>> escaping!), then: >>> - the URI was one of the Contact values in the 3xx response >>> - that response was why the new fork was generated. >>> >>> 2) If the index-val in the param points to the parent of this >>> hi-entry, then: >>> - the URI was generated from the URI of the parent hi-entry >>> - the fork was not generated due to the response from any other fork. >>> >>> 3) If the index-val in the param points to an hi-entry that is not the >>> parent, and that hi-entry does not contain a Reason header-param >>> containing a 3xx status, then: >>> - the URI was generated from the URI of the parent hi-entry >>> - the fork was generated due to the response from the hi-entry with >>> the specified index-val. >>> >>> And this doesn't match the section 5 definition of the value of "rc" >>> (etc.), which is: >>> >>> The "rc" header field parameter contains the value of the >>> hi-index in the hi-entry with an hi-targeted-to-uri that >>> reflects the Request-URI that was retargeted >> >> >> In section 5, these paragraphs need to be revised: >> >> o hi-target-param: An optional parameter reflecting the mechanism by >> which the Request URI captured in the hi-targeted-to-uri in the >> History-Info header field value (hi-entry) was determined. This >> parameter is either an "rc", "mp" or "np" header field parameter, >> which is interpreted as follows: >> >> "rc": The hi-targeted-to-URI represents a change in Request-URI >> while the target user remains the same. This occurs for >> example when user has multiple AoRs as an alias. The "rc" >> header field parameter contains the value of the hi-index in >> the hi-entry with an hi-targeted-to-uri that reflects the >> Request-URI that was retargeted >> >> "mp": The hi-targeted-to-URI represents a user other than the >> target user associated with the Request-URI in the incoming >> request that was retargeted. This occurs when a request is >> statically or dynamically retargeted to another user >> represented by an AoR unassociated with the AoR of the original >> target user. The "mp" header field parameter contains the >> value of the hi-index in the hi-entry with an hi-targeted-to- >> uri that reflects the Request-URI that was retargeted, thus >> identifying the "mapped from" target. >> >> "np": The hi-targeted-to-URI represents that there was no >> change in Request-URI. This would apply for example when a >> proxy merely forwards a request to a next hop proxy and loose >> routing is used. The "np" header field parameter contains the >> value of the hi-index in the hi-entry with an hi-targeted-to- >> uri that reflects the Request-URI that was copied unchanged >> into the request represented by this hi-entry. That value will >> usually be the hi-index of the parent hi-entry of this hi- >> entry. >> >> The revised paragraphs are: >> >> [MB] I don't agree with this proposal - that's way too much detail for >> this section. I believe that the normative >> sections describe how/when you add the "rc" tag which should match >> what you are describing in your new bullets. I will note that this >> section has been updated several times both adding more text and >> reducing the text in this section. What you have proposed for the >> bullets below (i.e., the "rc", "mp" etc.) is some of the level of >> detail we had previously (in the -02). I believe the text you >> suggest is application logic - note that items 2 & 4 describe the "rc" >> scenarios and this wasn't intended to be comprehensive. If you can >> highlight what's missing in those 2 bullets, we can perhaps make some >> changes there. I will note if these suggestions had been made much >> earlier in the process, it would have been much more helpful - much of >> the text you mention has been in the document since around the -02. >> We did several rounds of major edits while developing this document >> both while it was an individual and as a WG document. Note that this >> document became a WG document literally 3 years ago. It's quite >> disruptive to be raising this issues at this stage. [/MB] >> >> [This first paragraph is unchanged:] >> o hi-target-param: An optional parameter reflecting the mechanism by >> which the Request URI captured in the hi-targeted-to-uri in the >> History-Info header field value (hi-entry) was determined. This >> parameter is either an "rc", "mp" or "np" header field parameter, >> which is interpreted as follows: >> >> "rc": The hi-targeted-to-URI represents a change in Request-URI >> while the target user remains the same. This occurs for >> example when user has multiple AoRs as an alias or when >> forwarding the request to a registered contact of an AoR. >> >> "mp": The hi-targeted-to-URI represents a user other than the >> target user associated with the Request-URI in the incoming >> request that was retargeted. This occurs when a request is >> statically or dynamically retargeted to another user >> represented by an AoR unassociated with the AoR of the original >> target user. >> >> "np": The hi-targeted-to-URI represents that there was no >> change in Request-URI. This would apply for example when a >> proxy merely forwards a request to a next hop proxy and loose >> routing is used. The "np" header field parameter contains the >> value of the hi-index in the parent hi-entry of this hi-entry. >> >> If the index-val in the parameter points to the parent hi-entry of >> this >> hi-entry, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was not generated due to the response from any other >> fork. >> >> If the index-val in the parameter points to an hi-entry with a >> Reason >> header value whose protocol is "SIP" and whose cause begins with >> "3", >> then: >> - the URI was one of the Contact values in the 3xx response >> - the fork was generated due to the 3xx response from the hi-entry >> with >> the specified index-val. >> >> If the index-val in the param points to an hi-entry that is not the >> parent, and that hi-entry does not contain a Reason header value >> containing a SIP 3xx cause, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was generated due to the response from the hi-entry with >> the specified index-val. >> >> ====================================================================== >> >> I believe that is everything to be done. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Tue Feb 19 09:12:58 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 DA81221F8E63 for ; Tue, 19 Feb 2013 09:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 4IXs7jXaib62 for ; Tue, 19 Feb 2013 09:12:51 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC721F8E5B for ; Tue, 19 Feb 2013 09:12:41 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id z4so1944430qan.12 for ; Tue, 19 Feb 2013 09:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fmZ+ZaFcbm+RTrwcdCVZeUjummS4NPYdzToOUU8yw+8=; b=JUOF7kjeNR3TTM6UNVV5H08DGhDdiK6Xgl38/4R/bPesVMaVIptAzDDGVfPMptzIyK YED0PADQDigol+yhNaqJm3pH4V/U1zpd4t0kQCOu2Jjpqnm9aJWn/yKJREISvaLFjU8w Ve1ZX06ds/tfMIIqbUn2pIgFJlcFhXWShLf2E4k10IfQkDnc1a7Ilx/61ibCftMmHAXP LZbbVd/bLahb6BGJI9dRiNhsxqPcc3Yjd2I1dRXn2tJjEF3gZHqvi6yuWMA6jwXMRchM NVVZiB7Q/gEg5XWvGfXqlRTC27zEv05N+lz5uqmJi2pEROCHlcHg3U8p0/z1T2bs0f0w kt4Q== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr7055422qac.63.1361293960982; Tue, 19 Feb 2013 09:12:40 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 19 Feb 2013 09:12:40 -0800 (PST) In-Reply-To: <5123AD43.2080400@alum.mit.edu> References: <201302061509.r16F90sh016532@freeze.ariadne.com> <5123AD43.2080400@alum.mit.edu> Date: Tue, 19 Feb 2013 11:12:40 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: SIPCORE Subject: Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. 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 Feb 2013 17:12:59 -0000 On Tue, Feb 19, 2013 at 10:50 AM, Paul Kyzivat wrote: > Mary & Dale, > > This is very hard to follow. > But I do get it that the two of you are getting closer but still not in > total agreement. Can the two of you reach a mutually satisfactory > conclusion? [MB] In the end, this is a WG, chair and AD decision since this document has completed IETF LC. IMHO, the bar is much higher for changes at this stage in the process. If there is a lone voice with concerns that are not agreed by the WG and for which the justification is not extremely compelling, then I do not believe the changes should be made. As I said in my response, these changes could have been much more easily incorporated earlier in the process. For example, the last set of proposed changes are around text that has been heavily edited as well as a proposal to state things that are already in the document in a different manner. We can always find a way to edit text in our documents - at some point we say we're done which is usually after we've completed IETF LC unless the IESG review raises critical issues. [/MB] > > I'd love to have a new version with a direct diff to evaluate it all. [MB] I can generate a new version to reflect the changes that have been agreed. [/MB] > > I must say that I am surprised that so much effort was put into the > hierarchical numbering scheme for entries and yet the conclusion is that the > entries are not sorted in accord with this hierarchy. (Or did I get that > wrong?) > > Thanks, > Paul > > > On 2/19/13 11:16 AM, Mary Barnes wrote: >> >> Hi all, >> >> This is a set of suggested changes from Dale based upon the comments >> he sent to the list previously: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html >> >> Responses are inline below [MB]. Based upon my responses, I do not >> believe any of the changes impact normative behavior (as intended) >> thus another WG and/or IETF LC should not be necessary, but I will >> leave that decision to the chairs/AD. >> >> Mary. >> >> >> ---------- Forwarded message ---------- >> From: Dale R. Worley >> Date: Wed, Feb 6, 2013 at 9:09 AM >> Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. >> To: mary.h.barnes@gmail.com, pkyzivat@alum.mit.edu >> >> >> Here are my proposed fixes to the -11 version. I believe that all of >> these changes are non-controverisial, in that they adjust the document >> to express what we all agree it ought to mean. But in a number of >> places, the prescribed procedures are actually different from the >> current text. Please review this and get back to us with your >> thoughts. >> >> Thanks, >> >> Dale >> >> ====================================================================== >> >> Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. >> >> This document is organized as a series of responses to the points in >> my e-mail of 18 Jan >> (http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html). >> >> ========== >> >>> From: worley@ariadne.com (Dale R. Worley) >>> To: SIPCORE >>> Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt >>> Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST) >>> >>> I've got a few questions about 4244bis. I think that there are >>> understood answers to most of them, but we might have to update the >>> wording to remove ambiguity. >> >> >> ========== >> >>> 1. When an entity receives a (non-100) provisional response to a >>> request, should it modify the hi-entry by adding a Reason value >>> carrying the status of the response? The current text (section 10.2) >>> clearly requires it. If the request eventually receives a failure >>> response, the 1xx Reason will (probably) later be replaced by the >>> failure code. (But not necessarily: see section 10.2 paragraph 3.) >>> >>> The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this >>> situation is section 3.1 message F8, and the 180 status is not >>> reported in a Reason header-value for (which >>> thus contradicts section 10.2). >>> >>> The alternative is that 1xx responses do not set the Reason value >>> (although they do add to the cache any new hi-entries they carry). >>> This would require changing the text in section 9.3 step 2 and section >>> 10.2. >> >> >> NOTE: I am assuming that non-100 provisional responses are intended >> to carry hi-entries upstream, and that proxies that see those >> responses are intended to cache the hi-entries carried in them. >> (Those cached hi-entries can later be updated by a final response >> which adds a Reason header value to them.) If this is not so, these >> changes need to be revised. >> >> As far as I can tell, we have never intended for receipt of a >> provisional (1xx) response to an INVITE to set a Reason header on the >> corresponding cached hi-entry. The only example in 4244bis-callflows >> of this situation is message F6 of section 3.1, in which there would >> be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not. >> And RFC 4244, which also has the Reason header value mechanism, does >> not specify that 1xx responses set Reason header values. >> >> So I propose that we all agree that 1xx responses should not generate >> Reason headers and we edit the text accordingly. >> [MB] Correct. That's been the intent for both 4244 and 4244bis. >> It's mentioned in 9.4 that the HI is not sent in 100 responses (since >> those do not result in retargeting), thus there would be no reason to >> add a Reason header to anything. [/MB] >> >> The changes are: >> >> section 9.3 step 2 >> >> Step 2: Add Reason header field >> >> The SIP entity adds one or more Reason header fields to the hi- >> ------^ >> change "The" to "If the response code is not 1xx, the" >> targeted-to-uri in the (newly) cached hi-entry reflecting the SIP >> response code in the non-100 response, per the procedures of >> ---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> delete(?) >> Section 10.2. >> >> This change results in: >> >> If the response code is not 1xx, the SIP entity adds one or more >> Reason header fields to the hi-targeted-to-uri in the (newly) >> cached hi-entry reflecting the SIP response, per the procedures >> of Section 10.2. >> >> [MB] Note that the section is specific to non-100 responses, which is >> why it is written as it currently is. >> I don't see that your suggested text adds any more information - i.e., >> the IF isn't necessary. We are stating specific behavior for that >> specific step and an "IF" isn't necessary. I do not think this change >> is necessary. [/MB] >> >> 10.2. Reason in the History-Info Header Field >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> the receipt of a non-100 or non-2xx SIP response, as described in >> Section 9.3. If the Reason header field is being added due to >> receipt of an explicit SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. If the SIP response does not >> contain a Reason header field, the SIP entity MUST include a Reason >> header field, containing the SIP Response Code, in the "headers" >> component of the hi-targeted-to-uri in the last hi-entry added to the >> cache, unless the hi-targeted-to-uri is a Tel-URI. >> >> The changes to this paragraph are extensive enough that I am not >> showing the individual differences. Note I have changed "the last >> hi-entry added to the cache" to "the corresponding hi-entry". The >> latter makes more sense to me, and specifies the same hi-entry. But >> others may prefer the current description, in which case we can retain >> it. >> >> The new version of this paragraph is: >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when a non-100, non-2xx SIP response is received to >> the corresponding INVITE, or when a response is received containing >> the hi-entry with a Reason header value, as described in Section >> 9.3. >> [MB] You have dropped the reference to the cache here and that very >> important. I think it's obvious that we >> are dealing with the corresponding INVITE. When we talk about SIP >> responses, we do not qualify it as "the SIP response received to the >> corresponding INVITE". But, it certainly causes no harm. I would >> suggest that sentence read: >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> the receipt of a non-100 or non-2xx SIP response to the >> corresponding INVITE, as described in >> Section 9.3. >> >> [/MB] >> >> If the Reason header value is being added to an hi-targeted-to-uri >> due to receipt of an explicit SIP response to the corresponding >> INVITE and the response contains any Reason header fields (see >> [RFC3326]), then the SIP entity MUST also include the Reason header >> fields in the "headers" component of the hi-targeted-to-uri in the >> corresponding cached hi-entry, unless the hi-targeted-to-uri is a >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Tel-URI. If the SIP response does not contain a Reason header >> field with a protocol of "SIP", the SIP entity MUST include a >> Reason header field, containing the SIP Response Code, in the >> "headers" component of the hi-targeted-to-uri in the corresponding >> cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI. >> >> [MB] Note, you dropped "field" from the "Reason header value above, >> which is not correct. So the real changes I see above are with regards >> to highlighting that it's the corresponding cached hi-entry (rather >> than the last. I have annotated above that that is the only change >> (AFAICT). I can make that change as follows: >> OLD: >> If the Reason header field is being added due to receipt of an >> explicit >> SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. >> >> NEW: >> If the Reason header field is being added due to receipt of an >> explicit >> SIP response to the corresponding INVITE >> ^^^^^^^^^^^^^^^^^^^^^^ >> and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the corresponding cached hi-entry, unless >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> the hi-targeted-to-uri is a Tel-URI. >> [/MB] >> >> There is a slight change here in that if the response contains >> "Reason: Q.850;cause=14", then both the Q.850 response code and the >> SIP response code will be recorded in the cached hi-entry. The >> previous text caused only the Q.850 response code to be recorded. >> [MB] I don't see that the previous text said that only the Q.850 >> response code was recorded. >> The text says that "Reason header fields" as in plural fields are added. >> [/MB] >> >> If a Reason header includes a reason-value with protocol "SIP", that >> reason-value is recorded instead of the response code in the response. >> (This is the same as the previous text.) >> >> ========== >> >>> 2. During the life of the document, there was confusion about how >>> hi-entries were to be organized. The intention of the original writer >>> and the current draft is that hi-entries are accumulated in a cache in >>> the order the entity receives them (in requests and responses), >>> allowing hi-entries that have the *same* index but *different* URIs, >>> and (implicitly) eliminating duplicates. >> >> [MB] It wasn't just the original author and the current author, this >> has been the intent of >> the document and the approach was agreed by the WG. Certainly, there were >> some >> errors that might have lead one to believe otherwise, but that was >> never the intent. [/MB] >>> >>> >>> But some people who have worked on the draft (including myself) were >>> for a while mistaken in believing that the hi-entries were to be >>> organized into a tree, and hence the index values needed to be unique, >>> and the History-Info header would list the hi-entries in tree-walking >>> order (technically, "preorder"). The confusion was abetted by there >>> being no examples that distinguish the two techniques. >> >> [MB] I think the confusion is that if everyone supported HI, you would >> get a tree. >> You can still get a somewhat pruned tree using the indices. I think >> the confusion is that the RFC never >> had any intention of defining application behavior. It is merely >> recording what happens at the SIP protocol level. That's it. How an >> application uses the information (whether to build a tree or whatever) >> is out of scope. [/MB] >>> >>> Unfortunately, the -11 draft doesn't eliminate all the remnants of the >>> mistake. I haven't gone through -11 in detail, but "preorder" appears >>> in section 9.2 and section 10.3, so at least those sections describe >>> the accumulation of hi-entries incorrectly. >> >> >> The fix to this issue overlaps the fix for issue #4: >> >>> 4. If a downstream entity that does not support History-Info forks a >>> request to entities that do support History-Info, an entity can >>> receive two hi-entries with the same index that were not generated for >>> the same fork of the request. Conversely, an entity will receive >>> responses that contain hi-entries that are duplicates of entries that >>> are already in the cache. >>> >>> These facts imply that there is a process by which an entity >>> determines whether a received hi-entry is "the same" as an hi-entry >>> already in the cache (and so doesn't need to be added again). Since >>> index values cannot be depended upon to be unique, we really ought to >>> state what the comparison rule is. >>> >>> I think it is sufficient to use the rule "the same index value and the >>> URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the >>> Reason header fields)". This won't always give the result one would >>> want (if a non-supporting downstream element forks the request to two >>> target URIs that ultimately arrive at the same element, two hi-entries >>> could be generated with the same index and URI), but this rule is >>> simple, well-defined, and should work well in almost all situations. >> >> >> In addition, when a response is received, it may contain hi-entries >> that are duplicates of hi-entries already in the cache, except they >> contain Reason header values that are not in the cached hi-entries. I >> believe we intend that the cached hi-entries be updated to include the >> received Reason header values. >> >> The edits to fix these three issues are: >> >> 9.2. Sending a Request with History-Info >> >> When sending a request, a SIP entity MUST include all the hi-entries >> from the cache that was created per Section 9.1. In addition, the >> SIP entity MUST add a new hi-entry to the outgoing request, but the >> SIP entity MUST NOT add the hi-entry to the cache at this time. The >> --------------------------------------------------------------------^ >> Change this sentence to: "The hi-entries in the outgoing request's >> History-Info header are in the order of the hi-entries in the cache, >> which is the order in which they were added to the cache." >> >> [MB] That's fine. And, just for clarification, the statement below is >> the OLD and the one above is the NEW [/MB] >> >> hi-entries in the outgoing request's History-Info header field is the >> preorder of the tree of hi-entries, that is, by the lexicographic >> ordering of the hi-indexes. The new hi-entry is populated as >> follows: >> >> 9.3. Receiving a Response with History-Info or Request Timeouts >> >> Step 1: Add hi-entry to cache >> >> The SIP entity MUST add the hi-entry that was added to the request >> -----------------------------^ >> For clarity insert "to the cache" here, and... >> that received the non-100 response or timed out to the cache, if >> ------------------------------------------------------^^^^^^^^^^^^ >> ... remove "to the cache" here. >> it was not already cached. The hi-entry MUST be added to the >> ----------------------------------^ >> Change this sentence to "If so, the hi-entry MUST be added to the end >> of the cache." >> >> cache in ascending order as indicated by the values in the hi- >> index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 >> but before 1.2.2 or 1.3). >> >> [MB] I can't decipher the changes you are suggesting above. I think I >> see your point. However, >> there is something very subtle here. This is dealing with responses >> and we add the hi-entries once we >> get the response. However, the value of the hi-index actually does >> reflect a chronological order in terms of generating requests. As >> discussed previously, you lose that chronological ordering across >> entities, but for a specific >> SIP entity they do reflect the chronological processing at that >> entity. So, I don't think this is broken. With the cache >> model, we aren't adding them to the cache until we get the response >> even though they were added to the request (in both chronological and >> lexicographical order). >> [/MB] >> >> >> 9.3. Receiving a Response with History-Info or Request Timeouts >> >> Step 3: Add additional hi-entries >> >> The SIP entity MUST also add to the cache any hi-entries received >> in the response that are not already in the cache. This situation >> can occur when the entity that generated the non-100 response >> retargeted the request before generating the response. As per >> Step 1, the hi-entries MUST be added to the cache in ascending >> order as indicated by the values in the hi-index parameters of the >> hi-entries >> >> This paragraph needs more extensive changes: >> [MB] It's not clear to me why you think it needs to be done this way. >> This is still mapping back to the original request sent by a specific >> entity (e.g., Proxy A). I think you are confused by the scenario >> being described. The retargeting was not done by Proxy A that is >> caching the hi-entries. It was done by Proxy B that received the >> request and it retargeted before returning the 1xx response thus there >> is an additional hi-entry that Proxy A should add to its cache. [/MB] >> >> Step 3: Add and update additional hi-entries >> >> The SIP entity MUST also add to the cache any hi-entries received >> in the response that are not already in the cache. This >> can occur when the entity that generated the non-100 response >> retargeted the request before generating the response. Such >> hi-entries MUST be added to the end of the cache in the order >> they appear in the History-Info header field of the response. >> >> If an hi-entry in the response contains Reason header value(s) >> and the matching hi-entry in the cache does not, the Reason >> header value(s) MUST be added to the cached hi-entry. This can >> occur when the hi-entry was added to the cache by a provisional >> response to an INVITE that was further retargeted, and later a >> final response to that INVITE is received. >> >> In these cases, an hi-entry in a response's History-Info header >> field and an hi-entry in the cache are considered matching when >> they have the same index value and the hi-targeted-to-uris are >> equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason >> header fields). >> >> 10.2. Reason in the History-Info Header Field >> >> A Reason header field is added to the "headers" component in an hi- >> targeted-to-uri when the hi-entry is added to the cache based upon >> ----------------------------------------^^^^^^^^ >> change to "added to, or updated within," >> >> the receipt of a non-100 or non-2xx SIP response, as described in >> Section 9.3. [...] >> [MB] Why "updated within"? [/MB] >> >> 10.3. Indexing in the History-Info Header Field >> >> In order to maintain ordering and accurately reflect the retargeting >> of the request, the SIP entity MUST add a hi-index to each hi-entry. >> Per the syntax in Section 5, the hi-index consists of a series of >> nonnegative integer separated by dots (e.g., 1.1.2). Each dot >> reflects a SIP forwarding hop. The nonnegative integer following >> each dot reflects the order in which a request was retargeted at the >> hop. The highest nonnegative integer at each hop reflects the number >> of entities to which the request has been retargeted at the specific >> hop (i.e., the number of branches) at the time that the request >> represented by this hi-entry was generated. Thus, the indexing >> results in a logical tree representation for the history of the >> request and the hi-entries are given in the preorder of the tree. >> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> delete this clause >> [MB] Okay. [/MB] >> >> ========== >> >>> 3. Due to the confusion discussed in #2, we have to consider whether >>> consensus was actually found in the WGLC. >> >> [MB] We had consensus in WGLC. Your comments came well after WG last call >> and after IETF LC. >> >>> We thought we had >>> consensus, but people did not have the same understanding of this >>> aspect of the draft. (Ugh.) >> >> >> This is a procedural issue, not a technical one. I don't see any >> objection to correcting the normative text if everyone who cares >> agrees that the changes express what we intended. (We should check >> this point with the AD.) >> >> [MB] I do not see that we are changing any of the intended normative >> behavior but rather fixing things that didn't quite reflect the >> normative behavior as stated elsewhere (i.e., inconsistencies). [/MB] >> >> ========== >> >>> 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 >>> do not show the History-Info value in the final 200 response to the >>> UAC. This final value would be useful, in particular, because they >>> give further examples of how proxies process History-Info. >> >> >> I was mistaken here: The final 200 response from the example.com >> proxy to the UAC in these examples has the same History-Info as the >> 200 response arriving at the example.com proxy, because there is no >> History-Info information that the proxy knows that is not known to the >> UAS that generated the 200 response. Thus there is nothing >> interesting to document. >> >> ========== >> >>> 6. Interestingly, despite the fact that there can be duplicate index >>> values, when a request is received by a UAS, there is no ambiguity in >>> the history when tracing *back* from the last hi-entry (the one that >>> denotes the UAS). This is because even if this UAS is "down one fork" >>> from a forking non-supporting proxy, none of the hi-entries generated >>> "down the other fork" will be present in the request the UAS sees. >>> >>> This is in contrast to the situation at the UAC, which may see >>> hi-entries with duplicate indexes, and the interpretation of "rc", >>> "mp", and "np" parameters can be ambiguous. >> >> >> This is an interesting observation, but it does not require >> documentation in the RFCs. >> >> ========== >> >>> 7. In example 3.6 message F6 in >>> draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is: >>> >>> 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: >> target=sip:bob%40example.com;cause=408>;\ >>> index=1.3;mp=1.2 >>> History-Info: >> target=sip:bob%40example.com;cause=408>;\ >>> index=1.3.1;rc=1.3 >>> >>> This is what we intend, as it shows both where the index=1.3 URI came >>> from (sip:bob@example.com) as well as why the index=1.3 fork was >>> generated (because sip:carol@example.com failed). But it points out >>> that we need to improve the description in rfc4244bis section 5 of >>> what the values of the "rc" (etc.) parameters are. A naive reader >>> might think "rc=1.2" in the 1.3 entry means that >>> was >>> generated as a contact for . Instead, it means >>> that the 1.3 fork was generated *because* the 1.2 fork returned a >>> response; it was generated *from* the index=1 URI. >>> >>> Actually, the real rules for interpreting "rc" (etc.) are not simple: >> >> [MB] The above is an example, thus the description is not complete. [/MB] >>> >>> >>> 1) If the index-val in the param points to an entry with a Reason >>> header-param whose value is "SIP;cause=3xx" (after removing >>> escaping!), then: >>> - the URI was one of the Contact values in the 3xx response >>> - that response was why the new fork was generated. >>> >>> 2) If the index-val in the param points to the parent of this >>> hi-entry, then: >>> - the URI was generated from the URI of the parent hi-entry >>> - the fork was not generated due to the response from any other fork. >>> >>> 3) If the index-val in the param points to an hi-entry that is not the >>> parent, and that hi-entry does not contain a Reason header-param >>> containing a 3xx status, then: >>> - the URI was generated from the URI of the parent hi-entry >>> - the fork was generated due to the response from the hi-entry with >>> the specified index-val. >>> >>> And this doesn't match the section 5 definition of the value of "rc" >>> (etc.), which is: >>> >>> The "rc" header field parameter contains the value of the >>> hi-index in the hi-entry with an hi-targeted-to-uri that >>> reflects the Request-URI that was retargeted >> >> >> In section 5, these paragraphs need to be revised: >> >> o hi-target-param: An optional parameter reflecting the mechanism by >> which the Request URI captured in the hi-targeted-to-uri in the >> History-Info header field value (hi-entry) was determined. This >> parameter is either an "rc", "mp" or "np" header field parameter, >> which is interpreted as follows: >> >> "rc": The hi-targeted-to-URI represents a change in Request-URI >> while the target user remains the same. This occurs for >> example when user has multiple AoRs as an alias. The "rc" >> header field parameter contains the value of the hi-index in >> the hi-entry with an hi-targeted-to-uri that reflects the >> Request-URI that was retargeted >> >> "mp": The hi-targeted-to-URI represents a user other than the >> target user associated with the Request-URI in the incoming >> request that was retargeted. This occurs when a request is >> statically or dynamically retargeted to another user >> represented by an AoR unassociated with the AoR of the original >> target user. The "mp" header field parameter contains the >> value of the hi-index in the hi-entry with an hi-targeted-to- >> uri that reflects the Request-URI that was retargeted, thus >> identifying the "mapped from" target. >> >> "np": The hi-targeted-to-URI represents that there was no >> change in Request-URI. This would apply for example when a >> proxy merely forwards a request to a next hop proxy and loose >> routing is used. The "np" header field parameter contains the >> value of the hi-index in the hi-entry with an hi-targeted-to- >> uri that reflects the Request-URI that was copied unchanged >> into the request represented by this hi-entry. That value will >> usually be the hi-index of the parent hi-entry of this hi- >> entry. >> >> The revised paragraphs are: >> >> [MB] I don't agree with this proposal - that's way too much detail for >> this section. I believe that the normative >> sections describe how/when you add the "rc" tag which should match >> what you are describing in your new bullets. I will note that this >> section has been updated several times both adding more text and >> reducing the text in this section. What you have proposed for the >> bullets below (i.e., the "rc", "mp" etc.) is some of the level of >> detail we had previously (in the -02). I believe the text you >> suggest is application logic - note that items 2 & 4 describe the "rc" >> scenarios and this wasn't intended to be comprehensive. If you can >> highlight what's missing in those 2 bullets, we can perhaps make some >> changes there. I will note if these suggestions had been made much >> earlier in the process, it would have been much more helpful - much of >> the text you mention has been in the document since around the -02. >> We did several rounds of major edits while developing this document >> both while it was an individual and as a WG document. Note that this >> document became a WG document literally 3 years ago. It's quite >> disruptive to be raising this issues at this stage. [/MB] >> >> [This first paragraph is unchanged:] >> o hi-target-param: An optional parameter reflecting the mechanism by >> which the Request URI captured in the hi-targeted-to-uri in the >> History-Info header field value (hi-entry) was determined. This >> parameter is either an "rc", "mp" or "np" header field parameter, >> which is interpreted as follows: >> >> "rc": The hi-targeted-to-URI represents a change in Request-URI >> while the target user remains the same. This occurs for >> example when user has multiple AoRs as an alias or when >> forwarding the request to a registered contact of an AoR. >> >> "mp": The hi-targeted-to-URI represents a user other than the >> target user associated with the Request-URI in the incoming >> request that was retargeted. This occurs when a request is >> statically or dynamically retargeted to another user >> represented by an AoR unassociated with the AoR of the original >> target user. >> >> "np": The hi-targeted-to-URI represents that there was no >> change in Request-URI. This would apply for example when a >> proxy merely forwards a request to a next hop proxy and loose >> routing is used. The "np" header field parameter contains the >> value of the hi-index in the parent hi-entry of this hi-entry. >> >> If the index-val in the parameter points to the parent hi-entry of >> this >> hi-entry, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was not generated due to the response from any other >> fork. >> >> If the index-val in the parameter points to an hi-entry with a >> Reason >> header value whose protocol is "SIP" and whose cause begins with >> "3", >> then: >> - the URI was one of the Contact values in the 3xx response >> - the fork was generated due to the 3xx response from the hi-entry >> with >> the specified index-val. >> >> If the index-val in the param points to an hi-entry that is not the >> parent, and that hi-entry does not contain a Reason header value >> containing a SIP 3xx cause, then: >> - the URI was generated from the URI of the parent hi-entry >> - the fork was generated due to the response from the hi-entry with >> the specified index-val. >> >> ====================================================================== >> >> I believe that is everything to be done. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Feb 19 14:16: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 D283921E808E for ; Tue, 19 Feb 2013 14:16:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOV6sxWMOIOS for ; Tue, 19 Feb 2013 14:16:42 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECC21F88B9 for ; Tue, 19 Feb 2013 14:16:41 -0800 (PST) Received: from [64.7.84.134] (port=63231 helo=[192.168.11.4]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1U7vUM-0006Vj-WB; Tue, 19 Feb 2013 16:16:39 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 19 Feb 2013 14:16:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: 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.11.4]) [64.7.84.134]:63231 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: SIPCORE , "R.Jesske@telekom.de" , "Dale R. Worley" , Laura Liess 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: Tue, 19 Feb 2013 22:16:42 -0000 Hi Marianne; Thank you for further comments.. My comments inline.. On Feb 14, 2013, at 5:11 AM, = wrote: > Hello, >=20 > Most of my comments have been perfectly addressed but I have still = some concerns with the following changes: >=20 > MM#1 =A73.6 in F3: there is an "mp" tag in a Contact header; I guess = it's a mistake and it should be a History-Info header (as in F4). This is intentional. Per section 4.2.1 of RFC 4244bis regarding = Redirect Server=20 behavior, redirect server would indicate the method a redirect-to = contact was=20 determined.=20 >=20 > MM#2 =A73.6 in F6: The History-Info header is > History-Info: ;index=3D1 = [MM] ok [/MM] > History-Info: ;\ > index=3D1.1;rc=3D1 [MM] ok = [/MM] > History-Info: ;index=3D1.2;mp=3D1 [MM] ok = [/MM] > History-Info: ;\ > index=3D1.2.1;rc=3D1.2 = [MM] nok, it is a cause URI parameter that should be set to "480" (call = deflection) following RFC4458. The Reason header is escaped in the SIP = URI only when it is a real received respond (it is the case with the = 302) [/MM] > History-Info: target=3Dsip:bob%40example.com>;\ > index=3D1.3;mp=3D1 = [MM] nok, The hi-entry with the voicemail should be a copy of the R-URI = so with the cause=3D480 URI parameter. Additionally, the vm is finally = reached because Carol does not reply, so the no reply reason (cause=3D408)= should also be reflected in a cause URI parameter following RFC4458. = Hence, the hi-entry should be History-Info: = ; index=3D1.3;mp=3D1 =3D> Oops, I think we have a = problem... This is due to the fact that at the same time we have = successive forwarding (1 after the other) with Carol at the = second-to-last position and we try to join B's vm (1st diverting user). = IMO, we should add some text stating that depending on which voicemail = is reached (Bob or Carol), the call forwarding reason (Bob or Carol's = diverting reason) in the cause URI parameter should be set accordingly = (to be consistent). Here the target vm is Bob so only cause=3D480 should = be used and Carol's reason for not answering the call is lost. [/MM] > [MM]If someone have a better/other idea, please don't hesitate... = [/MM] > History-Info: target=3Dsip:bob%40example.com>;\ > index=3D1.3.1;rc=3D1.3 = [MM] nok, same comment >=20 > But IMO it should be: >=20 > History-Info: ;index=3D1=20 > History-Info: ;\=20 > index=3D1.1;rc=3D1 =20 > History-Info: ;index=3D1.2;mp=3D1=20 > History-Info: ;\ > index=3D1.2.1;rc=3D1.2=20 > History-Info: target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3;mp=3D1 > History-Info: target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3.1;rc=3D1.3 Ok. Fixed. >=20 > MM#3 =A73.7 in F4 and followings:=20 > In the hi-entry the reason-text has been added.=20 > I have 2 comments:=20 > 1. why adding the reason-text? (and why not ;)=3D> ok for me=20 > 2. if the reason-text is added, it should be "escaped" in the same way = as the cause parameter. =20 > So that, the hi-entry: > History-Info: ;text=3D"Moved Temporarily">\ > ;index=3D1.1;rc=3D1 >=20 > Should be: > History-Info: %3Btext%3D"Moved Temporarily">\ > ;index=3D1.1;rc=3D1 Good catch. Thanks Shida >=20 > Here is my feedback. >=20 > Best Regards, > Marianne >=20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de Paul Kyzivat > Envoy=E9 : vendredi 1 f=E9vrier 2013 23:37 > =C0 : R.Jesske@telekom.de; Laura Liess; MOHALI Marianne OLNC/OLN; = Brett Tate; Dale R. Worley > Cc : SIPCORE > Objet : [sipcore] Verify = draft-ietf-sipcore-rfc4244bis-callflows-02.txt >=20 > A new version of 4244bis-callflows has been published, to address the = comments we received in the WGLC review at the end of last year. >=20 > I've sent this *To* the people who provided comments. > I would appreciate your verifying that your comments were properly = addressed. (Please comment back one way or the other.) >=20 > This is *not* a new WGLC. So please don't bring up *new* issues now. = We are past that. I just want to verify that the comments already raised = have been handled. We are holding the bis to publish concurrently with = the callflows, so is the last thing holding them up. >=20 > Thanks, > Paul >=20 >=20 > -------- Original Message -------- > Subject: [sipcore] I-D Action:=20 > draft-ietf-sipcore-rfc4244bis-callflows-02.txt > Date: Tue, 29 Jan 2013 12:49:12 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: sipcore@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Session Initiation Protocol Core = Working Group of the IETF. >=20 > Title : Session Initiation Protocol (SIP) History-Info = Header=20 > Call Flow Examples > Author(s) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt > Pages : 46 > Date : 2013-01-29 >=20 > Abstract: > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows= -02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Feb 19 15:01:06 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 7126F21F893D for ; Tue, 19 Feb 2013 15:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 5Ix8uOZwdIUl for ; Tue, 19 Feb 2013 15:01:05 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8442D21F891D for ; Tue, 19 Feb 2013 15:00:59 -0800 (PST) Received: from [64.7.84.134] (port=64731 helo=[192.168.11.4]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1U7wBG-00071w-Uj; Tue, 19 Feb 2013 17:00:59 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88035C71@MBX06.citservers.local> Date: Tue, 19 Feb 2013 15:00:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <01BF7006-8F09-4A86-98A7-F39CD4B11C4D@ntt-at.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88035C71@MBX06.citservers.local> To: Brett Tate 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.11.4]) [64.7.84.134]:64731 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: SIPCORE 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: Tue, 19 Feb 2013 23:01:06 -0000 Hi Brett; Thanks for further comments.=20 My comments inline. On Feb 9, 2013, at 11:50 AM, Brett Tate wrote: > Howdy, >=20 > Most of my comments have been adequately addressed. >=20 > Thanks, > Brett >=20 > ----- >=20 > Concerning my various comments to include Max-Forwards, the values are = good enough for me; however I was surprised to see some of the = decrementing and initial values. For instance, section 3.1 F5 and F13 = contain initial values within ACK reflecting the related INVITE instead = of 70. And for instance, section 3.1 F6 and F9 reflect the proxy = decrementing the value again for INVITE sent to new location because of = 302 or timeout. My bad. Will fix these.=20 >=20 > If not intentional, the figure labels are of the format "Figure 1: = Figure 1." and not consistently located (i.e. before or after detailed = messages). I will fix these as well.=20 >=20 > Section 3.2 F3: top Via received should be on the second via. Thanks for the catch. Done.=20 >=20 > Section 3.4 picture: 302 ACK arrow reflection wrong source. The same = applies to sections 3.6 and 3.7. Thanks. Done. >=20 > Concerning = http://www.ietf.org/mail-archive/web/sipcore/current/msg05265.html = comment 2, section 3.5 was not modified; thus I'll assume that the = transport switch from UDP to TCP was intentional (i.e. registered UDP = Contact but INVITE sent over TCP). I must have overlooked this.. Fixed.=20 >=20 > Section 3.9 F2: Added Max-Forwards to response. Thanks. Fixed. Regards Shida >=20 > New comment (if want to address): figure 1 indicates a "retransmit = INVITE" with arrow after having received a 180.=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Feb 19 19:26: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 A61CD21F88B9 for ; Tue, 19 Feb 2013 19:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 p1k+J4Q2ku-r for ; Tue, 19 Feb 2013 19:26:53 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D09FF21F888B for ; Tue, 19 Feb 2013 19:26:53 -0800 (PST) Received: from [64.7.84.134] (port=57363 helo=[192.168.11.4]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1U80Ka-0000gd-Tg; Tue, 19 Feb 2013 21:26:52 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201302042053.r14KrZ9j1204625@shell01.TheWorld.com> Date: Tue, 19 Feb 2013 19:26:51 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5EB99B90-9711-4865-88CE-C4F50FB08E39@ntt-at.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <201302042053.r14KrZ9j1204625@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.11.4]) [64.7.84.134]:57363 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: Wed, 20 Feb 2013 03:26:55 -0000 Hi Dale; Thanks for further comments.. On Feb 4, 2013, at 12:53 PM, Dale R. Worley wrote: > My previous comments have been addressed acceptably. But there are a > few new nits that I've spotted: > > ** General > > * On page 19 > > Alice example.com Gold Silver Agent > > | | | | | > | INVITE F1 | | | | > |------------->| | | | > | | | | | > | | INVITE F2 | | | > | |------------->| | | > | | | | | > | | 302 Moved Temporarily F3 | | > | |<-------------| | | > | | | | | > | ACK | | | > |---------------------------->| | | > | | | | | > > The ACK should be shown thus: > > | | | | | > | | ACK | | | > | |------------->| | | > | | | | | > > * On page 27, the top ACK should be shown thus: > > | | | | | > | | ACK | | | > | |------------->| | | > | | | | | > > * On page 31, the top ACK should be shown thus: > > | | | | | > | | ACK | | | > | |------------->| | | > | | | | | > > * On page 40, there are two occurrences of: > > To: ;gr> > > "sip:sip:" should be replaced with "sip:". DONE. > > ** http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html > > * "5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 > do not show the History-Info value in the final 200 response to the > UAC. This final value would be useful, in particular, because they > give further examples of how proxies process History-Info." > > In neither of these examples is the final 200 response shown. I > assume that this is the authors' intention. This, I think was because the value of h-i would not change from the last proxy to UAC, and didn't see a need. If you want to see this added. I will add them > > ** http://www.ietf.org/mail-archive/web/sipcore/current/msg05429.html > > * "But in draft-ietf-sipcore-rfc4244bis-callflows-01, Reason header > values for 1xx responses are not generated. See message F8 in section > 3.1." > > rfc4244bis-callflows-02 does not show Reason headers with 1xx values. > I expect this is because the authors intend for this to be how > History-Info operates. But that does mean we are committed to > updating rfc4244bis to state that (because it currently says that 1xx > responses set Reason headers). Okay, I will add these. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From worley@shell01.TheWorld.com Wed Feb 20 07:43:07 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 1AA1621F87BA for ; Wed, 20 Feb 2013 07:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.317, 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 nCm9eFhLfqLh for ; Wed, 20 Feb 2013 07:43:06 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 23BEB21F883B for ; Wed, 20 Feb 2013 07:43:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1KFgs4l023864; Wed, 20 Feb 2013 10:42:57 -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 r1KFgsiM2208980; Wed, 20 Feb 2013 10:42:54 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1KFgrE02210959; Wed, 20 Feb 2013 10:42:53 -0500 (EST) Date: Wed, 20 Feb 2013 10:42:53 -0500 (EST) Message-Id: <201302201542.r1KFgrE02210959@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Shida Schubert In-reply-to: <5EB99B90-9711-4865-88CE-C4F50FB08E39@ntt-at.com> (shida@ntt-at.com) References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <201302042053.r14KrZ9j1204625@shell01.TheWorld.com> <5EB99B90-9711-4865-88CE-C4F50FB08E39@ntt-at.com> 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: Wed, 20 Feb 2013 15:43:07 -0000 > From: Shida Schubert [everything you write is fine with me] > > * "5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 > > do not show the History-Info value in the final 200 response to the > > UAC. This final value would be useful, in particular, because they > > give further examples of how proxies process History-Info." > > > > In neither of these examples is the final 200 response shown. I > > assume that this is the authors' intention. > > This, I think was because the value of h-i would not change from > the last proxy to UAC, and didn't see a need. If you want to see this > added. I will add them I agree that there is no need. I believe I was under a misapprehension when I wrote point 5. Dale From marianne.mohali@orange.com Wed Feb 20 07:45: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 E14C221F8810 for ; Wed, 20 Feb 2013 07:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 xGZVMvUlle8v for ; Wed, 20 Feb 2013 07:45:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB421F87E4 for ; Wed, 20 Feb 2013 07:44:59 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 886E222CDA1; Wed, 20 Feb 2013 16:44:57 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6096827C046; Wed, 20 Feb 2013 16:44:57 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 20 Feb 2013 16:44:56 +0100 From: To: "Dale R. Worley" Thread-Topic: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt Thread-Index: AQHOAMyZ06RJPrxNn0imU//2fV42V5h4a0gwgAfKxVeAAn6fQA== Date: Wed, 20 Feb 2013 15:44:56 +0000 Message-ID: <12124_1361375097_5124EF79_12124_5_1_8B970F90C584EA4E97D5BAAC9172DBB80BD7E7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> <201302182105.r1IL5tD22082001@shell01.TheWorld.com> In-Reply-To: <201302182105.r1IL5tD22082001@shell01.TheWorld.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" , "laura.liess.dt@googlemail.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: Wed, 20 Feb 2013 15:45:06 -0000 Hi Dale, See my answer inline [MM2] Marianne > -----Message d'origine----- > De=A0: Dale R. Worley [mailto:worley@ariadne.com] > Envoy=E9=A0: lundi 18 f=E9vrier 2013 22:06 > =C0=A0: MOHALI Marianne OLNC/OLN > Cc=A0: pkyzivat@alum.mit.edu; R.Jesske@telekom.de; > laura.liess.dt@googlemail.com; brett@broadsoft.com; sipcore@ietf.org > Objet=A0: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows- > 02.txt >=20 > > From: > > Subject: RE: [sipcore] Verify > > draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > > > MM#1 B'3.6 in F3: there is an "mp" tag in a Contact header; I guess > > it's a mistake and it should be a History-Info header (as in F4). >=20 > No, that's to show that the contact was > generated by "mapping" from the URI with index 1, . > This is described in 4244bis section 8. > (There are a number of such Contact headers in the callflows.) >=20 [MM2] Right, my mistake > > MM#2 B'3.6 in F6: The History-Info header is > > History-Info: ;index=3D1 [MM] ok [/MM] > > History-Info: ;\ > > index=3D1.1;rc=3D1 [MM] ok [/MM] > > History-Info: ;index=3D1.2;mp=3D1 [MM] ok [/MM] > > History-Info: ;\ > > index=3D1.2.1;rc=3D1.2 > > [MM] nok, it is a cause URI parameter that should be set to "480" > > (call deflection) following RFC4458. The Reason header is escaped in > > the SIP URI only when it is a real received respond (it is the case > > with the 302) [/MM] >=20 > I believe the cause is supposed to be 408 (Timeout) rather than 480, > and it is correct for the proxy to synthesize a 408 cause here because > of 4244bis section 10.2 paragraph 2. (And many SIP systems treat > timing out while waiting for a response as if they received an explicit > 408 response.) >=20 > This mistake of 480 for 408 is also present in the request-line of F6 > and the History-Info of F7. >=20 > (Confusion can easily arise because 480 (Temporarily Unavailable) is > also a plausible cause for diversion to VM.) >=20 [MM2] No, there is no mistake in the code, the correction were done after o= ne of my comments. Here we are in a Call Deflection immediate response situ= ation (as defined in TS24.604) and the cause URI parameter value to be used= and defined in RFC4458 is 480. My point was about the format which is a [R= eason header's cause parameter] format instead of the [cause URI parameter]= format in the URI. The line should be: History-Info: ;\ index=3D1.2.1;rc=3D1.2=20 >From RFC4458 +---------------------------------+-------+ | Redirecting Reason | Value | +---------------------------------+-------+ | Unknown/Not available | 404 | | User busy | 486 | | No reply | 408 | | Unconditional | 302 | | Deflection during alerting | 487 | | Deflection immediate response | 480 | | Mobile subscriber not reachable | 503 | +---------------------------------+-------+ > > History-Info: > target=3Dsip:bob%40example.com>;\ > > index=3D1.3;mp=3D1 > > [MM] nok, The hi-entry with the voicemail should be a copy of the > > R-URI so with the cause=3D480 URI parameter. Additionally, the vm is > > finally reached because Carol does not reply, so the no reply reason > > (cause=3D408) should also be reflected in a cause URI parameter > > following RFC4458. Hence, the hi-entry should be History-Info: > > ; > > index=3D1.3;mp=3D1 =3D> Oops, I think we have a problem... This is due= to > > the fact that at the same time we have successive forwarding (1 after > > the other) with Carol at the second-to-last position and we try to > > join B's vm (1st diverting user). IMO, we should add some text > stating > > that depending on which voicemail is reached (Bob or Carol), the call > > forwarding reason (Bob or Carol's diverting reason) in the cause URI > > parameter should be set accordingly (to be consistent). Here the > > target vm is Bob so only cause=3D480 should be used and Carol's reason > > for not answering the call is lost. [/MM] [MM]If someone have a > > better/other idea, please don't hesitate... [/MM] >=20 > Beware that message F6 does not correspond to entry 1.3 but rather to > entry 1.3.1, which is derived from 1.3 by internal redirection. (It > might be worth adding a note in the text to warn the reader!) So it is > entry 1.3.1 that must have the cause parameter, to match the request- > URI. >=20 > However, since the 1.3.1 request-URI has a cause parameter, it is > likely that 1.3 request-URI has the same cause parameter. >=20 > The messier problem is not really present. There is only one cause at > this point, the implicit 408 response from Carol. And there may be > complexities concerning what the diversion URI should be, but that is > the proxy's problem, not a problem in designing 4244bis, and we do not > have to solve it here, we only have to show the History-Info that comes > from this particular proxy's decisions. >=20 [MM2] OK, so the following hi-entry (index=3D1.3.1) must contain a cause UR= I parameter set to "cause=3D408" (removed from the draft-01 version) > > History-Info: > target=3Dsip:bob%40example.com>;\ > > index=3D1.3.1;rc=3D1.3 > > [MM] nok, same comment > > > > But IMO it should be: > > > > 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;cause=3D480>;\ > > index=3D1.3;mp=3D1 > > History-Info: > target=3Dsip:bob%40example.com;cause=3D480>;\ > > index=3D1.3.1;rc=3D1.3 > > > > MM#3 B'3.7 in F4 and followings: > > In the hi-entry the reason-text has been added. > > I have 2 comments: > > 1. why adding the reason-text? (and why not ;)=3D> ok for me 2. if the > > reason-text is added, it should be "escaped" in the same way as the > > cause parameter. > > So that, the hi-entry: > > History-Info: > ;text=3D"Moved Temporarily">\ > > ;index=3D1.1;rc=3D1 > > > > Should be: > > History-Info: > %3Btext%3D"Moved Temporarily">\ > > ;index=3D1.1;rc=3D1 >=20 > The header field as it stands is: >=20 > History-Info: ;text=3D"Moved Temporarily">\ > ;index=3D1.1;rc=3D1 >=20 > but the escaping is incorrect. The Reason header would be: >=20 > Reason: SIP;cause=3D302;text=3D"Moved Temporarily" >=20 > so the 'hname' is 'Reason' and the 'hvalue' is > 'SIP;cause=3D302;text=3D"Moved Temporarily"', so the URI should be >=20 > rily%34> >=20 > There are 4 instances of this problem, in 3.7 F4, F5, F6, and F7 >=20 [MM2] Exact! > Dale [MM2]Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From worley@shell01.TheWorld.com Wed Feb 20 07:45:12 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 A9AC321F8883 for ; Wed, 20 Feb 2013 07:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.303, 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 0YariMh8mFy4 for ; Wed, 20 Feb 2013 07:45:12 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45621F8833 for ; Wed, 20 Feb 2013 07:45:08 -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 r1KFioBJ005976; Wed, 20 Feb 2013 10:44:52 -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 r1KFio9c2209625; Wed, 20 Feb 2013 10:44:50 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1KFio8R2196886; Wed, 20 Feb 2013 10:44:50 -0500 (EST) Date: Wed, 20 Feb 2013 10:44:50 -0500 (EST) Message-Id: <201302201544.r1KFio8R2196886@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Mary Barnes In-reply-to: (mary.ietf.barnes@gmail.com) References: <201302061509.r16F90sh016532@freeze.ariadne.com> <5123AD43.2080400@alum.mit.edu> Cc: sipcore@ietf.org Subject: Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:45:12 -0000 > From: Mary Barnes > > On Tue, Feb 19, 2013 at 10:50 AM, Paul Kyzivat wrote: > > > > This is very hard to follow. > > But I do get it that the two of you are getting closer but still not in > > total agreement. Can the two of you reach a mutually satisfactory > > conclusion? Sorry about how messy the discussion has gotten. But the two of us do understand what the proposed changes are about and we're trying to get them settled as quickly as possible. > > I'd love to have a new version with a direct diff to evaluate it all. > > > > I must say that I am surprised that so much effort was put into the > > hierarchical numbering scheme for entries and yet the conclusion is that the > > entries are not sorted in accord with this hierarchy. (Or did I get that > > wrong?) > > [MB] As I highlighted to Dale, within an entity they are in order. > The issue is due to the fact that not all entities will support HI, > thus you cannot guarantee that the lexicographical order is meaningful > (amongst all the entities). Since we do require an entity to add the > entries in chronological order using the indexing scheme as specifed > they are in order for that entity. When the request is forwarded and > a response contains additional hi-entires (due to retargeting at the > next hop), the ordering is guaranteed for the entity to which the > request was forwarded. The issue comes when you get a reset to 0 > indicating an entity did not support HI, then you lose any ordering. > [/MB] There are some unusual, tricky cases where the hi-entries in an entity's cache won't be in lexicographic order. They involve parallel forking, where the processing on each fork sends back multiple 1xx provisional responses carrying additional retargetings. But in ordinary cases, adding to the cache sequentially/chronologically is *much* easier to specify than specifying the processing that would keep lexicographic ordering in all cases. As Mary points out, the problem is with forking by non-supporting intermediate entities, which results in duplicate index values (containing "0"), so you can't just sort by the index values. (There additional hacks that could get around this problem in most cases, but the additional complexity suggests that the chronological approach is simpler.) The penalty is that in parallel forking cases where the forking proxy is non-supporting, the application logic at the *UAC* end may not be able to reliably reconstruct the forking structure, due to the duplicate index values and the interleaving of responses from the parallel forks. However (I mention this in a note buried in my earlier message), at the *UAS* end, this messiness isn't seen: A UAS won't see hi-entries that come from sister forks originating at a non-supporting proxy, and so its interpretation of the History-Info won't be corrupted. And it is the interpretation by the UAS that we really care about. Dale From oferg@avaya.com Wed Feb 20 09:54: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 6164021F8759 for ; Wed, 20 Feb 2013 09:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599] 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 cy3S5mCNrQsr for ; Wed, 20 Feb 2013 09:54:39 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3328821F86CE for ; Wed, 20 Feb 2013 09:54:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP0QA1GHCzI1/2dsb2JhbABFvlIWc4IeAQEBAQMSKD8MBAIBCA0EBAEBCxQJBzIUCQgCBA4FCBqHbaFknHSNFINKYQOcGoo7gneBbzU X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="49575331" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Feb 2013 12:52:32 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Feb 2013 12:53:39 -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; Wed, 20 Feb 2013 19:53:52 +0200 From: Ofer Goren To: "Roy, Radhika R CIV USARMY (US)" Thread-Topic: question about B2B and Forking (UNCLASSIFIED) Thread-Index: AQHODrQ3VbbqTE922EiLXQTjY9/sy5iDCEyg Date: Wed, 20 Feb 2013 17:53:50 +0000 Message-ID: References: <8486C8728176924BAF5BDB2F7D7EEDDF490A18E1@ucolhp9l.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF490A18E1@ucolhp9l.easf.csd.disa.mil> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] question about B2B and Forking (UNCLASSIFIED) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:54:41 -0000 Hi Roy. This is exactly my question: is it needed. It looks like it might be, but I= cannot understand why would anybody wants to do that. It either a B2BUA, i= n that case it holds a state machine for each call created on each side, OR= it is a proxy forwarding transactions from side to side. I don't understan= d why anyone would like to mix the behavior, but I can't find anything in t= he specs prohibit it. Ofer. -----Original Message----- From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil]=20 Sent: Tuesday, February 19, 2013 5:18 PM To: Ofer Goren Cc: sipcore@ietf.org Subject: RE: question about B2B and Forking (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Ofer: In this case it not B2BUA spec per se. It will be rather specific to "Forking Specifications using B2BUA." If we want to have a interoperable implementation of forking using B2BUA. Is it really needed? BR/Radhika -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Ofer Goren Sent: Tuesday, February 19, 2013 8:02 AM To: sipcore@ietf.org Subject: [sipcore] question about B2B and Forking Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it forward downstream all the provisional responses to the generating UAC? Or, should it forward only one," absorbing" the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creates several early dialogs for which it should also handle transactions such as PRACK (in case of reliable provisional responses), or UPDATEs and such.=20 =20 So what do you think a B2B should do? =20 Thanks! Ofer =20 =20 _______________________________________________________________ If you lend someone $20, and never see that person again, it was probably worth the investment.=20 =20 =20 Classification: UNCLASSIFIED Caveats: NONE From oferg@avaya.com Wed Feb 20 10:00:01 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 3296921F88BD for ; Wed, 20 Feb 2013 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HQyEumQCstl8 for ; Wed, 20 Feb 2013 09:59:47 -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 2400F21F888A for ; Wed, 20 Feb 2013 09:59:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP0QA1GHCzI1/2dsb2JhbABFgki8ChZzgh4BAQEBAxIbXAIBCA0EBAEBCx0HMhQJCAEBBAESCBqHbaFknHSQXmEDnBqKO4J3giQ X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208,217";a="344453721" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Feb 2013 13:02:14 -0500 Received: from unknown (HELO rvil-mail2010.RADVISION.com) ([172.20.2.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Feb 2013 12:58:43 -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; Wed, 20 Feb 2013 19:58:56 +0200 From: Ofer Goren To: Brett Tate , "sipcore@ietf.org" Thread-Topic: question about B2B and Forking Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpwAB6S5AAJhrbBA= Date: Wed, 20 Feb 2013 17:58:56 +0000 Message-ID: References: <576A8B541C219D4E9CEB1DF8C19C7B8819697E23@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B8819697E23@MBX06.citservers.local> 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_D9AD3D1627F52341B829F32E6DDE089149E0CAF6rvilmail2010_" MIME-Version: 1.0 Subject: Re: [sipcore] question about B2B and Forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:00:12 -0000 --_000_D9AD3D1627F52341B829F32E6DDE089149E0CAF6rvilmail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brett. Why do you think those 3 RFCs suggest that B2BUAs should act as proxies for= UPDATE and 18x reliable responses? I'm not sure I follow. Ofer From: Brett Tate [mailto:brett@broadsoft.com] Sent: Sunday, February 17, 2013 7:30 PM To: Ofer Goren; sipcore@ietf.org Subject: RE: question about B2B and Forking Hi Ofer, The appropriate behavior depends upon the functionality that the B2BUA is p= roviding. Within normal call originations with devices compliant to RFC 3261, RFC 326= 2, and RFC 3311, it is typically best to act more like a proxy. However since there are still devices that don't support RFC 3262, RFC 3311= , or forking proxies, the B2BUA might have to act differently for interoper= ability reasons. Similarly, the B2BUA may need to act differently for serv= ice reasons. From: sipcore-bounces@ietf.org [mailto:sip= core-bounces@ietf.org] On Behalf Of Ofer Goren Sent: Sunday, February 17, 2013 11:23 AM To: sipcore@ietf.org Subject: [sipcore] question about B2B and Forking Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it f= orward downstream all the provisional responses to the generating UAC? Or, = should it forward only one," absorbing" the rest? Should it even wait for p= rovisional responses, or should it generates its own toward the UAC, indepe= ndent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creat= es several early dialogs for which it should also handle transactions such = as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer --_000_D9AD3D1627F52341B829F32E6DDE089149E0CAF6rvilmail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brett.

 

Why do you think those= 3 RFCs suggest that B2BUAs should act as proxies for UPDATE and 18x reliab= le responses? I’m not sure I follow.

 

Ofer

 

From: Brett Ta= te [mailto:brett@broadsoft.com]
Sent: Sunday, February 17, 2013 7:30 PM
To: Ofer Goren; sipcore@ietf.org
Subject: RE: question about B2B and Forking

 

Hi Ofer,

 

The appropriate behavi= or depends upon the functionality that the B2BUA is providing.

 

Within normal call ori= ginations with devices compliant to RFC 3261, RFC 3262, and RFC 3311, it is= typically best to act more like a proxy.

 

However since there ar= e still devices that don’t support RFC 3262, RFC 3311, or forking pro= xies, the B2BUA might have to act differently for interoperability reasons.=   Similarly, the B2BUA may need to act differently for service reasons.

 

 

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: Sunday, February 17, 2013 11:23 AM
To: sipcore@ietf.org
Subject: [sipcore] question about B2B and Forking<= /p>

 

Hi All.

I know B2B behavior is not defined with too much det= ails in the relevant SIP RFCs. I do ask for your opinion:

In forking scenarios, if B2B forks an INVITE to seve= ral UAS-es, should it forward downstream all the provisional responses to t= he generating UAC? Or, should it forward only one,” absorbing” = the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to t= he upstream side of the session?

If it should forward all provisional responses downs= tream, it in fact creates several early dialogs for which it should also ha= ndle transactions such as PRACK (in case of reliable provisional responses)= , or UPDATEs and such.

 

So what do you think a B2B should do?

 

Thanks!

Ofer

 

--_000_D9AD3D1627F52341B829F32E6DDE089149E0CAF6rvilmail2010_-- From brett@broadsoft.com Wed Feb 20 10:31:31 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 8393F21F875F for ; Wed, 20 Feb 2013 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rfcBBo9quMNC for ; Wed, 20 Feb 2013 10:31:29 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id A030921F8511 for ; Wed, 20 Feb 2013 10:31:29 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 20 Feb 2013 10:33:15 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 20 Feb 2013 10:33:15 -0800 From: Brett Tate To: Ofer Goren , "sipcore@ietf.org" Thread-Topic: question about B2B and Forking Thread-Index: Ac4NKiN6+I0c9/87S0qOu8XJfpZbpwAB6S5AAJhrbBAAADiC8A== Date: Wed, 20 Feb 2013 18:33:13 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881969A535@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B8819697E23@MBX06.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: multipart/alternative; boundary="_000_576A8B541C219D4E9CEB1DF8C19C7B881969A535MBX06citservers_" MIME-Version: 1.0 Subject: Re: [sipcore] question about B2B and Forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:31:31 -0000 --_000_576A8B541C219D4E9CEB1DF8C19C7B881969A535MBX06citservers_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't. I indicated that it is typically best for B2BUA to act more like = a proxy (i.e. to avoid breaking things that work with proxies) unless there= are service or interoperability reasons to do otherwise. The following STRAW draft may be interest to you since there are all kinds = of B2BUAs: draft-ietf-straw-b2bua-taxonomy. From: Ofer Goren [mailto:oferg@avaya.com] Sent: Wednesday, February 20, 2013 12:59 PM To: Brett Tate; sipcore@ietf.org Subject: RE: question about B2B and Forking Hi Brett. Why do you think those 3 RFCs suggest that B2BUAs should act as proxies for= UPDATE and 18x reliable responses? I'm not sure I follow. Ofer From: Brett Tate [mailto:brett@broadsoft.com] Sent: Sunday, February 17, 2013 7:30 PM To: Ofer Goren; sipcore@ietf.org Subject: RE: question about B2B and Forking Hi Ofer, The appropriate behavior depends upon the functionality that the B2BUA is p= roviding. Within normal call originations with devices compliant to RFC 3261, RFC 326= 2, and RFC 3311, it is typically best to act more like a proxy. However since there are still devices that don't support RFC 3262, RFC 3311= , or forking proxies, the B2BUA might have to act differently for interoper= ability reasons. Similarly, the B2BUA may need to act differently for serv= ice reasons. From: sipcore-bounces@ietf.org [mailto:sip= core-bounces@ietf.org] On Behalf Of Ofer Goren Sent: Sunday, February 17, 2013 11:23 AM To: sipcore@ietf.org Subject: [sipcore] question about B2B and Forking Hi All. I know B2B behavior is not defined with too much details in the relevant SI= P RFCs. I do ask for your opinion: In forking scenarios, if B2B forks an INVITE to several UAS-es, should it f= orward downstream all the provisional responses to the generating UAC? Or, = should it forward only one," absorbing" the rest? Should it even wait for p= rovisional responses, or should it generates its own toward the UAC, indepe= ndent to the upstream side of the session? If it should forward all provisional responses downstream, it in fact creat= es several early dialogs for which it should also handle transactions such = as PRACK (in case of reliable provisional responses), or UPDATEs and such. So what do you think a B2B should do? Thanks! Ofer --_000_576A8B541C219D4E9CEB1DF8C19C7B881969A535MBX06citservers_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t.  I= indicated that it is typically best for B2BUA to act more like a proxy (i.= e. to avoid breaking things that work with proxies) unless there are servic= e or interoperability reasons to do otherwise.

 

The following STRAW dr= aft may be interest to you since there are all kinds of B2BUAs: draft-ietf-= straw-b2bua-taxonomy.

 

 

 

From: Ofer Gor= en [mailto:oferg@avaya.com]
Sent: Wednesday, February 20, 2013 12:59 PM
To: Brett Tate; sipcore@ietf.org
Subject: RE: question about B2B and Forking

 

Hi Brett.

 

Why do you think those= 3 RFCs suggest that B2BUAs should act as proxies for UPDATE and 18x reliab= le responses? I’m not sure I follow.

 

Ofer

 

From: Brett Ta= te [mailto:brett@broadsoft.com]
Sent: Sunday, February 17, 2013 7:30 PM
To: Ofer Goren; sipcore@ietf.org=
Subject: RE: question about B2B and Forking

 

Hi Ofer,

 

The appropriate behavi= or depends upon the functionality that the B2BUA is providing.

 

Within normal call ori= ginations with devices compliant to RFC 3261, RFC 3262, and RFC 3311, it is= typically best to act more like a proxy.

 

However since there ar= e still devices that don’t support RFC 3262, RFC 3311, or forking pro= xies, the B2BUA might have to act differently for interoperability reasons.=   Similarly, the B2BUA may need to act differently for service reasons.

 

 

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: Sunday, February 17, 2013 11:23 AM
To: sipcore@ietf.org
Subject: [sipcore] question about B2B and Forking<= /p>

 

Hi All.

I know B2B behavior is not defined with too much det= ails in the relevant SIP RFCs. I do ask for your opinion:

In forking scenarios, if B2B forks an INVITE to seve= ral UAS-es, should it forward downstream all the provisional responses to t= he generating UAC? Or, should it forward only one,” absorbing” = the rest? Should it even wait for provisional responses, or should it generates its own toward the UAC, independent to t= he upstream side of the session?

If it should forward all provisional responses downs= tream, it in fact creates several early dialogs for which it should also ha= ndle transactions such as PRACK (in case of reliable provisional responses)= , or UPDATEs and such.

 

So what do you think a B2B should do?

 

Thanks!

Ofer

 

--_000_576A8B541C219D4E9CEB1DF8C19C7B881969A535MBX06citservers_-- From worley@shell01.TheWorld.com Wed Feb 20 12:50:03 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 9F24121E8039 for ; Wed, 20 Feb 2013 12:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=0.297, 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 gqEOM3quj-VI for ; Wed, 20 Feb 2013 12:50:03 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CE03721E8037 for ; Wed, 20 Feb 2013 12:50:02 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1KKnOuR020821; Wed, 20 Feb 2013 15:49:26 -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 r1KKnO4M2226935; Wed, 20 Feb 2013 15:49:24 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1KKnNqP2228854; Wed, 20 Feb 2013 15:49:23 -0500 (EST) Date: Wed, 20 Feb 2013 15:49:23 -0500 (EST) Message-Id: <201302202049.r1KKnNqP2228854@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: In-reply-to: <12124_1361375097_5124EF79_12124_5_1_8B970F90C584EA4E97D5BAAC9172DBB80BD7E7@PEXCVZYM12.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> <201302182105.r1IL5tD22082001@shell01.TheWorld.com> <12124_1361375097_5124EF79_12124_5_1_8B970F90C584EA4E97D5BAAC9172DBB80BD7E7@PEXCVZYM12.corporate.adroot.infra.ftgroup> Cc: sipcore@ietf.org, R.Jesske@telekom.de, laura.liess.dt@googlemail.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: Wed, 20 Feb 2013 20:50:03 -0000 The History-Info shown in example 3.6 F6 (of the -02 version) is: 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 In regard to this example Marianne Mohali has written (and I have heavily abridged): > From: > [MM2] No, there is no mistake in the code, the correction were done > after one of my comments. Here we are in a Call Deflection immediate > response situation (as defined in TS24.604) and the cause URI > parameter value to be used and defined in RFC4458 is 480. My point > was about the format which is a [Reason header's cause parameter] > format instead of the [cause URI parameter] format in the URI. > > The line should be: > History-Info: ;\ > index=1.2.1;rc=1.2 > > >From RFC4458 > +---------------------------------+-------+ > | Redirecting Reason | Value | > +---------------------------------+-------+ > | Unknown/Not available | 404 | > | User busy | 486 | > | No reply | 408 | > | Unconditional | 302 | > | Deflection during alerting | 487 | > | Deflection immediate response | 480 | > | Mobile subscriber not reachable | 503 | > +---------------------------------+-------+ > [MM2] OK, so the following hi-entry (index=1.3.1) must contain a > cause URI parameter set to "cause=408" (removed from the draft-01 > version) As I understand them, the suggestions are: The target sip:carol@example.com (index 1.2) is generated from sip:bob@example.com by "deflection immediate response", and so that URI should be augmented with the parameter cause=480. I assume that parameter is carried into the hi-entry 1.2.1. (It is not clear to me whether RFC 4458 applies exactly here, since the deflection is not directly to voicemail but rather to Carol. However, it seems that the intention of RFC 4458 is to describe how to mark deflections to targets other than VM as well. Probably comparison with PSTN operation is the way to resolve this question.) The target sip:vm@example.com (index 1.3) is generated from sip:bob@example.com due to timeout of the INVITE to sip:carol@192.0.2.4 (index 1.2.1). So hi-entry 1.2.1 gets "?Reason=SIP%3Bcause%3D408" and hi-entry 1.3 gets a URI parameter ";cause=408". I assume that parameter is carried into the hi-entry 1.3.1. If I haven't made any mistakes, the marked changes need to be made: 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 These changes need to be made to these hi-entries wherever they appear in the example, except the "Reason=SIP%3Bcause%3D408" for 1.2.1 only appears in F6 and F7. Also, in F3, the Contact header becomes: Contact: ;mp=1 Additionally, the last paragraph of the description of 3.6 seems to have a damaged sentence: Furthermore it is the proxy forwarding the call to VMS that determines the target of the voicemail, it is the proxy that sets the target of voicemail which is also the entity that utilizes RFC4244bis to find the target which is usually based on local policy installed by the user or an administrator. It might be helpful to add this note at F4: F4 INVITE Example.com -> Carol Because the call was forwarded from Bob to Carol due to "deflection immediate response", the URI parameter "cause=480" was added to Carol's AOR per [RFC448]. That parameter was carried through to Carol's contact URI during internal retargeting. INVITE sip:carol@192.0.2.4 SIP/2.0 ... Dale From worley@shell01.TheWorld.com Wed Feb 20 12:50: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 6733F21E8039 for ; Wed, 20 Feb 2013 12:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=0.291, 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 0uBEoPQ4xGoN for ; Wed, 20 Feb 2013 12:50:04 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CB49121E8037 for ; Wed, 20 Feb 2013 12:50:03 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1KKnids021624 for ; Wed, 20 Feb 2013 15:49:46 -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 r1KKniPC2221929 for ; Wed, 20 Feb 2013 15:49:44 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1KKniGa2212191; Wed, 20 Feb 2013 15:49:44 -0500 (EST) Date: Wed, 20 Feb 2013 15:49:44 -0500 (EST) Message-Id: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02: "Reason" placement X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:50:04 -0000 In draft-ietf-sipcore-rfc4244bis-callflows-02, I find the following inconsistency. Could people please advise me what the correct usage is? When a non-2xx final response is received by a proxy (or synthesized, in the case of timeouts), the response code is to be placed in the Reason header value in an hi-entry. It turns out that there are two plausible choices: One place is the hi-entry corresponding to the INVITE that was sent by the proxy and which matches the response received, the "next hop" location. The other place is the hi-entry which is the address of the UA which generated the response, the "leaf" location. draft-ietf-sipcore-rfc4244bis-callflows-02 is not rich in failure responses, but there are these examples, with the corresponding hi-entries for the failed fork: 3.1. Sequentially Forking (History-Info in Response) History-Info: ;index=1.2;mp=1 History-Info: ;\ index=1.2.1;index=1.2.1;rc=1.2 3.6. PBX Voicemail Example History-Info: ;index=1.2;mp=1 History-Info: ;\ index=1.2.1;rc=1.2 3.7. Consumer Voicemail Example History-Info: ;\ index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 As you can see, these are inconsistent. My belief (which may be faulty) is that the "Reason" goes in hi-entry corresponding to the INVITE that the proxy sent, because that's what the proxy can easily determine. Trying to find the right "leaf" hi-entry to attach the Reason to would be quite complicated in some forking cases. What is the right answer? Dale From marianne.mohali@orange.com Thu Feb 21 00:52:01 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 F2C6621F8DC9 for ; Thu, 21 Feb 2013 00:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 M5ns-j4eZ3rU for ; Thu, 21 Feb 2013 00:51:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B409821F8DEF for ; Thu, 21 Feb 2013 00:51:56 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E8C6418CAA1; Thu, 21 Feb 2013 09:51:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C3EF44C017; Thu, 21 Feb 2013 09:51:55 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 21 Feb 2013 09:51:55 +0100 From: To: Shida Schubert Thread-Topic: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt Thread-Index: AQHOAMyZ06RJPrxNn0imU//2fV42V5h4a0gwgAlf7ICAAROMkA== Date: Thu, 21 Feb 2013 08:51:54 +0000 Message-ID: <13889_1361436715_5125E02B_13889_535_1_8B970F90C584EA4E97D5BAAC9172DBB80BDA96@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> <11363_1360847497_511CE288_11363_3258_1_8B970F90C584EA4E97D5BAAC9172DBB80AFF59@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Cc: SIPCORE , "R.Jesske@telekom.de" , "Dale R. Worley" , Laura Liess 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 Feb 2013 08:52:01 -0000 Hi Shida, My answers inline [MM2] Marianne > -----Message d'origine----- > De=A0: Shida Schubert [mailto:shida@ntt-at.com] > Envoy=E9=A0: mardi 19 f=E9vrier 2013 23:17 > =C0=A0: MOHALI Marianne OLNC/OLN > Cc=A0: Paul Kyzivat; R.Jesske@telekom.de; Laura Liess; Brett Tate; Dale R. > Worley; SIPCORE > Objet=A0: Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows- > 02.txt >=20 >=20 > Hi Marianne; >=20 > Thank you for further comments.. My comments inline.. >=20 > On Feb 14, 2013, at 5:11 AM, > wrote: >=20 > > Hello, > > > > Most of my comments have been perfectly addressed but I have still > some concerns with the following changes: > > > > MM#1 =A73.6 in F3: there is an "mp" tag in a Contact header; I guess > it's a mistake and it should be a History-Info header (as in F4). >=20 > This is intentional. Per section 4.2.1 of RFC 4244bis regarding > Redirect Server behavior, redirect server would indicate the method a > redirect-to contact was determined. >=20 [MM2] ok, understood > > > > MM#2 =A73.6 in F6: The History-Info header is > > History-Info: ;index=3D1 [MM] ok [/MM] > > History-Info: ;\ > > index=3D1.1;rc=3D1 [MM] ok [/MM] > > History-Info: ;index=3D1.2;mp=3D1 [MM] ok [/MM] > > History-Info: ;\ > > index=3D1.2.1;rc=3D1.2 [MM] > nok, it is a cause URI parameter that should be set to "480" (call > deflection) following RFC4458. The Reason header is escaped in the SIP > URI only when it is a real received respond (it is the case with the > 302) [/MM] > > History-Info: > target=3Dsip:bob%40example.com>;\ > > index=3D1.3;mp=3D1 [MM] nok, > The hi-entry with the voicemail should be a copy of the R-URI so with > the cause=3D480 URI parameter. Additionally, the vm is finally reached > because Carol does not reply, so the no reply reason (cause=3D408) should > also be reflected in a cause URI parameter following RFC4458. Hence, > the hi-entry should be History-Info: > ; > index=3D1.3;mp=3D1 =3D> Oops, I think we have a problem... This is due to > the fact that at the same time we have successive forwarding (1 after > the other) with Carol at the second-to-last position and we try to join > B's vm (1st diverting user). IMO, we should add some text stating that > depending on which voicemail is reached (Bob or Carol), the call > forwarding reason (Bob or Carol's diverting reason) in the cause URI > parameter should be set accordingly (to be consistent). Here the target > vm is Bob so only cause=3D480 should be used and Carol's reason for not > answering the call is lost. [/MM] > > [MM]If someone have a better/other idea, please don't hesitate... > > [/MM] > > History-Info: > target=3Dsip:bob%40example.com>;\ > > index=3D1.3.1;rc=3D1.3 [MM] > nok, same comment > > > > But IMO it should be: > > > > 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;cause=3D480>;\ > > index=3D1.3;mp=3D1 > > History-Info: > target=3Dsip:bob%40example.com;cause=3D480>;\ > > index=3D1.3.1;rc=3D1.3 >=20 > Ok. Fixed. >=20 [MM2] After discussion with Dale, I'm not sure for the last hi-entry reason= value if it should be 408 (for the no reply from Carol) or 480 (for the in= itial call deflection from bob). Indeed, in this last proposal, we lose the= no reply reason from Carol so set 408 could give this information but on t= he other hand because there is mp=3D1 in the second-to-last hi-entry referi= ng to bob whom reason is 480...=20 Finally, I think 480 is correct and the 2-last reasons should be 408 (no re= ply) only if mp was=3D1.2. Do you agree? > > > > MM#3 =A73.7 in F4 and followings: > > In the hi-entry the reason-text has been added. > > I have 2 comments: > > 1. why adding the reason-text? (and why not ;)=3D> ok for me 2. if the > > reason-text is added, it should be "escaped" in the same way as the > cause parameter. > > So that, the hi-entry: > > History-Info: > ;text=3D"Moved Temporarily">\ > > ;index=3D1.1;rc=3D1 > > > > Should be: > > History-Info: > %3Btext%3D"Moved Temporarily">\ > > ;index=3D1.1;rc=3D1 >=20 > Good catch. Thanks [MM2] Once again, check Dale's response to me because remaining " and =3D s= eem also wrong. I didn't do the whole escaping.=20=20=20 >=20 > Shida >=20 > > > > Here is my feedback. > > > > Best Regards, > > Marianne > > > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la > > part de Paul Kyzivat Envoy=E9 : vendredi 1 f=E9vrier 2013 23:37 =C0 : > > R.Jesske@telekom.de; Laura Liess; MOHALI Marianne OLNC/OLN; Brett > > Tate; Dale R. Worley Cc : SIPCORE Objet : [sipcore] Verify > > draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > > > A new version of 4244bis-callflows has been published, to address the > comments we received in the WGLC review at the end of last year. > > > > I've sent this *To* the people who provided comments. > > I would appreciate your verifying that your comments were properly > > addressed. (Please comment back one way or the other.) > > > > This is *not* a new WGLC. So please don't bring up *new* issues now. > We are past that. I just want to verify that the comments already > raised have been handled. We are holding the bis to publish > concurrently with the callflows, so is the last thing holding them up. > > > > Thanks, > > Paul > > > > > > -------- Original Message -------- > > Subject: [sipcore] I-D Action: > > draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > Date: Tue, 29 Jan 2013 12:49:12 -0800 > > From: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: sipcore@ietf.org > > > > > > 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) : Mary Barnes > > Francois Audet > > Shida Schubert > > Detecon International Gmbh > > Christer Holmberg > > Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > Pages : 46 > > Date : 2013-01-29 > > > > Abstract: > > 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. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis- > callflo > > ws > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis- > callflo > > ws-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From shinji.okumura@softfront.jp Thu Feb 21 22:20: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 84D6021F8F51 for ; Thu, 21 Feb 2013 22:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAj31NTn5ZQy for ; Thu, 21 Feb 2013 22:20:47 -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 B5B5C21F8F47 for ; Thu, 21 Feb 2013 22:20:44 -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 87DCA42801F for ; Fri, 22 Feb 2013 15:20:41 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 22 Feb 2013 15:20:41 +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: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> Message-Id: <8CCE10C4BD1753shinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action: 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, 22 Feb 2013 06:20:47 -0000 Hi, all. I'm interested in these drafts, but I'm confused a little. draft-ietf-sipcore-rfc4244bis-callflows-02.txt Page 34 3.7. Consumer Voicemail Example In this scenario, I assume another indexing for last two History-Info headers. [original] F6 INVITE Example.com -> VM INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com SIP/2.0 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 Max-Forward: 67 From: Alice ;tag=kkaz- To: Bob Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE 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.2 History-Info: \ ;cause=408;index=1.3.1;rc=1.3 Contact: Alice Content-Type: application/sdp Content-Length: [my indexing] INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com;cause=408 SIP/2.0 History-Info: ;\ index=1.2.2;mp=1.2 History-Info: \ ;index=1.2.2.1;rc=1.2.2 Is my indexing against this specifications? Regards, Shinji. internet-drafts@ietf.org Tue, 29 Jan 2013 12:49:12 -0800 > >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) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt > Pages : 46 > Date : 2013-01-29 > >Abstract: > 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. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-callflows-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ From shinji.okumura@softfront.jp Mon Feb 25 02:03:00 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 CCC7C21F913F for ; Mon, 25 Feb 2013 02:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a2gf2p8tDmi for ; Mon, 25 Feb 2013 02:03:00 -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 B665821F9126 for ; Mon, 25 Feb 2013 02:02:59 -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 90C9D428022; Mon, 25 Feb 2013 19:02:56 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Mon, 25 Feb 2013 19:02:56 +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: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> References: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> Message-Id: Cc: "Dale R. Worley" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02: "Reason"placement 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, 25 Feb 2013 10:03:01 -0000 Hi, Dale. worley@ariadne.com (Dale R. Worley) Wed, 20 Feb 2013 15:49:44 -0500 (EST) >In draft-ietf-sipcore-rfc4244bis-callflows-02, I find the following >inconsistency. Could people please advise me what the correct usage >is? > >When a non-2xx final response is received by a proxy (or synthesized, >in the case of timeouts), the response code is to be placed in the >Reason header value in an hi-entry. It turns out that there are two >plausible choices: One place is the hi-entry corresponding to the >INVITE that was sent by the proxy and which matches the response >received, the "next hop" location. The other place is the hi-entry >which is the address of the UA which generated the response, the >"leaf" location. > >draft-ietf-sipcore-rfc4244bis-callflows-02 is not rich in failure >responses, but there are these examples, with the corresponding >hi-entries for the failed fork: > > 3.1. Sequentially Forking (History-Info in Response) > > History-Info: ;index=1.2;mp=1 > History-Info: ;\ > index=1.2.1;index=1.2.1;rc=1.2 > > 3.6. PBX Voicemail Example > > History-Info: ;index=1.2;mp=1 > History-Info: ;\ > index=1.2.1;rc=1.2 > > 3.7. Consumer Voicemail Example > > History-Info: ;\ > index=1.2;mp=1 > History-Info: ;index=1.2.1;rc=1.2 > >As you can see, these are inconsistent. > >My belief (which may be faulty) is that the "Reason" goes in hi-entry >corresponding to the INVITE that the proxy sent, because that's what >the proxy can easily determine. Trying to find the right "leaf" >hi-entry to attach the Reason to would be quite complicated in some >forking cases. > >What is the right answer? draft-ietf-sipcore-rfc4244bis-11 10.2. Reason in the History-Info Header Field If the Reason header field is being added due to receipt of an explicit SIP response and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. If the SIP response does not contain a Reason header field, the SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. according to this descriptions, SIP entity MUST include a Reason header "in the last hi-entry added to the cache". IIUC, it means "next hop" index=1.2.1. Regards, Shinji. From worley@shell01.TheWorld.com Mon Feb 25 08:14:03 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 CA5F721F952A for ; Mon, 25 Feb 2013 08:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=0.256, 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 ougKayP3v9gH for ; Mon, 25 Feb 2013 08:14:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA4921F9524 for ; Mon, 25 Feb 2013 08:14:02 -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 r1PGDY82031989 for ; Mon, 25 Feb 2013 11:13:36 -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 r1PGDY8x2579598 for ; Mon, 25 Feb 2013 11:13:34 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1PGDYoT2599674; Mon, 25 Feb 2013 11:13:34 -0500 (EST) Date: Mon, 25 Feb 2013 11:13:34 -0500 (EST) Message-Id: <201302251613.r1PGDYoT2599674@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (mary.ietf.barnes@gmail.com) References: <201302061509.r16F90sh016532@freeze.ariadne.com> Subject: Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1. 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, 25 Feb 2013 16:14:03 -0000 > From: Mary Barnes > > This is a set of suggested changes from Dale based upon the comments > he sent to the list previously: > http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html > > Responses are inline below [MB]. Based upon my responses, I do not > believe any of the changes impact normative behavior (as intended) > thus another WG and/or IETF LC should not be necessary, but I will > leave that decision to the chairs/AD. Just to get everyone oriented: I've been discussing my issues with Mary Barnes. After clearing away a number of minor points and misunderstandings, there are two significant questions. One question is properly describing how hi-entries are ordered. The terms "chronological order" and "tree preorder" have been used in the past, but neither is completely correct. I believe that Mary and I have agreed that "lexicographic order by index values" is completely correct and unambiguous. I've proposed some wording changes to support this, and Mary is reviewing them. The other question regards the details of adding "Reason" values to hi-entries in certain messy circumstances and ensuring the draft is unambiguous about how they are to be handled. I've formulated examples and descriptions, and sent them to Mary. Dale From rjsparks@nostrum.com Mon Feb 25 13:18: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 D577521F9344 for ; Mon, 25 Feb 2013 13:18:10 -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, SPF_PASS=-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 3njaQhYwLnAE for ; Mon, 25 Feb 2013 13:18:08 -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 192B321F944D for ; Mon, 25 Feb 2013 13:18:07 -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 r1PLI3mr068517 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 15:18:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512BD50B.1040709@nostrum.com> Date: Mon, 25 Feb 2013 15:18:03 -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: Paul Kyzivat References: <50B5404A.20807@nostrum.com> <5122B4D0.3020509@alum.mit.edu> In-Reply-To: <5122B4D0.3020509@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: sipcore@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, 25 Feb 2013 21:18:11 -0000 On 2/18/13 5:10 PM, Paul Kyzivat wrote: > On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote: > >>> * I'm ok proceeding with the IANA Considerations sections as they >>> currently >>> stand, but I wonder if instead of what's in 10.3 and 10.4, this >>> document >>> should create a new registry for the transport values. That way >>> someone >>> could search the registry for the strings "WS" or "WSS" and find >>> something >>> meaningful. >> >> I'm ok with what you suggest, but I don't think I can start such a new >> registry. If you consider that the document requires a new registry >> please let me know how to help with it. > > We just went through this by establishing a new registry for the > priority header field. > > But in that case, the draft that provoked the creation of the new > registry was in a different WG, and we thought it weird for that draft > to establish a new registry for a sip header field. > > In this case everything is within sipcore, so I don't see any reason > why we couldn't do everything within this draft. > > Robert, what do you think? Yes, in this draft is the right place to create the registry if the working group thinks a registry is a good idea. Is there anyone who thinks this would be a bad step? > Paul From rjsparks@nostrum.com Mon Feb 25 13:38:51 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 8467021F91F3 for ; Mon, 25 Feb 2013 13:38:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4suSLiGPtEyF for ; Mon, 25 Feb 2013 13:38:46 -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 3DAC521F91C2 for ; Mon, 25 Feb 2013 13:38: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 r1PLcitq070803 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 15:38:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512BD9E4.6020109@nostrum.com> Date: Mon, 25 Feb 2013 15:38:44 -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: Paul Kyzivat References: <50B5404A.20807@nostrum.com> <5122B4D0.3020509@alum.mit.edu> <512BD50B.1040709@nostrum.com> In-Reply-To: <512BD50B.1040709@nostrum.com> Content-Type: multipart/alternative; boundary="------------080304050408010704020502" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: sipcore@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, 25 Feb 2013 21:38:51 -0000 This is a multi-part message in MIME format. --------------080304050408010704020502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/25/13 3:18 PM, Robert Sparks wrote: > On 2/18/13 5:10 PM, Paul Kyzivat wrote: >> On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote: >> >>>> * I'm ok proceeding with the IANA Considerations sections as they >>>> currently >>>> stand, but I wonder if instead of what's in 10.3 and 10.4, this >>>> document >>>> should create a new registry for the transport values. That way >>>> someone >>>> could search the registry for the strings "WS" or "WSS" and find >>>> something >>>> meaningful. >>> >>> I'm ok with what you suggest, but I don't think I can start such a new >>> registry. If you consider that the document requires a new registry >>> please let me know how to help with it. >> >> We just went through this by establishing a new registry for the >> priority header field. >> >> But in that case, the draft that provoked the creation of the new >> registry was in a different WG, and we thought it weird for that >> draft to establish a new registry for a sip header field. >> >> In this case everything is within sipcore, so I don't see any reason >> why we couldn't do everything within this draft. >> >> Robert, what do you think? > Yes, in this draft is the right place to create the registry if the > working group thinks a registry is a good idea. > > Is there anyone who thinks this would be a bad step? If people _do_ think this is the right thing to do, this is the text I think we would need. (Based on a quick steal from the sipcore-priority document): 10.6 SIP Transports Registry This document adds a new registry, "SIP Transport". Its format and initial values are as shown in the following table: +------------+-----------+ | Priority | Reference | +------------+-----------+ | UDP | RFC 3261 | | TCP | RFC 3261 | | TLS | RFC 3261 | | SCTP | RFC 3261 | | WS | RFC XXXX | | WSS | RFC XXXX | +------------+-----------+ The policy for registration of values in this registry is "Standards Action", as that term is defined by [RFC5226]. RFC Editor Note: Please replace XXXX of the RFC number assigned for this document and remove this note. > > >> Paul > --------------080304050408010704020502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2/25/13 3:18 PM, Robert Sparks wrote:
On 2/18/13 5:10 PM, Paul Kyzivat wrote:
On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote:

* I'm ok proceeding with the IANA Considerations sections as they currently
   stand, but I wonder if instead of what's in 10.3 and 10.4, this document
   should create a new registry for the transport values. That way someone
   could search the registry for the strings "WS" or "WSS" and find something
   meaningful.

I'm ok with what you suggest, but I don't think I can start such a new
registry. If you consider that the document requires a new registry
please let me know how to help with it.

We just went through this by establishing a new registry for the priority header field.

But in that case, the draft that provoked the creation of the new registry was in a different WG, and we thought it weird for that draft to establish a new registry for a sip header field.

In this case everything is within sipcore, so I don't see any reason why we couldn't do everything within this draft.

Robert, what do you think?
Yes, in this draft is the right place to create the registry if the working group thinks a registry is a good idea.

Is there anyone who thinks this would be a bad step?
If people _do_ think this is the right thing to do, this is the text I think we would need. (Based on a quick steal from
the sipcore-priority document):


10.6 SIP Transports Registry

  This document adds a new registry, "SIP Transport".
  Its format and initial values are as shown in the following table:

                        +------------+-----------+
                        | Priority   | Reference |
                        +------------+-----------+
                        | UDP        | RFC 3261  |
                        | TCP        | RFC 3261  |
                        | TLS        | RFC 3261  |
                        | SCTP       | RFC 3261  |
                        | WS         | RFC XXXX  |
                        | WSS        | RFC XXXX  |
                        +------------+-----------+

   The policy for registration of values in this registry is "Standards Action",
   as that term is defined by [RFC5226].
     RFC Editor Note: Please replace XXXX of the RFC number assigned for this document and
     remove this note.


Paul


--------------080304050408010704020502-- From rjsparks@nostrum.com Mon Feb 25 13:52:46 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 AC12321F9006 for ; Mon, 25 Feb 2013 13:52:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX1xJY4A2bNr for ; Mon, 25 Feb 2013 13:52:46 -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 A878A21E80EE for ; Mon, 25 Feb 2013 13:52:45 -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 r1PLqhr6072365 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 15:52:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512BDD2B.8090102@nostrum.com> Date: Mon, 25 Feb 2013 15:52:43 -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: Paul Kyzivat References: <50B5404A.20807@nostrum.com> <5122B4D0.3020509@alum.mit.edu> <512BD50B.1040709@nostrum.com> <512BD9E4.6020109@nostrum.com> In-Reply-To: <512BD9E4.6020109@nostrum.com> Content-Type: multipart/alternative; boundary="------------030204070204020303090309" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: sipcore@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, 25 Feb 2013 21:52:46 -0000 This is a multi-part message in MIME format. --------------030204070204020303090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Looks like I missed 4168 - correction below: On 2/25/13 3:38 PM, Robert Sparks wrote: > On 2/25/13 3:18 PM, Robert Sparks wrote: >> On 2/18/13 5:10 PM, Paul Kyzivat wrote: >>> On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote: >>> >>>>> * I'm ok proceeding with the IANA Considerations sections as they >>>>> currently >>>>> stand, but I wonder if instead of what's in 10.3 and 10.4, this >>>>> document >>>>> should create a new registry for the transport values. That way >>>>> someone >>>>> could search the registry for the strings "WS" or "WSS" and >>>>> find something >>>>> meaningful. >>>> >>>> I'm ok with what you suggest, but I don't think I can start such a new >>>> registry. If you consider that the document requires a new registry >>>> please let me know how to help with it. >>> >>> We just went through this by establishing a new registry for the >>> priority header field. >>> >>> But in that case, the draft that provoked the creation of the new >>> registry was in a different WG, and we thought it weird for that >>> draft to establish a new registry for a sip header field. >>> >>> In this case everything is within sipcore, so I don't see any reason >>> why we couldn't do everything within this draft. >>> >>> Robert, what do you think? >> Yes, in this draft is the right place to create the registry if the >> working group thinks a registry is a good idea. >> >> Is there anyone who thinks this would be a bad step? > If people _do_ think this is the right thing to do, this is the text I > think we would need. (Based on a quick steal from > the sipcore-priority document): > > > 10.6 SIP Transports Registry > > This document adds a new registry, "SIP Transport". > Its format and initial values are as shown in the following table: +------------+---------------------+ | Priority | Reference | +------------+---------------------+ | UDP | RFC 3261 | | TCP | RFC 3261 | | TLS | RFC 3261 | | SCTP | RFC 3261, RFC 4168 | | TLS-SCTP | RFC 4168 | | WS | RFC XXXX | | WSS | RFC XXXX | +------------+---------------------+ > > The policy for registration of values in this registry is "Standards Action", > as that term is defined by [RFC5226]. > RFC Editor Note: Please replace XXXX of the RFC number assigned > for this document and > remove this note. >> >> >>> Paul >> > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------030204070204020303090309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Looks like I missed 4168 - correction below:

On 2/25/13 3:38 PM, Robert Sparks wrote:
On 2/25/13 3:18 PM, Robert Sparks wrote:
On 2/18/13 5:10 PM, Paul Kyzivat wrote:
On 2/17/13 8:31 PM, Iñaki Baz Castillo wrote:

* I'm ok proceeding with the IANA Considerations sections as they currently
   stand, but I wonder if instead of what's in 10.3 and 10.4, this document
   should create a new registry for the transport values. That way someone
   could search the registry for the strings "WS" or "WSS" and find something
   meaningful.

I'm ok with what you suggest, but I don't think I can start such a new
registry. If you consider that the document requires a new registry
please let me know how to help with it.

We just went through this by establishing a new registry for the priority header field.

But in that case, the draft that provoked the creation of the new registry was in a different WG, and we thought it weird for that draft to establish a new registry for a sip header field.

In this case everything is within sipcore, so I don't see any reason why we couldn't do everything within this draft.

Robert, what do you think?
Yes, in this draft is the right place to create the registry if the working group thinks a registry is a good idea.

Is there anyone who thinks this would be a bad step?
If people _do_ think this is the right thing to do, this is the text I think we would need. (Based on a quick steal from
the sipcore-priority document):


10.6 SIP Transports Registry

  This document adds a new registry, "SIP Transport".
  Its format and initial values are as shown in the following table:


                        +------------+---------------------+
                        | Priority   | Reference           |
                        +------------+---------------------+
                        | UDP        | RFC 3261            |
                        | TCP        | RFC 3261            |
                        | TLS        | RFC 3261            |
                        | SCTP       | RFC 3261, RFC 4168  |
                        | TLS-SCTP   | RFC 4168            |
                        | WS         | RFC XXXX            |
                        | WSS        | RFC XXXX            |
                        +------------+---------------------+

   The policy for registration of values in this registry is "Standards Action",
   as that term is defined by [RFC5226].
     RFC Editor Note: Please replace XXXX of the RFC number assigned for this document and
     remove this note.


Paul 




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

--------------030204070204020303090309-- From rjsparks@nostrum.com Mon Feb 25 14:00:14 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 CCD3B21E80E1 for ; Mon, 25 Feb 2013 14:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, SPF_PASS=-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 UPSiFFMWUk8V for ; Mon, 25 Feb 2013 14:00:14 -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 5E6DF21E80D4 for ; Mon, 25 Feb 2013 14:00:14 -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 r1PM0Dji073265 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 16:00:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512BDEED.9030706@nostrum.com> Date: Mon, 25 Feb 2013 16:00:13 -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" , draft-ietf-sipcore-sip-websocket@tools.ietf.org References: <50B5404A.20807@nostrum.com> In-Reply-To: <50B5404A.20807@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) 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, 25 Feb 2013 22:00:15 -0000 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? > RjS From keith.drage@alcatel-lucent.com Mon Feb 25 16:25:46 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 8572121E818F for ; Mon, 25 Feb 2013 16:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.124 X-Spam-Level: X-Spam-Status: No, score=-109.124 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ULoMtuS7N6JZ for ; Mon, 25 Feb 2013 16:25:45 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C021E8191 for ; Mon, 25 Feb 2013 16:25:44 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1Q0Pcdh001506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 01:25:40 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 26 Feb 2013 01:25:38 +0100 From: "DRAGE, Keith (Keith)" To: Robert Sparks , Paul Kyzivat Date: Tue, 26 Feb 2013 01:25:37 +0100 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt Thread-Index: Ac4ToISh1gwxFjspREKn1d0A30ZCOQAEIjRQ Message-ID: References: <50B5404A.20807@nostrum.com> <5122B4D0.3020509@alum.mit.edu> <512BD50B.1040709@nostrum.com> <512BD9E4.6020109@nostrum.com> In-Reply-To: <512BD9E4.6020109@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE210701F20EBFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "sipcore@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: Tue, 26 Feb 2013 00:25:46 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE210701F20EBFRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IANA considerations for the new registry needs to indicate it is groupe= d with the other SIP registries. I see Robert has already spotted RFC 4168. Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Robert Sparks Sent: 25 February 2013 21:39 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt On 2/25/13 3:18 PM, Robert Sparks wrote: On 2/18/13 5:10 PM, Paul Kyzivat wrote: On 2/17/13 8:31 PM, I=F1aki Baz Castillo wrote: * I'm ok proceeding with the IANA Considerations sections as they currently stand, but I wonder if instead of what's in 10.3 and 10.4, this document should create a new registry for the transport values. That way someone could search the registry for the strings "WS" or "WSS" and find somethi= ng meaningful. I'm ok with what you suggest, but I don't think I can start such a new registry. If you consider that the document requires a new registry please let me know how to help with it. We just went through this by establishing a new registry for the priority h= eader field. But in that case, the draft that provoked the creation of the new registry = was in a different WG, and we thought it weird for that draft to establish = a new registry for a sip header field. In this case everything is within sipcore, so I don't see any reason why we= couldn't do everything within this draft. Robert, what do you think? Yes, in this draft is the right place to create the registry if the working= group thinks a registry is a good idea. Is there anyone who thinks this would be a bad step? If people _do_ think this is the right thing to do, this is the text I thin= k we would need. (Based on a quick steal from the sipcore-priority document): 10.6 SIP Transports Registry This document adds a new registry, "SIP Transport". Its format and initial values are as shown in the following table: +------------+-----------+ | Priority | Reference | +------------+-----------+ | UDP | RFC 3261 | | TCP | RFC 3261 | | TLS | RFC 3261 | | SCTP | RFC 3261 | | WS | RFC XXXX | | WSS | RFC XXXX | +------------+-----------+ The policy for registration of values in this registry is "Standards Act= ion", as that term is defined by [RFC5226]. RFC Editor Note: Please replace XXXX of the RFC number assigned for th= is document and remove this note. Paul --_000_EDC0A1AE77C57744B664A310A0B23AE210701F20EBFRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The IANA considerations for the new registry needs to indicate it is grouped with the other SIP registries.

 

I see Robert has already spotted RFC 4= 168.

 

Keith

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Be= half Of Robert Sparks
Sent: 25 February 2013 21:39=
To: Paul Kyzivat
Cc: sipcore@ietf.org
Subject: Re: [sipcore] AD Re= view: draft-ietf-sipcore-sip-websocket-06.txt

=  

= On 2/25/13 3:18 PM, Robert Sparks wrote:

On 2/18/13 5:10 PM, Paul Kyzivat wrote: =

On 2/17/13 8:31 PM, I=F1aki Baz Castillo wrote:

= * I'm ok proceeding with the IANA Considerations sections as they currently
   stand, but I wonder if instead of what's in 10.3 and 10.4, thi= s document
   should create a new registry for the transport values. That wa= y someone
   could search the registry for the strings "WS" or "WSS" and find something
   meaningful.

=
I'm ok with what you suggest, but I don't think I can start such a new
registry. If you consider that the document requires a new registry
please let me know how to help with it.

=
We just went through this by establishing a new registry for the priority header field.

But in that case, the draft that provoked the creation of the new registry = was in a different WG, and we thought it weird for that draft to establish a ne= w registry for a sip header field.

In this case everything is within sipcore, so I don't see any reason why we couldn't do everything within this draft.

Robert, what do you think?

= Yes, in this draft is the right place to create = the registry if the working group thinks a registry is a good idea.

Is there anyone who thinks this would be a bad step?

If people _do_ th= ink this is the right thing to do, this is the text I think we would need. (Based on= a quick steal from
the sipcore-priority document):


10.6 SIP Transports Registry

  This document adds a new registry, "SIP Transport&=
quot;.
  Its format and initial values are as shown in the following table:=

 
            &=
nbsp;           +--------=
----+-----------+
            &=
nbsp;           | Priorit=
y   | Reference |
            &=
nbsp;           +--------=
----+-----------+
            &=
nbsp;           | UDP&nbs=
p;       | RFC 3261  |=

            &=
nbsp;           | TCP       =
 | RFC 3261  |
            &=
nbsp;           | TLS       =
 | RFC 3261  |
            &=
nbsp;           | SCTP&nb=
sp;      | RFC 3261  |
            &=
nbsp;           | WS =
;        | RFC XXXX  |
            &=
nbsp;           | WSS&nbs=
p;       | RFC XXXX  |=

            &=
nbsp;           +------------+=
-----------+
 
   The policy for registration of values in this registry is &q=
uot;Standards Action",
   as that term is defined by [RFC5226].

   = ;  RFC Editor Note: Please replace XXXX of the RFC number assigned for this document and
     remove this note.



= Paul

=  

=  

--_000_EDC0A1AE77C57744B664A310A0B23AE210701F20EBFRMRSSXCHMBSC_-- From R.Jesske@telekom.de Tue Feb 26 02:16:32 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 2A7D321F89AA for ; Tue, 26 Feb 2013 02:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 zt5AMeBSdOQi for ; Tue, 26 Feb 2013 02:16:31 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6616221F899E for ; Tue, 26 Feb 2013 02:16:30 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 26 Feb 2013 11:16:14 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 26 Feb 2013 11:16:13 +0100 From: To: , , , , Date: Tue, 26 Feb 2013 11:16:13 +0100 Thread-Topic: Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt Thread-Index: Ac4AzJenGHNcRatRSgCWm3nB1Wd56ATPXxrw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E36595DB@HE111648.emea1.cds.t-internal.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <510C4370.6020306@alum.mit.edu> In-Reply-To: <510C4370.6020306@alum.mit.edu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] 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: Tue, 26 Feb 2013 10:16:32 -0000 Hi Paul, I went through the draft and I'm happy with the status as it is. So from my side no more open issues and all my comments are covered. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Gesendet: Freitag, 1. Februar 2013 23:37 > An: Jesske, Roland; Laura Liess; > marianne.mohali@orange-ftgroup.com; Brett Tate; Dale R. Worley > Cc: SIPCORE > Betreff: Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt > > A new version of 4244bis-callflows has been published, to > address the comments we received in the WGLC review at the > end of last year. > > I've sent this *To* the people who provided comments. > I would appreciate your verifying that your comments were > properly addressed. (Please comment back one way or the other.) > > This is *not* a new WGLC. So please don't bring up *new* > issues now. We are past that. I just want to verify that the > comments already raised have been handled. We are holding the > bis to publish concurrently with the callflows, so is the > last thing holding them up. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: [sipcore] I-D Action: > draft-ietf-sipcore-rfc4244bis-callflows-02.txt > Date: Tue, 29 Jan 2013 12:49:12 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: sipcore@ietf.org > > > 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) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt > Pages : 46 > Date : 2013-01-29 > > Abstract: > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis > -callflows > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis > -callflows-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > From ibc@aliax.net Tue Feb 26 02:16:35 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 90C6121F8A0C for ; Tue, 26 Feb 2013 02:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.533, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GS1ZzZ0+Tyj for ; Tue, 26 Feb 2013 02:16:35 -0800 (PST) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id E69E521F89FB for ; Tue, 26 Feb 2013 02:16:34 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id w7so2351910qeb.37 for ; Tue, 26 Feb 2013 02:16:34 -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=8wKlxKsIRmct1M8PXqbNiuFeh/bBZbnFRWWBn0JsvY4=; b=TFHOraNNS4VQruurtxzlyMrwJlyMysH4mSkusJQngJQxA+dqJLLWFL8Zdp42u/nEfd JDT/mzKk4xxQL7tBsb8GyaKXGa6oaVJcU8y9AuF+B7MU/no19ollREI/OO622/PqvpfK GgTKuRdo5nlwQ/P/M+PspOuSst4/OUzu+o3X1ig9Rsn79OVkRRhom4AmnIwI7gfH76Mh KuKrmA779mfQQqy20gIIPTGTogfTvjxfffNkJCimbe5GIhUmkNGek1QtesyPTz6uPF/v nfVzxSCB1qRF+x30w8dkin37vOBbF1Bgd+DBVPj8QHwhDvSjqlfoqvr5KP9uQCJNWVn4 edkg== X-Received: by 10.224.9.201 with SMTP id m9mr992869qam.25.1361873794192; Tue, 26 Feb 2013 02:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.94.193 with HTTP; Tue, 26 Feb 2013 02:16:14 -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: Tue, 26 Feb 2013 11:16:14 +0100 Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn43h3pKTa/jCw+RZXOEGIwM6KaEcJCLFEe1C59VOeaKHp1DyEExLClkfbRhiGtcTwEFfig 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: Tue, 26 Feb 2013 10:16:35 -0000 Hi Robert, we are currently at MWC in Barcelona. We will address the issues you and Paul have reported during next days. Thanks a lot. 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 websocke= ts >> supposed to do if it gets a message containing Route header fields >> (think >> preloaded routes) where the next route value is for a transport=3Dws h= op >> that >> a connection doesn't yet exist for? >> > RjS > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From mary.ietf.barnes@gmail.com Tue Feb 26 14:10:20 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 C4E8921F86FF for ; Tue, 26 Feb 2013 14:10:20 -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=[BAYES_00=-2.599, 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 QJJ1r6nykPvW for ; Tue, 26 Feb 2013 14:10:20 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 35EA921F86D3 for ; Tue, 26 Feb 2013 14:10:20 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so49929qcm.25 for ; Tue, 26 Feb 2013 14:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=rXATbO59Al5qFIIhfMQSTCVn8ktB1S7ZFiofrLP4/ic=; b=bAuK/0FWb9DQtwFa9v/oJSXjni10tODqqbgZnFb2uvoSU+6qrucOy4u7wYxYCbc8ub MmT8izfBdDvAUt8UWUVNCvweNp15NQEo3vMRrRl3032qOGZFdQsFI4JHg/J4kPXN6qG7 fmRX00BAFhXR/6feSp7Ee4PICf2qt8Z3daxqQJXglVaJgF9I7LLioxY5fv12g7qL8MEr LavLVpsbf80d3GIeCU/32Y8mDXLpSDeyf5KTcHYK3TMYWK0+dS70+x61rtV/GEkFoeix wn73N+M60KnVP/9FvqKnClohFCjcqtoQs1sQdVl+HpemhTddNQ0634KgLJO4EA3C/HMF 9+RA== MIME-Version: 1.0 X-Received: by 10.224.174.80 with SMTP id s16mr4468949qaz.85.1361916619610; Tue, 26 Feb 2013 14:10:19 -0800 (PST) Received: by 10.49.24.130 with HTTP; Tue, 26 Feb 2013 14:10:19 -0800 (PST) Date: Tue, 26 Feb 2013 16:10:19 -0600 Message-ID: From: Mary Barnes To: "mmusic-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , Richard Barnes , SIPCORE , "rai-ads@tools.ietf.org" Subject: [sipcore] Dispatching of draft-ivov-dispatch-trickle-ice-sip-00 and draft-ivov-dispatch-sdpfrag 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, 26 Feb 2013 22:10:20 -0000 Hi all, We had our review of the DISPATCH-86 topics with the ADs this morning. The decision was to dispatch these documents to the MMUSIC WG for discussion as potential work items: - draft-ivov-dispatch-trickle-ice-sip (currently proposes a new INFO event package) - draft-ivov-dispatch-sdpfrag (defines application/sdpfrag MIME media type) It made more sense to dispatch to MMUSIC since they are related to draft-ivov-mmusic-trickle-ice-00 which is currently under discussion as a proposed MMUSIC WG document. And, neither the SIP change nor RFC 6086 require that this sort of work be done in SIPCORE. If you have any questions or comments, please let the ADs know ASAP. I will be posting this decision along with the plans for the other IETF-86 topics and agenda by tomorrow morning. Regards, Mary DISPATCH WG co-chair From worley@shell01.TheWorld.com Tue Feb 26 19:23: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 777F921F871D for ; Tue, 26 Feb 2013 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_05=-1.11, 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 YomXoF4w3o29 for ; Tue, 26 Feb 2013 19:23:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6891521F8745 for ; Tue, 26 Feb 2013 19:22:54 -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 r1R3MNxS017799; Tue, 26 Feb 2013 22:22:25 -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 r1R3MNko2684702; Tue, 26 Feb 2013 22:22:23 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1R3MNKv2626409; Tue, 26 Feb 2013 22:22:23 -0500 (EST) Date: Tue, 26 Feb 2013 22:22:23 -0500 (EST) Message-Id: <201302270322.r1R3MNKv2626409@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: OKUMURA Shinji In-reply-to: <8CCE10C4BD1753shinji.okumura@softfront.jp> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <8CCE10C4BD1753shinji.okumura@softfront.jp> Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: 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: Wed, 27 Feb 2013 03:23:04 -0000 > From: OKUMURA Shinji > [original] > F6 INVITE Example.com -> VM > > INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 > Max-Forward: 67 > From: Alice ;tag=kkaz- > To: Bob > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;text="Moved Temporarily">;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.2 > History-Info: \ > ;cause=408;index=1.3.1;rc=1.3 > Contact: Alice > Content-Type: application/sdp > Content-Length: > [my indexing] > INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com;cause=408 SIP/2.0 > > History-Info: ;\ > index=1.2.2;mp=1.2 > History-Info: \ > ;index=1.2.2.1;rc=1.2.2 I believe that you've found an error. If the call was sent to *Bob's* voicemail, then the fork to VM would be a child of the INVITE to sip:bob@example.com (index 1), so the INVITE to voicemail would have index 1.3. But in this case, the call was sent to *Carol's* voicemail, it is (most likely) a child of the INVITE to sip:carol@example.com (index 1.2), and so the INVITE to voicemail would have index 1.2.2. Dale From worley@shell01.TheWorld.com Tue Feb 26 19:23: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 7B27321F8751 for ; Tue, 26 Feb 2013 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=0.227, 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 l0J9eGxLIKc2 for ; Tue, 26 Feb 2013 19:23:02 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6739C21F8733 for ; Tue, 26 Feb 2013 19:22:54 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1R3M25g017080; Tue, 26 Feb 2013 22:22:04 -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 r1R3M1Ow2706403; Tue, 26 Feb 2013 22:22:01 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1R3M1QA2696992; Tue, 26 Feb 2013 22:22:01 -0500 (EST) Date: Tue, 26 Feb 2013 22:22:01 -0500 (EST) Message-Id: <201302270322.r1R3M1QA2696992@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: OKUMURA Shinji In-reply-to: References: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02: "Reason"placement X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 03:23:04 -0000 > From: OKUMURA Shinji [choosing one examle from several:] > > 3.1. Sequentially Forking (History-Info in Response) > > > > History-Info: ;index=1.2;mp=1 > > History-Info: ;\ > > index=1.2.1;index=1.2.1;rc=1.2 > draft-ietf-sipcore-rfc4244bis-11 > 10.2. Reason in the History-Info Header Field > > If the Reason header field is being added due to > receipt of an explicit SIP response and the response contains any > Reason header fields (see [RFC3326]), then the SIP entity MUST > include the Reason header fields in the "headers" component of the > hi-targeted-to-uri in the last hi-entry added to the cache, unless > the hi-targeted-to-uri is a Tel-URI. If the SIP response does not > contain a Reason header field, the SIP entity MUST include a Reason > header field, containing the SIP Response Code, in the "headers" > component of the hi-targeted-to-uri in the last hi-entry added to the > cache, unless the hi-targeted-to-uri is a Tel-URI. > > according to this descriptions, SIP entity MUST include a Reason header > "in the last hi-entry added to the cache". > IIUC, it means "next hop" index=1.2.1. Looking at the matter more closely, it is rather complex: The text says "the last hi-entry added to the cache". I believe that it means "the hi-entry that was most recently added to the cache". The processing described is in section 10.2. The only location where 10.2 is referenced is in Step 2 of section 9.3. Section 9.3 begins: 9.3. Receiving a Response with History-Info or Request Timeouts When a SIP entity receives a non-100 response or a request times out, the SIP entity performs the following steps: Step 1: Add hi-entry to cache The SIP entity MUST add the hi-entry that was added to the request that received the non-100 response or timed out to the cache, if it was not already cached. The hi-entry MUST be added to the cache in ascending order as indicated by the values in the hi- index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or 1.3). Step 2: Add Reason header field The SIP entity adds one or more Reason header fields to the hi- targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 response, per the procedures of Section 10.2. As you can see, the point where section 10.2 is invoked is in Step 2, and at that point the hi-entry that was most recently added to the cache is the hi-entry specified in Step 1, namely, "the hi-entry that was added to the request that received the ... response". (hi-entries taken from the response itself are added to the cache later, in Step 3.) In this case, I believe there is a problem with the wording: Step 1 does nothing because the specified hi-entry is already in the cache due to reception of response F7 (in the callflow 3.1), and so the specified hi-entry is not "added to the cache", but I believe it is intended to be the hi-entry upon which Step 2 and section 10.2 operate. Within that understanding, it seems to me that the Reason value should be added to hi-entry 1.2.1, because that is the hi-entry that corresponds to the INVITE that was sent from proxy "example.com" to Office. There is additional complexity because this is a case of "internal retargeting": It is as if the proxy sent "INVITE sip:office@example.com" (index 1.2) to another proxy, which sent "INVITE sip:office@192.0.2.5" (index 1.2.1). Clearly (?), "example.com" should apply "Reason=...408..." to hi-entry 1.2.1, because that corresponds to the request that timed out. But it seems to me that "example.com", in its role as the upstream proxy which internally receives the 408 response from itself in its role as the downstream proxy, should apply "Reason=...408..." to hi-entry 1.2 as well. (If the two proxies were separated, that is what would happen.) Dale From shinji.okumura@softfront.jp Wed Feb 27 00:22:56 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 E456821F85B2 for ; Wed, 27 Feb 2013 00:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8pAQwcpjDLF for ; Wed, 27 Feb 2013 00:22:55 -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 7345621F85AC for ; Wed, 27 Feb 2013 00:22:53 -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 49A38428035; Wed, 27 Feb 2013 17:22:47 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 27 Feb 2013 17:22:45 +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: <201302270322.r1R3M1QA2696992@shell01.TheWorld.com> References: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> <201302270322.r1R3M1QA2696992@shell01.TheWorld.com> Message-Id: Cc: "Dale R. Worley" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02:"Reason"placement X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:22:56 -0000 Hi, Dale. Thank you for your response, my comments inline. worley@ariadne.com (Dale R. Worley) Tue, 26 Feb 2013 22:22:01 -0500 (EST) >> From: OKUMURA Shinji > >[choosing one examle from several:] >> > 3.1. Sequentially Forking (History-Info in Response) >> > >> > History-Info: ;index=1.2;mp=1 >> > History-Info: ;\ >> > index=1.2.1;index=1.2.1;rc=1.2 > >> draft-ietf-sipcore-rfc4244bis-11 >> 10.2. Reason in the History-Info Header Field >> >> If the Reason header field is being added due to >> receipt of an explicit SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. If the SIP response does not >> contain a Reason header field, the SIP entity MUST include a Reason >> header field, containing the SIP Response Code, in the "headers" >> component of the hi-targeted-to-uri in the last hi-entry added to the >> cache, unless the hi-targeted-to-uri is a Tel-URI. >> >> according to this descriptions, SIP entity MUST include a Reason header >> "in the last hi-entry added to the cache". >> IIUC, it means "next hop" index=1.2.1. > >Looking at the matter more closely, it is rather complex: > >The text says "the last hi-entry added to the cache". I believe that >it means "the hi-entry that was most recently added to the cache". > >The processing described is in section 10.2. The only location where >10.2 is referenced is in Step 2 of section 9.3. Section 9.3 begins: > > 9.3. Receiving a Response with History-Info or Request Timeouts > > When a SIP entity receives a non-100 response or a request times out, > the SIP entity performs the following steps: > > Step 1: Add hi-entry to cache > > The SIP entity MUST add the hi-entry that was added to the request > that received the non-100 response or timed out to the cache, if > it was not already cached. The hi-entry MUST be added to the > cache in ascending order as indicated by the values in the hi- > index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 > but before 1.2.2 or 1.3). > > Step 2: Add Reason header field > > The SIP entity adds one or more Reason header fields to the hi- > targeted-to-uri in the (newly) cached hi-entry reflecting the SIP > response code in the non-100 response, per the procedures of > Section 10.2. > >As you can see, the point where section 10.2 is invoked is in Step 2, >and at that point the hi-entry that was most recently added to the >cache is the hi-entry specified in Step 1, namely, "the hi-entry that >was added to the request that received the ... response". (hi-entries >taken from the response itself are added to the cache later, in Step >3.) At a time when the SIP entity adds one or more Reason header fields, "the index of the last hi-entry added to the cache" is 1.2.1, isn't it? >In this case, I believe there is a problem with the wording: Step 1 >does nothing because the specified hi-entry is already in the cache >due to reception of response F7 (in the callflow 3.1), and so the >specified hi-entry is not "added to the cache", but I believe it is >intended to be the hi-entry upon which Step 2 and section 10.2 >operate. aha! At proxy.example.com, when to the cache ------------------------------------------------- receiving INVITE(F1) add index=1 sending INVITE(F2) add index=1.1 receiving 302(F4) include a Reason in index=1.1(last at the time) sending INVITE(F6) add index=1.2 add index=1.2.1 receiving 180(F7) add nothig. but it is terrible, if 180 has index=1.2.1.x... time out(--) include a Reason in index=1.2.1(last at the time) therefore, the SIP entity MUST include a Reason header field in the last hi-entry "created by itself". >Within that understanding, it seems to me that the Reason value should >be added to hi-entry 1.2.1, because that is the hi-entry that >corresponds to the INVITE that was sent from proxy "example.com" to >Office. I think so too. >There is additional complexity because this is a case of "internal >retargeting": It is as if the proxy sent "INVITE >sip:office@example.com" (index 1.2) to another proxy, which sent >"INVITE sip:office@192.0.2.5" (index 1.2.1). > >Clearly (?), "example.com" should apply "Reason=...408..." to hi-entry >1.2.1, because that corresponds to the request that timed out. > >But it seems to me that "example.com", in its role as the upstream >proxy which internally receives the 408 response from itself in its >role as the downstream proxy, should apply "Reason=...408..." to >hi-entry 1.2 as well. (If the two proxies were separated, that is >what would happen.) it seems fine that both hi-entries(1.2 and 1.2.1) have a Reason header. The last one MUST include it, another one "should" do it. Regards, Shinji. From shinji.okumura@softfront.jp Wed Feb 27 00:22:56 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 D313C21F85AF for ; Wed, 27 Feb 2013 00:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAbQIKSA++KI for ; Wed, 27 Feb 2013 00:22:55 -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 7338A21F85A0 for ; Wed, 27 Feb 2013 00:22:53 -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 3454642803E; Wed, 27 Feb 2013 17:22:50 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 27 Feb 2013 17:22:48 +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: <201302270322.r1R3MNKv2626409@shell01.TheWorld.com> References: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> <8CCE10C4BD1753shinji.okumura@softfront.jp> <201302270322.r1R3MNKv2626409@shell01.TheWorld.com> Message-Id: Cc: "Dale R. Worley" Subject: Re: [sipcore] I-D Action: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: Wed, 27 Feb 2013 08:22:56 -0000 Hi, Dale. Thank you for your response, my comments inline. worley@ariadne.com (Dale R. Worley) Tue, 26 Feb 2013 22:22:23 -0500 (EST) >> From: OKUMURA Shinji > >> [original] >> F6 INVITE Example.com -> VM >> >> INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com SIP/2.0 >> Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 >> Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 >> Max-Forward: 67 >> From: Alice ;tag=kkaz- >> To: Bob >> Supported: histinfo >> Call-Id: 12345600@example.com >> CSeq: 1 INVITE >> History-Info: ;index=1 >> History-Info: > ;text="Moved Temporarily">;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.2 >> History-Info: \ >> ;cause=408;index=1.3.1;rc=1.3 >> Contact: Alice >> Content-Type: application/sdp >> Content-Length: > >> [my indexing] >> INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com;cause=408 SIP/2.0 >> >> History-Info: ;\ >> index=1.2.2;mp=1.2 >> History-Info: \ >> ;index=1.2.2.1;rc=1.2.2 > >I believe that you've found an error. > >If the call was sent to *Bob's* voicemail, then the fork to VM would >be a child of the INVITE to sip:bob@example.com (index 1), so the >INVITE to voicemail would have index 1.3. > >But in this case, the call was sent to *Carol's* voicemail, it is >(most likely) a child of the INVITE to sip:carol@example.com (index >1.2), and so the INVITE to voicemail would have index 1.2.2. I don't think the original indexing is an error. Is a result of indexing unique? In this case, the Contact of 302 has mp=1.2. The index "1.2" is created by proxy.example.com. But if the index is "1.2.1.x" that created by another proxy, what is the new index of the new INVITE? 1.3? 1.2.1.x.1?? And I have an additional question. If Contact of 302 has no mp parameter, what is an index of the new hi-entry? and what is a mp parameter of it. Shinji. From fandreas@cisco.com Tue Feb 26 21:50: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 08C8E21F86F5 for ; Tue, 26 Feb 2013 21:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.515 X-Spam-Level: X-Spam-Status: No, score=-9.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Indq0KHIAGuq for ; Tue, 26 Feb 2013 21:50:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0B421F86C2 for ; Tue, 26 Feb 2013 21:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1361944209; x=1363153809; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qblEMinr+xTjyvRhwVABiSvXIe5eOm8hgRv4CIFf7fc=; b=VgmPcjUJgxo0fU6o/aIfw3e995lqQl94sXK4kylRbUzZ4i9eZsfrW3E/ tJ/6FzlUeHvLDmn5PCnfyBjNxbDHUITPuQRxP6kzG/PT51f87T7BBXUKV IJ8wZd5YUE++yBq45QuzwZwKUjH6OzRln9u/kgT0eoPERXwMICInZ7QVt s=; X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="178622583" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 27 Feb 2013 05:50:09 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.247.67]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1R5o6lR005173; Wed, 27 Feb 2013 05:50:06 GMT Message-ID: <512D9E8E.4060200@cisco.com> Date: Wed, 27 Feb 2013 00:50:06 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Feb 2013 06:07:09 -0800 Cc: Cullen Jennings , Richard Barnes , "mmusic-chairs@tools.ietf.org" , SIPCORE , "rai-ads@tools.ietf.org" Subject: Re: [sipcore] Dispatching of draft-ivov-dispatch-trickle-ice-sip-00 and draft-ivov-dispatch-sdpfrag X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 05:50:13 -0000 Ok - we'll add them to the MMUSIC agenda. Does any other group need to review these drafts at some point or can they be handled completely by MMUSIC ? Thanks -- Flemming On 2/26/13 5:10 PM, Mary Barnes wrote: > Hi all, > > We had our review of the DISPATCH-86 topics with the ADs this morning. > The decision was to dispatch these documents to the MMUSIC WG for > discussion as potential work items: > - draft-ivov-dispatch-trickle-ice-sip (currently proposes a new INFO > event package) > - draft-ivov-dispatch-sdpfrag (defines application/sdpfrag MIME media type) > > It made more sense to dispatch to MMUSIC since they are related to > draft-ivov-mmusic-trickle-ice-00 which is currently under discussion > as a proposed MMUSIC WG document. And, neither the SIP change nor RFC > 6086 require that this sort of work be done in SIPCORE. > > If you have any questions or comments, please let the ADs know ASAP. > I will be posting this decision along with the plans for the other > IETF-86 topics and agenda by tomorrow morning. > > Regards, > Mary > DISPATCH WG co-chair > . > From rjsparks@nostrum.com Wed Feb 27 07:07:58 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 7942C21F870E for ; Wed, 27 Feb 2013 07:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-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 s+FpGBPlWXYj for ; Wed, 27 Feb 2013 07:07:58 -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 B01AE21F870C for ; Wed, 27 Feb 2013 07:07:57 -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 r1RF79ds047586 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 09:07:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512E211F.7030400@nostrum.com> Date: Wed, 27 Feb 2013 09:07:11 -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: Flemming Andreasen References: <512D9E8E.4060200@cisco.com> In-Reply-To: <512D9E8E.4060200@cisco.com> 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) Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , Richard Barnes , SIPCORE , "mmusic-chairs@tools.ietf.org" Subject: Re: [sipcore] Dispatching of draft-ivov-dispatch-trickle-ice-sip-00 and draft-ivov-dispatch-sdpfrag X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:07:58 -0000 On 2/26/13 11:50 PM, Flemming Andreasen wrote: > Ok - we'll add them to the MMUSIC agenda. Does any other group need to > review these drafts at some point or can they be handled completely by > MMUSIC ? That depends entirely on what the final mechanisms start to look like. I would make sure SIPCORE stays aware of the things that end up transported in SIP, and as the drafts mature, continue to re-assess whether pieces of them need to be done in SIPCORE. > Thanks > > -- Flemming > > On 2/26/13 5:10 PM, Mary Barnes wrote: >> Hi all, >> >> We had our review of the DISPATCH-86 topics with the ADs this morning. >> The decision was to dispatch these documents to the MMUSIC WG for >> discussion as potential work items: >> - draft-ivov-dispatch-trickle-ice-sip (currently proposes a new INFO >> event package) >> - draft-ivov-dispatch-sdpfrag (defines application/sdpfrag MIME media >> type) >> >> It made more sense to dispatch to MMUSIC since they are related to >> draft-ivov-mmusic-trickle-ice-00 which is currently under discussion >> as a proposed MMUSIC WG document. And, neither the SIP change nor RFC >> 6086 require that this sort of work be done in SIPCORE. >> >> If you have any questions or comments, please let the ADs know ASAP. >> I will be posting this decision along with the plans for the other >> IETF-86 topics and agenda by tomorrow morning. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> . >> > From worley@shell01.TheWorld.com Wed Feb 27 08:28:58 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 17D4721F8573 for ; Wed, 27 Feb 2013 08:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=0.224, 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 VU6nP0AlziK6 for ; Wed, 27 Feb 2013 08:28:56 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BB24221F847A for ; Wed, 27 Feb 2013 08:28:54 -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 r1RGSIDI013485; Wed, 27 Feb 2013 11:28:20 -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 r1RGSIDT2735654; Wed, 27 Feb 2013 11:28:18 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1RGSH7e2736469; Wed, 27 Feb 2013 11:28:17 -0500 (EST) Date: Wed, 27 Feb 2013 11:28:17 -0500 (EST) Message-Id: <201302271628.r1RGSH7e2736469@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Flemming Andreasen In-reply-to: <512D9E8E.4060200@cisco.com> (fandreas@cisco.com) References: <512D9E8E.4060200@cisco.com> Cc: fluffy@cisco.com, rai-ads@tools.ietf.org, rbarnes@bbn.com, sipcore@ietf.org, mmusic-chairs@tools.ietf.org Subject: Re: [sipcore] Dispatching of draft-ivov-dispatch-trickle-ice-sip-00 and draft-ivov-dispatch-sdpfrag X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:28:58 -0000 > From: Flemming Andreasen > Ok - we'll add them to the MMUSIC agenda. Does any other group need to > review these drafts at some point or can they be handled completely by > MMUSIC ? > From: Robert Sparks > I would make sure SIPCORE stays aware of the things that end up > transported in SIP, and as the drafts mature, continue to re-assess > whether pieces of them need to be done in SIPCORE. RTCWEB seems to want trickle ICE, and RTCWEB will be providing another transport mechanism for trickle ICE updates, so I think they should stay informed as well. Dale From adam@nostrum.com Wed Feb 27 08:35:36 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 80B0F21F8569 for ; Wed, 27 Feb 2013 08:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, SPF_PASS=-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 mFv-7Pzow1k9 for ; Wed, 27 Feb 2013 08:35:35 -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 8290C21F873D for ; Wed, 27 Feb 2013 08:35:35 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1RGZUWR057357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 10:35:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <512E35D2.6080400@nostrum.com> Date: Wed, 27 Feb 2013 10:35:30 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "'SIPCORE'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: draft-rosen-rph-reg-policy@tools.ietf.org Subject: [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: Wed, 27 Feb 2013 16:35:36 -0000 [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 From keith.drage@alcatel-lucent.com Wed Feb 27 11:48: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 5598221F888F for ; Wed, 27 Feb 2013 11:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.307 X-Spam-Level: X-Spam-Status: No, score=-109.307 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 UuBs9rDvpG00 for ; Wed, 27 Feb 2013 11:48:21 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51D21F887F for ; Wed, 27 Feb 2013 11:48:21 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1RJmDZV023047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Feb 2013 20:48:18 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 27 Feb 2013 20:48:16 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , "'SIPCORE'" Date: Wed, 27 Feb 2013 20:48:15 +0100 Thread-Topic: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 Thread-Index: Ac4VCH6yWaz6nTcRQg+DzBdbID6ogwAFs7+w Message-ID: References: <512E35D2.6080400@nostrum.com> In-Reply-To: <512E35D2.6080400@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "draft-rosen-rph-reg-policy@tools.ietf.org" 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: Wed, 27 Feb 2013 19:48:22 -0000 I do not have a problem with relaxing the criteria and therefore we will ne= ed 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 t= his is correct. However that information also needs to appear in the top le= ft of the document. 2) The document gives no background material on why IETF review has been ch= osen, only that it no longer needs to be standards track (Note that I am no= t convinced "Standards Track" was selected in error). Personally I think "S= pecification Required" would be entirely appropriate, however if this is us= ed see comment 3) below. 3) As more relaxed criteria for IANA registration are defined, then materia= l has to be defined to support those reviewing the registration; for a stan= dards track defined protocol, this should be defined in a standards track d= ocument. For example RFC 4412 contains no information on when a new namespa= ce is appropriate, as opposed to reuse of an existing namespaces. I have ce= rtainly been involved in discussions as to whether the "ETS" namespace is r= estricted only to usage of "US government telecommunications service" or wh= ether another government body in a different country with identical require= ments can reuse the same namespace, or whether they have to define a new na= mespace, and RFC 4412 does not answer this. So the proposed update currentl= y contains no additional information (to RFC 4412) on: - what information needs to be provided for a new namespace or priority lev= el; - what criteria need to be met for adopting a new namespace or priority lev= el, 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 Behal= f > 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 >=20 > [as chair] >=20 > 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: >=20 > http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html >=20 > 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: >=20 > http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00 >=20 > (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). >=20 > 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. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian.rosen@neustar.biz Wed Feb 27 12:13:36 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 61F0821F8887 for ; Wed, 27 Feb 2013 12:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rOL5p3Qgw5MY for ; Wed, 27 Feb 2013 12:13:35 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC721F8622 for ; Wed, 27 Feb 2013 12:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361995889; x=1677344784; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=GDuym7Ds2X9PuEwvUcMzy G3eq9ZjfeZ38Hk4/iAIZfQ=; b=Ls2za2Ac5JjE1GxWmviTaIdQ2GOvr1mqgImq7 DAAzCsiNBsgkAnILc0JpMcRkDbjdp2afivR8CvMYgrdfNCBbw== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.16884290; Wed, 27 Feb 2013 15:11:27 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 27 Feb 2013 15:13:24 -0500 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" Date: Wed, 27 Feb 2013 15:13:23 -0500 Thread-Topic: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 Thread-Index: Ac4VJuUF9ubc5PjqT3aUtGqObByLSg== Message-ID: <9BB7865E-2142-4FC3-B846-A8B03B158635@neustar.biz> References: <512E35D2.6080400@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tVAf3U2EbO/TqKZ4yFXXuQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-rosen-rph-reg-policy@tools.ietf.org" , SIPCORE 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: Wed, 27 Feb 2013 20:13:36 -0000 We can fix 1 at AUTH48 if WGLC proceeds. The document doesn't have to say why a particular management policy was cho= sen. 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 a= bout 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 Re= view is adequate, because we do have several different classes of people wh= o care about various aspects of this. While I somewhat agree that 4412 is light on text defining when a new names= pace 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 th= e policy is left at Standards Track, it still doesn't define when a new nam= espace is appropriate. It still doesn't define whether an update to an exi= sting namespace is required. We could start an effort to do a 4412-bis to address these issues, but I wo= uld prefer not to turn this document into that. Brian On Feb 27, 2013, at 2:48 PM, "DRAGE, Keith (Keith)" 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. >=20 > I have the following comments on the document. >=20 > 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. >=20 > 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. >=20 > 3) As more relaxed criteria for IANA registration are defined, then mater= ial has to be defined to support those reviewing the registration; for a st= andards track defined protocol, this should be defined in a standards track= document. For example RFC 4412 contains no information on when a new names= pace 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 requi= rements 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 curren= tly contains no additional information (to RFC 4412) on: >=20 > - what information needs to be provided for a new namespace or priority l= evel; >=20 > - what criteria need to be met for adopting a new namespace or priority l= evel, versus reusing or modifying an existing one. >=20 > 4) Can a new document update an existing namespace with new priority leve= ls or other functionality? I believe this would normally be bad practice fo= r compatibility reasons, but the document does not cover this. >=20 > Keith >=20 >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> 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 >>=20 >> [as chair] >>=20 >> 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: >>=20 >> http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html >>=20 >> 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: >>=20 >> http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00 >>=20 >> (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). >>=20 >> 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. >>=20 >> /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 From rjsparks@nostrum.com Wed Feb 27 14:02:15 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 0BAA021F8838 for ; Wed, 27 Feb 2013 14:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, SPF_PASS=-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 anqIPPuISbtB for ; Wed, 27 Feb 2013 14:02:14 -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 E756C21F8751 for ; Wed, 27 Feb 2013 14:02:13 -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 r1RM2DIT093421 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 16:02:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <512E8265.9000403@nostrum.com> Date: Wed, 27 Feb 2013 16:02:13 -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: <9BB7865E-2142-4FC3-B846-A8B03B158635@neustar.biz> 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: Wed, 27 Feb 2013 22:02:15 -0000 On 2/27/13 2:13 PM, Rosen, Brian wrote: > We can fix 1 at AUTH48 if WGLC proceeds. We'll have opportunity to revise the draft earlier than AUTH48. > > 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)" 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. IETF review is the better path in this case. We're still learning what the guidance we would give an expert reviewer (which would go with specification required) - IETF review lets us move forward and discuss that as we go. If we actually do get many more of these, and it becomes clear both what that guidance would look like and that we don't need IETF-wide review for other reasons, we could shift to Specification Required later. >> >> 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 pkyzivat@alum.mit.edu Wed Feb 27 14:16:11 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 AB89A21F87EA for ; Wed, 27 Feb 2013 14:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 IqVRs1ezQ7-M for ; Wed, 27 Feb 2013 14:16:10 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F321F87E5 for ; Wed, 27 Feb 2013 14:16:01 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 5RQC1l0011vN32cA7aG1so; Wed, 27 Feb 2013 22:16:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([115.193.211.231]) by omta22.emeryville.ca.mail.comcast.net with comcast id 5aDq1l001506YvF8iaDuca; Wed, 27 Feb 2013 22:13:59 +0000 Message-ID: <512E8520.6070801@alum.mit.edu> Date: Thu, 28 Feb 2013 06:13:52 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: sipcore@ietf.org References: <512E35D2.6080400@nostrum.com> In-Reply-To: <512E35D2.6080400@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362003361; bh=A4EIdA0LfBr8NVuMcvCsJUAzvaHJThJD7bk98dP5huQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VN4WqdKBrqCVrCic/Z3pMbCj0SkFxAgWjqXqRibIyVbVqlB9DYkJ2E+4YU/pHKBzU nBDaUl69BzqQUsIqZslu1Yt2WbibLbUhVVlyQswgLEoBN5Lwhot6TC9Jo3WHydA5iZ 38QfXXa+z0GvcZ5A1iMMxtf2S1fzff+plV1DWABgF5CVhahgPi3DOwGlLgCGKt4nDL bhaT8EgKyEjwemeIW0Py0B1arSRBAeORim8GrUzfy9IqGrt9Nzdhe357fJE7HiB7Mf CYn83iLp64yoldaTDhCcdiNvZRKK+s0xt+9IRx/sGIY1Y6uevm/SPZUFaiABGLuUqs SosLYGjbgtaiw== 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: Wed, 27 Feb 2013 22:16:12 -0000 Mostly WFM. At the risk of setting off another long debate with Keith, ISTM that this document should be marked as updating 4412. (In the same way that draft-ietf-sipcore-priority updates 3261.) Otherwise, someone reading 4412 will have no hint that the policies established in that document have been changed. Thanks, Paul On 2/28/13 12:35 AM, Adam Roach wrote: > [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 > From brian.rosen@neustar.biz Wed Feb 27 14:18: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 14FAD21F87BA for ; Wed, 27 Feb 2013 14:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6vN3sVhXRNyS for ; Wed, 27 Feb 2013 14:18:02 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16221F873D for ; Wed, 27 Feb 2013 14:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1362003915; x=1677363427; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=8fQedLtHVwOD0SjkwcX7w aY2PaxksXhqHNG899SIgCY=; b=KhzDndybMNDYjxUuLbkxTE974cEszbyBRU7YY nqgDzC12jwdtJHNRLflMiD6b64HWQyGuxVWL/RSV4DXZb31bQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.21035278; Wed, 27 Feb 2013 17:25:14 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 27 Feb 2013 17:17:57 -0500 From: "Rosen, Brian" To: Paul Kyzivat Date: Wed, 27 Feb 2013 17:17:56 -0500 Thread-Topic: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 Thread-Index: Ac4VOEuxRcLd5lv/RRCdN1qfacuqwA== Message-ID: <268C4958-EA70-4F38-8AF6-18F0DD850F6C@neustar.biz> References: <512E35D2.6080400@nostrum.com> <512E8520.6070801@alum.mit.edu> In-Reply-To: <512E8520.6070801@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: c3fcoySZn9rJzOagfVv7xA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" 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: Wed, 27 Feb 2013 22:18:04 -0000 Yes, we will do that. Brian On Feb 27, 2013, at 5:13 PM, Paul Kyzivat wrote: > Mostly WFM. >=20 > At the risk of setting off another long debate with Keith, ISTM that this= document should be marked as updating 4412. (In the same way that draft-ie= tf-sipcore-priority updates 3261.) Otherwise, someone reading 4412 will hav= e no hint that the policies established in that document have been changed. >=20 > Thanks, > Paul >=20 > On 2/28/13 12:35 AM, Adam Roach wrote: >> [as chair] >>=20 >> 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: >>=20 >> http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html >>=20 >> 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: >>=20 >> http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00 >>=20 >> (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). >>=20 >> 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. >>=20 >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Wed Feb 27 17:19:51 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 E453D21F857C for ; Wed, 27 Feb 2013 17:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.303 X-Spam-Level: X-Spam-Status: No, score=-109.303 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 4yFUbY54QaJk for ; Wed, 27 Feb 2013 17:19:50 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id F29E021F8891 for ; Wed, 27 Feb 2013 17:11:09 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1S15KGI004227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Feb 2013 02:05:20 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 28 Feb 2013 02:05:20 +0100 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" , SIPCORE , "draft-rosen-rph-reg-policy@tools.ietf.org" Date: Thu, 28 Feb 2013 02:05:19 +0100 Thread-Topic: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 Thread-Index: Ac4VJuUF9ubc5PjqT3aUtGqObByLSgAJYzzQ Message-ID: References: <512E35D2.6080400@nostrum.com> <9BB7865E-2142-4FC3-B846-A8B03B158635@neustar.biz> In-Reply-To: <9BB7865E-2142-4FC3-B846-A8B03B158635@neustar.biz> 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.13 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: Thu, 28 Feb 2013 01:19:52 -0000 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 othe= r organization - by the designated expert I am not sure that the designated expert has to be a single expert - it cou= ld be several people - the ADs just need to put it in place. 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 >=20 > We can fix 1 at AUTH48 if WGLC proceeds. >=20 > 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. >=20 > 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 rewrit= e > 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. >=20 > 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. >=20 > Brian >=20 >=20 > On Feb 27, 2013, at 2:48 PM, "DRAGE, Keith (Keith)" lucent.com> wrote: >=20 > > I do not have a problem with relaxing the criteria and therefore we wil= l > 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 tha= t > 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 namespac= e, > 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 tim= e > >> 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