From hadriel.kaplan@oracle.com Sat Jun 15 12:26:01 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E77C21F9E0B for ; Sat, 15 Jun 2013 12:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov7kf2PQl2yZ for ; Sat, 15 Jun 2013 12:25:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EEA9921F9DD6 for ; Sat, 15 Jun 2013 12:25:55 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5FJPsN8001400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Jun 2013 19:25:55 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5FJPrLQ008613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Jun 2013 19:25:54 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5FJPrKu015071 for ; Sat, 15 Jun 2013 19:25:53 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-189-250.vpn.oracle.com (/10.154.189.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jun 2013 12:25:53 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jun 2013 15:25:52 -0400 References: <20130615192422.22852.89043.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [straw] Fwd: New Version Notification for draft-kaplan-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2013 19:26:01 -0000 Howdy, based on the feedback from the last meeting, I've updated the traceroute = draft. -hadriel Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-kaplan-straw-sip-traceroute-01.txt > Date: June 15, 2013 3:24:22 PM EDT > To: Hadriel Kaplan >=20 >=20 > A new version of I-D, draft-kaplan-straw-sip-traceroute-01.txt > has been successfully submitted by Hadriel Kaplan and posted to the > IETF repository. >=20 > Filename: draft-kaplan-straw-sip-traceroute > Revision: 01 > Title: A Media-based Traceroute Function for the = Session Initiation Protocol (SIP) > Creation date: 2013-06-15 > Group: Individual Submission > Number of pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-kaplan-straw-sip-traceroute-01.t= xt > Status: = http://datatracker.ietf.org/doc/draft-kaplan-straw-sip-traceroute > Htmlized: = http://tools.ietf.org/html/draft-kaplan-straw-sip-traceroute-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-kaplan-straw-sip-traceroute-01 >=20 > Abstract: > SIP already provides the ability to perform hop-by-hop traceroute > for SIP messages using the Max-Forwards header field, in order to > determine the reachability path of requests to a target. A > mechanism for media-loopback calls has also been defined separately, > which enables test calls to be generated which result in media being > looped back to the originator. This document describes a means of > performing hop-by-hop traceroute-style test calls using the media- > loopback mechanism, in order to test the media path when SIP > sessions go through media-relaying B2BUAs. >=20 From albrecht.schwarz@alcatel-lucent.com Sat Jun 15 22:12:59 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE5E21F9E52 for ; Sat, 15 Jun 2013 22:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th9Ls7BqWolJ for ; Sat, 15 Jun 2013 22:12:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BA57121F9E54 for ; Sat, 15 Jun 2013 22:12:52 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r5G5Coxf029064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Jun 2013 00:12:51 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5G5CoUU025371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Jun 2013 01:12:50 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 16 Jun 2013 01:12:49 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 16 Jun 2013 07:12:47 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Hadriel Kaplan , "" Thread-Topic: draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types Thread-Index: AQHOalAj8gpobm3rD0OdKV/RhKM1qw== Date: Sun, 16 Jun 2013 05:12:46 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC065CCF@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20130615192422.22852.89043.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Jun 2013 05:12:59 -0000 Hi Hadriel, fyi, some high-level comments to the taxonomy draft from perspective of dec= omposed SBCs (according H.248 model) http://ftp3.itu.int/av-arch/avc-site/2013-2016/1306_Osl/AVD-4391.zip=20 Regards, Albrecht From prvs=3879a1188b=christer.holmberg@ericsson.com Sun Jun 16 02:03:57 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B685721F9E92 for ; Sun, 16 Jun 2013 02:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnXuwP8qmgT6 for ; Sun, 16 Jun 2013 02:03:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6AA21F9CFA for ; Sun, 16 Jun 2013 02:03:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-40-51bd7f75fef5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D1.09.15700.57F7DB15; Sun, 16 Jun 2013 11:03:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Sun, 16 Jun 2013 11:03:49 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , Hadriel Kaplan , "" Thread-Topic: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types Thread-Index: AQHOalAuQy4rBJglv0Olxu/AXvjOQpk4CxXg Date: Sun, 16 Jun 2013 09:03:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C39C367@ESESSMB209.ericsson.se> References: <20130615192422.22852.89043.idtracker@ietfa.amsl.com> <786615F3A85DF44AA2A76164A71FE1AC065CCF@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC065CCF@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrW5Z/d5AgzW3uS3+tP5itPi06ROz xa3mx6wOzB6tz/ayeixZ8pPJ4+PTWywBzFHcNkmJJWXBmel5+nYJ3Bm31q1lLtjJVXH75RKW BsbLHF2MHBwSAiYSly+mdjFyApliEhfurWfrYuTiEBI4zCjxf8k7ZghnEaPEtY/trCANbAIW Et3/tEHiIgJzGSVuHm1jBukWFsiROLmimR3EFhHIldj1fz4LhG0kMXPVVHaQXhYBVYnGR44g YV4BX4knx56yQ8w/xigx+dx0JpAaToFoiRW7I0BqGIEO+n5qDROIzSwgLvHh4HVmiEMFJJbs OQ9li0q8fPyPFcJWkvix4RILRL2exI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jIL ScssJC0LGFlWMbLnJmbmpJcbbmIExsfBLb91dzCeOidyiFGag0VJnPfDqV2BQgLpiSWp2amp BalF8UWlOanFhxiZODhBBJdUA2O5DmfszA0/Gpa8OzJ1l+nLFj3rA+UTg033/nmQ2qv50PPG 8ZPi75jlVG1b9u6L33D5p3bZ5JLTzj//N+fUVXH0vHcx3PJUandm07IpzGU+hgs+lN8yVY7T ufBuu97yyR0s32PfuH/asWLx35J9hkqqi5W27I4tTtPP3/ktiyf93OF1bqtD3YyUWIozEg21 mIuKEwGKe8JnYgIAAA== Subject: Re: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 16 Jun 2013 09:03:57 -0000 (As co-chair) Hi Albrecht, I do appreciate the fact that you have taken a look at the draft, and studi= ed its applicability from a SG16 perspective. In the conclusion part, you ask whether there is a need to provide feedback= to STRAW. Keep in mind that the WGLC for the draft has finished, and that publication= has been requested by the chairs. Now, that does not prevent us from taking the draft back to the WG, and do = changes, but in order for that to happen there normally has to be some issu= es that need to be changed/addressed in order to publish the document as an= RFC. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: straw-bounces@ietf.org [mailto:straw-bounces@ietf.org] Puo= lesta Schwarz, Albrecht (Albrecht) L=E4hetetty: 16. kes=E4kuuta 2013 8:13 Vastaanottaja: Hadriel Kaplan; Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and= media plane b2bua types Hi Hadriel, fyi, some high-level comments to the taxonomy draft from perspective of dec= omposed SBCs (according H.248 model) http://ftp3.itu.int/av-arch/avc-site/2= 013-2016/1306_Osl/AVD-4391.zip=20 Regards, Albrecht _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw From prvs=98808d66bb=christer.holmberg@ericsson.com Mon Jun 17 01:02:54 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4214821F93E0 for ; Mon, 17 Jun 2013 01:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La-B1en25q5v for ; Mon, 17 Jun 2013 01:02:43 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32221F9B0C for ; Mon, 17 Jun 2013 00:58:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-6e-51bec149145e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B7.02.09795.941CEB15; Mon, 17 Jun 2013 09:56:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 09:56:56 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: Call for WG adoption: draft-kaplan-straw-sip-traceroute-01.txt Thread-Index: Ac5rLYjWmjPAiqThRoWHeTmUOxTXsg== Date: Mon, 17 Jun 2013 07:56:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C39EC4CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvra7nwX2BBuf7JCxuNT9mdWD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bjTvaCo2oVq1/MZmtg/K/YxcjJISFgIvH102JWCFtM4sK9 9WxdjFwcQgKHGSXOXbzHDOEsYpS4uGsnUIaDg03AQqL7nzZIg4iAqsSELzcZQWxhAXeJV9ee sEDEfSQOLfzIBmHrSRyaexzMZgGq33rrB1gNr4CvxKWlS5hAbEagxd9PrQGzmQXEJW49mc8E cZCAxJI955khbFGJl4//sYKcICGgKLG8Xw6iPF/i4KxdUCMFJU7OfMIygVFoFpJJs5CUzUJS BhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxsucmZuakl5tvYgQG/cEtvw12MG66L3aI UZqDRUmc99OpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QDI4uPKXNrp/PnR1Gu3IWy eWHX52cmzuuvrPs98ZOowy33lWk/SwIyZnk9EWGeOtdp0Q8+zi9b9ygKmKo7/eQwvr5PnFXi TSjXql9d66/Kbm1YLHSznNV6/snLyT9PF7uUbjnW1pJ9Jy3v866eZXvmv9+7uf/mJ+GpLoX6 vPW/9heXxR56rrnnlBJLcUaioRZzUXEiAJrZnxpNAgAA Subject: [straw] Call for WG adoption: draft-kaplan-straw-sip-traceroute-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2013 08:02:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C39EC4CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi, Based on the discussions in Orlando, Hadriel has submitted a new version (-= 01) of draft-kaplan-straw-sip-traceroute: http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt As discussed, once the draft is submitted, the chairs will call for WG adop= tion of the draft, as base for the following WG charter delivery: "A document defining the requirements for B2BUAs to support end-to-end and = hop-by-hop media-loopback test calls submitted to the IESG as PS" So, as no other proposals to implement the delivery have been submitted, th= e chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-01 as= base for the delivery above, and that anyone who has issues with that rais= es those issues it on the list by Friday 5th July. Thanks! Christer & Victor Ps. The notes from Orlando can be found at: http://www.ietf.org/proceedings= /86/minutes/minutes-86-straw --_000_7594FB04B1934943A5C02806D1A2204B1C39EC4CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi,

 

Based on the discussions in Orlando, Hadriel has sub= mitted a new version (-01) of draft-kaplan-straw-sip-traceroute:=

 

http://www.ietf.org/id/draft-kaplan-straw-sip-trace= route-01.txt

 

As discussed, once the draft is submitted, the chair= s will call for WG adoption of the draft, as base for the following WG char= ter delivery:

 

“A document defin= ing the requirements for B2BUAs to support end-to-end and hop-by-hop media-= loopback test calls submitted to the IESG as PS”

 

So, as no other proposals to implement the delivery = have been submitted, the chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-= 01 as base for the delivery above, and that anyone who has issues with = that raises those issues it on the list by Friday 5th July.

 

Thanks!

 

Christer & Victor

 

Ps. The notes from Orlando can be found at: http://www.ietf.org/proceedings/86/minutes/minutes-86-straw<= /p>

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C39EC4CESESSMB209erics_-- From iesg-secretary@ietf.org Mon Jun 17 07:35:54 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13E521F9968; Mon, 17 Jun 2013 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3p1bdLkCpQz; Mon, 17 Jun 2013 07:35:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AAA21F8FF8; Mon, 17 Jun 2013 07:35:53 -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.51.p2 Sender: Message-ID: <20130617143553.14774.20643.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 07:35:53 -0700 Cc: straw@ietf.org Subject: [straw] Last Call: (A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents) to Informational RFC X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 17 Jun 2013 14:35:54 -0000 The IESG has received a request from the Sip Traversal Required for Applications to Work WG (straw) to consider the following document: - 'A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-07-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In many SIP deployments, SIP entities exist in the SIP signaling path between the originating UAC and final terminating UAS, which go beyond the definition of a Proxy, performing functions not defined in standards-track RFCs. The only term for such devices provided in [RFC3261] is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a User Agent Server (UAS) and User Agent Client (UAC). There are numerous types of SIP Back-to-Back User Agents (B2BUAs), performing different roles in different ways. For Example IP-PBXs, SBCs and Application Servers. This document identifies several common B2BUA roles, in order to provide taxonomy other documents can use and reference. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-taxonomy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-taxonomy/ballot/ No IPR declarations have been submitted directly on this I-D. From hadriel.kaplan@oracle.com Tue Jun 18 11:13:04 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5C21F99BE for ; Tue, 18 Jun 2013 11:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZPCIM46SK+7 for ; Tue, 18 Jun 2013 11:12:59 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6037521F99B7 for ; Tue, 18 Jun 2013 11:12:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5IICpmW012036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Jun 2013 18:12:52 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5IICrOC004443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jun 2013 18:12:54 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5IICr7p024692 for ; Tue, 18 Jun 2013 18:12:53 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jun 2013 11:12:53 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> Date: Tue, 18 Jun 2013 14:12:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> To: straw@ietf.org X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2013 18:13:04 -0000 I should note there is one open issue in this draft. The issue is that = there is no way to determine when you've reached the final/real target = UAS. There are multiple ways of doing it, but each has pro's/con's. At a high-level, I think there're two paths: 1) Have the final UAS insert something somewhere in the signaling back, = to say "I'm the target you're looking for". 2) Have all the B2BUAs insert something in signaling back to say "We're = not the droids you're looking for". My vote is (2) makes more sense, because it's possible for the real = target not to implement this draft whatsoever but still function = correctly, because the real target only has to implement media-loopback = RFC. The B2BUAs are the ones to have to read and comply with this spec, = so might as well make them do whatever new thing we need. Besides which = it just feels weird to have to make a UAS respond with "yes it's really = me". :) The next problem is exactly what token to insert in what header/SDP = field. As usual, it's very tricky to pick a field that will survive the = whole way back in the 200 ok. It's basically a game of probability. = Some options: A) A Contact header param or URI param, which is arguably the right = place to put such a token.=20 B) A To header param. C) In the SDP answer. My vote is (C), because I think it has the best chance to survive back, = under the premise that if a media-loopback SDP offer works all the way = from UAC to the responding B2BUA, then an extra attribute in the answer = will likely work too. I think the Contact is the more natural/logical = place, but is doomed to fail. As justification for putting the token in = SDP, I guess we could claim the token signifies the final media target = hasn't been reached, and that this is a media middlebox device = responding instead. -hadriel On Jun 17, 2013, at 3:56 AM, Christer Holmberg = wrote: > (As co-chair) > =20 > Hi, > =20 > Based on the discussions in Orlando, Hadriel has submitted a new = version (-01) of draft-kaplan-straw-sip-traceroute: > =20 > http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt > =20 > As discussed, once the draft is submitted, the chairs will call for WG = adoption of the draft, as base for the following WG charter delivery: > =20 > =93A document defining the requirements for B2BUAs to support = end-to-end and hop-by-hop media-loopback test calls submitted to the = IESG as PS=94 > =20 > So, as no other proposals to implement the delivery have been = submitted, the chairs suggest that the WG adopts = draft-kaplan-straw-sip-traceroute-01 as base for the delivery above, and = that anyone who has issues with that raises those issues it on the list = by Friday 5th July. > =20 > Thanks! > =20 > Christer & Victor > =20 > Ps. The notes from Orlando can be found at: = http://www.ietf.org/proceedings/86/minutes/minutes-86-straw > =20 > =20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From pkyzivat@alum.mit.edu Tue Jun 18 20:16:59 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EA321F9B8E for ; Tue, 18 Jun 2013 20:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.782 X-Spam-Level: X-Spam-Status: No, score=0.782 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyUdJbXHwmmJ for ; Tue, 18 Jun 2013 20:16:54 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 99DD421F9B8F for ; Tue, 18 Jun 2013 20:16:53 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta07.emeryville.ca.mail.comcast.net with comcast id q2kG1l0050FhH24A73Gtab; Wed, 19 Jun 2013 03:16:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([64.55.78.101]) by omta08.emeryville.ca.mail.comcast.net with comcast id q3EY1l00x2B8dzU8U3EeVV; Wed, 19 Jun 2013 03:14:48 +0000 Message-ID: <51C12218.8010905@alum.mit.edu> Date: Tue, 18 Jun 2013 23:14:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: straw@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371611813; bh=ai2ek4Hz7dLlvAZcD5+jGAr0v1bcmLuKfRbEQsnAYGs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cAeZnUlPUUBRomlQGlq5Y4F/ThiF5bCn2yT4VLLaDThRIL7VrjTCC1hEl529LIcCb RO+czS+7C4MdLZ3kHmuHmo22QoMp4mvoxO74X8TdNFcIbREQuXOJuKGHgI9VLfnSFZ FYXaXiZ7SUmsWmENo6AhaHFpGnOtjL29wOZdHAbcjTg38ow8V+6hZN9IqO+igRfCIY THFcYCs7JkUcmEEgYwHqTaiHNloSGUZREmvVtXfHM3hG4mzGsXpsAU2CMcpbZK54bt YLk8pzYvcU4ZJ1OjRP5aUQW1e8Wemvv5tIv7KvfqbQqI7U0FccygRh4XLTDQ1Gi8QG SyRLBwUrR/P5A== Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:16:59 -0000 Hadriel, I was going to agree with you on (C), and then I got thinking... That makes good sense if we are doing traceroute with INVITE and media loopback, but what if we wanted to do a more basic traceroute, say with OPTIONS, where there was no O/A. In that case how would we identify reaching the target? Looking, this isn't covered at all in this draft. But isn't it a reasonable thing to want to do? Thanks, Paul On 6/18/13 2:12 PM, Hadriel Kaplan wrote: > > I should note there is one open issue in this draft. The issue is that there is no way to determine when you've reached the final/real target UAS. > > There are multiple ways of doing it, but each has pro's/con's. > > At a high-level, I think there're two paths: > 1) Have the final UAS insert something somewhere in the signaling back, to say "I'm the target you're looking for". > 2) Have all the B2BUAs insert something in signaling back to say "We're not the droids you're looking for". > > My vote is (2) makes more sense, because it's possible for the real target not to implement this draft whatsoever but still function correctly, because the real target only has to implement media-loopback RFC. The B2BUAs are the ones to have to read and comply with this spec, so might as well make them do whatever new thing we need. Besides which it just feels weird to have to make a UAS respond with "yes it's really me". :) > > The next problem is exactly what token to insert in what header/SDP field. As usual, it's very tricky to pick a field that will survive the whole way back in the 200 ok. It's basically a game of probability. Some options: > A) A Contact header param or URI param, which is arguably the right place to put such a token. > B) A To header param. > C) In the SDP answer. > > My vote is (C), because I think it has the best chance to survive back, under the premise that if a media-loopback SDP offer works all the way from UAC to the responding B2BUA, then an extra attribute in the answer will likely work too. I think the Contact is the more natural/logical place, but is doomed to fail. As justification for putting the token in SDP, I guess we could claim the token signifies the final media target hasn't been reached, and that this is a media middlebox device responding instead. > > -hadriel > > > On Jun 17, 2013, at 3:56 AM, Christer Holmberg wrote: > >> (As co-chair) >> >> Hi, >> >> Based on the discussions in Orlando, Hadriel has submitted a new version (-01) of draft-kaplan-straw-sip-traceroute: >> >> http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt >> >> As discussed, once the draft is submitted, the chairs will call for WG adoption of the draft, as base for the following WG charter delivery: >> >> “A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls submitted to the IESG as PS” >> >> So, as no other proposals to implement the delivery have been submitted, the chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-01 as base for the delivery above, and that anyone who has issues with that raises those issues it on the list by Friday 5th July. >> >> Thanks! >> >> Christer & Victor >> >> Ps. The notes from Orlando can be found at: http://www.ietf.org/proceedings/86/minutes/minutes-86-straw >> >> >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw > From hadriel.kaplan@oracle.com Tue Jun 18 20:43:19 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8DD21E80B6 for ; Tue, 18 Jun 2013 20:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CT-Xv8tJcBa for ; Tue, 18 Jun 2013 20:43:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5952421E8082 for ; Tue, 18 Jun 2013 20:43:06 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5J3h4P2028363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 03:43:05 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J3h3Ig000199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 03:43:04 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J3h3JV003021; Wed, 19 Jun 2013 03:43:03 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jun 2013 20:43:02 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C12218.8010905@alum.mit.edu> Date: Tue, 18 Jun 2013 23:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> <51C12218.8010905@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: straw@ietf.org Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 03:43:19 -0000 On Jun 18, 2013, at 11:14 PM, Paul Kyzivat = wrote: > Hadriel, >=20 > I was going to agree with you on (C), and then I got thinking... >=20 > That makes good sense if we are doing traceroute with INVITE and media = loopback, >=20 > but what if we wanted to do a more basic traceroute, say with OPTIONS, = where there was no O/A. In that case how would we identify reaching the = target? >=20 > Looking, this isn't covered at all in this draft. But isn't it a = reasonable thing to want to do? >=20 Well this is a draft about media loopback traceroute, not OPTIONS = traceroute. I believe RFC 3261 already specifies using Max-Forwards for = a traceroute with OPTIONS, with Proxies responding to it. I don't = believe it says anything about knowing you reached the target, so it = must not be a problem for OPTIONS, right? Ergo, no problem for OPTIONS. = ;) Oh wait... an OPTIONS response can actually contain SDP if I recall, to = indicate media capabilities. So we *could* put one in there. Yeah, = that'll happen... On a more serious note though - I just don't know of any appropriate = header field param we could create that has a high chance of making it = back in a 200 ok. I suppose we could specify *both* the Contact and SDP - for the OPTIONS = case, only put it in a Contact; for the INVITE case, put it in both. = the UAC checks both and if either is there, it knows. -hadriel From pkyzivat@alum.mit.edu Tue Jun 18 21:19:15 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE45821E80BC for ; Tue, 18 Jun 2013 21:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGFmiYFO1dIs for ; Tue, 18 Jun 2013 21:19:10 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 339D011E8135 for ; Tue, 18 Jun 2013 21:19:10 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id q4GX1l00E0S2fkCA14KAp7; Wed, 19 Jun 2013 04:19:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([64.55.78.101]) by omta09.emeryville.ca.mail.comcast.net with comcast id q4Gk1l00X2B8dzU8V4GqJj; Wed, 19 Jun 2013 04:17:05 +0000 Message-ID: <51C130AC.4010107@alum.mit.edu> Date: Wed, 19 Jun 2013 00:16:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> <51C12218.8010905@alum.mit.edu> <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> In-Reply-To: <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371615550; bh=r2NCMwvy14pa2aCQUwVK4CO8I5clmTV7njesACARo7U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b/4IWQQicnPn4CZ5yTelJxv5S+ZBn8fmAoCeP9UsVt8jrQ3DHAjB02dX38iq73Chw r9tBa1EBFXuB8mWCLQy54gCGZuZSVwkl3nkfn8sNTO5VIxqU9L133jgK0EKjc/mkuF O3kFya4HPjJjcsIDq2VhjzI0jQ1o7gAAgRFw+OMozW1W8CWkgKn1JA/Q5t8j5271lx dkne0CyDmSIart812Bounreu7mghlZ1T8Zp6TtKwVGmLJMWJzGIYC/X8aHa+aZAHsd Ox4F/1EZcIzoQ/WLI9vYP26Tc+lXghKia5QNqbI0X9ENJmz81V8SFgjVu7IHPjiULV lqVbw+tiTJ85A== Cc: straw@ietf.org Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 04:19:16 -0000 On 6/18/13 11:43 PM, Hadriel Kaplan wrote: > > On Jun 18, 2013, at 11:14 PM, Paul Kyzivat wrote: > >> Hadriel, >> >> I was going to agree with you on (C), and then I got thinking... >> >> That makes good sense if we are doing traceroute with INVITE and media loopback, >> >> but what if we wanted to do a more basic traceroute, say with OPTIONS, where there was no O/A. In that case how would we identify reaching the target? >> >> Looking, this isn't covered at all in this draft. But isn't it a reasonable thing to want to do? >> > > Well this is a draft about media loopback traceroute, not OPTIONS traceroute. I believe RFC 3261 already specifies using Max-Forwards for a traceroute with OPTIONS, with Proxies responding to it. I don't believe it says anything about knowing you reached the target, so it must not be a problem for OPTIONS, right? Ergo, no problem for OPTIONS. ;) Well, this draft is also about getting through SBCs. Some of the same issues apply for getting OPTIONS through SBCs with the Max-Forwards preserved. And there might be the same issue of wanting to determine if you have gotten to the end. OTOH, you have a point - how does regular traceroute with OPTIONS know it has gotten to the end? The only way I can see is that it tries to go one hop further and finds that the return is from the same place. Is there any other way? If that works, then why wouldn't the same thing work for the traceroute in this draft? > Oh wait... an OPTIONS response can actually contain SDP if I recall, to indicate media capabilities. So we *could* put one in there. Yeah, that'll happen... > > On a more serious note though - I just don't know of any appropriate header field param we could create that has a high chance of making it back in a 200 ok. > > I suppose we could specify *both* the Contact and SDP - for the OPTIONS case, only put it in a Contact; for the INVITE case, put it in both. the UAC checks both and if either is there, it knows. OK, after this discussion, I suggest one of the following: - do whatever is done with regular traceroute with OPTIONS. - do your option (C) and forget about my question. Thanks, Paul From prvs=688265bda6=christer.holmberg@ericsson.com Tue Jun 18 21:26:30 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB33021E80BF for ; Tue, 18 Jun 2013 21:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgRSPs9ilxtu for ; Tue, 18 Jun 2013 21:26:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7C611E80D7 for ; Tue, 18 Jun 2013 21:26:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-6c-51c132efac24 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2E.78.18006.FE231C15; Wed, 19 Jun 2013 06:26:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 06:26:23 +0200 From: Christer Holmberg To: Hadriel Kaplan , "straw@ietf.org" Thread-Topic: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 Thread-Index: AQHObE+uEhsxKT6EBE+u+HXehRSj95k8cUZA Date: Wed, 19 Jun 2013 04:26:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AC126@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvre57o4OBBiuvyVl82vSJ2eJW82NW ByaPJUt+Mnl8fHqLJYApitsmKbGkLDgzPU/fLoE7Y8LLZawF32QqZixfwdjAuEG8i5GTQ0LA RGLX/1ZmCFtM4sK99WxdjFwcQgKHGSUe3FzBCuEsYpSYc+QLUxcjBwebgIVE9z9tkAYRgWCJ dYvWMYLYwgLuEqtfb2aCiHtIPJ/zlQ3CNpLY8+A/K0gri4CqxMrnKiBhXgFficXzvrNAjG9k lFjRtxrsCE4BO4kfK0+CzWEEOuj7qTVgNrOAuMSHg9ehDhWQWLLnPJQtKvHy8T9WCFtJonHJ E1aIej2JG1OnsEHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9NzMxJ LzfaxAiMhoNbfqvuYLxzTuQQozQHi5I478dTuwKFBNITS1KzU1MLUovii0pzUosPMTJxcIII LqkGRqutem3G+lOaLr3jv/EztXbfyeYyndBLSVvMp9Sui6lM+XHRpHj6mbMJX78yVPjPCNjg dWzq9x1sOivvXvy5VWZv7Nb2sJ2vWd89jb95ekaOyoE7U/6F2l3j1Lx7mDVJ+EbLpj+RLw4y 3Po/Py0wrV5y895ZPUuXh+ptbk3fHOWt+inoiNQDI1MlluKMREMt5qLiRAC7RPdIWQIAAA== Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 04:26:30 -0000 (As co-chair) Hi Hadriel, Thanks for pointing out the open issue. However, we don't need to solve it in order to adopt the draft :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: straw-bounces@ietf.org [mailto:straw-bounces@ietf.org] Puo= lesta Hadriel Kaplan L=E4hetetty: 18. kes=E4kuuta 2013 21:13 Vastaanottaja: straw@ietf.org Aihe: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 I should note there is one open issue in this draft. The issue is that the= re is no way to determine when you've reached the final/real target UAS. There are multiple ways of doing it, but each has pro's/con's. At a high-level, I think there're two paths: 1) Have the final UAS insert something somewhere in the signaling back, to = say "I'm the target you're looking for". 2) Have all the B2BUAs insert something in signaling back to say "We're not= the droids you're looking for". My vote is (2) makes more sense, because it's possible for the real target = not to implement this draft whatsoever but still function correctly, becaus= e the real target only has to implement media-loopback RFC. The B2BUAs are= the ones to have to read and comply with this spec, so might as well make = them do whatever new thing we need. Besides which it just feels weird to h= ave to make a UAS respond with "yes it's really me". :) The next problem is exactly what token to insert in what header/SDP field. = As usual, it's very tricky to pick a field that will survive the whole way= back in the 200 ok. It's basically a game of probability. Some options: A) A Contact header param or URI param, which is arguably the right place t= o put such a token.=20 B) A To header param. C) In the SDP answer. My vote is (C), because I think it has the best chance to survive back, und= er the premise that if a media-loopback SDP offer works all the way from UA= C to the responding B2BUA, then an extra attribute in the answer will likel= y work too. I think the Contact is the more natural/logical place, but is = doomed to fail. As justification for putting the token in SDP, I guess we = could claim the token signifies the final media target hasn't been reached,= and that this is a media middlebox device responding instead. -hadriel On Jun 17, 2013, at 3:56 AM, Christer Holmberg wrote: > (As co-chair) > =20 > Hi, > =20 > Based on the discussions in Orlando, Hadriel has submitted a new version = (-01) of draft-kaplan-straw-sip-traceroute: > =20 > http://www.ietf.org/id/draft-kaplan-straw-sip-traceroute-01.txt > =20 > As discussed, once the draft is submitted, the chairs will call for WG ad= option of the draft, as base for the following WG charter delivery: > =20 > "A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls submitted to the IESG as PS" > =20 > So, as no other proposals to implement the delivery have been submitted, = the chairs suggest that the WG adopts draft-kaplan-straw-sip-traceroute-01 = as base for the delivery above, and that anyone who has issues with that ra= ises those issues it on the list by Friday 5th July. > =20 > Thanks! > =20 > Christer & Victor > =20 > Ps. The notes from Orlando can be found at: http://www.ietf.org/proceedin= gs/86/minutes/minutes-86-straw > =20 > =20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw From hadriel.kaplan@oracle.com Tue Jun 18 22:32:21 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB621F9D0A for ; Tue, 18 Jun 2013 22:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSZ8oiZSGsnt for ; Tue, 18 Jun 2013 22:32:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A044B21F9D07 for ; Tue, 18 Jun 2013 22:32:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5J5WAvZ008677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 05:32:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J5W96p005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 05:32:10 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J5W9lt010105; Wed, 19 Jun 2013 05:32:09 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jun 2013 22:32:09 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C130AC.4010107@alum.mit.edu> Date: Wed, 19 Jun 2013 01:32:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8776753B-F95F-49F2-BBC3-E2AB984DB677@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> <51C12218.8010905@alum.mit.edu> <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> <51C130AC.4010107@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: straw@ietf.org Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 05:32:21 -0000 On Jun 19, 2013, at 12:16 AM, Paul Kyzivat = wrote: > Well, this draft is also about getting through SBCs. Some of the same = issues apply for getting OPTIONS through SBCs with the Max-Forwards = preserved. And there might be the same issue of wanting to determine if = you have gotten to the end. I'm not sure I would go near OPTIONS handling and SBCs. We had a = massive debate about that on one of the old mailing lists a few years = ago when someone (Paul Jones?) submitted a draft on doing health = checking using OPTIONS to SBCs. We all do it, but no one could agree on = what the right things to do are and it generated a LOT of debate if I = recall, with no consensus. > OTOH, you have a point - how does regular traceroute with OPTIONS know = it has gotten to the end? The only way I can see is that it tries to go = one hop further and finds that the return is from the same place. Is = there any other way? >=20 > If that works, then why wouldn't the same thing work for the = traceroute in this draft? You don't know you reached the real target because the 200 ok looks the = same regardless who sent it, because B2BUAs generally replace received = Contact URIs (along with most other such identifying header fields/URIs) = with their own. After all, they're a UA on each side. :) Imagine a scenario like: Alice -> B2BUA1 -> B2BUA2 -> Bob. =20 Round-1) Alice makes test call with MF=3D0. B2BUA1 answers 200 ok with = Contact of itself. Alice receives answer with Contact of B2BUA1. Round-2) Alice makes test call with MF=3D1. B2BUA1 forwards it, B2BUA2 = answers 200 ok with Contact of itself, which B2BUA1 dutifully replaces = with Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. Round-3) Alice makes test call with MF=3D2. B2BUA1 and B2BUA2 forward = it, Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully = replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with = Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. Round-4) Alice makes test call with MF=3D3. Bob answers 200 ok with = contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, = and B2BUA1 dutifully replaces with Contact of B2BUA1. Alice receives = answer with Contact of B2BUA1. Alice can't know to stop after Round-3, or even after Round-4. = Arguably, the problem is really that Alice can't determine the = difference in any round above to begin with. If we could solve that, = then we could just let Alice do Round-4, detecting it's the same result = as Round-3, and stopping at that point. But I don't know how to do that in a way that B2BUAs (and in particular = SBCs and their owners), would allow to be sent through. Wellll... maybe = I do - I suppose we could put in a hashed cookie in a defined Contact = header param. Something that hashes to the same value given the same = received inputs, but is useless as a target. It doesn't even need to be = defined how to generate it; just something with that property, so that = Alice can tell she's reaching the same UAS or not. It might work. Have = to chew on it for a while. -hadriel From gsalguei@cisco.com Tue Jun 18 23:09:00 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7421F9F50 for ; Tue, 18 Jun 2013 23:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY8U6qEwKwoD for ; Tue, 18 Jun 2013 23:08:56 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id E33AD21F9F4D for ; Tue, 18 Jun 2013 23:08:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5J68mKG026382 for ; Wed, 19 Jun 2013 02:08:48 -0400 (EDT) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5J68mnT027371; Wed, 19 Jun 2013 02:08:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <8776753B-F95F-49F2-BBC3-E2AB984DB677@oracle.com> Date: Wed, 19 Jun 2013 02:08:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <43246A9A-7A86-4AEB-A8CD-4E624A7F3046@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> <51C12218.8010905@alum.mit.edu> <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> <51C130AC.4010107@alum.mit.edu> <8776753B-F95F-49F2-BBC3-E2AB984DB677@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: straw@ietf.org, Paul Kyzivat Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 06:09:01 -0000 On Jun 19, 2013, at 1:32 AM, Hadriel Kaplan = wrote: >=20 > On Jun 19, 2013, at 12:16 AM, Paul Kyzivat = wrote: >=20 >> Well, this draft is also about getting through SBCs. Some of the same = issues apply for getting OPTIONS through SBCs with the Max-Forwards = preserved. And there might be the same issue of wanting to determine if = you have gotten to the end. >=20 > I'm not sure I would go near OPTIONS handling and SBCs. We had a = massive debate about that on one of the old mailing lists a few years = ago when someone (Paul Jones?) submitted a draft on doing health = checking using OPTIONS to SBCs. We all do it, but no one could agree on = what the right things to do are and it generated a LOT of debate if I = recall, with no consensus. Yep. It generated LOTS of discussion (on the order of hundreds of = emails) and we never could come to an agreeable consensus on how to move = forward (a shame IMO). Here it is: http://tools.ietf.org/html/draft-jones-sip-options-ping >=20 >=20 >> OTOH, you have a point - how does regular traceroute with OPTIONS = know it has gotten to the end? The only way I can see is that it tries = to go one hop further and finds that the return is from the same place. = Is there any other way? >>=20 >> If that works, then why wouldn't the same thing work for the = traceroute in this draft? >=20 > You don't know you reached the real target because the 200 ok looks = the same regardless who sent it, because B2BUAs generally replace = received Contact URIs (along with most other such identifying header = fields/URIs) with their own. After all, they're a UA on each side. :) >=20 > Imagine a scenario like: Alice -> B2BUA1 -> B2BUA2 -> Bob. =20 >=20 > Round-1) Alice makes test call with MF=3D0. B2BUA1 answers 200 ok = with Contact of itself. Alice receives answer with Contact of B2BUA1. >=20 > Round-2) Alice makes test call with MF=3D1. B2BUA1 forwards it, = B2BUA2 answers 200 ok with Contact of itself, which B2BUA1 dutifully = replaces with Contact of B2BUA1. Alice receives answer with Contact of = B2BUA1. >=20 > Round-3) Alice makes test call with MF=3D2. B2BUA1 and B2BUA2 forward = it, Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully = replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with = Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. >=20 > Round-4) Alice makes test call with MF=3D3. Bob answers 200 ok with = contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, = and B2BUA1 dutifully replaces with Contact of B2BUA1. Alice receives = answer with Contact of B2BUA1. >=20 > Alice can't know to stop after Round-3, or even after Round-4. = Arguably, the problem is really that Alice can't determine the = difference in any round above to begin with. If we could solve that, = then we could just let Alice do Round-4, detecting it's the same result = as Round-3, and stopping at that point. >=20 > But I don't know how to do that in a way that B2BUAs (and in = particular SBCs and their owners), would allow to be sent through. = Wellll... maybe I do - I suppose we could put in a hashed cookie in a = defined Contact header param. Something that hashes to the same value = given the same received inputs, but is useless as a target. It doesn't = even need to be defined how to generate it; just something with that = property, so that Alice can tell she's reaching the same UAS or not. It = might work. Have to chew on it for a while. >=20 > -hadriel >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw >=20 From hadriel.kaplan@oracle.com Wed Jun 19 01:43:38 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33F21F9FB2 for ; Wed, 19 Jun 2013 01:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVukXPbY5r-Q for ; Wed, 19 Jun 2013 01:43:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5574821F9FAA for ; Wed, 19 Jun 2013 01:43:33 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5J8bETc031781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Jun 2013 08:37:15 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J8hLbH022070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jun 2013 08:43:22 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5J8hLdq026297 for ; Wed, 19 Jun 2013 08:43:21 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 01:43:21 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <20130418141719.11752.3305.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 04:43:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> References: <20130418141719.11752.3305.idtracker@ietfa.amsl.com> To: "straw@ietf.org" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [straw] Open issue in loop-detection too (not traceroute) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 08:43:38 -0000 Howdy, Apparently there is an open issue in the loop-detection draft as well, = which I kinda forgot about. I blame my co-author Victor for me having = forgotten this though, since he submitted the most recent draft version = because I was taking too long. So it's really his fault for being so = diligent. :) Anyway=85 the open issue is in section 4: [Note: should we require all B2BUAs to perform Via-header loop- detection as well, even if they themselves don't forward on the Via headers?] One of the WG chairs (I won't say who, but it's not Victor) asked me to = also put my 2-cents in for my preference, to get the ball rolling = towards discussion and consensus. But personally, I don't have a strong = opinion whether this should be required or not. I can see some = arguments either way. It would be nice to detect loops sooner/faster = than max-forwards would, for the cases where it could be detected. On = the other hand in the looping cases I've seen the via-header check would = never have stopped them - the scenarios for detecting a loop using = via-header checking are more limited in full B2BUA deployments. And = implementing Via-header loop-detection is a lot more work, extremely = difficult if not impossible in some systems, and might impact = performance on systems, so having this as a MUST statement means vendors = might weasel their way out of the whole RFC. (the philosophy here being = that the RFCs in STRAW are only as enforceable as the power of = purchasers of systems to ask their vendors to do them, because they make = sense to do) I guess we could hedge and do a "SHOULD" or "RECOMMENDED". But that's = really just a cop-out. A wise Jedi master once said: Do or do not, = there is no try. -hadriel On Apr 18, 2013, at 10:17 AM, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-00 From prvs=58822a6647=christer.holmberg@ericsson.com Wed Jun 19 03:54:17 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ED921F9B14 for ; Wed, 19 Jun 2013 03:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0L4jOPnkiS5 for ; Wed, 19 Jun 2013 03:54:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DD9E321F9B18 for ; Wed, 19 Jun 2013 03:54:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-ca-51c18dd1dfcb Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 08.E5.18006.1DD81C15; Wed, 19 Jun 2013 12:54:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 12:54:09 +0200 From: Christer Holmberg To: Hadriel Kaplan , "straw@ietf.org" Thread-Topic: [straw] Open issue in loop-detection too (not traceroute) Thread-Index: AQHObMkdswbj+2PES0eA8SePNavkQ5k83N7w Date: Wed, 19 Jun 2013 10:54:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3AFD1D@ESESSMB209.ericsson.se> References: <20130418141719.11752.3305.idtracker@ietfa.amsl.com> <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> In-Reply-To: <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> 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+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre7F3oOBBjM/m1t82vSJ2eJW82NW ByaPJUt+Mnl8fHqLJYApitsmKbGkLDgzPU/fLoE7Y0bLFbaCaUwVzS8DGxivMnYxcnBICJhI 3Dln0sXICWSKSVy4t56ti5GLQ0jgMKPEgXePWSGcRYwST9oWsIE0sAlYSHT/0wZpEBEIlli3 aB0jiC0s4Cbx+voXVoi4u8T6jw+YIWwjiQPPv4DVsAioStxbdAbM5hXwlXi79y6YLSRQInHx yS0wm1PATuL1jhVgNiPQQd9PrWECsZkFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC/KIosbxf DqJcR2LB7k9sELa2xLKFr5kh1gpKnJz5hGUCo+gsJFNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL jTYxAuPg4JbfqjsY75wTOcQozcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJL qoExhvlV5P1jP1pNpz0wny8Q9MRLyfRI3v6j/ktSOJcdKNTY0vs4yFInKJ7vzIG324LeKP82 z/LI+jRnjjLDKuuZOVsD25rOqBU63jQKCPoXey91rszlzn8sarOqeJ9E//v2/JSL6pdv3hKl uYtbD8+fXJfjljRhFaNO2ef8k+efXjxbzMD26PMtJZbijERDLeai4kQAbD9JKVYCAAA= Subject: Re: [straw] Open issue in loop-detection too (not traceroute) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 10:54:17 -0000 > One of the WG chairs (I won't say who, but it's not Victor) asked me to a= lso put my 2-cents in for my preference, It's good that you didn't mention WHICH WG, because otherwise it would have= been pretty obvious who you were talking about ;) Regards, Christer From albrecht.schwarz@alcatel-lucent.com Wed Jun 19 04:20:40 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552121F9A08; Wed, 19 Jun 2013 04:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFgVxKr99ikg; Wed, 19 Jun 2013 04:20:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBE21F99FB; Wed, 19 Jun 2013 04:20:34 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r5JBKRQj001944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 06:20:27 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5JBKRfD009438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 07:20:27 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 07:20:17 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 13:19:55 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , Hadriel Kaplan , "" Thread-Topic: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types Thread-Index: AQHOalAj8gpobm3rD0OdKV/RhKM1q5k36qyAgAT7yiA= Date: Wed, 19 Jun 2013 11:19:54 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC068C36@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20130615192422.22852.89043.idtracker@ietfa.amsl.com> <786615F3A85DF44AA2A76164A71FE1AC065CCF@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C39C367@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C39C367@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "megaco@ietf.org" Subject: Re: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2013 11:20:40 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Christer, Hadriel, I don't want to delay the publication. Don't see any principle issue, too. In case of a future revision of this RFC, then it might be beneficial to tr= y to add a term definition for B2BUA (because the whole taxonomy is actuall= y based on this term). 2nd I suppose a difference between B2BUA vs PROXY, hence might be worth as = well to point out differences. Personally, I could see following resolution proposal (based on ITU terms): Background: the subject as such was studied in Y.1251 (http://www.itu.int/r= ec/dologin_pub.asp?lang=3De&id=3DT-REC-Y.1251-200208-I!!PDF-E&type=3Ditems = ). Possible definition of term "B2BUA": B2BUA: provides a service interworking function (according clause 3.2/ITU-= T Y.1251) with following limitations, 1. network planes: only IP control and IP user plane; 2. protocol stack: same protocol at each side of the service interwor= king function. NOTE 1: hence, a B2BUA is not a proxy. Proxy (derived from ITU-T Y.2902): A system authorized to work on behalf of= another system including responding to protocol requests. NOTE 1: hence, a proxy does not provide any interworking function (neither = service interworking nor network interworking). NOTE 2: a proxy as network element is an intermediary node in the sense of = identical protocol stacks at incoming and outgoing interfaces of the proxy. SIP B2BUA: provides a B2BUA function with for the SIP, i.e., a service in= terworking function (according clause 3.2/ITU-T Y.1251) in the IP control p= lane. NOTE: the service interworking function may include as well the interworkin= g of the protocol stack for SIP transport (e.g., SIP-over-UDP/IP4 to SIP-ov= er-SCTP/IPv6 interworking). ... and then subsequent, derived term definitions for media plane B2BUA back-to-back IP host etc Just some thoughts, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Sonntag, 16. Juni 2013 11:04 To: Schwarz, Albrecht (Albrecht); Hadriel Kaplan; Subject: VS: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway mo= del and media plane b2bua types (As co-chair) Hi Albrecht, I do appreciate the fact that you have taken a look at the draft, and studi= ed its applicability from a SG16 perspective. In the conclusion part, you ask whether there is a need to provide feedback= to STRAW. Keep in mind that the WGLC for the draft has finished, and that publication= has been requested by the chairs. Now, that does not prevent us from taking the draft back to the WG, and do = changes, but in order for that to happen there normally has to be some issu= es that need to be changed/addressed in order to publish the document as an= RFC. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: straw-bounces@ietf.org [mai= lto:straw-bounces@ietf.org] Puolesta Schwarz, Albrecht (Albrecht) L=E4hetetty: 16. kes=E4kuuta 2013 8:13 Vastaanottaja: Hadriel Kaplan; > Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and= media plane b2bua types Hi Hadriel, fyi, some high-level comments to the taxonomy draft from perspective of dec= omposed SBCs (according H.248 model) http://ftp3.itu.int/av-arch/avc-site/2= 013-2016/1306_Osl/AVD-4391.zip Regards, Albrecht _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw --_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Christer, Hadriel,

 

