From internet-drafts@ietf.org Tue Dec 3 07:05:54 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA621AE18A; Tue, 3 Dec 2013 07:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y26d7_DuuOkY; Tue, 3 Dec 2013 07:05:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 852101AE182; Tue, 3 Dec 2013 07:05:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131203150552.2985.52602.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 07:05:52 -0800 Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-loop-detection-03.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:05:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sip Traversal Required for Applications t= o Work Working Group of the IETF. Title : Loop Detection Mechanisms for Session Initiation Protoco= l (SIP) Back-to- Back User Agents (B2BUAs) Author(s) : Hadriel Kaplan Victor Pascual Filename : draft-ietf-straw-b2bua-loop-detection-03.txt Pages : 6 Date : 2013-12-03 Abstract: SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-loop-detection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu Dec 5 09:39:52 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D971AE0C9 for ; Thu, 5 Dec 2013 09:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dddyrqI1gfb5 for ; Thu, 5 Dec 2013 09:39:51 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 05A561A1F66 for ; Thu, 5 Dec 2013 09:39:50 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id xoMq1m0020QuhwU5FtfnSA; Thu, 05 Dec 2013 17:39:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id xtfm1m00K3ZTu2S3Ntfmih; Thu, 05 Dec 2013 17:39:46 +0000 Message-ID: <52A0BA62.7070203@alum.mit.edu> Date: Thu, 05 Dec 2013 12:39:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: straw@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C55DF6C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55DF6C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386265187; bh=VQ3qrCoBYv+xiDn4lXHrd7FqsrKiGA2m0ThtRjU5ecc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TVB48AiXeZvWQU40TAX99Hwmt/k32kpNEYLFrdlyAAJ0ewewHtqapqd6egmU48iCO I5kLZsQGIzQQkm9ChGrAMUa1u43629DfR4VDCC4P38qlrKPD3cUT/RiirOQR+jZMJZ 3a00LlBU+qFYcvfaKrozJXOHuZFzT0WmVj2ws8bZ3J5+Oz2C39vHv183UtgG22cHdg rLvWhovGFY5Z1uL6OyL/Vza1JEoTuhO3w9aGF/2ZkEFfbvuL9c855wZk/MR8i2j+No XS6R9AlnyJaH1w0vHtSxriqPxIyHD6Eh7LKYi5bBypAInD3DZ45p0Vg0OVEdLQ/XHV E7AvUi30UYLjQ== Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:39:52 -0000 I provided my WGLC comments early: http://www.ietf.org/mail-archive/web/straw/current/msg00190.html Those still apply. I followed that one up with another comment I forgot, but for some reason I don't find it in the archives. So I'll repeat that one: One more thing I forgot: The IANA Considerations need to be updated. Get rid of "yet ..." Thanks, Paul On 11/27/13 8:22 AM, Christer Holmberg wrote: > (As co-chair) > > Hi, > > We could like to initiate WGLC for draft-ietf-straw-sip-traceroute-01.txt. > > We already earlier indicated that we will initiate the WGLC after > Vancouver, and got some very good comments. > > We will consider those as WGLC comments, but we of course encourage more > people to review the draft. Even if You read the document, and don’t > have any comments, it’s good to indicate that. > > Please provide any comments by Friday 13^th December (no, the choice of > that date was a pure coincidence :) > > Regards, > > Christer & Victor > > > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw > From gsalguei@cisco.com Wed Dec 11 09:33:23 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046341ADF9C for ; Wed, 11 Dec 2013 09:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PymTCPgi4Wn4 for ; Wed, 11 Dec 2013 09:33:20 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 200621ADF84 for ; Wed, 11 Dec 2013 09:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1386783194; x=1387992794; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=5uK6TylTd+XAM9xhY18lX8OuLuMNf1yWa/6NCBVtUk0=; b=CEY9PYudlaJdfu8DdxLv0LvszkIAtcbvj7B+Aor8fJrEndvyYVZbKavd J2CmTZkZtJPT2YCFIlPNS/uGeH07beuq+b06AfaEEhc2YBva/wyhqJKXG L9FbrYpIq4W/51TuGxbCRgVT5mRPCf8byi9u0hfeL4qppIR/S9gLUThYl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAKagqFKtJV2a/2dsb2JhbABZgwc4U7hLToEdFm0HgiUBAQEDAQEBATc0EAsCARkDAQIfECcLGwIIAQEEEwmHcwYNwi4XjiYQAgFRC4MbgRMEmBSSE4Mpgio X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208";a="6040704" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 11 Dec 2013 17:33:14 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBBHXEAS022182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Dec 2013 17:33:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 11:33:13 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "straw@ietf.org" Thread-Topic: [sipcore] draft-ietf-straw-sip-traceroute-01: WGLC comments Thread-Index: Ac72j7SabFUxvCuYTzG4rWshBxRIKA== Date: Wed, 11 Dec 2013 17:33:13 +0000 Message-ID: References: <576A8B541C219D4E9CEB1DF8C19C7B881A06D77E@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B9916D37C51204A99DAEFDA50C7DC56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [straw] Fwd: [sipcore] draft-ietf-straw-sip-traceroute-01: WGLC comments X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:33:23 -0000 Moving to straw@ list. Gonzalo Begin forwarded message: > From: Brett Tate > Subject: [sipcore] draft-ietf-straw-sip-traceroute-01: WGLC comments > Date: December 11, 2013 at 11:42:28 AM EST > To: "draft-ietf-straw-sip-traceroute@tools.ietf.org" , "sipcore@ietf.org" >=20 > Hi, >=20 > The following are some comments concerning draft-ietf-straw-sip-tracerout= e-01. >=20 > Thanks, > Brett >=20 > ------- >=20 > Section 3: >=20 > - B2bua-Hops should be Max-Forwards. >=20 > Section 3.2 paragraph 1: >=20 > - Potentially could clarify that the middle box is answering because of M= ax-Forwards 0 (instead of answering for another reason). >=20 > Section 3.2 paragraph 2: >=20 > - As discussed within the following email, I agree that requiring a speci= fic reason-text value might not desirable. This is because I view the text= parameter to be similar to the status-line's reason-phrase. If something = is needed instead of just 483 for automation reasons, the reason-params pot= entially could be expanded to include a new parameter such as "traceroute". >=20 > http://www.ietf.org/mail-archive/web/straw/current/msg00194.html >=20 >=20 > Section 7: >=20 > - [RFC3261] should be added; it is referenced within section 3.1. >=20 >=20 > This email is intended solely for the person or entity to which it is add= ressed and may contain confidential and/or privileged information. If you a= re not the intended recipient and have received this email in error, please= notify BroadSoft, Inc. immediately by replying to this message, and destro= y all copies of this message, along with any attachment, prior to reading, = distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Peter.Dawes@vodafone.com Fri Dec 13 01:31:10 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC511ADFD4 for ; Fri, 13 Dec 2013 01:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUYDvZujXZS7 for ; Fri, 13 Dec 2013 01:31:01 -0800 (PST) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by ietfa.amsl.com (Postfix) with ESMTP id 060351A802A for ; Fri, 13 Dec 2013 01:31:00 -0800 (PST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailout04.vodafone.com (Postfix) with ESMTP id 3A0118138A for ; Fri, 13 Dec 2013 10:30:35 +0100 (CET) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 2C6A481116 for ; Fri, 13 Dec 2013 10:30:35 +0100 (CET) Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 13 Dec 2013 10:30:34 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.127]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0146.002; Fri, 13 Dec 2013 10:30:33 +0100 From: "Dawes, Peter, Vodafone Group" To: "straw@ietf.org" Thread-Topic: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt Thread-Index: Ac73QNFEogX/74Y5RMufOLj8QOzw5g== Date: Fri, 13 Dec 2013 09:30:33 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789VOEXM31Winterna_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Dec 2013 05:19:08 -0800 Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 09:31:10 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789VOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I reviewed draft-ietf-straw-sip-traceroute-01.txt for WGLC and I have the c= omments below. The text from the draft that a comment refers to is copied a= bove the comments without any changes. Any suggested changes are below the = comment. Regards, Peter [draft text 1: clause 2. Introduction (lines 121 - 127)] In many deployments, the media for SIP-created sessions does not flow direc= tly from the originating user's UAC to the answering user's UAS. Often, S= IP B2BUAs in the SIP signaling path participate in the media plane, either = for injecting media such as rich-ringtones or music-on-hold, or for relayin= g media in order to provide functions such as transcoding, IPv4-IPv6 conver= sion, NAT traversal, SRTP termination, media steering, etc . [comment 1: It would be helpful to indicate how the B2BUA participates in t= he media plane with the text such as below] In many deployments, the media for SIP-created sessions does not flow direc= tly from the originating user's UAC to the answering user's UAS. Often, SI= P B2BUAs in the SIP signaling path also insert themselves in the media plan= e path by manipulating SDP, either for injecting media such as rich-rington= es or music-on-hold, or for relaying media in order to provide functions su= ch as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, m= edia steering, etc . [draft text 2: clause 2. Introduction (line 135)] If failures or degradation occurs in the media plane [comment 2: Typo, change as below] If failures or degradation occur in the media plane, [draft text 3: clause 2. Introduction (line 137)] to aid managing and troubleshooting SIP-based sessions and media crossing s= uch B2BUAs, it would be useful to be able to test the media path to each B2= BUA separately from the source. [comment 3: Unclear what the word "separately refers to. Suggested re-wordi= ng below] to aid managing and troubleshooting SIP-based sessions and media crossing s= uch B2BUAs, it would be useful to be able to progressively test the media p= ath as it reaches successive B2BUAs with a test controlled in a single-ende= d way from the source UA. [draft text 4: clause 2. Introduction (lines 139 - 144)] A mechanism to perform media-loopback test sessions has been defined in [RF= C6849], but it would be difficult to use the mechanism directly to test B2B= UAs because typically the B2BUAs do not have an Address of Record (AoR) to = be targeted, nor is it known a priori which B2BUAs will be crossed for any = given session. [comment 4: I guess that the existing mechanism cannot be used. Suggested r= e-wording below] A mechanism to perform media-loopback test sessions has been defined in [RF= C6849], but it cannot be used to directly to test B2BUAs because typically = the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it= known a priori which B2BUAs will be crossed for any given session. [draft text 5: clause 2. Introduction (lines 151 - 155)] A better solution would be to make a test call targeted to Bob, but with a = SIP traceroute-type mechanism that makes the call terminate at the B2BUAs, = such that she can perform test sessions to test the media path to each down= stream B2BUA . [comment 5: With one test call after another, will the media always take th= e same path?] [draft text 6: clause 2. Introduction (lines 157 - 169)] This document defines how such a mechanism can be employed, using the [RFC6= 849] mechanism along with the Max-Forwards SIP header field such that a SIP= User Agent can make multiple test calls, each reaching a B2BUA further dow= nstream. Each B2BUA in the path that supports this mechanism would answer t= he media-loopback call, and thus the originating SIP UA can test the media = path up to that B2BUA. [comment 6: Not clear what "this mechanism" refers to. Suggested re-wording= below] supports the mechanism in [RFC6849] would answer the media-loopback call , = and [draft text 7: clause 2. Introduction (lines 189 - 195)] The originating UAC can then generate another INVITE to the same target AoR= with a B2bua-Hops header value of 1 , which will reach the second B2BUA th= at supports this mechanism, and so on. A defined [RFC3326] SIP Reason head= er field cause value will be in the 200 answer from each B2BUA answering th= e INVITE, until the INVITE reaches the final UAS, which does not use the Re= ason cause value. (see Section 3.2 for details) [comment 7: If for example the signalling follows a path B2BUA-Proxy-B2BUA = then a hops value of 1 will reach the proxy not the next B2BUA.] [draft text 8: clause 3.1 Processing a Received Max-Forwards Header Field (= lines 206 - 208)] As currently defined in [RFC3261], the UAS half of a B2BUA does not technic= ally need to inspect the Max-Forwards header field value for received reque= sts - only Proxies do. [comment 8: The word "technically" suggests some doubt about whether an RFC= 3261 compliant B2BUA decrements the Max-Forwards header field or not. Sugg= ested re-wording below] [RFC3261] requires proxies to inspect the Max-Forwards header field but not= a B2BUA. [draft text 9: clause 3.2. Answering the INVITE] [comment 9: It is possible for a Max-Forwards header field value to fall to= zero for a call that is not a test call. A B2BUA that supports this draft = would answer such a call, which would be unexpected behaviour as far as the= calling party is concerned. How is this avoided?] [draft text 10: clause 5. IANA Considerations] [comment 10: Nothing stops another mechanism using the Reason text "Tracero= ute Response" as this is not in any IANA registry so the mechanism should n= ot depend on Reason text.] [draft text 11: clause 3. The SIP Traceroute Mechanism] [comment 11: How the mechanism works would be clearer if clause 3. had indi= vidual sub-clauses that describe the specific behaviour of a UAC, Proxy, B2= BUA, and UAS.] --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789VOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

I reviewed draft-ietf-straw-sip-traceroute-01.txt fo= r WGLC and I have the comments below. The text from the draft that a commen= t refers to is copied above the comments without any changes. Any suggested= changes are below the comment.

 

Regards,

Peter

 

[draft text 1: clause 2. Introduction (lines 121 - 1= 27)]

In many deployments, the media for SIP-created sessi= ons does not flow directly from the originating user's UAC to the answering=   user's UAS.  Often, SIP B2BUAs in the SIP signaling path partic= ipate in the media plane, either for injecting media such as rich-ringtones or music-on-hold, or for relaying media in or= der to provide functions such as transcoding, IPv4-IPv6 conversion, NAT tra= versal, SRTP termination, media steering, etc .

 

[comment 1: It would be helpful to indicate how the = B2BUA participates in the media plane with the text such as below]

In many deployments, the media for SIP-created sessi= ons does not flow directly from the originating user's UAC to the answering= user's UAS.  Often, SIP B2BUAs in the SIP signaling path also insert = themselves in the media plane path by manipulating SDP, either for injecting media such as rich-ringtones or music-on-hold, o= r for relaying media in order to provide functions such as transcoding, IPv= 4-IPv6 conversion, NAT traversal, SRTP termination, media steering, etc .

 

 

 

[draft text 2: clause 2. Introduction (line 135)]

If failures or degradation occurs in the media plane=

 

[comment 2: Typo, change as below]

If failures or degradation occur in the media plane,=

 

 

 

[draft text 3: clause 2. Introduction (line 137)]

to aid managing and troubleshooting SIP-based sessio= ns and media crossing such B2BUAs, it would be useful to be able to test th= e media path to each B2BUA separately from the source.

 

[comment 3: Unclear what the word "separately r= efers to. Suggested re-wording below]

to aid managing and troubleshooting SIP-based sessio= ns and media crossing such B2BUAs, it would be useful to be able to progres= sively test the media path as it reaches successive B2BUAs with a test cont= rolled in a single-ended way from the source UA.

 

 

 

[draft text 4: clause 2. Introduction (lines 139 - 1= 44)]

A mechanism to perform media-loopback test sessions = has been defined in [RFC6849], but it would be difficult to use the mechani= sm directly to test B2BUAs because typically the B2BUAs do not have an Addr= ess of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given sessio= n.

 

[comment 4: I guess that the existing mechanism cann= ot be used. Suggested re-wording below]

A mechanism to perform media-loopback test sessions = has been defined in [RFC6849], but it cannot be used to directly to test B2= BUAs because typically the B2BUAs do not have an Address of Record (AoR) to= be targeted, nor is it known a priori which B2BUAs will be crossed for any given session.

 

 

 

[draft text 5: clause 2. Introduction (lines 151 - 1= 55)]

A better solution would be to make a test call targe= ted to Bob, but with a SIP traceroute-type mechanism that makes the call te= rminate at the B2BUAs, such that she can perform test sessions to test the = media path to each downstream B2BUA .

 

[comment 5: With one test call after another, will t= he media always take the same path?]

 

 

 

[draft text 6: clause 2. Introduction (lines 157 - 1= 69)]

This document defines how such a mechanism can be em= ployed, using the [RFC6849] mechanism along with the Max-Forwards SIP heade= r field such that a SIP User Agent can make multiple test calls, each reach= ing a B2BUA further downstream. Each B2BUA in the path that supports this mechanism would answer the media-loop= back call, and thus the originating SIP UA can test the media path up to th= at B2BUA.

 

[comment 6: Not clear what "this mechanism"= ; refers to. Suggested re-wording below]

supports the mechan= ism in [RFC6849] would answer the media-loopback call , and

 

 

 

[draft text 7: clause 2. Introduction (lines 189 - 1= 95)]

The originating UAC= can then generate another INVITE to the same target AoR with a B2bua-Hops = header value of 1 , which will reach the second B2BUA that supports this me= chanism, and so on.  A defined [RFC3326] SIP Reason header field cause value will be in the 200 answer from each B2= BUA answering the INVITE, until the INVITE reaches the final UAS, which doe= s not use the Reason cause value. (see Section 3.2 for details)=

 

[comment 7: If for example the signalling follows a = path B2BUA-Proxy-B2BUA then a hops value of 1 will reach the proxy not the = next B2BUA.]

 

 

 

[draft text 8: clause 3.1 Processing a Received Max-= Forwards Header Field (lines 206 - 208)]

As currently defined in [RFC3261], the UAS half of a= B2BUA does not technically need to inspect the Max-Forwards header field v= alue for received requests - only Proxies do.

 

[comment 8: The word "technically" suggest= s some doubt about whether an RFC 3261 compliant B2BUA decrements the Max-F= orwards header field or not. Suggested re-wording below]

[RFC3261] requires proxies to inspect the Max-Forwar= ds header field but not a B2BUA.

 

 

 

[draft text 9: clause 3.2. Answering the INVITE]

 

[comment 9: It is possible for a Max-Forwards header= field value to fall to zero for a call that is not a test call. A B2BUA th= at supports this draft would answer such a call, which would be unexpected = behaviour as far as the calling party is concerned. How is this avoided?]

 

 

 

[draft text 10: clause 5. IANA Considerations]<= /o:p>

 

[comment 10: Nothing stops another mechanism using t= he Reason text "Traceroute Response" as this is not in any IANA r= egistry so the mechanism should not depend on Reason text.]

 

 

 

[draft text 11: clause 3. The SIP Traceroute Mechani= sm]

 

[comment 11: How the mechanism works would be cleare= r if clause 3. had individual sub-clauses that describe the specific behavi= our of a UAC, Proxy, B2BUA, and UAS.]

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789VOEXM31Winterna_-- From christer.holmberg@ericsson.com Fri Dec 13 06:16:39 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802371AE2B4 for ; Fri, 13 Dec 2013 06:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvHixMr-DH5B for ; Fri, 13 Dec 2013 06:16:37 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6A61AE2B0 for ; Fri, 13 Dec 2013 06:16:35 -0800 (PST) X-AuditID: c1b4fb32-b7f108e0000030dd-04-52ab16bc6418 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 78.CA.12509.CB61BA25; Fri, 13 Dec 2013 15:16:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.26]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0347.000; Fri, 13 Dec 2013 15:16:25 +0100 From: Christer Holmberg To: "Dawes, Peter, Vodafone Group" , "straw@ietf.org" Thread-Topic: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt Thread-Index: AQHO+A3nlMNXKGDD80KNNj5gSWpk9Q== Date: Fri, 13 Dec 2013 14:16:24 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_uykptk274j9d1gmq6kqr9mt31386944184840emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre4esdVBBhO/Klj0vfzCZHGr+TGr A5PHkiU/mTz6ZqxnDGCK4rJJSc3JLEst0rdL4MqY9H0/Y8G3JsaKExddGhj7crsYOTkkBEwk etpuMEPYYhIX7q1n62Lk4hASOMEo8fbiSnYIZzGjxJKjnYxdjBwcbAIWEt3/tEEaRASSJDbP Ps8GEhYWcJFYti4XIuwq8eLUDzYIW09i0rQ5TCAlLAKqEteOV4OYvAJuEnOucYFUCAmESlxd NIERxOYUCJOYsK2DCcRmBLrm+6k1YDazgLjErSfzmSCuFJBYsuc81MWiEi8f/2OFqMmR+Pnn CtgcXgFBiZMzn7BMYBSehaR9FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG yeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMAIOrjlt9EOxpN77A8xSnOwKInzXmetCRIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyCsz+b1EVuoV49u1T+PFJ617/dFof1USSzS36zdN pTXxzpd5rA4x7X3LeWYpy+Kl2gWSkxnf9IW7d8UosrzyqW23n8Ch0iuveviYjrPg+ot6tnsj P86QOlz4ImtuWbvnbN7PMnxTFF6IvnvBckahep76ftNJU6RPtK7696Pp/cX4btXtu+PKlViK MxINtZiLihMBtNdFvG4CAAA= Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:16:39 -0000 --_000_uykptk274j9d1gmq6kqr9mt31386944184840emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi Peter, Thank You very much for the review! Regards, Christer Sent from my Sony Ericsson Xperia arc S "Dawes, Peter, Vodafone Group" wrote: Hello All, I reviewed draft-ietf-straw-sip-traceroute-01.txt for WGLC and I have the c= omments below. The text from the draft that a comment refers to is copied a= bove the comments without any changes. Any suggested changes are below the = comment. Regards, Peter [draft text 1: clause 2. Introduction (lines 121 - 127)] In many deployments, the media for SIP-created sessions does not flow direc= tly from the originating user's UAC to the answering user's UAS. Often, S= IP B2BUAs in the SIP signaling path participate in the media plane, either = for injecting media such as rich-ringtones or music-on-hold, or for relayin= g media in order to provide functions such as transcoding, IPv4-IPv6 conver= sion, NAT traversal, SRTP termination, media steering, etc . [comment 1: It would be helpful to indicate how the B2BUA participates in t= he media plane with the text such as below] In many deployments, the media for SIP-created sessions does not flow direc= tly from the originating user's UAC to the answering user's UAS. Often, SI= P B2BUAs in the SIP signaling path also insert themselves in the media plan= e path by manipulating SDP, either for injecting media such as rich-rington= es or music-on-hold, or for relaying media in order to provide functions su= ch as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, m= edia steering, etc . [draft text 2: clause 2. Introduction (line 135)] If failures or degradation occurs in the media plane [comment 2: Typo, change as below] If failures or degradation occur in the media plane, [draft text 3: clause 2. Introduction (line 137)] to aid managing and troubleshooting SIP-based sessions and media crossing s= uch B2BUAs, it would be useful to be able to test the media path to each B2= BUA separately from the source. [comment 3: Unclear what the word "separately refers to. Suggested re-wordi= ng below] to aid managing and troubleshooting SIP-based sessions and media crossing s= uch B2BUAs, it would be useful to be able to progressively test the media p= ath as it reaches successive B2BUAs with a test controlled in a single-ende= d way from the source UA. [draft text 4: clause 2. Introduction (lines 139 - 144)] A mechanism to perform media-loopback test sessions has been defined in [RF= C6849], but it would be difficult to use the mechanism directly to test B2B= UAs because typically the B2BUAs do not have an Address of Record (AoR) to = be targeted, nor is it known a priori which B2BUAs will be crossed for any = given session. [comment 4: I guess that the existing mechanism cannot be used. Suggested r= e-wording below] A mechanism to perform media-loopback test sessions has been defined in [RF= C6849], but it cannot be used to directly to test B2BUAs because typically = the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it= known a priori which B2BUAs will be crossed for any given session. [draft text 5: clause 2. Introduction (lines 151 - 155)] A better solution would be to make a test call targeted to Bob, but with a = SIP traceroute-type mechanism that makes the call terminate at the B2BUAs, = such that she can perform test sessions to test the media path to each down= stream B2BUA . [comment 5: With one test call after another, will the media always take th= e same path?] [draft text 6: clause 2. Introduction (lines 157 - 169)] This document defines how such a mechanism can be employed, using the [RFC6= 849] mechanism along with the Max-Forwards SIP header field such that a SIP= User Agent can make multiple test calls, each reaching a B2BUA further dow= nstream. Each B2BUA in the path that supports this mechanism would answer t= he media-loopback call, and thus the originating SIP UA can test the media = path up to that B2BUA. [comment 6: Not clear what "this mechanism" refers to. Suggested re-wording= below] supports the mechanism in [RFC6849] would answer the media-loopback call , = and [draft text 7: clause 2. Introduction (lines 189 - 195)] The originating UAC can then generate another INVITE to the same target AoR= with a B2bua-Hops header value of 1 , which will reach the second B2BUA th= at supports this mechanism, and so on. A defined [RFC3326] SIP Reason head= er field cause value will be in the 200 answer from each B2BUA answering th= e INVITE, until the INVITE reaches the final UAS, which does not use the Re= ason cause value. (see Section 3.2 for details) [comment 7: If for example the signalling follows a path B2BUA-Proxy-B2BUA = then a hops value of 1 will reach the proxy not the next B2BUA.] [draft text 8: clause 3.1 Processing a Received Max-Forwards Header Field (= lines 206 - 208)] As currently defined in [RFC3261], the UAS half of a B2BUA does not technic= ally need to inspect the Max-Forwards header field value for received reque= sts - only Proxies do. [comment 8: The word "technically" suggests some doubt about whether an RFC= 3261 compliant B2BUA decrements the Max-Forwards header field or not. Sugg= ested re-wording below] [RFC3261] requires proxies to inspect the Max-Forwards header field but not= a B2BUA. [draft text 9: clause 3.2. Answering the INVITE] [comment 9: It is possible for a Max-Forwards header field value to fall to= zero for a call that is not a test call. A B2BUA that supports this draft = would answer such a call, which would be unexpected behaviour as far as the= calling party is concerned. How is this avoided?] [draft text 10: clause 5. IANA Considerations] [comment 10: Nothing stops another mechanism using the Reason text "Tracero= ute Response" as this is not in any IANA registry so the mechanism should n= ot depend on Reason text.] [draft text 11: clause 3. The SIP Traceroute Mechanism] [comment 11: How the mechanism works would be clearer if clause 3. had indi= vidual sub-clauses that describe the specific behaviour of a UAC, Proxy, B2= BUA, and UAS.] --_000_uykptk274j9d1gmq6kqr9mt31386944184840emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
(As co-chair)=0A=
=0A=
Hi Peter,=0A=
=0A=
Thank You very much for the review!=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> w=
rote:=0A=
=0A=

Hello All,

I reviewed draft-ietf-straw-sip-traceroute-01.txt fo= r WGLC and I have the comments below. The text from the draft that a commen= t refers to is copied above the comments without any changes. Any suggested= changes are below the comment.

 

Regards,

Peter

 

[draft text 1: clause 2. Introduction (lines 121 - 1= 27)]

In many deployments, the media for SIP-created sessi= ons does not flow directly from the originating user's UAC to the answering=   user's UAS.  Often, SIP B2BUAs in the SIP signaling path partic= ipate in the media plane, either for injecting media such as rich-ringtones or music-on-hold, or for relaying media in or= der to provide functions such as transcoding, IPv4-IPv6 conversion, NAT tra= versal, SRTP termination, media steering, etc .

 

[comment 1: It would be helpful to indicate how the = B2BUA participates in the media plane with the text such as below]

In many deployments, the media for SIP-created sessi= ons does not flow directly from the originating user's UAC to the answering= user's UAS.  Often, SIP B2BUAs in the SIP signaling path also insert = themselves in the media plane path by manipulating SDP, either for injecting media such as rich-ringtones or music-on-hold, o= r for relaying media in order to provide functions such as transcoding, IPv= 4-IPv6 conversion, NAT traversal, SRTP termination, media steering, etc .

 

 

 

[draft text 2: clause 2. Introduction (line 135)]

If failures or degradation occurs in the media plane=

 

[comment 2: Typo, change as below]

If failures or degradation occur in the media plane,=

 

 

 

[draft text 3: clause 2. Introduction (line 137)]

to aid managing and troubleshooting SIP-based sessio= ns and media crossing such B2BUAs, it would be useful to be able to test th= e media path to each B2BUA separately from the source.

 

[comment 3: Unclear what the word "separately r= efers to. Suggested re-wording below]

to aid managing and troubleshooting SIP-based sessio= ns and media crossing such B2BUAs, it would be useful to be able to progres= sively test the media path as it reaches successive B2BUAs with a test cont= rolled in a single-ended way from the source UA.

 

 

 

[draft text 4: clause 2. Introduction (lines 139 - 1= 44)]

A mechanism to perform media-loopback test sessions = has been defined in [RFC6849], but it would be difficult to use the mechani= sm directly to test B2BUAs because typically the B2BUAs do not have an Addr= ess of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given sessio= n.

 

[comment 4: I guess that the existing mechanism cann= ot be used. Suggested re-wording below]

A mechanism to perform media-loopback test sessions = has been defined in [RFC6849], but it cannot be used to directly to test B2= BUAs because typically the B2BUAs do not have an Address of Record (AoR) to= be targeted, nor is it known a priori which B2BUAs will be crossed for any given session.

 

 

 

[draft text 5: clause 2. Introduction (lines 151 - 1= 55)]

A better solution would be to make a test call targe= ted to Bob, but with a SIP traceroute-type mechanism that makes the call te= rminate at the B2BUAs, such that she can perform test sessions to test the = media path to each downstream B2BUA .

 

[comment 5: With one test call after another, will t= he media always take the same path?]

 

 

 

[draft text 6: clause 2. Introduction (lines 157 - 1= 69)]

This document defines how such a mechanism can be em= ployed, using the [RFC6849] mechanism along with the Max-Forwards SIP heade= r field such that a SIP User Agent can make multiple test calls, each reach= ing a B2BUA further downstream. Each B2BUA in the path that supports this mechanism would answer the media-loop= back call, and thus the originating SIP UA can test the media path up to th= at B2BUA.

 

[comment 6: Not clear what "this mechanism"= ; refers to. Suggested re-wording below]

supports the mechan= ism in [RFC6849] would answer the media-loopback call , and

 

 

 

[draft text 7: clause 2. Introduction (lines 189 - 1= 95)]

The originating UAC= can then generate another INVITE to the same target AoR with a B2bua-Hops = header value of 1 , which will reach the second B2BUA that supports this me= chanism, and so on.  A defined [RFC3326] SIP Reason header field cause value will be in the 200 answer from each B2= BUA answering the INVITE, until the INVITE reaches the final UAS, which doe= s not use the Reason cause value. (see Section 3.2 for details)

 

[comment 7: If for example the signalling follows a = path B2BUA-Proxy-B2BUA then a hops value of 1 will reach the proxy not the = next B2BUA.]

 

 

 

[draft text 8: clause 3.1 Processing a Received Max-= Forwards Header Field (lines 206 - 208)]

As currently defined in [RFC3261], the UAS half of a= B2BUA does not technically need to inspect the Max-Forwards header field v= alue for received requests - only Proxies do.

 

[comment 8: The word "technically" suggest= s some doubt about whether an RFC 3261 compliant B2BUA decrements the Max-F= orwards header field or not. Suggested re-wording below]

[RFC3261] requires proxies to inspect the Max-Forwar= ds header field but not a B2BUA.

 

 

 

[draft text 9: clause 3.2. Answering the INVITE]

 

[comment 9: It is possible for a Max-Forwards header= field value to fall to zero for a call that is not a test call. A B2BUA th= at supports this draft would answer such a call, which would be unexpected = behaviour as far as the calling party is concerned. How is this avoided?]

 

 

 

[draft text 10: clause 5. IANA Considerations]

 

[comment 10: Nothing stops another mechanism using t= he Reason text "Traceroute Response" as this is not in any IANA r= egistry so the mechanism should not depend on Reason text.]

 

 

 

[draft text 11: clause 3. The SIP Traceroute Mechani= sm]

 

[comment 11: How the mechanism works would be cleare= r if clause 3. had individual sub-clauses that describe the specific behavi= our of a UAC, Proxy, B2BUA, and UAS.]

--_000_uykptk274j9d1gmq6kqr9mt31386944184840emailandroidcom_-- From christer.holmberg@ericsson.com Mon Dec 16 04:34:20 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7601AE2FC for ; Mon, 16 Dec 2013 04:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmeT18uwLa1F for ; Mon, 16 Dec 2013 04:34:18 -0800 (PST) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 321C11AE1E5 for ; Mon, 16 Dec 2013 04:34:17 -0800 (PST) X-AuditID: c1b4fb31-b7fa78e0000005dd-0e-52aef3488e86 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 76.F6.01501.843FEA25; Mon, 16 Dec 2013 13:34:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 13:34:06 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: Request for WG adoption: draft-miniero-straw-b2bua-rtcp-00 Thread-Index: Ac7rdCGdm2gqMTCbSIK/fKSkkNUP8gO5i0UA Date: Mon, 16 Dec 2013 12:34:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5C8AD8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C55EFC5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C55EFC5@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5C8AD8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvra7H53VBBq8Wq1ts37KAyeJW82NW ByaPJUt+Mnl0PLzPHsAUxWWTkpqTWZZapG+XwJUx4dgHpoIu24oHk5qZGhi/mXYxcnJICJhI 9Cz/zAZhi0lcuLceyObiEBI4wSjROOs4M4SzhFFidctJIIeDg03AQqL7nzZIg4iAqsSELzcZ QWxmAWeJn7dXMYPYwgLuElvvbWSFqPGQuHP6OAuEbSSx+slJJhCbBai36+YssF5eAV+Js2cg 6oWA7OZdz1hBVnEK+ElMOZ4HEmYEuu37qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sULY ihLtTxugTsuXOHDtIjPEKkGJkzOfsExgFJ2FZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+ c+AxE7L4Akb2VYySxanFSbnpRoZ6uem5JXqpRZnJxcX5eXrFqZsYgVF3cMtvwx2ME6/ZH2KU 5mBREudlmN4ZJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxRdjCtmufF4n9qOq5lVZee90x 93ijgHDF9gXT3Zxl//L/Ocmef2qOJoN3xRsxn7fa66TTJh5R2nInNdvpkPm72TseSRcJR/19 XCflMKdF0U5pAl9r/y0J0bfSbVn9eY3J2qo1J2J+fY/5eeOU0MGHTrMD792NUuffef2xq7JA 4VPpW9Z+194osRRnJBpqMRcVJwIAu55gBYgCAAA= Cc: "Lorenzo Miniero \(lorenzo@meetecho.com\)" Subject: Re: [straw] Request for WG adoption: draft-miniero-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 12:34:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5C8AD8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi, As nobody has indicated any issues with adopting the draft, and as nobody h= as indicated an intention to submit an alternative draft for the delivery, = the WG will adopt draft-miniero-straw-b2bua-rtcp-00 as the base for the fol= lowing delivery: "A document defining the requirements for B2BUAs to support= RTCP end-to-end submitted to the IESG as PS" The authors are requested to submit a draft-ietf-straw version of the draft= . Thanks! Regards, Christer & Victor From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 27. marraskuuta 2013 15:32 To: straw@ietf.org Cc: Lorenzo Miniero (lorenzo@meetecho.com) Subject: [straw] Request for WG adoption: draft-miniero-straw-b2bua-rtcp-00 (As co-chair) Hi, Some time ago Lorenzo submitted draft-miniero-straw-b2bua-rtcp-00, as input= for the following STRAW delivery: "A document defining the requirements for B2BUAs to support RTCP end-to-end= submitted to the IESG as PS" The chairs asked whether someone else is planning to submit a draft for the= delivery, but we have not received any such indication. Therefore, we would like to suggest that the WG adopts draft-miniero-straw-= b2bua-rtcp-00 as base for the delivery. Please indicate by December 6th if you have an issue with that. Regards, Christer & Victor --_000_7594FB04B1934943A5C02806D1A2204B1C5C8AD8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi,<= /p>

 

As nobody has indicate= d any issues with adopting the draft, and as nobody has indicated an intent= ion to submit an alternative draft for the delivery, the WG will adopt draf= t-miniero-straw-b2bua-rtcp-00 as the base for the following delivery:

 

   &nbs= p;            “= ;A document defining the requirements for B2BUAs to support RTCP end-to-end= submitted to the IESG as PS”

 

The authors are reques= ted to submit a draft-ietf-straw version of the draft.

 

Thanks!

 

Regards,

 

Christer & Victor<= o:p>

 

 

From: straw [m= ailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 27. marraskuuta 2013 15:32
To: straw@ietf.org
Cc: Lorenzo Miniero (lorenzo@meetecho.com)
Subject: [straw] Request for WG adoption: draft-miniero-straw-b2bua-= rtcp-00

 

(As co-chair)

 

Hi,

 

Some time ago Lorenzo submitted draft-miniero-straw-= b2bua-rtcp-00, as input for the following STRAW delivery:

 

“A document defin= ing the requirements for B2BUAs to support RTCP end-to-end submitted to the= IESG as PS”

 

The chairs asked whether someone else is planning to= submit a draft for the delivery, but we have not received any such indicat= ion.

 

Therefore, we would like to suggest that the WG adop= ts draft-miniero-straw-b2bua-rtcp-00 as base for the delivery.

 

Please indicate by December 6th if you ha= ve an issue with that.

 

Regards,

 

Christer & Victor

 

--_000_7594FB04B1934943A5C02806D1A2204B1C5C8AD8ESESSMB209erics_-- From hadriel.kaplan@oracle.com Mon Dec 16 11:25:36 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BDD1AC499 for ; Mon, 16 Dec 2013 11:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9H6UjOLNLcS for ; Mon, 16 Dec 2013 11:25:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBD21A82E2 for ; Mon, 16 Dec 2013 11:25:34 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBGJPWQL020220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 19:25:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBGJPUc7005802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Dec 2013 19:25:31 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBGJPUJ2029296; Mon, 16 Dec 2013 19:25:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Dec 2013 11:25:30 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Hadriel Kaplan In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> Date: Mon, 16 Dec 2013 14:25:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41F7292D-28D8-4192-A4BF-22738BF3939D@oracle.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> To: "Dawes, Peter, Vodafone Group" X-Mailer: Apple Mail (2.1822) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "straw@ietf.org" Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:25:36 -0000 Thanks for the comments Peter! - responses below... On Dec 13, 2013, at 4:30 AM, Dawes, Peter, Vodafone Group = wrote: > [draft text 1: clause 2. Introduction (lines 121 - 127)] > In many deployments, the media for SIP-created sessions does not flow = directly from the originating user's UAC to the answering user's UAS. = Often, SIP B2BUAs in the SIP signaling path participate in the media = plane, either for injecting media such as rich-ringtones or = music-on-hold, or for relaying media in order to provide functions such = as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, = media steering, etc . > =20 > [comment 1: It would be helpful to indicate how the B2BUA participates = in the media plane with the text such as below] > In many deployments, the media for SIP-created sessions does not flow = directly from the originating user's UAC to the answering user's UAS. = Often, SIP B2BUAs in the SIP signaling path also insert themselves in = the media plane path by manipulating SDP, either for injecting media = such as rich-ringtones or music-on-hold, or for relaying media in order = to provide functions such as transcoding, IPv4-IPv6 conversion, NAT = traversal, SRTP termination, media steering, etc . Done. > [draft text 2: clause 2. Introduction (line 135)] > If failures or degradation occurs in the media plane > =20 > [comment 2: Typo, change as below] > If failures or degradation occur in the media plane, Done. > [draft text 3: clause 2. Introduction (line 137)] > to aid managing and troubleshooting SIP-based sessions and media = crossing such B2BUAs, it would be useful to be able to test the media = path to each B2BUA separately from the source. > =20 > [comment 3: Unclear what the word "separately refers to. Suggested = re-wording below] > to aid managing and troubleshooting SIP-based sessions and media = crossing such B2BUAs, it would be useful to be able to progressively = test the media path as it reaches successive B2BUAs with a test = controlled in a single-ended way from the source UA. Done. > [draft text 4: clause 2. Introduction (lines 139 - 144)] > A mechanism to perform media-loopback test sessions has been defined = in [RFC6849], but it would be difficult to use the mechanism directly to = test B2BUAs because typically the B2BUAs do not have an Address of = Record (AoR) to be targeted, nor is it known a priori which B2BUAs will = be crossed for any given session. > =20 > [comment 4: I guess that the existing mechanism cannot be used. = Suggested re-wording below] > A mechanism to perform media-loopback test sessions has been defined = in [RFC6849], but it cannot be used to directly to test B2BUAs because = typically the B2BUAs do not have an Address of Record (AoR) to be = targeted, nor is it known a priori which B2BUAs will be crossed for any = given session.=20 Done. > [draft text 5: clause 2. Introduction (lines 151 - 155)] > A better solution would be to make a test call targeted to Bob, but = with a SIP traceroute-type mechanism that makes the call terminate at = the B2BUAs, such that she can perform test sessions to test the media = path to each downstream B2BUA . > =20 > [comment 5: With one test call after another, will the media always = take the same path?] No not necessarily, but I don=92t see that there=92s anything we can do = about that. :( > [draft text 6: clause 2. Introduction (lines 157 - 169)] > This document defines how such a mechanism can be employed, using the = [RFC6849] mechanism along with the Max-Forwards SIP header field such = that a SIP User Agent can make multiple test calls, each reaching a = B2BUA further downstream. Each B2BUA in the path that supports this = mechanism would answer the media-loopback call, and thus the originating = SIP UA can test the media path up to that B2BUA. > =20 > [comment 6: Not clear what "this mechanism" refers to. Suggested = re-wording below] > supports the mechanism in [RFC6849] would answer the media-loopback = call , and=20 Done. > [draft text 7: clause 2. Introduction (lines 189 - 195)] > The originating UAC can then generate another INVITE to the same = target AoR with a B2bua-Hops header value of 1 , which will reach the = second B2BUA that supports this mechanism, and so on. A defined = [RFC3326] SIP Reason header field cause value will be in the 200 answer = from each B2BUA answering the INVITE, until the INVITE reaches the final = UAS, which does not use the Reason cause value. (see Section 3.2 for = details) > =20 > [comment 7: If for example the signalling follows a path = B2BUA-Proxy-B2BUA then a hops value of 1 will reach the proxy not the = next B2BUA.] Yeah the wording in that section got all screwed up when I removed the = B2bua-Hops header thing. I think I=92ve cleaned it up now. > [draft text 8: clause 3.1 Processing a Received Max-Forwards Header = Field (lines 206 - 208)] > As currently defined in [RFC3261], the UAS half of a B2BUA does not = technically need to inspect the Max-Forwards header field value for = received requests - only Proxies do. > =20 > [comment 8: The word "technically" suggests some doubt about whether = an RFC 3261 compliant B2BUA decrements the Max-Forwards header field or = not. Suggested re-wording below] > [RFC3261] requires proxies to inspect the Max-Forwards header field = but not a B2BUA.=20 But I think it is in fact in doubt. I know of many B2BUAs which do in = fact decrement max-forwards. (and I think they=92re right to) > [draft text 9: clause 3.2. Answering the INVITE] > =20 > [comment 9: It is possible for a Max-Forwards header field value to = fall to zero for a call that is not a test call. A B2BUA that supports = this draft would answer such a call, which would be unexpected behaviour = as far as the calling party is concerned. How is this avoided?] The SDP won=92t have loopback. > [draft text 10: clause 5. IANA Considerations] > =20 > [comment 10: Nothing stops another mechanism using the Reason text = "Traceroute Response" as this is not in any IANA registry so the = mechanism should not depend on Reason text.] It doesn=92t depend on it - I=92ve added some wording to make that = clearer. > [draft text 11: clause 3. The SIP Traceroute Mechanism] > =20 > [comment 11: How the mechanism works would be clearer if clause 3. had = individual sub-clauses that describe the specific behaviour of a UAC, = Proxy, B2BUA, and UAS.] Not sure what you mean? -hadriel From hadriel.kaplan@oracle.com Mon Dec 16 11:28:32 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006A1A82E2 for ; Mon, 16 Dec 2013 11:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24vJgVCpeBJy for ; Mon, 16 Dec 2013 11:28:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A91871A1F3D for ; Mon, 16 Dec 2013 11:28:30 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBGJSSgK027593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 19:28:29 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBGJSRmp015115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Dec 2013 19:28:28 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBGJSRTY009168; Mon, 16 Dec 2013 19:28:27 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Dec 2013 11:28:26 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Hadriel Kaplan In-Reply-To: <526C35FC.2050501@alum.mit.edu> Date: Mon, 16 Dec 2013 14:28:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C4EF8F7@ESESSMB209.ericsson.se> <526C35FC.2050501@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1822) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: straw@ietf.org Subject: Re: [straw] Coming up: WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:28:32 -0000 Thanks for the comments Paul! - responses below... On Oct 26, 2013, at 5:37 PM, Paul Kyzivat wrote: > Section 3 and is sub-sections have some problems that derive from its = evolution. Originally a new header, B2bua-Hops was used. We have since = decided to use Max-Forwards instead. There is still a reference to = B2bua-Hops in this section. Right - it=92s all fubar. I=92ve tried to clean it up now. > Also, while instructions for the receiving B2BUA are given, the = instructions for the UAC are skimpy. I think something should say that = it should first send the request with Max-Forwards:0, and then increment = it one by one until it gets an error unrelated to the Max-Forwards, or a = success that doesn't have the special reason code. And during that = process it may get 483 responses (from proxies or B2BUAs that don't = support this mechanism) and must ignore those. Right, done as part of the section 3.2 cleanup. > Section 3.2 is confusing to be in the way it conflates B2BUA and UAS. = ISTM this section should distinguish between a device that judges itself = to be the intended destination of the request, and one that judges = itself to be a B2BUA intermediary. If it is the intended destination, = then it acts normally, without regard to Max-Forwards. If it judges = itself to be an intermediary, then it checks Max-Forwards. If its zero = then either it answers 483, or else it responds 200 with the special = Reason and sets up the loopback. Done. > Also in 3.2, note that: >=20 > When the final UAS answers a loopback-based INVITE with a Max- > Forwards greater than 0, the Reason header would not be added to the > response and the UAC will know the traceroute is complete. >=20 > is off by one. It should say "greater than or equal to 0". But = addressing my other comments will probably cause it to be rewritten = anyway. Done. > Since we decided not to do the 205 response, the Reason header becomes = key. I'm a little uncomfortable with specifying that we use reason 483 = with a *specific* reason-text value. I think we either say the 483 = reason means this regardless of the reason-text, or else register a new = reason code for this. (But registering a new reason code seems like = overkill.) I=92ve tried to clear it up to say the code 483 is what the UAC uses to = distinguish, but I still think we want to specify a reason phrase for = the b2bua to use, to make it easy to figure it out in wireshark etc. -hadriel From Peter.Dawes@vodafone.com Tue Dec 17 04:04:29 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04931AE187 for ; Tue, 17 Dec 2013 04:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqzqvEmGV4B1 for ; Tue, 17 Dec 2013 04:04:27 -0800 (PST) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by ietfa.amsl.com (Postfix) with ESMTP id C2A1C1AE1EB for ; Tue, 17 Dec 2013 04:04:26 -0800 (PST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailout03.vodafone.com (Postfix) with ESMTP id 8EA60140893 for ; Tue, 17 Dec 2013 13:04:23 +0100 (CET) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 6EC9D1407C4; Tue, 17 Dec 2013 13:04:23 +0100 (CET) Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 17 Dec 2013 13:04:22 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.127]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0146.002; Tue, 17 Dec 2013 13:04:21 +0100 From: "Dawes, Peter, Vodafone Group" To: Hadriel Kaplan Thread-Topic: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt Thread-Index: AQHO+pSfJfgZsqbMXE+cNvCMDQ15NppYOTBA Date: Tue, 17 Dec 2013 12:04:21 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973914B4F@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D9973905789@VOEXM31W.internal.vodafone.com> <41F7292D-28D8-4192-A4BF-22738BF3939D@oracle.com> In-Reply-To: <41F7292D-28D8-4192-A4BF-22738BF3939D@oracle.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "straw@ietf.org" Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 12:04:30 -0000 Hello Hadriel, Thanks for responding to my comments, it seems that most of them are now fi= xed :-) To try to clarify the remaining couple of comments: I think the draft text in clause 3.1 Processing a Received Max-Forwards Hea= der Field (lines 206 - 208)] "As currently defined in [RFC3261], the UAS ha= lf of a B2BUA does not technically need to inspect the Max-Forwards header = field value for received requests - only Proxies do." should be clearer in = terms of what the implementer actually has to do.=20 You replied that "...I think it is in fact in doubt. I know of many B2BUAs= which do in fact decrement max-forwards. (and I think they're right to)". = So what does the implementer do? Be happy that they might not need to chang= e too much? Make sure all of their B2BUAs decrement Max-Forwards whether th= ey will loopback media or not? Be aware that if they don't want their B2BUA= to decrement Max-Forwards then they can't use this mechanism? Something el= se? To clarify my comment " How the mechanism works would be clearer if clause = 3. had individual sub-clauses that describe the specific behaviour of a UAC= , Proxy, B2BUA, and UAS.", I am suggesting the kind of structure below. As = one example, clause 3.2 Answering the INVITE mixes B2BUA and UAS behaviour = suggesting that they can be considered in the same way but the UAS behaviou= r might impact a user and I think it's likely that a UAS will reject loopba= ck requests.=20 3. The SIP Traceroute Mechanism Overview and signalling example 3.1 Originating UA Procedures Constructing an INVITE request including choosing the Request-URI, assignin= g a value to Max-Forwards, constructing SDP Processing a 483 response (from proxy, from b2bua, from terminating UA) Processing a 200 response (from b2bua, from terminating UA) Processing a rejection from the terminating UA, either in SDP or as a SIP r= esponse 3.2 B2BUA Procuedures Decrementing Max-Forwards Processing SDP and setting up loopback Assigning Reason header value Sending a SIP response (200 or 483) 3.3 Terminating UA Procedures Similar to 3.2 but how does a terminating UA reject the loopback request? i= n SDP or by a SIP response? I think clause 4. Security Considerations shoul= d refer to RFC 6849 to point out that a UAS which is looping back should al= ert the user and loopback can have DoS implications.=20 Peter -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: 16 December 2013 19:25 To: Dawes, Peter, Vodafone Group Cc: straw@ietf.org Subject: Re: [straw] WGLC for draft-ietf-straw-sip-traceroute-01.txt Thanks for the comments Peter! - responses below... On Dec 13, 2013, at 4:30 AM, Dawes, Peter, Vodafone Group wrote: > [draft text 1: clause 2. Introduction (lines 121 - 127)] In many=20 > deployments, the media for SIP-created sessions does not flow directly fr= om the originating user's UAC to the answering user's UAS. Often, SIP B2B= UAs in the SIP signaling path participate in the media plane, either for in= jecting media such as rich-ringtones or music-on-hold, or for relaying medi= a in order to provide functions such as transcoding, IPv4-IPv6 conversion, = NAT traversal, SRTP termination, media steering, etc . > =20 > [comment 1: It would be helpful to indicate how the B2BUA participates=20 > in the media plane with the text such as below] In many deployments, the = media for SIP-created sessions does not flow directly from the originating = user's UAC to the answering user's UAS. Often, SIP B2BUAs in the SIP signa= ling path also insert themselves in the media plane path by manipulating SD= P, either for injecting media such as rich-ringtones or music-on-hold, or f= or relaying media in order to provide functions such as transcoding, IPv4-I= Pv6 conversion, NAT traversal, SRTP termination, media steering, etc . Done. > [draft text 2: clause 2. Introduction (line 135)] If failures or=20 > degradation occurs in the media plane > =20 > [comment 2: Typo, change as below] > If failures or degradation occur in the media plane, Done. > [draft text 3: clause 2. Introduction (line 137)] to aid managing and=20 > troubleshooting SIP-based sessions and media crossing such B2BUAs, it wou= ld be useful to be able to test the media path to each B2BUA separately fro= m the source. > =20 > [comment 3: Unclear what the word "separately refers to. Suggested=20 > re-wording below] to aid managing and troubleshooting SIP-based sessions = and media crossing such B2BUAs, it would be useful to be able to progressiv= ely test the media path as it reaches successive B2BUAs with a test control= led in a single-ended way from the source UA. Done. > [draft text 4: clause 2. Introduction (lines 139 - 144)] A mechanism=20 > to perform media-loopback test sessions has been defined in [RFC6849], bu= t it would be difficult to use the mechanism directly to test B2BUAs becaus= e typically the B2BUAs do not have an Address of Record (AoR) to be targete= d, nor is it known a priori which B2BUAs will be crossed for any given sess= ion. > =20 > [comment 4: I guess that the existing mechanism cannot be used.=20 > Suggested re-wording below] A mechanism to perform media-loopback test se= ssions has been defined in [RFC6849], but it cannot be used to directly to = test B2BUAs because typically the B2BUAs do not have an Address of Record (= AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed = for any given session. Done. > [draft text 5: clause 2. Introduction (lines 151 - 155)] A better=20 > solution would be to make a test call targeted to Bob, but with a SIP tra= ceroute-type mechanism that makes the call terminate at the B2BUAs, such th= at she can perform test sessions to test the media path to each downstream = B2BUA . > =20 > [comment 5: With one test call after another, will the media always=20 > take the same path?] No not necessarily, but I don't see that there's anything we can do about t= hat. :( > [draft text 6: clause 2. Introduction (lines 157 - 169)] This document=20 > defines how such a mechanism can be employed, using the [RFC6849] mechani= sm along with the Max-Forwards SIP header field such that a SIP User Agent = can make multiple test calls, each reaching a B2BUA further downstream. Eac= h B2BUA in the path that supports this mechanism would answer the media-loo= pback call, and thus the originating SIP UA can test the media path up to t= hat B2BUA. > =20 > [comment 6: Not clear what "this mechanism" refers to. Suggested=20 > re-wording below] supports the mechanism in [RFC6849] would answer the=20 > media-loopback call , and Done. > [draft text 7: clause 2. Introduction (lines 189 - 195)] The=20 > originating UAC can then generate another INVITE to the same target=20 > AoR with a B2bua-Hops header value of 1 , which will reach the second=20 > B2BUA that supports this mechanism, and so on. A defined [RFC3326]=20 > SIP Reason header field cause value will be in the 200 answer from=20 > each B2BUA answering the INVITE, until the INVITE reaches the final=20 > UAS, which does not use the Reason cause value. (see Section 3.2 for=20 > details) > =20 > [comment 7: If for example the signalling follows a path=20 > B2BUA-Proxy-B2BUA then a hops value of 1 will reach the proxy not the=20 > next B2BUA.] Yeah the wording in that section got all screwed up when I removed the B2bu= a-Hops header thing. I think I've cleaned it up now. > [draft text 8: clause 3.1 Processing a Received Max-Forwards Header=20 > Field (lines 206 - 208)] As currently defined in [RFC3261], the UAS half = of a B2BUA does not technically need to inspect the Max-Forwards header fie= ld value for received requests - only Proxies do. > =20 > [comment 8: The word "technically" suggests some doubt about whether=20 > an RFC 3261 compliant B2BUA decrements the Max-Forwards header field or n= ot. Suggested re-wording below] [RFC3261] requires proxies to inspect the M= ax-Forwards header field but not a B2BUA. But I think it is in fact in doubt. I know of many B2BUAs which do in fact= decrement max-forwards. (and I think they're right to) > [draft text 9: clause 3.2. Answering the INVITE] > =20 > [comment 9: It is possible for a Max-Forwards header field value to=20 > fall to zero for a call that is not a test call. A B2BUA that supports=20 > this draft would answer such a call, which would be unexpected=20 > behaviour as far as the calling party is concerned. How is this=20 > avoided?] The SDP won't have loopback. > [draft text 10: clause 5. IANA Considerations] > =20 > [comment 10: Nothing stops another mechanism using the Reason text=20 > "Traceroute Response" as this is not in any IANA registry so the=20 > mechanism should not depend on Reason text.] It doesn't depend on it - I've added some wording to make that clearer. > [draft text 11: clause 3. The SIP Traceroute Mechanism] > =20 > [comment 11: How the mechanism works would be clearer if clause 3. had=20 > individual sub-clauses that describe the specific behaviour of a UAC,=20 > Proxy, B2BUA, and UAS.] Not sure what you mean? -hadriel From internet-drafts@ietf.org Thu Dec 19 08:36:24 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094351ADFAD; Thu, 19 Dec 2013 08:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpxiXddc6ZXC; Thu, 19 Dec 2013 08:36:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC841AD190; Thu, 19 Dec 2013 08:36:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219163622.29630.27184.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 08:36:22 -0800 Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-00.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 16:36:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sip Traversal Required for Applications t= o Work Working Group of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back Us= er Agents (B2BUAs) Author(s) : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-00.txt Pages : 10 Date : 2013-12-19 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate media legs that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Fri Dec 20 13:23:47 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7C1AE17A; Fri, 20 Dec 2013 13:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpU_a6eJTcmT; Fri, 20 Dec 2013 13:23:43 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0E1AE17F; Fri, 20 Dec 2013 13:23:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3CA5E7FC3AF; Fri, 20 Dec 2013 13:23:12 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131220212312.3CA5E7FC3AF@rfc-editor.org> Date: Fri, 20 Dec 2013 13:23:12 -0800 (PST) Cc: drafts-update-ref@iana.org, straw@ietf.org, rfc-editor@rfc-editor.org Subject: [straw] RFC 7092 on A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 21:23:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7092 Title: A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents Author: H. Kaplan, V. Pascual Status: Informational Stream: IETF Date: December 2013 Mailbox: hadriel.kaplan@oracle.com, victor.pascual@quobis.com Pages: 10 Characters: 22085 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-straw-b2bua-taxonomy-03.txt URL: http://www.rfc-editor.org/rfc/rfc7092.txt In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC). There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference. This document is a product of the Sip Traversal Required for Applications to Work Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From christer.holmberg@ericsson.com Sat Dec 21 10:10:13 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0301ADFB9 for ; Sat, 21 Dec 2013 10:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiKFBUEii9C4 for ; Sat, 21 Dec 2013 10:10:12 -0800 (PST) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 83CAF1ADFE2 for ; Sat, 21 Dec 2013 10:10:11 -0800 (PST) X-AuditID: c1b4fb28-b7f4e8e000000b43-eb-52b5d97f3f37 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8B.F3.02883.F79D5B25; Sat, 21 Dec 2013 19:10:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0347.000; Sat, 21 Dec 2013 19:10:09 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: [straw] RFC 7092 on A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents Thread-Index: AQHO/cnOLvO/xqYni06ii3+nTPsLFZpe88Nn Date: Sat, 21 Dec 2013 18:10:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5DF21A@ESESSMB209.ericsson.se> References: <20131220212312.3CA5E7FC3AF@rfc-editor.org> In-Reply-To: <20131220212312.3CA5E7FC3AF@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrW79za1BBsu/mVncan7M6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLfXjzMXzJOoONvSytrAOEW4i5GTQ0LAROLtgzZmCFtM4sK9 9WxdjFwcQgInGCU2bfzLCOEsYZRY3/idvYuRg4NNwEKi+582SIOIgKrEhC83GUFsYYFsidlb l7KAlIgI5EhMWecFUWIkcfnbZxYQmwWofErDbzYQm1fAV+LF+T5WEFtIwFzi+YzH7CA2J9D0 3vcXwGxGoHu+n1rDBGIzC4hL3HoynwniTgGJJXvOQ90sKvHy8T9WkLUSAkoS07amQZTrSCzY /YkNwtaWWLbwNTPEWkGJkzOfsExgFJ2FZOosJC2zkLTMQtKygJFlFaNkcWpxcW66kaFebnpu iV5qUWZycXF+nl5x6iZGYFwc3PJbYwdj9zX7Q4zSHCxK4rxVMzuDhATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTAypf9OssnnXBK/L9J290bez93r9DZv0VXhd0qST7C5PP3tGpPvfiutlV3a WA2aFF4edpk0N9uaw2bJ7KUpRg3dgdv2F93t807xs6tI/cHIo384Ytu8F6e3M801llidOfdg 3rnG1K0vNkp1npDuutQ1MW3LN44DkbumHbG2OXeH71ieg9bSfh8lluKMREMt5qLiRACh1jxX WQIAAA== Subject: [straw] FW: RFC 7092 on A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 18:10:13 -0000 (As co-chair) Folks, our first RFC has been published! Thank You to everyone who made thi= s happen! :) Regards, Christer & Victor ________________________________________ From: straw [straw-bounces@ietf.org] on behalf of rfc-editor@rfc-editor.org= [rfc-editor@rfc-editor.org] Sent: Friday, 20 December 2013 11:23 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; straw@ietf.org; rfc-editor@rfc-editor.org Subject: [straw] RFC 7092 on A Taxonomy of Session Initiation Protocol (SIP= ) Back-to-Back User Agents A new Request for Comments is now available in online RFC libraries. RFC 7092 Title: A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents Author: H. Kaplan, V. Pascual Status: Informational Stream: IETF Date: December 2013 Mailbox: hadriel.kaplan@oracle.com, victor.pascual@quobis.com Pages: 10 Characters: 22085 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-straw-b2bua-taxonomy-03.txt URL: http://www.rfc-editor.org/rfc/rfc7092.txt In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC). There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference. This document is a product of the Sip Traversal Required for Applications t= o Work Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw