From internet-drafts@ietf.org Mon Oct 1 03:28:24 2012 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 8602C21F8533; Mon, 1 Oct 2012 03:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 N3TYhim4e4m1; Mon, 1 Oct 2012 03:28:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E0521F8600; Mon, 1 Oct 2012 03:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121001102753.8571.73703.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2012 03:27:53 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-04.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, 01 Oct 2012 10:28:24 -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-04.txt Pages : 20 Date : 2012-10-01 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in new scenarios. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Mon Oct 1 03:33:50 2012 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 62D2621F851B for ; Mon, 1 Oct 2012 03:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, 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 nFLaLpbrqrjl for ; Mon, 1 Oct 2012 03:33:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42F5221F8496 for ; Mon, 1 Oct 2012 03:33:49 -0700 (PDT) Received: by lbok13 with SMTP id k13so4352677lbo.31 for ; Mon, 01 Oct 2012 03:33:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=jNKkHPAyKHHHT+/HFF4w9rV5UECGEYE1ydXoifmHuyM=; b=BnYB0C1km6+50dCkQQX5rLzRGyX3pXlQZO6vflP3nu4B3T+Kuju+57ubRjswCGocR4 oXuTuP/pm+RUzeHeM9e+gjW+kpg3+QxSesKd0ZJw0wEeR1AlhlDtH+ezKv4Yc0BWPpo0 kynd5PuZrrA3opnZKJIxfJPBAp8PWDNhvvSluzRzQSZkIk2orj+PnqS01vbLHrsGd+sj avnrPBBd3brYTPNs6W2EnuCUpU4U+YnlqsiV/kkWU38QihwrRrJ6SPJtNphuidTEUBMf 15+wE+cHjw7o8KFE47619XjzN0yqJyjFWxn7ooX3FrST+ChHWIaRaChOwp8x5C6Fvcjs 6ADg== Received: by 10.152.110.74 with SMTP id hy10mr11524982lab.54.1349087628190; Mon, 01 Oct 2012 03:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Mon, 1 Oct 2012 03:33:28 -0700 (PDT) In-Reply-To: <20121001102753.8571.73703.idtracker@ietfa.amsl.com> References: <20121001102753.8571.73703.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Oct 2012 12:33:28 +0200 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl1LdTOBg+E99Bx02Dytcssh92s9tLszzLFoeWVuvdqtv7dwktlelJwGtNrfAyH8qoG6ely Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-04.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, 01 Oct 2012 10:33:50 -0000 Hi all, This new version 04 of the draft-ietf-sipcore-sip-websocket includes the "Updates RFC3261" notation in the heading (since it updates it in section 5.2.3 "Via received parameter"). There were no other open issues. Thanks a lot. 2012/10/1 : > > 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-04.txt > Pages : 20 > Date : 2012-10-01 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities to enable usage of SIP in new > scenarios. > > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-04 > > > 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 pkyzivat@alum.mit.edu Tue Oct 2 09:28:53 2012 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 A0AE021F8508 for ; Tue, 2 Oct 2012 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, 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 YWBjzJTftzvU for ; Tue, 2 Oct 2012 09:28:53 -0700 (PDT) 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 EDE5821F844C for ; Tue, 2 Oct 2012 09:28:52 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id 6Cxy1k0021ap0As57GUw11; Tue, 02 Oct 2012 16:28:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 6GQR1k00o3ZTu2S3iGQRb2; Tue, 02 Oct 2012 16:24:26 +0000 Message-ID: <506B1517.7080405@alum.mit.edu> Date: Tue, 02 Oct 2012 12:23:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:28:53 -0000 I'm sorry I have to do this, but I'm going to start another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01. The reason is that after examining the email records I am concerned that the use cases have not been carefully reviewed for correctness and consistency with the final form of draft-ietf-sipcore-rfc4244bis-10. To ensure that we have that, I am requesting volunteers to review each of the eleven detailed call flows described in sections 3.1 through 3.11 of the document. I am not asking one person to review all eleven, as that would be cruel and unusual punishment. What I am asking is for people to volunteer for particular flows. Obviously I'll need at least one volunteer for each flow, though more than one would be good. When reviewing a flow it is important to verify the following: * the message content is consistent with draft-ietf-sipcore-rfc4244bis-10 * ladder diagram is consistent with the text description of the call flow * message details are consistent with the text description of the call flow * ladder diagram is consistent with the message details - all the messages are consistent with valid sip usage - all messages necessary for valid sip usage are present, or else the omission is noted - each message contains all the header fields and SDP lines necessary for valid sip usage, or else the omission is noted - escaping of special characters in header fields is correct The points marked with "*" are the focus. But the others are also important in any call flow. It is OK if irrelevant detail is omitted as long as it is *indicated* as omitted. Rather than declare in advance when the WGLC will conclude, it will run until we have volunteers for each of the call flows and they have had time to do their review. When you volunteer for a review, please let me know when you commit to having it done. I'm hoping for a week for a review, but I understand it may take longer if you volunteer for several. So if you want this done, PLEASE step up and volunteer to review part of it. And please publicize which parts you are volunteering for. I'll keep tabs and let people know if one they are volunteering for is already covered. Getting the call flows reviewed (and making any needed fixes as a result) is the last gating item to turning this draft over to the ADs for IESG review. And note that the progression of draft-ietf-sipcore-rfc4244bis-10 is also waiting on this. Thanks, Paul From worley@shell01.TheWorld.com Fri Oct 5 12:25:09 2012 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 AE06921F87A5 for ; Fri, 5 Oct 2012 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[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 sPf7oxK2eG5o for ; Fri, 5 Oct 2012 12:25:08 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41621F8671 for ; Fri, 5 Oct 2012 12:25:08 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q95JP16B016758 for ; Fri, 5 Oct 2012 15:25:03 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q95JP1OT4048938; Fri, 5 Oct 2012 15:25:01 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q95JP0244047637; Fri, 5 Oct 2012 15:25:00 -0400 (EDT) Date: Fri, 5 Oct 2012 15:25:00 -0400 (EDT) Message-Id: <201210051925.q95JP0244047637@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] 4244bis-callflows 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, 05 Oct 2012 19:25:09 -0000 I've done a little work on the callflows document. I need some help to iron out a couple of points. 1) There is something wrong with F6 in section 3.2. It's not indented like the messages. And the 3rd History-Info contains "invalidtarget userindex": History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: | | | | | | | | | INVITE F2 | | | |--------------->| | | | | | | | | INVITE F3 | | | |--------------->| | | | | | | | 200 F4 | | | |<---------------| | | | | | | 200 F5 | | | |<---------------| | | | | | | 200 F6 | | | |<---------------| | | | | | | | ACK | | | |--------------->| ACK | | | |--------------->| ACK | | | |--------------->| Figure: Example with a proxy that does not support History-Info Message Details F1 INVITE alice -> atlanta.example.com INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 Contact: Alice Content-Type: application/sdp Content-Length: F2 INVITE atlanta.example.com -> cadiz.example.com INVITE sip:bob@cadiz.example.com SIP/2.0 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 Contact: Alice Content-Type: application/sdp Content-Length: F3 INVITE cadiz.example.com -> Bob INVITE sip:bob@192.0.1.11 SIP/2.0 Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.0.1 History-Info: ;index=1.0.1.1;rc=1.0.1 Contact: Alice Content-Type: application/sdp Content-Length: F4 200 OK Bob -> cadiz.example.com SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.0.1 History-Info: ;index=1.0.1.1;rc=1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F5 200 OK cadiz.example.com -> atlanta.example.com SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.0.1 History-Info: ;index=1.0.1.1;rc=1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F6 200 OK atlanta.example.com -> Alice SIP/2.0 200 OK Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.0.1 History-Info: ;index=1.0.1.1;rc=1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: Question: Item 6 of section 10.3 seems ambiguous to me. Currently, it reads: 6. Missing entity: If the request clearly has a gap in the hi-entry (i.e., the last hi-entry and Request-URI differ), the entity adding an hi-entry MUST add a single index with a value of "0" (i.e., the non-negative integer zero) prior to adding the appropriate index for the action to be taken. For example, if the index of the last hi-entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. Following the reference to it in section 9.1, upon receipt of message F1, cadiz.example.com would have to add this to the message: History-Info: ;index=1.0.1 adding a value of 0 and then the "appropriate index for the action to be taken" (which clearly must be 1 whenever we are doing the section 9.1 processing). Then upon sending F2, cadiz.example.com would have to add History-Info: ;index=1.0.1.1 Is this what is intended, or do we want to have the final History-Info be: History-Info: ;index=1 History-Info: ;index=1.0 History-Info: ;index=1.0.1;rc=1.0.1 using the "0" alone to represent "unknown forwarding/branching at this point"? 3) Here is another example, where a request is forked by a non-supporting proxy. Unfortunately, it leads to a situation where there are duplicate indexes in the History-Info list. This is an example where a proxy/registrar forks the call to several alternative destinations. The proxy/registrar does not support History-Info but the destinations do. Alice atlanta.example.com biloxi.example.com Bob Office | | | | | | INVITE F1 | | | | |--------------->| | | | | | | | | | | INVITE F2 | | | | |--------------->| | | | | | | | | | | INVITE F3 | | | | |--------------->| | | | | | | | | | 180 Ringing F4 | | | | |<---------------| | | | | | | | | 180 Ringing F5 | | | |<---------------| | | | | | | | | 180 Ringing F6 | | | |<---------------| | | | | | | | | | | | 408 Timeout F7 | | | | |<---------------| | | | | | | | | | INVITE F8 | | | | |------------------------>| | | | | | | | | 180 Ringing F9 | | | | |<------------------------| | | | | | | | 180 Ringing F10 | | | |<---------------| | | | | | | | | 180 Ringing F11 | | | |<---------------| | | | | | | | | | | | 200 OK F12 | | | | |<------------------------| | | | | | | | 200 OK F13 | | | | |<---------------| | | | | | | | | 200 OK F14 | | | | |<---------------| | | | | | | | | | ACK | | | | |--------------->| ACK | | | | |--------------->| ACK | | | | |------------------------>| Example with forking by non-supporting proxy Note that atlanta.example.com and all the UAs support History-Info; biloxi.example.com does not. F1 INVITE alice -> atlanta.example.com INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 Contact: Alice Content-Type: application/sdp Content-Length: F2 INVITE atlanta.example.com -> biloxi.example.com INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: F3 INVITE biloxi.example.com -> Bob INVITE sip:bob@192.0.1.11 SIP/2.0 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE Expires: 30 History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: F4 180 Ringing bob -> biloxi.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F5 180 Ringing biloxi.example.com -> atlanta.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F6 180 Ringing atlanta.example.com -> alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: Note that atlanta added a Reason parameter to entry 1.1, due to receiving a 180 from that branch of the call. F4 408 Timeout bob -> biloxi.example.com SIP/2.0 408 Timeout Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F8 INVITE biloxi.example.com -> office INVITE sip:office@192.0.1.123 SIP/2.0 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE Expires: 30 History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: F9 180 Ringing office -> biloxi.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: F10 180 Ringing biloxi.example.com -> atlanta.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: F11 180 Ringing atlanta.example.com -> alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: atlanta needs to record a Reason specifying response 180 in index 1.1. It presumably replaces the previous Reason 180 in that entry. At this point, there is a problem regarding sorting the History-Info entries correctly: atlanta.example.com added ";index=1.1.0.1" to its cache due to receiving F5, and added ";index=1.1.0.1" due to receiving F10, but there is no defined ordering between them. Dale From pkyzivat@alum.mit.edu Fri Oct 5 13:03:29 2012 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 D223221F8443 for ; Fri, 5 Oct 2012 13:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, 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 t3A788kKTr21 for ; Fri, 5 Oct 2012 13:03:28 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4716221F8442 for ; Fri, 5 Oct 2012 13:03:28 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id 7PZ61k0030mv7h051Y3YXg; Fri, 05 Oct 2012 20:03:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 7XyK1k00s3ZTu2S3XXyLy9; Fri, 05 Oct 2012 19:58:20 +0000 Message-ID: <506F3BE2.2070909@alum.mit.edu> Date: Fri, 05 Oct 2012 15:58:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210051925.q95JP0244047637@shell01.TheWorld.com> In-Reply-To: <201210051925.q95JP0244047637@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] 4244bis-callflows 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, 05 Oct 2012 20:03:30 -0000 Hi Dale, Thanks for the review. I'm trying to discern what sort of coverage this gives us on the document as a whole. Is the issue you raise with the 3.2 case the only issue you have with it? Do you consider it to otherwise be ok? IIUC, the other cases you give are *new* cases that you think are needed. Is that right? And, does your lack of mention of any other cases imply that you have not considered them? Or that you looked at them and found them ok? Thanks, Paul On 10/5/12 3:25 PM, Dale R. Worley wrote: > I've done a little work on the callflows document. I need some help > to iron out a couple of points. > > 1) There is something wrong with F6 in section 3.2. It's not indented > like the messages. And the 3rd History-Info contains "invalidtarget > userindex": > > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: 2) Here is another example I think is needed. It shows the operation > of the rule for when a supporting entity receives a request proxied > through a non-supporting entity. The index values are constructed > according to the text of 4244bis, but I'm not sure that the wording > exactly matches our intentions. > This example provides a basic call scenario without forking. The > distinguishing feature is that the first proxy changes the > request-URI but does not support History-Info. > > > Alice atlanta.example.com cadiz.example.com Bob > | | | | > | INVITE F1 | | | > |--------------->| | | > | | | | > | | INVITE F2 | | > | |--------------->| | > | | | | > | | | INVITE F3 | > | | |--------------->| > | | | | > | | | 200 F4 | > | | |<---------------| > | | | | > | | 200 F5 | | > | |<---------------| | > | | | | > | 200 F6 | | | > |<---------------| | | > | | | | > | ACK | | | > |--------------->| ACK | | > | |--------------->| ACK | > | | |--------------->| > > Figure: Example with a proxy that does not support History-Info > > > Message Details > > F1 INVITE alice -> atlanta.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > F2 INVITE atlanta.example.com -> cadiz.example.com > > INVITE sip:bob@cadiz.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > F3 INVITE cadiz.example.com -> Bob > > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > F4 200 OK Bob -> cadiz.example.com > > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > > > F5 200 OK cadiz.example.com -> atlanta.example.com > > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F6 200 OK atlanta.example.com -> Alice > > SIP/2.0 200 OK > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > Question: Item 6 of section 10.3 seems ambiguous to me. Currently, > it reads: > > 6. Missing entity: If the request clearly has a gap in the hi-entry > (i.e., the last hi-entry and Request-URI differ), the entity > adding an hi-entry MUST add a single index with a value of "0" > (i.e., the non-negative integer zero) prior to adding the > appropriate index for the action to be taken. For example, if > the index of the last hi-entry in the request received was 1.1.2 > and there was a missing hi-entry and the request was being > forwarded to the next hop, the resulting index will be 1.1.2.0.1. > > Following the reference to it in section 9.1, upon receipt of message > F1, cadiz.example.com would have to add this to the message: > > History-Info: ;index=1.0.1 > > adding a value of 0 and then the "appropriate index for the action to > be taken" (which clearly must be 1 whenever we are doing the section > 9.1 processing). > > Then upon sending F2, cadiz.example.com would have to add > > History-Info: ;index=1.0.1.1 > > Is this what is intended, or do we want to have the final History-Info > be: > > History-Info: ;index=1 > History-Info: ;index=1.0 > History-Info: ;index=1.0.1;rc=1.0.1 > > using the "0" alone to represent "unknown forwarding/branching at this > point"? > > 3) Here is another example, where a request is forked by a > non-supporting proxy. Unfortunately, it leads to a situation where > there are duplicate indexes in the History-Info list. > This is an example where a proxy/registrar forks the call to > several alternative destinations. The proxy/registrar does not > support History-Info but the destinations do. > > Alice atlanta.example.com biloxi.example.com Bob Office > | | | | | > | INVITE F1 | | | | > |--------------->| | | | > | | | | | > | | INVITE F2 | | | > | |--------------->| | | > | | | | | > | | | INVITE F3 | | > | | |--------------->| | > | | | | | > | | | 180 Ringing F4 | | > | | |<---------------| | > | | | | | > | | 180 Ringing F5 | | > | |<---------------| | | > | | | | | > | 180 Ringing F6 | | | > |<---------------| | | | > | | | | | > | | | 408 Timeout F7 | | > | | |<---------------| | > | | | | | > | | | INVITE F8 | | > | | |------------------------>| > | | | | | > | | | 180 Ringing F9 | | > | | |<------------------------| > | | | | | > | | 180 Ringing F10 | | > | |<---------------| | | > | | | | | > | 180 Ringing F11 | | | > |<---------------| | | | > | | | | | > | | | 200 OK F12 | | > | | |<------------------------| > | | | | | > | | 200 OK F13 | | | > | |<---------------| | | > | | | | | > | 200 OK F14 | | | | > |<---------------| | | | > | | | | | > | ACK | | | | > |--------------->| ACK | | | > | |--------------->| ACK | | > | | |------------------------>| > > Example with forking by non-supporting proxy > > Note that atlanta.example.com and all the UAs support History-Info; > biloxi.example.com does not. > > > F1 INVITE alice -> atlanta.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > F2 INVITE atlanta.example.com -> biloxi.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > > F3 INVITE biloxi.example.com -> Bob > > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > F4 180 Ringing bob -> biloxi.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F5 180 Ringing biloxi.example.com -> atlanta.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F6 180 Ringing atlanta.example.com -> alice > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > Note that atlanta added a Reason parameter to entry 1.1, due to > receiving a 180 from that branch of the call. > > F4 408 Timeout bob -> biloxi.example.com > > SIP/2.0 408 Timeout > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F8 INVITE biloxi.example.com -> office > > INVITE sip:office@192.0.1.123 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > F9 180 Ringing office -> biloxi.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > > F10 180 Ringing biloxi.example.com -> atlanta.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > > F11 180 Ringing atlanta.example.com -> alice > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > atlanta needs to record a Reason specifying response 180 in index > 1.1. It presumably replaces the previous Reason 180 in that entry. > > At this point, there is a problem regarding sorting the History-Info > entries correctly: atlanta.example.com added > ";index=1.1.0.1" to its cache due to receiving F5, > and added ";index=1.1.0.1" due to receiving > F10, but there is no defined ordering between them. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Fri Oct 5 13:22:09 2012 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 1E22C21F8681 for ; Fri, 5 Oct 2012 13:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, 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 H-i-YMg5dke5 for ; Fri, 5 Oct 2012 13:22:08 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 67F9721F8667 for ; Fri, 5 Oct 2012 13:22:08 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta04.westchester.pa.mail.comcast.net with comcast id 7PvD1k0040vyq2s54YNBeN; Fri, 05 Oct 2012 20:22:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 7YHW1k0093ZTu2S3RYHWhM; Fri, 05 Oct 2012 20:17:30 +0000 Message-ID: <506F4041.4040905@alum.mit.edu> Date: Fri, 05 Oct 2012 16:17:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: SIPCORE References: <506B1517.7080405@alum.mit.edu> In-Reply-To: <506B1517.7080405@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 20:22:09 -0000 Hey people, it's been several days and the only response I have gotten with any actual review content is one from Dale today. This is gating for 4244bis, so if you want that then PLEASE volunteer to work on this. I'll be happy to have people volunteer to review a single case. Thanks, Paul On 10/2/12 12:23 PM, Paul Kyzivat wrote: > I'm sorry I have to do this, but I'm going to start another WGLC for > draft-ietf-sipcore-rfc4244bis-callflows-01. > > The reason is that after examining the email records I am concerned that > the use cases have not been carefully reviewed for correctness and > consistency with the final form of draft-ietf-sipcore-rfc4244bis-10. > > To ensure that we have that, I am requesting volunteers to review each > of the eleven detailed call flows described in sections 3.1 through 3.11 > of the document. I am not asking one person to review all eleven, as > that would be cruel and unusual punishment. What I am asking is for > people to volunteer for particular flows. Obviously I'll need at least > one volunteer for each flow, though more than one would be good. > > When reviewing a flow it is important to verify the following: > * the message content is consistent with > draft-ietf-sipcore-rfc4244bis-10 > * ladder diagram is consistent with the text description > of the call flow > * message details are consistent with the text description > of the call flow > * ladder diagram is consistent with the message details > - all the messages are consistent with valid sip usage > - all messages necessary for valid sip usage are present, > or else the omission is noted > - each message contains all the header fields and SDP lines > necessary for valid sip usage, or else the omission is noted > - escaping of special characters in header fields is correct > > The points marked with "*" are the focus. But the others are also > important in any call flow. It is OK if irrelevant detail is omitted as > long as it is *indicated* as omitted. > > Rather than declare in advance when the WGLC will conclude, it will run > until we have volunteers for each of the call flows and they have had > time to do their review. When you volunteer for a review, please let me > know when you commit to having it done. I'm hoping for a week for a > review, but I understand it may take longer if you volunteer for several. > > So if you want this done, PLEASE step up and volunteer to review part of > it. And please publicize which parts you are volunteering for. I'll keep > tabs and let people know if one they are volunteering for is already > covered. > > Getting the call flows reviewed (and making any needed fixes as a > result) is the last gating item to turning this draft over to the ADs > for IESG review. And note that the progression of > draft-ietf-sipcore-rfc4244bis-10 is also waiting on this. > > Thanks, > Paul > From dean.willis@softarmor.com Fri Oct 5 14:36:13 2012 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 796FD21F86BB for ; Fri, 5 Oct 2012 14:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 1xIL7M13iXBX for ; Fri, 5 Oct 2012 14:36:12 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B76D621F86B5 for ; Fri, 5 Oct 2012 14:36:12 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2641254oag.31 for ; Fri, 05 Oct 2012 14:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=B+uMjANxomwSdxhxTk8vuz0JCeuK5JSBOmeedZJ6uXk=; b=Zuli1xwfTNQkLetWcHlRq08CdP2Z+aBHv1VrZNKEWEKZmrm3sAcJlNFqLzbbelxh1h khUidh71rw326XhHWrjZ1eyF4UI2VbYqO+VIsDzUqSTYB5MymMdDLe37u0ywOjkTHy1o NnKwVksMD5BeF8P1OjEhCUviPN3kcvYDwmIUU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=B+uMjANxomwSdxhxTk8vuz0JCeuK5JSBOmeedZJ6uXk=; b=LkwsFYhNl3PqILU0WEmEtIAtE78OLqT+zPmnz2G6M4k4Xu5O6mcErsn4WPv9bk9n3j zhdn4ynD2iB6EqYFmf6CGAhsLJeq7TG0Vw9gjMFWxgZhc75fNryOwbeVK0R7L4N6eIJG t4TM3qfyV2YSwiPv2J68e+ng8CYItsAJthDZmv+Lz4mHJ2ZegoPvIf8frinufvfPHU5/ O8V5SEJtAaGqvqqODB1cCnN+VFrfI2xw3K/FWqO7UClh8mfqOXTkoE8T2gLlU2ECuEBc 77nUHD5smAcyc9p2KcQ3wjHR8khjg2EjWjUjYuPkJe4DLEX/36/PnNlpPivsq5pxqxOa qoqg== Received: by 10.182.231.65 with SMTP id te1mr8125022obc.86.1349472972165; Fri, 05 Oct 2012 14:36:12 -0700 (PDT) Received: from [192.168.2.105] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPS id hz6sm10498821obb.1.2012.10.05.14.36.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 14:36:11 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <8607A927-BCD8-4C72-838A-38DA6C4F70B8@softarmor.com> Date: Fri, 5 Oct 2012 16:36:13 -0500 To: sipcore@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkqPbcVpGuI7jUWGQ4objCje9TpkAwrZ25m/yBG0r7fZH7mb65YUmYmsjb88V/BJ5Wu0Ypw Subject: [sipcore] Any clue on recent attack on Callcentric? 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, 05 Oct 2012 21:36:13 -0000 I have a line hosted by Callcentric in the US. They're reporting a new = and successful SIP-protocol DOS attack: "For the past two days we have been experiencing a sophisticated type of = attack. As soon we noticed the first attempt we commenced an immediate = physical upgrade to all of our servers increasing capacity and CPU power = by a factor of four in addition to other precautions. Unfortunately even = though this is similar to a "typical" DDoS attack it is targeted = specifically at the SIP protocol and causes server load to increase to = 100% within 1 minute of initiation. As such, standard and extraordinary = prevention measures were unable to prevent it. We do not know the = specific methodology of the attack but are aware that it is *similar* in = effect to a DNS TRASH flood attack. We are performing forensic analysis = on the data we have and are capturing traffic to find an exact reason = and solution." Anybody have a clue what's happening? Is there a protocol design flaw = here that we need to consider?= From lishitao@huawei.com Mon Oct 8 00:28:49 2012 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 219D721F857E for ; Mon, 8 Oct 2012 00:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 e5ea-zZ5lujO for ; Mon, 8 Oct 2012 00:28:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2049221F8551 for ; Mon, 8 Oct 2012 00:28:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALK49963; Mon, 08 Oct 2012 07:28:44 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 08:28:27 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 08:28:38 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.56]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 15:28:34 +0800 From: Lishitao To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Paul Kyzivat Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt Thread-Index: AQHNjPYQ7gNsvsmFIEWk/JnUAeqm2Jd+WPsAgAl9KBD//7ncgIAOHwBQgABZZQCAB8e5IIAB5sAAgAGDYACADfcukA== Date: Mon, 8 Oct 2012 07:28:33 +0000 Message-ID: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> <5065F3AC.5080601@alum.mit.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:28:49 -0000 aGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K PiBPZiBJP2FraSBCYXogQ2FzdGlsbG8NCj4gU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMzAsIDIw MTIgMjowNiBBTQ0KPiBUbzogUGF1bCBLeXppdmF0DQo+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBjb3JlLXNp cC13ZWJzb2NrZXQtMDMudHh0DQo+IA0KPiAyMDEyLzkvMjggUGF1bCBLeXppdmF0IDxwa3l6aXZh dEBhbHVtLm1pdC5lZHU+Og0KPiA+IElmIHlvdSBhdHRlbXB0IHRvIGNvbmN1cnJlbnRseSByZWdp c3RlciBpbnN0YW5jZXMgZnJvbSBtdWx0aXBsZSB3aW5kb3dzIG9uDQo+ID4gdGhlIHNhbWUgbWFj aGluZSwgaXQgd2lsbCBiZSBhIHByb2JsZW0gaWYgdGhleSB1c2UgdGhlIHNhbWUgaW5zdGFuY2VJ RCwNCj4gPiB1bmxlc3MgdGhleSBjYW4gY29vcmRpbmF0ZSBhbmQgc2hhcmUgYSBzaW5nbGUgcmVn aXN0cmF0aW9uLg0KPiANCj4gSGkgUGF1bCwgdGhlcmUgaXMgYSBuZXcgZHJhZnQgZm9yIFdlYlNv Y2tldCB0aGF0IGFsbG93cyBkaWZmZXJlbnQNCj4gImNsaWVudHMiIHJ1bm5pbmcgaW4gdGhlIHNh bWUgYnJvd3NlciAoaS5lLiB1c2luZyBtdWx0aXBsZSB0YWJzKSB0bw0KPiBzaGFyZSB0aGUgc2Ft ZSBXZWJTb2NrZXQgY29ubmVjdGlvbiB0byB0aGUgc2FtZSBzZXJ2ZXIgYnkgdXNpbmcNCj4gbXVs dGlwbGV4YXRpb246DQo+IA0KQXMgaXQgbWVudGlvbmVkLCBpdCBvbmx5IGFsbG93IGRpZmZlcmVu dCAiY2xpZW50cyIgcnVubmluZyBpbiB0aGUgc2FtZSBicm93c2VyLCBidXQgdGhlIGNhc2Ugbm93 IGlzIGlmIEkgdHJ5IHRvIG9wZW4gbXVsdGlwbGUgd2luZG93cyhicm93c2VycyksIGFuZCByZWdp c3RlciB1c2luZyB0aGUgc2FtZSBTSVAgVVJJLCBpbiB0aGlzIGNhc2UsIEkgZG9u4oCZdCB0aGlu ayB3ZWJzb2NrZXQtbXVsdGlwbGV4aW5nIGNhbiBiZSB1c2VkLg0KDQpSZWdhcmRzDQpzaGl0YW8N Cg== From worley@shell01.TheWorld.com Mon Oct 8 11:24:04 2012 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 E990A21F87CD for ; Mon, 8 Oct 2012 11:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[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 TKWuMKbSf5Gr for ; Mon, 8 Oct 2012 11:24:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 45DCE21F87C7 for ; Mon, 8 Oct 2012 11:24:01 -0700 (PDT) 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 q98INeWx027131; Mon, 8 Oct 2012 14:23:42 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q98INenF4189571; Mon, 8 Oct 2012 14:23:40 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q98INdXE4220851; Mon, 8 Oct 2012 14:23:39 -0400 (EDT) Date: Mon, 8 Oct 2012 14:23:39 -0400 (EDT) Message-Id: <201210081823.q98INdXE4220851@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <506F3BE2.2070909@alum.mit.edu> (pkyzivat@alum.mit.edu) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 08 Oct 2012 18:24:04 -0000 > From: Paul Kyzivat > > Thanks for the review. > I'm trying to discern what sort of coverage this gives us on the > document as a whole. > > Is the issue you raise with the 3.2 case the only issue you have > with > it? Do you consider it to otherwise be ok? > > IIUC, the other cases you give are *new* cases that you think are > needed. Is that right? > > And, does your lack of mention of any other cases imply that you > have > not considered them? Or that you looked at them and found them ok? At this point, I've only looked at 4244bis-callflows enough to see that there are no cases exercising the rules that deal with non-supporting proxies. While trying to write up examples of that, I found an error in the algorithms of 4244bis, and error that doesn't have an obvious fix. Dale From pkyzivat@alum.mit.edu Mon Oct 8 11:45:57 2012 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 10E3321F8845 for ; Mon, 8 Oct 2012 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Dt+MSyO344+a for ; Mon, 8 Oct 2012 11:45:56 -0700 (PDT) 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 7799421F881F for ; Mon, 8 Oct 2012 11:45:56 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8e2m1k0080cZkys53im0zM; Mon, 08 Oct 2012 18:46:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 8igu1k00n3ZTu2S3WiguGr; Mon, 08 Oct 2012 18:40:54 +0000 Message-ID: <50731E36.1070702@alum.mit.edu> Date: Mon, 08 Oct 2012 14:40:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> In-Reply-To: <201210081823.q98INdXE4220851@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Dale R. Worley" Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:45:57 -0000 On 10/8/12 2:23 PM, Dale R. Worley wrote: > At this point, I've only looked at 4244bis-callflows enough to see > that there are no cases exercising the rules that deal with > non-supporting proxies. While trying to write up examples of that, I > found an error in the algorithms of 4244bis, and error that doesn't > have an obvious fix. Thanks Dale! EVERYBODY INTERESTED IN 4244bis: This is an example of why we NEED to have careful reviews of the callflows. So far I have been deafened by the silence. There was quite a bit of enthusiasm for both the bis and the callflows as long as it only took an email containing "+1". Who, other than the authors, wants these enough to do some work??? Thanks, Paul (as co-chair) From mary.ietf.barnes@gmail.com Mon Oct 8 12:08:42 2012 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 2F78C21F8513 for ; Mon, 8 Oct 2012 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k1Mo9lG9UX4v for ; Mon, 8 Oct 2012 12:08:41 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41CE721F8510 for ; Mon, 8 Oct 2012 12:08:41 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2749244lam.31 for ; Mon, 08 Oct 2012 12:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qk8xqdKaHDNRUyXlVmmgjQkdfUXE56GkJ0CKls1lGcU=; b=aFST+mG2ItwBVtLGC0qB7vDu7ofwHCg+K0cTSk8f0TbJx6fSfPfZY8MtalcsWAXhlK 75VBe9aoJSMn5exI3R6EbY2z6MB73QXdRtKU0pmJb4rOsSvDdAhU57oTE4l/P30rsFx2 blAJECPBBC7HNITbGl8UEOEt3Pjno/Pb9vGOXwbToCRWG113QPgrTaXj+9ZLgi+y/2x/ Unjl2pBDNwW39o2rqFYdQ+6PH4Z4OHqMFv9ibuhXrbyjdZFgy23dM78vlxl3Ukbo0+Vq 7wBcifO27g5fGMpJHW5caUet4GAzFUn+pvj2qn7IrufkhPub9FhO64AnOMU2XI+/OO1A BlZg== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr14552023lab.30.1349723320238; Mon, 08 Oct 2012 12:08:40 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 12:08:40 -0700 (PDT) In-Reply-To: <201210081823.q98INdXE4220851@shell01.TheWorld.com> References: <506F3BE2.2070909@alum.mit.edu> <201210081823.q98INdXE4220851@shell01.TheWorld.com> Date: Mon, 8 Oct 2012 14:08:40 -0500 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=e89a8f2346650c42b904cb90f39b Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 08 Oct 2012 19:08:42 -0000 --e89a8f2346650c42b904cb90f39b Content-Type: text/plain; charset=ISO-8859-1 I'm confused as to the issue you noted where there isn't an obvious fix - can you clarify what that is? I'll respond inline to your detailed review. I will also note that 4244 also didn't have examples of a non-supporting proxy and it's not the usual that we have those examples in any of our documents when we are defining optional headers. Mary. On Mon, Oct 8, 2012 at 1:23 PM, Dale R. Worley wrote: > > From: Paul Kyzivat > > > > Thanks for the review. > > I'm trying to discern what sort of coverage this gives us on the > > document as a whole. > > > > Is the issue you raise with the 3.2 case the only issue you have > > with > > it? Do you consider it to otherwise be ok? > > > > IIUC, the other cases you give are *new* cases that you think are > > needed. Is that right? > > > > And, does your lack of mention of any other cases imply that you > > have > > not considered them? Or that you looked at them and found them ok? > > At this point, I've only looked at 4244bis-callflows enough to see > that there are no cases exercising the rules that deal with > non-supporting proxies. While trying to write up examples of that, I > found an error in the algorithms of 4244bis, and error that doesn't > have an obvious fix. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --e89a8f2346650c42b904cb90f39b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm confused as to the issue you noted where there isn't an obvious= fix - can you clarify what that is? =A0I'll respond inline to your det= ailed review.

I will also note that 4244 also didn't= have examples of a non-supporting proxy and it's not the usual that we= have those examples in any of our documents when we are defining optional = headers.=A0

Mary.=A0

On Mon,= Oct 8, 2012 at 1:23 PM, Dale R. Worley <worley@ariadne.com> wrote:
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>
> Thanks for the review.
> I'm trying to discern what sort of coverage this gives us on the > document as a whole.
>
> Is the issue you raise with the 3.2 case the only issue you have
> with
> it? Do you consider it to otherwise be ok?
>
> IIUC, the other cases you give are *new* cases that you think are
> needed. Is that right?
>
> And, does your lack of mention of any other cases imply that you
> have
> not considered them? Or that you looked at them and found them ok?

At this point, I've only looked at 4244bis-callflows enough to se= e
that there are no cases exercising the rules that deal with
non-supporting proxies. =A0While trying to write up examples of that, I
found an error in the algorithms of 4244bis, and error that doesn't
have an obvious fix.

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

--e89a8f2346650c42b904cb90f39b-- From shida@ntt-at.com Mon Oct 8 17:12:33 2012 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 964FC1F0C4A for ; Mon, 8 Oct 2012 17:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 4uWIOMuOuSjI for ; Mon, 8 Oct 2012 17:12:31 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 08E041F0C73 for ; Mon, 8 Oct 2012 17:12:27 -0700 (PDT) Received: from [118.109.76.216] (port=52918 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TLNQw-0000Y6-7k; Mon, 08 Oct 2012 19:12:27 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_42A0068C-6984-4B70-915E-9A22EBBDFE72" From: Shida Schubert In-Reply-To: <201210051925.q95JP0244047637@shell01.TheWorld.com> Date: Tue, 9 Oct 2012 09:11:27 +0900 Message-Id: References: <201210051925.q95JP0244047637@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.17]) [118.109.76.216]:52918 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 09 Oct 2012 00:12:33 -0000 --Apple-Mail=_42A0068C-6984-4B70-915E-9A22EBBDFE72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dale; Thanks for your review, my comments inline.. On Oct 6, 2012, at 4:25 AM, Dale R. Worley wrote: > I've done a little work on the callflows document. I need some help > to iron out a couple of points. >=20 > 1) There is something wrong with F6 in section 3.2. It's not indented > like the messages. And the 3rd History-Info contains "invalidtarget > userindex": >=20 > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: =20 It was supposed to be = ;index=3D1.1.1;rc=3D1.1 > 2) Here is another example I think is needed. It shows the operation > of the rule for when a supporting entity receives a request proxied > through a non-supporting entity. The index values are constructed > according to the text of 4244bis, but I'm not sure that the wording > exactly matches our intentions. >=20 > This example provides a basic call scenario without forking. The > distinguishing feature is that the first proxy changes the > request-URI but does not support History-Info. >=20 >=20 > Alice atlanta.example.com cadiz.example.com Bob > | | | | > | INVITE F1 | | | > |--------------->| | | > | | | | > | | INVITE F2 | | > | |--------------->| | > | | | | > | | | INVITE F3 | > | | |--------------->| > | | | | > | | | 200 F4 | > | | |<---------------| > | | | | > | | 200 F5 | | > | |<---------------| | > | | | | > | 200 F6 | | | > |<---------------| | | > | | | | > | ACK | | | > |--------------->| ACK | | > | |--------------->| ACK | > | | |--------------->| >=20 > Figure: Example with a proxy that does not support History-Info >=20 >=20 > Message Details >=20 > F1 INVITE alice -> atlanta.example.com >=20 > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 >=20 >=20 > F2 INVITE atlanta.example.com -> cadiz.example.com >=20 > INVITE sip:bob@cadiz.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 >=20 >=20 > F3 INVITE cadiz.example.com -> Bob >=20 > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=3Dz9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.0.1 > History-Info: ;index=3D1.0.1.1;rc=3D1.0.1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F4 200 OK Bob -> cadiz.example.com >=20 > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=3Dz9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.0.1 > History-Info: ;index=3D1.0.1.1;rc=3D1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 >=20 >=20 >=20 > F5 200 OK cadiz.example.com -> atlanta.example.com >=20 > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.0.1 > History-Info: ;index=3D1.0.1.1;rc=3D1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F6 200 OK atlanta.example.com -> Alice >=20 > SIP/2.0 200 OK > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.0.1 > History-Info: ;index=3D1.0.1.1;rc=3D1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 > Question: Item 6 of section 10.3 seems ambiguous to me. Currently, > it reads: >=20 > 6. Missing entity: If the request clearly has a gap in the hi-entry > (i.e., the last hi-entry and Request-URI differ), the entity > adding an hi-entry MUST add a single index with a value of "0" > (i.e., the non-negative integer zero) prior to adding the > appropriate index for the action to be taken. For example, if > the index of the last hi-entry in the request received was 1.1.2 > and there was a missing hi-entry and the request was being > forwarded to the next hop, the resulting index will be = 1.1.2.0.1. >=20 > Following the reference to it in section 9.1, upon receipt of message > F1, cadiz.example.com would have to add this to the message: >=20 > History-Info: ;index=3D1.0.1 >=20 > adding a value of 0 and then the "appropriate index for the action to > be taken" (which clearly must be 1 whenever we are doing the section > 9.1 processing). >=20 > Then upon sending F2, cadiz.example.com would have to add >=20 > History-Info: ;index=3D1.0.1.1 >=20 > Is this what is intended, or do we want to have the final History-Info > be: >=20 > History-Info: ;index=3D1 > History-Info: ;index=3D1.0 > History-Info: ;index=3D1.0.1;rc=3D1.0.1 >=20 > using the "0" alone to represent "unknown forwarding/branching at this > point"? I thinks this is a useful example.=20 As for the indexing the gap, I think we need the 1 as the=20 draft currently specifies.=20 The receiving entity can in fact, if able to identify the forked = message=20 to be the same message, provide appropriate index. (looking at the=20 dialog identifier etc.) For example, if the call was forked upstream and reaches the=20 same entity downstream, the downstream entity by identifying=20 the request to be sourced from the same message, can add=20 unique index. e.g. 1.0.1 to the first receiving forked request 1.0.2 to the next >=20 > 3) Here is another example, where a request is forked by a > non-supporting proxy. Unfortunately, it leads to a situation where > there are duplicate indexes in the History-Info list. >=20 > This is an example where a proxy/registrar forks the call to > several alternative destinations. The proxy/registrar does not > support History-Info but the destinations do. >=20 > Alice atlanta.example.com biloxi.example.com Bob Office > | | | | | > | INVITE F1 | | | | > |--------------->| | | | > | | | | | > | | INVITE F2 | | | > | |--------------->| | | > | | | | | > | | | INVITE F3 | | > | | |--------------->| | > | | | | | > | | | 180 Ringing F4 | | > | | |<---------------| | > | | | | | > | | 180 Ringing F5 | | > | |<---------------| | | > | | | | | > | 180 Ringing F6 | | | > |<---------------| | | | > | | | | | > | | | 408 Timeout F7 | | > | | |<---------------| | > | | | | | > | | | INVITE F8 | | > | | |------------------------>| > | | | | | > | | | 180 Ringing F9 | | > | | |<------------------------| > | | | | | > | | 180 Ringing F10 | | > | |<---------------| | | > | | | | | > | 180 Ringing F11 | | | > |<---------------| | | | > | | | | | > | | | 200 OK F12 | | > | | |<------------------------| > | | | | | > | | 200 OK F13 | | | > | |<---------------| | | > | | | | | > | 200 OK F14 | | | | > |<---------------| | | | > | | | | | > | ACK | | | | > |--------------->| ACK | | | > | |--------------->| ACK | | > | | |------------------------>| >=20 > Example with forking by non-supporting proxy >=20 > Note that atlanta.example.com and all the UAs support History-Info; > biloxi.example.com does not. >=20 >=20 > F1 INVITE alice -> atlanta.example.com >=20 > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 > F2 INVITE atlanta.example.com -> biloxi.example.com >=20 > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 >=20 >=20 >=20 > F3 INVITE biloxi.example.com -> Bob >=20 > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 > F4 180 Ringing bob -> biloxi.example.com >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F5 180 Ringing biloxi.example.com -> atlanta.example.com >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F6 180 Ringing atlanta.example.com -> alice >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: = ;index=3D1.1;rc=3D1= > History-Info: ;index=3D1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 > Note that atlanta added a Reason parameter to entry 1.1, due to > receiving a 180 from that branch of the call. >=20 > F4 408 Timeout bob -> biloxi.example.com >=20 > SIP/2.0 408 Timeout > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F8 INVITE biloxi.example.com -> office >=20 > INVITE sip:office@192.0.1.123 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F9 180 Ringing office -> biloxi.example.com >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F10 180 Ringing biloxi.example.com -> atlanta.example.com >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > >=20 >=20 > F11 180 Ringing atlanta.example.com -> alice >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3D22 > To: Bob ;tag=3D33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: = ;index=3D1.1;rc=3D1= > History-Info: ;index=3D1.1.0.1 > History-Info: ;index=3D1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > >=20 > atlanta needs to record a Reason specifying response 180 in index > 1.1. It presumably replaces the previous Reason 180 in that entry. >=20 > At this point, there is a problem regarding sorting the History-Info > entries correctly: atlanta.example.com added > ";index=3D1.1.0.1" to its cache due to receiving = F5, > and added ";index=3D1.1.0.1" due to receiving > F10, but there is no defined ordering between them. Hmm.. I really don't see the issues here.=20 Sure, there are duplicate entries but receiving entity and sending=20 entity can both get useful information out of this.=20 Receiving entity (UAS) The request was sent to bob but ultimately was received=20 at office (Because UAS serving office knows that it formed a=20 dialog with alice). It can see that path it took.. =20 Sending entity (UAC) Again it knows that it has established a dialog with office=20 and depending on how it is implemented, it will probably=20 knows that bob was tried as well.=20 =20 I see that even with the duplicate entries, entities that are likely=20 to utilize the information can make use of the H-I entries.=20 Thanks for your comments Shida >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_42A0068C-6984-4B70-915E-9A22EBBDFE72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I've = done a little work on the callflows document.  I need some = help
to iron out a couple of points.

1) There is something = wrong with F6 in section 3.2.  It's not indented
like the = messages.  And the 3rd History-Info contains = "invalidtarget
userindex":

History-Info: <sip:anonymous@anonymous.invalid>;index=3D1
History-Info: <sip:bob@biloxi.example.com;p=3Dx= >;index=3D1.1;rc=3D1
History-Info: <sip:anonymous@anonymous.inv= alidtarget = userindex=3D1.1.1;rc=3D1.1


I= t was supposed to be sip:anonymous@anonymous.invalid>;index=3D1.1.1;rc=3D1.1

2) Here is another example I think is needed. =  It shows the operation
of the rule for when a supporting entity = receives a request proxied
through a non-supporting entity.  The = index values are constructed
according to the text of 4244bis, but = I'm not sure that the wording
exactly matches our intentions.

=   This example provides a basic call scenario without forking. =  The
  distinguishing feature is that the first proxy = changes the
  request-URI but does not support = History-Info.


  Alice   atlanta.example.com  cadiz.example.com =    Bob
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  |   INVITE F1 =    | =             &n= bsp;  | =             &n= bsp;  |
  |--------------->| =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  |   INVITE F2    | =             &n= bsp;  |
  | =             &n= bsp;  |--------------->| =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  | INVITE F3      |
=   | =             &n= bsp;  | =             &n= bsp;  |--------------->|
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  |     200 F4 =     |
  | =             &n= bsp;  | =             &n= bsp;  |<---------------|
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  |     200 F5 =     | =             &n= bsp;  |
  | =             &n= bsp;  |<---------------| =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  |     200 F6 =     | =             &n= bsp;  | =             &n= bsp;  |
  |<---------------| =             &n= bsp;  | =             &n= bsp;  |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |
  |     ACK =        | =             &n= bsp;  | =             &n= bsp;  |
  |--------------->| =    ACK         | =             &n= bsp;  |
  | =             &n= bsp;  |--------------->|     ACK =        |
  | =             &n= bsp;  | =             &n= bsp;  |--------------->|

  Figure: = Example with a proxy that does not support History-Info


=   Message Details

  F1 INVITE alice -> atlanta.example.com

=   INVITE sip:bob@biloxi.example.com = SIP/2.0
  Via: SIP/2.0/TCP = 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->



  F2 = INVITE  atlanta.example.com -> cadiz.example.com

=   INVITE sip:bob@cadiz.example.com = SIP/2.0
  Via: SIP/2.0/TCP = proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->



  F3 = INVITE  cadiz.example.com = -> Bob

  INVITE sip:bob@192.0.1.11 SIP/2.0
=   Via: SIP/2.0/TCP = proxy.cadiz.example.com:5060;branch=3Dz9hG4bK
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0.1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D= 1.0.1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F4 200 = OK  Bob -> cadiz.example.com

=   SIP/2.0 200 OK
  Via: SIP/2.0/TCP = proxy.cadiz.example.com:5060;branch=3Dz9hG4bK
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0.1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D= 1.0.1
  Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->




=   F5 200 OK  cadiz.example.com -> atlanta.example.com

=   SIP/2.0 200 OK
  Via: SIP/2.0/TCP = proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0.1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D= 1.0.1
  Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F6 200 = OK  atlanta.example.com = -> Alice

  SIP/2.0 200 OK
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0.1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D= 1.0.1
  Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->

Question:  Item 6 = of section 10.3 seems ambiguous to me.  Currently,
it = reads:

  6.  Missing entity: If the request = clearly has a gap in the hi-entry
=       (i.e., the last hi-entry and = Request-URI differ), the entity
=       adding an hi-entry MUST add a single = index with a value of "0"
      (i.e., = the non-negative integer zero) prior to adding the
=       appropriate index for the action to = be taken.  For example, if
=       the index of the last hi-entry in = the request received was 1.1.2
=       and there was a missing hi-entry and = the request was being
      forwarded = to the next hop, the resulting index will be 1.1.2.0.1.

Following = the reference to it in section 9.1, upon receipt of message
F1, cadiz.example.com would have to = add this to the message:

  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0.1

adding a value of 0 and then the "appropriate index for = the action to
be taken" (which clearly must be 1 whenever we are = doing the section
9.1 processing).

Then upon sending F2, cadiz.example.com would have to = add

  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1
=
Is this what is intended, or do we want to have the final = History-Info
be:

  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@cadiz.example.com>;index= =3D1.0
  History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1;rc=3D= 1.0.1

using the "0" alone to represent "unknown = forwarding/branching at = this
point"?

 I thinks = this is a useful example. 

 As for = the indexing the gap, I think we need the 1 as the 
draft = currently specifies. 

 The receiving = entity can in fact, if able to identify the forked = message 
to be the same message, provide appropriate = index. (looking at the 
dialog identifier = etc.)

 For example, if the call was forked = upstream and reaches the 
same entity downstream, the = downstream entity by identifying 
the request to be = sourced from the same message, can add 
unique = index.

 e.g. 1.0.1 to the first receiving = forked request
         1.0.2 to the = next


3) Here is another = example, where a request is forked by a
non-supporting proxy. =  Unfortunately, it leads to a situation where
there are = duplicate indexes in the History-Info list.

  This is = an example where a proxy/registrar forks the call to
=   several alternative destinations.  The proxy/registrar = does not
  support History-Info but the destinations = do.

  Alice   atlanta.example.com  biloxi.example.com =   Bob    Office
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |   INVITE F1    | =             &n= bsp;  | =             &n= bsp;  |        |
=   |--------------->| =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  |   INVITE F2    | =             &n= bsp;  |        |
=   | =             &n= bsp;  |--------------->| =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | INVITE F3      | =        |
  | =             &n= bsp;  | =             &n= bsp;  |--------------->| =        |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | 180 Ringing F4 | =        |
  | =             &n= bsp;  | =             &n= bsp;  |<---------------| =        |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  |   180 Ringing F5 =             &n= bsp;  |        |
=   | =             &n= bsp;  |<---------------| =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |   180 Ringing F6 =             &n= bsp;  | =             &n= bsp;  |        |
=   |<---------------| =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | 408 Timeout F7 | =        |
  | =             &n= bsp;  | =             &n= bsp;  |<---------------| =        |
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | INVITE F8      | =        |
  | =             &n= bsp;  | =             &n= bsp;  |------------------------>|
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | 180 Ringing F9 | =        |
  | =             &n= bsp;  | =             &n= bsp;  |<------------------------|
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  |   180 Ringing F10 =             &n= bsp; |        |
=   | =             &n= bsp;  |<---------------| =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |   180 Ringing F11 =             &n= bsp; | =             &n= bsp;  |        |
=   |<---------------| =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | 200 OK F12     | =        |
  | =             &n= bsp;  | =             &n= bsp;  |<------------------------|
  | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  |   200 OK F13   | =             &n= bsp;  |        |
=   | =             &n= bsp;  |<---------------| =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |    200 OK F14  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |<---------------| =             &n= bsp;  | =             &n= bsp;  |        |
=   | =             &n= bsp;  | =             &n= bsp;  | =             &n= bsp;  |        |
=   |     ACK =        | =             &n= bsp;  | =             &n= bsp;  |        |
=   |--------------->|    ACK =         | =             &n= bsp;  |        |
=   | =             &n= bsp;  |--------------->|     ACK =        | =        |
  | =             &n= bsp;  | =             &n= bsp;  |------------------------>|

=     Example with forking by non-supporting = proxy

  Note that atlanta.example.com and all the = UAs support History-Info;
  biloxi.example.com does = not.


  F1 INVITE alice -> atlanta.example.com

=   INVITE sip:bob@biloxi.example.com = SIP/2.0
  Via: SIP/2.0/TCP = 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->

  F2 INVITE =  atlanta.example.com = -> biloxi.example.com

=   INVITE sip:bob@biloxi.example.com = SIP/2.0
  Via: SIP/2.0/TCP = proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->




=   F3 INVITE  biloxi.example.com -> = Bob

  INVITE sip:bob@192.0.1.11 SIP/2.0
=   Via: SIP/2.0/TCP = proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  Expires: 30
=   History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->

  F4 180 = Ringing  bob -> biloxi.example.com

=   SIP/2.0 180 Ringing
  Via: SIP/2.0/TCP = proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
  Contact: Bob = <sip:bob@192.0.1.11>
<= blockquote type=3D"cite">
  Content-Type: = application/sdp
  Content-Length: <appropriate = value>
  <!-- SDP Not Shown -->


=   F5 180 Ringing  biloxi.example.com -> atlanta.example.com

=   SIP/2.0 180 Ringing
  Via: SIP/2.0/TCP = proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=   Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F6 180 = Ringing  atlanta.example.com -> = alice

  SIP/2.0 180 Ringing
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@bil= oxi.example.com?Reason=3DSIP%3Bcause%3D180>;index=3D1.1;rc=3D1
=   History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=   Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->

Note that atlanta added = a Reason parameter to entry 1.1, due to
receiving a 180 from that = branch of the call.

  F4 408 Timeout  bob -> = biloxi.example.com

=   SIP/2.0 408 Timeout
  Via: SIP/2.0/TCP = proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=   Contact: Bob <sip:bob@192.0.1.11>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F8 = INVITE  biloxi.example.com = -> office

  INVITE sip:office@192.0.1.123 SIP/2.0
=   Via: SIP/2.0/TCP = proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>
=   Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  Expires: 30
=   History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  Contact: Alice <sip:alice@192.0.2.3>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F9 180 = Ringing  office -> biloxi.example.com

=   SIP/2.0 180 Ringing
  Via: SIP/2.0/TCP = proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz
  Via: = SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
=   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=   From: Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  History-Info: <sip:office@192.0.1.123>;index=3D1.1= .0.1
  Contact: Office <sip:office@192.0.1.123>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F10 180 = Ringing  biloxi.example.com= -> atlanta.example.com

=   SIP/2.0 180 Ringing
  Via: SIP/2.0/TCP = proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1.1;rc=3D1
  History-Info: <sip:office@192.0.1.123>;index=3D1.1= .0.1
  Contact: Office <sip:office@192.0.1.123>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->


  F11 180 = Ringing  atlanta.example.com -> = alice

  SIP/2.0 180 Ringing
  Via: = SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
  From: = Alice <sip:alice@atlanta.example.com&g= t;;tag=3D22
  To: Bob <sip:bob@biloxi.example.com>;tag= =3D33
  Supported: histinfo
  Call-Id: 12345600@atlanta.example.com<= /a>
  CSeq: 1 INVITE
  History-Info: <sip:bob@biloxi.example.com>;ind= ex=3D1
  History-Info: <sip:bob@bil= oxi.example.com?Reason=3DSIP%3Bcause%3D180>;index=3D1.1;rc=3D1
=   History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=   History-Info: <sip:office@192.0.1.123>;index=3D1.1= .0.1
  Contact: Office <sip:office@192.0.1.123>
=   Content-Type: application/sdp
=   Content-Length: <appropriate value>
=   <!-- SDP Not Shown -->

atlanta needs to record = a Reason specifying response 180 in index
1.1.  It presumably = replaces the previous Reason 180 in that entry.

At this point, = there is a problem regarding sorting the History-Info
entries = correctly:  atlanta.example.com = added
"<sip:bob@192.0.1.11>;index=3D1.1.0.1" = to its cache due to receiving F5,
and added "<sip:office@192.0.1.123>;index=3D1.1= .0.1" due to receiving
F10, but there is no defined ordering between = them.

 Hmm.. I really = don't see the issues here. 

 Sure, = there are duplicate entries but receiving entity and = sending 
entity can both get useful information out of = this. 

 Receiving entity = (UAS)
   The request was sent to bob but ultimately = was received 
     at office (Because UAS = serving office knows that it formed a 
    =  dialog with alice). It can see that path it = took..
 
 Sending entity = (UAC)
   Again it knows that it has established a = dialog  with office 
     and = depending on how it is implemented, it will = probably 
     knows that bob was tried as = well. 
 
 I see that even with the = duplicate entries, entities that are likely 
to utilize = the information can make use of the H-I = entries. 

 Thanks for your = comments
   Shida


Dale
___________________________________________= ____
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

= --Apple-Mail=_42A0068C-6984-4B70-915E-9A22EBBDFE72-- From youssef.chadli@orange.com Mon Oct 8 17:52:46 2012 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 6673E1F0C89 for ; Mon, 8 Oct 2012 17:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 R4HxptlELvVQ for ; Mon, 8 Oct 2012 17:52:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7091F0C8B for ; Mon, 8 Oct 2012 17:52:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 86B963240A7 for ; Tue, 9 Oct 2012 02:52:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6CCA427C053 for ; Tue, 9 Oct 2012 02:52:35 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 9 Oct 2012 02:52:34 +0200 From: To: SIPCORE Thread-Topic: 415 Unsoprted Media Type response & MIME type paramteer Thread-Index: Ac2luFtdgpd8qzIvTSWafAxO9+rn6Q== Date: Tue, 9 Oct 2012 00:52:34 +0000 Message-ID: <2276_1349743955_50737553_2276_19944_1_0817F9C5E16DA44DBAC216E633460EC5033833@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_0817F9C5E16DA44DBAC216E633460EC5033833PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.8.232433 Subject: [sipcore] 415 Unsoprted Media Type response & MIME type paramteer 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, 09 Oct 2012 00:52:46 -0000 --_000_0817F9C5E16DA44DBAC216E633460EC5033833PEXCVZYM11corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, A mandatory MIME type parameter may be associated to the MIME type name. A UAS may receive a request with a content-type set to a MIME type name whi= ch it supports and an associated mandatory parameter set to a non-support= ed value. My understanding is that the UAS in that case must reject the req= uest with a 415 "Unsupported Media Type". In fact, both the MIME Type name = AND the associated parameter describe the media type. Is my understanding correct ? I did not find an explicit answer to this in RFC 3261. This latter says: 21.4.13 415 Unsupported Media Type The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5 Youssef ___________________________________________________________________________= ______________________________________________ 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. --_000_0817F9C5E16DA44DBAC216E633460EC5033833PEXCVZYM11corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

A mandatory MIME type parameter= may be associated to the MIME type name.  

 

A UAS may receive a request wit= h a content-type set to a MIME type name which it supports and  an ass= ociated  mandatory parameter set to a non-supported value. My understa= nding is that the UAS in that case must reject the request with a 415 “Unsupported Media Type”. In fact, both= the MIME Type name AND the associated parameter describe the media type.

 

Is my understanding correct ?

 

I did not find an explicit answ= er to this in RFC 3261. This latter says:

21.4.13= 415 Unsupported Media Type

&n= bsp;

 &= nbsp; The server is refusing to service the request because the message

 &= nbsp; body of the request is in a format not supported by the server for

 &= nbsp; the requested method.  The server MUST return a list of acceptab= le

 &= nbsp; formats using the Accept, Accept-Encoding, or Accept-Language header<= o:p>

 &= nbsp; field, depending on the specific problem with the content.  UAC<= o:p>

 &= nbsp; processing of this response is described in Section 8.1.3.5

 

Youssef

 

 

______________________________________________________________________=
___________________________________________________

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.
--_000_0817F9C5E16DA44DBAC216E633460EC5033833PEXCVZYM11corpora_-- From mary.ietf.barnes@gmail.com Tue Oct 9 07:59:24 2012 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 A6C4011E80AD for ; Tue, 9 Oct 2012 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AoVT8GjilQLc for ; Tue, 9 Oct 2012 07:59:22 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98C11E80C5 for ; Tue, 9 Oct 2012 07:59:21 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3440639lam.31 for ; Tue, 09 Oct 2012 07:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NBf5bdpY5nKtIbGcvEHy7rl73vXbpaTT8sY4kk0wGNM=; b=erNO2egGnYI6bdPLIf2/O4bZFw8ghRnE+4OUPh0mouOCKWTs+8mrY90qGKXVv/xCJP mKVZNHZs5eJ+IWwvAhjICJ6ie9wiCojjOD4luWf0n5kkc90YYpiQZ1Yd3YTTEkHtbrfu ydtFMx/iEG0sAak0cc63pPAs3LSBCaPka3SVa9w50ZnagBVLe9ad9bO5ERmNDr+elCfn SiFleMZyQb8Du0tX1Wcg3PwrAd2Z0BID1L3oQcmUFuotCQNktk9m+5hUQUvyE4xRetTb c7F6XauiHzvFQ6MDHhwL/xmvIS0ZLo6erQb3RIC6Ka+vxEtoOOzEtq8uj8tWKNPbQtCN cNSw== MIME-Version: 1.0 Received: by 10.112.99.37 with SMTP id en5mr2517220lbb.1.1349794759849; Tue, 09 Oct 2012 07:59:19 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 9 Oct 2012 07:59:19 -0700 (PDT) In-Reply-To: <201210051925.q95JP0244047637@shell01.TheWorld.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> Date: Tue, 9 Oct 2012 09:59:19 -0500 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=f46d0401f9ff2e36bf04cba19516 Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 09 Oct 2012 14:59:24 -0000 --f46d0401f9ff2e36bf04cba19516 Content-Type: text/plain; charset=ISO-8859-1 I have responses below to 1) and 2). Shida addressed 3). Mary. On Fri, Oct 5, 2012 at 2:25 PM, Dale R. Worley wrote: > I've done a little work on the callflows document. I need some help > to iron out a couple of points. > > 1) There is something wrong with F6 in section 3.2. It's not indented > like the messages. And the 3rd History-Info contains "invalidtarget > userindex": > > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: [MB] We'll fix that. [/MB] > > 2) Here is another example I think is needed. It shows the operation > of the rule for when a supporting entity receives a request proxied > through a non-supporting entity. The index values are constructed > according to the text of 4244bis, but I'm not sure that the wording > exactly matches our intentions. > > This example provides a basic call scenario without forking. The > distinguishing feature is that the first proxy changes the > request-URI but does not support History-Info. > > > Alice atlanta.example.com cadiz.example.com Bob > | | | | > | INVITE F1 | | | > |--------------->| | | > | | | | > | | INVITE F2 | | > | |--------------->| | > | | | | > | | | INVITE F3 | > | | |--------------->| > | | | | > | | | 200 F4 | > | | |<---------------| > | | | | > | | 200 F5 | | > | |<---------------| | > | | | | > | 200 F6 | | | > |<---------------| | | > | | | | > | ACK | | | > |--------------->| ACK | | > | |--------------->| ACK | > | | |--------------->| > > Figure: Example with a proxy that does not support History-Info > > > Message Details > > F1 INVITE alice -> atlanta.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > F2 INVITE atlanta.example.com -> cadiz.example.com > > INVITE sip:bob@cadiz.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > F3 INVITE cadiz.example.com -> Bob > > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > F4 200 OK Bob -> cadiz.example.com > > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > > > F5 200 OK cadiz.example.com -> atlanta.example.com > > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F6 200 OK atlanta.example.com -> Alice > > SIP/2.0 200 OK > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.0.1 > History-Info: ;index=1.0.1.1;rc=1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > Question: Item 6 of section 10.3 seems ambiguous to me. Currently, > it reads: > > 6. Missing entity: If the request clearly has a gap in the hi-entry > (i.e., the last hi-entry and Request-URI differ), the entity > adding an hi-entry MUST add a single index with a value of "0" > (i.e., the non-negative integer zero) prior to adding the > appropriate index for the action to be taken. For example, if > the index of the last hi-entry in the request received was 1.1.2 > and there was a missing hi-entry and the request was being > forwarded to the next hop, the resulting index will be 1.1.2.0.1. > > Following the reference to it in section 9.1, upon receipt of message > F1, cadiz.example.com would have to add this to the message: > > History-Info: ;index=1.0.1 > > adding a value of 0 and then the "appropriate index for the action to > be taken" (which clearly must be 1 whenever we are doing the section > 9.1 processing). > > Then upon sending F2, cadiz.example.com would have to add > > History-Info: ;index=1.0.1.1 > > Is this what is intended, or do we want to have the final History-Info > be: > > History-Info: ;index=1 > History-Info: ;index=1.0 > History-Info: ;index=1.0.1;rc=1.0.1 > > using the "0" alone to represent "unknown forwarding/branching at this > point"? > [MB] We want the latter as is highlighted by the example. Per 4244bis, the entity that receives a request from a non-supporting entity adds an hi-entry on behalf of the entity sending the request. The "0" indicates that the hi-entries prior to this one may not reflect the complete history. Note that this section describes how one calculates the index. But, I think we did lose something from the spirit of 4244 that should be corrected. We can add the following qualifications to highlight the index is being added the hi-entry that is being added on behalf of the entity that doesn't support history-Info, something like the following: 6. Missing entity: If the request clearly has a gap in the hi-entry (i.e., the last hi-entry and Request-URI differ), the entity MUST add the missing hi-entry with an index with a value of "0" (i.e., the non-negative integer zero) prior to adding the hi-entry with the appropriate index for the action to be taken. For example, if the index of the last hi-entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. [/MB] > > 3) Here is another example, where a request is forked by a > non-supporting proxy. Unfortunately, it leads to a situation where > there are duplicate indexes in the History-Info list. > [MB] I think Shida answered this one. [/MB] > > This is an example where a proxy/registrar forks the call to > several alternative destinations. The proxy/registrar does not > support History-Info but the destinations do. > > Alice atlanta.example.com biloxi.example.com Bob Office > | | | | | > | INVITE F1 | | | | > |--------------->| | | | > | | | | | > | | INVITE F2 | | | > | |--------------->| | | > | | | | | > | | | INVITE F3 | | > | | |--------------->| | > | | | | | > | | | 180 Ringing F4 | | > | | |<---------------| | > | | | | | > | | 180 Ringing F5 | | > | |<---------------| | | > | | | | | > | 180 Ringing F6 | | | > |<---------------| | | | > | | | | | > | | | 408 Timeout F7 | | > | | |<---------------| | > | | | | | > | | | INVITE F8 | | > | | |------------------------>| > | | | | | > | | | 180 Ringing F9 | | > | | |<------------------------| > | | | | | > | | 180 Ringing F10 | | > | |<---------------| | | > | | | | | > | 180 Ringing F11 | | | > |<---------------| | | | > | | | | | > | | | 200 OK F12 | | > | | |<------------------------| > | | | | | > | | 200 OK F13 | | | > | |<---------------| | | > | | | | | > | 200 OK F14 | | | | > |<---------------| | | | > | | | | | > | ACK | | | | > |--------------->| ACK | | | > | |--------------->| ACK | | > | | |------------------------>| > > Example with forking by non-supporting proxy > > Note that atlanta.example.com and all the UAs support History-Info; > biloxi.example.com does not. > > > F1 INVITE alice -> atlanta.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > F2 INVITE atlanta.example.com -> biloxi.example.com > > INVITE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > > > F3 INVITE biloxi.example.com -> Bob > > INVITE sip:bob@192.0.1.11 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > F4 180 Ringing bob -> biloxi.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F5 180 Ringing biloxi.example.com -> atlanta.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F6 180 Ringing atlanta.example.com -> alice > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: >;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > Note that atlanta added a Reason parameter to entry 1.1, due to > receiving a 180 from that branch of the call. > > F4 408 Timeout bob -> biloxi.example.com > > SIP/2.0 408 Timeout > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Bob > Content-Type: application/sdp > Content-Length: > > > > F8 INVITE biloxi.example.com -> office > > INVITE sip:office@192.0.1.123 SIP/2.0 > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > Expires: 30 > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > Contact: Alice > Content-Type: application/sdp > Content-Length: > > > > F9 180 Ringing office -> biloxi.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > > F10 180 Ringing biloxi.example.com -> atlanta.example.com > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: ;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > > F11 180 Ringing atlanta.example.com -> alice > > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 > From: Alice ;tag=22 > To: Bob ;tag=33 > Supported: histinfo > Call-Id: 12345600@atlanta.example.com > CSeq: 1 INVITE > History-Info: ;index=1 > History-Info: >;index=1.1;rc=1 > History-Info: ;index=1.1.0.1 > History-Info: ;index=1.1.0.1 > Contact: Office > Content-Type: application/sdp > Content-Length: > > > atlanta needs to record a Reason specifying response 180 in index > 1.1. It presumably replaces the previous Reason 180 in that entry. > > At this point, there is a problem regarding sorting the History-Info > entries correctly: atlanta.example.com added > ";index=1.1.0.1" to its cache due to receiving F5, > and added ";index=1.1.0.1" due to receiving > F10, but there is no defined ordering between them. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --f46d0401f9ff2e36bf04cba19516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have responses below to 1) and 2). =A0Shida addressed 3).

<= div>Mary.

On Fri, Oct 5, 2012 at 2:25 PM,= Dale R. Worley <worley@ariadne.com> wrote:
I've done a little work on the callflows document. =A0I need some help<= br> to iron out a couple of points.

1) There is something wrong with F6 in section 3.2. =A0It's not indente= d
like the messages. =A0And the 3rd History-Info contains "invalidtarget=
userindex":

History-Info: <sip:anonymous@anonymous.invalid>;index=3D1
History-Info: <sip:bob@biloxi.example.com;p=3Dx>;index=3D1.1;rc=3D1
History-Info: <sip:anonymous@anonymous.invalidtarget userindex=3D1.1.1;r= c=3D1.1

[MB] We'll fix that. [/MB]= =A0

2) Here is another example I think is needed. =A0It shows the operation
of the rule for when a supporting entity receives a request proxied
through a non-supporting entity. =A0The index values are constructed
according to the text of 4244bis, but I'm not sure that the wording
exactly matches our intentions.

=A0 =A0This example provides a basic call scenario without forking. =A0The<= br> =A0 =A0distinguishing feature is that the first proxy changes the
=A0 =A0request-URI but does not support History-Info.


=A0 =A0Alice =A0 a= tlanta.example.com =A0cadiz.example.com =A0 =A0Bob
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 INVITE F1 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0|--------------->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 INVITE F2 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = INVITE F3 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-= -------------->|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 200 F4 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|&= lt;---------------|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 200 F5 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 200 F6 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0|<---------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 ACK =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0|--------------->| =A0 =A0ACK =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 ACK = =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-= -------------->|

=A0 =A0Figure: Example with a proxy that does not support History-Info


=A0 =A0Message Details

=A0 =A0F1 INVITE alice -> atlanta.example.com

=A0 =A0INVITE sip:bob@biloxi.example.com SIP/2.0
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->



=A0 =A0F2 INVITE =A0atlanta.example.com -> cadiz.example.com

=A0 =A0INVITE sip:bob@cadiz.example.com SIP/2.0
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->



=A0 =A0F3 INVITE =A0= cadiz.example.com -> Bob

=A0 =A0INVITE sip= :bob@192.0.1.11 SIP/2.0
=A0 =A0Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=3Dz9hG4bK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0.1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D1.0.1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F4 200 OK =A0Bob -> cadiz.example.com

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=3Dz9hG4bK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0.1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->




=A0 =A0F5 200 OK =A0= cadiz.example.com -> atlanta.example.com

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0.1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F6 200 OK =A0atlanta.example.com -> Alice

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0.1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1;rc=3D1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->

Question: =A0Item 6 of section 10.3 seems ambiguous to me. =A0Currently, it reads:

=A0 =A06. =A0Missing entity: If the request clearly has a gap in the hi-ent= ry
=A0 =A0 =A0 =A0(i.e., the last hi-entry and Request-URI differ), the entity=
=A0 =A0 =A0 =A0adding an hi-entry MUST add a single index with a value of &= quot;0"
=A0 =A0 =A0 =A0(i.e., the non-negative integer zero) prior to adding the =A0 =A0 =A0 =A0appropriate index for the action to be taken. =A0For example= , if
=A0 =A0 =A0 =A0the index of the last hi-entry in the request received was 1= .1.2
=A0 =A0 =A0 =A0and there was a missing hi-entry and the request was being =A0 =A0 =A0 =A0forwarded to the next hop, the resulting index will be 1.1.2= .0.1.

Following the reference to it in section 9.1, upon receipt of message
F1, cadiz.example.co= m would have to add this to the message:

=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0.1

adding a value of 0 and then the "appropriate index for the action to<= br> be taken" (which clearly must be 1 whenever we are doing the section 9.1 processing).

Then upon sending F2, cadiz.example.com would have to add

=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1.1

Is this what is intended, or do we want to have the final History-Info
be:

=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@cadiz.example.com>;index=3D1.0
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.0.1;rc=3D1.0.1

using the "0" alone to represent "unknown forwarding/branchi= ng at this
point"?
[MB] We want the latter as is highlighted= by the example. Per 4244bis, the entity that receives a request from a non= -supporting entity adds an hi-entry on behalf of the entity sending the req= uest. =A0The "0" indicates that the hi-entries prior to this one = may not reflect the complete history. Note that this section describes how = one calculates the index. =A0But, I think we did lose something from the sp= irit of 4244 that should be corrected. =A0We can add the following qualific= ations to highlight the index is being added the hi-entry that is being add= ed on behalf of the entity that doesn't support history-Info, something= like the following:

6. =A0Missing entity: If the request clearly has a gap = in the hi-entry
=A0 =A0 =A0 =A0(i.e., the last hi-entry and Request-URI = differ), the entity
=A0 =A0 =A0 =A0MUST add the missing hi-entry with an= index with=A0
=A0 =A0 =A0 =A0a value of "0"=A0(i.e., the non-negative inte= ger zero)
=A0 =A0 =A0 =A0prior to adding the hi-entry with the
=A0 =A0 =A0 =A0appropriate index for the action to be taken. =A0For= example, if
=A0 =A0 =A0 =A0the index of the last hi-entry in the reques= t received was 1.1.2
=A0 =A0 =A0 =A0and there was a missing hi-entry and the request was being=A0 =A0 =A0 =A0forwarded to the next hop, the resulting index will be 1.1= .2.0.1.

[/MB]=A0

3) Here is another example, where a request is forked by a
non-supporting proxy. =A0Unfortunately, it leads to a situation where
there are duplicate indexes in the History-Info list.
= [MB] I think Shida answered this one. [/MB]=A0

=A0 =A0This is an example where a proxy/registrar forks the call to
=A0 =A0several alternative destinations. =A0The proxy/registrar does not =A0 =A0support History-Info but the destinations do.

=A0 =A0Alice =A0 a= tlanta.example.com =A0biloxi.example.com =A0 Bob =A0 =A0Office
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 INVITE F1 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0|--------------->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 INVITE F2 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = INVITE F3 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-= -------------->| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = 180 Ringing F4 | =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|&= lt;---------------| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 180 Ringing F5 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 180 Ringing F6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0|<---------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = 408 Timeout F7 | =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|&= lt;---------------| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = INVITE F8 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-= ----------------------->|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = 180 Ringing F9 | =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|&= lt;------------------------|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 180 Ringing F10 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 180 Ringing F11 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0|<---------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = 200 OK F12 =A0 =A0 | =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|&= lt;------------------------|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 200 OK F13 =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<---------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0200 OK F14 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0|<---------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 ACK =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0|--------------->| =A0 =A0ACK =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|--------------->| =A0 =A0 ACK = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-= ----------------------->|

=A0 =A0 =A0 =A0 =A0 =A0 =A0Example with forking by non-supporting proxy

=A0 =A0Note that a= tlanta.example.com and all the UAs support History-Info;
=A0 =A0biloxi.examp= le.com does not.


=A0 =A0F1 INVITE alice -> atlanta.example.com

=A0 =A0INVITE sip:bob@biloxi.example.com SIP/2.0
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->

=A0 =A0F2 INVITE =A0atlanta.example.com -> biloxi.example.com

=A0 =A0INVITE sip:bob@biloxi.example.com SIP/2.0
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->




=A0 =A0F3 INVITE =A0biloxi.example.com -> Bob

=A0 =A0INVITE sip= :bob@192.0.1.11 SIP/2.0
=A0 =A0Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0Expires: 30
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->

=A0 =A0F4 180 Ringing =A0bob -> biloxi.example.com

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F5 180 Ringing =A0biloxi.example.com -> atlanta.example.com

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F6 180 Ringing =A0atlanta.example.com -> alice

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com?Reason= =3DSIP%3Bcause%3D180>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->

Note that atlanta added a Reason parameter to entry 1.1, due to
receiving a 180 from that branch of the call.

=A0 =A0F4 408 Timeout =A0bob -> biloxi.example.com

=A0 =A0SIP/2.0 408 Timeout
=A0 =A0Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bK
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=A0 =A0Contact: Bob <sip:bob@192.0.1.11>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F8 INVITE =A0biloxi.example.com -> office

=A0 =A0INVITE sip:office@192.0.1.123 SIP/2.0
=A0 =A0Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz =A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0Expires: 30
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0Contact: Alice <sip:alice@192.0.2.3>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F9 180 Ringing =A0office -> biloxi.example.com

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=3Dz9hG4bKxyz =A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:office@192.0.1.123>;index=3D1.1.0.1
=A0 =A0Contact: Office <sip:office@192.0.1.123>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F10 180 Ringing =A0biloxi.example.com -> atlanta.example.com

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2=
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:office@192.0.1.123>;index=3D1.1.0.1
=A0 =A0Contact: Office <sip:office@192.0.1.123>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->


=A0 =A0F11 180 Ringing =A0atlanta.example.com -> alice

=A0 =A0SIP/2.0 180 Ringing
=A0 =A0Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321
=A0 =A0From: Alice <sip:alice@atlanta.example.com>;tag=3D22
=A0 =A0To: Bob <sip:bob@biloxi.example.com>;tag=3D33
=A0 =A0Supported: histinfo
=A0 =A0Call-Id: 12345600@atlanta.example.com
=A0 =A0CSeq: 1 INVITE
=A0 =A0History-Info: <sip:bob@biloxi.example.com>;index=3D1
=A0 =A0History-Info: <sip:bob@biloxi.example.com?Reason= =3DSIP%3Bcause%3D180>;index=3D1.1;rc=3D1
=A0 =A0History-Info: <sip:bob@192.0.1.11>;index=3D1.1.0.1
=A0 =A0History-Info: <sip:office@192.0.1.123>;index=3D1.1.0.1
=A0 =A0Contact: Office <sip:office@192.0.1.123>
=A0 =A0Content-Type: application/sdp
=A0 =A0Content-Length: <appropriate value>
=A0 =A0<!-- SDP Not Shown -->

atlanta needs to record a Reason specifying response 180 in index
1.1. =A0It presumably replaces the previous Reason 180 in that entry.

At this point, there is a problem regarding sorting the History-Info
entries correctly: =A0atlanta.example.com added
"<sip:bob= @192.0.1.11>;index=3D1.1.0.1" to its cache due to receiving F5,=
and added "<sip:office@192.0.1.123>;index=3D1.1.0.1" due to receivin= g
F10, but there is no defined ordering between them.

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--f46d0401f9ff2e36bf04cba19516-- From brett@broadsoft.com Tue Oct 9 12:34:29 2012 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 B5B4921F8625 for ; Tue, 9 Oct 2012 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuhXdU2YnaQX for ; Tue, 9 Oct 2012 12:34:27 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 4D78E21F8753 for ; Tue, 9 Oct 2012 12:34:22 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 12:38:42 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 9 Oct 2012 12:38:41 -0700 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-10: question and comment Thread-Index: Ac2mVRQF1PiXzs7gS7alittcKmkhbw== Date: Tue, 9 Oct 2012 19:38:40 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B880163B3@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-10: question and comment 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, 09 Oct 2012 19:34:29 -0000 Hi, Based upon sections 6.1 and 9.2, it looks like the UAC MUST include History= -Info within the initial INVITE. However since section 5.1 and some (not a= ll) draft-ietf-sipcore-rfc4244bis-callflows-01 examples do not include it, = I thought that I'd ask. Does draft-ietf-sipcore-rfc4244bis require History-Info to be added by the = UAC? If yes, section 5.1 should be updated to show it. Thanks, Brett From R.Jesske@telekom.de Wed Oct 10 04:14:44 2012 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 E0B5521F85A3 for ; Wed, 10 Oct 2012 04:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDTgDWTMA7XB for ; Wed, 10 Oct 2012 04:14:43 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7E121F8754 for ; Wed, 10 Oct 2012 04:14:42 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 10 Oct 2012 13:14:40 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 10 Oct 2012 13:14:40 +0200 From: To: , Date: Wed, 10 Oct 2012 13:14:38 +0200 Thread-Topic: [sipcore] 4244bis-callflows Use Case 3.2 Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6w Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] 4244bis-callflows Use Case 3.2 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, 10 Oct 2012 11:14:45 -0000 Hi, I have looked on Example 3.2 and have a question. 4244bis states that: 10.1.2. Applying Privacy When a SIP message is forwarded to a domain for which the SIP intermediary is not responsible, a Privacy Service at the boundary of the domain applies the appropriate privacy based on the value of the Privacy header field in the message header or in the "headers" component of the hi-targeted-to-uri in the individual hi-entries. Now within the example privacy is only applied for one Entry as follows. F2 INVITE example.com -> Bob F2 INVITE atlanta.example.com -> biloxi.example.com INVITE sip:bob@biloxi.example.com;p=3Dx SIP/2.0 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=3Dz9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 From: Alice ;tag=3D22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=3D1 History-Info: ;index=3D1.1;rc=3D1 Contact: Alice Content-Type: application/sdp Content-Length: So my question is if really only one entry has to be deleted or both. Because the privacy service mut know the routing target which is within the= Request URI. So if the Request URI is known then also the History Info entry is known. Now privacy apply. Privacy =3D history then all known history entries has t= o be anonymised. In this case both entries has to be deleted. So question is now what has to be applied and why. Is my assumption correct= or wrong? With regard to that answer we should put some wording into the use case des= cription how the privacy header field has to be interpreted. Best Regards Roland From pkyzivat@alum.mit.edu Wed Oct 10 08:52:47 2012 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 5DD3C21F87BD for ; Wed, 10 Oct 2012 08:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, 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 XJ7TJd07sjUd for ; Wed, 10 Oct 2012 08:52:46 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id DAC4A21F87CF for ; Wed, 10 Oct 2012 08:52:44 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id 9TkH1k0011swQuc5ATsodF; Wed, 10 Oct 2012 15:52:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 9TqC1k00n3ZTu2S3bTqCHb; Wed, 10 Oct 2012 15:50:12 +0000 Message-ID: <5075989F.3090305@alum.mit.edu> Date: Wed, 10 Oct 2012 11:47:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> In-Reply-To: <50731E36.1070702@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:52:47 -0000 Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. We have also had a partial review of 3.2 by Dale. So we only need volunteers for the other 7.5. Thanks, Paul On 10/8/12 2:40 PM, Paul Kyzivat wrote: > EVERYBODY INTERESTED IN 4244bis: > > This is an example of why we NEED to have careful reviews of the callflows. > > So far I have been deafened by the silence. > There was quite a bit of enthusiasm for both the bis and the callflows > as long as it only took an email containing "+1". > Who, other than the authors, wants these enough to do some work??? > > Thanks, > Paul (as co-chair) > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Wed Oct 10 10:45:38 2012 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 0220221F87B0 for ; Wed, 10 Oct 2012 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, 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 8iuJDcIzxfbJ for ; Wed, 10 Oct 2012 10:45:37 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B44AB21F87A8 for ; Wed, 10 Oct 2012 10:45:29 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id 9Po51k00A1swQuc55VlZwG; Wed, 10 Oct 2012 17:45:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 9Vix1k00R3ZTu2S3bVixRS; Wed, 10 Oct 2012 17:42:57 +0000 Message-ID: <5075B30C.3020503@alum.mit.edu> Date: Wed, 10 Oct 2012 13:40:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <2276_1349743955_50737553_2276_19944_1_0817F9C5E16DA44DBAC216E633460EC5033833@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <2276_1349743955_50737553_2276_19944_1_0817F9C5E16DA44DBAC216E633460EC5033833@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] 415 Unsoprted Media Type response & MIME type paramteer 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, 10 Oct 2012 17:45:38 -0000 On 10/8/12 8:52 PM, youssef.chadli@orange.com wrote: > Hello all, > > A mandatory MIME type parameter may be associated to the MIME type name. > > A UAS may receive a request with a content-type set to a MIME type name > which it supports and an associated mandatory parameter set to a > non-supported value. My understanding is that the UAS in that case must > reject the request with a 415 “Unsupported Media Type”. In fact, both > the MIME Type name AND the associated parameter describe the media type. > > Is my understanding correct ? I'm not an expert on MIME types and MIME type parameters. But if you don't support the particular combination of MIME type and parameter then I agree this seems to be the correct way to indicate that. In this case you then need to include an Accept header in the 415, showing the types you *do* support. Presumably you should then indicate this MIME type with the parameter you do support. E.g. if you have objected to 'Content-Type: foo/bar;p1' then the 415 should include 'Accept: foo/bar;p2,foo/bar;p3' indicating that you support the p2 and p3 variants. (You need to look at section 14.1 of RFC2616 for details of the Accept header.) Thanks, Paul > I did not find an explicit answer to this in RFC 3261. This latter says: > > 21.4.13 415 Unsupported Media Type > > The server is refusing to service the request because the message > > body of the request is in a format not supported by the server for > > the requested method. The server MUST return a list of acceptable > > formats using the Accept, Accept-Encoding, or Accept-Language header > > field, depending on the specific problem with the content. UAC > > processing of this response is described in Section 8.1.3.5 > > Youssef > > _________________________________________________________________________________________________________________________ > > 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 > From worley@shell01.TheWorld.com Wed Oct 10 13:33:09 2012 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 3908E21F8647 for ; Wed, 10 Oct 2012 13:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=0.186, 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 qr9YwU8yp-Xs for ; Wed, 10 Oct 2012 13:33:08 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id B57E921F859F for ; Wed, 10 Oct 2012 13:33:08 -0700 (PDT) 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 q9AKWrNP016515 for ; Wed, 10 Oct 2012 16:32:55 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKWqiM4288969 for ; Wed, 10 Oct 2012 16:32:53 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKWqFN4352452; Wed, 10 Oct 2012 16:32:52 -0400 (EDT) Date: Wed, 10 Oct 2012 16:32:52 -0400 (EDT) Message-Id: <201210102032.q9AKWqFN4352452@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Organization: Ariadne Internet Services, Inc. To: sipcore@ietf.org In-reply-to: <5075989F.3090305@alum.mit.edu> (pkyzivat@alum.mit.edu) Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:33:09 -0000 > From: Paul Kyzivat > > We have also had a partial review of 3.2 by Dale. I think you mean Roland there. Dale From worley@shell01.TheWorld.com Wed Oct 10 14:00:03 2012 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 6225321F8525 for ; Wed, 10 Oct 2012 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.155, 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 itE5b1sPKEtr for ; Wed, 10 Oct 2012 14:00:03 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C7C1A21F84F9 for ; Wed, 10 Oct 2012 14:00:02 -0700 (PDT) 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 q9AKxLqp024861 for ; Wed, 10 Oct 2012 16:59:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKxLkf4349550 for ; Wed, 10 Oct 2012 16:59:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKxLBM4336806; Wed, 10 Oct 2012 16:59:21 -0400 (EDT) Date: Wed, 10 Oct 2012 16:59:21 -0400 (EDT) Message-Id: <201210102059.q9AKxLBM4336806@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) Subject: Re: [sipcore] 4244bis-callflows 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, 10 Oct 2012 21:00:03 -0000 > From: Mary Barnes > > I will also note that 4244 also didn't have examples of a > non-supporting > proxy and it's not the usual that we have those examples in any of > our > documents when we are defining optional headers. It is true that examples showing interoperation with non-supporting elements are not often given. But in *this* case, it is not trivial to arrange that a non-supporting proxy within a call of supporting elements works in a way that is useful, and in particular, the mechanism we have defined includes specific actions to make that use case work. Because of this, it is useful to provide an example showing exactly how the use case operates. Dale From worley@shell01.TheWorld.com Wed Oct 10 14:14:03 2012 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 717E41F0417 for ; Wed, 10 Oct 2012 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.133, 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 NeIVxAgpmQaD for ; Wed, 10 Oct 2012 14:14:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4B21F8552 for ; Wed, 10 Oct 2012 14:14:02 -0700 (PDT) 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 q9ALD72M004067 for ; Wed, 10 Oct 2012 17:13:09 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9ALD7W24339215 for ; Wed, 10 Oct 2012 17:13:07 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9ALD7Dp4343814; Wed, 10 Oct 2012 17:13:07 -0400 (EDT) Date: Wed, 10 Oct 2012 17:13:07 -0400 (EDT) Message-Id: <201210102113.q9ALD7Dp4343814@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (shida@ntt-at.com) Subject: Re: [sipcore] 4244bis-callflows 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, 10 Oct 2012 21:14:03 -0000 > From: Shida Schubert > > > 3) Here is another example, where a request is forked by a > > non-supporting proxy. Unfortunately, it leads to a situation > > where > > there are duplicate indexes in the History-Info list. > > Hmm.. I really don't see the issues here. > > Sure, there are duplicate entries but receiving entity and sending > entity can both get useful information out of this. > > Receiving entity (UAS) > The request was sent to bob but ultimately was received > at office (Because UAS serving office knows that it formed a > dialog with alice). It can see that path it took.. > > Sending entity (UAC) > Again it knows that it has established a dialog with office > and depending on how it is implemented, it will probably > knows that bob was tried as well. > > I see that even with the duplicate entries, entities that are > likely > to utilize the information can make use of the H-I entries. The core issue is this: Are two entries with the same index value allowed in History-Info? No specific answer is given to this question in rfc4244bis. (This is part of my complaint that the draft does not enunciate the constraints of the History-Info values.) The entirety of rfc4424bis is written in a way that *suggests*, but does not *state*, that no two entries in History-Info may have the same index. For example, all of the following passages suggest that the lexicographic preorder of the indexes puts the History-Info entries into a unique and well-defined order: By adding the new entries in order (i.e., following existing entries per the details in Section 10.3), [...] The hi-entries MUST be added to the cache in the order in which they were received in the request. The 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 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). Similarly, the descriptions of the "rc", "mp", and "np" parameters presume that the value of the parameter species *exactly one* hi-entry: 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 It turns out that the algorithms defined in rfc4244bis will at times insert two hi-entries with the *same* index value. There are two solutions: One solution is to affirm that no two entries can exist with the same index. To do that, we must change the algorithm so that it doesn't create that situation. The other solution is to affirm that two entries *can* exist with the same index. That requires that we: (1) Clearly warn the reader that this can happen, so that implementers are not misled; (2) Revise all the above passages to make clear what should be done when there are multiple entries with the same index; and (3) Adjust how the "rc", "mp", and "np" parameters are to be handled, given that their values are not guaranteed to specify a unique hi-entry. Dale From worley@shell01.TheWorld.com Wed Oct 10 14:20:06 2012 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 6C58011E80AD for ; Wed, 10 Oct 2012 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.116, 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 cLQtMEpXBvRd for ; Wed, 10 Oct 2012 14:20:06 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id BB83311E809A for ; Wed, 10 Oct 2012 14:20:05 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9ALJEda006414 for ; Wed, 10 Oct 2012 17:19:16 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9ALJDnk4345746 for ; Wed, 10 Oct 2012 17:19:14 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9ALJDMx4263054; Wed, 10 Oct 2012 17:19:13 -0400 (EDT) Date: Wed, 10 Oct 2012 17:19:13 -0400 (EDT) Message-Id: <201210102119.q9ALJDMx4263054@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (shida@ntt-at.com) Subject: Re: [sipcore] 4244bis-callflows 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, 10 Oct 2012 21:20:06 -0000 > From: Shida Schubert > > > Then upon sending F2, cadiz.example.com would have to add > > > > History-Info: ;index=1.0.1.1 > > > > Is this what is intended, or do we want to have the final > > History-Info > > be: > > > > History-Info: ;index=1 > > History-Info: ;index=1.0 > > History-Info: ;index=1.0.1;rc=1.0.1 > > > > using the "0" alone to represent "unknown forwarding/branching at > > this > > point"? > > As for the indexing the gap, I think we need the 1 as the > draft currently specifies. > > The receiving entity can in fact, if able to identify the forked > message > to be the same message, provide appropriate index. (looking at the > dialog identifier etc.) > > For example, if the call was forked upstream and reaches the > same entity downstream, the downstream entity by identifying > the request to be sourced from the same message, can add > unique index. > > e.g. 1.0.1 to the first receiving forked request > 1.0.2 to the next Currently, at least as I read the text, the construction of the indexes of new hi-entries on the outgoing forks of two different incoming requests are done independently. It seems to me that you are suggesting that with two different forks of one request entering the entity (and trigger the "0" processing) should have their new indexes assigned in a way that take each other into account. If you want to prescribe that behavior, it should be clearly specified in the text. As far as I can tell, in all cases, when a "0" is added to an index, "1" must be added following it, because any forking of outgoing requests is indicated by the *next* index component. That is, "0" is required to be followed by a "1". Dale From worley@shell01.TheWorld.com Wed Oct 10 13:53:07 2012 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 B9C9F21F8574 for ; Wed, 10 Oct 2012 13:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, MISSING_SUBJECT=1.762, 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 a7VR5lY6ZyLO for ; Wed, 10 Oct 2012 13:53:06 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 81FCF21F8644 for ; Wed, 10 Oct 2012 13:53:05 -0700 (PDT) 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 q9AKqULt011707 for ; Wed, 10 Oct 2012 16:52:32 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKqT3Z4312460 for ; Wed, 10 Oct 2012 16:52:30 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKqTRe4347897; Wed, 10 Oct 2012 16:52:29 -0400 (EDT) Date: Wed, 10 Oct 2012 16:52:29 -0400 (EDT) Message-Id: <201210102052.q9AKqTRe4347897@shell01.TheWorld.com> From: Dale R Worley To: sipcore@ietf.org In-reply-to: X-Mailman-Approved-At: Wed, 10 Oct 2012 14:31:23 -0700 Subject: [sipcore] (no subject) 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, 10 Oct 2012 20:53:07 -0000 (brett@broadsoft.com) Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10: question and comment --text follows this line-- > From: Brett Tate > > Based upon sections 6.1 and 9.2, it looks like the UAC MUST include > History-Info within the initial INVITE. That's true. It is a change from earlier versions. > However since section 5.1 > and some (not all) draft-ietf-sipcore-rfc4244bis-callflows-01 > examples do not include it, I thought that I'd ask. Well, section 5.1 is "Acknowledgements". But "History-Info:" is missing from: case 3.6 message F1 case 3.7 message F1 case 3.11 message F1 and "Supported: histinfo" is missing from: case 3.8 messages F3 and F4 case 3.11 message F1 assuming I've not made any mistakes. Dale From worley@shell01.TheWorld.com Wed Oct 10 15:20:08 2012 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 E5FE821F862B for ; Wed, 10 Oct 2012 15:20:07 -0700 (PDT) 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.103, 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 THK21yyevMwe for ; Wed, 10 Oct 2012 15:20:07 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3279521F862A for ; Wed, 10 Oct 2012 15:20:07 -0700 (PDT) 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 q9AMJPfD023058; Wed, 10 Oct 2012 18:19:27 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AMJOus4357371; Wed, 10 Oct 2012 18:19:25 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AMJOTW4297537; Wed, 10 Oct 2012 18:19:24 -0400 (EDT) Date: Wed, 10 Oct 2012 18:19:24 -0400 (EDT) Message-Id: <201210102219.q9AMJOTW4297537@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) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 10 Oct 2012 22:20:08 -0000 > From: Mary Barnes > > > Then upon sending F2, cadiz.example.com would have to add > > > > History-Info: ;index=1.0.1.1 > > > > Is this what is intended, or do we want to have the final History-Info > > be: > > > > History-Info: ;index=1 > > History-Info: ;index=1.0 > > History-Info: ;index=1.0.1;rc=1.0.1 > > > > using the "0" alone to represent "unknown forwarding/branching at this > > point"? > > > [MB] We want the latter as is highlighted by the example. OK, that makes more sense to me. I hadn't fully noticed the example in section 10.3 item 6. Of course, that means my example needs to be updated. > Per 4244bis, the > entity that receives a request from a non-supporting entity adds an > hi-entry on behalf of the entity sending the request. The "0" indicates > that the hi-entries prior to this one may not reflect the complete history. > Note that this section describes how one calculates the index. But, I > think we did lose something from the spirit of 4244 that should be > corrected. We can add the following qualifications to highlight the index > is being added the hi-entry that is being added on behalf of the entity > that doesn't support history-Info, something like the following: I think that the relevant text (sections 9.1 and 10.3 item 6) is less clear than it might be. May I suggest the marked changes: 9.1. Receiving a Request [...] If the Request-URI of the incoming request does not match the hi- targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity before proceeding to Section 9.2, as follows: The SIP entity MUST set the hi-targeted-to-uri to the value of the Request-URI in the incoming request. If the Request-URI is a Tel- URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of [RFC3261] before being added as a hi-targted-to-uri. If privacy is required, the SIP entity MUST follow the procedures of Section 10.1. The SIP entity MUST set the hi-index parameter as described in > Section 10.3, that is, the hi-index will be the hi-index of the > previously last hi-entry, with the number "0" appended. The SIP entity MUST NOT include an "rc", "mp" or "np" header field parameter. 10.3. Indexing in the History-Info Header Field [...] > 6. Missing entity: When a request is received that clearly has a > gap in the hi-entries (i.e., the last hi-entry and Request-URI > differ), before other processing of History-Info, the receiver > must (section 9.1) add an hi-entry whose index value is that of > the previously last hi-entry, with an appended number "0" > (i.e., the non-negative integer zero). This new hi-entry's > index value becomes the base from which will be constructed the > indexes of the hi-entries added to forwarded requests (section 9.2). > > For example, if the index of the last hi-entry in the request > received was 1.1.2 and there was a missing hi-entry and the > request is forwarded to a next hop, the forwarded request will > have two additional hi-entries, one containing the incoming > Request-URI with the index 1.1.2.0 (section 9.1) and one > containing the outgoing Request-URI with the index 1.1.2.0.1 > (section 9.2). A second outgoing request to another > destination will have added hi-entries with the indexes 1.1.2.0 > and 1.1.2.0.2. Dale From worley@shell01.TheWorld.com Wed Oct 10 15:28:07 2012 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 1F8C521F865E for ; Wed, 10 Oct 2012 15:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.093, 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 FEoecNeX0Hwi for ; Wed, 10 Oct 2012 15:28:06 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8331821F864D for ; Wed, 10 Oct 2012 15:28:06 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9AMRE6P003927; Wed, 10 Oct 2012 18:27:16 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AMRDAC4342055; Wed, 10 Oct 2012 18:27:13 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AMRDCU4355503; Wed, 10 Oct 2012 18:27:13 -0400 (EDT) Date: Wed, 10 Oct 2012 18:27:13 -0400 (EDT) Message-Id: <201210102227.q9AMRDCU4355503@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) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 10 Oct 2012 22:28:07 -0000 > From: Mary Barnes > > > Is this what is intended, or do we want to have the final History-Info > > be: > > > > History-Info: ;index=1 > > History-Info: ;index=1.0 > > History-Info: ;index=1.0.1;rc=1.0.1 > > > > using the "0" alone to represent "unknown forwarding/branching at this > > point"? > > > [MB] We want the latter as is highlighted by the example. One interesting consequence of using the latter method is that if a non-supporting proxy is the *last* proxy before the UAS, then the *final* hi-entry (as they are reported back to the UAC) will have an index that ends in "0". There's nothing contradictory about that, but it is not something you'd expect at first. Dale From shida@ntt-at.com Wed Oct 10 20:41:35 2012 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 9D65D11E809A for ; Wed, 10 Oct 2012 20:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.349, 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 zQAa6j8z0UkP for ; Wed, 10 Oct 2012 20:41:34 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id A1BFA11E8099 for ; Wed, 10 Oct 2012 20:41:34 -0700 (PDT) Received: from [118.109.76.216] (port=56725 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TM9eP-0000d9-2Y; Wed, 10 Oct 2012 22:41:33 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210102113.q9ALD7Dp4343814@shell01.TheWorld.com> Date: Thu, 11 Oct 2012 12:41:31 +0900 Content-Transfer-Encoding: 7bit Message-Id: <963D8AC6-3184-4CA2-A5F6-7D224593BFC9@ntt-at.com> References: <201210102113.q9ALD7Dp4343814@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.17]) [118.109.76.216]:56725 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 11 Oct 2012 03:41:35 -0000 Hi Dale; My comments inline.. On Oct 11, 2012, at 6:13 AM, Dale R. Worley wrote: >> From: Shida Schubert >> >>> 3) Here is another example, where a request is forked by a >>> non-supporting proxy. Unfortunately, it leads to a situation >>> where >>> there are duplicate indexes in the History-Info list. >> >> Hmm.. I really don't see the issues here. >> >> Sure, there are duplicate entries but receiving entity and sending >> entity can both get useful information out of this. >> >> Receiving entity (UAS) >> The request was sent to bob but ultimately was received >> at office (Because UAS serving office knows that it formed a >> dialog with alice). It can see that path it took.. >> >> Sending entity (UAC) >> Again it knows that it has established a dialog with office >> and depending on how it is implemented, it will probably >> knows that bob was tried as well. >> >> I see that even with the duplicate entries, entities that are >> likely >> to utilize the information can make use of the H-I entries. > > The core issue is this: > > Are two entries with the same index value allowed in History-Info? As far as I know RFC4244 doesn't have any mechanism to prevent this from happening, so yes it could happen. Whether this will happen in reality, I am not sure.. > > No specific answer is given to this question in rfc4244bis. (This is > part of my complaint that the draft does not enunciate the constraints > of the History-Info values.) > > The entirety of rfc4424bis is written in a way that *suggests*, but > does not *state*, that no two entries in History-Info may have the > same index. For example, all of the following passages suggest that > the lexicographic preorder of the indexes puts the History-Info > entries into a unique and well-defined order: > > By adding the new entries in order (i.e., following existing > entries per the details in Section 10.3), [...] > > The hi-entries MUST be added to the cache in the order in > which they were received in the request. > > The 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 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). This holds true for entity supporting the history-info and setting the hi-entries.. It doesn't say anything about receiving such duplicate information... The current spec about generating index on the outgoing request holds true, it is handling of requests with duplicate index that is not specified currently. > > Similarly, the descriptions of the "rc", "mp", and "np" parameters > presume that the value of the parameter species *exactly one* > hi-entry: > > 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 > > It turns out that the algorithms defined in rfc4244bis will at times > insert two hi-entries with the *same* index value. There are two > solutions: > > One solution is to affirm that no two entries can exist with the same > index. To do that, we must change the algorithm so that it doesn't > create that situation. You mean to create some sort of hash etc., to make each hi-entry a unique value and reference that instead of hi-index to show the correlation? Or add the uri of the processing entity to identify each hi-entry as a unique entry? That to me seems like an overkill. Furthermore with 4244 being deployed already and potentially allowing duplicate index on the path, don't know how much this helps. > > The other solution is to affirm that two entries *can* exist with the > same index. That requires that we: (1) Clearly warn the reader that > this can happen, so that implementers are not misled; (2) Revise all > the above passages to make clear what should be done when there are > multiple entries with the same index; and (3) Adjust how the "rc", > "mp", and "np" parameters are to be handled, given that their values > are not guaranteed to specify a unique hi-entry. (1) agree, (2) The only place I see where change is needed is to add some text about handling duplicate hi-index in receiving requests. 4244 entity will not be able to sanitize the duplicate hi-index, so adding this behavior may help but will not solve the already existing problem with 4244 out there (If we believe that this is a problem).. Thanks Shida > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Wed Oct 10 20:44:05 2012 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 DF83921F8661 for ; Wed, 10 Oct 2012 20:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.233, 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 agoCynuJn6Gv for ; Wed, 10 Oct 2012 20:44:05 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F821F853A for ; Wed, 10 Oct 2012 20:44:05 -0700 (PDT) Received: from [118.109.76.216] (port=56751 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TM9gq-0001rH-GQ; Wed, 10 Oct 2012 22:44:04 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210102227.q9AMRDCU4355503@shell01.TheWorld.com> Date: Thu, 11 Oct 2012 12:44:03 +0900 Content-Transfer-Encoding: 7bit Message-Id: <005067D3-1BF3-4E51-B3D5-81C9CFA6EA2F@ntt-at.com> References: <201210102227.q9AMRDCU4355503@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.17]) [118.109.76.216]:56751 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 11 Oct 2012 03:44:06 -0000 Hmm.. No you wouldn't because it is the entity forwarding the request that always set the hi-entry of the outgoing request. In the following case, it is the entity that set the >>> History-Info: ;index=1.0 that also sets the >>> History-Info: ;index=1.0.1;rc=1.0.1 before forwarding the request to bob@192.0.1.11. 0 never hangs by itself, because an entity that sets the 0 to the incoming request MUST set index and hi-entry to the outgoing request as well. Regards Shida On Oct 11, 2012, at 7:27 AM, Dale R. Worley wrote: >> From: Mary Barnes >> >>> Is this what is intended, or do we want to have the final History-Info >>> be: >>> >>> History-Info: ;index=1 >>> History-Info: ;index=1.0 >>> History-Info: ;index=1.0.1;rc=1.0.1 >>> >>> using the "0" alone to represent "unknown forwarding/branching at this >>> point"? >>> >> [MB] We want the latter as is highlighted by the example. > > One interesting consequence of using the latter method is that if a > non-supporting proxy is the *last* proxy before the UAS, then the > *final* hi-entry (as they are reported back to the UAC) will have an > index that ends in "0". There's nothing contradictory about that, but > it is not something you'd expect at first. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From R.Jesske@telekom.de Wed Oct 10 23:16:37 2012 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 A303121F8625 for ; Wed, 10 Oct 2012 23:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4Jr39F6gJ93T for ; Wed, 10 Oct 2012 23:16:35 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 971CD21F86F6 for ; Wed, 10 Oct 2012 23:16:33 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2012 08:16:29 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Oct 2012 08:16:29 +0200 From: To: , Date: Thu, 11 Oct 2012 08:16:24 +0200 Thread-Topic: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: Ac2m/7e3K8n/Fd+aQ8eIPj3MJbRAigAeCjgw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F056C6@HE111648.emea1.cds.t-internal.com> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> In-Reply-To: <5075989F.3090305@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 Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 06:16:37 -0000 Hi Paul, I'm looking for 3.3, 3.5 and 3.7 Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Paul Kyzivat Gesendet: Mittwoch, 10. Oktober 2012 17:48 An: sipcore@ietf.org Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipco= re-rfc4244bis-callflows-01 Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. We have also had a partial review of 3.2 by Dale. So we only need volunteers for the other 7.5. Thanks, Paul On 10/8/12 2:40 PM, Paul Kyzivat wrote: > EVERYBODY INTERESTED IN 4244bis: > > This is an example of why we NEED to have careful reviews of the callflow= s. > > So far I have been deafened by the silence. > There was quite a bit of enthusiasm for both the bis and the callflows > as long as it only took an email containing "+1". > Who, other than the authors, wants these enough to do some work??? > > Thanks, > Paul (as co-chair) > > _______________________________________________ > 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 R.Jesske@telekom.de Wed Oct 10 23:56:58 2012 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 60D7821F8625 for ; Wed, 10 Oct 2012 23:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWkd9J2Q-lLh for ; Wed, 10 Oct 2012 23:56:57 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8736321F8606 for ; Wed, 10 Oct 2012 23:56:57 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2012 08:56:53 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Oct 2012 08:56:52 +0200 From: To: , , Date: Thu, 11 Oct 2012 08:56:50 +0200 Thread-Topic: WGLC 4244bis-callflows Use Case 3.3 (3.2) Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6wACivAIA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 11 Oct 2012 06:56:58 -0000 Hi, Review for 3.3 (including parts of 3.2) 1. History-Info included by the UAC Why does put the UA an History-Info into the INVITE? Of course the UA is a= llowed to do it but why? My understanding of H-I is to track changes due to retargeting and forwardi= ng. The UAC does not know what will happen with the Request URI. Nevertheless I have no problem since this is an example. But I do not see a= n value add. (This comment belongs also to other use cases) 2. F2 INVITE ... History-Info: ;index=3D1 History-Info: ;index=3D1.1;rc=3D1 ... Why is there an entry added with rc? There is no change of the request URI therefore no reason to add anything. This comment belongs at also to call flow 3.2 even the first entry is anony= mized the 2nd has the same information. So in 3.2 the flows indicates F1 INVITE ... History-Info: ;index=3D1 ... F2 INVITE ... History-Info: ;index=3D1 History-Info: ;index=3D1.1;rc=3D1 ... --> 2nd entry is wrong there was no retargeting/change within the request U= RI. 3. History-Info forwarded to the UAS Why is the History-Info forwarded to the UAS? That is only allowed when the UAS is within the same trust domain. Either this must mentioned explicitly within the description or the entry h= as to be anonymized. 4. Question is why we have this use case? Because in 3.2 we have already a privacy value of an entry. So from my side= it is already covered by 3.2. Which leads me to the question which privacy scenarios should be shown with= in the call flows. --> I would propose to change 3.2 without an entry privacy. Best Regards Roland From brett@broadsoft.com Thu Oct 11 03:05:35 2012 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 9339521F85A0 for ; Thu, 11 Oct 2012 03:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCzew0RmLmqt for ; Thu, 11 Oct 2012 03:05:35 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 272A021F859C for ; Thu, 11 Oct 2012 03:05:35 -0700 (PDT) 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; Thu, 11 Oct 2012 03:05:35 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 11 Oct 2012 03:05:35 -0700 From: Brett Tate To: Dale R Worley , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-10: question and comment Thread-Index: AQHNpy6uRRkszvr5Uky74jsJGv/yXJez364A Date: Thu, 11 Oct 2012 10:05:33 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B880166EE@MBX06.citservers.local> References: <201210102052.q9AKqTRe4347897@shell01.TheWorld.com> In-Reply-To: <201210102052.q9AKqTRe4347897@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10: question and comment 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, 11 Oct 2012 10:05:35 -0000 > > Based upon sections 6.1 and 9.2, it looks like the=20 > > UAC MUST include History-Info within the initial INVITE. >=20 > That's true. It is a change from earlier versions. >=20 > > However since section 5.1 and some (not all)=20 > > draft-ietf-sipcore-rfc4244bis-callflows-01 > > examples do not include it, I thought that I'd ask. >=20 > Well, section 5.1 is "Acknowledgements". The section 5.1 reference/comment was for draft-ietf-sipcore-rfc4244bis-10 = section 5.1. Thanks for the response, Brett From R.Jesske@telekom.de Thu Oct 11 04:28:22 2012 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 13A0A21F86D0 for ; Thu, 11 Oct 2012 04:28:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...544DB2BD3@HE111648.emea1.cds.t-internal.com>\n X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS-UocDlYs1x for ; Thu, 11 Oct 2012 04:28:21 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8802521F8686 for ; Thu, 11 Oct 2012 04:28:20 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2012 13:28:18 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Oct 2012 13:28:18 +0200 From: To: , Date: Thu, 11 Oct 2012 13:28:15 +0200 Thread-Topic: WGLC 4244bis-callflows Use Case 3.3 (3.2) Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6wACivAIAACOH1kA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05C59@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 11 Oct 2012 11:28:22 -0000 Hi, Review for 3.5 Main focus on this use case is UAS. So with regard to the UAC it is not needed that UAC supports historyinfo. Only UAS has to do it. Perhaps that should be mentioned within the use case. It will be the same behaviour when the call comes from the PSTN via an MGC. So the shown content is independent on the information given within INVITE = F3. Also in this case it is not needed that the UAC includes the History-Info. = Why? Minor editorial: Text first paragraph: Within the IMS the Public User Identity is used --> replacement of public i= dentity by public user identity (PUID) is proposed. Best Regards Roland From pkyzivat@alum.mit.edu Thu Oct 11 08:34:51 2012 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 2B4D921F86F0 for ; Thu, 11 Oct 2012 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, 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 kLyeuncUpVfL for ; Thu, 11 Oct 2012 08:34:50 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3FE21F866C for ; Thu, 11 Oct 2012 08:34:50 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 9qD51k0060vyq2s5BraugY; Thu, 11 Oct 2012 15:34:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 9rWB1k0093ZTu2S3RrWC5a; Thu, 11 Oct 2012 15:30:14 +0000 Message-ID: <5076E5E7.7080604@alum.mit.edu> Date: Thu, 11 Oct 2012 11:29:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F056C6@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F056C6@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:34:51 -0000 On 10/11/12 2:16 AM, R.Jesske@telekom.de wrote: > Hi Paul, > I'm looking for 3.3, 3.5 and 3.7 Thank you Roland! I see you have already sent comments and questions about a couple of these. Not surprisingly your initial comments are about the details of the H-I entries, which is entirely reasonable, and deserves the most focus. However I do request that you do your best to verify all aspects of the messages for correctness. When do you expect to be finished reviewing? Thanks, Paul > Roland > > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Mittwoch, 10. Oktober 2012 17:48 > An: sipcore@ietf.org > Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 > > Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. > We have also had a partial review of 3.2 by Dale. > > So we only need volunteers for the other 7.5. > > Thanks, > Paul > > On 10/8/12 2:40 PM, Paul Kyzivat wrote: > >> EVERYBODY INTERESTED IN 4244bis: >> >> This is an example of why we NEED to have careful reviews of the callflows. >> >> So far I have been deafened by the silence. >> There was quite a bit of enthusiasm for both the bis and the callflows >> as long as it only took an email containing "+1". >> Who, other than the authors, wants these enough to do some work??? >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> 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 worley@shell01.TheWorld.com Thu Oct 11 09:46:06 2012 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 4F13D21F85B4 for ; Thu, 11 Oct 2012 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.085, 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 aY58nrl5kP85 for ; Thu, 11 Oct 2012 09:46:05 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 844AF21F85AE for ; Thu, 11 Oct 2012 09:46:05 -0700 (PDT) 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 q9BGjLVi002628; Thu, 11 Oct 2012 12:45:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9BGjKBc4399878; Thu, 11 Oct 2012 12:45:20 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9BGjJDU4393839; Thu, 11 Oct 2012 12:45:19 -0400 (EDT) Date: Thu, 11 Oct 2012 12:45:19 -0400 (EDT) Message-Id: <201210111645.q9BGjJDU4393839@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Shida Schubert In-reply-to: <005067D3-1BF3-4E51-B3D5-81C9CFA6EA2F@ntt-at.com> (shida@ntt-at.com) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 11 Oct 2012 16:46:06 -0000 > From: Shida Schubert > > No you wouldn't because it is the entity forwarding the > request that always set the hi-entry of the outgoing request. > > In the following case, it is the entity that set the > > >>> History-Info: ;index=1.0 > > that also sets the > > >>> History-Info: ;index=1.0.1;rc=1.0.1 > > before forwarding the request to bob@192.0.1.11. Uh, what? If a UAS receives a request where the request-URI does not match the last hi-entry, the rules of section 9.1 "Receiving a Request" apply -- it must add an hi-entry describing the request-URI that it sees. That hi-entry's index will end with "0", and it will be the last hi-entry in the cache. Being a UAS, it does not forward the request anywhere. But being a UAS, it sends a response, and that response contains all the hi-entries in the cache, one of which is the hi-entry added during the section 9.1 processing. Dale From worley@shell01.TheWorld.com Thu Oct 11 09:52:03 2012 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 0F13221F8653 for ; Thu, 11 Oct 2012 09:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.077, 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 U5nxKKf33DBn for ; Thu, 11 Oct 2012 09:52:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 412A721F862B for ; Thu, 11 Oct 2012 09:52:02 -0700 (PDT) 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 q9BGp9jQ019247; Thu, 11 Oct 2012 12:51:11 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9BGp9v74401469; Thu, 11 Oct 2012 12:51:09 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9BGp8894383931; Thu, 11 Oct 2012 12:51:08 -0400 (EDT) Date: Thu, 11 Oct 2012 12:51:08 -0400 (EDT) Message-Id: <201210111651.q9BGp8894383931@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Shida Schubert In-reply-to: <963D8AC6-3184-4CA2-A5F6-7D224593BFC9@ntt-at.com> (shida@ntt-at.com) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 11 Oct 2012 16:52:03 -0000 > From: Shida Schubert > > > The core issue is this: > > > > Are two entries with the same index value allowed in > > History-Info? > > As far as I know RFC4244 doesn't have any mechanism to > prevent this from happening, so yes it could happen. Whether this > will happen in reality, I am not sure.. I have previously posted a detailed example showing how it could happen. See http://www.ietf.org/mail-archive/web/sipcore/current/msg05220.html, item 3. You may consider it to be unrealistic, but it seems quite realistic to me. That situation will arise any time a non-supporting proxy forks a request to two supporting destinations. Dale From shida@ntt-at.com Thu Oct 11 19:50:26 2012 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 8ED3411E809B for ; Thu, 11 Oct 2012 19:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.161 X-Spam-Level: X-Spam-Status: No, score=-101.161 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_20=-0.74, 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 VolySASo2C7P for ; Thu, 11 Oct 2012 19:50:26 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 31EB811E808D for ; Thu, 11 Oct 2012 19:50:26 -0700 (PDT) Received: from [118.109.76.216] (port=63694 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TMVKT-00043Z-0f; Thu, 11 Oct 2012 21:50:25 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210111645.q9BGjJDU4393839@shell01.TheWorld.com> Date: Fri, 12 Oct 2012 11:50:23 +0900 Content-Transfer-Encoding: 7bit Message-Id: <44A0EEEC-0BB6-42B7-AD6B-02AD7B8F159E@ntt-at.com> References: <201210111645.q9BGjJDU4393839@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.17]) [118.109.76.216]:63694 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 12 Oct 2012 02:50:26 -0000 I see, you are talking about UAS receiving a request with gap in H-I. In which case, you are right that the last entry will be that of its own and you would end up with 0 at the end of the hi-inex. Regards Shida On Oct 12, 2012, at 1:45 AM, Dale R. Worley wrote: >> From: Shida Schubert >> >> No you wouldn't because it is the entity forwarding the >> request that always set the hi-entry of the outgoing request. >> >> In the following case, it is the entity that set the >> >>>>> History-Info: ;index=1.0 >> >> that also sets the >> >>>>> History-Info: ;index=1.0.1;rc=1.0.1 >> >> before forwarding the request to bob@192.0.1.11. > > Uh, what? > > If a UAS receives a request where the request-URI does not match the > last hi-entry, the rules of section 9.1 "Receiving a Request" apply -- > it must add an hi-entry describing the request-URI that it sees. That > hi-entry's index will end with "0", and it will be the last hi-entry > in the cache. > > Being a UAS, it does not forward the request anywhere. > > But being a UAS, it sends a response, and that response contains all > the hi-entries in the cache, one of which is the hi-entry added during > the section 9.1 processing. > > Dale From shida@ntt-at.com Thu Oct 11 20:48:01 2012 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 433D321F84D4 for ; Thu, 11 Oct 2012 20:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.195 X-Spam-Level: X-Spam-Status: No, score=-101.195 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, 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 CMK1BgjvgZKW for ; Thu, 11 Oct 2012 20:48:00 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4521F84CF for ; Thu, 11 Oct 2012 20:48:00 -0700 (PDT) Received: from [118.109.76.216] (port=64370 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TMWE2-0002UO-V6; Thu, 11 Oct 2012 22:47:51 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210111651.q9BGp8894383931@shell01.TheWorld.com> Date: Fri, 12 Oct 2012 12:47:48 +0900 Content-Transfer-Encoding: 7bit Message-Id: <2BB5565E-F13A-4D94-9C6D-54F72881E014@ntt-at.com> References: <201210111651.q9BGp8894383931@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.17]) [118.109.76.216]:64370 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 12 Oct 2012 03:48:01 -0000 Hi Dale; I agree, this can happen. I was just thinking about our network.. Where this is not likely to happen.. Anyway, what do you suggest we do? Do we just make a note stating that this can happen and when this happens, information will not be as useful unless the entity utilizing the hi-entries have extended knowledge of the network?? OR make use of other information such as (associated response code etc.) Or do we add another layer of complexity to already complex mechanism? Regards Shida On Oct 12, 2012, at 1:51 AM, Dale R. Worley wrote: >> From: Shida Schubert >> >>> The core issue is this: >>> >>> Are two entries with the same index value allowed in >>> History-Info? >> >> As far as I know RFC4244 doesn't have any mechanism to >> prevent this from happening, so yes it could happen. Whether this >> will happen in reality, I am not sure.. > > I have previously posted a detailed example showing how it could > happen. See > http://www.ietf.org/mail-archive/web/sipcore/current/msg05220.html, > item 3. You may consider it to be unrealistic, but it seems quite > realistic to me. That situation will arise any time a non-supporting > proxy forks a request to two supporting destinations. > > Dale From R.Jesske@telekom.de Thu Oct 11 22:35:26 2012 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 9153421F84C9 for ; Thu, 11 Oct 2012 22:35:26 -0700 (PDT) X-Quarantine-ID: <9JKYxdsCsc4Z> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...544DB2BD3@HE111648.emea1.cds.t-internal.com>\n X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JKYxdsCsc4Z for ; Thu, 11 Oct 2012 22:35:26 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7721F84C5 for ; Thu, 11 Oct 2012 22:35:25 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 12 Oct 2012 07:35:23 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Oct 2012 07:35:23 +0200 From: To: , , Date: Fri, 12 Oct 2012 07:35:20 +0200 Thread-Topic: WGLC 4244bis-callflows Use Case 3.5 Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6wACivAIAACOH1kAAn8NAQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F060CC@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> 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 Subject: [sipcore] WGLC 4244bis-callflows Use Case 3.5 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, 12 Oct 2012 05:35:26 -0000 Sorry wrong Headline It is the review for 3.5 -----Urspr=FCngliche Nachricht----- Von: Jesske, Roland Gesendet: Donnerstag, 11. Oktober 2012 13:28 An: 'shida@ntt-at.com'; 'sipcore@ietf.org' Betreff: WGLC 4244bis-callflows Use Case 3.3 (3.2) Hi, Review for 3.5 Main focus on this use case is UAS. So with regard to the UAC it is not needed that UAC supports historyinfo. Only UAS has to do it. Perhaps that should be mentioned within the use case. It will be the same behaviour when the call comes from the PSTN via an MGC. So the shown content is independent on the information given within INVITE = F3. Also in this case it is not needed that the UAC includes the History-Info. = Why? Minor editorial: Text first paragraph: Within the IMS the Public User Identity is used --> replacement of public i= dentity by public user identity (PUID) is proposed. Best Regards Roland From R.Jesske@telekom.de Fri Oct 12 04:55:14 2012 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 7838121F859A for ; Fri, 12 Oct 2012 04:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DKt+Bg3aN++t for ; Fri, 12 Oct 2012 04:55:13 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 931F121F8503 for ; Fri, 12 Oct 2012 04:55:12 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 12 Oct 2012 13:55:10 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Oct 2012 13:55:10 +0200 From: To: Date: Fri, 12 Oct 2012 13:55:08 +0200 Thread-Topic: AW: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: Ac2nxgNuaPsVE2rRTGy1LHQS6mDFrQAqkrGA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504744C@HE111648.emea1.cds.t-internal.com> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F056C6@HE111648.emea1.cds.t-internal.com> <5076E5E7.7080604@alum.mit.edu> In-Reply-To: <5076E5E7.7080604@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] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:55:14 -0000 Hi Paul, I hope till Sunday latest on Monday. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Gesendet: Donnerstag, 11. Oktober 2012 17:30 An: Jesske, Roland Cc: sipcore@ietf.org Betreff: Re: AW: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-s= ipcore-rfc4244bis-callflows-01 On 10/11/12 2:16 AM, R.Jesske@telekom.de wrote: > Hi Paul, > I'm looking for 3.3, 3.5 and 3.7 Thank you Roland! I see you have already sent comments and questions about a couple of these.= Not surprisingly your initial comments are about the details of the H-I en= tries, which is entirely reasonable, and deserves the most focus. However I= do request that you do your best to verify all aspects of the messages for= correctness. When do you expect to be finished reviewing? Thanks, Paul > Roland > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im > Auftrag von Paul Kyzivat > Gesendet: Mittwoch, 10. Oktober 2012 17:48 > An: sipcore@ietf.org > Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for > draft-ietf-sipcore-rfc4244bis-callflows-01 > > Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. > We have also had a partial review of 3.2 by Dale. > > So we only need volunteers for the other 7.5. > > Thanks, > Paul > > On 10/8/12 2:40 PM, Paul Kyzivat wrote: > >> EVERYBODY INTERESTED IN 4244bis: >> >> This is an example of why we NEED to have careful reviews of the callflo= ws. >> >> So far I have been deafened by the silence. >> There was quite a bit of enthusiasm for both the bis and the >> callflows as long as it only took an email containing "+1". >> Who, other than the authors, wants these enough to do some work??? >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> 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 brett@broadsoft.com Fri Oct 12 06:21:10 2012 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 14F3021F8540 for ; Fri, 12 Oct 2012 06:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuvf9DvUtH2K for ; Fri, 12 Oct 2012 06:21:09 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1BE21F8539 for ; Fri, 12 Oct 2012 06:21:09 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 06:21:10 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 06:21:10 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.1 comments Thread-Index: Ac2ofG+MdMl2GIXbTieAdwk8f18WGA== Date: Fri, 12 Oct 2012 13:21:09 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016A80@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.1 comments 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, 12 Oct 2012 13:21:10 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.1. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) F4 and F5 need a To tag to be RFC 3261 compliant. 3) The Record-Route should be removed from F4 and F11. 4) Unique Via branch identifiers cannot be reused. Thus F6 should have a d= ifferent unique Top via branch; adjust F7 accordingly. 5) F6 via branch must match F1 via branch; adjust F8 accordingly. 6) F7 must contain a Contact; adjust F8 accordingly. 7) F8 needs the Record-Route. 8) F9, F10, F11, F13 need to be adjusted similar to 4) and 5). 9) Different locations should not be generating the same To tag. F10, F11,= and F13 should not contain the To tag sent in F7. 10) F12 and F14 need a To tag to be RFC 3261 compliant. 11) F12 and F14 via branches must match F1. 12) F13 From contains extra ';'. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 07:04:16 2012 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 70E2F21F860E for ; Fri, 12 Oct 2012 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUUUVQsfp9L for ; Fri, 12 Oct 2012 07:04:16 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3A21F85C2 for ; Fri, 12 Oct 2012 07:04:15 -0700 (PDT) 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; Fri, 12 Oct 2012 07:04:17 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 07:04:17 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.2 comments Thread-Index: Ac2ognX5/fF/m+JyQxO0h5GlMDkOzQ== Date: Fri, 12 Oct 2012 14:04:16 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016A9F@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.2 comments 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, 12 Oct 2012 14:04:16 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.2. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) Concerning F1 Privacy header, I recommend "History" be change to "histor= y" to reflect the IANA registered case. 3) I recommend F3 and F4 not use only the magic cookie as the Via branch. 4) F2, F3, F4, F5 and F6 should contain Record-Route or Figure 1 should ind= icate single ACK from Alice to Bob. 5) Last History-Info of F6 is corrupted; compare with F5. 6) It seems strange that the second figure is labeled figure 1. Section 3.= 1's figure should likely be labeled figure 1. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 07:32:04 2012 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 4E70921F85B4 for ; Fri, 12 Oct 2012 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt3C-aZZNtJo for ; Fri, 12 Oct 2012 07:32:03 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68821F84DE for ; Fri, 12 Oct 2012 07:31:58 -0700 (PDT) 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; Fri, 12 Oct 2012 07:31:59 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 07:31:59 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.3 comments Thread-Index: Ac2ohlSzBIB0LdZvT/St9Kj74zDMQg== Date: Fri, 12 Oct 2012 14:31:59 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016AB5@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.3 comments 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, 12 Oct 2012 14:32:04 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.3. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) F2, F3, F4, F5 and F6 should contain Record-Route or Figure 2 should ind= icate single ACK from Alice to Bob. 3) To be RFC 3261 compliant, Via sent-by containing an FQDN must cause the = received parameter to be added by the proxy/UAS receiving the request. Thu= s F3, F4, and F5 should be adjusted accordingly. The same applies to secti= ons 3.1 and 3.2. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 08:00:23 2012 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 DF93021F8628 for ; Fri, 12 Oct 2012 08:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-QpSRWeIi4g for ; Fri, 12 Oct 2012 08:00:23 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 74D9621F8619 for ; Fri, 12 Oct 2012 08:00:23 -0700 (PDT) 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; Fri, 12 Oct 2012 08:00:25 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 08:00:25 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.4 comments Thread-Index: Ac2oik1iZHmXd+IEStOdiC+IryjLMg== Date: Fri, 12 Oct 2012 15:00:24 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016AC2@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.4 comments 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, 12 Oct 2012 15:00:24 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.4. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) Figure is missing an ACK for 302; consider it optional to also include t= he ACK message details. 3) To be RFC 3261 compliant, Via sent-by containing an FQDN must cause the = received parameter to be added by the proxy/UAS receiving the request. Thu= s F3 should be adjusted accordingly. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 08:39:44 2012 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 9268621F86E3 for ; Fri, 12 Oct 2012 08:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntNuzL18idlY for ; Fri, 12 Oct 2012 08:39:44 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8D21F86EE for ; Fri, 12 Oct 2012 08:39:40 -0700 (PDT) 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; Fri, 12 Oct 2012 08:39:41 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 08:39:41 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.5 comments Thread-Index: Ac2oj8mIFAfj7K2oT92iJTD8f1jFvg== Date: Fri, 12 Oct 2012 15:39:40 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016AD0@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.5 comments 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, 12 Oct 2012 15:39:44 -0000 The following is a WGLC comment concerning draft-ietf-sipcore-rfc4244bis-ca= llflows-01 section 3.5. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 09:18:22 2012 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 CDB7121F86DB for ; Fri, 12 Oct 2012 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ0nl6zj-mPm for ; Fri, 12 Oct 2012 09:18:22 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5039521F86D9 for ; Fri, 12 Oct 2012 09:18:22 -0700 (PDT) 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; Fri, 12 Oct 2012 09:18:23 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 09:18:23 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.6 comments Thread-Index: Ac2olTHTfWVB9h+tRnahWQdMDHDo6A== Date: Fri, 12 Oct 2012 16:18:23 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016AF3@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.6 comments 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, 12 Oct 2012 16:18:23 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.6. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) Figure is missing an ACK for 302; consider it optional to also include t= he ACK message details. 3) For draft-ietf-sipcore-rfc4244bis compliance, F1 appears to need a Histo= ry-Info. 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs mp=3D1= added to the Contact. 5) F1 and F6 are missing SIP/2.0 This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 09:26:32 2012 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 5E53A21F8732 for ; Fri, 12 Oct 2012 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFNxZfm5bNUe for ; Fri, 12 Oct 2012 09:26:31 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id E10E821F8731 for ; Fri, 12 Oct 2012 09:26:31 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 09:26:33 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 09:26:33 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQg== Date: Fri, 12 Oct 2012 16:26:33 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 12 Oct 2012 16:26:32 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.7. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) Figure is missing an ACK for 302; consider it optional to also include t= he ACK message details. 3) For draft-ietf-sipcore-rfc4244bis compliance, F1 appears to need a Histo= ry-Info. 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs mp=3D1= added to the Contact. 5) F1 and F6 are missing SIP/2.0 This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From worley@shell01.TheWorld.com Fri Oct 12 09:38:04 2012 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 2114721F871D for ; Fri, 12 Oct 2012 09:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.066, 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 6BxP61eM4ne7 for ; Fri, 12 Oct 2012 09:38:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2589D21F8713 for ; Fri, 12 Oct 2012 09:38:02 -0700 (PDT) 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 q9CGbYOA014639; Fri, 12 Oct 2012 12:37:37 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9CGbY4G4435991; Fri, 12 Oct 2012 12:37:34 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9CGbX9r4214916; Fri, 12 Oct 2012 12:37:33 -0400 (EDT) Date: Fri, 12 Oct 2012 12:37:33 -0400 (EDT) Message-Id: <201210121637.q9CGbX9r4214916@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Shida Schubert In-reply-to: <2BB5565E-F13A-4D94-9C6D-54F72881E014@ntt-at.com> (shida@ntt-at.com) Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 12 Oct 2012 16:38:04 -0000 > From: Shida Schubert > > I agree, this can happen. I was just thinking about our > network.. Where this is not likely to happen.. > > Anyway, what do you suggest we do? Do we just make > a note stating that this can happen and when this > happens, information will not be as useful unless the > entity utilizing the hi-entries have extended knowledge > of the network?? OR make use of other information > such as (associated response code etc.) Well, we could just live with the problem. We do have to warn implementers, because an implementation must not drop one of a pair of hi-entries with duplicate indexes, and the "obvious" implementations might do that. A problem with that approach is that the situation would arise consistently for any call that originated from a supporting system, was forked within a non-supporting system, and had two destinations in supporting systems. (And that can happen with "call forward on no answer" and "call forward on busy".) The number of caller/called-directory-number combinations that cause that pattern would probably be small, but for such a combination, *every* call would produce the *same* sort of problematic History-Info. > Or do we add another layer of complexity to already complex > mechanism? I'd phrase it, "Fix the problem with a minimum of additional complexity." We could use a version of what I suggested in my e-mail of 19 Apr 2012 during the WGLC (http://www.ietf.org/mail-archive/web/sipcore/current/msg04830.html) -- which I notice that nobody responded to: > One way to avoid this problem is to add a random number after the "0", > so the hi-entries created by the two UASs are (probably) different: > > History-Info: ;index=1.1.0.42949 > History-Info: ;index=1.1.0.34317 > > To do this consistently and statelessly, one can hash the branch > parameter of the topmost Via of the incoming request, extract 16 bits > and add 1. By the Birthday Paradox, using 16 bits for the number, > twenty forks can be accommodated with a low probability (0.3%) of > collision. > > With this change, the final response would have this H-I: > > History-Info: ;index=1 > History-Info: ;np=1;index=1.1 > History-Info: ;index=1.1.0.34317 > History-Info: ;index=1.1.0.42949 The essential idea is that any entity adding a "0" hi-entry follows the "0" with a random number taken from a sufficiently large set. (One way to generate such random numbers is to hash the branch parameter of the topmost Via, which has the advantage of being stateless.) If the range of the random numbers is sufficiently large, the chances of the entities on two branches choosing the same number is small enough that there isn't a problem in practice. We can use the "birthday paradox" formulas to determine the needed range for the random numbers. If: k = maximum number of forks expected within the non-supported proxies within the "gap" L = probability of the hi-entries generated by the k forks having duplicate random number parts n = range of the generated random numbers then the minimum range is (to a close approximation): n = k^2 / 2*L A conservative choice is k (maximum number of forks) = 10 and L = 10^-5 ("five nines" reliability), which gives n = 5,000,000. That requires 7 digit random numbers. Adjusting the assumptions will change the needed range, of course. Given that the needed range is only half of the range of seven-digit numbers, we could restrict the range to 1000000 to 9999999, and eliminate the "0", since any number with seven digits could only come from gap processing. This would make the final response in the above example: History-Info: ;index=1 History-Info: ;np=1;index=1.1 History-Info: ;index=1.1.3431783 History-Info: ;index=1.1.4294938 There may be better solutions, though. Dale From mary.ietf.barnes@gmail.com Fri Oct 12 09:40:54 2012 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 AC3B621F8758 for ; Fri, 12 Oct 2012 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 evmW3yzSfXGj for ; Fri, 12 Oct 2012 09:40:54 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1C21F8757 for ; Fri, 12 Oct 2012 09:40:53 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2382526lam.31 for ; Fri, 12 Oct 2012 09:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lkYf1AlsQj6tnFXsERiUivSyytPyKPAcrC1j28BbMvk=; b=BSD+JOmxQXK/Ur9C1v+uiWCRxPBZQiuGpT962F0XdZmrK17A4QiF4zLbQz+fC0sSA/ VqQF3H0Jm1f7phs44nk6tvkZ7SSpU3GindA4pRrNDfuvo2mNtD95eaTrzQoKqW7PtaWk wiTzdB1DtejsIbwwSmTT2VzP+bWFhrerugnR4nBj1ruh/s3GmfrMbNiOh2HQNtM+c3L/ b3fqq5qYkCjpkbVS6lghufHiA/XPreypVfMNj2hG6Vt9y7AZc2EnSDLF5WDS9YMKFMGO a5ikP5QB+Hm1O3rRlgh7CrVeJRSukmDBLmZHOwCPBunk0hRJaX8KsFZfHcZ5Raw7Y5hK B0Ow== MIME-Version: 1.0 Received: by 10.112.39.138 with SMTP id p10mr1894465lbk.54.1350060052298; Fri, 12 Oct 2012 09:40:52 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Fri, 12 Oct 2012 09:40:52 -0700 (PDT) In-Reply-To: <2BB5565E-F13A-4D94-9C6D-54F72881E014@ntt-at.com> References: <201210111651.q9BGp8894383931@shell01.TheWorld.com> <2BB5565E-F13A-4D94-9C6D-54F72881E014@ntt-at.com> Date: Fri, 12 Oct 2012 11:40:52 -0500 Message-ID: From: Mary Barnes To: Shida Schubert Content-Type: multipart/alternative; boundary=485b390f7ac4d7bbe104cbdf597b Cc: "Dale R. Worley" , sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 12 Oct 2012 16:40:54 -0000 --485b390f7ac4d7bbe104cbdf597b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 11, 2012 at 10:47 PM, Shida Schubert wrote: > > Hi Dale; > > I agree, this can happen. I was just thinking about our > network.. Where this is not likely to happen.. > > Anyway, what do you suggest we do? Do we just make > a note stating that this can happen and when this > happens, information will not be as useful unless the > entity utilizing the hi-entries have extended knowledge > of the network?? OR make use of other information > such as (associated response code etc.) > [MB] My opinion is that we perhaps expand the text in the application consideration section. We already highlight that this can happen. But, I absolutely do not believe it's useful to complicate the protocol. Note, we already discussion backwards compatibility issues in section 16.1. I would like to understand what might be missing and not quite so clear in these sections than add *anything* into the body of the document.[/MB] > > Or do we add another layer of complexity to already > complex mechanism? > > Regards > Shida > > On Oct 12, 2012, at 1:51 AM, Dale R. Worley wrote: > > >> From: Shida Schubert > >> > >>> The core issue is this: > >>> > >>> Are two entries with the same index value allowed in > >>> History-Info? > >> > >> As far as I know RFC4244 doesn't have any mechanism to > >> prevent this from happening, so yes it could happen. Whether this > >> will happen in reality, I am not sure.. > > > > I have previously posted a detailed example showing how it could > > happen. See > > http://www.ietf.org/mail-archive/web/sipcore/current/msg05220.html, > > item 3. You may consider it to be unrealistic, but it seems quite > > realistic to me. That situation will arise any time a non-supporting > > proxy forks a request to two supporting destinations. > > > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --485b390f7ac4d7bbe104cbdf597b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 11, 2012 at 10:47 PM, Shida = Schubert <shida@ntt-at.com> wrote:

Hi Dale;

=A0I agree, this can happen. I was just thinking about our
network.. Where this is not likely to happen..

=A0Anyway, what do you suggest we do? Do we just make
a note stating that this can happen and when this
happens, information will not be as useful unless the
entity utilizing the hi-entries have extended knowledge
of the network?? OR make use of other information
such as (associated response code etc.)
[MB] My opinio= n is that we perhaps expand the text in the application consideration secti= on. We already highlight that this can happen. =A0But, I absolutely do not = believe it's useful to complicate the protocol. Note, we already discus= sion backwards compatibility issues in section 16.1. =A0I would like to und= erstand what might be missing and not quite so clear in these sections than= add *anything* into the body of the document.[/MB]=A0

=A0Or do we add another layer of complexity to already
complex mechanism?

=A0Regards
=A0 Shida

On Oct 12, 2012, at 1:51 AM, Dale R. Worley wrote:

>> From: Shida Schubert <shida= @ntt-at.com>
>>
>>> The core issue is this:
>>>
>>> =A0 Are two entries with the same index value allowed in
>>> =A0 History-Info?
>>
>> As far as I know RFC4244 doesn't have any mechanism to
>> prevent this from happening, so yes it could happen. Whether this<= br> >> will happen in reality, I am not sure..
>
> I have previously posted a detailed example showing how it could
> happen. =A0See
> http://www.ietf.org/mail-archive/web/sipcore/cur= rent/msg05220.html,
> item 3. =A0You may consider it to be unrealistic, but it seems quite > realistic to me. =A0That situation will arise any time a non-supportin= g
> proxy forks a request to two supporting destinations.
>
> Dale

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

--485b390f7ac4d7bbe104cbdf597b-- From mary.ietf.barnes@gmail.com Fri Oct 12 09:46:17 2012 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 9EFFE21F8738 for ; Fri, 12 Oct 2012 09:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uO2se+s-AwXO for ; Fri, 12 Oct 2012 09:46:16 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF821F86A2 for ; Fri, 12 Oct 2012 09:46:15 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2385840lam.31 for ; Fri, 12 Oct 2012 09:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OUHhuLu7NrFlkhcer+vIU056CPl3p8P9UqUSc4Ddy90=; b=PdQtC2wejgnkENMeLkWMK2/d8R6G3dDGjExMWgkgWZgFQ9naUhsesUy5lB7dhNFnvN FWoAXjXrkdh3d4zlvTIn4KRc+jQOoRoqbeFeELaXANIW99HtQ544HvMeYZV6nxL3iaZP tLHesgvQczDMDm12+9qHi9cxVzaXvuLh43BFpPT+aeEi79ZgDWu+KD7Jzz1UjaTLtDjW 81yXEzZHItuHm3iktuSci0YNYI7bhQolZz44SEFRpIXaiNRFLIITXRTDW2W4Zx4MKRRA EJWdBT4XurvfH4d8jIszhB548Zo0RwYNQ3IoRCHq1jYuRVkNZzcbRLACHYP9i9ndzsEs /2Dw== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr4439765lab.11.1350060374879; Fri, 12 Oct 2012 09:46:14 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Fri, 12 Oct 2012 09:46:14 -0700 (PDT) In-Reply-To: <201210121637.q9CGbX9r4214916@shell01.TheWorld.com> References: <2BB5565E-F13A-4D94-9C6D-54F72881E014@ntt-at.com> <201210121637.q9CGbX9r4214916@shell01.TheWorld.com> Date: Fri, 12 Oct 2012 11:46:14 -0500 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=bcaec54eecc811eb9504cbdf6d39 Cc: sipcore@ietf.org Subject: Re: [sipcore] 4244bis-callflows 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, 12 Oct 2012 16:46:17 -0000 --bcaec54eecc811eb9504cbdf6d39 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 12, 2012 at 11:37 AM, Dale R. Worley wrote: > > From: Shida Schubert > > > > I agree, this can happen. I was just thinking about our > > network.. Where this is not likely to happen.. > > > > Anyway, what do you suggest we do? Do we just make > > a note stating that this can happen and when this > > happens, information will not be as useful unless the > > entity utilizing the hi-entries have extended knowledge > > of the network?? OR make use of other information > > such as (associated response code etc.) > > Well, we could just live with the problem. We do have to warn > implementers, because an implementation must not drop one of a pair of > hi-entries with duplicate indexes, and the "obvious" implementations > might do that. > > A problem with that approach is that the situation would arise > consistently for any call that originated from a supporting system, > was forked within a non-supporting system, and had two destinations in > supporting systems. (And that can happen with "call forward on no > answer" and "call forward on busy".) > > The number of caller/called-directory-number combinations that cause > that pattern would probably be small, but for such a combination, > *every* call would produce the *same* sort of problematic > History-Info. > [MB] Per the response I just sent, we already address this in sections 11 (Application considerations) and section 16.1 (Backwards compatibility). Please review those sections and provide text that you think is missing or might be helpful. [/MB] > > > Or do we add another layer of complexity to already complex > > mechanism? > > I'd phrase it, "Fix the problem with a minimum of additional > complexity." > > We could use a version of what I suggested in my e-mail of 19 Apr 2012 > during the WGLC > (http://www.ietf.org/mail-archive/web/sipcore/current/msg04830.html) > -- which I notice that nobody responded to: > > > One way to avoid this problem is to add a random number after the "0", > > so the hi-entries created by the two UASs are (probably) different: > > > > History-Info: ;index=1.1.0.42949 > > History-Info: ;index=1.1.0.34317 > > > > To do this consistently and statelessly, one can hash the branch > > parameter of the topmost Via of the incoming request, extract 16 bits > > and add 1. By the Birthday Paradox, using 16 bits for the number, > > twenty forks can be accommodated with a low probability (0.3%) of > > collision. > > > > With this change, the final response would have this H-I: > > > > History-Info: ;index=1 > > History-Info: ;np=1;index=1.1 > > History-Info: ;index=1.1.0.34317 > > History-Info: &Reason=SIP%3Bcause%3D4xx>;index=1.1.0.42949 > > The essential idea is that any entity adding a "0" hi-entry follows > the "0" with a random number taken from a sufficiently large set. > (One way to generate such random numbers is to hash the branch > parameter of the topmost Via, which has the advantage of being > stateless.) If the range of the random numbers is sufficiently large, > the chances of the entities on two branches choosing the same number > is small enough that there isn't a problem in practice. > > We can use the "birthday paradox" formulas to determine the needed > range for the random numbers. If: > > k = maximum number of forks expected within the non-supported proxies > within the "gap" > > L = probability of the hi-entries generated by the k forks having > duplicate random number parts > > n = range of the generated random numbers > > then the minimum range is (to a close approximation): > > n = k^2 / 2*L > > A conservative choice is k (maximum number of forks) = 10 and L = > 10^-5 ("five nines" reliability), which gives n = 5,000,000. That > requires 7 digit random numbers. Adjusting the assumptions will > change the needed range, of course. > > Given that the needed range is only half of the range of seven-digit > numbers, we could restrict the range to 1000000 to 9999999, and > eliminate the "0", since any number with seven digits could only come > from gap processing. This would make the final response in the above > example: > > History-Info: ;index=1 > History-Info: ;np=1;index=1.1 > History-Info: ;index=1.1.3431783 > History-Info: &Reason=SIP%3Bcause%3D4xx>;index=1.1.4294938 > > There may be better solutions, though. > [MB] This really doesn't make sense to add this complexity for the applications that we anticipate to use 4244bis (which are those that are in the original call flow document). In the cases of the missing entries, most applications will need default behavior rather than sorting through complex indices. For debug, you will be able to see what happened. [/MB] > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --bcaec54eecc811eb9504cbdf6d39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 12, 2012 at 11:37 AM, Dale R= . Worley <worley@ariadne.com> wrote:
> From: Shida Schubert <shida@ntt= -at.com>
>
> I agree, this can happen. I was just thinking about our
> network.. Where this is not likely to happen..
>
> Anyway, what do you suggest we do? Do we just make
> a note stating that this can happen and when this
> happens, information will not be as useful unless the
> entity utilizing the hi-entries have extended knowledge
> of the network?? OR make use of other information
> such as (associated response code etc.)

Well, we could just live with the problem. =A0We do have to warn
implementers, because an implementation must not drop one of a pair of
hi-entries with duplicate indexes, and the "obvious" implementati= ons
might do that.

A problem with that approach is that the situation would arise
consistently for any call that originated from a supporting system,
was forked within a non-supporting system, and had two destinations in
supporting systems. =A0(And that can happen with "call forward on no answer" and "call forward on busy".)

The number of caller/called-directory-number combinations that cause
that pattern would probably be small, but for such a combination,
*every* call would produce the *same* sort of problematic
History-Info.
[MB] Per the response I just sent, we al= ready address this in sections 11 (Application considerations) and section = 16.1 (Backwards compatibility). Please review those sections and provide te= xt that you think is missing or might be helpful. [/MB]

> Or do we add another layer of complexity to already complex
> mechanism?

I'd phrase it, "Fix the problem with a minimum of additional=
complexity."

We could use a version of what I suggested in my e-mail of 19 Apr 2012
during the WGLC
(http://www.ietf.org/mail-archive/web/sipcore/current= /msg04830.html)
-- which I notice that nobody responded to:

> One way to avoid this problem is to add a random number after the &quo= t;0",
> so the hi-entries created by the two UASs are (probably) different: >
> =A0 =A0History-Info: <sip:bo= b@192.0.2.3>;index=3D1.1.0.42949
> =A0 =A0History-Info: <sip:bo= b@192.0.2.7>;index=3D1.1.0.34317
>
> To do this consistently and statelessly, one can hash the branch
> parameter of the topmost Via of the incoming request, extract 16 bits<= br> > and add 1. =A0By the Birthday Paradox, using 16 bits for the number, > twenty forks can be accommodated with a low probability (0.3%) of
> collision.
>
> With this change, the final response would have this H-I:
>
> =A0 =A0History-Info: <sip:bob@biloxi.example.com;p=3Dx>;index=3D1
> =A0 =A0History-Info: <sip:bob@biloxi.example.com;p=3Dx>;np=3D1;index=3D1.1
> =A0 =A0History-Info: <sip:bo= b@192.0.2.7>;index=3D1.1.0.34317
> =A0 =A0History-Info: <sip:bo= b@192.0.2.3&Reason=3DSIP%3Bcause%3D4xx>;index=3D1.1.0.42949

The essential idea is that any entity adding a "0" hi-entry follo= ws
the "0" with a random number taken from a sufficiently large set.=
(One way to generate such random numbers is to hash the branch
parameter of the topmost Via, which has the advantage of being
stateless.) =A0If the range of the random numbers is sufficiently large, the chances of the entities on two branches choosing the same number
is small enough that there isn't a problem in practice.

We can use the "birthday paradox" formulas to determine the neede= d
range for the random numbers. If:

k =3D maximum number of forks expected within the non-supported proxies
within the "gap"

L =3D probability of the hi-entries generated by the k forks having
duplicate random number parts

n =3D range of the generated random numbers

then the minimum range is (to a close approximation):

n =3D k^2 / 2*L

A conservative choice is k (maximum number of forks) =3D 10 and L =3D
10^-5 ("five nines" reliability), which gives n =3D 5,000,000. = =A0That
requires 7 digit random numbers. =A0Adjusting the assumptions will
change the needed range, of course.

Given that the needed range is only half of the range of seven-digit
numbers, we could restrict the range to 1000000 to 9999999, and
eliminate the "0", since any number with seven digits could only = come
from gap processing. =A0This would make the final response in the above
example:

=A0 =A0 History-Info: <s= ip:bob@biloxi.example.com;p=3Dx>;index=3D1
=A0 =A0 History-Info: <s= ip:bob@biloxi.example.com;p=3Dx>;np=3D1;index=3D1.1
=A0 =A0 History-Info: <sip:bob@19= 2.0.2.7>;index=3D1.1.3431783
=A0 =A0 History-Info: <sip:bob@19= 2.0.2.3&Reason=3DSIP%3Bcause%3D4xx>;index=3D1.1.4294938

There may be better solutions, though.
[MB] This reall= y doesn't make sense to add this complexity for the applications that w= e anticipate to use 4244bis (which are those that are in the original call = flow document). =A0In the cases of the missing entries, most applications w= ill need default behavior rather than sorting through complex indices. =A0F= or debug, you will be able to see what happened. [/MB]=A0

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

--bcaec54eecc811eb9504cbdf6d39-- From brett@broadsoft.com Fri Oct 12 10:08:15 2012 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 32A5E21F87B4 for ; Fri, 12 Oct 2012 10:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cn3ewSO7Irq for ; Fri, 12 Oct 2012 10:08:13 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id DB4C621F87A2 for ; Fri, 12 Oct 2012 10:08:13 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 10:08:15 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 10:08:15 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.8 comments Thread-Index: Ac2onCjrQfpHulnBT0SqDCk23ZEmdQ== Date: Fri, 12 Oct 2012 17:08:14 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016B6A@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.8 comments 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, 12 Oct 2012 17:08:15 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.8. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) If not intentional (e.g. switching to TCP because INVITE message size), = the example registers a contact which indicates SHOULD use UDP; however it = is reached using TCP. The same comment applies to section 3.5. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 10:14:56 2012 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 9548821F87B6 for ; Fri, 12 Oct 2012 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFqTIvDGTB8V for ; Fri, 12 Oct 2012 10:14:56 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8E421F86AF for ; Fri, 12 Oct 2012 10:14:56 -0700 (PDT) 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; Fri, 12 Oct 2012 10:14:57 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 10:14:57 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.9 comments Thread-Index: Ac2onRiqUMqflAteQKCHSusNjacQkQ== Date: Fri, 12 Oct 2012 17:14:56 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016B7F@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.9 comments 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, 12 Oct 2012 17:14:56 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.9. 1) All of the requests must include Max-Forwards to be RFC 3261 compliant. 2) If not intentional (e.g. switching to TCP because INVITE message size), = the example registers a contact which indicates SHOULD use UDP; however it = is reached using TCP. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 10:20:37 2012 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 684CF21F87C1 for ; Fri, 12 Oct 2012 10:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEVvAJnBr0Ae for ; Fri, 12 Oct 2012 10:20:37 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id F3AEC21F87B9 for ; Fri, 12 Oct 2012 10:20:36 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 10:20:38 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 10:20:38 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.11 comments Thread-Index: Ac2onePLhfYcVHOZQTGu4eAFGkXaMQ== Date: Fri, 12 Oct 2012 17:20:37 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.11 comments 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, 12 Oct 2012 17:20:37 -0000 The following are some WGLC comments concerning draft-ietf-sipcore-rfc4244b= is-callflows-01 section 3.11. 1) F2 Max-Forwards should be 69. 2) F3 Max-Forwards should be 68. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From brett@broadsoft.com Fri Oct 12 11:08:42 2012 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 8BF2621F8643 for ; Fri, 12 Oct 2012 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv65XfEH4t75 for ; Fri, 12 Oct 2012 11:08:42 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 102C621F8605 for ; Fri, 12 Oct 2012 11:08:42 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 11:08:43 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 11:08:43 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.11 comments Thread-Index: Ac2onePLhfYcVHOZQTGu4eAFGkXaMQABEIvQ Date: Fri, 12 Oct 2012 18:08:42 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016BD0@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.11 comments 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, 12 Oct 2012 18:08:42 -0000 > The following are some WGLC comments concerning=20 > draft-ietf-sipcore-rfc4244bis-callflows-01 section 3.11. >=20 > 1) F2 Max-Forwards should be 69. >=20 > 2) F3 Max-Forwards should be 68. 3) For draft-ietf-sipcore-rfc4244bis compliance, F1 appears to need a Histo= ry-Info if Alice's device supports the draft. 4) If Alice's device wants the History-Info in response, F1 must include "S= upported: histinfo". 5) F1, F2, and F3 need the To's URI enclosed in angle brackets. From christer.holmberg@ericsson.com Fri Oct 12 11:46:42 2012 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 E04F721F86FD for ; Fri, 12 Oct 2012 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ZraA-5ukqw6y for ; Fri, 12 Oct 2012 11:46:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E6ADC21F86FC for ; Fri, 12 Oct 2012 11:46:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-63-507865907584 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1D.A0.17130.09568705; Fri, 12 Oct 2012 20:46:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Oct 2012 20:46:40 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 12 Oct 2012 20:46:39 +0200 Thread-Topic: Proxy-feature: Suggested changes/additions based on IESG review Thread-Index: AQHNqKnqO1B02hC1ck6YlLPrJOuxZQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvre7E1IoAgzftTBZ7/i5it1ix4QCr xbU5jWwWX39sYnNg8fj7/gOTx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVMfN9ZcFMzopX z86zNDDOZ+9i5OSQEDCReLZtFzOELSZx4d56ti5GLg4hgVOMEodbj7KAJIQEFjJKPJjI1MXI wcEmYCHR/U8bJCwioCmx/NtWsDnMAk2MEqd264PYLAKqEp9Pd7GC2MICHhKPjpxihaj3lfhy 7gQzhK0nce1uIxuIzSsQLtF19zJYnBHohu+n1jBBzBSXuPVkPhPEbQISS/ach7pTVOLl43+s EPWiEnfa1zNC1OtJ3Jg6hQ3C1pZYtvA1M8R8QYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUV o3BuYmZOerm5XmpRZnJxcX6eXnHqJkZglBzc8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYBR77dMm8Kwy9aU4A8/SrfOkVt5lq3nIb+ax3GatabxKnNy6 xNW1hp6LGx8o3lZ9vdxz7+KZWjX1X6N/XrRo4JItMHY6Gl/+9TQr41vzoM1XZi37e1PwOdsH /aSvVwL/SrDs3xOxS+fg191xFxSDZE+6HJX6/tJwSffeNtcWo533emdtY9w8jV2JpTgj0VCL uag4EQB3nEHTYAIAAA== Subject: [sipcore] Proxy-feature: Suggested changes/additions based on IESG review 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, 12 Oct 2012 18:46:43 -0000 Hi, Based on comments during the IESG review, there are a couple of suggested c= hanges/additions to draft-ietf-sipcore-proxy-feature that we want to bring = to the attention of the WG. First, it has been suggested that all 2119 uppercase words in section 5.3 (= Feature Capability Indicator Specification Requirements) and section 8 (Fea= ture Capability Indicator Registration Template) are changed to lowercase. = The reason is because the sections are about documentation, not interoperab= ility. Second, it was suggested to clarify whether an entity can remove or re-orde= r Feature-Caps header fields within a SIP message. We suggest the following= paragraph to be added to section 4.2.1: "Based on features and policies, a SIP entity MAY remove a Feature- Caps header field from a SIP message. Also, a SIP entity MAY remove a feature capability indicator from a Feature-Caps header field within a SIP message. A SIP entity SHOULD NOT re-order the Feature- Caps header fields within a SIP message." Please indicate if you object to these suggested changes/additions. Thanks! Regards, Christer From brett@broadsoft.com Fri Oct 12 11:57:57 2012 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 1358721F86F5 for ; Fri, 12 Oct 2012 11:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiDsXUwX23nQ for ; Fri, 12 Oct 2012 11:57:56 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9697F21F867A for ; Fri, 12 Oct 2012 11:57:56 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 12 Oct 2012 11:57:58 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 12 Oct 2012 11:57:58 -0700 From: Brett Tate To: "R.Jesske@telekom.de" , "sipcore@ietf.org" Thread-Topic: WGLC 4244bis-callflows Use Case 3.3 (3.2) Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6wACivAIAATFTn8A== Date: Fri, 12 Oct 2012 18:57:58 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016C03@MBX06.citservers.local> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 12 Oct 2012 18:57:57 -0000 > Why does put the UA an History-Info into the INVITE? It is required. The following thread contains Dale's response to my recent= question. http://www.ietf.org/mail-archive/web/sipcore/current/msg05246.html The following are some draft-ietf-sipcore-rfc4244bis-10 snippets. Section 6.1: "When issuing a request, the UAC MUST follow the procedures in Section 9.2. In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi- entries with which to populate the History-Info header field and the hi-index is set to 1 per Section 10.3." Section 9.2: "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," From pkyzivat@alum.mit.edu Sun Oct 14 13:22:29 2012 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 D9EE821F8487 for ; Sun, 14 Oct 2012 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[AWL=0.081, 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 2pol+AB6eXfG for ; Sun, 14 Oct 2012 13:22:29 -0700 (PDT) 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 4A7A821F8455 for ; Sun, 14 Oct 2012 13:22:28 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id B4MK1k0081uE5Es538NZoB; Sun, 14 Oct 2012 20:22:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id B8Hm1k0053ZTu2S3c8Hmgk; Sun, 14 Oct 2012 20:17:46 +0000 Message-ID: <507B1DD7.4020608@alum.mit.edu> Date: Sun, 14 Oct 2012 16:17:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B88016BD0@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016BD0@MBX06.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 20:22:30 -0000 Brett, Thank you very much for the review of all the flows. That is above and beyond the call of duty!!! I do want to confirm with you exactly what you did, and didn't review in these flows. Based on the nature of your comments, I am guessing that you focused on the generic sip aspects of the flows. (This is great, because others don't seem to be doing that, and you are exceedingly qualified to do this.) You didn't comment much on the H-I parts. I am guessing that means that you were deferring to others on that. Did I guess right? Thanks again, Paul From shida@ntt-at.com Mon Oct 15 04:01:18 2012 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 295B321F86B6 for ; Mon, 15 Oct 2012 04:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.94 X-Spam-Level: X-Spam-Status: No, score=-100.94 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_20=-0.74, 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 dEKMvsNd2yjr for ; Mon, 15 Oct 2012 04:01:16 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE1F21F86C4 for ; Mon, 15 Oct 2012 04:01:16 -0700 (PDT) Received: from [118.109.76.216] (port=49369 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TNiQ5-0003CP-BO; Mon, 15 Oct 2012 06:01:13 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> Date: Mon, 15 Oct 2012 20:01:09 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3A3C5B49-C395-4AF5-BE04-D1E7E4216279@ntt-at.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:49369 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 15 Oct 2012 11:01:18 -0000 Hi Roland; Many thanks for your thorough review.=20 On Oct 11, 2012, at 3:56 PM, = wrote: > Hi, > Review for 3.3 (including parts of 3.2) >=20 > 1. History-Info included by the UAC > Why does put the UA an History-Info into the INVITE? Of course the UA = is allowed to do it but why? > My understanding of H-I is to track changes due to retargeting and = forwarding. The UAC does not know what will happen with the Request URI. > Nevertheless I have no problem since this is an example. But I do not = see an value add. (This comment belongs also to other use cases) As far as I recall, it was so that the first R-URI is recorded.=20 There is not guarantee that the first proxy on the path will=20 support H-I and with 4244bis, and by having UAC inserting=20 hi-entry when supporting 4244bis, there is more chance to=20 capture the first R-URI. >=20 > 2. F2 INVITE > ... > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > ... >=20 > Why is there an entry added with rc? > There is no change of the request URI therefore no reason to add = anything. You are right this I believe is an error. There should NOT be any "rc". >=20 > This comment belongs at also to call flow 3.2 even the first entry is = anonymized the 2nd has the same information. >=20 > So in 3.2 the flows indicates > F1 INVITE > ... > History-Info: ;index=3D1 > ... >=20 > F2 INVITE >=20 > ... > History-Info: ;index=3D1 > History-Info: ;index=3D1.1;rc=3D1 > ... >=20 True will fix this..=20 > --> 2nd entry is wrong there was no retargeting/change within the = request URI. >=20 > 3. History-Info forwarded to the UAS > Why is the History-Info forwarded to the UAS? > That is only allowed when the UAS is within the same trust domain. > Either this must mentioned explicitly within the description or the = entry has to be anonymized. =20 One of the use-case for History-Info is delivering the request uri = parameter to the UAS,=20 which is usually lost during retargeting.. A use-case in 3.8, 3.9 and 3.10 illustrates the need to deliver = history-info to=20 UAS in some scenario.=20 >=20 >=20 >=20 > 4. Question is why we have this use case? > Because in 3.2 we have already a privacy value of an entry. So from my = side it is already covered by 3.2. > Which leads me to the question which privacy scenarios should be shown = within the call flows. > --> I would propose to change 3.2 without an entry privacy. Are you saying that we don't need 3.3 because we have privacy based on = privacy header and=20 per-entry privacy using the uri parameter?? If so, I tend to agree if = other people are okay with=20 removing 3.3 and only leaving 3.2 to show call-flow with privacy = enabled.=20 Many Thanks! Shida >=20 > Best Regards >=20 > Roland From shida@ntt-at.com Mon Oct 15 04:02:18 2012 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 3BF7421F8707 for ; Mon, 15 Oct 2012 04:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.493 X-Spam-Level: X-Spam-Status: No, score=-100.493 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, 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 EUlgo50JlGb6 for ; Mon, 15 Oct 2012 04:02:17 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B9E5021F8705 for ; Mon, 15 Oct 2012 04:02:17 -0700 (PDT) Received: from [118.109.76.216] (port=49369 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TNiR4-0003CP-SU; Mon, 15 Oct 2012 06:02:15 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> Date: Mon, 15 Oct 2012 20:02:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6AEDEE05-7EDE-45C7-AF77-5136A92084C8@ntt-at.com> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:49369 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.11 comments 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, 15 Oct 2012 11:02:18 -0000 Hi Brett; Rather than saying thanks to all of your comments, I will=20 just say a BIG THANKS to all of your comments you have=20 sent so far.=20 We will reflect your comments when we update the=20 draft..=20 Thanks Shida On Oct 13, 2012, at 2:20 AM, Brett Tate wrote: > The following are some WGLC comments concerning = draft-ietf-sipcore-rfc4244bis-callflows-01 section 3.11. >=20 > 1) F2 Max-Forwards should be 69. >=20 > 2) F3 Max-Forwards should be 68. >=20 > This email is intended solely for the person or entity to which it is = addressed and may contain confidential and/or privileged information. If = you are not the intended recipient and have received this email in = error, please notify BroadSoft, Inc. immediately by replying to this = message, or by sending an email to helpdesk@broadsoft.com, and destroy = all copies of this message, along with any attachment, prior to reading, = distributing or copying it. From shida@ntt-at.com Mon Oct 15 04:10:26 2012 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 6949C21F86AB for ; Mon, 15 Oct 2012 04:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.39 X-Spam-Level: X-Spam-Status: No, score=-100.39 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_50=0.001, 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 mTz8uEclSXL6 for ; Mon, 15 Oct 2012 04:10:25 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADD21F86AA for ; Mon, 15 Oct 2012 04:10:25 -0700 (PDT) Received: from [118.109.76.216] (port=49511 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TNiYy-0007Vb-0C; Mon, 15 Oct 2012 06:10:24 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05C59@HE111648.emea1.cds.t-internal.com> Date: Mon, 15 Oct 2012 20:10:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCD23A7-A087-4439-BC86-2F544BE68D09@ntt-at.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05C59@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:49511 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 6 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 15 Oct 2012 11:10:26 -0000 Hi Roland; You are right about the focus of the use-cases.=20 Use-case 3.5, 3.8, 3.9 are more about UAS understanding=20 history-info and making use of the information.=20 Thanks for the suggested text, we will change the text as suggested.=20 =20 Regards Shida On Oct 11, 2012, at 8:28 PM, = wrote: >=20 >=20 >=20 > Hi, > Review for 3.5 >=20 > Main focus on this use case is UAS. > So with regard > to the UAC it is not needed that UAC supports historyinfo. > Only UAS has to do it. >=20 > Perhaps that should be mentioned within the use case. > It will be the same behaviour when the call comes from the PSTN via an = MGC. > So the shown content is independent on the information given within = INVITE F3. >=20 > Also in this case it is not needed that the UAC includes the = History-Info. Why? >=20 > Minor editorial: > Text first paragraph: > Within the IMS the Public User Identity is used --> replacement of = public identity by public user identity (PUID) is proposed. >=20 > Best Regards >=20 > Roland From R.Jesske@telekom.de Mon Oct 15 05:10:57 2012 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 A888411E808A for ; Mon, 15 Oct 2012 05:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 rm-T34emJU0x for ; Mon, 15 Oct 2012 05:10:57 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDE11E808D for ; Mon, 15 Oct 2012 05:10:55 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 15 Oct 2012 14:10:53 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 15 Oct 2012 14:10:53 +0200 From: To: , Date: Mon, 15 Oct 2012 14:10:52 +0200 Thread-Topic: WGLC 4244bis-callflows Use Case 3.3 (3.2) Thread-Index: Ac2lstBpx7Xc7PthQgqRQKZ6AvuYVQBIm/6wACivAIAATFTn8ACAy3qQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545047EAD@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016C03@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016C03@MBX06.citservers.local> 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 Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 15 Oct 2012 12:10:57 -0000 Hi Brett, Thank you for the hint. So for me it looks that the review of the call flows bring more understandi= ng of the RFC4244bis. Now I have some problems with backwards compatibility with regard to RFC424= 4 itself. Because I'm missing at least a description how to behave as B2BUA when no H= -I is received even the supported header is set to history. It is described when we have a GAP or is this seen as a GAP even if we have= no first entry in the call. This is not really realistic in networks already having millions of Clients= supporting RFC4244. To switch this clients to the RFC4244bis. So each call= will have then the entry 0 and 0.1 after passing the first network entity = supporting "histinfo" regarding RFC4244bis. So perhaps we could do something about this case to make it, from my point = of view, a little bit better workable. I see this problem only for the first hop. Comments? Thank you Roland -----Urspr=FCngliche Nachricht----- Von: Brett Tate [mailto:brett@broadsoft.com] Gesendet: Freitag, 12. Oktober 2012 20:58 An: Jesske, Roland; sipcore@ietf.org Betreff: RE: WGLC 4244bis-callflows Use Case 3.3 (3.2) > Why does put the UA an History-Info into the INVITE? It is required. The following thread contains Dale's response to my recent= question. http://www.ietf.org/mail-archive/web/sipcore/current/msg05246.html The following are some draft-ietf-sipcore-rfc4244bis-10 snippets. Section 6.1: "When issuing a request, the UAC MUST follow the procedures in Section 9.2= . In the case of an initial request, except where the UAC is part of a B2= BUA, there is no cache of hi- entries with which to populate the History-I= nfo header field and the hi-index is set to 1 per Section 10.3." Section 9.2: "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," From R.Jesske@telekom.de Mon Oct 15 07:45:22 2012 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 4A81811E80EC for ; Mon, 15 Oct 2012 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, 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 KI6NhotyO1cm for ; Mon, 15 Oct 2012 07:45:21 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62311E80D2 for ; Mon, 15 Oct 2012 07:45:20 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 15 Oct 2012 16:45:18 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 15 Oct 2012 16:45:18 +0200 From: To: Date: Mon, 15 Oct 2012 16:45:17 +0200 Thread-Topic: WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 Thread-Index: Ac2q47GCHWMnI2fiRW2RNKFfdqBVSA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504810D@HE111648.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 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, 15 Oct 2012 14:45:22 -0000 Hi, here is my review of Section 3.7 In addition to Brett's comments I have the following: 1. Within F6/F7 the cause parameter (408) regarding RFC4458 is missing. The cause parameter is also included within cases where no Response appears= . It is the same as for the escaped Reason. e.G.: History-Info: ; cau= se=3D408\ index=3D1.3;mp=3D1.2 2. F4/F5/F6/F7 the text of Response code is missing e.G. ?Reason=3DSIP%3Bca= use%3D302; text=3D"Moved Temporarily" 3. F6/F7 The Question is if it is implementation depended if the target par= ameter is put into both entries identifying the Voice Mail. If it is so the= n some text to point to the fact that this is possible would be nice. 4.F6/F7 Last H-I there is the rc=3D1.3 missing History-Info: ;\ index=3D1.3.1; rc=3D1.3 5. Perhaps a hint that End devices don't have to put in an "mp", "rc", "np"= would help the reader to differentiate between the different use cases. (3= .6 versus 3.7) I hope I don't miss anything. Best Regards Roland From R.Jesske@telekom.de Mon Oct 15 07:50:52 2012 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 E9BB121F86AB for ; Mon, 15 Oct 2012 07:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ5MbaGmyLJB for ; Mon, 15 Oct 2012 07:50:48 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0421F86A5 for ; Mon, 15 Oct 2012 07:50:48 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 15 Oct 2012 16:50:46 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 15 Oct 2012 16:50:45 +0200 From: To: , , Date: Mon, 15 Oct 2012 16:50:44 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQgCTYEGw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 15 Oct 2012 14:50:52 -0000 Hi Brett, with regard to your comment: > 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs mp= =3D1 added to the > Contact. I understand RFC4244bis correct that the adding of mp=3D1 needs only to be = done when it is a redirect server which carol's end device is not. RFC4244bis ... 8. Redirect Server Handling of History-Info Header Fields A redirect server MUST follow the procedures in Section 9.1 when it receives a SIP Request. A redirect server MUST follow the procedures in Section 9.4 when it sends a SIP Response. When generating the Contact header field in a 3xx response, the redirect server MUST add the appropriate "mp", "np" or "rc" header field parameter to each Contact header field as described in Section 10.4, if applicable. ... Best Regards Roland From brett@broadsoft.com Mon Oct 15 07:59:50 2012 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 560A721F86F8 for ; Mon, 15 Oct 2012 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR5UeXXKYPhe for ; Mon, 15 Oct 2012 07:59:49 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id D77F121F86DE for ; Mon, 15 Oct 2012 07:59:49 -0700 (PDT) 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; Mon, 15 Oct 2012 07:59:53 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 15 Oct 2012 07:59:53 -0700 From: Brett Tate To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: AQHNqkm59WCkbLiHj0y9o4GVZAyBHZe6OrVQ Date: Mon, 15 Oct 2012 14:59:52 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016F80@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B96@MBX06.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B88016BD0@MBX06.citservers.local> <507B1DD7.4020608@alum.mit.edu> In-Reply-To: <507B1DD7.4020608@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.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 14:59:50 -0000 > You didn't comment much on the H-I parts. I am=20 > guessing that means that you were deferring to=20 > others on that. Did I guess right? Yes; my review was not good enough to avoid needing someone more familiar w= ith draft-ietf-sipcore-rfc4244bis-10 to also review draft-ietf-sipcore-rfc4= 244bis-callflows. From brett@broadsoft.com Mon Oct 15 08:30:30 2012 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 DE59021F86BB for ; Mon, 15 Oct 2012 08:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SobmJdpJTP22 for ; Mon, 15 Oct 2012 08:30:30 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6921F86BA for ; Mon, 15 Oct 2012 08:30:29 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 15 Oct 2012 08:30:33 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 15 Oct 2012 08:30:33 -0700 From: Brett Tate To: "R.Jesske@telekom.de" , "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQgCTYEGwAACeTEA= Date: Mon, 15 Oct 2012 15:30:33 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88016F9F@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 15 Oct 2012 15:30:31 -0000 Hi Roland, Based upon the following RFC 3261 definition of Redirect Server, Bob's clie= nt is a redirect server. Thus the parameter must be added. And if not add= ed by the Redirect Server, F4 is non compliant to the following draft-ietf-= sipcore-rfc4244bis section 10.4 MUST NOT. RFC 3261 section 6: "Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs." Draft-ietf-sipcore-rfc4244bis-10 section 10.4: "If the Contact header field does not contain an "rc" or "mp" header field parameter, then the SIP entity MUST NOT include an "rc" or "mp" header field parameter in the hi-target-param in the hi-entry when the request is retargeted to a contact URI received in a 3xx response." > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, October 15, 2012 10:51 AM > To: Brett Tate; sipcore@ietf.org; draft-ietf-sipcore-rfc4244bis- > callflows@tools.ietf.org > Subject: AW: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: > section 3.7 comments >=20 > Hi Brett, > with regard to your comment: >=20 > > 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs > mp=3D1 added to the > > Contact. >=20 >=20 > I understand RFC4244bis correct that the adding of mp=3D1 needs only to > be done when it is a redirect server which carol's end device is not. >=20 > RFC4244bis > ... > 8. Redirect Server Handling of History-Info Header Fields >=20 > A redirect server MUST follow the procedures in Section 9.1 when it > receives a SIP Request. A redirect server MUST follow the > procedures > in Section 9.4 when it sends a SIP Response. When generating the > Contact header field in a 3xx response, the redirect server MUST add > the appropriate "mp", "np" or "rc" header field parameter to each > Contact header field as described in Section 10.4, if applicable. > ... >=20 > Best Regards >=20 > Roland From R.Jesske@telekom.de Mon Oct 15 08:50:49 2012 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 5926421F86E4 for ; Mon, 15 Oct 2012 08:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neILEvEaL4Dl for ; Mon, 15 Oct 2012 08:50:48 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0221F85A4 for ; Mon, 15 Oct 2012 08:50:47 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 15 Oct 2012 17:50:46 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 15 Oct 2012 17:50:46 +0200 From: To: , , Date: Mon, 15 Oct 2012 17:50:45 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQgCTYEGwAACeTEAAAWrT4A== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048185@HE111648.emea1.cds.t-internal.com> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016F9F@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88016F9F@MBX06.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 15 Oct 2012 15:50:49 -0000 Hi Brett, Thank you for the clarification. So then the contact in 302 I think, has to contain the mp=3D1.1 . Due to th= e last entry of: History-Info: ;\ index=3D1.1;rc=3D1 correct? Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Brett Tate Gesendet: Montag, 15. Oktober 2012 17:31 An: Jesske, Roland; sipcore@ietf.org; draft-ietf-sipcore-rfc4244bis-callflo= ws@tools.ietf.org Betreff: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section = 3.7 comments Hi Roland, Based upon the following RFC 3261 definition of Redirect Server, Bob's clie= nt is a redirect server. Thus the parameter must be added. And if not add= ed by the Redirect Server, F4 is non compliant to the following draft-ietf-= sipcore-rfc4244bis section 10.4 MUST NOT. RFC 3261 section 6: "Redirect Server: A redirect server is a user agent server that generates = 3xx responses to requests it receives, directing the client to contact an = alternate set of URIs." Draft-ietf-sipcore-rfc4244bis-10 section 10.4: "If the Contact header field does not contain an "rc" or "mp" header field parameter, then the SIP ent= ity MUST NOT include an "rc" or "mp" header field parameter in the hi-targ= et-param in the hi-entry when the request is retargeted to a contact URI r= eceived in a 3xx response." > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, October 15, 2012 10:51 AM > To: Brett Tate; sipcore@ietf.org; draft-ietf-sipcore-rfc4244bis- > callflows@tools.ietf.org > Subject: AW: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: > section 3.7 comments > > Hi Brett, > with regard to your comment: > > > 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 needs > mp=3D1 added to the > > Contact. > > > I understand RFC4244bis correct that the adding of mp=3D1 needs only to > be done when it is a redirect server which carol's end device is not. > > RFC4244bis > ... > 8. Redirect Server Handling of History-Info Header Fields > > A redirect server MUST follow the procedures in Section 9.1 when it > receives a SIP Request. A redirect server MUST follow the > procedures > in Section 9.4 when it sends a SIP Response. When generating the > Contact header field in a 3xx response, the redirect server MUST add > the appropriate "mp", "np" or "rc" header field parameter to each > Contact header field as described in Section 10.4, if applicable. > ... > > Best Regards > > Roland _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Oct 15 10:13:18 2012 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 4795211E80FD for ; Mon, 15 Oct 2012 10:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Wb8ah+HKvSEn for ; Mon, 15 Oct 2012 10:13:17 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0D11E80F7 for ; Mon, 15 Oct 2012 10:13:17 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id BPUt1k0011c6gX854VDNi6; Mon, 15 Oct 2012 17:13:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id BV7d1k00H3ZTu2S3jV7dmm; Mon, 15 Oct 2012 17:07:37 +0000 Message-ID: <507C4300.3020300@alum.mit.edu> Date: Mon, 15 Oct 2012 13:08:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proxy-feature: Suggested changes/additions based on IESG review 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, 15 Oct 2012 17:13:18 -0000 (as co-chair) We are now post-WGLC and finishing up IESG comments on this draft. The following changes that were requested by the IESG can be considered more than editorial. So please review these in and comment if you are opposed to any of these changes. Please be quick, we want to finish this up. Thanks, Paul On 10/12/12 2:46 PM, Christer Holmberg wrote: > Hi, > > Based on comments during the IESG review, there are a couple of suggested changes/additions to draft-ietf-sipcore-proxy-feature that we want to bring to the attention of the WG. > > First, it has been suggested that all 2119 uppercase words in section 5.3 (Feature Capability Indicator Specification Requirements) and section 8 (Feature Capability Indicator Registration Template) are changed to lowercase. The reason is because the sections are about documentation, not interoperability. > > Second, it was suggested to clarify whether an entity can remove or re-order Feature-Caps header fields within a SIP message. We suggest the following paragraph to be added to section 4.2.1: > > "Based on features and policies, a SIP entity MAY remove a Feature- > Caps header field from a SIP message. Also, a SIP entity MAY remove > a feature capability indicator from a Feature-Caps header field > within a SIP message. A SIP entity SHOULD NOT re-order the Feature- > Caps header fields within a SIP message." > > Please indicate if you object to these suggested changes/additions. > > Thanks! > > Regards, > > Christer > > > > > > From pkyzivat@alum.mit.edu Mon Oct 15 10:38:56 2012 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 97C6D21F87B6 for ; Mon, 15 Oct 2012 10:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=0.077, 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 wx-YOqdC6GhF for ; Mon, 15 Oct 2012 10:38:56 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id CA89121F8766 for ; Mon, 15 Oct 2012 10:38:55 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id BTeN1k00D0ldTLk51Vf0GH; Mon, 15 Oct 2012 17:39:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id BVZj1k01K3ZTu2S3QVZjLz; Mon, 15 Oct 2012 17:33:44 +0000 Message-ID: <507C4901.8000402@alum.mit.edu> Date: Mon, 15 Oct 2012 13:33:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proxy-feature: Suggested changes/additions based on IESG review 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, 15 Oct 2012 17:38:56 -0000 (now responding as individual) On 10/12/12 2:46 PM, Christer Holmberg wrote: > Hi, > > Based on comments during the IESG review, there are a couple of suggested changes/additions to draft-ietf-sipcore-proxy-feature that we want to bring to the attention of the WG. > > First, it has been suggested that all 2119 uppercase words in section 5.3 (Feature Capability Indicator Specification Requirements) and section 8 (Feature Capability Indicator Registration Template) are changed to lowercase. The reason is because the sections are about documentation, not interoperability. I disagree with this change. *Some* of the usage is probably gratuitous and unnecessary, but there is some of it that is *intended* to be normative. Yes, these are requirements about the "documentation", but without this information interoperation in the use of particular feature capability indicators is impossible. Media feature tags make this information optional. That was one of the motivations for setting up a separate registry - so that we could make this information mandatory. My opinions per section: - 5.3.1: retain 2119 language - 5.3.2: " - 5.3.3: " - 5.3.4: " - 5.3.5: " - 5.3.6: " - 5.3.7: need not be normative - 5.3.8: need not be normative - 8: use of 2119 language is redundant Regarding section 8: It already says: "Instructions are preceded by '|'. All fields are mandatory." So using MUST within those is redundant and can be omitted. > Second, it was suggested to clarify whether an entity can remove or re-order Feature-Caps header fields within a SIP message. We suggest the following paragraph to be added to section 4.2.1: > > "Based on features and policies, a SIP entity MAY remove a Feature- > Caps header field from a SIP message. Also, a SIP entity MAY remove > a feature capability indicator from a Feature-Caps header field > within a SIP message. A SIP entity SHOULD NOT re-order the Feature- > Caps header fields within a SIP message." I'm ok with this. Thanks, Paul From brett@broadsoft.com Mon Oct 15 10:51:42 2012 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 D8A2C21F8823 for ; Mon, 15 Oct 2012 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 tX-zROUqtk9B for ; Mon, 15 Oct 2012 10:51:40 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id F238D21F8820 for ; Mon, 15 Oct 2012 10:51:37 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 15 Oct 2012 10:51:42 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 15 Oct 2012 10:51:42 -0700 From: Brett Tate To: "R.Jesske@telekom.de" , "sipcore@ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQgCTYEGwAACeTEAAAWrT4AAA/EKw Date: Mon, 15 Oct 2012 17:51:41 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88017013@MBX06.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016F9F@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048185@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048185@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 15 Oct 2012 17:51:42 -0000 > So then the contact in 302 I think, has to contain=20 > the mp=3D1.1 . Due to the last entry of: >=20 > History-Info: ;\ > index=3D1.1;rc=3D1 > correct? Someone more familiar with draft-ietf-sipcore-rfc4244bis should respond. I= find sections 5 and 10.4 a little ambiguous concerning the topic; the rc i= nvolvement adds to my confusion (e.g. can an mp=3Dnon-mp-index?). It looks= like section 10.4 applies: "The mapping was done by the receiving entity o= n its own authority, in which case the mp-value is the parent index of the = hi-entry's index". Based upon rfc4244bis-callflows sections 3.1 and 3.4, it should be mp=3D1 Based upon rfc4244bis-callflows sections 3.6 and 3.7 F4 History-Info, it sh= ould be mp=3D1 Based upon sipcore-rfc4244bis section 5 example, it should be mp=3D1.1 > > > 4) If I understand draft-ietf-sipcore-rfc4244bis=20 > > > correctly, F3 needs mp=3D1 added to the Contact. From christer.holmberg@ericsson.com Mon Oct 15 11:15:45 2012 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 8E40921F87F1 for ; Mon, 15 Oct 2012 11:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 euvwDS3Npjx0 for ; Mon, 15 Oct 2012 11:15:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA921F87DD for ; Mon, 15 Oct 2012 11:15:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-43-507c52cea9fd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.20.11467.EC25C705; Mon, 15 Oct 2012 20:15:42 +0200 (CEST) Received: from ESESSHC016.ericsson.se (153.88.183.66) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Oct 2012 20:15:42 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 20:15:42 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Thread-Topic: Proxy-feature: Suggested changes/additions based on IESG review Thread-Index: AQHNqvs+KRwwwLi/rEqx+F/L6/XRU5e6qprQ Date: Mon, 15 Oct 2012 18:15:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B015940@ESESSMB209.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8A@ESESSCMS0356.eemea.ericsson.se> <507C4901.8000402@alum.mit.edu> In-Reply-To: <507C4901.8000402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM+Jvre65oJoAg4a9hhZ7/i5it1ix4QCr xbU5jWwWX39sYnNg8fj7/gOTx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVseNPF2PBXMGK 2w1zmBoY9/N2MXJySAiYSMy59oARwhaTuHBvPVsXIxeHkMApRol32+ewQzg7GSWW7/8F5Sxh lHgw9wZLFyMHB5uAhUT3P22QbhEBLYkDVy6zgNjMAhUSvXf+gNnCAj4SvW/+MUHU+Ep8OXeC GcI2kuj+/RJsM4uAqsT2u29ZQWxeAW+J6yd7GEHGCwlUSnS0B4CEOQV0JG6+nwM2hhHo0O+n 1jBBrBKXuPVkPhPEAwISS/acZ4awRSVePv7HCjJGQkBRYnm/HES5jsSC3Z/YIGxtiWULXzND bBWUODnzCdjFQkDxlsUT2CcwSsxCsmEWkvZZSNpnIWlfwMiyilE4NzEzJ73cUC+1KDO5uDg/ T684dRMjMA4Pbvmtu4Px1DmRQ4zSHCxK4rxcSfv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTDqtDyeJxWx0SD6pWnlp+SQ45VvJaZrrVnM9pvtqPcuDmsP47/TvnQ9jmY8zfBzwtlO6bvv Q0K1mfrNHq4QZZqUMNmYbfFu4wWrubl+1z7Yy80Vt6DadvLXm/emL1Sb0vUr5qDE4x3bN/o1 64R1JV2RnrJgNcsE7i2Bhsz75Pg+7/wd5S0vXbhPiaU4I9FQi7moOBEAXXju3JECAAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proxy-feature: Suggested changes/additions based on IESG review 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, 15 Oct 2012 18:15:45 -0000 Hi,=20 >> Based on comments during the IESG review, there are a couple of suggeste= d changes/additions=20 >> to draft-ietf-sipcore-proxy-feature that we want to bring to the attenti= on of the WG. >> >> First, it has been suggested that all 2119 uppercase words in section 5.= 3 (Feature Capability=20 >> Indicator Specification Requirements) and section 8 (Feature Capability = Indicator Registration=20 >> Template) are changed to lowercase. The reason is because the sections a= re about documentation, not interoperability. > > I disagree with this change. > > *Some* of the usage is probably gratuitous and unnecessary, but there is = some of it that is *intended* to be normative.=20 > Yes, these are requirements about the "documentation", but without this i= nformation interoperation in the use of=20 > particular feature capability indicators is impossible. Media feature tag= s make this information optional. That was=20 > one of the motivations for setting up a separate registry - so that we co= uld make this information mandatory. > > My opinions per section: > > - 5.3.1: retain 2119 language > - 5.3.2: " > - 5.3.3: " > - 5.3.4: " > - 5.3.5: " > - 5.3.6: " > - 5.3.7: need not be normative > - 5.3.8: need not be normative > - 8: use of 2119 language is redundant > > Regarding section 8: > > It already says: "Instructions are preceded by '|'. All fields are manda= tory." So using MUST within those is redundant and can be omitted. I am ok with you suggestion. ------------------------------- >> Second, it was suggested to clarify whether an entity can remove or re-o= rder Feature-Caps header fields within a SIP message. We suggest the follow= ing paragraph to be added to section 4.2.1: >> >> "Based on features and policies, a SIP entity MAY remove a Featur= e- >> Caps header field from a SIP message. Also, a SIP entity MAY remo= ve >> a feature capability indicator from a Feature-Caps header field >> within a SIP message. A SIP entity SHOULD NOT re-order the Featur= e- >> Caps header fields within a SIP message." > > I'm ok with this. Good :) Regards, Christer From iesg-secretary@ietf.org Mon Oct 15 13:12:12 2012 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 756CF21F89ED; Mon, 15 Oct 2012 13:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 kLX7P8MDUMSl; Mon, 15 Oct 2012 13:12:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63E21F89F1; Mon, 15 Oct 2012 13:12:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015201209.17199.1991.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:12:09 -0700 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-proxy-feature-11.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, 15 Oct 2012 20:12:12 -0000 The IESG has approved the following document: - 'Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)' (draft-ietf-sipcore-proxy-feature-11.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature/ Technical Summary This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. Working Group Summary This document was driven by, and appears to be of interest primarily to the IMS community. However the resulting mechanism is of general applicability. Document Quality There are implementations of this document. 3GPP IMS has a dependency on this document. It will be incorporated by reference in an upcoming version of IMS, and will thus eventually be implemented widely. The document shepherd has been a reviewer and critic of this document, and promoted significant changes in the contemplated mechanism. Shida Shubert provided an in depth WGLC review. Personnel Paul Kyzivat is the document shepherd. Robert Sparks is the responsible area director. From pkyzivat@alum.mit.edu Mon Oct 15 16:00:48 2012 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 98CE411E812C for ; Mon, 15 Oct 2012 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076, 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 moGaioM3Gbfd for ; Mon, 15 Oct 2012 16:00:48 -0700 (PDT) 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 0BA6E11E812B for ; Mon, 15 Oct 2012 16:00:47 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta07.westchester.pa.mail.comcast.net with comcast id BYAa1k0030xGWP857b0se8; Mon, 15 Oct 2012 23:00:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Bauq1k00V3ZTu2S3Yauqmy; Mon, 15 Oct 2012 22:54:50 +0000 Message-ID: <507C9472.9060101@alum.mit.edu> Date: Mon, 15 Oct 2012 18:55:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> In-Reply-To: <5075989F.3090305@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 23:00:48 -0000 In addition to Laura, Roland has provided reviews of 3.3, 3.5, 3.7, and another partial review of 3.2. And Brett did a quite thorough review of the non-HI-specific aspects of all 11 flows. We still need people to review at least the HI-specific parts of 3.8-3.11. PLEASE! The reviews so far have identified things, so this is not just a formality. Its important! Thanks, Paul On 10/10/12 11:47 AM, Paul Kyzivat wrote: > Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. > We have also had a partial review of 3.2 by Dale. > > So we only need volunteers for the other 7.5. > > Thanks, > Paul > > On 10/8/12 2:40 PM, Paul Kyzivat wrote: > >> EVERYBODY INTERESTED IN 4244bis: >> >> This is an example of why we NEED to have careful reviews of the >> callflows. >> >> So far I have been deafened by the silence. >> There was quite a bit of enthusiasm for both the bis and the callflows >> as long as it only took an email containing "+1". >> Who, other than the authors, wants these enough to do some work??? >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> 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 Mon Oct 15 17:04:28 2012 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 4749F1F0C86 for ; Mon, 15 Oct 2012 17:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315, 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 MBYB83IAQUdh for ; Mon, 15 Oct 2012 17:04:27 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id A05481F0C84 for ; Mon, 15 Oct 2012 17:04:27 -0700 (PDT) Received: from [118.109.76.216] (port=60473 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TNue1-0005Dj-66; Mon, 15 Oct 2012 19:04:25 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545047EAD@HE111648.emea1.cds.t-internal.com> Date: Tue, 16 Oct 2012 09:04:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016C03@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545047EAD@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:60473 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 16 Oct 2012 00:04:28 -0000 Hi Roland; Gap as defined in the spec is when the last hi-entry (one=20 with the largest index) is different from R-URI.. May be=20 we need to be more explicit that the 0 never become the=20 first index.=20 Reference >> Chapter 10.3 6=20 =20 Thanks Shida On Oct 15, 2012, at 9:10 PM, = wrote: > Hi Brett, > Thank you for the hint. >=20 > So for me it looks that the review of the call flows bring more = understanding of the RFC4244bis. >=20 > Now I have some problems with backwards compatibility with regard to = RFC4244 itself. > Because I'm missing at least a description how to behave as B2BUA when = no H-I is received even the supported header is set to history. > It is described when we have a GAP or is this seen as a GAP even if we = have no first entry in the call. > This is not really realistic in networks already having millions of = Clients supporting RFC4244. To switch this clients to the RFC4244bis. So = each call will have then the entry 0 and 0.1 after passing the first = network entity supporting "histinfo" regarding RFC4244bis. >=20 > So perhaps we could do something about this case to make it, from my = point of view, a little bit better workable. >=20 > I see this problem only for the first hop. >=20 > Comments? >=20 >=20 > Thank you >=20 > Roland >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Brett Tate [mailto:brett@broadsoft.com] > Gesendet: Freitag, 12. Oktober 2012 20:58 > An: Jesske, Roland; sipcore@ietf.org > Betreff: RE: WGLC 4244bis-callflows Use Case 3.3 (3.2) >=20 >> Why does put the UA an History-Info into the INVITE? >=20 > It is required. The following thread contains Dale's response to my = recent question. >=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg05246.html >=20 >=20 > The following are some draft-ietf-sipcore-rfc4244bis-10 snippets. >=20 > Section 6.1: >=20 > "When issuing a request, the UAC MUST follow the procedures in = Section 9.2. In the case of an initial request, except where the UAC = is part of a B2BUA, there is no cache of hi- entries with which to = populate the History-Info header field and the hi-index is set to 1 per = Section 10.3." >=20 > Section 9.2: >=20 > "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," >=20 From shida@ntt-at.com Mon Oct 15 17:10:00 2012 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 700C31F0C86 for ; Mon, 15 Oct 2012 17:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=0.606, 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 sWBZdSifV2Fb for ; Mon, 15 Oct 2012 17:10:00 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id E6E9F1F0C61 for ; Mon, 15 Oct 2012 17:09:59 -0700 (PDT) Received: from [118.109.76.216] (port=60522 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TNujN-0000T8-Sk; Mon, 15 Oct 2012 19:09:58 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504810D@HE111648.emea1.cds.t-internal.com> Date: Tue, 16 Oct 2012 09:09:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2096F240-A05D-4306-AF99-CA75B68D4239@ntt-at.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504810D@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:60522 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 5 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 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, 16 Oct 2012 00:10:00 -0000 Hi Roland; Thanks again for your comments.. My comments inline.. On Oct 15, 2012, at 11:45 PM, = wrote: > Hi, > here is my review of Section 3.7 > In addition to Brett's comments I have the following: >=20 > 1. Within F6/F7 the cause parameter (408) regarding RFC4458 is = missing. > The cause parameter is also included within cases where no Response = appears. It is the same as for the escaped Reason. > e.G.: > History-Info: ; = cause=3D408\ Great.. > index=3D1.3;mp=3D1.2 > 2. F4/F5/F6/F7 the text of Response code is missing e.G. = ?Reason=3DSIP%3Bcause%3D302; text=3D"Moved Temporarily" Thanks.=20 >=20 > 3. F6/F7 The Question is if it is implementation depended if the = target parameter is put into both entries identifying the Voice Mail. If = it is so then some text to point to the fact that this is possible would = be nice. You mean to mention that adding target parameter is one way to = explicitly indicate=20 the target URI of the voicemail? (As an optional mechanism to accomplish=20= something defined here?)=20 >=20 > 4.F6/F7 Last H-I there is the rc=3D1.3 missing >=20 > History-Info: ;\ > index=3D1.3.1; rc=3D1.3 Thanks. >=20 > 5. Perhaps a hint that End devices don't have to put in an "mp", "rc", = "np" would help the reader to differentiate between the different use = cases. (3.6 versus 3.7) What do you mean?=20 Only device that are retargeting or forwarding the request=20 would set the "mp", "rc" and "np" So the UE would not=20 set these parameters.. Do we need to be more explicit=20 about that? >=20 > I hope I don't miss anything. >=20 > Best Regards >=20 > Roland From R.Jesske@telekom.de Tue Oct 16 05:30:23 2012 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 E0EB321F88B3 for ; Tue, 16 Oct 2012 05:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 H-RgMqN3xRKl for ; Tue, 16 Oct 2012 05:30:22 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC3021F8880 for ; Tue, 16 Oct 2012 05:30:22 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 14:30:13 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 14:30:12 +0200 From: To: Date: Tue, 16 Oct 2012 14:30:10 +0200 Thread-Topic: WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 Thread-Index: Ac2rKPEJwTGnVFT5T3mIAUz0Jg9ssAAR6OpA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> In-Reply-To: <507C9472.9060101@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 Subject: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 16 Oct 2012 12:30:24 -0000 Hi, here is an review of Section 3.11. 1. look at Berett's SIP corrections on Max-Forwards and the to URI. 2. In consideration of Brett's comments 3&4 regarding the use of supported = histinfo by the UAC I have the following view: For this use case the suppor= t of History-Info by the originating UAC is not needed. That is OK. I think= this should be mentioned within the describing text. 2. F3: From my understanding the last H-I is wrong. rc must be rc=3D1.1.1 a= nd the index must be index=3D1.1.1.1 This is how it is described within Ind= ex rule 1 "Forwarding a request without changing the target:" So the H-I should look like: History-Info: ;index=3D1, ;index=3D1.1;mp=3D1, ;index=3D1.1.1;rc=3D1.1 ;index=3D1.1.1.1;rc=3D1.1.1 Perhaps a hint within the text would also useful. 4. The following section is not clear (last sentence in 4th section): ... However, in our example here, since the translation was performed by a SIP proxy upstream from the gateway, the original 8xx number would have been lost, and the call will not interwork properly with the PSTN. ... How will a call with the PSTN interwork when sending it out from Atlanta.co= m with a alias? That is not clear. To interwork it with the PSTN a Request URI with a telep= hone number is needed. So in this case a forwarding to PSTN is not possible= . For having interworking the application forwarding this call has then to = take the PSTN number out of the H-I and has to guarantee that it will not b= e retargeted again. So I think it would be good to add here some notes to d= escribe this fact. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Paul Kyzivat Gesendet: Dienstag, 16. Oktober 2012 00:56 An: sipcore@ietf.org Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipco= re-rfc4244bis-callflows-01 In addition to Laura, Roland has provided reviews of 3.3, 3.5, 3.7, and ano= ther partial review of 3.2. And Brett did a quite thorough review of the non-HI-specific aspects of all= 11 flows. We still need people to review at least the HI-specific parts of 3.8-3.11. PLEASE! The reviews so far have identified things, so this is not just a formality.= Its important! Thanks, Paul On 10/10/12 11:47 AM, Paul Kyzivat wrote: > Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6. > We have also had a partial review of 3.2 by Dale. > > So we only need volunteers for the other 7.5. > > Thanks, > Paul > > On 10/8/12 2:40 PM, Paul Kyzivat wrote: > >> EVERYBODY INTERESTED IN 4244bis: >> >> This is an example of why we NEED to have careful reviews of the >> callflows. >> >> So far I have been deafened by the silence. >> There was quite a bit of enthusiasm for both the bis and the >> callflows as long as it only took an email containing "+1". >> Who, other than the authors, wants these enough to do some work??? >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> 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 R.Jesske@telekom.de Tue Oct 16 09:01:19 2012 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 5BAA021F8905 for ; Tue, 16 Oct 2012 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 igUA-4nQGOPd for ; Tue, 16 Oct 2012 09:01:17 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6E921F8973 for ; Tue, 16 Oct 2012 09:01:15 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 18:01:09 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 18:01:09 +0200 From: To: Date: Tue, 16 Oct 2012 18:01:07 +0200 Thread-Topic: WGLC 4244bis-callflows Use Case 3.3 (3.2) Thread-Index: Ac2rMdBbg2bntN8uT6yz3TIgD4xBXgAhWL2A Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DF5D@HE111648.emea1.cds.t-internal.com> References: <201210051925.q95JP0244047637@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544DB2BD3@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1544F05783@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016C03@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545047EAD@HE111648.emea1.cds.t-internal.com> In-Reply-To: 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] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 16 Oct 2012 16:01:19 -0000 Hi Shida > > Gap as defined in the spec is when the last hi-entry (one > with the largest index) is different from R-URI.. May be we > need to be more explicit that the 0 never become the first index. > That could be also interpreted for the first entry that is missing. So as you propose some more words help. Thank You Roland > Reference >> Chapter 10.3 6 > > Thanks > Shida > > On Oct 15, 2012, at 9:10 PM, > wrote: > > > Hi Brett, > > Thank you for the hint. > > > > So for me it looks that the review of the call flows bring > more understanding of the RFC4244bis. > > > > Now I have some problems with backwards compatibility with > regard to RFC4244 itself. > > Because I'm missing at least a description how to behave as > B2BUA when no H-I is received even the supported header is > set to history. > > It is described when we have a GAP or is this seen as a GAP > even if we have no first entry in the call. > > This is not really realistic in networks already having > millions of Clients supporting RFC4244. To switch this > clients to the RFC4244bis. So each call will have then the > entry 0 and 0.1 after passing the first network entity > supporting "histinfo" regarding RFC4244bis. > > > > So perhaps we could do something about this case to make > it, from my point of view, a little bit better workable. > > > > I see this problem only for the first hop. > > > > Comments? > > > > > > Thank you > > > > Roland > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Brett Tate [mailto:brett@broadsoft.com] > > Gesendet: Freitag, 12. Oktober 2012 20:58 > > An: Jesske, Roland; sipcore@ietf.org > > Betreff: RE: WGLC 4244bis-callflows Use Case 3.3 (3.2) > > > >> Why does put the UA an History-Info into the INVITE? > > > > It is required. The following thread contains Dale's > response to my recent question. > > > > http://www.ietf.org/mail-archive/web/sipcore/current/msg05246.html > > > > > > The following are some draft-ietf-sipcore-rfc4244bis-10 snippets. > > > > Section 6.1: > > > > "When issuing a request, the UAC MUST follow the > procedures in Section 9.2. In the case of an initial > request, except where the UAC is part of a B2BUA, there is > no cache of hi- entries with which to populate the > History-Info header field and the hi-index is set to 1 per > Section 10.3." > > > > Section 9.2: > > > > "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," > > > > From R.Jesske@telekom.de Tue Oct 16 09:17:48 2012 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 4F9D521F8A3C for ; Tue, 16 Oct 2012 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 lwmcaJYIKYUC for ; Tue, 16 Oct 2012 09:17:47 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7880F21F8A23 for ; Tue, 16 Oct 2012 09:17:47 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 18:17:45 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 18:17:45 +0200 From: To: Date: Tue, 16 Oct 2012 18:17:45 +0200 Thread-Topic: WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 Thread-Index: Ac2rMpaIYRlCj9aaTL6gYsxmzwJjNAAhPzUA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DF71@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504810D@HE111648.emea1.cds.t-internal.com> <2096F240-A05D-4306-AF99-CA75B68D4239@ntt-at.com> In-Reply-To: <2096F240-A05D-4306-AF99-CA75B68D4239@ntt-at.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 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, 16 Oct 2012 16:17:48 -0000 Hi Shida, > > > > 3. F6/F7 The Question is if it is implementation depended > if the target parameter is put into both entries identifying > the Voice Mail. If it is so then some text to point to the > fact that this is possible would be nice. > > You mean to mention that adding target parameter is one way > to explicitly indicate the target URI of the voicemail? (As > an optional mechanism to accomplish something defined here?) My Question is more if this is RFC4458 compliant. I'm not really sure. It l= ook's OK but that is a Application issue of the retargeting in combination = with RFC4458. So question is if both entries (also belongs to the Request URI) are valid = with a target parameter or not. > > > > 5. Perhaps a hint that End devices don't have to put in an > "mp", "rc", > > "np" would help the reader to differentiate between the > different use > > cases. (3.6 versus 3.7) > > What do you mean? > > Only device that are retargeting or forwarding the request > would set the "mp", "rc" and "np" So the UE would not set > these parameters.. Do we need to be more explicit about that? > As Brett referred already to RFC3261, that the UE in the 302 case is a UE a= Redirect Server. So for 302 the "mp"/"rc" has to be set in other cases not= . I Think it would be help to be a little bit more explicit on this. Best Regards Roland From R.Jesske@telekom.de Tue Oct 16 09:34:20 2012 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 B218A21F8A23 for ; Tue, 16 Oct 2012 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Jy+gIEBnV3vG for ; Tue, 16 Oct 2012 09:34:20 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB521F8A13 for ; Tue, 16 Oct 2012 09:34:19 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 18:34:18 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 18:34:18 +0200 From: To: , , Date: Tue, 16 Oct 2012 18:34:18 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments Thread-Index: Ac2ollYDzsmluaajQh6TumzWBMajQgCTYEGwAACeTEAAAWrT4AAA/EKwADKhDDA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DF82@HE111648.emea1.cds.t-internal.com> References: <576A8B541C219D4E9CEB1DF8C19C7B88016B08@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048117@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88016F9F@MBX06.citservers.local> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545048185@HE111648.emea1.cds.t-internal.com> <576A8B541C219D4E9CEB1DF8C19C7B88017013@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88017013@MBX06.citservers.local> 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 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments 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, 16 Oct 2012 16:34:20 -0000 Hi, I was looking on all call flows regarding that issue. And I found something in RFC4244bis which states: ... Note that there are two scenarios by which the "mp" header field parameter can be derived. o The mapping was done by the receiving entity on its own authority, in which case the mp-value is the parent index of the hi-entry's index. o The mapping was done due to receiving a 3xx response, in which case the mp-value is an earlier sibling or descendant of an earlier sibling of the hi-entry's index, that of the downstream request which received the 3xx response. ... Nevertheless my question is how the UE indicate the correct sibling? So it looks that it must be mp=3D1 Best Regrads Roland > -----Urspr=FCngliche Nachricht----- > Von: Brett Tate [mailto:brett@broadsoft.com] > Gesendet: Montag, 15. Oktober 2012 19:52 > An: Jesske, Roland; sipcore@ietf.org; > draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org > Betreff: RE: [sipcore] > draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.7 comments > > > So then the contact in 302 I think, has to contain the > mp=3D1.1 . Due to > > the last entry of: > > > > History-Info: ;\ > > index=3D1.1;rc=3D1 > > correct? > > Someone more familiar with draft-ietf-sipcore-rfc4244bis > should respond. I find sections 5 and 10.4 a little > ambiguous concerning the topic; the rc involvement adds to my > confusion (e.g. can an mp=3Dnon-mp-index?). It looks like > section 10.4 applies: "The mapping was done by the receiving > entity on its own authority, in which case the mp-value is > the parent index of the hi-entry's index". > > Based upon rfc4244bis-callflows sections 3.1 and 3.4, it > should be mp=3D1 > > Based upon rfc4244bis-callflows sections 3.6 and 3.7 F4 > History-Info, it should be mp=3D1 > > Based upon sipcore-rfc4244bis section 5 example, it should be mp=3D1.1 > > > > > > > 4) If I understand draft-ietf-sipcore-rfc4244bis correctly, F3 > > > > needs mp=3D1 added to the Contact. > > From worley@shell01.TheWorld.com Tue Oct 16 11:40:05 2012 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 11C3B21F8A1D for ; Tue, 16 Oct 2012 11:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.062, 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 K9KnRL7k0axb for ; Tue, 16 Oct 2012 11:40:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id DA21E21F8A0B for ; Tue, 16 Oct 2012 11:40:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9GIcit5015998; Tue, 16 Oct 2012 14:38:46 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9GIchXA4655091; Tue, 16 Oct 2012 14:38:43 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9GIcg5e4645365; Tue, 16 Oct 2012 14:38:42 -0400 (EDT) Date: Tue, 16 Oct 2012 14:38:42 -0400 (EDT) Message-Id: <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 16 Oct 2012 18:40:05 -0000 > From: > > 2. In consideration of Brett's comments 3&4 regarding the use of > supported histinfo by the UAC I have the following view: For this > use case the support of History-Info by the originating UAC is not > needed. That is OK. I think this should be mentioned within the > describing text. It is not clear. RFC 4244 allows a proxy to add History-Info to a request even if the request does not contain "Supported: histinfo". 4244bis does not state that a proxy is allowed to do that, although it doesn't clear specify that it may not do that. > 4. The following section is not clear (last sentence in 4th > 4. section): > > ... > However, in > our example here, since the translation was performed by a SIP > proxy > upstream from the gateway, the original 8xx number would have > been > lost, and the call will not interwork properly with the PSTN. > ... > > How will a call with the PSTN interwork when sending it out from > Atlanta.com with a alias? > That is not clear. To interwork it with the PSTN a Request URI with > a telephone number is needed. So in this case a forwarding to PSTN > is not possible. For having interworking the application forwarding > this call has then to take the PSTN number out of the H-I and has to > guarantee that it will not be retargeted again. So I think it would > be good to add here some notes to describe this fact. To me, the text in section 3.11 appears to be discussing different situations than what is shown in the message flow. The text discusses various aspects of freephone processing when it is not done in an end-to-end SIP network. The message flow is a "pure SIP" implementation of free-phone number conversion: The first step is translating the free-phone number into the ordinary directory number, the second step is translating the ordinary directory number into a SIP AOR, and the third step is translating the SIP AOR into the registered UAS URI. As a matter of terminology, I believe that "freephone" is more used internationally than "toll free", "800", or "8xx", but I might be wrong. Dale From worley@shell01.TheWorld.com Tue Oct 16 11:56:03 2012 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 3298221F87EC for ; Tue, 16 Oct 2012 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_MILLIONSOF=0.315] 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 sqMlSMJTFwCH for ; Tue, 16 Oct 2012 11:56:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE7921F87E9 for ; Tue, 16 Oct 2012 11:56:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9GItvh0032107; Tue, 16 Oct 2012 14:55:59 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9GItvxb4709091; Tue, 16 Oct 2012 14:55:57 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9GItuhq4713135; Tue, 16 Oct 2012 14:55:56 -0400 (EDT) Date: Tue, 16 Oct 2012 14:55:56 -0400 (EDT) Message-Id: <201210161855.q9GItuhq4713135@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545047EAD@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 16 Oct 2012 18:56:03 -0000 > From: > > Now I have some problems with backwards compatibility with regard to > RFC4244 itself. Because I'm missing at least a description how to > behave as B2BUA when no H-I is received even the supported header is > set to history. It is described when we have a GAP or is this seen > as a GAP even if we have no first entry in the call. > > This is not really realistic in networks already having millions of > Clients supporting RFC4244. To switch this clients to the > RFC4244bis. So each call will have then the entry 0 and 0.1 after > passing the first network entity supporting "histinfo" regarding > RFC4244bis. > > I see this problem only for the first hop. My memory is that with RFC 4244, it is expected that the first proxy will add a "1" entry containing the request-URI that it received. (Since this is the first proxy, that request-URI will be the request-URI when the request was originally generated by the UAC.) Under 4244bis, I think that this would be considered a "gap" situation, although the text is ambiguous: the text in section 9.1 says: If the Request-URI of the incoming request does not match the hi- targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity before proceeding to Section 9.2, as follows: But it does not make clear what is to be done if there is no "last hi-entry". In practice, I think the following is the desired behavior (which is also compatible with RFC 4244): When receiving a request: If there is no hi-entry and the request contains exactly one Via, then the entity must add an hi-entry with index "1". [This is the behavior in RFC 4244.] If there is no hi-entry and the request contains more than one Via, then the entity must add an hi-entry with index "0". [This is the "gap" behavior.] This is practical because the first proxy can determine that it *is* the first proxy, and hence it can safely determine the original request-URI. Dale From pkyzivat@alum.mit.edu Tue Oct 16 15:39:44 2012 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 7332D1F0CA4 for ; Tue, 16 Oct 2012 15:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, 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 jih0741u6qEI for ; Tue, 16 Oct 2012 15:39:44 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id DE8531F0CA5 for ; Tue, 16 Oct 2012 15:39:43 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id Bnlv1k0020vyq2s5DyfnYC; Tue, 16 Oct 2012 22:39:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Byb71k00l3ZTu2S3Ryb7uW; Tue, 16 Oct 2012 22:35:08 +0000 Message-ID: <507DE100.7030901@alum.mit.edu> Date: Tue, 16 Oct 2012 18:34:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210161855.q9GItuhq4713135@shell01.TheWorld.com> In-Reply-To: <201210161855.q9GItuhq4713135@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 16 Oct 2012 22:39:44 -0000 On 10/16/12 2:55 PM, Dale R. Worley wrote: > This is practical because the first proxy can determine that it *is* > the first proxy, and hence it can safely determine the original > request-URI. This is true as long as there are only proxies, not B2BUAs on the path. There could have been a whole chain non-HI-aware things culminating in a last B2BUA that "anonymizes" by removing all the Vias and replacing them with one for itself. For instance, this could happen at the boundary between two service providers. Thanks, Paul From shida@ntt-at.com Tue Oct 16 17:22:58 2012 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 D73D021F85AF for ; Tue, 16 Oct 2012 17:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.557 X-Spam-Level: X-Spam-Status: No, score=-101.557 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315, 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 r0L+MuSdtqYW for ; Tue, 16 Oct 2012 17:22:58 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6121F85AE for ; Tue, 16 Oct 2012 17:22:58 -0700 (PDT) Received: from [118.109.76.216] (port=51272 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TOHPT-0007Ux-Ku; Tue, 16 Oct 2012 19:22:55 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210161855.q9GItuhq4713135@shell01.TheWorld.com> Date: Wed, 17 Oct 2012 09:22:54 +0900 Content-Transfer-Encoding: 7bit Message-Id: <38A52345-3F37-4E3C-AC1E-DA4C2C0F6520@ntt-at.com> References: <201210161855.q9GItuhq4713135@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:51272 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] WGLC 4244bis-callflows Use Case 3.3 (3.2) 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, 17 Oct 2012 00:22:59 -0000 Hi Dale, Roland; My comments inline.. On Oct 17, 2012, at 3:55 AM, Dale R. Worley wrote: >> From: >> >> Now I have some problems with backwards compatibility with regard to >> RFC4244 itself. Because I'm missing at least a description how to >> behave as B2BUA when no H-I is received even the supported header is >> set to history. It is described when we have a GAP or is this seen >> as a GAP even if we have no first entry in the call. >> >> This is not really realistic in networks already having millions of >> Clients supporting RFC4244. To switch this clients to the >> RFC4244bis. So each call will have then the entry 0 and 0.1 after >> passing the first network entity supporting "histinfo" regarding >> RFC4244bis. >> >> I see this problem only for the first hop. > > My memory is that with RFC 4244, it is expected that the first proxy > will add a "1" entry containing the request-URI that it received. > (Since this is the first proxy, that request-URI will be the > request-URI when the request was originally generated by the UAC.) > > Under 4244bis, I think that this would be considered a "gap" > situation, although the text is ambiguous: the text in section 9.1 > says: > > If the Request-URI of the incoming request does not match the hi- > targeted-to-uri in the last hi-entry (i.e., the previous SIP entity > that sent the request did not include a History-Info header field), > the SIP entity MUST add a hi-entry to end of the cache, on behalf > of > the previous SIP entity before proceeding to Section 9.2, as > follows: > > But it does not make clear what is to be done if there is no "last > hi-entry". Right.. > > In practice, I think the following is the desired behavior (which is > also compatible with RFC 4244): > > When receiving a request: > > If there is no hi-entry and the request contains exactly one Via, > then the entity must add an hi-entry with index "1". > [This is the behavior in RFC 4244.] > > If there is no hi-entry and the request contains more than one Via, > then the entity must add an hi-entry with index "0". > [This is the "gap" behavior.] Okay, but do we need to differentiate them? Can we just start with 1 when there are no prior hi-entry?? Is it considered a gap when there were no hi-entry to start with?? Thanks Shida > > This is practical because the first proxy can determine that it *is* > the first proxy, and hence it can safely determine the original > request-URI. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Oct 16 17:46:05 2012 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 E45071F042B for ; Tue, 16 Oct 2012 17:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TbTau9WECn+v for ; Tue, 16 Oct 2012 17:46:05 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0E98421F871E for ; Tue, 16 Oct 2012 17:46:04 -0700 (PDT) Received: from [118.109.76.216] (port=51598 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TOHlq-0003Yd-6V; Tue, 16 Oct 2012 19:46:02 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B2922A2F-18B4-4CC1-9DB4-B0111A549027" From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DF71@HE111648.emea1.cds.t-internal.com> Date: Wed, 17 Oct 2012 09:46:01 +0900 Message-Id: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154504810D@HE111648.emea1.cds.t-internal.com> <2096F240-A05D-4306-AF99-CA75B68D4239@ntt-at.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DF71@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:51598 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7 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, 17 Oct 2012 00:46:06 -0000 --Apple-Mail=_B2922A2F-18B4-4CC1-9DB4-B0111A549027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Roland; Many Thanks for your comments, more comments inline. On Oct 17, 2012, at 1:17 AM, = wrote: > Hi Shida, >=20 >>>=20 >>> 3. F6/F7 The Question is if it is implementation depended >> if the target parameter is put into both entries identifying >> the Voice Mail. If it is so then some text to point to the >> fact that this is possible would be nice. >>=20 >> You mean to mention that adding target parameter is one way >> to explicitly indicate the target URI of the voicemail? (As >> an optional mechanism to accomplish something defined here?) >=20 > My Question is more if this is RFC4458 compliant. I'm not really sure. = It look's OK but that is a Application issue of the retargeting in = combination with RFC4458. > So question is if both entries (also belongs to the Request URI) are = valid with a target parameter or not. >=20 >=20 Snip from RFC4458 about using it with H-I.. History-Info can complement this specification. In particular, when a proxy inserts a URI containing the parameters defined in this specification into the Request-URI of a forwarded request, the proxy can also insert a History-Info header field entry into the forwarded request, and the URI in that entry will incorporate these parameters. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which may be of use to the UAS. Consequently, UASes that make use of this information may find the information in the History-Info header and/or in the Request-URI, depending on the capability of the proxy to support generation of History-Info or on the behavior of downstream proxies; therefore, applications need to take this into account. >=20 >=20 >>>=20 >>> 5. Perhaps a hint that End devices don't have to put in an >> "mp", "rc", >>> "np" would help the reader to differentiate between the >> different use >>> cases. (3.6 versus 3.7) >>=20 >> What do you mean? >>=20 >> Only device that are retargeting or forwarding the request >> would set the "mp", "rc" and "np" So the UE would not set >> these parameters.. Do we need to be more explicit about that? >>=20 >=20 > As Brett referred already to RFC3261, that the UE in the 302 case is a = UE a Redirect Server. So for 302 the "mp"/"rc" has to be set in other = cases not. I Think it would be help to be a little bit more explicit on = this. Okay, I see.. I think I know what you are getting at.=20 UE when receiving 302 doesn't set mp or rc at its own decision but the=20= Redirect Server when sending a response would set contact with "mp"=20 or "rc". UE would then generate a hi-entry using the contact (with mp or = rc)=20 as it is the R-URI of the outgoing request. =20 The procedure covers this case as it is defined, as far as I know.. But=20= do you feel that we need more explanation?=20 Regards Shida >=20 > Best Regards >=20 > Roland >=20 --Apple-Mail=_B2922A2F-18B4-4CC1-9DB4-B0111A549027 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii R.Jesske@telekom.de> <R.Jesske@telekom.de> = wrote:
Hi Shida,


3. F6/F7 The Question is if it = is implementation depended
if the target parameter is put into both entries = identifying
the Voice Mail. If = it is so then some text to point to the
fact that this is possible would be = nice.

You mean to = mention that adding target parameter is one = way
to explicitly indicate the = target URI of the voicemail? (As
an optional mechanism to accomplish something defined = here?)

My Question is more if this is RFC4458 = compliant. I'm not really sure. It look's OK but that is a Application = issue of the retargeting in combination with RFC4458.
So question is = if both entries (also belongs to the Request URI) are valid with a = target parameter or = not.



 Snip = from RFC4458 about using it with H-I..

History-Info can complement this specification.  In =
particular, when
   a proxy inserts a URI containing the parameters defined in this
   specification into the Request-URI of a forwarded request, the proxy
   can also insert a History-Info header field entry into the forwarded
   request, and the URI in that entry will incorporate these parameters.
   Therefore, even if the Request-URI is replaced as a result of
   rerouting by a downstream proxy, the History-Info header field will
   still contain these parameters, which may be of use to the UAS.
   Consequently, UASes that make use of this information may find the
   information in the History-Info header and/or in the Request-URI,
   depending on the capability of the proxy to support generation of
   History-Info or on the behavior of downstream proxies; therefore,
   applications need to take this into =
account.




5. Perhaps a hint that End = devices don't have to put in an
"mp", "rc",
"np" would help the reader to = differentiate between the
different use
cases. (3.6 versus = 3.7)

What do you = mean?

Only device = that are retargeting or forwarding the = request
would set the "mp", = "rc" and "np" So the UE would not set
these parameters.. Do we need to be more explicit about = that?


As = Brett referred already to RFC3261, that the UE in the 302 case is a UE a = Redirect Server. So for 302 the "mp"/"rc" has to be set in other cases = not. I Think it would be help to be a little bit more explicit on = this.

 Okay, I see.. I = think I know what you are getting = at. 

 UE when receiving 302 doesn't = set mp or rc at its own decision but the 
Redirect = Server when sending a response would set contact with = "mp" 
or "rc". UE would then generate a hi-entry = using the contact (with mp or rc) 
as it is = the R-URI of the outgoing request. =   

 The procedure covers this = case as it is defined, as far as I know.. But 
do you = feel that we need more = explanation? 

 Regards
 = Shida


Best = Regards

Roland


= --Apple-Mail=_B2922A2F-18B4-4CC1-9DB4-B0111A549027-- From R.Jesske@telekom.de Wed Oct 17 02:36:02 2012 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 D0CD321F883B for ; Wed, 17 Oct 2012 02:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.032, 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 DVCD0+YlsL7n for ; Wed, 17 Oct 2012 02:36:00 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C621F86A4 for ; Wed, 17 Oct 2012 02:35:59 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 17 Oct 2012 11:35:50 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 17 Oct 2012 11:35:50 +0200 From: To: Date: Wed, 17 Oct 2012 11:35:48 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 Thread-Index: Ac2rzahILlVJ9QvbSoSDeWWyD9rBBAAfK59A Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> In-Reply-To: <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 17 Oct 2012 09:36:02 -0000 Hi Dale, see below Roland > > > > 2. In consideration of Brett's comments 3&4 regarding the use of > > supported histinfo by the UAC I have the following view: > For this use > > case the support of History-Info by the originating UAC is > not needed. > > That is OK. I think this should be mentioned within the describing > > text. > > It is not clear. RFC 4244 allows a proxy to add History-Info > to a request even if the request does not contain "Supported: > histinfo". > 4244bis does not state that a proxy is allowed to do that, > although it doesn't clear specify that it may not do that. > So with regard to that we have then a GAP. Because there are Services based= upon that. 3GPP has defined the Communication Forwarding using that approach. So due to backwards compatibility we need then there a description. From laura.liess.dt@googlemail.com Wed Oct 17 04:26:06 2012 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 0C08B21F87D3 for ; Wed, 17 Oct 2012 04:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, 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 eP7ecLp5Wmta for ; Wed, 17 Oct 2012 04:26:05 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7DD21F87DB for ; Wed, 17 Oct 2012 04:26:05 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13262120iec.31 for ; Wed, 17 Oct 2012 04:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j5tlPQQs1lObrWA3ECQXGtQASjW7ex7kgunp7HzB3kY=; b=ThIIGLBuZ0baBMUxhK4jiooLCP+uUtkdQ3NkriSVKwuX2j6gGm5jiDO5V0kWUQRGe7 BgybAWqXlf/ZB5XA7LJySh5heAfyxAN2YzMIlemfpTCi/ZGPhY3wcIHXjJG/8ed9h88x nNAbOsqZBptSJ+q/6pY9NCAE770pGtxx33+Pvj2sssjWqhC4PURqJohNErUYttgif9Gs H4u2BDr9TGhgD3D02Q3zGDqqh8XVWncRfspzH1wnsvANFi7GibUts1fquDko1oaKBlBd xRRqR7djf7s5abmjKhHsKou2fX8J6P32LBqOf9wnyw816E+Ke9DAPLMzmZnpGj0iOUAe pncw== MIME-Version: 1.0 Received: by 10.50.106.227 with SMTP id gx3mr1236545igb.10.1350473164905; Wed, 17 Oct 2012 04:26:04 -0700 (PDT) Received: by 10.231.58.80 with HTTP; Wed, 17 Oct 2012 04:26:04 -0700 (PDT) Date: Wed, 17 Oct 2012 13:26:04 +0200 Message-ID: From: Laura Liess To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01: section 3.1, 3.4, 3.6 comments 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, 17 Oct 2012 11:26:06 -0000 Hi, Please find additional comments on the sections 3.1, 3.4 and 3.6: 1) 3.1, second paragraph: "In other words, Office and *Bob* are not bound through SIP Registration with Bob's AOR." should be "In other words, Office and *Home* are not bound through SIP Registration with Bob's AOR." 2) 3.1 third paragraph: It seems to me that something is missing in the sentence " Thus, avoiding another INVITE to Bob's home phone." 3) 3.1, message F5: My understanding is that 192.0.2.4 is the registred IP-address of Bob, not of the example.com proxy. In this case, " F5 ACK 192.0.2.4 -> Bob" should be " F5 ACK example.com -> Bob". 4) 3.4, diagram. The diagram shows the Gold and Silver entities, in the detailed messages we find "F2 INVITE Example.com -> Gold.Example.com". 5) 3.4, messages F2 and F4: RFC4244bis , Section 9.2 says: "The hi-targeted-to-uri MUST be set to the value of the Request-URI of the current (outgoing) request." In F2 we have: Request URI = sip:john@192.0.2.1 and last hi-targeted-to-uri = . I think the Request-RI should be Gold@gold.example.com. In F4 we have: Request URI = sip:Silver@example.com and last hi-targeted-to-uri = . I think the Request-URI should be Silver@silver.example.com. 6) 3.4, message F9: Is the H-I in ACK OK? rfc4244bis , section 5: " The History-Info header field defined in this specification defines the usage in out-of-dialog requests or initial requests for a dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) and any non-100 provisional or final responses to these requests." I seems to me is that H-I is not to be used in ACK. ( Note:The ACK messages in 3.1 do not contain a H-I.I think this is OK.) 7) 3.6, message F1: I would expect to find a History-Info: ;index=1 in this message? 8) 3.6, message F3: mp=1 missing in the Contact: -header. 9) 3.6, messages F6 and F7: History-Info: ;\index=1.3;mp=1.2 I MO mp=1.2 is not correct. RFC4244bis says on page 8: "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." IMO, because it's Bob's VM, the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted is in this case with index=1 and not so I would expect here mp=1. If the call would have been retargeted to Carol's VM, we would have mp=1.2. But maybe I missed something here. (Note: I do not see any difference to the message F9 in 3.1, where we have mp=1.) 10) 3.6, message F7: Contact: seems wrong to me, it should be the VM. Thanks, Laura From shida@ntt-at.com Wed Oct 17 16:45:00 2012 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 4D32321F8621 for ; Wed, 17 Oct 2012 16:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.821 X-Spam-Level: X-Spam-Status: No, score=-101.821 tagged_above=-999 required=5 tests=[AWL=0.444, 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 EOkhb1TbheX1 for ; Wed, 17 Oct 2012 16:44:59 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id DE26F21F861F for ; Wed, 17 Oct 2012 16:44:59 -0700 (PDT) Received: from [118.109.76.216] (port=55505 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TOdIH-0001mW-CR; Wed, 17 Oct 2012 18:44:57 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com> Date: Thu, 18 Oct 2012 08:44:55 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:55505 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: worley@ariadne.com, sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 17 Oct 2012 23:45:00 -0000 There is no text that prevents proxy to add hi-entries.=20 But if there is a strong feeling towards adding an explicit=20 text something along the line of=20 "Intermediaries such as proxies MAY add hi-entries even=20 if there is no histinfo option tag in the Supported header" Regards Shida On Oct 17, 2012, at 6:35 PM, = wrote: > Hi Dale, > see below >=20 > Roland >>>=20 >>> 2. In consideration of Brett's comments 3&4 regarding the use of >>> supported histinfo by the UAC I have the following view: >> For this use >>> case the support of History-Info by the originating UAC is >> not needed. >>> That is OK. I think this should be mentioned within the describing >>> text. >>=20 >> It is not clear. RFC 4244 allows a proxy to add History-Info >> to a request even if the request does not contain "Supported: >> histinfo". >> 4244bis does not state that a proxy is allowed to do that, >> although it doesn't clear specify that it may not do that. >>=20 > So with regard to that we have then a GAP. Because there are Services = based upon that. > 3GPP has defined the Communication Forwarding using that approach. > So due to backwards compatibility we need then there a description. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From R.Jesske@telekom.de Thu Oct 18 00:09:18 2012 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 E613321F8462 for ; Thu, 18 Oct 2012 00:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.157, 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 Lz4rpgYijhKw for ; Thu, 18 Oct 2012 00:09:18 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id A403A21F845A for ; Thu, 18 Oct 2012 00:09:17 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 18 Oct 2012 09:08:53 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 18 Oct 2012 09:08:53 +0200 From: To: Date: Thu, 18 Oct 2012 09:08:52 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 Thread-Index: Ac2swW0+UNUHCjgYRn+3BTH2fboYKQAPYv3w Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545215FB3@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com> In-Reply-To: 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: worley@ariadne.com, sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 18 Oct 2012 07:09:19 -0000 Hi Shida, in the past I had many problems to express our requirements to vendors and = how they have to read standards. So if it is allowed then we need some words within the text. I think as cle= arer standard text is as less problems we will get with implementations. So I'm in favour to add some text. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Shida Schubert [mailto:shida@ntt-at.com] > Gesendet: Donnerstag, 18. Oktober 2012 01:45 > An: Jesske, Roland > Cc: worley@ariadne.com; sipcore@ietf.org > Betreff: Re: [sipcore] WGLC for > draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 > > > There is no text that prevents proxy to add hi-entries. > > But if there is a strong feeling towards adding an explicit > text something along the line of > > "Intermediaries such as proxies MAY add hi-entries even if > there is no histinfo option tag in the Supported header" > > Regards > Shida > > On Oct 17, 2012, at 6:35 PM, > wrote: > > > Hi Dale, > > see below > > > > Roland > >>> > >>> 2. In consideration of Brett's comments 3&4 regarding the use of > >>> supported histinfo by the UAC I have the following view: > >> For this use > >>> case the support of History-Info by the originating UAC is > >> not needed. > >>> That is OK. I think this should be mentioned within the > describing > >>> text. > >> > >> It is not clear. RFC 4244 allows a proxy to add History-Info to a > >> request even if the request does not contain "Supported: > >> histinfo". > >> 4244bis does not state that a proxy is allowed to do that, > although > >> it doesn't clear specify that it may not do that. > >> > > So with regard to that we have then a GAP. Because there > are Services based upon that. > > 3GPP has defined the Communication Forwarding using that approach. > > So due to backwards compatibility we need then there a description. > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > From marianne.mohali@orange.com Thu Oct 18 03:56:51 2012 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 4FAA321F8624 for ; Thu, 18 Oct 2012 03:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 vofgTWngLXcp for ; Thu, 18 Oct 2012 03:56:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6FF21F8623 for ; Thu, 18 Oct 2012 03:56:49 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9FEFB22C153 for ; Thu, 18 Oct 2012 12:56:48 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 85C7123805C for ; Thu, 18 Oct 2012 12:56:48 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:56:48 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows global comments Thread-Index: Ac2tH0TOT8Yg86UuQFu1sfU4tINgQg== Date: Thu, 18 Oct 2012 10:56:48 +0000 Message-ID: <15076_1350557808_507FE070_15076_1100_1_8B970F90C584EA4E97D5BAAC9172DBB8087497@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8087497PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [sipcore] WGLC 4244bis-callflows global comments 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, 18 Oct 2012 10:56:51 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8087497PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I reviewed both draft-4244bis and call flow and here and following email ar= e my feedback on the callflows draft. General comments: MM#28 About Dale's comments 2) and 3): I agree that a complex example using= the "0" value should be present in the call flow document. If you do a cal= l flow document, you should show complex cases. MM#29 Regarding Figures numbering and label, the document in not uniform. E= ach call flow should have its Figure number and label just above (not 3 pag= es later). Best Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB8087497PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I reviewed both draft-4244bis and call flow= and here and following email are my feedback on the callflows draft.<= /o:p>

 

General comments:

 

MM#28 About Dale’s comments 2) and 3)= : I agree that a complex example using the “0” value should be = present in the call flow document. If you do a call flow document, you should show complex cases.

 

MM#29 Regarding Figures numbering and label= , the document in not uniform. Each call flow should have its Figure number= and label just above (not 3 pages later).

 

 

Best Regards,

Marianne Mohali

 

 

______________________________________________________________________=
___________________________________________________

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8087497PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:00 2012 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 0EBC321F8622 for ; Thu, 18 Oct 2012 03:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GkRuP6pfXOfB for ; Thu, 18 Oct 2012 03:56:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 86CA621F861F for ; Thu, 18 Oct 2012 03:56:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C10232DC33D for ; Thu, 18 Oct 2012 12:56:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A5B21238056 for ; Thu, 18 Oct 2012 12:56:56 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:56:56 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.1 Thread-Index: Ac2tH0mEnntdFaKuQmaV7xXXALIzrw== Date: Thu, 18 Oct 2012 10:56:56 +0000 Message-ID: <15076_1350557816_507FE078_15076_1113_1_8B970F90C584EA4E97D5BAAC9172DBB80874A3@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874A3PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [sipcore] WGLC 4244bis-callflows 3.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: Thu, 18 Oct 2012 10:57:00 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874A3PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1 Ok with Laura comments. MM#2: second paragraph: "The hi-entry containing the initial contact is the= hi-entry just prior to the first hi-entry tagged with an "rc" header field= parameter." According to the logic of "rc" param it is strange to use the = terms "just prior". Proposed correction: "The hi-entry containing the initial contact is the hi= -entry just prior to *pointed by* the first hi-entry tagged with an "rc" he= ader field parameter." MM#3: F9: The timeout causing the retargeting is not a received SIP respons= e so, in my first understanding, the Reason header should not be used. It w= ould be better to use the RFC4458 reason for no reply in an URI parameter. = May be I missed a specific change from RFC4244 on this topic. draft4244bis states : "A reason is included in the hi-targeted-to-uri of an= hi-entry to reflect information received in a response to the request sent= to that URI." See my comment MM#20 on 3.6 History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;\ index=3D1.2.1>;index=3D1.2.1;rc=3D1.2 History-Info: ;index=3D1.3;mp=3D1 History-Info: ;index=3D1.3.1;rc=3D1.3 Instead, we can use de "cause" URI parameter (and may be also the "target")= in the hi-entry where the "mp" is added has follows: History-Info: ;\ index=3D1.2.1>;index=3D1.2.1;rc=3D1.2 History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;\ index=3D1.2.1>;index=3D1.2.1;rc=3D1.2 History-Info: ;index=3D1.3;mp=3D1 History-Info: ;index=3D1.3.1;rc=3D1.3 Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874A3PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.1

Ok with Laura comments.

MM#2: second paragraph: “The hi-entry= containing the initial contact is the hi-entry just prior to the first hi-= entry tagged with an "rc" header field parameter.” According to the logic of “rc” param it is strange to use the terms R= 20;just prior”.

Proposed correction: “The hi-entry co= ntaining the initial contact is the hi-entry just prior to *pointed by* the first hi-entry tagged with an "rc&= quot; header field parameter.”

 

MM#3: F9: The timeout causing the retargeting is =
not a received SIP response so, in my first understanding, the Reason heade=
r should not be used. It would be better to use the RFC4458 reason for no r=
eply in an URI parameter. May be I missed a specific change from RFC4244 on=
 this topic. 
draft4244bis states : “A reason is inclu=
ded in the hi-targeted-to-uri of an hi-entry to reflect information receive=
d in a response to the request sent to that URI.” See my comment =
MM#20 on 3.6
 
History-Info: <sip:bob@example.com>;index=
=3D1

   History-Info: <sip:bob@192.= 0.2.4?Reason=3DSIP%3Bcause%3D302>;\

       &= nbsp;         index=3D1.1;rc=3D1

   History-Info: <sip:office@e= xample.com>;index=3D1.2;mp=3D1

   History-Info: <sip:office@1= 92.0.2.5?Reason=3DSIP%3Bcause%3D408>;\<= o:p>

       &= nbsp;         index=3D1.2.1>;ind= ex=3D1.2.1;rc=3D1.2

   History-Info: <sip:home@exa= mple.com>;index=3D1.3;mp=3D1

   History-Info: <sip:home@192= .0.2.6>;index=3D1.3.1;rc=3D1.3

 

Instead, we can use de “cause” = URI parameter (and may be also the “target”) in the hi-entry wh= ere the “mp” is added has follows:

History-Info: <sip:office@192.0.2.5>;= \

       &= nbsp;         index=3D1.2.1>;ind= ex=3D1.2.1;rc=3D1.2

History-Info: <sip:bob@example.com>;index=
=3D1

   History-Info: <sip:bob@192.= 0.2.4?Reason=3DSIP%3Bcause%3D302>;\

       &= nbsp;         index=3D1.1;rc=3D1

   History-Info: <sip:office@e= xample.com>;index=3D1.2;mp=3D1

   History-Info: <sip:office@1= 92.0.2.5?Reason=3DSIP%3Bcause%3D408= >;\

       &= nbsp;         index=3D1.2.1>;ind= ex=3D1.2.1;rc=3D1.2

   History-Info: <sip:home@exa= mple.com; cause=3D408>;index=3D1.3;mp= =3D1

   History-Info: <sip:home@192= .0.2.6>;index=3D1.3.1;rc=3D1.3

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874A3PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:03 2012 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 3689621F8648 for ; Thu, 18 Oct 2012 03:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k-si242zSoEM for ; Thu, 18 Oct 2012 03:57:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A01DA21F8647 for ; Thu, 18 Oct 2012 03:57:01 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DAE8D3244AF for ; Thu, 18 Oct 2012 12:57:00 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B343235C045 for ; Thu, 18 Oct 2012 12:57:00 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:00 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.2 Thread-Index: Ac2tH0xDLjjKWt9fSImhgUZBDiTpHQ== Date: Thu, 18 Oct 2012 10:57:00 +0000 Message-ID: <2924_1350557820_507FE07C_2924_2438_3_8B970F90C584EA4E97D5BAAC9172DBB80874AC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874ACPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.2 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, 18 Oct 2012 10:57:03 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874ACPEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.2 MM#4 About Dale's comment #1) 3.2 F6: agree MM#5 About Brett's comments #2),#5) same comment as Dale #1) and comment#6)= : Agree Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874ACPEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.2

MM#4 About Dale’s comment #1) 3.2 F6:= agree

MM#5 About Brett’s comments #2),#5) s= ame comment as Dale #1) and comment#6): Agree

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874ACPEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:17 2012 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 6279521F8647 for ; Thu, 18 Oct 2012 03:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4nl0GQoZD1TM for ; Thu, 18 Oct 2012 03:57:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5DB21F861F for ; Thu, 18 Oct 2012 03:57:14 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 07011264347 for ; Thu, 18 Oct 2012 12:57:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DE0FC4C069 for ; Thu, 18 Oct 2012 12:57:13 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:13 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.4 Thread-Index: Ac2tH1OjfJIhH9cVRKaoojZH9SEBdQ== Date: Thu, 18 Oct 2012 10:57:12 +0000 Message-ID: <5435_1350557833_507FE089_5435_766_1_8B970F90C584EA4E97D5BAAC9172DBB80874C4@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874C4PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [sipcore] WGLC 4244bis-callflows 3.4 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, 18 Oct 2012 10:57:17 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874C4PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.4 MM#10 first paragraph: In the sentence: "Upon receipt of the call at the ag= ent assigned to handle the incoming call, based upon the History-Info heade= r in the message, the application at the agent can provide an indication th= at this is a Gold call by extracting the hi-entry associated with the incom= ing request which is determined by locating the hi-entry whose index is ref= lected in the first hi-entry with an hi-target of "mp". In the example thi= s would be the hi-entry referenced by the value of the last "mp" header fie= ld parameter -i.e., the hi-entry containing an index of "1". > In the last sentence, I think it should be a *first* instead of the *last* = "mp" i.e. In the example this would be the hi-entry referenced by the value= of the lastfirst "mp" header field parameter -i.e., the hi-entry containin= g an index of "1". Am I wrong? MM#11 second paragraph: In the sentence: "Thus, for this scenario, one would expect that the Proxy = would not support the sending of the History-Info in the response, even if = requested by Alice." I propose to add the following text: "Thus, for this scenario, one would ex= pect that the Proxy would not support the sending of the History-Info in th= e response, even if requested by Alice or the proxy could anonymize the Sil= ver related hi-entries by adding privacy in the Silver hi-entries." MM#12 in F5: in the second hi-entry, the "rc=3D1" is missing (presents in F= 4). Same for the following Fx. MM#13 in F5: 2 new hi-entries are added. Is it a shortcut or the second one= is not required. MM#14 last paragraph: "The last hi-entry with the "mp" header field paramet= er contains a "mp" header field parameter value of 1 which points to the or= iginal-target which allows the operator to identify that the call was from = the "Gold" customer." I would change the *last* in *first*: "The lastfirst hi-entry with the "mp"= header field parameter contains a "mp" header field parameter value of 1 w= hich points to the original-target which allows the operator to identify th= at the call was from the "Gold" customer." Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874C4PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.4

 

MM#10 first paragraph: In the sentence: = 220;Upon receipt of the call at the agent assigned to handle the incomin= g call, based upon the History-Info header in the message, the application at the agent can provide an indication that this is a Gold= call by extracting the hi-entry associated with the incoming request which= is determined by locating the hi-entry whose index is reflected in the fir= st hi-entry with an hi-target of "mp".  In the example this would be the hi-entry referenced= by the value of the last "mp" header field parameter -i.e., the = hi-entry containing an index of "1". » <= /o:p>

In the last sentence, I think it should be = a *first* instead of the *last* “mp” i.e. In the example this would be the hi-entry referenced by the value of the= lastfirs= t "mp" header field parameter -i.e., the hi-entry containi= ng an index of "1". Am I wrong?

 

MM#11 second paragraph:

In the sentence: “Thus, for this scenario, one would expect that the Proxy would no= t support the sending of the History-Info in the response, even if requeste= d by Alice.”

I propose to add the following text: = 220;Thus, for this scenario, one would expect that the Proxy would not supp= ort the sending of the History-Info in the response, even if requested by Alice or the proxy could ano= nymize the Silver related hi-entries by adding privacy in the Silver hi-ent= ries.”

 

MM#12 in F5: in the second hi-entry, the &#= 8220;rc=3D1” is missing (presents in F4). Same for the following Fx.

 

MM#13 in F5: 2 new hi-entries are added. Is= it a shortcut or the second one is not required.

 

MM#14 last paragraph: “The last hi= -entry with the "mp" header field parameter contains a "mp&q= uot; header field parameter value of 1 which points to the original-target which allows the operator to identify that the call was from the "Gol= d" customer.”

I would change the *last* in *first*= : “The lastfirst hi-entry with the "mp" header field p= arameter contains a "mp" header field parameter value of 1 which = points to the original-target which allows the operator to identify that the call was from the "Gold" customer.”

 

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874C4PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:17 2012 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 7732A21F861F for ; Thu, 18 Oct 2012 03:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aQshm4LGgu6V for ; Thu, 18 Oct 2012 03:57:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 93F6321F8619 for ; Thu, 18 Oct 2012 03:57:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F0ED03B4453 for ; Thu, 18 Oct 2012 12:57:07 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D642D35C048 for ; Thu, 18 Oct 2012 12:57:07 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:07 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.3 Thread-Index: Ac2tH1AhIexsazGwRduU1ebFPU6LZQ== Date: Thu, 18 Oct 2012 10:57:07 +0000 Message-ID: <2926_1350557827_507FE083_2926_6838_1_8B970F90C584EA4E97D5BAAC9172DBB80874B8@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874B8PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.3 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, 18 Oct 2012 10:57:17 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874B8PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.3 MM#6: About Roland's comments 1): If the UAC (must) add a H-I when initiati= ng a request, please note that H-I is missing in the initial request of exa= mples 3.6, 3.7 and 3.11... IMO, the sentence in section 6.2 in the draft-42= 44bis needs to be more explicit: "In the case of an initial request, except where the UAC is part of a B2BUA= , there is no cache of hi- entries with which to populate the History-Info = header field and the hi-index is set to 1 per Section 10.3. " I think this sentence need to be change as following: "In the case of an initial request, except where the UAC is part of a B2BUA= , there is no cache of hi- entries with which to populate the History-Info = header field, so the UAC populates the History-Info header field with the o= utgoing Request-URI and the hi-index is set to 1 per Section 10.3. " My last question is: Is it really mandatory that the UAC inserts the H-I? A= SHOULD/CAN/MUST would be welcomed. Section 9.1 mentions the case where no H-I is received by a proxy: "If the = Request-URI of the incoming request does not match the hi-targeted-to-uri i= n the last hi-entry (i.e., the previous SIP entity that sent the request di= d not include a History-Info header field), the SIP entity MUST add a hi-en= try to end of the cache, on behalf of the previous SIP entity before procee= ding to Section 9.2, as follows:" IMO a MUST would be too strong because the case where the proxy add the rec= eived URI before the outgoing URI is described and because I think it is un= realistic to ask UAC to add a H-I. MM#7: About Roland's comments 2): sections 3.3(F2) and 3.2(F2): I also thin= k that the parameter should not be "rc" but "np" because the address remain= s unchanged. Even if it is certain for 3.3, for 3.2 I have a doubt because = putting a "np" parameter (saying -it is the same-) to a visible identity po= inting at the anonymized identity is a non sense... but it is the truth and= this non sense exist because the anonymized address is not handled by the = domain requesting privacy. MM#8: About Roland's comments 3): I think UAS can receive H-I if no privacy= is asked for the hi-entries or the global request. A number presentation s= ervice could propose to display the last retargeting user so that the final= destination is able to know that the call was first intended to another ta= rget (and is not a direct call). MM#9 About Roland's comments 4): Indeed, a different Privacy use case from = 3.2 would be better because this one is too similar. Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874B8PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.3

MM#6: About Roland’s comments 1): If = the UAC (must) add a H-I when initiating a request, please note that H-I is= missing in the initial request of examples 3.6, 3.7 and 3.11… IMO, the sentence in section 6.2 in the draft-4244bis needs to= be more explicit: 

“In the cas=
e of an initial request, except where the UAC is part of a B2BUA, there is =
no cache of hi- entries with which to populate the History-Info header fiel=
d and the hi-index is set to 1 per Section 10.3. “ 
I think this sentenc=
e need to be change as following: 
“In the cas=
e of an initial request, except where the UAC is part of a B2BUA, there is =
no cache of hi- entries with which =
to populate the History-Info header field, so the=
 UAC populates the History-Info header field with the outgoing Request-URI =
and the hi-index is set to 1 per Section 10.3. “
My last question is:=
 Is it really mandatory that the UAC inserts the H-I? A SHOULD/CAN/MUST wou=
ld be welcomed.
Section 9.1 mentions=
 the case where no H-I is received by a proxy: “If the Request-URI=
 of the incoming request does not match the hi-targeted-to-uri in the last =
hi-entry (i.e., the previous SIP entity that sent the request did not inclu=
de a History-Info header field), the SIP entity MUST add a hi-entry to end =
of the cache, on behalf of the previous SIP entity before proceeding to Sec=
tion 9.2, as follows:”
IMO a MUST would be =
too strong because the case where the proxy add the received URI before the=
 outgoing URI is described and because I think it is unrealistic to ask UAC=
 to add a H-I.

 

MM#7: About Roland’s comments 2): sec= tions 3.3(F2) and 3.2(F2): I also think that the parameter should not be &#= 8220;rc” but “np” because the address remains unchanged. = Even if it is certain for 3.3, for 3.2 I have a doubt because putting a “= np” parameter (saying –it is the same-) to a visible identity p= ointing at the anonymized identity is a non sense… but it is the trut= h and this non sense exist because the anonymized address is not handled by the domain requesting privacy.

 

MM#8: About Roland’s comments 3): I t= hink UAS can receive H-I if no privacy is asked for the hi-entries or the g= lobal request. A number presentation service could propose to display the last retargeting user so that the final destination is able= to know that the call was first intended to another target (and is not a d= irect call).

 

MM#9 About Roland’s comments 4): Inde= ed, a different Privacy use case from 3.2 would be better because this one = is too similar.

 

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874B8PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:22 2012 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 767AF21F866C for ; Thu, 18 Oct 2012 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5j8Rxcc6wZ0U for ; Thu, 18 Oct 2012 03:57:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AC92121F865B for ; Thu, 18 Oct 2012 03:57:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1814122C26C for ; Thu, 18 Oct 2012 12:57:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F179A35C045 for ; Thu, 18 Oct 2012 12:57:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:19 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.5 Thread-Index: Ac2tH1ct0oTVj4v+RoqVVePhhOFLhQ== Date: Thu, 18 Oct 2012 10:57:18 +0000 Message-ID: <2926_1350557840_507FE090_2926_6854_1_8B970F90C584EA4E97D5BAAC9172DBB80874CC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874CCPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.5 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, 18 Oct 2012 10:57:22 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874CCPEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.5 MM#15 Third paragraph: "The alias for the call is determined by hi-entry wi= th the index that matches the value of the last hi-entry with a "rc" header= field parameter in the Request received." If there is an intermediary prox= y, it would also add a "rc" parameter. No? Is it a risk of confusion? Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874CCPEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.5

MM#15 Third paragraph: “The alias for th=
e call is determined by hi-entry with the index that matches the value of t=
he last hi-entry with a "rc" header field parameter in the Reques=
t received.” If there is an intermediary proxy, it would also add=
 a “rc” parameter. No? Is it a risk of confusion?

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874CCPEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:30 2012 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 ADA9721F866D for ; Thu, 18 Oct 2012 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UaUBiCG7fwxJ for ; Thu, 18 Oct 2012 03:57:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BABA921F8619 for ; Thu, 18 Oct 2012 03:57:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2E68818C497 for ; Thu, 18 Oct 2012 12:57:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0D08435C04E for ; Thu, 18 Oct 2012 12:57:24 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:23 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.6 Thread-Index: Ac2tH1oAdEfvDk1wRia4oCU9INGC3g== Date: Thu, 18 Oct 2012 10:57:23 +0000 Message-ID: <2924_1350557844_507FE094_2924_2445_1_8B970F90C584EA4E97D5BAAC9172DBB80874D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874D9PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.6 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, 18 Oct 2012 10:57:30 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874D9PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.6 MM#16 About Brett's comment#3) agree (see Roland's comment 1) MM#17 first paragraph: "The voicemail system typically requires the origina= l called party information to determine the appropriate mailbox so an appro= priate greeting can be provided and the appropriate party notified of the m= essage." I would add a note as following to avoid questions: In some cases, the fina= l voicemail is only responsible for the last retargeting user and so the ma= ilbox would be interested in the last retargeting user hi-entry (case prese= nted in section 3.7) MM#18 second paragraph: regarding "The original target is determined by fin= ding the first hi-entry tagged with "rc" and using the hi-entry referenced = by the index of "rc" header field parameter as the target for determining t= he appropriate mailbox." May be I'm wrong but in my understanding, it can also be the "mp" parameter= . So I propose to change the sentence as following: "The original target is= determined by finding the first hi-entry tagged with "rc" or "mp" and usin= g the hi-entry referenced by the index of "rc" or "mp" header field paramet= er as the target for determining the appropriate mailbox." MM#19 F6: in the first line INVITE sip:vm@192.0.2.6;target=3Dsip:bob%40example.com;cause=3D408 Bob answered a 302 which is a call deflection forwarding service, so per RF= C4458 the cause uri parameter should be populated with a 480 (and not a 408= used for "no reply"). Same comment for the hi-entries in F6. MM#20 F6: In the H-I header: 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: ;\ index=3D1.3;mp=3D1.2 History-Info: ;\ index=3D1.3.1;rc=3D1.3 In the line: History-Info: = ;index=3D1.2.1;rc=3D1.2 In RFC4244 it was stated that the Reason header is only inserted when the r= eal response is received. If it is the same with draft-4244bis, no Reason h= eader should be inserted associated with Carol hi-entry. I found the follow= ing text in 4244bis: "A reason is included in the hi-targeted-to-uri of an = hi-entry to reflect information received in a response to the request sent = to that URI." So I have a doubt and if effectively the Reason header can be= added even without error response received, it should be explicitly mentio= ned in 4244bis as it is a difference with RFC4244. Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874D9PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.6

MM#16 About Brett’s comment#3) agree = (see Roland’s comment 1)

 

MM#17 first paragraph: “The voicemail sy=
stem typically requires the original called party information to determine =
the appropriate mailbox so an appropriate greeting can be provided and the =
appropriate party notified of the message.”

I would add a note as following to avoid question=
s: In some cases, the final voicemail is only responsible for the la=
st retargeting user and so the mailbox would be interested in the last reta=
rgeting user hi-entry (case presented in section 3.7)

 


MM#18 second paragraph: regarding “The original target is determined by finding the first hi-entry tagged wit=
h "rc" and using the hi-entry referenced by the index
 of "rc" header field parameter as the target for determining the=
 appropriate mailbox.”



May be I’m wrong but in my understand=
ing, it can also be the “mp” parameter. So I propose to change =
the sentence as following: “The original target is determined by
 finding the first hi-entry tagged with "rc" or “mp” and using the hi-entry referenced by the i=
ndex of "rc"
or “mp” header field parameter=
 as the target for determining the appropriate mailbox.”



 


MM#19 F6: in the first line


INVITE sip:vm@192.0.2.6;target=3Dsip:bob%40=
example.com;cause=3D408


Bob answered a 302 which is a call deflecti=
on forwarding service, so per RFC4458 the cause uri parameter should be pop=
ulated with a
480 (and not a 408 used for “=
no reply”). Same comment for the hi-entries in F6.<=
/p>

 


 


MM#20 F6: In the H-I header:


   History-Info: <sip:bob@exam=
ple.com>;index=3D1


   History-Info: <sip:bob@192.=
0.2.5?Reason=3DSIP%3Bcause%3D302>;\


       &=
nbsp;           &nbs=
p;  index=3D1.1;rc=3D1


   History-Info: <sip:carol@ex=
ample.com>;index=3D1.2;mp=3D1


   History-Info: <sip:carol@19=
2.0.2.4?Reason=3DSIP%3Bcause%3D408>;\


       &=
nbsp;           &nbs=
p;  index=3D1.2.1;rc=3D1.2


   History-Info: <sip:vm@examp=
le.com;\


       &=
nbsp;           &nbs=
p;  target=3Dsip:bob%40example.com;cause=3D408>;\=



       &=
nbsp;           &nbs=
p;  index=3D1.3;mp=3D1.2


   History-Info: <sip:vm@192.0=
.2.6;\


       &=
nbsp;           &nbs=
p;  target=3Dsip:bob%40example.com;cause=3D408>;\=



       &=
nbsp;           &nbs=
p;  index=3D1.3.1;rc=3D1.3


In the line: History-Info: <sip:carol@19=
2.0.2.4?Reason=3DSIP%3Bcause%3D408>;index=3D1.2.1;rc=3D1.2


In RFC4244 it was stated that the Reason header i=
s only inserted when the real response is received. If it is the same with =
draft-4244bis, no Reason header should be inserted associated with Carol hi=
-entry. I found the following text in 4244bis: “A reason is included =
in the hi-targeted-to-uri of an hi-entry to reflect information received in=
 a response to the request sent to that URI.” So I have a doubt and i=
f effectively the Reason header can be added even without error response re=
ceived, it should be explicitly mentioned in 4244bis as it is a difference =
with RFC4244.


 


 


Best Regards,=



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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874D9PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:31 2012 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 D509121F8619 for ; Thu, 18 Oct 2012 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6Mrv5DHpcm+n for ; Thu, 18 Oct 2012 03:57:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C2DB821F864A for ; Thu, 18 Oct 2012 03:57:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3684722C265 for ; Thu, 18 Oct 2012 12:57:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1805135C061 for ; Thu, 18 Oct 2012 12:57:28 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:27 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.7 Thread-Index: Ac2tH1ybiGyx7yQZTTO16zdFlqTNVQ== Date: Thu, 18 Oct 2012 10:57:28 +0000 Message-ID: <2921_1350557848_507FE098_2921_998_1_8B970F90C584EA4E97D5BAAC9172DBB80874E1@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874E1PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Subject: [sipcore] WGLC 4244bis-callflows 3.7 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, 18 Oct 2012 10:57:31 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874E1PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.7 MM#21 About Brett's comment#3) agree (see Roland's comment 1) MM#22 second paragraph: "In order to determine the appropriate mailbox to = use for this call, the VMS needs the appropriate target for the request. T= he last target is determined by finding the hi-entry referenced by the inde= x of last hi-entry tagged with "rc" for determining the appropriate mailbox= ." In my understanding, the last target is referenced by the index of last hi-= entry tagged with "mp"... MM#23 F6, F7: same comment as 3.6 MM# regarding the use of the Reason heade= r. MM#24 F6, F7: same comment as Roland related to the missing cause=3D408 in = VM hi-entries If this comment is agreed, I suggest to change the last paragraph with "The= VMS can look at the last hi-entry and find the target of the mailbox by lo= oking for the "target" URI parameter in the hi-entry and the reason by the = "cause" URI parameter in the same hi-entry." Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874E1PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.7

MM#21 About Brett’s comment#3) agree = (see Roland’s comment 1)

 

MM#22 second paragraph:  “In order =
to determine the appropriate mailbox to use for this call, the VMS needs th=
e appropriate target for the request.  The last target is determined b=
y finding the hi-entry referenced by the index of last hi-entry tagged with=
 "rc" for determining the appropriate mailbox.”

In my understanding, the last target is ref= erenced by the index of last hi-entry tagged with “mp”… =

MM#23 F6, F7: same comment as 3.6 MM# regar= ding the use of the Reason header.

MM#24 F6, F7: same comment as Roland relate= d to the missing cause=3D408 in VM hi-entries 

If this comment is agreed, I suggest to change th=
e last paragraph with “The VMS can look at the last hi-entry and f=
ind the target of the mailbox by looking for the "target" URI par=
ameter in the hi-entry and the reason by the =
“cause” URI parameter in the same hi-entry.”

 

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874E1PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 03:57:43 2012 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 F26FA21F864D for ; Thu, 18 Oct 2012 03:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jJr3LutFbV8w for ; Thu, 18 Oct 2012 03:57:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5221F864A for ; Thu, 18 Oct 2012 03:57:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 63A9F32426A for ; Thu, 18 Oct 2012 12:57:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 46F594C063 for ; Thu, 18 Oct 2012 12:57:41 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:40 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.10 Thread-Index: Ac2tH2QMqX5TkyrbTkqXtfQJb7aadQ== Date: Thu, 18 Oct 2012 10:57:40 +0000 Message-ID: <5435_1350557861_507FE0A5_5435_774_1_8B970F90C584EA4E97D5BAAC9172DBB80874FF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874FFPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [sipcore] WGLC 4244bis-callflows 3.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: Thu, 18 Oct 2012 10:57:43 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874FFPEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.10 MM#25: this section provides text that would be better to have in the main = 4244bis document, instead of the callflow document. Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874FFPEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.10

MM#25: this section provides text that woul= d be better to have in the main 4244bis document, instead of the callflow d= ocument.

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874FFPEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 04:06:03 2012 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 6CB2A21F8616 for ; Thu, 18 Oct 2012 04:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v1p-Of2JJjb0 for ; Thu, 18 Oct 2012 04:06:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70F21F85A1 for ; Thu, 18 Oct 2012 04:06:02 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4D0F32641F9 for ; Thu, 18 Oct 2012 12:57:33 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2709D27C053 for ; Thu, 18 Oct 2012 12:57:33 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:32 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.8 and 3.9 Thread-Index: Ac2tH18+exXgqg1uS7uvEmZY5ZSY+Q== Date: Thu, 18 Oct 2012 10:57:32 +0000 Message-ID: <21156_1350557853_507FE09D_21156_4473_11_8B970F90C584EA4E97D5BAAC9172DBB80874EE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB80874EEPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.8 and 3.9 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, 18 Oct 2012 11:06:03 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB80874EEPEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.8 No specific comment Section 3.9 No specific comment Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB80874EEPEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.8

No specific comment

 

Section 3.9

No specific comment

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB80874EEPEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 04:07:35 2012 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 6899F21F864D for ; Thu, 18 Oct 2012 04:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HNNJVB2dUEOf for ; Thu, 18 Oct 2012 04:07:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E788121F8629 for ; Thu, 18 Oct 2012 04:07:33 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 94C68324241 for ; Thu, 18 Oct 2012 12:57:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6A6384C063 for ; Thu, 18 Oct 2012 12:57:51 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:50 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 2 Thread-Index: Ac2tH2oQdeFPdUx/Tvq4V8unL9HCaA== Date: Thu, 18 Oct 2012 10:57:50 +0000 Message-ID: <5431_1350557871_507FE0AF_5431_247_1_8B970F90C584EA4E97D5BAAC9172DBB8087514@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8087514PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [sipcore] WGLC 4244bis-callflows 2 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, 18 Oct 2012 11:07:35 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8087514PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2: MM#1: there is two times the term "redirect" in the following sentence "The= terms "location service", "redirect", "redirect" and "AOR" are used consis= tent with the terminology in [RFC3261]. Proposed correction: "The terms "location service", "redirect" *"forward"*,= "redirect" and "AOR" are used consistent with the terminology in [RFC3261]= ." Best regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB8087514PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 2:

MM#1: there is two times the term “re= direct” in the following sentence “The terms "location ser= vice", "redirect", "redirect" and "AOR" = are used consistent with the terminology in [RFC3261].

Proposed correction: “The terms "= ;location service", "redirect" *”forward”*, "redirect" and "= AOR" are used consistent with the terminology in [RFC3261].”

 

Best regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8087514PEXCVZYM12corpora_-- From marianne.mohali@orange.com Thu Oct 18 04:07:36 2012 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 D624021F8653 for ; Thu, 18 Oct 2012 04:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AFdwSkpcEWTo for ; Thu, 18 Oct 2012 04:07:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1421F864A for ; Thu, 18 Oct 2012 04:07:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 74CB7324122 for ; Thu, 18 Oct 2012 12:57:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 578E427C053 for ; Thu, 18 Oct 2012 12:57:46 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 18 Oct 2012 12:57:45 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC 4244bis-callflows 3.11 Thread-Index: Ac2tH2cMbQ3LL1u9R7u/saxmKh1kgA== Date: Thu, 18 Oct 2012 10:57:45 +0000 Message-ID: <21159_1350557866_507FE0AA_21159_11925_1_8B970F90C584EA4E97D5BAAC9172DBB8087507@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8087507PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.18.91522 Subject: [sipcore] WGLC 4244bis-callflows 3.11 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, 18 Oct 2012 11:07:37 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8087507PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.11 MM#26 About Brett's comment#5) agree, RFC 3261 states: "Even if the "displa= y-name" is empty, the "name-addr" form MUST be used if the "addr-spec" cont= ains a comma, question mark, or semicolon." MM#27 I agree with Roland comment#3 on F3: last rc must be rc=3D1.1.1 and t= he index must be index=3D1.1.1.1 Best Regards, 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. --_000_8B970F90C584EA4E97D5BAAC9172DBB8087507PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.11

MM#26 About Brett’s comment#5) agree,= RFC 3261 states: “Even if the "display-name" is empty, the "name-add= r" form MUST be used if the "addr-spec" contains a comma, qu= estion mark, or semicolon.“

 

MM#27 I agree with Roland comment#3 on F3: last rc must be rc=3D1.1.1 and the index mu= st be index=3D1.1.1.1

 

Best Regards,=

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.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8087507PEXCVZYM12corpora_-- From shida@ntt-at.com Thu Oct 18 06:18:06 2012 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 CEC5121F877A for ; Thu, 18 Oct 2012 06:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=0.415, 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 9sJuJBDqBb4i for ; Thu, 18 Oct 2012 06:18:06 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 563C521F8776 for ; Thu, 18 Oct 2012 06:18:06 -0700 (PDT) Received: from [118.109.76.216] (port=52402 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TOpz8-0007sY-LG; Thu, 18 Oct 2012 08:18:02 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1545215FB3@HE111648.emea1.cds.t-internal.com> Date: Thu, 18 Oct 2012 22:17:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCF773A-D44B-4BA1-977A-27990D00C2B8@ntt-at.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1545215FB3@HE111648.emea1.cds.t-internal.com> 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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:52402 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: worley@ariadne.com, sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 18 Oct 2012 13:18:07 -0000 Hi Roland; I am actually looking at the spec again and=20 what the spec is saying is that the intermediary=20 that supports RFC4244bis MUST set hi-entries,=20 it has nothing to do with whether "histinfo" is set=20 on the Supported header..=20 The only place where the behavior is affected=20 by the presence of option tag in Supported header=20 is "sending h-i in response (9.4)"=20 So I think RFC4244bis is fine as is.. Thoughts?=20 Regards shida On Oct 18, 2012, at 4:08 PM, = wrote: > Hi Shida, > in the past I had many problems to express our requirements to vendors = and how they have to read standards. > So if it is allowed then we need some words within the text. I think = as clearer standard text is as less problems we will get with = implementations. >=20 > So I'm in favour to add some text. >=20 > Best Regards >=20 > Roland >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Shida Schubert [mailto:shida@ntt-at.com] >> Gesendet: Donnerstag, 18. Oktober 2012 01:45 >> An: Jesske, Roland >> Cc: worley@ariadne.com; sipcore@ietf.org >> Betreff: Re: [sipcore] WGLC for >> draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 >>=20 >>=20 >> There is no text that prevents proxy to add hi-entries. >>=20 >> But if there is a strong feeling towards adding an explicit >> text something along the line of >>=20 >> "Intermediaries such as proxies MAY add hi-entries even if >> there is no histinfo option tag in the Supported header" >>=20 >> Regards >> Shida >>=20 >> On Oct 17, 2012, at 6:35 PM, >> wrote: >>=20 >>> Hi Dale, >>> see below >>>=20 >>> Roland >>>>>=20 >>>>> 2. In consideration of Brett's comments 3&4 regarding the use of >>>>> supported histinfo by the UAC I have the following view: >>>> For this use >>>>> case the support of History-Info by the originating UAC is >>>> not needed. >>>>> That is OK. I think this should be mentioned within the >> describing >>>>> text. >>>>=20 >>>> It is not clear. RFC 4244 allows a proxy to add History-Info to a >>>> request even if the request does not contain "Supported: >>>> histinfo". >>>> 4244bis does not state that a proxy is allowed to do that, >> although >>>> it doesn't clear specify that it may not do that. >>>>=20 >>> So with regard to that we have then a GAP. Because there >> are Services based upon that. >>> 3GPP has defined the Communication Forwarding using that approach. >>> So due to backwards compatibility we need then there a description. >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 From shida@ntt-at.com Thu Oct 18 06:21:02 2012 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 F14F621F8701 for ; Thu, 18 Oct 2012 06:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 33c9Jya2rk+B for ; Thu, 18 Oct 2012 06:21:01 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0011A21F8700 for ; Thu, 18 Oct 2012 06:21:00 -0700 (PDT) Received: from [118.109.76.216] (port=52637 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TOq1z-0002Ei-PV; Thu, 18 Oct 2012 08:21:00 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6866A71-0463-4DCE-B04A-B70389B1AB26" From: Shida Schubert In-Reply-To: <15076_1350557808_507FE070_15076_1100_1_8B970F90C584EA4E97D5BAAC9172DBB8087497@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 18 Oct 2012 22:20:58 +0900 Message-Id: References: <15076_1350557808_507FE070_15076_1100_1_8B970F90C584EA4E97D5BAAC9172DBB8087497@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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:52637 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC 4244bis-callflows global comments 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, 18 Oct 2012 13:21:02 -0000 --Apple-Mail=_F6866A71-0463-4DCE-B04A-B70389B1AB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Marianne; Thanks for your review and comments. Should the figure number be above the callflow figure or=20 above the message examples?=20 Regards Shida On Oct 18, 2012, at 7:56 PM, = wrote: > Hello all, > =20 > I reviewed both draft-4244bis and call flow and here and following = email are my feedback on the callflows draft. > =20 > General comments: > =20 > MM#28 About Dale=92s comments 2) and 3): I agree that a complex = example using the =930=94 value should be present in the call flow = document. If you do a call flow document, you should show complex cases. > =20 > MM#29 Regarding Figures numbering and label, the document in not = uniform. Each call flow should have its Figure number and label just = above (not 3 pages later). > =20 > =20 > Best Regards, > Marianne Mohali > =20 > =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. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_F6866A71-0463-4DCE-B04A-B70389B1AB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Marianne;

 Thanks for your review and = comments.

 Should the figure number be = above the callflow figure or 
above the message = examples? 

 Regards
  = Shida


On Oct 18, 2012, at 7:56 PM, = <marianne.mohali@orange.com&= gt; <marianne.mohali@orange.com&= gt; wrote:

Hello = all,
I reviewed both = draft-4244bis and call flow and here and following email are my feedback = on the callflows draft.
General = comments:
MM#28 About = Dale=92s comments 2) and 3): I agree that a complex example using the = =930=94 value should be present in the call flow document. If you do a = call flow document, you should show complex = cases.
MM#29 Regarding = Figures numbering and label, the document in not uniform. Each call flow = should have its Figure number and label just above (not 3 pages = later).
Best = Regards,
Marianne = Mohali
 
sipcore@ietf.org

Subject: Re: [sipcore] WGLC 4244bis-callflows global comments
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, 18 Oct 2012 13:26:56 -0000

--_000_8B970F90C584EA4E97D5BAAC9172DBB8087661PEXCVZYM12corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Shida,

If I were you, I would put the Figure number/label just above the callflow =
figure (it is weird to see it 3 pages after the figure).

Marianne

De : Shida Schubert [mailto:shida@ntt-at.com]
Envoy=E9 : jeudi 18 octobre 2012 15:21
=C0 : MOHALI Marianne OLNC/OLN
Cc : sipcore@ietf.org
Objet : Re: [sipcore] WGLC 4244bis-callflows global comments


Hi Marianne;

 Thanks for your review and comments.

 Should the figure number be above the callflow figure or
above the message examples?

 Regards
  Shida


On Oct 18, 2012, at 7:56 PM, > > wrote:


Hello all,

I reviewed both draft-4244bis and call flow and here and following email ar=
e my feedback on the callflows draft.

General comments:

MM#28 About Dale's comments 2) and 3): I agree that a complex example using=
 the "0" value should be present in the call flow document. If you do a cal=
l flow document, you should show complex cases.

MM#29 Regarding Figures numbering and label, the document in not uniform. E=
ach call flow should have its Figure number and label just above (not 3 pag=
es later).


Best Regards,
Marianne Mohali



___________________________________________________________________________=
______________________________________________



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.
_______________________________________________
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.


--_000_8B970F90C584EA4E97D5BAAC9172DBB8087661PEXCVZYM12corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Shida,


 <=
/p>

If I were =
you, I would put the Figure number/label just above the callflow figure (it=
 is weird to see it 3 pages after the figure).


 =
;


Marianne


 =
;






De : Shid=
a Schubert [mailto:shida@ntt-at.com]


Envoy=E9 : jeudi 18 octobre 2012 15:21

=C0 : MOHALI Marianne OLNC/OLN

Cc : sipcore@ietf.org

Objet : Re: [sipcore] WGLC 4244bis-callflows global comments






 




 






Hi Marianne;






 






 Thanks for your review and comments.






 






 Should the figure number be above the callflow=
 figure or 






above the message examples? 






 






 Regards






  Shida






 




 
















Hello all,






 






I reviewed both draft-4244bis and call flow=
 and here and following email are my feedback on the callflows draft.






 






General comments:<=
/o:p>






 






MM#28 About Dale’s comments 2) and 3)=
: I agree that a complex example using the “0” value should be =
present in the call flow document. If you do a call flow document,
 you should show complex cases.






 






MM#29 Regarding Figures numbering and label=
, the document in not uniform. Each call flow should have its Figure number=
 and label just above (not 3 pages later).






 






 






Best Regards,






Marianne Mohali






 






 




______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 me=
ssages 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.




--_000_8B970F90C584EA4E97D5BAAC9172DBB8087661PEXCVZYM12corpora_--

From pkyzivat@alum.mit.edu  Thu Oct 18 11:10:19 2012
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 93B2021F8529 for ; Thu, 18 Oct 2012 11:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Level: 
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068,  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 HVkYXXLMqj68 for ; Thu, 18 Oct 2012 11:10:19 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id B5AAB21F845D for ; Thu, 18 Oct 2012 11:10:16 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id Cgs51k0080vyq2s51iAMXA; Thu, 18 Oct 2012 18:10:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id CiAh1k00V3ZTu2S3RiAhkf; Thu, 18 Oct 2012 18:10:41 +0000
Message-ID: <50804606.6050405@alum.mit.edu>
Date: Thu, 18 Oct 2012 14:10:14 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu>
In-Reply-To: <507C9472.9060101@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 18:10:19 -0000

If my records are correct we have now had significant reviews of all the 
callflows!!!

Many thanks to the volunteers:
- Brett
- Laura
- Marianne
- Roland

And to the others who have also contributed comments.

I have found the review comments and the resulting discussion to be 
interesting and significant. I regret not having provoked this level of 
attention sooner.

Shida has been commenting on specific points along the way.
Now I think it is time to assess where we are as a result of this exercise:
- how much is just defects to be fixed in the callflows
- have needs been identified for changes in the bis

I would like to see a "report" about this from the authors, and would be 
happy to hear more from others in the wg about it too. Hopefully we can 
wrap this all up quickly.

	Thanks,
	Paul

From internet-drafts@ietf.org  Thu Oct 18 23:45:13 2012
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 C79AD21F8485; Thu, 18 Oct 2012 23:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level: 
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 OSne4+kjVB8H; Thu, 18 Oct 2012 23:45:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16121F846C; Thu, 18 Oct 2012 23:45:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121019064513.12114.37939.idtracker@ietfa.amsl.com>
Date: Thu, 18 Oct 2012 23:45:13 -0700
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-12.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, 19 Oct 2012 06:45:14 -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           : Mechanism to indicate support of features and capabiliti=
es in the Session Initiation Protocol (SIP)
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
                          Hadriel Kaplan
	Filename        : draft-ietf-sipcore-proxy-feature-12.txt
	Pages           : 22
	Date            : 2012-10-18

Abstract:
   This specification defines a new SIP header field, Feature-Caps.  The
   Feature-Caps header field conveys feature capability indicators that
   are used to indicate support of features and capabilities for SIP
   entities that are not represented by the Uniform Resource Identifier
   (URI) of the Contact header field.

   SIP entities that are represented by the URI of the SIP Contact
   header field can convey media feature tags in the Contact header
   field to indicate support of features and capabilities.

   This specification also defines feature capability indicators, and
   creates a new IANA registry, "Proxy-Feature Feature Capability
   Indicator Trees", for registering feature capability indicators.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-12


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From christer.holmberg@ericsson.com  Thu Oct 18 23:53:02 2012
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 88F5A21F8685 for ; Thu, 18 Oct 2012 23:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.128
X-Spam-Level: 
X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 aPv2XHc1HvCD for ; Thu, 18 Oct 2012 23:53:01 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 54EB921F863F for ; Thu, 18 Oct 2012 23:53:01 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-53-5080f8cb1215
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.90.04547.BC8F0805; Fri, 19 Oct 2012 08:53:00 +0200 (CEST)
Received: from ESESSHC003.ericsson.se (153.88.183.27) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Oct 2012 08:53:00 +0200
Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 08:52:59 +0200
From: Christer Holmberg 
To: "sipcore@ietf.org" 
Thread-Topic: Draft new version: proxy-feature-12
Thread-Index: Ac2txjjD5IZpUedBQCavLYEbWBnNoQ==
Date: Fri, 19 Oct 2012 06:52:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B01972F@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B01972FESESSMB209ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre6ZHw0BBv2n2Sy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIZVc9kLGkQrjt7YxNLAeE+oi5GTQ0LARGLdol42CFtM4sK9 9UA2F4eQwClGiRnHJ7JDODsZJZ49PMkC4SxhlHiw9C1rFyMHB5uAhUT3P22QbhEBTYnl37ay g9jCAjoSR6ctZYaIG0p8PDKHBcLWk/g7oZEVxGYRUJVofn0AzOYV8JaY13UWzGYEuuL7qTVM IDazgLjErSfzmSCuE5BYsuc8M4QtKvHy8T9WCFtRYufZdmaI+nyJPUeOskHMFJQ4OfMJ2F4h AW2JlsUT2CcwisxCMnYWkpZZSFog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7Kkbh3MTM nPRyI73Uoszk4uL8PL3i1E2MwAg6uOW36g7GO+dEDjFKc7AoifNab93jLySQnliSmp2aWpBa FF9UmpNafIiRiYNTqoHRI778WKD79mn7Ej/wVB796dUZF730o2JTRd3hOCcRu29Tcgv3W2wI URZ8I9zLl1nl+PSrVtGmawv+Wn2ZXmYW9N3qUviOZTYvShKlj+Z6ZT2TEPn2cMakz3/lv/eu 2bjLXYXHR+Vub31feI9AQ/05jpOX6li292rsebPycl3mizdrvCZZX+ZWYinOSDTUYi4qTgQA A+9kGm4CAAA=
Subject: [sipcore] Draft new version: proxy-feature-12
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, 19 Oct 2012 06:53:02 -0000

--_000_7594FB04B1934943A5C02806D1A2204B01972FESESSMB209ericsso_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Based on the suggestions by Paul, I've submitted a new version (-12), of dr=
aft-ietf-sipcore-proxy-feature, which is now provided to the RFC Editor.

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B01972FESESSMB209ericsso_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Based on the suggestions by Paul, I’ve submitt=
ed a new version (-12), of draft-ietf-sipcore-proxy-feature, which is now p=
rovided to the RFC Editor.


 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B01972FESESSMB209ericsso_--

From R.Jesske@telekom.de  Fri Oct 19 04:08:47 2012
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 699C521F8589 for ; Fri, 19 Oct 2012 04:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.223
X-Spam-Level: 
X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.026,  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 fLmXQGFo0bSq for ; Fri, 19 Oct 2012 04:08:46 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1CA21F852B for ; Fri, 19 Oct 2012 04:08:46 -0700 (PDT)
Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 19 Oct 2012 13:08:43 +0200
Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 19 Oct 2012 13:08:43 +0200
From: 
To: 
Date: Fri, 19 Oct 2012 13:08:43 +0200
Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
Thread-Index: Ac2tM4ZA11POtoZfREivMiNpvGA4AQAtVErg
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FC@HE111648.emea1.cds.t-internal.com>
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D154513DC98@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de) <201210161838.q9GIcg5e4645365@shell01.TheWorld.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D154513E4AA@HE111648.emea1.cds.t-internal.com>  <580BEA5E3B99744AB1F5BFF5E9A3C67D1545215FB3@HE111648.emea1.cds.t-internal.com> <5DCF773A-D44B-4BA1-977A-27990D00C2B8@ntt-at.com>
In-Reply-To: <5DCF773A-D44B-4BA1-977A-27990D00C2B8@ntt-at.com>
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: worley@ariadne.com, sipcore@ietf.org
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
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, 19 Oct 2012 11:08:47 -0000

Hi Shida,
so if this is reflected then I'm satisfied.
But for me it is important that the first entry then starts with Index=3D1.

Best Regards

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: Shida Schubert [mailto:shida@ntt-at.com]
> Gesendet: Donnerstag, 18. Oktober 2012 15:18
> An: Jesske, Roland
> Cc: worley@ariadne.com; sipcore@ietf.org
> Betreff: Re: [sipcore] WGLC for
> draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
>
>
>  Hi Roland;
>
>  I am actually looking at the spec again and what the spec is
> saying is that the intermediary that supports RFC4244bis MUST
> set hi-entries, it has nothing to do with whether "histinfo"
> is set on the Supported header..
>
>  The only place where the behavior is affected by the
> presence of option tag in Supported header is "sending h-i in
> response (9.4)"
>
>  So I think RFC4244bis is fine as is.. Thoughts?
>
>  Regards
>   shida
>
> On Oct 18, 2012, at 4:08 PM, 
>  wrote:
>
> > Hi Shida,
> > in the past I had many problems to express our requirements
> to vendors and how they have to read standards.
> > So if it is allowed then we need some words within the
> text. I think as clearer standard text is as less problems we
> will get with implementations.
> >
> > So I'm in favour to add some text.
> >
> > Best Regards
> >
> > Roland
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Shida Schubert [mailto:shida@ntt-at.com]
> >> Gesendet: Donnerstag, 18. Oktober 2012 01:45
> >> An: Jesske, Roland
> >> Cc: worley@ariadne.com; sipcore@ietf.org
> >> Betreff: Re: [sipcore] WGLC for
> >> draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
> >>
> >>
> >> There is no text that prevents proxy to add hi-entries.
> >>
> >> But if there is a strong feeling towards adding an explicit text
> >> something along the line of
> >>
> >> "Intermediaries such as proxies MAY add hi-entries even if
> there is
> >> no histinfo option tag in the Supported header"
> >>
> >> Regards
> >>  Shida
> >>
> >> On Oct 17, 2012, at 6:35 PM, 
> >>  wrote:
> >>
> >>> Hi Dale,
> >>> see below
> >>>
> >>> Roland
> >>>>>
> >>>>> 2. In consideration of Brett's comments 3&4 regarding
> the use of
> >>>>> supported histinfo by the UAC I have the following view:
> >>>> For this use
> >>>>> case the support of History-Info by the originating UAC is
> >>>> not needed.
> >>>>> That is OK. I think this should be mentioned within the
> >> describing
> >>>>> text.
> >>>>
> >>>> It is not clear.  RFC 4244 allows a proxy to add
> History-Info to a
> >>>> request even if the request does not contain "Supported:
> >>>> histinfo".
> >>>> 4244bis does not state that a proxy is allowed to do that,
> >> although
> >>>> it doesn't clear specify that it may not do that.
> >>>>
> >>> So with regard to that we have then a GAP. Because there
> >> are Services based upon that.
> >>> 3GPP has defined the Communication Forwarding using that approach.
> >>> So due to backwards compatibility we need then there a
> description.
> >>>
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> sipcore@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>
> >>
>
>

From R.Jesske@telekom.de  Fri Oct 19 04:08:48 2012
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 7DC9721F852B for ; Fri, 19 Oct 2012 04:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qwnHrYHPB3IN for ; Fri, 19 Oct 2012 04:08:46 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6952D21F8528 for ; Fri, 19 Oct 2012 04:08:45 -0700 (PDT)
Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Oct 2012 13:08:43 +0200
Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by he110890 ([10.134.92.131]) with mapi; Fri, 19 Oct 2012 13:08:43 +0200
From: 
To: , 
Date: Fri, 19 Oct 2012 13:08:43 +0200
Thread-Topic: [sipcore]  WGLC 4244bis-callflows 3.1
Thread-Index: Ac2tH0mEnntdFaKuQmaV7xXXALIzrwAyIGaw
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FB@HE111648.emea1.cds.t-internal.com>
References: <15076_1350557816_507FE078_15076_1113_1_8B970F90C584EA4E97D5BAAC9172DBB80874A3@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <15076_1350557816_507FE078_15076_1113_1_8B970F90C584EA4E97D5BAAC9172DBB80874A3@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FBHE111648emea1_"
MIME-Version: 1.0
Subject: Re: [sipcore] WGLC 4244bis-callflows 3.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: Fri, 19 Oct 2012 11:08:48 -0000

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FBHE111648emea1_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Marianne,
there was no change related with this. RFC4244 states:

For retargets as a result of timeouts or internal events, a Reason

   MAY be associated with the hi-targeted-to-uri that has been

   retargeted
I understand the same applies also to RFC4244bis.
So it is allowed to include a 408 on a timeout. So that is nothing RFC4244b=
is specific.

Best Regards

Roland
________________________________
Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag =
von marianne.mohali@orange.com
Gesendet: Donnerstag, 18. Oktober 2012 12:57
An: sipcore@ietf.org
Betreff: [sipcore] WGLC 4244bis-callflows 3.1

Section 3.1
Ok with Laura comments.
MM#2: second paragraph: "The hi-entry containing the initial contact is the=
 hi-entry just prior to the first hi-entry tagged with an "rc" header field=
 parameter." According to the logic of "rc" param it is strange to use the =
terms "just prior".
Proposed correction: "The hi-entry containing the initial contact is the hi=
-entry just prior to *pointed by* the first hi-entry tagged with an "rc" he=
ader field parameter."


MM#3: F9: The timeout causing the retargeting is not a received SIP respons=
e so, in my first understanding, the Reason header should not be used. It w=
ould be better to use the RFC4458 reason for no reply in an URI parameter. =
May be I missed a specific change from RFC4244 on this topic.

draft4244bis states : "A reason is included in the hi-targeted-to-uri of an=
 hi-entry to reflect information received in a response to the request sent=
 to that URI." See my comment MM#20 on 3.6



History-Info: ;index=3D1
   History-Info: ;\
                 index=3D1.1;rc=3D1
   History-Info: ;index=3D1.2;mp=3D1
   History-Info: ;\
                 index=3D1.2.1>;index=3D1.2.1;rc=3D1.2
   History-Info: ;index=3D1.3;mp=3D1
   History-Info: ;index=3D1.3.1;rc=3D1.3

Instead, we can use de "cause" URI parameter (and may be also the "target")=
 in the hi-entry where the "mp" is added has follows:
History-Info: ;\
                 index=3D1.2.1>;index=3D1.2.1;rc=3D1.2

History-Info: ;index=3D1
   History-Info: ;\
                 index=3D1.1;rc=3D1
   History-Info: ;index=3D1.2;mp=3D1
   History-Info: ;\
                 index=3D1.2.1>;index=3D1.2.1;rc=3D1.2
   History-Info: ;index=3D1.3;mp=3D1
   History-Info: ;index=3D1.3.1;rc=3D1.3

Best Regards,
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.


--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FBHE111648emea1_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi=20
Marianne,


there=20
was no change related with this. RFC4244 states:


For retargets as a result of timeouts or internal even=
ts, a=20
Reason


   =
MAY be=20
associated with the hi-targeted-to-uri that has=20
been


  =20
retargeted


I understand the same applies also to=20
RFC4244bis.


So it is allowed to include a 408 on a timeout. So that is not=
hing=20
RFC4244bis specific.


 


Best=20
Regards


 


Roland 








Von: sipcore-bounces@ietf.org=20
[mailto:sipcore-bounces@ietf.org] Im Auftrag von=20
marianne.mohali@orange.com
Gesendet: Donnerstag, 18. Oktober =
2012=20
12:57
An: sipcore@ietf.org
Betreff: [sipcore] WGLC=20
4244bis-callflows 3.1



  

  

  
Sectio=
n=20
  3.1

  
Ok with Laura comments.

  
MM#2: second paragraph: “The hi-entry containing the i=
nitial=20
  contact is the hi-entry just prior to the first hi-entry tagged with an "=
rc"=20
  header field parameter.” According to the logic of “rc”=
 param it is strange to=20
  use the terms “just prior”.

  
Proposed correction: “The hi-entry containing the init=
ial contact=20
  is the hi-entry just prior to *pointed by* the first hi-entry tagged=
 with=20
  an "rc" header field parameter.” 

  
 
MM#3: F9=
: The timeout causing the retargeting is not a received SIP response so, in=
 my first understanding, the Reason header should not be used. It would be =
better to use the RFC4458 reason for no reply in an URI parameter. May be I=
 missed a specific change from RFC4244 on this topic. 
draft4244bis states : “A reason is incl=
uded in the hi-targeted-to-uri of an hi-entry to reflect information receiv=
ed in a response to the request sent to that URI.” See my comment=
 MM#20 on 3.6
 
History-Info: <sip:bob@example.c=
om>;index=3D1

  
   History-Info:=20
  <sip:bob@192.0.2.4?Reason=3DSIP%3Bcause%3D302>;\<=
/P>
  
          =
      =20
  index=3D1.1;rc=3D1

  
   History-Info:=20
  <sip:office@example.com>;index=3D1.2;mp=3D1

  
   History-Info: <sip:office@192.0.2.5?Reason=3DSIP%3Bcause%3D408>;\<=
/SPAN>

  
          =
      =20
  index=3D1.2.1>;index=3D1.2.1;rc=3D1.2

  
   History-Info:=20
  <sip:home@example.com>;index=3D1.3;mp=3D1

  
   History-Info:=20
  <sip:home@192.0.2.6>;index=3D1.3.1;rc=3D1.3

  
 

  
Instead, we can use de “cause” URI parameter (an=
d may be also the=20
  “target”) in the hi-entry where the “mp” is added=
 has=20
  follows:

  
History-Info: <sip:office@192.0.2.5>;\

  
          =
      =20
  index=3D1.2.1>;index=3D1.2.1;rc=3D1.2
History-Info: <sip:bob@example.com>;index=3D1=


  
   History-Info:=20
  <sip:bob@192.0.2.4?Reason=3DSIP%3Bcause%3D302>;\<=
/P>
  
          =
      =20
  index=3D1.1;rc=3D1

  
   History-Info:=20
  <sip:office@example.com>;index=3D1.2;mp=3D1

  
   History-Info: <sip:office@192.0.2.5?Reason=3DSIP%3Bcause%3D408>;\

  
          =
      =20
  index=3D1.2.1>;index=3D1.2.1;rc=3D1.2

  
   History-Info: <sip:home@example.com; cause=3D408>;index=3D1.3;mp=3D1

  
   History-Info:=20
  <sip:home@192.0.2.6>;index=3D1.3.1;rc=3D1.3

  
 

  
Best Regards,
  
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.
--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D15452DF8FBHE111648emea1_-- From brett@broadsoft.com Fri Oct 19 04:30:11 2012 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 7BA6321F8608 for ; Fri, 19 Oct 2012 04:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nriYQR-J36o1 for ; Fri, 19 Oct 2012 04:30:11 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97221F8600 for ; Fri, 19 Oct 2012 04:30:11 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 19 Oct 2012 04:30:17 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 04:30:17 -0700 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: AQHNrVvtI3VIpLcIAkaR3NwvZpjuNpfAdz6w Date: Fri, 19 Oct 2012 11:30:16 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@MBX06.citservers.local> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> <50804606.6050405@alum.mit.edu> In-Reply-To: <50804606.6050405@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:30:11 -0000 > Now I think it is time to assess where we are as=20 > a result of this exercise: > - how much is just defects to be fixed in the callflows In my opinion, there were enough rfc4244bis-callflows-01 comments to requir= e another WGLC. > - have needs been identified for changes in the bis Yes; the following comments correspond to draft-ietf-sipcore-rfc4244bis-10. 1) Section 5.1's example should indicate the mandatory History-Info within = first INVITE. 2) For clarification and backward compatibility reasons, I recommend that t= he draft highlight that the UAC must now add the History-Info and highlight= how the next hop should behave if History-Info is not present. 3) The last bullet of section 10.4 appears to conflict with prior text with= in the same section. More specifically, the bullet does not mention that t= he mp-value was obtained from the 3xx response's Contact. Thus it could be= interpreted as though it may be acceptable to ignore the prior MUST NOT. From pkyzivat@alum.mit.edu Fri Oct 19 08:26:53 2012 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 0122521F8461 for ; Fri, 19 Oct 2012 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, 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 si5dLfRkB0hn for ; Fri, 19 Oct 2012 08:26:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 734F721F845C for ; Fri, 19 Oct 2012 08:26:52 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id CzLB1k0060cZkys553Sw3o; Fri, 19 Oct 2012 15:26:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id D3So1k00d3ZTu2S3W3Sp7r; Fri, 19 Oct 2012 15:26:49 +0000 Message-ID: <5081713A.7080604@alum.mit.edu> Date: Fri, 19 Oct 2012 11:26:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> <50804606.6050405@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@MBX06.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:26:53 -0000 Brett, A question below. Thanks, Paul On 10/19/12 7:30 AM, Brett Tate wrote: >> Now I think it is time to assess where we are as >> a result of this exercise: >> - how much is just defects to be fixed in the callflows > > In my opinion, there were enough rfc4244bis-callflows-01 comments to require another WGLC. On the callflows, the bis, or both? >> - have needs been identified for changes in the bis > > Yes; the following comments correspond to draft-ietf-sipcore-rfc4244bis-10. > > 1) Section 5.1's example should indicate the mandatory History-Info within first INVITE. > > 2) For clarification and backward compatibility reasons, I recommend that the draft highlight that the UAC must now add the History-Info and highlight how the next hop should behave if History-Info is not present. > > 3) The last bullet of section 10.4 appears to conflict with prior text within the same section. More specifically, the bullet does not mention that the mp-value was obtained from the 3xx response's Contact. Thus it could be interpreted as though it may be acceptable to ignore the prior MUST NOT. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Fri Oct 19 08:59:22 2012 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 7BDE421F874C for ; Fri, 19 Oct 2012 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxcXfrATuIzZ for ; Fri, 19 Oct 2012 08:59:22 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4021F870E for ; Fri, 19 Oct 2012 08:59:21 -0700 (PDT) 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; Fri, 19 Oct 2012 08:59:29 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 08:59:29 -0700 From: Brett Tate To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: AQHNrg5Dw81d/JbU2USr6oxsgnNlxZfAwabQ Date: Fri, 19 Oct 2012 15:59:28 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88017AF9@MBX06.citservers.local> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> <50804606.6050405@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@MBX06.citservers.local> <5081713A.7080604@alum.mit.edu> In-Reply-To: <5081713A.7080604@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:59:22 -0000 > >> Now I think it is time to assess where we are as > >> a result of this exercise: > >> - how much is just defects to be fixed in the callflows > > > > In my opinion, there were enough rfc4244bis-callflows-01=20 > > comments to require another WGLC. >=20 > On the callflows, the bis, or both? The comment was to WGLC an updated version of draft-ietf-sipcore-rfc4244bis= -callflows. Concerning the following comments, I'm currently not sure if others agree t= hat all should be made and if such changes would require another WGLC. > >> - have needs been identified for changes in the bis > > > > Yes; the following comments correspond to draft-ietf-sipcore- > rfc4244bis-10. > > > > 1) Section 5.1's example should indicate the mandatory History-Info > within first INVITE. > > > > 2) For clarification and backward compatibility reasons, I recommend > that the draft highlight that the UAC must now add the History-Info and > highlight how the next hop should behave if History-Info is not > present. > > > > 3) The last bullet of section 10.4 appears to conflict with prior > text within the same section. More specifically, the bullet does not > mention that the mp-value was obtained from the 3xx response's Contact. > Thus it could be interpreted as though it may be acceptable to ignore > the prior MUST NOT. From worley@shell01.TheWorld.com Fri Oct 19 10:54:02 2012 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 8125921F85ED for ; Fri, 19 Oct 2012 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.063, 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 8zlMqXl7k1Ou for ; Fri, 19 Oct 2012 10:54:02 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D1F1E21F8434 for ; Fri, 19 Oct 2012 10:54:01 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9JHrMLr030771 for ; Fri, 19 Oct 2012 13:53:24 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9JHrL3f4849462 for ; Fri, 19 Oct 2012 13:53:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9JHrLUv4843438; Fri, 19 Oct 2012 13:53:21 -0400 (EDT) Date: Fri, 19 Oct 2012 13:53:21 -0400 (EDT) Message-Id: <201210191753.q9JHrLUv4843438@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <5DCF773A-D44B-4BA1-977A-27990D00C2B8@ntt-at.com> (shida@ntt-at.com) Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 19 Oct 2012 17:54:03 -0000 > From: Shida Schubert > > I am actually looking at the spec again and what the spec is saying > is that the intermediary that supports RFC4244bis MUST set > hi-entries, it has nothing to do with whether "histinfo" is set on > the Supported header.. > > The only place where the behavior is affected by the presence of > option tag in Supported header is "sending h-i in response (9.4)" > > So I think RFC4244bis is fine as is.. Thoughts? Yes, I was incorrect. A 4244bis-compliant proxy MUST add an hi-entry, as is described in section 7. But I agree with Roland, we need to arrange that in almost all cases, when a non-supporting UA sends a request to a supporting proxy, the proxy can insert an hi-entry with index=1. I believe that was the behavior in RFC 4244. Dale From shida@ntt-at.com Sat Oct 20 02:25:14 2012 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 7580221F85B3 for ; Sat, 20 Oct 2012 02:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=0.366, 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 sMcXIU9+U-KN for ; Sat, 20 Oct 2012 02:25:14 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id F22AE21F85A7 for ; Sat, 20 Oct 2012 02:25:13 -0700 (PDT) Received: from [118.109.76.216] (port=61263 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TPVIt-0006zX-6L; Sat, 20 Oct 2012 04:25:11 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@MBX06.citservers.local> Date: Sat, 20 Oct 2012 18:25:09 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> <50804606.6050405@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:61263 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 09:25:14 -0000 Hi Brett; My comments inline.. On Oct 19, 2012, at 8:30 PM, Brett Tate wrote: >> Now I think it is time to assess where we are as=20 >> a result of this exercise: >> - how much is just defects to be fixed in the callflows >=20 > In my opinion, there were enough rfc4244bis-callflows-01 comments to = require another WGLC. >=20 >> - have needs been identified for changes in the bis >=20 > Yes; the following comments correspond to = draft-ietf-sipcore-rfc4244bis-10. >=20 > 1) Section 5.1's example should indicate the mandatory History-Info = within first INVITE. >=20 > 2) For clarification and backward compatibility reasons, I recommend = that the draft highlight that the UAC must now add the History-Info and = highlight how the next hop should behave if History-Info is not present. The first point here I believe is already addressed in section 6.1 of = 4244bis-10..=20 Section 16.1 in 4244bis-10 also highlights the change in normative = behavior=20 in respect to UAC adding the "histinfo" Supported option tag and=20 addition of "history-info".=20 As for the second point I agree that there seems to be some need=20 for a text explicitly stating the behavior for when this condition is=20 met.=20 >=20 > 3) The last bullet of section 10.4 appears to conflict with prior text = within the same section. More specifically, the bullet does not mention = that the mp-value was obtained from the 3xx response's Contact. Thus it = could be interpreted as though it may be acceptable to ignore the prior = MUST NOT. I see where the confusion comes from.. The paragraph you mention is = really=20 talking about how and when the "mp" may be set. The MUST NOT paragraph=20= you mentioned specifically talk about these values in 3xx response and = how=20 they should be handled.=20 I believe what you are suggesting is to wordsmith the section so it is = clear=20 that entity receiving the 3xx simply copy what is in the contact and try = not to=20 determine the appropriate header field parameters ("mp","rc" or "np") so = there=20 is no confusion, am I right?=20 Thanks Shida >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sat Oct 20 02:30:59 2012 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 0D85721F8CA1 for ; Sat, 20 Oct 2012 02:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.92 X-Spam-Level: X-Spam-Status: No, score=-101.92 tagged_above=-999 required=5 tests=[AWL=0.345, 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 V2lcsFk5grP3 for ; Sat, 20 Oct 2012 02:30:58 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 846CA21F8C0E for ; Sat, 20 Oct 2012 02:30:58 -0700 (PDT) Received: from [118.109.76.216] (port=61390 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TPVOT-0001sg-F3; Sat, 20 Oct 2012 04:30:57 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210191753.q9JHrLUv4843438@shell01.TheWorld.com> Date: Sat, 20 Oct 2012 18:30:56 +0900 Content-Transfer-Encoding: 7bit Message-Id: <93617CA4-A357-4BC5-9580-3E510F8EFC1B@ntt-at.com> References: <201210191753.q9JHrLUv4843438@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:61390 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 20 Oct 2012 09:30:59 -0000 Hi Dale; That's correct.. And RFC4244bis as far as authors are concerned behave the same way as RFC4244 if there is no hi-entry in the incoming request. This really depends on if we keep the semantics of the gap as is (Gap is considered a gap only when there is hi-entry and last one doesn't match the R-URI of the incoming request). Obviously some text may be needed to explicitly state what entity should do when it is not the UAC and adding the first hi-entry.. Thanks Shida On Oct 20, 2012, at 2:53 AM, Dale R. Worley wrote: >> From: Shida Schubert >> >> I am actually looking at the spec again and what the spec is saying >> is that the intermediary that supports RFC4244bis MUST set >> hi-entries, it has nothing to do with whether "histinfo" is set on >> the Supported header.. >> >> The only place where the behavior is affected by the presence of >> option tag in Supported header is "sending h-i in response (9.4)" >> >> So I think RFC4244bis is fine as is.. Thoughts? > > Yes, I was incorrect. A 4244bis-compliant proxy MUST add an hi-entry, > as is described in section 7. > > But I agree with Roland, we need to arrange that in almost all cases, > when a non-supporting UA sends a request to a supporting proxy, the > proxy can insert an hi-entry with index=1. I believe that was the > behavior in RFC 4244. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Sun Oct 21 11:57:45 2012 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 8BBCF21F8908 for ; Sun, 21 Oct 2012 11:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSoqwjWF51kU for ; Sun, 21 Oct 2012 11:57:45 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3021F889F for ; Sun, 21 Oct 2012 11:57:44 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 21 Oct 2012 11:57:53 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Sun, 21 Oct 2012 11:57:53 -0700 From: Brett Tate To: Shida Schubert , "sipcore@ietf.org" Thread-Topic: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Thread-Index: AQHNrqTVnn0D+EqEyECFrLrfDKH5+JfEB0+g Date: Sun, 21 Oct 2012 18:57:52 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88017D74@MBX06.citservers.local> References: <201210081823.q98INdXE4220851@shell01.TheWorld.com> <50731E36.1070702@alum.mit.edu> <5075989F.3090305@alum.mit.edu> <507C9472.9060101@alum.mit.edu> <50804606.6050405@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B88017A6D@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WRAPUP of Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 18:57:45 -0000 > >> - have needs been identified for changes in the bis > > > > Yes; the following comments correspond to draft-ietf-sipcore- > rfc4244bis-10. > > > > 1) Section 5.1's example should indicate the mandatory History-Info > within first INVITE. > > > > 2) For clarification and backward compatibility reasons, I recommend > that the draft highlight that the UAC must now add the History-Info and > highlight how the next hop should behave if History-Info is not > present. >=20 > The first point here I believe is already addressed in section 6.1 of > 4244bis-10.. > Section 16.1 in 4244bis-10 also highlights the change in normative > behavior > in respect to UAC adding the "histinfo" Supported option tag and > addition of "history-info". I agree; section 16.1 does address the first part of the comment. After re= -reading sections 6.1, 9.2, and 16.1, I withdraw the first part of the comm= ent. > As for the second point I agree that there seems to be some need > for a text explicitly stating the behavior for when this condition is > met. >=20 > > > > 3) The last bullet of section 10.4 appears to conflict with prior > text within the same section. More specifically, the bullet does not > mention that the mp-value was obtained from the 3xx response's Contact. > Thus it could be interpreted as though it may be acceptable to ignore > the prior MUST NOT. >=20 > I see where the confusion comes from.. The paragraph you=20 > mention is really talking about how and when the "mp" may=20 > be set. The MUST NOT paragraph you mentioned specifically=20 > talk about these values in 3xx response and how they=20 > should be handled. >=20 > I believe what you are suggesting is to wordsmith the=20 > section so it is clear that entity receiving the 3xx=20 > simply copy what is in the contact and try not to > determine the appropriate header field parameters=20 > ("mp","rc" or "np") so there is no confusion, am I=20 > right? Yes; I recommend clarifying the last bullet to explicitly indicate (instead= of attempting to imply) that the mp-value was obtained from the 3xx respon= se's Contact. From internet-drafts@ietf.org Sun Oct 21 13:03:07 2012 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 30DCA21F8A24; Sun, 21 Oct 2012 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 FxvVba-qg3Uu; Sun, 21 Oct 2012 13:03:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B452221F88DC; Sun, 21 Oct 2012 13:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121021200306.8016.92228.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 13:03:06 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-05.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: Sun, 21 Oct 2012 20:03:07 -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-05.txt Pages : 21 Date : 2012-10-21 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in new scenarios. 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Sun Oct 21 13:10:15 2012 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 0C59421F8724 for ; Sun, 21 Oct 2012 13:10:15 -0700 (PDT) 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.067, 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 pV5mVLGHONXY for ; Sun, 21 Oct 2012 13:10:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22C21F86C8 for ; Sun, 21 Oct 2012 13:10:13 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1467270lbo.31 for ; Sun, 21 Oct 2012 13:10:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=qogGXJHaEcE/dcO06JUhW7RmZdGvY/sIuIv2VjAUMLA=; b=oZix/PvudR6+KdPUOInZprc27oshCsiEQZBRe3yCksceRlCsVL3KQiCrkUXwUiYbLE Pzg71zouYQ4Fp38yDfHhi9gnICI4OrmwDaok+fE8hiWNJeYYXq9/VdHhkcbcmrADpP2e Gp3yi4+UUx8xQsL496bUsyFuE85NnYkiHpDNr1oNSWD+Me8oSgmwKzwIl5nJLSpyEqQ5 OiYW9XkBUbsZSWaUM9DXegifhZBeheLj6IYVhmq//YvpFAbF2d3JPZ0Yqerflv8d2g7n +MVHjt0vLe9MzMwTaomqDcl4nIbToKT1dgm/FfHyvEi1mcen2RROS3DrbfdC/lJ9HqXL H5sA== Received: by 10.152.135.41 with SMTP id pp9mr6484438lab.7.1350850212862; Sun, 21 Oct 2012 13:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Sun, 21 Oct 2012 13:09:52 -0700 (PDT) In-Reply-To: <20121021200306.8016.92228.idtracker@ietfa.amsl.com> References: <20121021200306.8016.92228.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 21 Oct 2012 22:09:52 +0200 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmNMA7C5oXuvlx9RmiQboE9qKA52ylqrMoCwCV3kxH+YeFSEA3M8RRWBv7hpNszGSkYIOOz Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-05.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: Sun, 21 Oct 2012 20:10:15 -0000 2012/10/21 : > > 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-05.txt > Pages : 21 > Date : 2012-10-21 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities to enable usage of SIP in new > scenarios. 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-05 Hi all. This new version of the draft includes the following changes given the feedback given for the previous version 04: - atlanta.com is replaced with example.com in flow examples. - Abstract now mentions that this specification updates RFC 3261 and Introduction gives more details. - New requests in IANA Considerations section for the "SIP/SIPS URI Parameters" Sub-Registry, "Header Fields" Sub-Registry and "Header Field Parameters and Parameter Values" Sub-Registry. As always your comments are welcome. Best regards. --=20 I=C3=B1aki Baz Castillo From R.Jesske@telekom.de Sun Oct 21 22:30:08 2012 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 7661021F8878 for ; Sun, 21 Oct 2012 22:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ODJ9L3s1rPFU for ; Sun, 21 Oct 2012 22:30:08 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E686D21F87DF for ; Sun, 21 Oct 2012 22:30:05 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 07:30:04 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 22 Oct 2012 07:30:04 +0200 From: To: , Date: Mon, 22 Oct 2012 07:30:03 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 Thread-Index: Ac2uIsSWrEA40G4WTfmtpuGPDtncLgB8xREQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15452DFD0F@HE111648.emea1.cds.t-internal.com> References: <5DCF773A-D44B-4BA1-977A-27990D00C2B8@ntt-at.com> (shida@ntt-at.com) <201210191753.q9JHrLUv4843438@shell01.TheWorld.com> In-Reply-To: <201210191753.q9JHrLUv4843438@shell01.TheWorld.com> 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 Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 22 Oct 2012 05:30:08 -0000 Dale, even a supporting RFC4244 UA should not include an H-I when not needed. We are using RFC4244 only to show the real forwarding ("mp"). For our netwo= rk this is sufficient, because we want to avoid loops in forwarding calls (= max 5 times). That was one of our requirements. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. Worley > Gesendet: Freitag, 19. Oktober 2012 19:53 > An: sipcore@ietf.org > Betreff: Re: [sipcore] WGLC for > draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 > > > From: Shida Schubert > > > > I am actually looking at the spec again and what the spec > is saying is > > that the intermediary that supports RFC4244bis MUST set > hi-entries, it > > has nothing to do with whether "histinfo" is set on the Supported > > header.. > > > > The only place where the behavior is affected by the presence of > > option tag in Supported header is "sending h-i in response (9.4)" > > > > So I think RFC4244bis is fine as is.. Thoughts? > > Yes, I was incorrect. A 4244bis-compliant proxy MUST add an > hi-entry, as is described in section 7. > > But I agree with Roland, we need to arrange that in almost > all cases, when a non-supporting UA sends a request to a > supporting proxy, the proxy can insert an hi-entry with > index=3D1. I believe that was the behavior in RFC 4244. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From shida@ntt-at.com Mon Oct 22 04:39:39 2012 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 BBD1F21F8AE0 for ; Mon, 22 Oct 2012 04:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.937 X-Spam-Level: X-Spam-Status: No, score=-101.937 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 W1Vqcq8l1ZDK for ; Mon, 22 Oct 2012 04:39:37 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6921F85D5 for ; Mon, 22 Oct 2012 04:39:37 -0700 (PDT) Received: from [118.109.76.216] (port=50595 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TQGM3-0003AX-O2; Mon, 22 Oct 2012 06:39:36 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_072AF1EF-B4B7-4528-A6F9-5F3A22E8FAA2" From: Shida Schubert In-Reply-To: <15059_1350566813_5080039D_15059_4048_1_8B970F90C584EA4E97D5BAAC9172DBB8087661@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Mon, 22 Oct 2012 20:39:34 +0900 Message-Id: <4BD00C3A-C445-4BA8-8DF2-8ACD0A1E08E3@ntt-at.com> References: <15076_1350557808_507FE070_15076_1100_1_8B970F90C584EA4E97D5BAAC9172DBB8087497@PEXCVZYM12.corporate.adroot.infra.ftgroup> <15059_1350566813_5080039D_15059_4048_1_8B970F90C584EA4E97D5BAAC9172DBB8087661@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: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:50595 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC 4244bis-callflows global comments 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, 22 Oct 2012 11:39:39 -0000 --Apple-Mail=_072AF1EF-B4B7-4528-A6F9-5F3A22E8FAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Marianne; I will go through your comments this week and provide=20 feedbacks. I will put the label above the figure as you=20 suggested.=20 Many thanks again for all of your comments.=20 Regards Shida On Oct 18, 2012, at 10:26 PM, = wrote: > Hi Shida, > =20 > If I were you, I would put the Figure number/label just above the = callflow figure (it is weird to see it 3 pages after the figure). > =20 > Marianne > =20 > De : Shida Schubert [mailto:shida@ntt-at.com]=20 > Envoy=E9 : jeudi 18 octobre 2012 15:21 > =C0 : MOHALI Marianne OLNC/OLN > Cc : sipcore@ietf.org > Objet : Re: [sipcore] WGLC 4244bis-callflows global comments > =20 > =20 > Hi Marianne; > =20 > Thanks for your review and comments. > =20 > Should the figure number be above the callflow figure or=20 > above the message examples?=20 > =20 > Regards > Shida > =20 > =20 > On Oct 18, 2012, at 7:56 PM, = wrote: >=20 >=20 > Hello all, > =20 > I reviewed both draft-4244bis and call flow and here and following = email are my feedback on the callflows draft. > =20 > General comments: > =20 > MM#28 About Dale=92s comments 2) and 3): I agree that a complex = example using the =930=94 value should be present in the call flow = document. If you do a call flow document, you should show complex cases. > =20 > MM#29 Regarding Figures numbering and label, the document in not = uniform. Each call flow should have its Figure number and label just = above (not 3 pages later). > =20 > =20 > Best Regards, > Marianne Mohali > =20 > =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. > _______________________________________________ > 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. --Apple-Mail=_072AF1EF-B4B7-4528-A6F9-5F3A22E8FAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Marianne;

 I will go through your comments = this week and provide 
feedbacks. I will put the label = above the figure as = you 
suggested. 

 Many = thanks again for all of your = comments. 

 Regards
  = Shida

On Oct 18, 2012, at 10:26 PM, <marianne.mohali@orange.com&= gt; <marianne.mohali@orange.com&= gt; wrote:

Hi = Shida,
If I were you, I would put the Figure number/label = just above the callflow figure (it is weird to see it 3 pages after the = figure).
 
 
 Shida Schubert = [mailto:shida@ntt-at.com] 
Envoy=E9 : jeudi 18 octobre 2012 = 15:21
=C0 : MOHALI Marianne = OLNC/OLN
Cc : sipcore@ietf.org
Objet : Re: [sipcore] WGLC = 4244bis-callflows global = comments
Hi = Marianne;
 Thanks for your = review and comments.
 Should the figure = number be above the callflow figure = or 
above the message = examples? 
  = Shida
On Oct 18, 2012, at 7:56 = PM, <marianne.mohali@orange.com> = <marianne.mohali@orange.com> = wrote:
Hello = all,
I = reviewed both draft-4244bis and call flow and here and following email = are my feedback on the callflows draft.
 MM#28 About = Dale=92s comments 2) and 3): I agree that a complex example using the = =930=94 value should be present in the call flow document. If you do a = call flow document, you should show complex cases.
Marianne Mohali
 
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@ietf.org
 
In-Reply-To: 
Date: Mon, 22 Oct 2012 20:48:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121021200306.8016.92228.idtracker@ietfa.amsl.com> 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1499)
Cc: sipcore@ietf.org, "Olle E. Johansson" 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-05.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, 22 Oct 2012 18:49:00 -0000

Random comments:

- If the RFC adds NAPTR records, should it update RFC 3263 as well?

- Section 9.1: I suggest using normative language and change "SIP =
traffic transported over
a websocket connection SHOULD be protected by using a WebSocket =
connection over TLS."

- Section 10.3 should propably mention "WS/WSS" transport identifiers - =
or?

I suggest that GRUU support is upgraded to a MUST. It's required for SIP =
subscriptions,
for transfers and many other operations that involve the Contact - which =
is quite a=20
useless URI. All operations that involve the contact should hit the =
proxy.

/O


From ibc@aliax.net  Mon Oct 22 14:16:07 2012
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 E92D511E8099 for ; Mon, 22 Oct 2012 14:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level: 
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.064,  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 UhKEpSbyOK3k for ; Mon, 22 Oct 2012 14:16:07 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC511E8097 for ; Mon, 22 Oct 2012 14:16:06 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so2254323lbo.31 for ; Mon, 22 Oct 2012 14:16:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=spxfVHT/TL+ISE75NqXfED9V6G8X1DLxVJzLtCJe9aY=; b=PcL+1OiFOltp1UqJ6PfUHQGH/0PMsq9+qG3zFeYjCoopxhvdMU+dd9D4wOABb4F3xK aEw7KsHrI3oBWmDlJmyAAKkzFQYucaSYGIFrUm0t4d2um/uPbzmLp3syIdN59lzgYaVV 2nZ4qMB3VQtwXLtqdx64RIRlio8YbnXtEdvbxLyb/miCdx5M4JtZLIrWE9d6NljCB4Xo exCRE3iMozsUAz7jfDW6JepSR8fwS2yHOP9eCKDw5mN5bSvNToCcUFjX6ahJebHdOEGV j0326eGJqIqovE1zsJaG8BEvRpGdpWKV6kKk1XXQm/clhjEEKv4ABygJXfhC+5JrsyFz U5VA==
Received: by 10.152.135.41 with SMTP id pp9mr9521523lab.7.1350940565707; Mon, 22 Oct 2012 14:16:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Mon, 22 Oct 2012 14:15:45 -0700 (PDT)
In-Reply-To: 
References: <20121021200306.8016.92228.idtracker@ietfa.amsl.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 22 Oct 2012 23:15:45 +0200
Message-ID: 
To: "Olle E. Johansson" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmdl5bpjuWr+R3Nu2cprFES8xrNM1QB1xVP3G8Hbopzyjo9tvXf+VI9jxZBaRl4hfd5wHUL
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-05.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, 22 Oct 2012 21:16:08 -0000

2012/10/22 Olle E. Johansson :
> Random comments:
>
> - If the RFC adds NAPTR records, should it update RFC 3263 as well?

Hi, RFC 4168 (SIP SCTP transport) does not update RFC 3261 nor RFC
3263 (while it defines a new SIP transport and new NAPTR records).
I think that adding new NAPTR records does not mean that RFC 3263
should be updated since all what is said in RFC 3262 is still true and
does not change at all due to the addition of new NAPTR records. Am I
wrong?



> - Section 9.1: I suggest using normative language and change "SIP traffic=
 transported over
> a websocket connection SHOULD be protected by using a WebSocket connectio=
n over TLS."

No RFC states that "SIP over TCP-TLS SHOULD be used" so I can't
understand the reason to mandate WebSocket over TLS. Thoughts?



> - Section 10.3 should propably mention "WS/WSS" transport identifiers - o=
r?

As Robert explained in a previous mail: "the URI parameter registry
lists the names of the URI parameters, but not the values":

http://www.iana.org/assignments/sip-parameters

BTW take into account that this spec just defines a single value for
;transport parameter which is "ws". WSS justs exists in the Via header
(in the same way that TLS over TCP is represented with ;transport=3Dtcp,
SIPS schema and TLS in the Via header).




> I suggest that GRUU support is upgraded to a MUST. It's required for SIP =
subscriptions,
> for transfers and many other operations that involve the Contact - which =
is quite a
> useless URI. All operations that involve the contact should hit the proxy=
.

While I mostly agree, this was already discussed in Paris some months
ago and there was consensus not to mandate GRUU (nor Outbound which
also makes sense).


Thanks a lot for your feedback.


--=20
I=C3=B1aki Baz Castillo


From worley@shell01.TheWorld.com  Tue Oct 23 13:04:08 2012
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 71BE321F8568 for ; Tue, 23 Oct 2012 13:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level: 
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.684, 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 AI4r9sovZ1ta for ; Tue, 23 Oct 2012 13:04:08 -0700 (PDT)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id E138321F855E for ; Tue, 23 Oct 2012 13:04:07 -0700 (PDT)
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 q9NK3H2N027635 for ; Tue, 23 Oct 2012 16:03:20 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9NK3F705146642 for ; Tue, 23 Oct 2012 16:03:15 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9NK3Dnw5182327; Tue, 23 Oct 2012 16:03:13 -0400 (EDT)
Date: Tue, 23 Oct 2012 16:03:13 -0400 (EDT)
Message-Id: <201210232003.q9NK3Dnw5182327@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: sipcore@ietf.org
In-reply-to: <580BEA5E3B99744AB1F5BFF5E9A3C67D15452DFD0F@HE111648.emea1.cds.t-internal.com> (R.Jesske@telekom.de)
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01	Section 3.11
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, 23 Oct 2012 20:04:08 -0000

> From: 
> 
> even a supporting RFC4244 UA should not include an H-I when not needed.
> We are using RFC4244 only to show the real forwarding ("mp"). For
> our network this is sufficient, because we want to avoid loops in
> forwarding calls (max 5 times).
> That was one of our requirements.

How could the UAC possibly know whether H-I will be needed once the
INVITE reaches a destination?  Or a proxy, for that matter?

Dale

From mary.ietf.barnes@gmail.com  Tue Oct 23 13:32:05 2012
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 AA37C1F0C9B for ; Tue, 23 Oct 2012 13:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.392
X-Spam-Level: 
X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wDyCJtg155qG for ; Tue, 23 Oct 2012 13:32:05 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2BDD1F0424 for ; Tue, 23 Oct 2012 13:32:04 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2981281lam.31 for ; Tue, 23 Oct 2012 13:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gxSAE12yQm9gmtNiIT0es7cyUGRjU8xYKZB5RRH8sgs=; b=sRqCvcY274bNaIqtZ49eWA1ChBIOOFavjB46+i1+Wtw5mYiynsZYgKi89UGBq1vP5n wky2YPCq+EwE0ihqwA+8tctdw4XVu3IYqs+rhc4bZUIqMQAkNCQCKO8r+z6+XBJCexiv qpWDhG1winxLfqcVUUBd/cITT4uvCSnegd2tk01eZGk/or0T0pnjDUFtoDVUWSooQiIj HRgYIA33ao8b3fPP+DyjY+SYUqy2/BoJo7GyVZ0+SBPzdD0/8GX9ADYqBXnWhkXiydCu bIgDl7iOFIEwUN9Sswl2uVRf1kAPlC2ALHh5pchFySMwK3PE70yrXiYKqDBUUpJE+hNf Tp2w==
MIME-Version: 1.0
Received: by 10.152.148.8 with SMTP id to8mr12598173lab.2.1351024323775; Tue, 23 Oct 2012 13:32:03 -0700 (PDT)
Received: by 10.114.69.139 with HTTP; Tue, 23 Oct 2012 13:32:03 -0700 (PDT)
In-Reply-To: <201210232003.q9NK3Dnw5182327@shell01.TheWorld.com>
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D15452DFD0F@HE111648.emea1.cds.t-internal.com> <201210232003.q9NK3Dnw5182327@shell01.TheWorld.com>
Date: Tue, 23 Oct 2012 15:32:03 -0500
Message-ID: 
From: Mary Barnes 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=e89a8f22bd09e6cd9904ccbfdc44
Cc: sipcore@ietf.org
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
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, 23 Oct 2012 20:32:05 -0000

--e89a8f22bd09e6cd9904ccbfdc44
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 23, 2012 at 3:03 PM, Dale R. Worley  wrote:

> > From: 
> >
> > even a supporting RFC4244 UA should not include an H-I when not needed.
> > We are using RFC4244 only to show the real forwarding ("mp"). For
> > our network this is sufficient, because we want to avoid loops in
> > forwarding calls (max 5 times).
> > That was one of our requirements.
>
[MB] That approach is NOT compliant with 4244bis. One of the bigger changes
between 4244 and 4244bis was to change the addition of HI to a MUST. While
you may not care about "mp", you are not compliant if you don't add the
other values.  [/MB]

>
> How could the UAC possibly know whether H-I will be needed once the
> INVITE reaches a destination?  Or a proxy, for that matter?
>
[MB] Exactly - trying to do that embeds application logic into the core SIP
message processing - not a good idea at all.  [/MB]

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

--e89a8f22bd09e6cd9904ccbfdc44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tue, Oct 23, 2012 at 3:03 PM, Dale R.=
 Worley <worley@ariadne.com> wrote:

> From: <R.Jesske@telekom.de>


>

> even a supporting RFC4244 UA should not include an H-I when not needed=
.

> We are using RFC4244 only to show the real forwarding ("mp")=
. For

> our network this is sufficient, because we want to avoid loops in

> forwarding calls (max 5 times).

> That was one of our requirements.






How could the UAC possibly know whether H-I will be needed once the
INVITE reaches a destination? =A0Or a proxy, for that matter?
[MB] Exactly - trying to do that embeds application logic into the =
core SIP message processing - not a good idea at all. =A0[/MB]=A0





Dale

_______________________________________________

sipcore mailing list

sipcore@ietf.org

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





--e89a8f22bd09e6cd9904ccbfdc44--

From worley@shell01.TheWorld.com  Tue Oct 23 14:46:06 2012
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 CD7771F0C3A for ; Tue, 23 Oct 2012 14:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=0.085,  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 BEk0Uib8nlSx for ; Tue, 23 Oct 2012 14:46:06 -0700 (PDT)
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id D3C031F0424 for ; Tue, 23 Oct 2012 14:46:05 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9NLjZj4018246 for ; Tue, 23 Oct 2012 17:45:37 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9NLjZsf5195689 for ; Tue, 23 Oct 2012 17:45:35 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9NLjYRY5181600; Tue, 23 Oct 2012 17:45:34 -0400 (EDT)
Date: Tue, 23 Oct 2012 17:45:34 -0400 (EDT)
Message-Id: <201210232145.q9NLjYRY5181600@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: sipcore@ietf.org
In-reply-to: <93617CA4-A357-4BC5-9580-3E510F8EFC1B@ntt-at.com> (shida@ntt-at.com)
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01	Section 3.11
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, 23 Oct 2012 21:46:06 -0000

> From: Shida Schubert 
> 
>  That's correct.. And RFC4244bis as far as authors are 
> concerned behave the same way as RFC4244 if there 
> is no hi-entry in the incoming request. 
> 
> This really depends on if we keep the semantics 
> of the gap as is (Gap is considered a gap only when there 
> is hi-entry and last one doesn't match the R-URI of the 
> incoming request). 
>    
> Obviously some text may be needed to explicitly state 
> what entity should do when it is not the UAC and adding the 
> first hi-entry.. 

And some thought needs to be put into what the desired behavior is.
Off the top of my head, the desiderata include:

- Updating the logic defining a "gap" so that it does not fail if
  there is no H-I present.

- Behaving the same as RFC 4244.

- Creating an H-I that resembles what would be created if the UAC
  inserted the index=1 element, in the case of the first-hop proxy
  adding the initial hi-entry.

- If the UAC is a B2BUA creating a request with only one Via header,
  the H-I should not deceive the UAS to the point of causing
  malfunction (in the bulk of cases).

(These may be incompatible!)

In regard to 4244, the relevant text is:

   4.3.  Protocol Usage

   This section describes the processing specific to UAs and Proxies for
   the History-Info header, the "histinfo" option tag, and the priv-
   value of "history".  As discussed in Section 1.3, the fundamental
   objective is to capture the target Request-URIs as a request is
   forwarded.  This allows for the capturing of the history of a request
   that would be lost due to subsequent (re)targeting and forwarding.
   To accomplish this for the entire history of a request, either the
   UAC must capture the Request-URI in a History-Info header in the
   initial request or a proxy must add a History-Info header with both a
   hi-entry for the Request-URI in the initial request and a hi-entry
   for the target Request-URI as the request is forwarded.  [...]

   4.3.1.  User Agent Client (UAC) Behavior

   The UAC SHOULD include the "histinfo" option tag in the Supported
   header in any request not associated with an established dialog for
   which the UAC would like the History-Info header in the response.  In
   addition, the UAC MAY improve the diagnostic utility of its request
   by adding a History-Info header, using the Request-URI of the request
   as the hi-target-to-uri and initializing the index to the RECOMMENDED
   value of 1 in the hi-entry.  [...]

   4.3.3.1.  Adding the History-Info Header to Requests

   [...] Additionally, if a request is received that doesn't include a
   History-Info header, the proxy MAY add a History-Info header with a
   hi-entry preceding the one being added for the current request
   being forwarded.  The index for this hi-entry is RECOMMENDED to
   start at 1.  [...]

Which suggests that the "obvious" rule is that if a supporting proxy
receives a request that does not contain a History-Info header,
instead of considering it a "gap" situation, it must add one
containing the request-URI of the incoming request, with an index of 1
before further processing.  (This is a case where the current 4244bis
"gap definition" is ambiguous as written.)

The consequences of this rule include:

- Due to section 9.4 in 4244bis, a proxy that adds such an initial
  hi-entry will not send History-Info in the response to the initial
  request.  So upstream (presumably non-supporting) elements are
  "protected" from seeing H-I.

- UASs are deceived regarding the original request-URI.  This seems to
  be tolerable, as it means that the UAS is unaware of earlier
  translation steps, but that it correctly sees the tail of the
  sequence of translation steps.  This may deny it information that it
  could act on, but the information it sees is accurate, as long as it
  is aware that the index=1 entry may not be the true user-dialed
  number.

Dale

From shida@ntt-at.com  Tue Oct 23 17:32:58 2012
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 9922411E8124 for ; Tue, 23 Oct 2012 17:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.954
X-Spam-Level: 
X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.311, 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 tN7SM3aMGelW for ; Tue, 23 Oct 2012 17:32:58 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id EA55711E8125 for ; Tue, 23 Oct 2012 17:32:57 -0700 (PDT)
Received: from [118.109.76.216] (port=57858 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TQou0-0002n5-6o; Tue, 23 Oct 2012 19:32:56 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert 
In-Reply-To: <201210232145.q9NLjYRY5181600@shell01.TheWorld.com>
Date: Wed, 24 Oct 2012 09:32:56 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <3E34394E-3935-47FC-AA7B-535A5F72B30D@ntt-at.com>
References: <201210232145.q9NLjYRY5181600@shell01.TheWorld.com>
To: Dale R. Worley 
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:57858
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: sipcore@ietf.org
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01	Section 3.11
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, 24 Oct 2012 00:32:58 -0000

Hi Dale;

 My comments inline..

On Oct 24, 2012, at 6:45 AM, Dale R. Worley wrote:

>> From: Shida Schubert 
>> 
>> That's correct.. And RFC4244bis as far as authors are 
>> concerned behave the same way as RFC4244 if there 
>> is no hi-entry in the incoming request. 
>> 
>> This really depends on if we keep the semantics 
>> of the gap as is (Gap is considered a gap only when there 
>> is hi-entry and last one doesn't match the R-URI of the 
>> incoming request). 
>> 
>> Obviously some text may be needed to explicitly state 
>> what entity should do when it is not the UAC and adding the 
>> first hi-entry.. 
> 
> And some thought needs to be put into what the desired behavior is.
> Off the top of my head, the desiderata include:
> 
> - Updating the logic defining a "gap" so that it does not fail if
>  there is no H-I present.

 What do you mean fail? 

> 
> - Behaving the same as RFC 4244.

 Then we can't set 0.. We would need to set 1. 

> 
> - Creating an H-I that resembles what would be created if the UAC
>  inserted the index=1 element, in the case of the first-hop proxy
>  adding the initial hi-entry.

 Right.. 

> 
> - If the UAC is a B2BUA creating a request with only one Via header,
>  the H-I should not deceive the UAS to the point of causing
>  malfunction (in the bulk of cases).

 Can you elaborate?

> 
> (These may be incompatible!)
> 
> In regard to 4244, the relevant text is:
> 
>   4.3.  Protocol Usage
> 
>   This section describes the processing specific to UAs and Proxies for
>   the History-Info header, the "histinfo" option tag, and the priv-
>   value of "history".  As discussed in Section 1.3, the fundamental
>   objective is to capture the target Request-URIs as a request is
>   forwarded.  This allows for the capturing of the history of a request
>   that would be lost due to subsequent (re)targeting and forwarding.
>   To accomplish this for the entire history of a request, either the
>   UAC must capture the Request-URI in a History-Info header in the
>   initial request or a proxy must add a History-Info header with both a
>   hi-entry for the Request-URI in the initial request and a hi-entry
>   for the target Request-URI as the request is forwarded.  [...]
> 
>   4.3.1.  User Agent Client (UAC) Behavior
> 
>   The UAC SHOULD include the "histinfo" option tag in the Supported
>   header in any request not associated with an established dialog for
>   which the UAC would like the History-Info header in the response.  In
>   addition, the UAC MAY improve the diagnostic utility of its request
>   by adding a History-Info header, using the Request-URI of the request
>   as the hi-target-to-uri and initializing the index to the RECOMMENDED
>   value of 1 in the hi-entry.  [...]
> 
>   4.3.3.1.  Adding the History-Info Header to Requests
> 
>   [...] Additionally, if a request is received that doesn't include a
>   History-Info header, the proxy MAY add a History-Info header with a
>   hi-entry preceding the one being added for the current request
>   being forwarded.  The index for this hi-entry is RECOMMENDED to
>   start at 1.  [...]
> 
> Which suggests that the "obvious" rule is that if a supporting proxy
> receives a request that does not contain a History-Info header,
> instead of considering it a "gap" situation, it must add one
> containing the request-URI of the incoming request, with an index of 1
> before further processing.  (This is a case where the current 4244bis
> "gap definition" is ambiguous as written.)
> 
> The consequences of this rule include:
> 
> - Due to section 9.4 in 4244bis, a proxy that adds such an initial
>  hi-entry will not send History-Info in the response to the initial
>  request.  So upstream (presumably non-supporting) elements are
>  "protected" from seeing H-I.

 Could you elaborate this? I am not quite seeing what you are 
trying to address here.. 

> 
> - UASs are deceived regarding the original request-URI.  This seems to
>  be tolerable, as it means that the UAS is unaware of earlier
>  translation steps, but that it correctly sees the tail of the
>  sequence of translation steps.  This may deny it information that it
>  could act on, but the information it sees is accurate, as long as it
>  is aware that the index=1 entry may not be the true user-dialed
>  number.

 Right.. 

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


From marianne.mohali@orange.com  Tue Oct 23 23:58:10 2012
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 B23D521F8D8F for ; Tue, 23 Oct 2012 23:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Jcn30jA9vATB for ; Tue, 23 Oct 2012 23:58:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8122921F8D85 for ; Tue, 23 Oct 2012 23:58:06 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 37FE12DC526 for ; Wed, 24 Oct 2012 08:58:05 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1AD4F4C015 for ; Wed, 24 Oct 2012 08:58:05 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 24 Oct 2012 08:58:04 +0200
From: 
To: "sipcore@ietf.org" 
Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments
Thread-Index: Ac2xcTXreG5fkIryRHqNfDwLVeAeEQ==
Date: Wed, 24 Oct 2012 06:58:04 +0000
Message-ID: <32004_1351061885_5087917D_32004_14903_1_8B970F90C584EA4E97D5BAAC9172DBB8088378@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8088378PEXCVZYM12corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.50316
Subject: [sipcore]  draft-ietf-sipcore-rfc4244bis-10 Comments
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, 24 Oct 2012 06:58:10 -0000

--_000_8B970F90C584EA4E97D5BAAC9172DBB8088378PEXCVZYM12corpora_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Here is my feedback on 4244bis-10. Sorry for this late feedback but I prefe=
r to do it now than never.

MM#1 Section 5:  In this section which is about the protocol structure, in =
the Privacy bullet, the new priv-value "history" is not mentioned at all wh=
ereas it is used in the example just after. Because we are in an important =
structure section, this lack could lead to confusion in privacy mechanism u=
nderstanding. In addition, a reference to section 10.1 dedicated to Privacy=
 should be useful.

MM#2 Section 5: In the same idea as the previous comment, the new option ta=
g "histinfo" is not mentioned (or I missed it)


MM#3 Section 6.1: Regarding the sentence: "In the case of an initial reques=
t, except where the UAC is part of a B2BUA, there is no cache of hi-entries
   with which to populate the History-Info header field and the hi-index is=
 set to 1 per Section 10.3."
Reading this sentence, it is not clear to me on what should/must do the UAC=
. I guess, because there is no cache, the UAC can (or not) insert a hi-entr=
y based on the R-URI with an index set to 1. And if the UAC don't add the H=
-I, the next proxy adding a H-I would do it for 2 entries (the received R-U=
RI and the new R-URI). Am I right? Don't you think the sentence should be m=
ore explicit?


MM#4 Section 12.1: Regarding the sentence: "The original target is determin=
ed by finding the first hi-entry tagged with "rc" and using the hi-entry re=
ferenced by the index of "rc" header field parameter as the target for dete=
rmining the appropriate mailbox. >

Instead of "the first hi-entry tagged with "rc"

I would say "the first hi-entry tagged with "rc" or "mp"" in case there is =
no first "rc" before an "mp". Do you agree?


MM#5 Section 12.2: In the same idea as my previous comment, in the second p=
aragraph, why only "rc" is mentioned and not "mp"? May be I missed somethin=
g.

Best Regards,
Marianne Mohali

___________________________________________________________________________=
______________________________________________

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.


--_000_8B970F90C584EA4E97D5BAAC9172DBB8088378PEXCVZYM12corpora_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,


 


Here is my feedback on 4244bis-=
10. Sorry for this late feedback but I prefer to do it now than never.=



 


MM#1 Section 5:  In this s=
ection which is about the protocol structure, in the Privacy bullet, the ne=
w priv-value “history” is not mentioned at all whereas it is us=
ed in the example just after. Because we are in an important
 structure section, this lack could lead to confusion in privacy mechanism =
understanding. In addition, a reference to section 10.1 dedicated to Privac=
y should be useful.


 


MM#2 Section 5: In the same ide=
a as the previous comment, the new option tag “histinfo” is not=
 mentioned (or I missed it)


 


MM#3 Section 6.1: Regarding the sentence: “In the case of an initial request, except where the =
UAC is part of a B2BUA, there is no cache of hi-entries

   with which to populate the His=
tory-Info header field and the hi-index is set to 1 per Section 10.3.”=
;


Reading this sentence, it is no=
t clear to me on what should/must do the UAC. I guess, because there is no =
cache, the UAC can (or not) insert a hi-entry based on the R-URI with an in=
dex set to 1. And if the UAC don’t add
 the H-I, the next proxy adding a H-I would do it for 2 entries (the receiv=
ed R-URI and the new R-URI). Am I right? Don’t you think the sentence=
 should be more explicit?


 


MM#4 Section 12.1: Regarding the sentence: “The original target is determined by finding the fi=
rst hi-entry tagged with "rc" and using the hi-entry referenced b=
y the index of "rc" header field parameter as the target for dete=
rmining the appropriate mailbox. » 


Instead of =
220;the first hi-entry tagged with "rc" 


I would say &#=
8220;the first hi-entry tagged with "rc" or “mp”” in case there is no first “rc” before an “mp=
”. Do you agree?


 


MM#5 Section 12.2: In the same =
idea as my previous comment, in the second paragraph, why only “rc=
221; is mentioned and not “mp”? May be I missed something.=



 


Best Regards,=



Marianne Mohali




______________________________________________________________________=
___________________________________________________

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.




--_000_8B970F90C584EA4E97D5BAAC9172DBB8088378PEXCVZYM12corpora_--

From brett@broadsoft.com  Wed Oct 24 04:38:46 2012
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 2D47021F8A07 for ; Wed, 24 Oct 2012 04:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZJaVrbaBma8 for ; Wed, 24 Oct 2012 04:38:45 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8E21F8829 for ; Wed, 24 Oct 2012 04:38:45 -0700 (PDT)
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; Wed, 24 Oct 2012 04:38:56 -0700
Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 24 Oct 2012 04:38:56 -0700
From: Brett Tate 
To: "marianne.mohali@orange.com" , "sipcore@ietf.org" 
Thread-Topic: [sipcore]  draft-ietf-sipcore-rfc4244bis-10 Comments
Thread-Index: Ac2xcTXreG5fkIryRHqNfDwLVeAeEQAZ8aVA
Date: Wed, 24 Oct 2012 11:38:55 +0000
Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B880182CD@MBX06.citservers.local>
References: <32004_1351061885_5087917D_32004_14903_1_8B970F90C584EA4E97D5BAAC9172DBB8088378@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <32004_1351061885_5087917D_32004_14903_1_8B970F90C584EA4E97D5BAAC9172DBB8088378@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.98.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments
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, 24 Oct 2012 11:38:46 -0000

> MM#3 Section 6.1: Regarding the sentence: "In the case=20
> of an initial request, except where the UAC is part of=20
> a B2BUA, there is no cache of hi-entries with which to=20
> populate the History-Info header field and the hi-index=20
> is set to 1 per Section 10.3."
> Reading this sentence, it is not clear to me on what=20
> should/must do the UAC. I guess, because there is no=20
> cache, the UAC can (or not) insert a hi-entry based=20
> on the R-URI with an index set to 1. And if the UAC=20
> don't add the H-I, the next proxy adding a H-I would=20
> do it for 2 entries (the received R-URI and the new=20
> R-URI). Am I right?=20

The UAC must add the History-Info.


> Don't you think the sentence should be more explicit?

I had a similar comment; although I'm not sure what all makes the text ambi=
guous.

1) Different from RFC 4244.
2) Text split across 3 sections.
3) Section 5.1 example is non compliant.
4) Some draft-ietf-sipcore-rfc4244bis-callflows-01 examples are non complia=
nt.

The following are the 3 draft-ietf-sipcore-rfc4244bis-10 snippets indicatin=
g that the History-Info must be added.

Section 6.1:

"When issuing a request, the UAC MUST follow the
 procedures in Section 9.2.  In the case of an initial request, except
 where the UAC is part of a B2BUA, there is no cache of hi- entries
 with which to populate the History-Info header field and the hi-index
 is set to 1 per Section 10.3."

Section 9.2:

"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,"

Section 16.1:

"Inclusion of hi-target-entry along with hi-index has changed from
 MAY/RECOMMEND to MUST/MUST."


From marianne.mohali@orange.com  Wed Oct 24 09:18:16 2012
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 DCC3721F8964 for ; Wed, 24 Oct 2012 09:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054,  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 98G70x5Y91Ub for ; Wed, 24 Oct 2012 09:18:16 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F33ED21F8853 for ; Wed, 24 Oct 2012 09:18:15 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B6EC63249C4; Wed, 24 Oct 2012 18:18:14 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9B3CA23804B; Wed, 24 Oct 2012 18:18:14 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 24 Oct 2012 18:18:14 +0200
From: 
To: Brett Tate , "sipcore@ietf.org" 
Thread-Topic: [sipcore]  draft-ietf-sipcore-rfc4244bis-10 Comments
Thread-Index: Ac2xcTXreG5fkIryRHqNfDwLVeAeEQAZ8aVAAAFzuuA=
Date: Wed, 24 Oct 2012 16:18:13 +0000
Message-ID: <19800_1351095494_508814C6_19800_4436_1_8B970F90C584EA4E97D5BAAC9172DBB80885EE@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <32004_1351061885_5087917D_32004_14903_1_8B970F90C584EA4E97D5BAAC9172DBB8088378@PEXCVZYM12.corporate.adroot.infra.ftgroup> <576A8B541C219D4E9CEB1DF8C19C7B880182CD@MBX06.citservers.local>
In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B880182CD@MBX06.citservers.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
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: 2012.10.24.110314
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments
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, 24 Oct 2012 16:18:17 -0000

Hi Brett,

If it is true that UAC MUST include the History-Info, then:
- Several call flows are not compliant in the callflow draft (3.6, 3.7 and =
3.11-comment already sent)
- Why there is no "MUST" in the UAC section when initiating a request which=
 is the most common case??! (Issuing or receiving a request is different fr=
om initiating. There is no MUST in the sentence I quoted)
- There is no backward compatibility with RFC4244 for UAC.

If it is a MUST, it MUST be written ;)
IMO, the ambiguity comes from the fact that the UAC has no cache when initi=
ating a request.

Marianne

-----Message d'origine-----
De=A0: Brett Tate [mailto:brett@broadsoft.com]=20
Envoy=E9=A0: mercredi 24 octobre 2012 13:39
=C0=A0: MOHALI Marianne OLNC/OLN; sipcore@ietf.org
Objet=A0: RE: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments

> MM#3 Section 6.1: Regarding the sentence: "In the case=20
> of an initial request, except where the UAC is part of=20
> a B2BUA, there is no cache of hi-entries with which to=20
> populate the History-Info header field and the hi-index=20
> is set to 1 per Section 10.3."
> Reading this sentence, it is not clear to me on what=20
> should/must do the UAC. I guess, because there is no=20
> cache, the UAC can (or not) insert a hi-entry based=20
> on the R-URI with an index set to 1. And if the UAC=20
> don't add the H-I, the next proxy adding a H-I would=20
> do it for 2 entries (the received R-URI and the new=20
> R-URI). Am I right?=20

The UAC must add the History-Info.


> Don't you think the sentence should be more explicit?

I had a similar comment; although I'm not sure what all makes the text ambi=
guous.

1) Different from RFC 4244.
2) Text split across 3 sections.
3) Section 5.1 example is non compliant.
4) Some draft-ietf-sipcore-rfc4244bis-callflows-01 examples are non complia=
nt.

The following are the 3 draft-ietf-sipcore-rfc4244bis-10 snippets indicatin=
g that the History-Info must be added.

Section 6.1:

"When issuing a request, the UAC MUST follow the
 procedures in Section 9.2.  In the case of an initial request, except
 where the UAC is part of a B2BUA, there is no cache of hi- entries
 with which to populate the History-Info header field and the hi-index
 is set to 1 per Section 10.3."

Section 9.2:

"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,"

Section 16.1:

"Inclusion of hi-target-entry along with hi-index has changed from
 MAY/RECOMMEND to MUST/MUST."


___________________________________________________________________________=
______________________________________________

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 shida@ntt-at.com  Wed Oct 24 10:06:23 2012
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 CAF6D21F8529 for ; Wed, 24 Oct 2012 10:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.968
X-Spam-Level: 
X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ogPb6f6Bwn4P for ; Wed, 24 Oct 2012 10:06:23 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id DC70121F847D for ; Wed, 24 Oct 2012 10:06:22 -0700 (PDT)
Received: from [118.109.76.216] (port=62068 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TR4PM-0001cM-4X; Wed, 24 Oct 2012 12:06:20 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C677518F-86C3-4699-8AC7-FF2D42BA3F2A"
From: Shida Schubert 
In-Reply-To: <19800_1351095494_508814C6_19800_4436_1_8B970F90C584EA4E97D5BAAC9172DBB80885EE@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Date: Thu, 25 Oct 2012 02:06:20 +0900
Message-Id: 
References: <32004_1351061885_5087917D_32004_14903_1_8B970F90C584EA4E97D5BAAC9172DBB8088378@PEXCVZYM12.corporate.adroot.infra.ftgroup> <576A8B541C219D4E9CEB1DF8C19C7B880182CD@MBX06.citservers.local> <19800_1351095494_508814C6_19800_4436_1_8B970F90C584EA4E97D5BAAC9172DBB80885EE@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: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:62068
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments
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, 24 Oct 2012 17:06:23 -0000

--Apple-Mail=_C677518F-86C3-4699-8AC7-FF2D42BA3F2A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Hi Marianne;

 My comments inline..

On Oct 25, 2012, at 1:18 AM,  =
 wrote:

> Hi Brett,
>=20
> If it is true that UAC MUST include the History-Info, then:
> - Several call flows are not compliant in the callflow draft (3.6, 3.7 =
and 3.11-comment already sent)

 The call flows are missing the normative behavior in 4244bis and these =
were addressed=20
by Brett already. I will fix these.=20

> - Why there is no "MUST" in the UAC section when initiating a request =
which is the most common case??! (Issuing or receiving a request is =
different from initiating. There is no MUST in the sentence I quoted)

 It does.. It references section 9.2 where the normative behavior is to =
add=20
hi-entry. Per section 9.2 as UAC has no cache when sending initial=20
request it would follow the second paragraph in section 9.2..=20

"In addition, the
   SIP entity MUST add a new hi-entry to the outgoing request"


> - There is no backward compatibility with RFC4244 for UAC.

 RFC4244 can add hi-entry as specified in section 4.3.1 of the=20
RFC. It's a MAY but it is not like UAC wasn't able to add hi-entry=20
that the next hop (proxy) will be surprised receiving hi-entry from=20
the UAC.. It should have expected it as it was allowed to add.=20

>=20
> If it is a MUST, it MUST be written ;)
> IMO, the ambiguity comes from the fact that the UAC has no cache when =
initiating a request.

 Do you mean the text in 9.2 is not sufficient??

 Thanks
  Shida

>=20
> Marianne
>=20
> -----Message d'origine-----
> De : Brett Tate [mailto:brett@broadsoft.com]=20
> Envoy=E9 : mercredi 24 octobre 2012 13:39
> =C0 : MOHALI Marianne OLNC/OLN; sipcore@ietf.org
> Objet : RE: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments
>=20
>> MM#3 Section 6.1: Regarding the sentence: "In the case=20
>> of an initial request, except where the UAC is part of=20
>> a B2BUA, there is no cache of hi-entries with which to=20
>> populate the History-Info header field and the hi-index=20
>> is set to 1 per Section 10.3."
>> Reading this sentence, it is not clear to me on what=20
>> should/must do the UAC. I guess, because there is no=20
>> cache, the UAC can (or not) insert a hi-entry based=20
>> on the R-URI with an index set to 1. And if the UAC=20
>> don't add the H-I, the next proxy adding a H-I would=20
>> do it for 2 entries (the received R-URI and the new=20
>> R-URI). Am I right?=20
>=20
> The UAC must add the History-Info.
>=20
>=20
>> Don't you think the sentence should be more explicit?
>=20
> I had a similar comment; although I'm not sure what all makes the text =
ambiguous.
>=20
> 1) Different from RFC 4244.
> 2) Text split across 3 sections.
> 3) Section 5.1 example is non compliant.
> 4) Some draft-ietf-sipcore-rfc4244bis-callflows-01 examples are non =
compliant.
>=20
> The following are the 3 draft-ietf-sipcore-rfc4244bis-10 snippets =
indicating that the History-Info must be added.
>=20
> Section 6.1:
>=20
> "When issuing a request, the UAC MUST follow the
> procedures in Section 9.2.  In the case of an initial request, except
> where the UAC is part of a B2BUA, there is no cache of hi- entries
> with which to populate the History-Info header field and the hi-index
> is set to 1 per Section 10.3."
>=20
> Section 9.2:
>=20
> "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,"
>=20
> Section 16.1:
>=20
> "Inclusion of hi-target-entry along with hi-index has changed from
> MAY/RECOMMEND to MUST/MUST."
>=20
>=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


--Apple-Mail=_C677518F-86C3-4699-8AC7-FF2D42BA3F2A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

marianne.mohali@orange.com&=
gt; <marianne.mohali@orange.com&=
gt; wrote:

Hi Brett,

If it is true that UAC MUST include = the History-Info, then:
- Several call flows are not compliant in the = callflow draft (3.6, 3.7 and 3.11-comment already = sent)

 The call flows are = missing the normative behavior in 4244bis and these were = addressed 
by Brett already. I will fix = these. 

- Why there is no = "MUST" in the UAC section when initiating a request which is the most = common case??! (Issuing or receiving a request is different from = initiating. There is no MUST in the sentence I = quoted)

 It does.. It = references section 9.2 where the normative behavior is to = add 
hi-entry. Per section 9.2 as UAC has no cache when = sending initial 
request it would follow the second = paragraph in section 9.2.. 

"In addition, the
   SIP entity MUST add a new hi-entry =
to the outgoing request"


- There is no backward compatibility with RFC4244 for = UAC.

 RFC4244 can add = hi-entry as specified in section 4.3.1 of the 
RFC. It's = a MAY but it is not like UAC wasn't able to add = hi-entry 
that the next hop (proxy) will be surprised = receiving hi-entry from 
the UAC.. It should have = expected it as it was allowed to add. 


If it is a MUST, it MUST be written ;)
IMO, = the ambiguity comes from the fact that the UAC has no cache when = initiating a request.

 Do = you mean the text in 9.2 is not = sufficient??

 Thanks
  = Shida


Marianne

-----Message = d'origine-----
De : Brett Tate [mailto:brett@broadsoft.com] =
Envoy=E9 : mercredi 24 octobre 2012 13:39
=C0 : MOHALI = Marianne OLNC/OLN; sipcore@ietf.org
Objet : = RE: [sipcore] draft-ietf-sipcore-rfc4244bis-10 = Comments

MM#3 Section 6.1: Regarding = the sentence: "In the case
of = an initial request, except where the UAC is part of =
a B2BUA, there is no cache of = hi-entries with which to
populate the History-Info header field and the hi-index =
is set to 1 per Section = 10.3."
Reading this sentence, = it is not clear to me on what
should/must do the UAC. I guess, because there is no =
cache, the UAC can (or not) = insert a hi-entry based
on = the R-URI with an index set to 1. And if the UAC =
don't add the H-I, the next = proxy adding a H-I would
do = it for 2 entries (the received R-URI and the new =
R-URI). Am I right? =

The UAC must add the = History-Info.


Don't you think the = sentence should be more explicit?

I had a similar = comment; although I'm not sure what all makes the text = ambiguous.

1) Different from RFC 4244.
2) Text split across 3 = sections.
3) Section 5.1 example is non compliant.
4) Some = draft-ietf-sipcore-rfc4244bis-callflows-01 examples are non = compliant.

The following are the 3 = draft-ietf-sipcore-rfc4244bis-10 snippets indicating that the = History-Info must be added.

Section 6.1:

"When issuing a = request, the UAC MUST follow the
procedures in Section 9.2.  In = the case of an initial request, except
where the UAC is part of a = B2BUA, there is no cache of hi- entries
with which to populate the = History-Info header field and the hi-index
is set to 1 per Section = 10.3."

Section 9.2:

"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,"

Section = 16.1:

"Inclusion of hi-target-entry along with hi-index has = changed from
MAY/RECOMMEND to = MUST/MUST."


___________________________________________________= ______________________________________________________________________
=
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

= --Apple-Mail=_C677518F-86C3-4699-8AC7-FF2D42BA3F2A-- From worley@shell01.TheWorld.com Wed Oct 24 12:50:22 2012 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 82B9C21F8ACD for ; Wed, 24 Oct 2012 12:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[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 y6nfUcvUmnzQ for ; Wed, 24 Oct 2012 12:50:22 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A621F8ACE for ; Wed, 24 Oct 2012 12:50:21 -0700 (PDT) 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 q9OJo0gd004910; Wed, 24 Oct 2012 15:50:03 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9OJm9wp5230385; Wed, 24 Oct 2012 15:48:09 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9OJm8Cw5219522; Wed, 24 Oct 2012 15:48:08 -0400 (EDT) Date: Wed, 24 Oct 2012 15:48:08 -0400 (EDT) Message-Id: <201210241948.q9OJm8Cw5219522@shell01.TheWorld.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: Shida Schubert In-reply-to: <3E34394E-3935-47FC-AA7B-535A5F72B30D@ntt-at.com> (shida@ntt-at.com) X-Mailman-Approved-At: Wed, 24 Oct 2012 12:51:53 -0700 Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 24 Oct 2012 19:50:22 -0000 > From: Shida Schubert > > On Oct 24, 2012, at 6:45 AM, Dale R. Worley wrote: > > - Updating the logic defining a "gap" so that it does not fail if > > there is no H-I present. > > What do you mean fail? Reading the text ("If the Request-URI of the incoming request does not match the hi-targeted-to-uri in the last hi-entry") as an algorithm, no provision is made for the possibility that there is no hi-entry. As code, this would have a run-time error, and it is ambiguous what action should be taken in this case. > > - Behaving the same as RFC 4244. > > Then we can't set 0.. We would need to set 1. > > > - Creating an H-I that resembles what would be created if the UAC > > inserted the index=1 element, in the case of the first-hop proxy > > adding the initial hi-entry. > > Right.. > > > - If the UAC is a B2BUA creating a request with only one Via header, > > the H-I should not deceive the UAS to the point of causing > > malfunction (in the bulk of cases). > > Can you elaborate? Earlier, I suggested that we add a rule that if a proxy receives a request with no "Supported: histinfo" or History-Info, but it contains exactly one Via, then the proxy can add the incoming request-URI to the H-I with index=1 because the proxy knows that it is receiving the request directly from the UAC. (In this latest proposal, the restriction "exactly one Via" is removed.) Paul pointed out that the UAC in question may be the client side of a B2BUA, and so the incoming request-URI at the proxy isn't really the origination request-URI. So there is the question of whether the "application" in the UAS will be confused by the History-Info in some way that makes a difference. I believe that there is no risk, because the application does not absolutely need to know the true origination request-URI, and will not be deceived dangerously if the initial request-URIs are missing. In general, the application should walk the hi-entries, starting with the *last* one, and following the chain of URIs from which the final request-URI was derived, until it reaches one that it does not recognize (or it gets to the beginning). The last-examined URI (the earliest in the H-I) that it recognizes, is the "incoming" URI from the point of view of the application, and answers the question of "What URI did the user use (directly or indirectly) when he called us?" >From this point of view, losing initial hi-entries will degrade the information that the application can extract, but it does not make that information fundamentally incorrect. > > The consequences of this rule include: > > > > - Due to section 9.4 in 4244bis, a proxy that adds such an initial > > hi-entry will not send History-Info in the response to the initial > > request. So upstream (presumably non-supporting) elements are > > "protected" from seeing H-I. > > Could you elaborate this? I am not quite seeing what you are > trying to address here.. I seem to remember during the discussions there was a desire to not have History-Info sent in responses to a UAC if the UAC has not indicated support for H-I (by adding a History-Info header or "Supported: histinfo"). This was not to prevent the UAC from being "confused" by a header that it did not understand, but to prevent the last-hop response from being enlarged. RFC 4244 does not state a MUST that ensures this effect, although the text in section 4.3.2 suggests this. 4244bis does ensure this effect in section 9.4. > > - UASs are deceived regarding the original request-URI. This seems to > > be tolerable, as it means that the UAS is unaware of earlier > > translation steps, but that it correctly sees the tail of the > > sequence of translation steps. This may deny it information that it > > could act on, but the information it sees is accurate, as long as it > > is aware that the index=1 entry may not be the true user-dialed > > number. > > Right.. Dale From worley@shell01.TheWorld.com Wed Oct 24 16:08:08 2012 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 2619D21F8C80 for ; Wed, 24 Oct 2012 16:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.079, 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 nio30QjsUJ+w for ; Wed, 24 Oct 2012 16:08:07 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1221F8C7F for ; Wed, 24 Oct 2012 16:08:06 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9ON7QSc004746 for ; Wed, 24 Oct 2012 19:07:28 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9ON7Q5X5217131 for ; Wed, 24 Oct 2012 19:07:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9ON7PpY5229025; Wed, 24 Oct 2012 19:07:25 -0400 (EDT) Date: Wed, 24 Oct 2012 19:07:25 -0400 (EDT) Message-Id: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] "Gaps" in call flows 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, 24 Oct 2012 23:08:08 -0000 As I see it, the central pivot of the problem is this: What does a proxy do when it receives a response that contains a "duplicate" hi-entry? (That is, an hi-entry whose index is the same as in a previously received hi-entry, but whose URI is different.) (The two responses involved necessarily are generated by different forks made by a non-supporting proxy, and will come from two different elements, or at least, two different proxy transactions.) Actually, the problem is messier than a single duplicate hi-entry, as each of the duplicate hi-entries can have "child" hi-entries. For example, one response can contain: History-Info: ..., ;index=1.1.0.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1.1, ;index=1.1.0.1.1.2 and the other can contain: History-Info: ..., ;index=1.1.0.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1.1 "At the top level", and are duplicates, but they have the corresponding (with index 1.1.0.1.1.1) child duplicates and , and the hi-entry with index 1.1.0.1.1.2 is affected by the duplication despite not being a duplicate itself. The first consideration is that we can't avoid the problem. All proposals that have been discussed will cause this situation, at least occasionally, when a supporting proxy forwards a request to a non-supporting proxy, which forks the request to two supporting elements. One alternative is for the RFC to say nothing about handling the situation. This is dangerous, because the text leaves the strong impression that the index of an hi-entry uniquely determines the URI, and the needed processing naturally suggests using data structures that depends on this uniqueness. So if we say nothing, it is likely that implementations will crash when they encounter this problem. So we need to warn the implementer about this problem. There are two obvious alternatives that an implementer can choose. One choice is for the implementation to keep one hi-entry and discard the other hi-entry (and to discard the "child" hi-entries of that other hi-entry). The cache is still keyed by the index values, but when there is a duplication, one of the duplicate hi-entries is lost. This approach loses information, but results in a History-Info header that conforms to everyone's expectations. In the above example, the History-Info in the proxy's response would be one of the two received response History-Infos. The other choice is for the implementation to keep both hi-entries. This requires a different data structure for the cache, and causes the proxy to send History-Info that contain duplicate hi-entries. These duplicate hi-entries in a single response create cascading duplications upstream. This choice also raises the question of how the hi-entries are to be ordered in History-Info, since the prescribed tree preorder assumes that indexes are unique. In the above example, we could place the two index-1.1.0.1 hi-entries as siblings and have their children follow in tree order: History-Info: ..., ;index=1.1.0.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1.1, ;index=1.1.0.1.1.2, ;index=1.1.0.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1.1 or we could sort the hi-entries by their index values, which is what the current text seems to demand: History-Info: ..., ;index=1.1.0.1, ;index=1.1.0.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1, ;index=1.1.0.1.1.1, ;index=1.1.0.1.1.1, ;index=1.1.0.1.1.2 In any case, it becomes more difficult for a UAS application to extract knowledge about the origin of the request that it received -- if hi-entries are discarded, information is inevitably lost; if duplicates are preserved, parameters referencing indexes are inevitably ambiguous. It seems to be safer for the RFC to specify that one or the other approach is required in proxies, so that all proxies handle duplicates consistently, and applications can depend on that. It seems to be safer to require that the proxy discard one duplicate (and all its children), because that approach never generates History-Info values that contain duplicates -- there is less information in History-Info, but the structure of History-Info is not made more complex, and the way to interpret it is unambiguous. Regardless of how we prescribe that a proxy should handle duplicates, it is clear that we want to minimize the chances of duplicates happening, since duplicates unavoidably result in loss of information. Within this context, we can discuss how we would like to handle "gaps", as that affects how often duplicates will be seen. One approach is to not mark gaps at all, which is the approach in RFC 4244. This results in duplicates being generated every time a call passes through the troublesome situation: a supporting proxy forwards a request to a non-supporting proxy, which forks the request to two supporting elements. Additionally, the existence of the gap is not flagged at all. The approach in the draft is to represent gaps by inserting "0" as a number in the index. This is an improvement relative to RFC 4244, because the presence of gaps are marked explicitly, but it does not reduce the number of duplicates: duplicates are generated by every call that passes through the troublesome situation. Another approach is to represent gaps by a randomly-chosen number from a suitably large range. If the specified range does not overlap the branch numbers that are generated in normal situations, gaps are flagged explicitly. In addition, the number of duplicates can be reduced to whatever degree is desired, since duplicates only happen when two random numbers happen to be the same -- with high probability, even in the troublesome situation, two responses will not not contain duplicates, and the proxy will assemble a History-Info that unambiguously presents all the information that it received. Dale From shida@ntt-at.com Thu Oct 25 06:09:06 2012 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 C1D8521F88CD for ; Thu, 25 Oct 2012 06:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=0.283, 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 h5uYAF8RjWAl for ; Thu, 25 Oct 2012 06:09:06 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 109EB21F86E1 for ; Thu, 25 Oct 2012 06:09:05 -0700 (PDT) Received: from [118.109.76.216] (port=49992 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TRNBI-0006vq-CO; Thu, 25 Oct 2012 08:09:04 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201210241948.q9OJm8Cw5219522@shell01.TheWorld.com> Date: Thu, 25 Oct 2012 22:09:04 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <201210241948.q9OJm8Cw5219522@shell01.TheWorld.com> To: worley@alum.mit.edu (Dale R. Worley) X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [118.109.76.216]:49992 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 5 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 25 Oct 2012 13:09:06 -0000 Hi Dale; My comment inline.. On Oct 25, 2012, at 4:48 AM, Dale R. Worley wrote: >> From: Shida Schubert >> >> On Oct 24, 2012, at 6:45 AM, Dale R. Worley wrote: >>> - Updating the logic defining a "gap" so that it does not fail if >>> there is no H-I present. >> >> What do you mean fail? > > Reading the text ("If the Request-URI of the incoming request does not > match the hi-targeted-to-uri in the last hi-entry") as an algorithm, > no provision is made for the possibility that there is no hi-entry. > As code, this would have a run-time error, and it is ambiguous what > action should be taken in this case. For optional header to cause a run-time error because there is no value that is optional in the first place, sounds to me like a bad coding.. Anyway, if what you are saying is to explicitly state somewhere that hi-entry doesn't always exist that's fine.. > >>> - Behaving the same as RFC 4244. >> >> Then we can't set 0.. We would need to set 1. >> >>> - Creating an H-I that resembles what would be created if the UAC >>> inserted the index=1 element, in the case of the first-hop proxy >>> adding the initial hi-entry. >> >> Right.. >> >>> - If the UAC is a B2BUA creating a request with only one Via header, >>> the H-I should not deceive the UAS to the point of causing >>> malfunction (in the bulk of cases). >> >> Can you elaborate? > > Earlier, I suggested that we add a rule that if a proxy receives a > request with no "Supported: histinfo" or History-Info, but it contains > exactly one Via, then the proxy can add the incoming request-URI to > the H-I with index=1 because the proxy knows that it is receiving the > request directly from the UAC. > > (In this latest proposal, the restriction "exactly one Via" is > removed.) > > Paul pointed out that the UAC in question may be the client side of a > B2BUA, and so the incoming request-URI at the proxy isn't really the > origination request-URI. > > So there is the question of whether the "application" in the UAS will > be confused by the History-Info in some way that makes a difference. > > I believe that there is no risk, because the application does not > absolutely need to know the true origination request-URI, and will not > be deceived dangerously if the initial request-URIs are missing. I completely agree. > > In general, the application should walk the hi-entries, starting with > the *last* one, and following the chain of URIs from which the final > request-URI was derived, until it reaches one that it does not > recognize (or it gets to the beginning). The last-examined URI (the > earliest in the H-I) that it recognizes, is the "incoming" URI from > the point of view of the application, and answers the question of > "What URI did the user use (directly or indirectly) when he called > us?" Right. > > From this point of view, losing initial hi-entries will degrade the > information that the application can extract, but it does not make > that information fundamentally incorrect. Right. > >>> The consequences of this rule include: >>> >>> - Due to section 9.4 in 4244bis, a proxy that adds such an initial >>> hi-entry will not send History-Info in the response to the initial >>> request. So upstream (presumably non-supporting) elements are >>> "protected" from seeing H-I. >> >> Could you elaborate this? I am not quite seeing what you are >> trying to address here.. > > I seem to remember during the discussions there was a desire to not > have History-Info sent in responses to a UAC if the UAC has not > indicated support for H-I (by adding a History-Info header or > "Supported: histinfo"). This was not to prevent the UAC from being > "confused" by a header that it did not understand, but to prevent the > last-hop response from being enlarged. > > RFC 4244 does not state a MUST that ensures this effect, although the > text in section 4.3.2 suggests this. 4244bis does ensure this effect > in section 9.4. Right.. There was some debate about UAS sending back all the hi-entries with the MUST strength due to the concern about the message size of the response. > >>> - UASs are deceived regarding the original request-URI. This seems to >>> be tolerable, as it means that the UAS is unaware of earlier >>> translation steps, but that it correctly sees the tail of the >>> sequence of translation steps. This may deny it information that it >>> could act on, but the information it sees is accurate, as long as it >>> is aware that the index=1 entry may not be the true user-dialed >>> number. >> >> Right.. > > Dale From mary.ietf.barnes@gmail.com Thu Oct 25 07:14:12 2012 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 96B5321F867C for ; Thu, 25 Oct 2012 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PyoZI4UFpbpZ for ; Thu, 25 Oct 2012 07:14:11 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDAD21F8417 for ; Thu, 25 Oct 2012 07:14:04 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1726323lam.31 for ; Thu, 25 Oct 2012 07:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/QiEUoIu686wnyUSf6r7HAZb2c3UZ9S9+uwAR6CEtN8=; b=QOPgrOoDJCAm7+4YksD5i+dQzeIDaTBWw8SVax07CPBqmsklRdrpbc7LG4rTEscbzc 6Af0nCh48UX7nRztE2hGi1w/9qPloAuj6jnFpi0hFIUluBrSj56CoLRJ+2Mvny173oSK I7LbstSuINF+sAMhsfVtSddGtpqfQ4+uJlRFIqT1QjwGfX64XOoFpK3igDNYtsWljGyO mZE3GSUld17CHdjzQBzopz/yp3jN5nWVziZzzAgjR3QAvoeCjoznZFUA37opVUomqg1y RqsngBPbD9Dcp9od+Zkrgblx4B8LCSm7NqU3ZlDfAQBm1eZYrewNM2Bnu4FfMOVnh1w2 v7DQ== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr7979833lbf.24.1351174443104; Thu, 25 Oct 2012 07:14:03 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 25 Oct 2012 07:14:03 -0700 (PDT) In-Reply-To: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> References: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> Date: Thu, 25 Oct 2012 09:14:03 -0500 Message-ID: From: Mary Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=e0cb4efe2a0ab5f98104cce2d039 Cc: sipcore@ietf.org Subject: Re: [sipcore] "Gaps" in call flows 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, 25 Oct 2012 14:14:12 -0000 --e0cb4efe2a0ab5f98104cce2d039 Content-Type: text/plain; charset=ISO-8859-1 I believe the best and most appropriate approach is to include this in the application considerations section. The addition of the hi-entries is mechanical and it's not up to a proxy to determine validity of the information. I don't think we should add normative text around this. You need to keep in mind that one use case for HI is debug, so you really don't want to muck with the entries or synthesize the information so that it's compatible for a specific application. Note that even with the duplicates there is value in the ordering and it's up to an application to decide whether it needs the "last set of entries associated with a duplicate index or a previous set. My guess is that the last set would be the usual and again, we could add a note about that in the application considerations section. I think we need to be very careful about changing the normative text without a solid reason that is consistent with the intent of 4244bis which is described in the section summarizing the differences. I think complicating the creation of the index is a really bad idea and well beyond the intent of 4244 or 4244bis. Regards, Mary. On Wed, Oct 24, 2012 at 6:07 PM, Dale R. Worley wrote: > As I see it, the central pivot of the problem is this: What does a > proxy do when it receives a response that contains a "duplicate" > hi-entry? (That is, an hi-entry whose index is the same as in a > previously received hi-entry, but whose URI is different.) (The two > responses involved necessarily are generated by different forks made > by a non-supporting proxy, and will come from two different elements, > or at least, two different proxy transactions.) > > Actually, the problem is messier than a single duplicate hi-entry, as > each of the duplicate hi-entries can have "child" hi-entries. For > example, one response can contain: > > History-Info: ..., > ;index=1.1.0.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1.1, > ;index=1.1.0.1.1.2 > > and the other can contain: > > History-Info: ..., > ;index=1.1.0.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1.1 > > "At the top level", and are > duplicates, but they have the corresponding (with index 1.1.0.1.1.1) > child duplicates and , and the > hi-entry with index 1.1.0.1.1.2 is affected by the > duplication despite not being a duplicate itself. > > The first consideration is that we can't avoid the problem. All > proposals that have been discussed will cause this situation, at least > occasionally, when a supporting proxy forwards a request to a > non-supporting proxy, which forks the request to two supporting > elements. > > One alternative is for the RFC to say nothing about handling the > situation. This is dangerous, because the text leaves the strong > impression that the index of an hi-entry uniquely determines the URI, > and the needed processing naturally suggests using data structures > that depends on this uniqueness. So if we say nothing, it is likely > that implementations will crash when they encounter this problem. > > So we need to warn the implementer about this problem. There are two > obvious alternatives that an implementer can choose. > > One choice is for the implementation to keep one hi-entry and discard > the other hi-entry (and to discard the "child" hi-entries of that > other hi-entry). The cache is still keyed by the index values, but > when there is a duplication, one of the duplicate hi-entries is lost. > This approach loses information, but results in a History-Info header > that conforms to everyone's expectations. In the above example, the > History-Info in the proxy's response would be one of the two received > response History-Infos. > > The other choice is for the implementation to keep both hi-entries. > This requires a different data structure for the cache, and causes the > proxy to send History-Info that contain duplicate hi-entries. These > duplicate hi-entries in a single response create cascading > duplications upstream. This choice also raises the question of how > the hi-entries are to be ordered in History-Info, since the prescribed > tree preorder assumes that indexes are unique. > > In the above example, we could place the two index-1.1.0.1 hi-entries > as siblings and have their children follow in tree order: > > History-Info: ..., > ;index=1.1.0.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1.1, > ;index=1.1.0.1.1.2, > ;index=1.1.0.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1.1 > > or we could sort the hi-entries by their index values, which is what > the current text seems to demand: > > History-Info: ..., > ;index=1.1.0.1, > ;index=1.1.0.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1, > ;index=1.1.0.1.1.1, > ;index=1.1.0.1.1.1, > ;index=1.1.0.1.1.2 > > In any case, it becomes more difficult for a UAS application to > extract knowledge about the origin of the request that it received -- > if hi-entries are discarded, information is inevitably lost; if > duplicates are preserved, parameters referencing indexes are > inevitably ambiguous. > > It seems to be safer for the RFC to specify that one or the other > approach is required in proxies, so that all proxies handle duplicates > consistently, and applications can depend on that. > > It seems to be safer to require that the proxy discard one duplicate > (and all its children), because that approach never generates > History-Info values that contain duplicates -- there is less > information in History-Info, but the structure of History-Info is not > made more complex, and the way to interpret it is unambiguous. > > Regardless of how we prescribe that a proxy should handle duplicates, > it is clear that we want to minimize the chances of duplicates > happening, since duplicates unavoidably result in loss of information. > > Within this context, we can discuss how we would like to handle > "gaps", as that affects how often duplicates will be seen. > > One approach is to not mark gaps at all, which is the approach in RFC > 4244. This results in duplicates being generated every time a call > passes through the troublesome situation: a supporting proxy forwards > a request to a non-supporting proxy, which forks the request to two > supporting elements. Additionally, the existence of the gap is not > flagged at all. > > The approach in the draft is to represent gaps by inserting "0" as a > number in the index. This is an improvement relative to RFC 4244, > because the presence of gaps are marked explicitly, but it does not > reduce the number of duplicates: duplicates are generated by every > call that passes through the troublesome situation. > > Another approach is to represent gaps by a randomly-chosen number from > a suitably large range. If the specified range does not overlap the > branch numbers that are generated in normal situations, gaps are > flagged explicitly. In addition, the number of duplicates can be > reduced to whatever degree is desired, since duplicates only happen > when two random numbers happen to be the same -- with high > probability, even in the troublesome situation, two responses will not > not contain duplicates, and the proxy will assemble a History-Info > that unambiguously presents all the information that it received. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --e0cb4efe2a0ab5f98104cce2d039 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe the best and most appropriate approach is to include this in the = application considerations section. The addition of the hi-entries is mecha= nical and it's not up to a proxy to determine validity of the informati= on. =A0I don't think we should add normative text around this. =A0You n= eed to keep in mind that one use case for HI is debug, so you really don= 9;t want to muck with the entries or synthesize the information so that it&= #39;s compatible for a specific application. =A0Note that even with the dup= licates there is value in the ordering and it's up to an application to= decide whether it needs the "last set of entries associated with a du= plicate index or a previous set. =A0My guess is that the last set would be = the usual and again, we could add a note about that in the application cons= iderations section. =A0I think we need to be very careful about changing th= e normative text without a solid reason that is consistent with the intent = of 4244bis which is described in the section summarizing the differences. = =A0

I think complicating the creation of the index is a really b= ad idea and well beyond the intent of 4244 or 4244bis. =A0

Regards,
Mary.=A0

On Wed= , Oct 24, 2012 at 6:07 PM, Dale R. Worley <worley@ariadne.com> wrote:
As I see it, the central pivot of the proble= m is this: =A0What does a
proxy do when it receives a response that contains a "duplicate"<= br> hi-entry? =A0(That is, an hi-entry whose index is the same as in a
previously received hi-entry, but whose URI is different.) =A0(The two
responses involved necessarily are generated by different forks made
by a non-supporting proxy, and will come from two different elements,
or at least, two different proxy transactions.)

Actually, the problem is messier than a single duplicate hi-entry, as
each of the duplicate hi-entries can have "child" hi-entries. =A0= For
example, one response can contain:

=A0 =A0 History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <a.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <e.a.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <h.e.a.example.com>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <i.e.a.example.com>;index=3D1.1.0.1.1.2

and the other can contain:

=A0 =A0 History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <b.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <g.b.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <n.g.b.example.com>;index=3D1.1.0.1.1.1

"At the top level", <a.example.com> and <b.example.com> are
duplicates, but they have the corresponding (with index 1.1.0.1.1.1)
child duplicates <h.e.a.example.com> and <n.g.b.example.com>, and the
hi-entry with index 1.1.0.1.1.2 <i.e.a.example.com> is affected by the
duplication despite not being a duplicate itself.

The first consideration is that we can't avoid the problem. =A0All
proposals that have been discussed will cause this situation, at least
occasionally, when a supporting proxy forwards a request to a
non-supporting proxy, which forks the request to two supporting
elements.

One alternative is for the RFC to say nothing about handling the
situation. =A0This is dangerous, because the text leaves the strong
impression that the index of an hi-entry uniquely determines the URI,
and the needed processing naturally suggests using data structures
that depends on this uniqueness. =A0So if we say nothing, it is likely
that implementations will crash when they encounter this problem.

So we need to warn the implementer about this problem. =A0There are two
obvious alternatives that an implementer can choose.

One choice is for the implementation to keep one hi-entry and discard
the other hi-entry (and to discard the "child" hi-entries of that=
other hi-entry). =A0The cache is still keyed by the index values, but
when there is a duplication, one of the duplicate hi-entries is lost.
This approach loses information, but results in a History-Info header
that conforms to everyone's expectations. =A0In the above example, the<= br> History-Info in the proxy's response would be one of the two received response History-Infos.

The other choice is for the implementation to keep both hi-entries.
This requires a different data structure for the cache, and causes the
proxy to send History-Info that contain duplicate hi-entries. =A0These
duplicate hi-entries in a single response create cascading
duplications upstream. =A0This choice also raises the question of how
the hi-entries are to be ordered in History-Info, since the prescribed
tree preorder assumes that indexes are unique.

In the above example, we could place the two index-1.1.0.1 hi-entries
as siblings and have their children follow in tree order:

=A0 =A0 History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <a.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <e.a.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <h.e.a.example.com>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <i.e.a.example.com>;index=3D1.1.0.1.1.2,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <b.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <g.b.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <n.g.b.example.com>;index=3D1.1.0.1.1.1

or we could sort the hi-entries by their index values, which is what
the current text seems to demand:

=A0 =A0 History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <a.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <b.example.com>;index=3D1.1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <e.a.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <g.b.example.com>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <h.e.a.example.com>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <n.g.b.example.com>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <i.e.a.example.com>;index=3D1.1.0.1.1.2

In any case, it becomes more difficult for a UAS application to
extract knowledge about the origin of the request that it received --
if hi-entries are discarded, information is inevitably lost; if
duplicates are preserved, parameters referencing indexes are
inevitably ambiguous.

It seems to be safer for the RFC to specify that one or the other
approach is required in proxies, so that all proxies handle duplicates
consistently, and applications can depend on that.

It seems to be safer to require that the proxy discard one duplicate
(and all its children), because that approach never generates
History-Info values that contain duplicates -- there is less
information in History-Info, but the structure of History-Info is not
made more complex, and the way to interpret it is unambiguous.

Regardless of how we prescribe that a proxy should handle duplicates,
it is clear that we want to minimize the chances of duplicates
happening, since duplicates unavoidably result in loss of information.

Within this context, we can discuss how we would like to handle
"gaps", as that affects how often duplicates will be seen.

One approach is to not mark gaps at all, which is the approach in RFC
4244. =A0This results in duplicates being generated every time a call
passes through the troublesome situation: =A0a supporting proxy forwards a request to a non-supporting proxy, which forks the request to two
supporting elements. =A0Additionally, the existence of the gap is not
flagged at all.

The approach in the draft is to represent gaps by inserting "0" a= s a
number in the index. =A0This is an improvement relative to RFC 4244,
because the presence of gaps are marked explicitly, but it does not
reduce the number of duplicates: =A0duplicates are generated by every
call that passes through the troublesome situation.

Another approach is to represent gaps by a randomly-chosen number from
a suitably large range. =A0If the specified range does not overlap the
branch numbers that are generated in normal situations, gaps are
flagged explicitly. =A0In addition, the number of duplicates can be
reduced to whatever degree is desired, since duplicates only happen
when two random numbers happen to be the same -- with high
probability, even in the troublesome situation, two responses will not
not contain duplicates, and the proxy will assemble a History-Info
that unambiguously presents all the information that it received.

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

--e0cb4efe2a0ab5f98104cce2d039-- From pkyzivat@alum.mit.edu Thu Oct 25 09:19:05 2012 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 4148921F86E0 for ; Thu, 25 Oct 2012 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, 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 z-Nk5URvJAOH for ; Thu, 25 Oct 2012 09:19:04 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9021F8531 for ; Thu, 25 Oct 2012 09:19:04 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id FNzE1k0040bG4ec55UK96c; Thu, 25 Oct 2012 16:19:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id FUJr1k00F3ZTu2S3PUJrPa; Thu, 25 Oct 2012 16:18:51 +0000 Message-ID: <50896676.7050909@alum.mit.edu> Date: Thu, 25 Oct 2012 12:19:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210241948.q9OJm8Cw5219522@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 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, 25 Oct 2012 16:19:05 -0000 On 10/25/12 9:09 AM, Shida Schubert wrote: >> I seem to remember during the discussions there was a desire to not >> have History-Info sent in responses to a UAC if the UAC has not >> indicated support for H-I (by adding a History-Info header or >> "Supported: histinfo"). This was not to prevent the UAC from being >> "confused" by a header that it did not understand, but to prevent the >> last-hop response from being enlarged. >> >> RFC 4244 does not state a MUST that ensures this effect, although the >> text in section 4.3.2 suggests this. 4244bis does ensure this effect >> in section 9.4. > > Right.. There was some debate about UAS sending back all the > hi-entries with the MUST strength due to the concern about the message > size of the response. If the response was small enough to reach the proxy, then it should be small enough to reach the UAC. (It gets smaller with each hop due to removal of Via header fields.) I guess this might not be true if link characteristics are different, or if the first hop was UDP and the subsequent hops were TCP. But if PDU size is a concern, why isn't it a concern on every hop? Should there have been some dispensation that H-I can be pruned in responses if necessary to reduce PDU size? One concern I had was if the first proxy is dialog-stateless. Then it will have to go to extra work to remember that the H-I should not be passed in the response. (Dale remineded me that a stateless proxy can do this by putting a flag in its Via.) This wouldn't be such an issue if returning the H-I in this case is optional. Thanks, Paul (as individual) From pkyzivat@alum.mit.edu Thu Oct 25 09:22:47 2012 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 7E39421F88E8 for ; Thu, 25 Oct 2012 09:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 3ZxYK+MJ26hO for ; Thu, 25 Oct 2012 09:22:46 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id ECED621F89A0 for ; Thu, 25 Oct 2012 09:22:41 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id FUHW1k0060mv7h056UNl2q; Thu, 25 Oct 2012 16:22:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id FUNS1k00s3ZTu2S3XUNTHU; Thu, 25 Oct 2012 16:22:27 +0000 Message-ID: <5089674E.8090303@alum.mit.edu> Date: Thu, 25 Oct 2012 12:22:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] "Gaps" in call flows 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, 25 Oct 2012 16:22:47 -0000 On 10/25/12 10:14 AM, Mary Barnes wrote: > I believe the best and most appropriate approach is to include this in > the application considerations section. The addition of the hi-entries > is mechanical and it's not up to a proxy to determine validity of the > information. I don't think we should add normative text around this. > You need to keep in mind that one use case for HI is debug, so you > really don't want to muck with the entries or synthesize the information > so that it's compatible for a specific application. Note that even with > the duplicates there is value in the ordering and it's up to an > application to decide whether it needs the "last set of entries > associated with a duplicate index or a previous set. My guess is that > the last set would be the usual and again, we could add a note about > that in the application considerations section. Which set should be the "last set" among those with duplicate indexes? Thanks, Paul (as individual) > I think we need to be > very careful about changing the normative text without a solid reason > that is consistent with the intent of 4244bis which is described in the > section summarizing the differences. > > I think complicating the creation of the index is a really bad idea and > well beyond the intent of 4244 or 4244bis. > > Regards, > Mary. > > On Wed, Oct 24, 2012 at 6:07 PM, Dale R. Worley > wrote: > > As I see it, the central pivot of the problem is this: What does a > proxy do when it receives a response that contains a "duplicate" > hi-entry? (That is, an hi-entry whose index is the same as in a > previously received hi-entry, but whose URI is different.) (The two > responses involved necessarily are generated by different forks made > by a non-supporting proxy, and will come from two different elements, > or at least, two different proxy transactions.) > > Actually, the problem is messier than a single duplicate hi-entry, as > each of the duplicate hi-entries can have "child" hi-entries. For > example, one response can contain: > > History-Info: ..., > >;index=1.1.0.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1.1, > >;index=1.1.0.1.1.2 > > and the other can contain: > > History-Info: ..., > >;index=1.1.0.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1.1 > > "At the top level", > and > > are > duplicates, but they have the corresponding (with index 1.1.0.1.1.1) > child duplicates > and > >, and the > hi-entry with index 1.1.0.1.1.2 > is affected by the > duplication despite not being a duplicate itself. > > The first consideration is that we can't avoid the problem. All > proposals that have been discussed will cause this situation, at least > occasionally, when a supporting proxy forwards a request to a > non-supporting proxy, which forks the request to two supporting > elements. > > One alternative is for the RFC to say nothing about handling the > situation. This is dangerous, because the text leaves the strong > impression that the index of an hi-entry uniquely determines the URI, > and the needed processing naturally suggests using data structures > that depends on this uniqueness. So if we say nothing, it is likely > that implementations will crash when they encounter this problem. > > So we need to warn the implementer about this problem. There are two > obvious alternatives that an implementer can choose. > > One choice is for the implementation to keep one hi-entry and discard > the other hi-entry (and to discard the "child" hi-entries of that > other hi-entry). The cache is still keyed by the index values, but > when there is a duplication, one of the duplicate hi-entries is lost. > This approach loses information, but results in a History-Info header > that conforms to everyone's expectations. In the above example, the > History-Info in the proxy's response would be one of the two received > response History-Infos. > > The other choice is for the implementation to keep both hi-entries. > This requires a different data structure for the cache, and causes the > proxy to send History-Info that contain duplicate hi-entries. These > duplicate hi-entries in a single response create cascading > duplications upstream. This choice also raises the question of how > the hi-entries are to be ordered in History-Info, since the prescribed > tree preorder assumes that indexes are unique. > > In the above example, we could place the two index-1.1.0.1 hi-entries > as siblings and have their children follow in tree order: > > History-Info: ..., > >;index=1.1.0.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1.1, > >;index=1.1.0.1.1.2, > >;index=1.1.0.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1.1 > > or we could sort the hi-entries by their index values, which is what > the current text seems to demand: > > History-Info: ..., > >;index=1.1.0.1, > >;index=1.1.0.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1, > >;index=1.1.0.1.1.1, > >;index=1.1.0.1.1.1, > >;index=1.1.0.1.1.2 > > In any case, it becomes more difficult for a UAS application to > extract knowledge about the origin of the request that it received -- > if hi-entries are discarded, information is inevitably lost; if > duplicates are preserved, parameters referencing indexes are > inevitably ambiguous. > > It seems to be safer for the RFC to specify that one or the other > approach is required in proxies, so that all proxies handle duplicates > consistently, and applications can depend on that. > > It seems to be safer to require that the proxy discard one duplicate > (and all its children), because that approach never generates > History-Info values that contain duplicates -- there is less > information in History-Info, but the structure of History-Info is not > made more complex, and the way to interpret it is unambiguous. > > Regardless of how we prescribe that a proxy should handle duplicates, > it is clear that we want to minimize the chances of duplicates > happening, since duplicates unavoidably result in loss of information. > > Within this context, we can discuss how we would like to handle > "gaps", as that affects how often duplicates will be seen. > > One approach is to not mark gaps at all, which is the approach in RFC > 4244. This results in duplicates being generated every time a call > passes through the troublesome situation: a supporting proxy forwards > a request to a non-supporting proxy, which forks the request to two > supporting elements. Additionally, the existence of the gap is not > flagged at all. > > The approach in the draft is to represent gaps by inserting "0" as a > number in the index. This is an improvement relative to RFC 4244, > because the presence of gaps are marked explicitly, but it does not > reduce the number of duplicates: duplicates are generated by every > call that passes through the troublesome situation. > > Another approach is to represent gaps by a randomly-chosen number from > a suitably large range. If the specified range does not overlap the > branch numbers that are generated in normal situations, gaps are > flagged explicitly. In addition, the number of duplicates can be > reduced to whatever degree is desired, since duplicates only happen > when two random numbers happen to be the same -- with high > probability, even in the troublesome situation, two responses will not > not contain duplicates, and the proxy will assemble a History-Info > that unambiguously presents all the information that it received. > > 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 Thu Oct 25 12:57:55 2012 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 BADEA21F8782 for ; Thu, 25 Oct 2012 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 iSahXJUTuhF0 for ; Thu, 25 Oct 2012 12:57:54 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7121F8758 for ; Thu, 25 Oct 2012 12:57:53 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2140172lam.31 for ; Thu, 25 Oct 2012 12:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lHV/hcmoi2ejdhaIPcs3VKjaBuCQF78BVfZ413R7MTc=; b=Nq/PzjULse4dxgJMl6UHakGQkgLW+2rqUc1ML2HdBmhhEr5mRJ6LSQNneGo4QE3zKM A+FGfm3Pjj02Day9Z02NadnVZqGe22P5Nml+mUBnMIEIasmJyIl45+h78tpfAmgOzu0O w8MUtHRoLliPWq++avGhmPJRqQBKuJLhEVMoppB6btitMVrXolBf02zJaNAOxQhwdHBC vwcIKCHW0RIwdw9v7XlS3o5h2OruMYDVZwimAtv8/dQGG/v2K+aJgUzt6g6aTq3TP2Pl Zw6iBfntc9Yc6Po7DE8HB8cvoMoFYHuhsXM9k2EBG+M10fchpfH1cCu9zV8292gL8aMO rnTg== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr8356442lbf.24.1351195072548; Thu, 25 Oct 2012 12:57:52 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 25 Oct 2012 12:57:52 -0700 (PDT) In-Reply-To: <5089674E.8090303@alum.mit.edu> References: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> <5089674E.8090303@alum.mit.edu> Date: Thu, 25 Oct 2012 14:57:52 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e0cb4efe2a0a52509004cce79e16 Cc: sipcore@ietf.org Subject: Re: [sipcore] "Gaps" in call flows 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, 25 Oct 2012 19:57:55 -0000 --e0cb4efe2a0a52509004cce79e16 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 11:22 AM, Paul Kyzivat wrote: > On 10/25/12 10:14 AM, Mary Barnes wrote: > >> I believe the best and most appropriate approach is to include this in >> the application considerations section. The addition of the hi-entries >> is mechanical and it's not up to a proxy to determine validity of the >> information. I don't think we should add normative text around this. >> You need to keep in mind that one use case for HI is debug, so you >> really don't want to muck with the entries or synthesize the information >> so that it's compatible for a specific application. Note that even with >> the duplicates there is value in the ordering and it's up to an >> application to decide whether it needs the "last set of entries >> associated with a duplicate index or a previous set. My guess is that >> the last set would be the usual and again, we could add a note about >> that in the application considerations section. >> > > Which set should be the "last set" among those with duplicate indexes? > [MB] The hi-entries are added in order of the message processing which MUST be maintained per the requirements and per the definition of the index (same for 4244). We could add a note in that definition that it is possible in cases of gaps to have the same index but the chronological order must still be maintained. [/MB] > > Thanks, > Paul (as individual) > > I think we need to be >> very careful about changing the normative text without a solid reason >> that is consistent with the intent of 4244bis which is described in the >> section summarizing the differences. >> >> I think complicating the creation of the index is a really bad idea and >> well beyond the intent of 4244 or 4244bis. >> >> Regards, >> Mary. >> >> On Wed, Oct 24, 2012 at 6:07 PM, Dale R. Worley > > wrote: >> >> As I see it, the central pivot of the problem is this: What does a >> proxy do when it receives a response that contains a "duplicate" >> hi-entry? (That is, an hi-entry whose index is the same as in a >> previously received hi-entry, but whose URI is different.) (The two >> responses involved necessarily are generated by different forks made >> by a non-supporting proxy, and will come from two different elements, >> or at least, two different proxy transactions.) >> >> Actually, the problem is messier than a single duplicate hi-entry, as >> each of the duplicate hi-entries can have "child" hi-entries. For >> example, one response can contain: >> >> History-Info: ..., >> >;index=** >> 1.1.0.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1.1, >> > >;**index=1.1.0.1.1.2 >> >> >> and the other can contain: >> >> History-Info: ..., >> >;index=** >> 1.1.0.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1.1 >> >> "At the top level", > and >> > are >> >> duplicates, but they have the corresponding (with index 1.1.0.1.1.1) >> child duplicates > and >> >, and the >> >> hi-entry with index 1.1.0.1.1.2 > > is affected by the >> >> duplication despite not being a duplicate itself. >> >> The first consideration is that we can't avoid the problem. All >> proposals that have been discussed will cause this situation, at least >> occasionally, when a supporting proxy forwards a request to a >> non-supporting proxy, which forks the request to two supporting >> elements. >> >> One alternative is for the RFC to say nothing about handling the >> situation. This is dangerous, because the text leaves the strong >> impression that the index of an hi-entry uniquely determines the URI, >> and the needed processing naturally suggests using data structures >> that depends on this uniqueness. So if we say nothing, it is likely >> that implementations will crash when they encounter this problem. >> >> So we need to warn the implementer about this problem. There are two >> obvious alternatives that an implementer can choose. >> >> One choice is for the implementation to keep one hi-entry and discard >> the other hi-entry (and to discard the "child" hi-entries of that >> other hi-entry). The cache is still keyed by the index values, but >> when there is a duplication, one of the duplicate hi-entries is lost. >> This approach loses information, but results in a History-Info header >> that conforms to everyone's expectations. In the above example, the >> History-Info in the proxy's response would be one of the two received >> response History-Infos. >> >> The other choice is for the implementation to keep both hi-entries. >> This requires a different data structure for the cache, and causes the >> proxy to send History-Info that contain duplicate hi-entries. These >> duplicate hi-entries in a single response create cascading >> duplications upstream. This choice also raises the question of how >> the hi-entries are to be ordered in History-Info, since the prescribed >> tree preorder assumes that indexes are unique. >> >> In the above example, we could place the two index-1.1.0.1 hi-entries >> as siblings and have their children follow in tree order: >> >> History-Info: ..., >> >;index=** >> 1.1.0.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1.1, >> > >;**index=1.1.0.1.1.2, >> >;index=** >> 1.1.0.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1.1 >> >> >> or we could sort the hi-entries by their index values, which is what >> the current text seems to demand: >> >> History-Info: ..., >> >;index=** >> 1.1.0.1, >> >;index=** >> 1.1.0.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1, >> > >;**index=1.1.0.1.1.1, >> > >;**index=1.1.0.1.1.1, >> > >;**index=1.1.0.1.1.2 >> >> >> In any case, it becomes more difficult for a UAS application to >> extract knowledge about the origin of the request that it received -- >> if hi-entries are discarded, information is inevitably lost; if >> duplicates are preserved, parameters referencing indexes are >> inevitably ambiguous. >> >> It seems to be safer for the RFC to specify that one or the other >> approach is required in proxies, so that all proxies handle duplicates >> consistently, and applications can depend on that. >> >> It seems to be safer to require that the proxy discard one duplicate >> (and all its children), because that approach never generates >> History-Info values that contain duplicates -- there is less >> information in History-Info, but the structure of History-Info is not >> made more complex, and the way to interpret it is unambiguous. >> >> Regardless of how we prescribe that a proxy should handle duplicates, >> it is clear that we want to minimize the chances of duplicates >> happening, since duplicates unavoidably result in loss of information. >> >> Within this context, we can discuss how we would like to handle >> "gaps", as that affects how often duplicates will be seen. >> >> One approach is to not mark gaps at all, which is the approach in RFC >> 4244. This results in duplicates being generated every time a call >> passes through the troublesome situation: a supporting proxy forwards >> a request to a non-supporting proxy, which forks the request to two >> supporting elements. Additionally, the existence of the gap is not >> flagged at all. >> >> The approach in the draft is to represent gaps by inserting "0" as a >> number in the index. This is an improvement relative to RFC 4244, >> because the presence of gaps are marked explicitly, but it does not >> reduce the number of duplicates: duplicates are generated by every >> call that passes through the troublesome situation. >> >> Another approach is to represent gaps by a randomly-chosen number from >> a suitably large range. If the specified range does not overlap the >> branch numbers that are generated in normal situations, gaps are >> flagged explicitly. In addition, the number of duplicates can be >> reduced to whatever degree is desired, since duplicates only happen >> when two random numbers happen to be the same -- with high >> probability, even in the troublesome situation, two responses will not >> not contain duplicates, and the proxy will assemble a History-Info >> that unambiguously presents all the information that it received. >> >> Dale >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> >> >> >> >> >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> >> > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --e0cb4efe2a0a52509004cce79e16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2012 at 11:22 AM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
On 10/25/12 10:14 AM, Mary Barnes wrote:
I believe the best and most appropriate approach is to include this in
the application considerations section. The addition of the hi-entries
is mechanical and it's not up to a proxy to determine validity of the information. =A0I don't think we should add normative text around this.=
=A0 You need to keep in mind that one use case for HI is debug, so you
really don't want to muck with the entries or synthesize the informatio= n
so that it's compatible for a specific application. =A0Note that even w= ith
the duplicates there is value in the ordering and it's up to an
application to decide whether it needs the "last set of entries
associated with a duplicate index or a previous set. =A0My guess is that the last set would be the usual and again, we could add a note about
that in the application considerations section.

Which set should be the "last set" among those with duplicate ind= exes?
[MB] The hi-entries are added in order of the me= ssage processing which MUST be maintained per the requirements and per the = definition of the index (same for 4244). We could add a note in that defini= tion that it is possible in cases of gaps to have the same index but the ch= ronological order must still be maintained. =A0[/MB]

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul (as individual)

I think we need to be
very careful about changing the normative text without a solid reason
that is consistent with the intent of 4244bis which is described in the
section summarizing the differences.

I think complicating the creation of the index is a really bad idea and
well beyond the intent of 4244 or 4244bis.

Regards,
Mary.

On Wed, Oct 24, 2012 at 6:07 PM, Dale R. Worley <worley@ariadne.com
<mailto:worley@a= riadne.com>> wrote:

=A0 =A0 As I see it, the central pivot of the problem is this: =A0What does= a
=A0 =A0 proxy do when it receives a response that contains a "duplicat= e"
=A0 =A0 hi-entry? =A0(That is, an hi-entry whose index is the same as in a<= br> =A0 =A0 previously received hi-entry, but whose URI is different.) =A0(The = two
=A0 =A0 responses involved necessarily are generated by different forks mad= e
=A0 =A0 by a non-supporting proxy, and will come from two different element= s,
=A0 =A0 or at least, two different proxy transactions.)

=A0 =A0 Actually, the problem is messier than a single duplicate hi-entry, = as
=A0 =A0 each of the duplicate hi-entries can have "child" hi-entr= ies. =A0For
=A0 =A0 example, one response can contain:

=A0 =A0 =A0 =A0 =A0History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a.example.com <http://a.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<e.a.example.com
=A0 =A0 <http://e.a= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<h.e.a.example.com
=A0 =A0 <http://h= .e.a.example.com>>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<i.e.a.example.com
=A0 =A0 <http://i= .e.a.example.com>>;index=3D1.1.0.1.1.2

=A0 =A0 and the other can contain:

=A0 =A0 =A0 =A0 =A0History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<b.example.com <http://b.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<g.b.example.com
=A0 =A0 <http://g.b= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<n.g.b.example.com
=A0 =A0 <http://n= .g.b.example.com>>;index=3D1.1.0.1.1.1

=A0 =A0 "At the top level", <a.example.com <http://a.example.com>> and
=A0 =A0 <b.example.co= m <http://b.examp= le.com>> are

=A0 =A0 duplicates, but they have the corresponding (with index 1.1.0.1.1.1= )
=A0 =A0 child duplicates <h.e.a.example.com <http://h.e.a.example.com>> and
=A0 =A0 <n.g.b.ex= ample.com <ht= tp://n.g.b.example.com>>, and the

=A0 =A0 hi-entry with index 1.1.0.1.1.2 <i.e.a.example.com
=A0 =A0 <http://i= .e.a.example.com>> is affected by the

=A0 =A0 duplication despite not being a duplicate itself.

=A0 =A0 The first consideration is that we can't avoid the problem. =A0= All
=A0 =A0 proposals that have been discussed will cause this situation, at le= ast
=A0 =A0 occasionally, when a supporting proxy forwards a request to a
=A0 =A0 non-supporting proxy, which forks the request to two supporting
=A0 =A0 elements.

=A0 =A0 One alternative is for the RFC to say nothing about handling the =A0 =A0 situation. =A0This is dangerous, because the text leaves the strong=
=A0 =A0 impression that the index of an hi-entry uniquely determines the UR= I,
=A0 =A0 and the needed processing naturally suggests using data structures<= br> =A0 =A0 that depends on this uniqueness. =A0So if we say nothing, it is lik= ely
=A0 =A0 that implementations will crash when they encounter this problem.
=A0 =A0 So we need to warn the implementer about this problem. =A0There are= two
=A0 =A0 obvious alternatives that an implementer can choose.

=A0 =A0 One choice is for the implementation to keep one hi-entry and disca= rd
=A0 =A0 the other hi-entry (and to discard the "child" hi-entries= of that
=A0 =A0 other hi-entry). =A0The cache is still keyed by the index values, b= ut
=A0 =A0 when there is a duplication, one of the duplicate hi-entries is los= t.
=A0 =A0 This approach loses information, but results in a History-Info head= er
=A0 =A0 that conforms to everyone's expectations. =A0In the above examp= le, the
=A0 =A0 History-Info in the proxy's response would be one of the two re= ceived
=A0 =A0 response History-Infos.

=A0 =A0 The other choice is for the implementation to keep both hi-entries.=
=A0 =A0 This requires a different data structure for the cache, and causes = the
=A0 =A0 proxy to send History-Info that contain duplicate hi-entries. =A0Th= ese
=A0 =A0 duplicate hi-entries in a single response create cascading
=A0 =A0 duplications upstream. =A0This choice also raises the question of h= ow
=A0 =A0 the hi-entries are to be ordered in History-Info, since the prescri= bed
=A0 =A0 tree preorder assumes that indexes are unique.

=A0 =A0 In the above example, we could place the two index-1.1.0.1 hi-entri= es
=A0 =A0 as siblings and have their children follow in tree order:

=A0 =A0 =A0 =A0 =A0History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a.example.com <http://a.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<e.a.example.com
=A0 =A0 <http://e.a= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<h.e.a.example.com
=A0 =A0 <http://h= .e.a.example.com>>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<i.e.a.example.com
=A0 =A0 <http://i= .e.a.example.com>>;index=3D1.1.0.1.1.2,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<b.example.com <http://b.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<g.b.example.com
=A0 =A0 <http://g.b= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<n.g.b.example.com
=A0 =A0 <http://n= .g.b.example.com>>;index=3D1.1.0.1.1.1

=A0 =A0 or we could sort the hi-entries by their index values, which is wha= t
=A0 =A0 the current text seems to demand:

=A0 =A0 =A0 =A0 =A0History-Info: ...,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a.example.com <http://a.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<b.example.com <http://b.example.com>>;index=3D1.= 1.0.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<e.a.example.com
=A0 =A0 <http://e.a= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<g.b.example.com
=A0 =A0 <http://g.b= .example.com>>;index=3D1.1.0.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<h.e.a.example.com
=A0 =A0 <http://h= .e.a.example.com>>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<n.g.b.example.com
=A0 =A0 <http://n= .g.b.example.com>>;index=3D1.1.0.1.1.1,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<i.e.a.example.com
=A0 =A0 <http://i= .e.a.example.com>>;index=3D1.1.0.1.1.2


=A0 =A0 In any case, it becomes more difficult for a UAS application to
=A0 =A0 extract knowledge about the origin of the request that it received = --
=A0 =A0 if hi-entries are discarded, information is inevitably lost; if
=A0 =A0 duplicates are preserved, parameters referencing indexes are
=A0 =A0 inevitably ambiguous.

=A0 =A0 It seems to be safer for the RFC to specify that one or the other =A0 =A0 approach is required in proxies, so that all proxies handle duplica= tes
=A0 =A0 consistently, and applications can depend on that.

=A0 =A0 It seems to be safer to require that the proxy discard one duplicat= e
=A0 =A0 (and all its children), because that approach never generates
=A0 =A0 History-Info values that contain duplicates -- there is less
=A0 =A0 information in History-Info, but the structure of History-Info is n= ot
=A0 =A0 made more complex, and the way to interpret it is unambiguous.

=A0 =A0 Regardless of how we prescribe that a proxy should handle duplicate= s,
=A0 =A0 it is clear that we want to minimize the chances of duplicates
=A0 =A0 happening, since duplicates unavoidably result in loss of informati= on.

=A0 =A0 Within this context, we can discuss how we would like to handle
=A0 =A0 "gaps", as that affects how often duplicates will be seen= .

=A0 =A0 One approach is to not mark gaps at all, which is the approach in R= FC
=A0 =A0 4244. =A0This results in duplicates being generated every time a ca= ll
=A0 =A0 passes through the troublesome situation: =A0a supporting proxy for= wards
=A0 =A0 a request to a non-supporting proxy, which forks the request to two=
=A0 =A0 supporting elements. =A0Additionally, the existence of the gap is n= ot
=A0 =A0 flagged at all.

=A0 =A0 The approach in the draft is to represent gaps by inserting "0= " as a
=A0 =A0 number in the index. =A0This is an improvement relative to RFC 4244= ,
=A0 =A0 because the presence of gaps are marked explicitly, but it does not=
=A0 =A0 reduce the number of duplicates: =A0duplicates are generated by eve= ry
=A0 =A0 call that passes through the troublesome situation.

=A0 =A0 Another approach is to represent gaps by a randomly-chosen number f= rom
=A0 =A0 a suitably large range. =A0If the specified range does not overlap = the
=A0 =A0 branch numbers that are generated in normal situations, gaps are =A0 =A0 flagged explicitly. =A0In addition, the number of duplicates can be=
=A0 =A0 reduced to whatever degree is desired, since duplicates only happen=
=A0 =A0 when two random numbers happen to be the same -- with high
=A0 =A0 probability, even in the troublesome situation, two responses will = not
=A0 =A0 not contain duplicates, and the proxy will assemble a History-Info<= br> =A0 =A0 that unambiguously presents all the information that it received.
=A0 =A0 Dale
=A0 =A0 _______________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore





_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--e0cb4efe2a0a52509004cce79e16-- From pkyzivat@alum.mit.edu Thu Oct 25 13:51:53 2012 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 F2E4021F84D8 for ; Thu, 25 Oct 2012 13:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, 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 QiK5IFWAQOCb for ; Thu, 25 Oct 2012 13:51:52 -0700 (PDT) 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 3C20A21F84BB for ; Thu, 25 Oct 2012 13:51:50 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id FY6S1k0081ap0As53YrvVR; Thu, 25 Oct 2012 20:51:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id FYsR1k0113ZTu2S3iYsSHc; Thu, 25 Oct 2012 20:52:26 +0000 Message-ID: <5089A664.2010804@alum.mit.edu> Date: Thu, 25 Oct 2012 16:51:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mary Barnes References: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> <5089674E.8090303@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] "Gaps" in call flows 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, 25 Oct 2012 20:51:53 -0000 On 10/25/12 3:57 PM, Mary Barnes wrote: > > > On Thu, Oct 25, 2012 at 11:22 AM, Paul Kyzivat > wrote: > > On 10/25/12 10:14 AM, Mary Barnes wrote: > > I believe the best and most appropriate approach is to include > this in > the application considerations section. The addition of the > hi-entries > is mechanical and it's not up to a proxy to determine validity > of the > information. I don't think we should add normative text around > this. > You need to keep in mind that one use case for HI is debug, > so you > really don't want to muck with the entries or synthesize the > information > so that it's compatible for a specific application. Note that > even with > the duplicates there is value in the ordering and it's up to an > application to decide whether it needs the "last set of entries > associated with a duplicate index or a previous set. My guess > is that > the last set would be the usual and again, we could add a note about > that in the application considerations section. > > > Which set should be the "last set" among those with duplicate indexes? > > [MB] The hi-entries are added in order of the message processing which > MUST be maintained per the requirements and per the definition of the > index (same for 4244). We could add a note in that definition that it is > possible in cases of gaps to have the same index but the chronological > order must still be maintained. [/MB] My point is that the order will end up being arbitrary. IIUC, to get duplicates, the forking must have occurred in a proxy that doesn't support H-I. The duplicates will come in responses. The node detecting the duplicates will only know in which order it received the responses, but not the order in which the requests that yielded those responses were sent. Meanwhile, AFAIK the ordering by nodes supporting H-I will be by when the requests were sent. Maybe it doesn't matter - it really is arbitrary. But nobody should be deluded into thinking that the order among duplicates has any significance. Thanks, Paul From mary.ietf.barnes@gmail.com Thu Oct 25 14:30:40 2012 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 70E4921F85C0 for ; Thu, 25 Oct 2012 14:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.395 X-Spam-Level: X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 i2ZMhczJoOHN for ; Thu, 25 Oct 2012 14:30:38 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BECA421F8589 for ; Thu, 25 Oct 2012 14:30:37 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2245577lam.31 for ; Thu, 25 Oct 2012 14:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+6T7ffcFyNAUG2BFiQueo6W6+oQUinOA2z7xwAxvnE=; b=Gtj1pWfXR6y4+66BpobfJMdOCtmCDBQiPbwhVRmBibnVz7ScZru1iY5d9g4cvyFUp/ Z2d/MTVQTly9e/joQPiAZwJ/KGpDViG+Hvf+rcXJ97XRUm4UMzgZTzg0tzScMq/7cEzy +Y85YYOD9wqp8VVxnnqliY5XE7cZVrfrXSxYtZTHuEgR0BuV6HgutfguisAZrjH1igXQ PHe7Jtfz56dAcugvJRjI/v3K0iHo57ghrhTyg7gcyp70F1vaGlXuabZC3iriStMnYkBv 7K5XBHGtECxH08+W44eWQha2z6EiOqHrEW312H8hOo+tUPyH7mwVNyvQfu0/gmskuwnJ NgAA== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr8277506lbo.122.1351200636714; Thu, 25 Oct 2012 14:30:36 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 25 Oct 2012 14:30:36 -0700 (PDT) In-Reply-To: <5089A664.2010804@alum.mit.edu> References: <201210242307.q9ON7PpY5229025@shell01.TheWorld.com> <5089674E.8090303@alum.mit.edu> <5089A664.2010804@alum.mit.edu> Date: Thu, 25 Oct 2012 16:30:36 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0401fe59f8c08704cce8e995 Cc: sipcore@ietf.org Subject: Re: [sipcore] "Gaps" in call flows 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, 25 Oct 2012 21:30:40 -0000 --f46d0401fe59f8c08704cce8e995 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 3:51 PM, Paul Kyzivat wrote: > On 10/25/12 3:57 PM, Mary Barnes wrote: > >> >> >> On Thu, Oct 25, 2012 at 11:22 AM, Paul Kyzivat > **> wrote: >> >> On 10/25/12 10:14 AM, Mary Barnes wrote: >> >> I believe the best and most appropriate approach is to include >> this in >> the application considerations section. The addition of the >> hi-entries >> is mechanical and it's not up to a proxy to determine validity >> of the >> information. I don't think we should add normative text around >> this. >> You need to keep in mind that one use case for HI is debug, >> so you >> really don't want to muck with the entries or synthesize the >> information >> so that it's compatible for a specific application. Note that >> even with >> the duplicates there is value in the ordering and it's up to an >> application to decide whether it needs the "last set of entries >> associated with a duplicate index or a previous set. My guess >> is that >> the last set would be the usual and again, we could add a note >> about >> that in the application considerations section. >> >> >> Which set should be the "last set" among those with duplicate indexes? >> >> [MB] The hi-entries are added in order of the message processing which >> MUST be maintained per the requirements and per the definition of the >> index (same for 4244). We could add a note in that definition that it is >> possible in cases of gaps to have the same index but the chronological >> order must still be maintained. [/MB] >> > > My point is that the order will end up being arbitrary. > IIUC, to get duplicates, the forking must have occurred in a proxy that > doesn't support H-I. The duplicates will come in responses. The node > detecting the duplicates will only know in which order it received the > responses, but not the order in which the requests that yielded those > responses were sent. Meanwhile, AFAIK the ordering by nodes supporting H-I > will be by when the requests were sent. > [MB2] If the forking comes from nodes that don't support HI then an application that needs 4244bis compliant entries would just ignore those or provide limited functionality.[/MB2] Maybe it doesn't matter - it really is arbitrary. But nobody should be > deluded into thinking that the order among duplicates has any significance. > [MB] In the case of forking, the order is always arbitrary in the responses. There's no way around that - again we're dealing with the lack of consistency with forking in SIP. HI is only as deterministic/consistent as SIP message ordering itself.[/MB] > > Thanks, > Paul > > --f46d0401fe59f8c08704cce8e995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2012 at 3:51 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
On 10/25/12 3:57 PM, Mary Barnes wrote:


On Thu, Oct 25, 2012 at 11:22 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
=
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 On 10/25/12 10:14 AM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 I believe the best and most appropriate approach is to incl= ude
=A0 =A0 =A0 =A0 this in
=A0 =A0 =A0 =A0 the application considerations section. The addition of the=
=A0 =A0 =A0 =A0 hi-entries
=A0 =A0 =A0 =A0 is mechanical and it's not up to a proxy to determine v= alidity
=A0 =A0 =A0 =A0 of the
=A0 =A0 =A0 =A0 information. =A0I don't think we should add normative t= ext around
=A0 =A0 =A0 =A0 this.
=A0 =A0 =A0 =A0 =A0 =A0You need to keep in mind that one use case for HI is= debug,
=A0 =A0 =A0 =A0 so you
=A0 =A0 =A0 =A0 really don't want to muck with the entries or synthesiz= e the
=A0 =A0 =A0 =A0 information
=A0 =A0 =A0 =A0 so that it's compatible for a specific application. =A0= Note that
=A0 =A0 =A0 =A0 even with
=A0 =A0 =A0 =A0 the duplicates there is value in the ordering and it's = up to an
=A0 =A0 =A0 =A0 application to decide whether it needs the "last set o= f entries
=A0 =A0 =A0 =A0 associated with a duplicate index or a previous set. =A0My = guess
=A0 =A0 =A0 =A0 is that
=A0 =A0 =A0 =A0 the last set would be the usual and again, we could add a n= ote about
=A0 =A0 =A0 =A0 that in the application considerations section.


=A0 =A0 Which set should be the "last set" among those with dupli= cate indexes?

[MB] The hi-entries are added in order of the message processing which
MUST be maintained per the requirements and per the definition of the
index (same for 4244). We could add a note in that definition that it is possible in cases of gaps to have the same index but the chronological
order must still be maintained. =A0[/MB]

My point is that the order will end up being arbitrary.
IIUC, to get duplicates, the forking must have occurred in a proxy that doe= sn't support H-I. The duplicates will come in responses. The node detec= ting the duplicates will only know in which order it received the responses= , but not the order in which the requests that yielded those responses were= sent. Meanwhile, AFAIK the ordering by nodes supporting H-I will be by whe= n the requests were sent.
[MB2] =A0If the forking comes from nodes that don't s= upport HI then an application that needs 4244bis compliant entries would ju= st ignore those or provide limited functionality.[/MB2] =A0

<= /div>
Maybe it doesn't matter - it really is arbitrary. But nobody should be = deluded into thinking that the order among duplicates has any significance.=
[MB] In the case of forking, the order is always arbi= trary in the responses. =A0There's no way around that - again we're= dealing with the lack of consistency with forking in SIP. =A0HI is only as= deterministic/consistent as SIP message ordering itself.[/MB] =A0

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


--f46d0401fe59f8c08704cce8e995--