I don't want to delay the pu= blication.

Don't see any principle issu= e, too.

 

In case of a future revision= of this RFC, then it might be beneficial to try to add a term definition f= or B2BUA (because the whole taxonomy is actually based on this term).<= /o:p>

2nd I suppose a difference b= etween B2BUA vs PROXY, hence might be worth as well to point out difference= s.

 

Personally, I could see foll= owing resolution proposal (based on ITU terms):

Background: the subject as s= uch was studied in Y.1251 (http://w= ww.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-Y.1251-200208-I!!PDF= -E&type=3Ditems ).

 

Possible definition of term “B2BUA&= #8221;:

 

B2BUA:  provides a service interworking function (according clause 3.2/IT= U-T Y.1251) with following limitations,

1. &nb= sp;     network plane= s: only IP control and IP user plane;

2. &nb= sp;     protocol stac= k: same protocol at each side of the service interworking function.

NOTE 1: hence, a B2BUA is not a proxy.

 

Proxy (derived from ITU-T Y.2902): A system authorized to work on behalf of another system inc= luding responding to protocol requests.

NOTE 1: hence, a proxy does not provide any interworking function (neither service interw= orking nor network interworking).

NOTE 2: a proxy as network element is an intermediary node in the sense of identical protocol stacks at incom= ing and outgoing interfaces of the proxy.

 

SIP B2BUA:   provides a B2BUA function with for the SIP, i.e., a service in= terworking function (according clause 3.2/ITU-T Y.1251) in the IP control plane.

NOTE: the service interworking function may = include as well the interworking of the protocol stack for SIP transport (e= .g., SIP-over-UDP/IP4 to SIP-over-SCTP/IPv6 interworking).

 

… and then subsequent,= derived term definitions for

media plane B2BUA=

back-to-back IP host

etc

 

Just some thoughts,

Albrecht

 

 

-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sonntag, 16. Juni 2013 11:04
To: Schwarz, Albrecht (Albrecht); Hadriel Kaplan; <straw@ietf.org> Subject: VS: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway mo= del and media plane b2bua types

 

(As co-chair)

 

Hi Albrecht,

 

I do appreciate the fact that you have taken a lo= ok at the draft, and studied its applicability from a SG16 perspective.

 

In the conclusion part, you ask whether there is = a need to provide feedback to STRAW.

 

Keep in mind that the WGLC for the draft has fini= shed, and that publication has been requested by the chairs.

 

Now, that does not prevent us from taking the dra= ft back to the WG, and do changes, but in order for that to happen there no= rmally has to be some issues that need to be changed/addressed in order to = publish the document as an RFC.

 

Regards,

 

Christer

 

 

 

-----Alkuper=E4inen viesti-----

L=E4hett=E4j=E4: straw-bounc= es@ietf.org [mailto:straw-bounces@ietf.org<= /span>] Puolesta Schwarz, Albrecht (Albrecht)

L=E4hetetty: 16. kes=E4kuuta 2013 8:13=

Vastaanottaja: Hadriel Kaplan; <s= traw@ietf.org>

Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: de= composed gateway model and media plane b2bua types

 

Hi Hadriel,

fyi, some high-level comments to the taxonomy dra= ft from perspective of decomposed SBCs (according H.248 model) http://ftp3.itu= .int/av-arch/avc-site/2013-2016/1306_Osl/AVD-4391.zip

 

Regards,

Albrecht

_______________________________________________

straw mailing list

straw@ietf.org=

https://www.ie= tf.org/mailman/listinfo/straw

--_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_-- From pkyzivat@alum.mit.edu Thu Jun 20 09:14:47 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E840121F9CF8 for ; Thu, 20 Jun 2013 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Q9FMB7gnDl for ; Thu, 20 Jun 2013 09:14:43 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F421F9DD1 for ; Thu, 20 Jun 2013 09:14:42 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id qeHt1l0041ei1Bg59gEih2; Thu, 20 Jun 2013 16:14:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id qgEh1l0153ZTu2S3kgEhGD; Thu, 20 Jun 2013 16:14:42 +0000 Message-ID: <51C32A72.1070306@alum.mit.edu> Date: Thu, 20 Jun 2013 12:14:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> <51C12218.8010905@alum.mit.edu> <0CDB7E6F-C120-4135-B872-A56BFF4981AD@oracle.com> <51C130AC.4010107@alum.mit.edu> <8776753B-F95F-49F2-BBC3-E2AB984DB677@oracle.com> <43246A9A-7A86-4AEB-A8CD-4E624A7F3046@cisco.com> In-Reply-To: <43246A9A-7A86-4AEB-A8CD-4E624A7F3046@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371744882; bh=+5KKEAV4kc4rOXwVezwefGKYiCqoVujClYMDEkZdFY0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r9m+15UKV/t9CE1lW5rAt5P7P4XOV7dpRiYZgCUZAcEjXCVh06XO8EiyfnynSZfCd 7XRI8F35ChFAYg0lrMxqlM/jZvi5DVsGc71hpnRjMPVrXLB9Q12yMFs6xjrDK9GmU5 joB5+C4z4zCdArezrTKZ++r71VbLIlWj3EfF94q0Z6wAOROYmt5vT6ZejA7O/nCsTw dgmIudLi77PQa2FqCRkhpq+C2g+2cG2iT2JEqRRDTn546XxDBkTu9jeYYCZUcfqTgV HlTKpQxmQnegH2Ju2s0w6x8ahqrOvY+yQd22UeCpeYol670IlOp3mUypFYjzjtIwpw 7do/vnDFH/fnw== Cc: Hadriel Kaplan , straw@ietf.org Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2013 16:14:48 -0000 OK, forget it. Option (C) works for me. Thanks, Paul On 6/19/13 2:08 AM, Gonzalo Salgueiro wrote: > > On Jun 19, 2013, at 1:32 AM, Hadriel Kaplan wrote: > >> >> On Jun 19, 2013, at 12:16 AM, Paul Kyzivat wrote: >> >>> Well, this draft is also about getting through SBCs. Some of the same issues apply for getting OPTIONS through SBCs with the Max-Forwards preserved. And there might be the same issue of wanting to determine if you have gotten to the end. >> >> I'm not sure I would go near OPTIONS handling and SBCs. We had a massive debate about that on one of the old mailing lists a few years ago when someone (Paul Jones?) submitted a draft on doing health checking using OPTIONS to SBCs. We all do it, but no one could agree on what the right things to do are and it generated a LOT of debate if I recall, with no consensus. > > Yep. It generated LOTS of discussion (on the order of hundreds of emails) and we never could come to an agreeable consensus on how to move forward (a shame IMO). Here it is: > > http://tools.ietf.org/html/draft-jones-sip-options-ping > >> >> >>> OTOH, you have a point - how does regular traceroute with OPTIONS know it has gotten to the end? The only way I can see is that it tries to go one hop further and finds that the return is from the same place. Is there any other way? >>> >>> If that works, then why wouldn't the same thing work for the traceroute in this draft? >> >> You don't know you reached the real target because the 200 ok looks the same regardless who sent it, because B2BUAs generally replace received Contact URIs (along with most other such identifying header fields/URIs) with their own. After all, they're a UA on each side. :) >> >> Imagine a scenario like: Alice -> B2BUA1 -> B2BUA2 -> Bob. >> >> Round-1) Alice makes test call with MF=0. B2BUA1 answers 200 ok with Contact of itself. Alice receives answer with Contact of B2BUA1. >> >> Round-2) Alice makes test call with MF=1. B2BUA1 forwards it, B2BUA2 answers 200 ok with Contact of itself, which B2BUA1 dutifully replaces with Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. >> >> Round-3) Alice makes test call with MF=2. B2BUA1 and B2BUA2 forward it, Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. >> >> Round-4) Alice makes test call with MF=3. Bob answers 200 ok with contact of Bob, which B2BUA2 dutifully replaces with Contact of B2BUA2, and B2BUA1 dutifully replaces with Contact of B2BUA1. Alice receives answer with Contact of B2BUA1. >> >> Alice can't know to stop after Round-3, or even after Round-4. Arguably, the problem is really that Alice can't determine the difference in any round above to begin with. If we could solve that, then we could just let Alice do Round-4, detecting it's the same result as Round-3, and stopping at that point. >> >> But I don't know how to do that in a way that B2BUAs (and in particular SBCs and their owners), would allow to be sent through. Wellll... maybe I do - I suppose we could put in a hashed cookie in a defined Contact header param. Something that hashes to the same value given the same received inputs, but is useless as a target. It doesn't even need to be defined how to generate it; just something with that property, so that Alice can tell she's reaching the same UAS or not. It might work. Have to chew on it for a while. >> >> -hadriel >> >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw >> > > From brett@broadsoft.com Fri Jun 21 06:34:18 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AF921E810B for ; Fri, 21 Jun 2013 06:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpTdEqFCSriX for ; Fri, 21 Jun 2013 06:34:13 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31221E811B for ; Fri, 21 Jun 2013 06:34:12 -0700 (PDT) Received: from CASUMHUB05.citservers.local (172.16.98.229) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Jun 2013 06:37:45 -0700 Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Fri, 21 Jun 2013 06:37:45 -0700 From: Brett Tate To: Hadriel Kaplan , "straw@ietf.org" Thread-Topic: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 Thread-Index: AQHObFAwlatG/4AftUGJJUad49AqeJlAGQkQ Date: Fri, 21 Jun 2013 13:37:44 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196B7F46@MBX07.citservers.local> References: <7594FB04B1934943A5C02806D1A2204B1C39EC4C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [straw] Open issue in draft-kaplan-straw-sip-traceroute-01 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2013 13:34:18 -0000 > At a high-level, I think there're two paths: > 1) Have the final UAS insert something somewhere in the=20 > signaling back, to say "I'm the target you're looking for". > 2) Have all the B2BUAs insert something in signaling back=20 > to say "We're not the droids you're looking for". Option 2 sounds appropriate. However I think that section 3.2 would need t= o clarify how it knows that it is not the droid you're looking for. I assu= me that the answer is that it is the droid you're looking for unless Max-Fo= rwards is the reason that the request was not relayed to a subsequent exter= nal (or internal) destination. > The next problem is exactly what token to insert in what=20 > header/SDP field. As usual, it's very tricky to pick a=20 > field that will survive the whole way back in the 200 ok. > It's basically a game of probability. Some options: > A) A Contact header param or URI param, which is=20 > arguably the right place to put such a token. > B) A To header param. > C) In the SDP answer. This draft basically introduces a new service (RFC 5373 variant) to trigger= automatically answering a call (thus there might be similar RFC 5373 IPR c= laims). Unless it would be appropriate to communicate the "reason for auto= answer" within the above locations, it sounds appropriate to introduce a n= ew header, new use for Answer-Mode, or new use for Reason header. Should this draft be an RFC 5373 extension for auto-answering? For instanc= e, the draft could introduce a new answer-mode-param (or new answer-mode-va= lue). The new parameter could be sent within INVITE to clearly communicate= to middle box to follow this draft. The new parameter (and/or another par= ameter) could be within INVITE's 2xx to satisfy the open issue. Thanks, Brett From victor.pascual.avila@gmail.com Thu Jun 27 00:47:48 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A627D21F9B3A for ; Thu, 27 Jun 2013 00:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6IpoMBEuUsI for ; Thu, 27 Jun 2013 00:47:48 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C725B21F9B5B for ; Thu, 27 Jun 2013 00:47:41 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so431309lab.7 for ; Thu, 27 Jun 2013 00:47: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:content-transfer-encoding; bh=Z1kB0yH/T+0l1JeOj7FPaBSW8XAxumjhqoIYaFN0cxg=; b=SNRqHc0jKEAD+ehPHsANWncyDYbKDzatRW6LwzdMprhE4LDD2vy726jpWMoxEjLyLp 5PyNQUVWT9horSFpwEwObYjGwusrA01/EqAsxW3RspHJNjlKisDf8m+mRvgBHeXRrjyI /79XCufpfd/QiO5SYQstm/cTkQYpZ1KjF3ztC0IMEmRPyXMf7Yy/RjphrHt+rOwRQtbx waaJQdsawjwRk+VMbk4JHQyZ/FnQ0j2ecTv3tQICyOQhKEQyiaU/nWNwNMdiFhNfhA/C cEzl3SiRRsUEtgPxpZMcrRlCMvY1aErUzmG9v7xlTRHiCqTDPDXn5kXV18u7YoVG9hFB RnZA== MIME-Version: 1.0 X-Received: by 10.112.144.97 with SMTP id sl1mr3709742lbb.56.1372319259366; Thu, 27 Jun 2013 00:47:39 -0700 (PDT) Received: by 10.114.180.100 with HTTP; Thu, 27 Jun 2013 00:47:39 -0700 (PDT) In-Reply-To: <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> References: <20130418141719.11752.3305.idtracker@ietfa.amsl.com> <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> Date: Thu, 27 Jun 2013 09:47:39 +0200 Message-ID: From: Victor Pascual Avila To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "straw@ietf.org" Subject: Re: [straw] Open issue in loop-detection too (not traceroute) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 07:47:48 -0000 I agree with the comments below -Victor On Wed, Jun 19, 2013 at 10:43 AM, Hadriel Kaplan wrote: > Howdy, > Apparently there is an open issue in the loop-detection draft as well, wh= ich I kinda forgot about. I blame my co-author Victor for me having forgot= ten this though, since he submitted the most recent draft version because I= was taking too long. So it's really his fault for being so diligent. :) > > Anyway=E2=80=A6 the open issue is in section 4: > [Note: should we require all B2BUAs to perform Via-header loop- > detection as well, even if they themselves don't forward on the Via > headers?] > > One of the WG chairs (I won't say who, but it's not Victor) asked me to a= lso put my 2-cents in for my preference, to get the ball rolling towards di= scussion and consensus. But personally, I don't have a strong opinion whet= her this should be required or not. I can see some arguments either way. = It would be nice to detect loops sooner/faster than max-forwards would, for= the cases where it could be detected. On the other hand in the looping ca= ses I've seen the via-header check would never have stopped them - the scen= arios for detecting a loop using via-header checking are more limited in fu= ll B2BUA deployments. And implementing Via-header loop-detection is a lot = more work, extremely difficult if not impossible in some systems, and might= impact performance on systems, so having this as a MUST statement means ve= ndors might weasel their way out of the whole RFC. (the philosophy here bei= ng that the RFCs in STRAW are only as enforceable as the power of purchaser= s of systems to ask their vendors to do them, because they make sense to do= ) > > I guess we could hedge and do a "SHOULD" or "RECOMMENDED". But that's re= ally just a cop-out. A wise Jedi master once said: Do or do not, there is = no try. > > -hadriel > > > On Apr 18, 2013, at 10:17 AM, internet-drafts@ietf.org wrote: > >> 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-00 > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From christer.holmberg@ericsson.com Thu Jun 27 04:08:49 2013 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB85C21F9D10 for ; Thu, 27 Jun 2013 04:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.151 X-Spam-Level: X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPI6LlWTD2OT for ; Thu, 27 Jun 2013 04:08:44 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA121F962D for ; Thu, 27 Jun 2013 04:08:44 -0700 (PDT) X-AuditID: c1b4fb38-b7fc16d000004a21-88-51cc1d3a7778 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A2.3D.18977.A3D1CC15; Thu, 27 Jun 2013 13:08:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 13:08:42 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: [straw] Open issue in loop-detection too (not traceroute) Thread-Index: AQHObMkdswbj+2PES0eA8SePNavkQ5lJcxKw Date: Thu, 27 Jun 2013 11:08:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BC699@ESESSMB209.ericsson.se> References: <20130418141719.11752.3305.idtracker@ietfa.amsl.com> <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> In-Reply-To: <3F8ED05D-3078-4565-A739-F6C24487DF07@oracle.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvra617JlAg1//uC0+bfrEbHGr+TGr xZ/dHYwOzB47Z91l91iy5CeTx8ent1gCmKO4bFJSczLLUov07RK4Mt7PeMtS8FC0YsXL2AbG Y4JdjJwcEgImEp3777FB2GISF+6tB7K5OIQEjjJKLGr8wwrhLGKUaN3zFMjh4GATsJDo/qcN 0iAioCox4ctNRpAaZoEljBJ7D/UwgiSEBdwkXl//wgpR5C6x/uMDZgjbSGJK7zOwGhag5q5f 58DivAK+Eqc+T2IBsYUESiQuPrkFVsMpYCfxescKMJsR6Lrvp9YwgdjMAuISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWxFifanDYwQ9XoSN6ZOYYOwtSWWLXwNtVdQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXIUZxanJSbbmSwiREYOQe3/LbYwXj5r80hRmkOFiVx3k+ndgUKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYLyiu9WNXZadc9uXjx/DU+bmnqrwPpL4+5ysxK2tb4UfXHy9 rvjGTo+oI2sCzzIfMmhcs+jZ+viZ/ZoT9biKbVSZpvBVrF1gcGOS8pLS6n1CE9euqSma/8xv xyV9Pf60lusvzCa8mf24P3Km1D5Xj/umu6Su3K1ayymQm1njdNlcim1WzTyelutKLMUZiYZa zEXFiQCBHbcTagIAAA== Cc: "Victor Pascual \(victor.pascual.avila@gmail.com\)" , "Hadriel Kaplan \(hadriel.kaplan@oracle.com\)" Subject: Re: [straw] Open issue in loop-detection too (not traceroute) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2013 11:08:50 -0000 (As co-chair) Hi, Nobody has objected to Hadriel's suggestion on closing the open issue. So, my suggestion is that the authors submit a new version of the draft, im= plementing the suggested solution to the open issue, and we will then initi= ate WGLC. Regards, Christer -----Original Message----- From: straw-bounces@ietf.org [mailto:straw-bounces@ietf.org] On Behalf Of H= adriel Kaplan Sent: 19. kes=E4kuuta 2013 11:43 To: straw@ietf.org Subject: [straw] Open issue in loop-detection too (not traceroute) Howdy, Apparently there is an open issue in the loop-detection draft as well, whic= h I kinda forgot about. I blame my co-author Victor for me having forgotte= n this though, since he submitted the most recent draft version because I w= as taking too long. So it's really his fault for being so diligent. :) Anyway. the open issue is in section 4: [Note: should we require all B2BUAs to perform Via-header loop- detection as well, even if they themselves don't forward on the Via headers?] One of the WG chairs (I won't say who, but it's not Victor) asked me to als= o put my 2-cents in for my preference, to get the ball rolling towards disc= ussion and consensus. But personally, I don't have a strong opinion whethe= r this should be required or not. I can see some arguments either way. It= would be nice to detect loops sooner/faster than max-forwards would, for t= he cases where it could be detected. On the other hand in the looping case= s I've seen the via-header check would never have stopped them - the scenar= ios for detecting a loop using via-header checking are more limited in full= B2BUA deployments. And implementing Via-header loop-detection is a lot mo= re work, extremely difficult if not impossible in some systems, and might i= mpact performance on systems, so having this as a MUST statement means vend= ors might weasel their way out of the whole RFC. (the philosophy here being= that the RFCs in STRAW are only as enforceable as the power of purchasers = of systems to ask their vendors to do them, because they make sense to do) I guess we could hedge and do a "SHOULD" or "RECOMMENDED". But that's real= ly just a cop-out. A wise Jedi master once said: Do or do not, there is no= try. -hadriel On Apr 18, 2013, at 10:17 AM, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-00 _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw