From nobody Mon Feb 2 08:17:44 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91C1A1BFB; Mon, 2 Feb 2015 08:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6istDftMKNT6; Mon, 2 Feb 2015 08:17:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A58DE1A6FEF; Mon, 2 Feb 2015 08:17:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 08:17:04 -0800 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:17:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Message Handling for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Authors : Ram Mohan Ravindranath Tirumaleswar Reddy Gonzalo Salgueiro Filename : draft-ietf-straw-b2bua-stun-01.txt Pages : 14 Date : 2015-02-02 Abstract: Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path, rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing. It is critical that B2BUAs handle these STUN messages properly. This document defines behavior for a B2BUA performing ICE processing. The goal of this draft is to ensure that ICE used for NAT and Firewall traversal of multimedia sessions works when there are B2BUAs in place and the B2BUAs handle STUN messages properly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-stun-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 2 08:19:37 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946E61A1B43 for ; Mon, 2 Feb 2015 08:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ3VMkcR_Bds for ; Mon, 2 Feb 2015 08:19:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4851A037B for ; Mon, 2 Feb 2015 08:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1422893974; x=1424103574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DZm5dvMfgWCnQ4k7/GCAqMkkqpxB2tOVp0kBO/xEQB4=; b=Iw+WqzOFDHe7F6AYWBYJxdmljgxxyNBfpnTeMcfYsYLxnAgw+w+4QgVm JCThrjL5Q7J2JItLcNhR2LgK8jCK85g50nyFVcQF5l9CeofPN3ZzJAWCZ 8CaBltS4nzvmqCmDVoTEDePwtWJrQ0V5z7nmYzfrcGrAdn1RNQhR9g/U0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAMmiz1StJA2H/2dsb2JhbABbgwZSVAUExFoKhXECgRxDAQEBAQF9hAwBAQEEAQEBawsMBAIBCBEDAQIvJwsdCAIEDgUJiCQIBdYRAQEBAQEBAQEBAQEBAQEBAQEBAQEYj3gHBoQjBYlvhRqDToVXgRc2gk2LBYM9IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,507,1418083200"; d="scan'208";a="389610162" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 02 Feb 2015 16:19:33 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t12GJXAe017164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 16:19:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.51]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 10:19:33 -0600 From: "Ram Mohan R (rmohanr)" To: "straw@ietf.org" Thread-Topic: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt Thread-Index: AQHQPwQGRz595lsgqkKNaTnmJiuxDg== Date: Mon, 2 Feb 2015 16:19:32 +0000 Message-ID: References: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> In-Reply-To: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.67.161] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7148A4FF4EE49545A39C78E847B25C57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:19:35 -0000 This revision addresses the WGLC comments received so far. Please review and provide your feedback. Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Monday, 2 February 2015 9:47 pm To: "i-d-announce@ietf.org" Cc: "straw@ietf.org" Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Sip Traversal Required for Applications >to Work Working Group of the IETF. > > Title : Session Traversal Utilities for NAT (STUN) >Message Handling for Session Initiation Protocol (SIP) Back-to-Back User >Agents (B2BUAs) > Authors : Ram Mohan Ravindranath > Tirumaleswar Reddy > Gonzalo Salgueiro > Filename : draft-ietf-straw-b2bua-stun-01.txt > Pages : 14 > Date : 2015-02-02 > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > are often designed to be on the media path, rather than just > intercepting signaling. This means that B2BUAs often act on the > media path leading to separate media legs that the B2BUA correlates > and bridges together. When acting on the media path, B2BUAs are > likely to receive Session Traversal Utilities for NAT (STUN) packets > as part of Interactive Connectivity Establishment (ICE) processing. > It is critical that B2BUAs handle these STUN messages properly. > > This document defines behavior for a B2BUA performing ICE processing. > The goal of this draft is to ensure that ICE used for NAT and > Firewall traversal of multimedia sessions works when there are B2BUAs > in place and the B2BUAs handle STUN messages properly. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-stun-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >straw mailing list >straw@ietf.org >https://www.ietf.org/mailman/listinfo/straw From nobody Mon Feb 2 09:30:59 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5971A8787 for ; Mon, 2 Feb 2015 09:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSIwdByb7kI4 for ; Mon, 2 Feb 2015 09:30:55 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF481A877A for ; Mon, 2 Feb 2015 09:30:54 -0800 (PST) Received: from userPC (unknown [122.172.242.8]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 52400639B7C for ; Mon, 2 Feb 2015 17:30:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1422898255; bh=7CE/Lb7IzTVcc45Vj8N2qCyCIkHBXPbH5r+R+f37Xs4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=htUB5/aDYps0U7O2nqn++5edDElUghn+wrj6s0UXtEOMoZ67Vw90eYty+M1xshaoi VmQLR/45N4psMJPM27LzbXnfhllJbN/7YUcPe7xD6lEDFor6M80cibxu5Oe5k/bnmT 82NO74aBKYeHhNSEbE1SgXBO6VnYozRTCm+P6Jvs= From: "Parthasarathi R" To: References: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> In-Reply-To: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> Date: Mon, 2 Feb 2015 23:00:47 +0530 Message-ID: <00db01d03f0d$fe28b5f0$fa7a21d0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdA/A8lkz0DdbGPZQoauqqdexhF9yAACghMQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.54CFB44E.024F, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.001 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:30:57 -0000 Hi all, The draft looks good. Some of the minor comments are as follows: 1) Sec 3.3. First bullet must have normative statement for adding its own candidate list or else "c" line mismatch occurs. 2) It will be good to add ICE to non-ICE callflow in B2BUA. Non-ICE is because of one of the endpoint does not support ICE. The challenge is for ICE Passthrough with B2BUAs (Sec 3.3) as the candidate pair in the answer has to be as per ICE to non-ICE. Thanks Partha > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, February 02, 2015 9:47 PM > To: i-d-announce@ietf.org > Cc: straw@ietf.org > Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Sip Traversal Required for > Applications to Work Working Group of the IETF. > > Title : Session Traversal Utilities for NAT (STUN) > Message Handling for Session Initiation Protocol (SIP) Back-to-Back > User Agents (B2BUAs) > Authors : Ram Mohan Ravindranath > Tirumaleswar Reddy > Gonzalo Salgueiro > Filename : draft-ietf-straw-b2bua-stun-01.txt > Pages : 14 > Date : 2015-02-02 > > Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > are often designed to be on the media path, rather than just > intercepting signaling. This means that B2BUAs often act on the > media path leading to separate media legs that the B2BUA correlates > and bridges together. When acting on the media path, B2BUAs are > likely to receive Session Traversal Utilities for NAT (STUN) packets > as part of Interactive Connectivity Establishment (ICE) processing. > It is critical that B2BUAs handle these STUN messages properly. > > This document defines behavior for a B2BUA performing ICE > processing. > The goal of this draft is to ensure that ICE used for NAT and > Firewall traversal of multimedia sessions works when there are > B2BUAs > in place and the B2BUAs handle STUN messages properly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-stun-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Mon Feb 2 19:44:33 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2371A1DBE for ; Mon, 2 Feb 2015 19:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw_CvTkEq1LG for ; Mon, 2 Feb 2015 19:44:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489431A1BD2 for ; Mon, 2 Feb 2015 19:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3970; q=dns/txt; s=iport; t=1422935056; x=1424144656; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hSEqmoR9YZBVwQjrHiG5Wf+UL5Dof5Q75DlJjWEs3+Y=; b=VYK+8zw8m8aXGBQM61HL1Dxj4rDq+baIzYgYquaiyY1NBNi1I3LvSuOi 2yDty5IfGaMUvIUKPd7vrxvoQbAhjEFLAXqoP11Fpcob8UTv8f/dJdSi4 B0wbko7Op+YRVWqf0wZ3bJmRUYbEHp6A8+7dXKGJ7mpOq9dXAiPm+QXN3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAJND0FStJA2I/2dsb2JhbABagwZSVAUExHIKhXECgR9DAQEBAQF9hAwBAQEEAQEBaxcEAgEIEQMBAQEoBycLFAkIAgQBEgmIJAgF1W4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXj38GhCMFiW+FGoNOhVeBFzaCTY5CIoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,510,1418083200"; d="scan'208";a="392886421" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 03 Feb 2015 03:44:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t133iEi0008903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 03:44:14 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.51]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 21:44:14 -0600 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "straw@ietf.org" Thread-Topic: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt Thread-Index: AQHQP2OsmxmVfy909kWsREQaFujvtw== Date: Tue, 3 Feb 2015 03:44:13 +0000 Message-ID: References: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> <00db01d03f0d$fe28b5f0$fa7a21d0$@co.in> In-Reply-To: <00db01d03f0d$fe28b5f0$fa7a21d0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.206] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <31D144037396D44F84F2ADDCAD654332@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 03:44:22 -0000 Hi Partha, See inline=20 -----Original Message----- From: Parthasarathi R Date: Monday, 2 February 2015 11:00 pm To: "straw@ietf.org" Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt >Hi all, > >The draft looks good. Some of the minor comments are as follows: > >1) Sec 3.3. First bullet must have normative statement for adding its own >candidate list or else "c" line mismatch occurs. Ok. will add normative statement in this section > >2) It will be good to add ICE to non-ICE callflow in B2BUA. Non-ICE is >because of one of the endpoint does not support ICE. The challenge is for >ICE Passthrough with B2BUAs (Sec 3.3) as the candidate pair in the answer >has to be as per ICE to non-ICE. Right a B2BUA may do ICE to no-ICE. Section 3.2 mentions about B2BUA terminating ICE where in it treats each ICE context separately. So it is very much possible to do ICE only on one side. The sample flow given is just one use-case. I can add some text to say for this case but really don=B9t see a need for separate call flow. Regards, Ram > >Thanks >Partha > >> -----Original Message----- >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Monday, February 02, 2015 9:47 PM >> To: i-d-announce@ietf.org >> Cc: straw@ietf.org >> Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Sip Traversal Required for >> Applications to Work Working Group of the IETF. >>=20 >> Title : Session Traversal Utilities for NAT (STUN) >> Message Handling for Session Initiation Protocol (SIP) Back-to-Back >> User Agents (B2BUAs) >> Authors : Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Gonzalo Salgueiro >> Filename : draft-ietf-straw-b2bua-stun-01.txt >> Pages : 14 >> Date : 2015-02-02 >>=20 >> Abstract: >> Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >> are often designed to be on the media path, rather than just >> intercepting signaling. This means that B2BUAs often act on the >> media path leading to separate media legs that the B2BUA correlates >> and bridges together. When acting on the media path, B2BUAs are >> likely to receive Session Traversal Utilities for NAT (STUN) packets >> as part of Interactive Connectivity Establishment (ICE) processing. >> It is critical that B2BUAs handle these STUN messages properly. >>=20 >> This document defines behavior for a B2BUA performing ICE >> processing. >> The goal of this draft is to ensure that ICE used for NAT and >> Firewall traversal of multimedia sessions works when there are >> B2BUAs >> in place and the B2BUAs handle STUN messages properly. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-stun-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 nobody Thu Feb 5 16:29:48 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41F1A0062 for ; Thu, 5 Feb 2015 16:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.179 X-Spam-Level: X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_UZB1HURJIi for ; Thu, 5 Feb 2015 16:29:37 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8FA1A0032 for ; Thu, 5 Feb 2015 16:29:37 -0800 (PST) Received: from userPC (unknown [122.167.181.109]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 6832586962A; Fri, 6 Feb 2015 00:29:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1423182571; bh=oyCf/IUwaZFhzfNTlA8C5xt8FeWprJIk/BBW4cAYBA4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mCMdyh7HARvb2L/2RKQZViF74ld8NWGIWZ0xt6kcfIbfrix/r6CT6HKpVy48Q/wSm JqLEBIDBTV0lmDz0b+9xJScN2SkEn1ZjpFgcd3kWw6nFJeNTwfzcJq+BeP8z77VI9O i0kFLCsfCf5v2lFGMSrKrLG6BOa/w1P5ozh+kawA= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> <00db01d03f0d$fe28b5f0$fa7a21d0$@co.in> In-Reply-To: Date: Fri, 6 Feb 2015 05:59:20 +0530 Message-ID: <022901d041a3$f6037200$e20a5600$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQP2OsmxmVfy909kWsREQaFujvt5zixyjQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.54D40AEB.0142, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.001 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:29:41 -0000 Hi Ram, I'm fine with your approach for ICE to non-ICE callflow. Regards Partha > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Tuesday, February 03, 2015 9:14 AM > To: Parthasarathi R; straw@ietf.org > Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt >=20 > Hi Partha, >=20 > See inline >=20 > -----Original Message----- > From: Parthasarathi R > Date: Monday, 2 February 2015 11:00 pm > To: "straw@ietf.org" > Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt >=20 > >Hi all, > > > >The draft looks good. Some of the minor comments are as follows: > > > >1) Sec 3.3. First bullet must have normative statement for adding its > own > >candidate list or else "c" line mismatch occurs. >=20 > Ok. will add normative statement in this section > > > >2) It will be good to add ICE to non-ICE callflow in B2BUA. Non-ICE = is > >because of one of the endpoint does not support ICE. The challenge is > for > >ICE Passthrough with B2BUAs (Sec 3.3) as the candidate pair in the > answer > >has to be as per ICE to non-ICE. >=20 > Right a B2BUA may do ICE to no-ICE. Section 3.2 mentions about B2BUA > terminating ICE where in it treats each ICE context separately. So it > is > very much possible to do ICE only on one side. > The sample flow given is just one use-case. I can add some text to say > for > this case but really don=B9t see a need for separate call flow. >=20 > Regards, > Ram > > > >Thanks > >Partha > > > >> -----Original Message----- > >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of internet- > >> drafts@ietf.org > >> Sent: Monday, February 02, 2015 9:47 PM > >> To: i-d-announce@ietf.org > >> Cc: straw@ietf.org > >> Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Sip Traversal Required for > >> Applications to Work Working Group of the IETF. > >> > >> Title : Session Traversal Utilities for NAT = (STUN) > >> Message Handling for Session Initiation Protocol (SIP) Back-to-Back > >> User Agents (B2BUAs) > >> Authors : Ram Mohan Ravindranath > >> Tirumaleswar Reddy > >> Gonzalo Salgueiro > >> Filename : draft-ietf-straw-b2bua-stun-01.txt > >> Pages : 14 > >> Date : 2015-02-02 > >> > >> Abstract: > >> Session Initiation Protocol (SIP) Back-to-Back User Agents > (B2BUAs) > >> are often designed to be on the media path, rather than just > >> intercepting signaling. This means that B2BUAs often act on the > >> media path leading to separate media legs that the B2BUA > correlates > >> and bridges together. When acting on the media path, B2BUAs are > >> likely to receive Session Traversal Utilities for NAT (STUN) > packets > >> as part of Interactive Connectivity Establishment (ICE) > processing. > >> It is critical that B2BUAs handle these STUN messages properly. > >> > >> This document defines behavior for a B2BUA performing ICE > >> processing. > >> The goal of this draft is to ensure that ICE used for NAT and > >> Firewall traversal of multimedia sessions works when there are > >> B2BUAs > >> in place and the B2BUAs handle STUN messages properly. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-01 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-stun-01 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at = tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Mon Feb 9 07:17:17 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CC81A0076; Mon, 9 Feb 2015 07:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBGk2T2qwKxG; Mon, 9 Feb 2015 07:00:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA821A005A; Mon, 9 Feb 2015 07:00:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209150044.17912.46624.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 07:00:44 -0800 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-03.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:00:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-03.txt Pages : 14 Date : 2015-02-09 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 9 07:24:55 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510011A1A15 for ; Mon, 9 Feb 2015 07:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsjIUG6ew0lG for ; Mon, 9 Feb 2015 07:05:52 -0800 (PST) Received: from smtpcmd02102.aruba.it (smtpcmd02102.aruba.it [62.149.158.102]) by ietfa.amsl.com (Postfix) with ESMTP id 39C641A1A12 for ; Mon, 9 Feb 2015 07:05:52 -0800 (PST) Received: from lminiero ([143.225.229.180]) by smtpcmd02.ad.aruba.it with bizsmtp id qF5p1p01x3uAlfT01F5qEj; Mon, 09 Feb 2015 16:05:50 +0100 Date: Mon, 9 Feb 2015 16:05:49 +0100 From: Lorenzo Miniero To: straw@ietf.org Message-ID: <20150209160549.0c698aaa@lminiero> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [straw] Fw: New Version Notification for draft-ietf-straw-b2bua-rtcp-03.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:05:56 -0000 Hi all, apologies for this late update. I just refreshed the RTCP document, and this now addresses the main issue identified in Honolulu after it was first introduced in Toronto, that is the MITM behaviour for secure sessions in B2BUAs. The text should now be much clearer with respect to the fact this behaviour is discouraged and unspecified. There are also a couple of new lines in Security Considerations, although the document doesn't introduce any new behaviour and as such shouldn't introduce any new Security issue that wasn't addressed in the original standards already. Let us know whether you think the wording is sufficient or not, or whether it's needed at all. The document in it current stage should be pretty much ready. Any feedback and/or review would be more than welcome! After that, we authors believe the document might be ready for WGLC. Looking forward to your thoughts, thanks, Lorenzo Begin forwarded message: Date: Mon, 09 Feb 2015 07:00:44 -0800 From: internet-drafts@ietf.org To: "Sergio Garcia Murillo" , "Sergio Garcia Murillo" , "Victor Pascual" , "Victor Pascual" , "Lorenzo Miniero" , "Lorenzo Miniero" Subject: New Version Notification for draft-ietf-straw-b2bua-rtcp-03.txt A new version of I-D, draft-ietf-straw-b2bua-rtcp-03.txt has been successfully submitted by Lorenzo Miniero and posted to the IETF repository. Name: draft-ietf-straw-b2bua-rtcp Revision: 03 Title: Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Document date: 2015-02-09 Group: straw Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-straw-b2bua-rtcp-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ Htmlized: http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-03 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Feb 9 21:03:29 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E6D1A8BB7; Mon, 9 Feb 2015 21:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFZfjpDaANj4; Mon, 9 Feb 2015 21:03:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FCE1A8714; Mon, 9 Feb 2015 21:03:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210050322.10040.38804.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 21:03:22 -0800 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 05:03:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Message Handling for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Authors : Ram Mohan Ravindranath Tirumaleswar Reddy Gonzalo Salgueiro Filename : draft-ietf-straw-b2bua-stun-02.txt Pages : 14 Date : 2015-02-09 Abstract: Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path, rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing. It is critical that B2BUAs handle these STUN messages properly. This document defines behavior for a B2BUA performing ICE processing. The goal of this draft is to ensure that ICE used for NAT and Firewall traversal of multimedia sessions works when there are B2BUAs in place and the B2BUAs handle STUN messages properly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-stun-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 9 21:04:27 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33521A8A7D for ; Mon, 9 Feb 2015 21:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-bHxHfyoSn0 for ; Mon, 9 Feb 2015 21:04:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918F21A8714 for ; Mon, 9 Feb 2015 21:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7098; q=dns/txt; s=iport; t=1423544654; x=1424754254; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WoEKJaaS6Nlc8fJF90OVRLlhTJrHEjbGh/zS81saaXE=; b=iG2aJmCaiH0ScWKo9mFzyXzZa5Qaqo8S7Y0WFPbLTpUnEUupknwWahV7 IoYZ+6X57rx3UQzMBm+Vi3ga9dAOhG8fBuzfccn4sEZAaveLsCMjOdYSc X0IWlCOdSB2FJg48tvjvtv6kad2JaY4lUve3wbp99mg+dAiMlUpTTFEU6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAJSQ2VStJV2Q/2dsb2JhbABcgwZSVQUEgn6/cgqFcQIcgQFDAQEBAQEBfIQMAQEBBAEBATE6FwQCAQgRAwEBAQUjBQICJQsUCQgCBAESCYgkCAWZGpxkBpcFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EbjmMGglyBSAWPG4NQhVyBGDaCTYsXgz4ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,548,1418083200"; d="scan'208";a="394822841" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 10 Feb 2015 05:04:13 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1A54DGQ023460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 05:04:13 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.157]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 23:04:13 -0600 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "straw@ietf.org" Thread-Topic: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt Thread-Index: AQHQRO8BjP5Ox7UQ7E+9UsE+xCfrEQ== Date: Tue, 10 Feb 2015 05:04:12 +0000 Message-ID: References: <20150202161704.25783.95534.idtracker@ietfa.amsl.com> <00db01d03f0d$fe28b5f0$fa7a21d0$@co.in> <022901d041a3$f6037200$e20a5600$@co.in> In-Reply-To: <022901d041a3$f6037200$e20a5600$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.206] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-01.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 05:04:20 -0000 SGkgUGFydGhhLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEhhdmUgYWRkcmVzc2VkIHlv dXIgY29tbWVudHMgYW5kIHB1Ymxpc2hlZCBhIG5ldw0KcmV2aXNpb24uDQoNClJlZ2FyZHMsDQpS YW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhcnRoYXNhcmF0aGkgUiA8 cGFydGhhQHBhcnRoYXNhcmF0aGkuY28uaW4+DQpEYXRlOiBGcmlkYXksIDYgRmVicnVhcnkgMjAx NSA1OjU5IGFtDQpUbzogQ2lzY28gRW1wbG95ZWUgPHJtb2hhbnJAY2lzY28uY29tPiwgInN0cmF3 QGlldGYub3JnIiA8c3RyYXdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3N0cmF3XSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXN0cmF3LWIyYnVhLXN0dW4tMDEudHh0DQoNCj5IaSBSYW0sDQo+DQo+ SSdtIGZpbmUgd2l0aCB5b3VyIGFwcHJvYWNoIGZvciBJQ0UgdG8gbm9uLUlDRSBjYWxsZmxvdy4N Cj4NCj5SZWdhcmRzDQo+UGFydGhhDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogc3RyYXcgW21haWx0bzpzdHJhdy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUmFtIE1vaGFuIFINCj4+IChybW9oYW5yKQ0KPj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkg MDMsIDIwMTUgOToxNCBBTQ0KPj4gVG86IFBhcnRoYXNhcmF0aGkgUjsgc3RyYXdAaWV0Zi5vcmcN Cj4+IFN1YmplY3Q6IFJlOiBbc3RyYXddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3RyYXctYjJi dWEtc3R1bi0wMS50eHQNCj4+IA0KPj4gSGkgUGFydGhhLA0KPj4gDQo+PiBTZWUgaW5saW5lDQo+ PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBQYXJ0aGFzYXJhdGhp IFIgPHBhcnRoYUBwYXJ0aGFzYXJhdGhpLmNvLmluPg0KPj4gRGF0ZTogTW9uZGF5LCAyIEZlYnJ1 YXJ5IDIwMTUgMTE6MDAgcG0NCj4+IFRvOiAic3RyYXdAaWV0Zi5vcmciIDxzdHJhd0BpZXRmLm9y Zz4NCj4+IFN1YmplY3Q6IFJlOiBbc3RyYXddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3RyYXct YjJidWEtc3R1bi0wMS50eHQNCj4+IA0KPj4gPkhpIGFsbCwNCj4+ID4NCj4+ID5UaGUgZHJhZnQg bG9va3MgZ29vZC4gU29tZSBvZiB0aGUgbWlub3IgY29tbWVudHMgYXJlIGFzIGZvbGxvd3M6DQo+ PiA+DQo+PiA+MSkgU2VjIDMuMy4gRmlyc3QgYnVsbGV0IG11c3QgaGF2ZSBub3JtYXRpdmUgc3Rh dGVtZW50IGZvciBhZGRpbmcgaXRzDQo+PiBvd24NCj4+ID5jYW5kaWRhdGUgbGlzdCBvciBlbHNl ICJjIiBsaW5lIG1pc21hdGNoIG9jY3Vycy4NCj4+IA0KPj4gT2suIHdpbGwgYWRkIG5vcm1hdGl2 ZSBzdGF0ZW1lbnQgaW4gdGhpcyBzZWN0aW9uDQo+PiA+DQo+PiA+MikgSXQgd2lsbCBiZSBnb29k IHRvIGFkZCBJQ0UgdG8gbm9uLUlDRSBjYWxsZmxvdyBpbiBCMkJVQS4gTm9uLUlDRSBpcw0KPj4g PmJlY2F1c2Ugb2Ygb25lIG9mIHRoZSBlbmRwb2ludCBkb2VzIG5vdCBzdXBwb3J0IElDRS4gVGhl IGNoYWxsZW5nZSBpcw0KPj4gZm9yDQo+PiA+SUNFIFBhc3N0aHJvdWdoIHdpdGggQjJCVUFzIChT ZWMgMy4zKSBhcyB0aGUgY2FuZGlkYXRlIHBhaXIgaW4gdGhlDQo+PiBhbnN3ZXINCj4+ID5oYXMg dG8gYmUgYXMgcGVyIElDRSB0byBub24tSUNFLg0KPj4gDQo+PiBSaWdodCBhIEIyQlVBIG1heSBk byBJQ0UgdG8gbm8tSUNFLiBTZWN0aW9uIDMuMiBtZW50aW9ucyBhYm91dCBCMkJVQQ0KPj4gdGVy bWluYXRpbmcgSUNFIHdoZXJlIGluIGl0IHRyZWF0cyBlYWNoIElDRSBjb250ZXh0IHNlcGFyYXRl bHkuIFNvIGl0DQo+PiBpcw0KPj4gdmVyeSBtdWNoIHBvc3NpYmxlIHRvIGRvIElDRSBvbmx5IG9u IG9uZSBzaWRlLg0KPj4gVGhlIHNhbXBsZSBmbG93IGdpdmVuIGlzIGp1c3Qgb25lIHVzZS1jYXNl LiBJIGNhbiBhZGQgc29tZSB0ZXh0IHRvIHNheQ0KPj4gZm9yDQo+PiAgdGhpcyBjYXNlIGJ1dCBy ZWFsbHkgZG9uqfZ0IHNlZSBhIG5lZWQgZm9yIHNlcGFyYXRlIGNhbGwgZmxvdy4NCj4+IA0KPj4g UmVnYXJkcywNCj4+IFJhbQ0KPj4gPg0KPj4gPlRoYW5rcw0KPj4gPlBhcnRoYQ0KPj4gPg0KPj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IHN0cmF3IFttYWlsdG86 c3RyYXctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LQ0KPj4gPj4gZHJh ZnRzQGlldGYub3JnDQo+PiA+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1IDk6NDcg UE0NCj4+ID4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+ID4+IENjOiBzdHJhd0BpZXRm Lm9yZw0KPj4gPj4gU3ViamVjdDogW3N0cmF3XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXN0cmF3 LWIyYnVhLXN0dW4tMDEudHh0DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4gPj4g ZGlyZWN0b3JpZXMuDQo+PiA+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2lw IFRyYXZlcnNhbCBSZXF1aXJlZCBmb3INCj4+ID4+IEFwcGxpY2F0aW9ucyB0byBXb3JrIFdvcmtp bmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+PiA+Pg0KPj4gPj4gICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4+ID4+IE1l c3NhZ2UgSGFuZGxpbmcgZm9yIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBCYWNr LXRvLUJhY2sNCj4+ID4+IFVzZXIgQWdlbnRzIChCMkJVQXMpDQo+PiA+PiAgICAgICAgIEF1dGhv cnMgICAgICAgICA6IFJhbSBNb2hhbiBSYXZpbmRyYW5hdGgNCj4+ID4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGlydW1hbGVzd2FyIFJlZGR5DQo+PiA+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgIEdvbnphbG8gU2FsZ3VlaXJvDQo+PiA+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1zdHJhdy1iMmJ1YS1zdHVuLTAxLnR4dA0KPj4gPj4gCVBhZ2VzICAgICAgICAgICA6IDE0 DQo+PiA+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNS0wMi0wMg0KPj4gPj4NCj4+ID4+IEFic3Ry YWN0Og0KPj4gPj4gICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIEJhY2stdG8t QmFjayBVc2VyIEFnZW50cw0KPj4gKEIyQlVBcykNCj4+ID4+ICAgIGFyZSBvZnRlbiBkZXNpZ25l ZCB0byBiZSBvbiB0aGUgbWVkaWEgcGF0aCwgcmF0aGVyIHRoYW4ganVzdA0KPj4gPj4gICAgaW50 ZXJjZXB0aW5nIHNpZ25hbGluZy4gIFRoaXMgbWVhbnMgdGhhdCBCMkJVQXMgb2Z0ZW4gYWN0IG9u IHRoZQ0KPj4gPj4gICAgbWVkaWEgcGF0aCBsZWFkaW5nIHRvIHNlcGFyYXRlIG1lZGlhIGxlZ3Mg dGhhdCB0aGUgQjJCVUENCj4+IGNvcnJlbGF0ZXMNCj4+ID4+ICAgIGFuZCBicmlkZ2VzIHRvZ2V0 aGVyLiAgV2hlbiBhY3Rpbmcgb24gdGhlIG1lZGlhIHBhdGgsIEIyQlVBcyBhcmUNCj4+ID4+ICAg IGxpa2VseSB0byByZWNlaXZlIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChT VFVOKQ0KPj4gcGFja2V0cw0KPj4gPj4gICAgYXMgcGFydCBvZiBJbnRlcmFjdGl2ZSBDb25uZWN0 aXZpdHkgRXN0YWJsaXNobWVudCAoSUNFKQ0KPj4gcHJvY2Vzc2luZy4NCj4+ID4+ICAgIEl0IGlz IGNyaXRpY2FsIHRoYXQgQjJCVUFzIGhhbmRsZSB0aGVzZSBTVFVOIG1lc3NhZ2VzIHByb3Blcmx5 Lg0KPj4gPj4NCj4+ID4+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBiZWhhdmlvciBmb3IgYSBC MkJVQSBwZXJmb3JtaW5nIElDRQ0KPj4gPj4gcHJvY2Vzc2luZy4NCj4+ID4+ICAgIFRoZSBnb2Fs IG9mIHRoaXMgZHJhZnQgaXMgdG8gZW5zdXJlIHRoYXQgSUNFIHVzZWQgZm9yIE5BVCBhbmQNCj4+ ID4+ICAgIEZpcmV3YWxsIHRyYXZlcnNhbCBvZiBtdWx0aW1lZGlhIHNlc3Npb25zIHdvcmtzIHdo ZW4gdGhlcmUgYXJlDQo+PiA+PiBCMkJVQXMNCj4+ID4+ICAgIGluIHBsYWNlIGFuZCB0aGUgQjJC VUFzIGhhbmRsZSBTVFVOIG1lc3NhZ2VzIHByb3Blcmx5Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+ID4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3RyYXctYjJidWEt c3R1bi8NCj4+ID4+DQo+PiA+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCj4+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3Ry YXctYjJidWEtc3R1bi0wMQ0KPj4gPj4NCj4+ID4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtc3RyYXctYjJidWEtc3R1bi0wMQ0KPj4gPj4NCj4+ID4+DQo+PiA+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPj4gPj4gc3VibWlzc2lvbg0KPj4gPj4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+ID4+DQo+ PiA+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+PiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gPj4NCj4+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiBzdHJhdyBtYWlsaW5nIGxpc3QNCj4+ID4+IHN0cmF3QGlldGYub3JnDQo+PiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0cmF3DQo+PiA+DQo+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5zdHJhdyBtYWlsaW5n IGxpc3QNCj4+ID5zdHJhd0BpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3RyYXcNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHN0cmF3IG1haWxpbmcgbGlzdA0KPj4gc3RyYXdAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RyYXcNCj4NCg0K From nobody Mon Feb 9 21:05:00 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0761A8BB6 for ; Mon, 9 Feb 2015 21:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6UfBYij9oES for ; Mon, 9 Feb 2015 21:04:53 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EE21A8714 for ; Mon, 9 Feb 2015 21:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2729; q=dns/txt; s=iport; t=1423544693; x=1424754293; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FrWTti6daizI4PHPo3zVpajPvCkEaK9+5G1YauotC6k=; b=Qp79lSFea6qsYlJLPGhNMbi14vN/1PxRuGJyqBBW4pt1iXNY000LL+E8 do2KyQndos6LeEx2mj8z2wExkT54NXLeEvVFdWLVDUnbOBqZPcDRQwqM9 DDJVl2WRt+nBIohUVAfkPAGKilyppTQCraM/5h8Npe8yKzhclRLb0GtrW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BQApkdlU/49dJa1cgwZSVQUEwnAKhXECgR1DAQEBAQEBfIQMAQEBBAEBATc0FwQCAQgRAwECHxAnCx0IAgQTCYgkCAXNDwEBAQEBAQQBAQEBAQEBG49+BoQkBY8bg1CFXIEYNoJNjlUig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,548,1418083200"; d="scan'208";a="122108374" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 10 Feb 2015 05:04:52 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1A54qtC022815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Feb 2015 05:04:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.157]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 23:04:52 -0600 From: "Ram Mohan R (rmohanr)" To: "straw@ietf.org" Thread-Topic: [straw] I-D Action: draft-ietf-straw-b2bua-stun-02.txt Thread-Index: AQHQRO7x0nT0GB9x5U+7TZ4XsIxrkZzqFRmA Date: Tue, 10 Feb 2015 05:04:51 +0000 Message-ID: References: <20150210050322.10040.38804.idtracker@ietfa.amsl.com> In-Reply-To: <20150210050322.10040.38804.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.206] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-stun-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 05:04:56 -0000 This version addresses some of the WGLC comments received in the mailing list. Thanks for the reviews/feedback so far. Please let us know if you have any more comments on this draft. Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Tuesday, 10 February 2015 10:33 am To: "i-d-announce@ietf.org" Cc: "straw@ietf.org" Subject: [straw] I-D Action: draft-ietf-straw-b2bua-stun-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Sip Traversal Required for Applications >to Work Working Group of the IETF. > > Title : Session Traversal Utilities for NAT (STUN) >Message Handling for Session Initiation Protocol (SIP) Back-to-Back User >Agents (B2BUAs) > Authors : Ram Mohan Ravindranath > Tirumaleswar Reddy > Gonzalo Salgueiro > Filename : draft-ietf-straw-b2bua-stun-02.txt > Pages : 14 > Date : 2015-02-09 > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > are often designed to be on the media path, rather than just > intercepting signaling. This means that B2BUAs often act on the > media path leading to separate media legs that the B2BUA correlates > and bridges together. When acting on the media path, B2BUAs are > likely to receive Session Traversal Utilities for NAT (STUN) packets > as part of Interactive Connectivity Establishment (ICE) processing. > It is critical that B2BUAs handle these STUN messages properly. > > This document defines behavior for a B2BUA performing ICE processing. > The goal of this draft is to ensure that ICE used for NAT and > Firewall traversal of multimedia sessions works when there are B2BUAs > in place and the B2BUAs handle STUN messages properly. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-stun/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-stun-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >straw mailing list >straw@ietf.org >https://www.ietf.org/mailman/listinfo/straw From nobody Tue Feb 10 00:02:12 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB2A1A0143 for ; Tue, 10 Feb 2015 00:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGIGQwYWhe4h for ; Tue, 10 Feb 2015 00:02:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174B51A19FE for ; Tue, 10 Feb 2015 00:02:07 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-33-54d9bafea854 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.E2.04076.EFAB9D45; Tue, 10 Feb 2015 09:02:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 10 Feb 2015 09:02:05 +0100 From: Christer Holmberg To: Lorenzo Miniero , "straw@ietf.org" Thread-Topic: [straw] Fw: New Version Notification for draft-ietf-straw-b2bua-rtcp-03.txt Thread-Index: AdBFB9vg92nb6g25RVqygKDRvXaQOw== Date: Tue, 10 Feb 2015 08:02:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6C082F@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje6/XTdDDPZ8E7fYvmUBk8Wt5ses DkweS5b8ZPLoeHifPYApissmJTUnsyy1SN8ugStj3dOHTAXNchXPbk9iaWBcKtHFyMkhIWAi 8ennASYIW0ziwr31bF2MXBxCAkcYJWZf/8wI4SxhlNgz4QVzFyMHB5uAhUT3P22QBhEBX4kv b4+ygNjCAlESm1v+MkLEoyX6Tx+EsvUkzuy6xQxiswioStxo+sMEMoYXqHfVgwKQMCPQ3u+n 1oDdwCwgLnHryXyoewQkluw5zwxhi0q8fPyPFcJWlPj4ah8jRL2OxILdn9ggbG2JZQtfg9Xz CghKnJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC g/7glt9WOxgPPnc8xCjAwajEw2tQcjNEiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2Mlqu+MnKsmdty1fLQ7E8ezdPybn0tc1tvkJqp7N+6UHjhg+ZMh8eK 7s8/zTq79dL362tTtcp/nRe+2HbxTNyi1XfmbPrOei/45c5a52yvEya5DsYvbv0XV6ud+nNZ 4Umj/k93f7ntf1cUxPJLRyCj3+rL2uYgntAdRy/9iGZYeolnfkOE9/aTWUosxRmJhlrMRcWJ AA52LY5bAgAA Archived-At: Subject: Re: [straw] Fw: New Version Notification for draft-ietf-straw-b2bua-rtcp-03.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:02:12 -0000 (As co-chair) Hi Lorenzo, Thanks for submitting a new version of the draft! The chairs encourage peop= le to take a look. The chairs would also like to request for at a couple of persons who would = be willing to perform a WGLC review of the draft. Regards, Christer -----Original Message----- From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Lorenzo Miniero Sent: 9. helmikuuta 2015 17:06 To: straw@ietf.org Subject: [straw] Fw: New Version Notification for draft-ietf-straw-b2bua-rt= cp-03.txt Hi all, apologies for this late update. I just refreshed the RTCP document, and this now addresses the main issue i= dentified in Honolulu after it was first introduced in Toronto, that is the= MITM behaviour for secure sessions in B2BUAs. The text should now be much = clearer with respect to the fact this behaviour is discouraged and unspecif= ied. There are also a couple of new lines in Security Considerations, altho= ugh the document doesn't introduce any new behaviour and as such shouldn't = introduce any new Security issue that wasn't addressed in the original stan= dards already. Let us know whether you think the wording is sufficient or n= ot, or whether it's needed at all. The document in it current stage should be pretty much ready. Any feedback = and/or review would be more than welcome! After that, we authors believe th= e document might be ready for WGLC. Looking forward to your thoughts, thanks, Lorenzo Begin forwarded message: Date: Mon, 09 Feb 2015 07:00:44 -0800 From: internet-drafts@ietf.org To: "Sergio Garcia Murillo" , "Sergio Garc= ia Murillo" , "Victor Pascual" , "Victor Pascual" , "Lorenzo Miniero" , "Lor= enzo Miniero" Subject: New Version Notification for = draft-ietf-straw-b2bua-rtcp-03.txt A new version of I-D, draft-ietf-straw-b2bua-rtcp-03.txt has been successfully submitted by Lorenzo Miniero and posted to the IETF r= epository. Name: draft-ietf-straw-b2bua-rtcp Revision: 03 Title: Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Document date: 2015-02-09 Group: straw Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-straw-b2bua-rtcp-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ Htmlized: http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-straw-b2bua-rtcp-03 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw From nobody Wed Feb 11 05:39:15 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9DD1A8930 for ; Wed, 11 Feb 2015 05:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E__iXgk88e0f for ; Wed, 11 Feb 2015 05:39:12 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AD81A890A for ; Wed, 11 Feb 2015 05:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2645; q=dns/txt; s=iport; t=1423661930; x=1424871530; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=agQuiJGX3t+PND4Oyp4fW0G0jMV8WLpB23FBPmhHXQE=; b=TdaIHiw36pOp9GAbTkyv7FSczu5zWKLl3FsX7iY4vINXKp9eFIFrVtqB QaN1s8RdUBA6WFhvwRwYXmp6nXwB4FtP0IvAJY+czo7SZ1WXFPSL0ebIW PLyTstGFORUbGpFKn94vBU2/Pw1nQuWv3h2LxoX6g+T2Xw1csT1sA8j3p A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAFla21StJV2c/2dsb2JhbABbgwZSVQUEwwSFbwKBJUMBAQEBAQF8hAwBAQEEOj0OBAIBCBEDAQIfEDIbAQEFAwIEEwmIJAgF0XgBAQEBAQEEAQEBAQEBARuPfgaEJAWPIoNShV2BGDaCTo5dIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,558,1418083200"; d="scan'208";a="395306853" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 11 Feb 2015 13:38:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1BDcnG4018432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Feb 2015 13:38:49 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.107]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 11 Feb 2015 07:38:49 -0600 From: "Ram Mohan R (rmohanr)" To: "straw@ietf.org" Thread-Topic: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt Thread-Index: AQHQRf9PCJAHfZcMrUCSfAweu9zaL5zsNOgA Date: Wed, 11 Feb 2015 13:38:49 +0000 Message-ID: References: <20150211133318.20959.29977.idtracker@ietfa.amsl.com> In-Reply-To: <20150211133318.20959.29977.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.63.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BBDC81E268F0541AB42F766DF726C12@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:39:14 -0000 This version addresses some of the comments received during reviews from Dan Wing and Charles Eckel Please review the revision http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-02 Look at the diff here - http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-straw-b2bua-dtls-srtp-02 One major change is - removing the part where we have mentioned about B2BUA handling all forked responses to INVITE. Since we have reduced the scope of this draft to not consider B2BUAs terminating DTLS-SRTP this piece also needs to be removed. Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, 11 February 2015 7:03 pm To: Cisco Employee , "Tirumaleswar Reddy (tireddy)" , Victor Pascual , Victor Pascual , Parthasarathi Ravindran , "Gonzalo Salgueiro (gsalguei)" , Parthasarathi Ravindran , "Gonzalo Salgueiro (gsalguei)" , "Tirumaleswar Reddy (tireddy)" , Cisco Employee Subject: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt > >A new version of I-D, draft-ram-straw-b2bua-dtls-srtp-02.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to >the >IETF repository. > >Name: draft-ram-straw-b2bua-dtls-srtp >Revision: 02 >Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP) >Back-to-Back User Agents (B2BUAs) >Document date: 2015-02-11 >Group: Individual Submission >Pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-dtls-srtp-02.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-dtls-srtp/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-straw-b2bua-dtls-srtp-02 > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > often function on the media plane, rather than just on the signaling > path. This document describes the behavior B2BUAs should follow when > acting on the media plane that use Secure Real-time Transport (SRTP) > security context setup with Datagram Transport Layer Security (DTLS) > protocol. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Wed Feb 11 05:48:26 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D801A88FC for ; Wed, 11 Feb 2015 05:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQAVHuVUscUG for ; Wed, 11 Feb 2015 05:48:23 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314F01A88FF for ; Wed, 11 Feb 2015 05:47:37 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-45-54db5d77aa17 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.14.24955.77D5BD45; Wed, 11 Feb 2015 14:47:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 14:47:34 +0100 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "straw@ietf.org" Thread-Topic: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt Thread-Index: AQHQRf9PCJAHfZcMrUCSfAweu9zaL5zsNOgA//9BN1A= Date: Wed, 11 Feb 2015 13:47:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CCC94@ESESSMB209.ericsson.se> References: <20150211133318.20959.29977.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjW557O0Qg/t7xSyWd+1gtLjV/JjV gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4/bGi4IlURUfbCdYGxlViXYycHBICJhIn Hj5igbDFJC7cW8/WxcjFISRwhFHi57l3YAkhgSWMEjfeBXYxcnCwCVhIdP/TBgmLCIRIvO34 xAZiCwsESexuO80GEQ+WWHbrLCNIuYiAlcTdyd4gYRYBVYlZP5Yxg9i8Ar4Sdx+dZ4WYnibR srYdrJVTQF9i0t5OsBpGoHO+n1rDBGIzC4hL3HoynwniTAGJJXvOM0PYohIvH/9jhbCVJNYe 3s4CUa8jsWA3xGnMAtoSyxa+htorKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7K TTcy1kstykwuLs7P08tLLdnECIyQg1t+q+5gvPzG8RCjAAejEg/vhqO3QoRYE8uKK3MPMUpz sCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJh47o1XkLyb5zFFRzfZxMV7xD78 cQhxKLxlKHjAMKT56d0TfC8b1Mr72Ve5b3Ca9DR2QoX1zXvrBBcov/6xIbD4k0eX24duv66S f3+yo/mO6RUu97tivv/xkm0V35cpTJQuPdBZ5hB8Knye9O+ewzmVr1cLnrQ7LNz5MUH5zdVI 226LM3tTjiqxFGckGmoxFxUnAgADRvmKcQIAAA== Archived-At: Subject: Re: [straw] New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:48:25 -0000 (As co-chair) Hi Ram, Thanks for submitting the new version! The chairs intend to ask the community for WG adoption of the draft soon, b= ut we would like those who had issues with earlier versions (especially the= B2BUA DTLS-SRTP termination part) to take a look to see whether their issu= es have been addressed. Thanks! Regards, Christer -----Original Message----- From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R (rmoha= nr) Sent: 11 February 2015 15:39 To: straw@ietf.org Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtl= s-srtp-02.txt This version addresses some of the comments received during reviews from Da= n Wing and Charles Eckel Please review the revision http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-02 Look at the diff here - http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-straw-b2bua-dtls-srtp-02 One major change is - removing the part where we have mentioned about B2BUA= handling all forked responses to INVITE. Since we have reduced the scope o= f this draft to not consider B2BUAs terminating DTLS-SRTP this piece also n= eeds to be removed. Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, 11 February 2015 7:03 pm To: Cisco Employee , "Tirumaleswar Reddy (tireddy)" , Victor Pascual , Victor Pas= cual , Parthasarathi Ravindran , "Gonzalo Salgueiro (gsalguei)" , Parthasarathi Ravindran ,= "Gonzalo Salgueiro (gsalguei)" , "Tirumaleswar Reddy (tireddy)" , C= isco Employee Subject: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-02.txt > >A new version of I-D, draft-ram-straw-b2bua-dtls-srtp-02.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to=20 >the IETF repository. > >Name: draft-ram-straw-b2bua-dtls-srtp >Revision: 02 >Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP) >Back-to-Back User Agents (B2BUAs) >Document date: 2015-02-11 >Group: Individual Submission >Pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-dtls-srtp-02.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-dtls-srtp/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-straw-b2bua-dtls-srtp-02 > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > often function on the media plane, rather than just on the signaling > path. This document describes the behavior B2BUAs should follow when > acting on the media plane that use Secure Real-time Transport (SRTP) > security context setup with Datagram Transport Layer Security (DTLS) > protocol. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw From nobody Mon Feb 23 05:22:47 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E161A1AB0 for ; Mon, 23 Feb 2015 05:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmL7eT8y6y_L for ; Mon, 23 Feb 2015 05:22:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552BB1A1A9F for ; Mon, 23 Feb 2015 05:22:43 -0800 (PST) X-AuditID: c1b4fb30-f79626d000003cf6-47-54eb29a0c88b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.70.15606.0A92BE45; Mon, 23 Feb 2015 14:22:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 14:22:40 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: WGLC: draft-ietf-straw-b2bua-rtcp-03.txt Thread-Index: AdBPa6G93iYYLgF6Tt2JeXOX3wxijQ== Date: Mon, 23 Feb 2015 13:22:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D713C28@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D713C28ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje5CzdchBuf+slg86TzIYnGr+TGr A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxdvdDloL7MhVHbzUxNTBuk+xi5OSQEDCR WPltFzOELSZx4d56NhBbSOAIo8Ssd0oQ9hJGia6FMl2MHBxsAhYS3f+0QcIiAqoSE77cZASx mQXSJW70b2IHsYUFDCUe/N/LDlFjJjFvfi+UrScxcUUjC4jNAtTb82Mq2CpeAV+JWfvXgsUZ gU74fmoNE8RMcYlbT+YzQZwmILFkz3moM0UlXj7+xwphK0ksuv0Zqj5fYs36c+wQMwUlTs58 wjKBUXgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnp pRZlJhcX5+fp5aWWbGIExs7BLb8NdjC+fO54iFGAg1GJh3fD9FchQqyJZcWVuYcYpTlYlMR5 7YwPhQgJpCeWpGanphakFsUXleakFh9iZOLglGpgLHgvwM2jlMb1dOGlkzPT70yWZ+XMX6mg nnv6/lkuleSGF8Hxar+ZL291PtmdlHn2qdAsRfUl6ubzJrBWel0y/rXBtzmWN+33mUpXRyGZ xMN7b5XeFVl/Ye9Km6SqpIfqN7cvvPfm706jzTfdFh32f735+8rPK73m/z2TrZG8/C+TdE7S LrbVs5RYijMSDbWYi4oTAaY5ssJ+AgAA Archived-At: Cc: "draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org" Subject: [straw] WGLC: draft-ietf-straw-b2bua-rtcp-03.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 13:22:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D713C28ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi, This is a working group last call announcement for draft-ietf-straw-b2bua-r= tcp-03.txt. The working group last call will run for 2,5 weeks, until Friday 13th (hope= fully it won't end in horror :). Please provide your comments on the STRAW list. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D713C28ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi,

 

This is a working group last call announcement for d= raft-ietf-straw-b2bua-rtcp-03.txt.

 

The working group last call will run for 2,5 week= s, until Friday 13th (hopefully it won’t end in horror :).=

 

Please provide your comments on the STRAW list.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D713C28ESESSMB209erics_-- From nobody Mon Feb 23 11:57:19 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172041A1B81 for ; Mon, 23 Feb 2015 08:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0DBQ01Jn5TQ for ; Mon, 23 Feb 2015 08:17:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB9D1A1B4C for ; Mon, 23 Feb 2015 08:17:33 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-69-54eb529b30eb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.BF.24955.B925BE45; Mon, 23 Feb 2015 17:17:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Mon, 23 Feb 2015 17:17:30 +0100 Message-ID: <54EB529B.1070004@ericsson.com> Date: Mon, 23 Feb 2015 17:17:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUyM+Jvje7soNchBgt2q1k86TzIYnGr+TGr A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXx5EdewSq5imP3DrE3MN4T72Lk5JAQMJHY PLGHDcIWk7hwbz2QzcUhJHCEUWLbmbdMIAkhgeWMEmdm5ncxcnDwCmhLnDwcABJmEVCV+HK2 lxXEZhOwkLj5oxFsjqhAsMTi50/B4rwCghInZz5hAWkVEXCTeNnpCxIWFnCQeLbhMStImFlA U2L9Ln2QMLOAvETz1tnMEEu1JRqaOlgnMPLNQjJoFkLHLCQdCxiZVzGKFqcWJ+WmGxnrpRZl JhcX5+fp5aWWbGIEBtfBLb9VdzBefuN4iFGAg1GJh7fA4XWIEGtiWXFl7iFGaQ4WJXFeO+ND IUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY25iqdd43fHj0PkqZNa58wfsqlRVFAjGSKnv+ uRycktP55uqFcpvX/30fKBYKHi5sk4ricNSd/j6nKPfXK+WoEo4DVe+fSCv918rff51n4t1r 57dVtW7evP7dfG39x/4b55bM3OPw785yhoSpsYW+vZdmr2HIbu+I2h25xlLB9eHx0pl8PK3p SizFGYmGWsxFxYkA2OK5rg8CAAA= Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 11:57:18 -0800 Subject: [straw] My comments on WGLC for draft-ietf-straw-b2bua-rtcp-03 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 16:17:42 -0000 WG, Section 3.2: APP: [RFC3550] If the B2BUA has changed any SSRC in any direction, it MUST update the SSRC in the BYE message. Copy and paste error "BYE" message. Section 3.2: Feedback messages: [RFC4585] All Feedback messages have a common packet format, which includes the SSRC of the packet sender and the one of the media source the feedack is related to. Just as described for the previous messages, these SSRC identifiers MUST be updated if the B2BUA has changed any SSRC in any direction. It MUST NOT, though, change a media source SSRC that was originally set to zero. Besides, considering that many feedback messages also include additional data as part of their specific Feedback Control Information (FCI), a media-aware B2BUA MUST take care of them accordingly, if it can parse and regenerate them, according to the following guidelines. I think to avoid erroneous behaviour one must demand that any B2BUA that rewrites SSRCs MUST be capable of parsing the FCI for any feedback message it allows being used in the RTP session. Otherwise you will end up with FCI with wrong SSRC information. Thus I would suggest that you remove the caveat from that last sentence to force the implementation to follow them. "It MUST NOT, though, change a media source SSRC that was originally set to zero." This is likely the right decision, however it has the error case when an endpoint uses SSRC 0. Otherwise one must be Feedback message type aware and know if this is an unused 0 or an actually used 0 that then needs rewriting. Section 3.2: At the same time, the ability for a media-aware B2BUA to inspect/modify RTCP packets may also mean such a B2BUA may choose to drop RTCP packets it can't parse: in that case, a media-aware B2BUA SHOULD also advertize its RTCP level of support in the SDP in a coherent way, in order to prevent, for instance, a UAC to make use of NACK messages that would never reach the intended recipients. I wished this was stronger. I think dropping packets only as really last possibility, and then only for issues that are of temporary nature. I would also like to make clear that when one are talking about dropping RTCP packets, then one only drops the offending RTCP packet, not the whole compound RTCP packet. Section 3.2: What about the ECN Feedback messages and RTCP XR report specified in RFC 6679? There are sequence numbers and SSRCs that needs to rewritten consistently here. Section 3.3: I think there should be a reference here to Section 3.2.2 of draft-ietf-avtcore-rtp-topologies-update. Somewhere: I am missing a discussion of the impact of both reduced size RTCP (RFC 5506) as well as RTP/RTCP multiplexing (RFC 5761). The reduced size is mostly a question if the endpoint as well as the B2BUA can support it, thus enable it coherently across the both sides. When it comes to RTP/RTCP multiplexing, it can be used by the Media-aware relay as well as the media terminator on each leg independently given that it ensure that there are no conflicting RTP payload type numbers on both sides alternatively is capable of rewriting RTP payload type numbers to ensure no conflict in the domain where the RTP/RTCP multiplexing is applied. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 24 00:09:32 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECD1A8714 for ; Tue, 24 Feb 2015 00:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ARxi0X8OzL for ; Tue, 24 Feb 2015 00:09:28 -0800 (PST) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id B577B1A8712 for ; Tue, 24 Feb 2015 00:09:27 -0800 (PST) Received: from lminiero ([79.43.26.85]) by smtpcmd01.ad.aruba.it with bizsmtp id w89M1p0081qA56P0189Mki; Tue, 24 Feb 2015 09:09:25 +0100 Date: Tue, 24 Feb 2015 09:09:20 +0100 From: Lorenzo Miniero To: Magnus Westerlund Message-ID: <20150224090920.75735d61@lminiero> In-Reply-To: <54EB529B.1070004@ericsson.com> References: <54EB529B.1070004@ericsson.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: straw@ietf.org, draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [straw] My comments on WGLC for draft-ietf-straw-b2bua-rtcp-03 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 08:09:31 -0000 Hello Magnus, thanks a lot for your detailed review! I've added a couple of inline comments. On Mon, 23 Feb 2015 17:17:31 +0100 Magnus Westerlund wrote: > WG, >=20 >=20 > Section 3.2: >=20 > APP: [RFC3550] > If the B2BUA has changed any SSRC in any direction, it MUST > update the SSRC in the BYE message. >=20 > Copy and paste error "BYE" message. >=20 Ack. >=20 > Section 3.2: >=20 > Feedback messages: [RFC4585] > All Feedback messages have a common packet format, which > includes the SSRC of the packet sender and the one of the media > source the feedack is related to. Just as described for the previous > messages, these SSRC identifiers MUST be updated if the B2BUA > has changed any SSRC in any direction. It MUST NOT, though, change a > media source SSRC that was originally set to zero. Besides, > considering that many feedback messages also include additional > data as part of their specific Feedback Control Information > (FCI), a media-aware B2BUA MUST take care of them accordingly, if it > can parse and regenerate them, according to the following guidelines. >=20 > I think to avoid erroneous behaviour one must demand that any B2BUA > that rewrites SSRCs MUST be capable of parsing the FCI for any > feedback message it allows being used in the RTP session. Otherwise > you will end up with FCI with wrong SSRC information. Thus I would > suggest that you remove the caveat from that last sentence to force > the implementation to follow them. >=20 That's a good point, I'll remove that part. > "It MUST NOT, though, change a > media source SSRC that was originally set to zero." >=20 > This is likely the right decision, however it has the error case when > an endpoint uses SSRC 0. Otherwise one must be Feedback message type > aware and know if this is an unused 0 or an actually used 0 that then > needs rewriting. >=20 I hadn't thought about that: I'll add a clarification in the points where we talk about an SSRC=3D0, specifying that it must not be changed unless the B2BUA is aware of an actually used SSRC=3D0 in the managed sessions. >=20 > Section 3.2: > At the same time, the > ability for a media-aware B2BUA to inspect/modify RTCP packets may > also mean such a B2BUA may choose to drop RTCP packets it can't > parse: in that case, a media-aware B2BUA SHOULD also advertize its > RTCP level of support in the SDP in a coherent way, in order to > prevent, for instance, a UAC to make use of NACK messages that > would never reach the intended recipients. >=20 > I wished this was stronger. I think dropping packets only as really > last possibility, and then only for issues that are of temporary > nature. I would also like to make clear that when one are talking > about dropping RTCP packets, then one only drops the offending RTCP > packet, not the whole compound RTCP packet. >=20 By stronger you mean turn the SHOULD to a MUST? Will clarify about just stripping the unknown RTCP from the compound packet. > Section 3.2: >=20 > What about the ECN Feedback messages and RTCP XR report specified in > RFC 6679? There are sequence numbers and SSRCs that needs to rewritten > consistently here. >=20 Thanks for this, I wasn't sure indeed whether we were covering all the RTCP messages. XR are already there in general, ECN and related XR are not, so I'll add them. >=20 > Section 3.3: >=20 > I think there should be a reference here to Section 3.2.2 of > draft-ietf-avtcore-rtp-topologies-update. >=20 Thanks, I'll add this. >=20 > Somewhere: >=20 > I am missing a discussion of the impact of both reduced size RTCP (RFC > 5506) as well as RTP/RTCP multiplexing (RFC 5761). >=20 > The reduced size is mostly a question if the endpoint as well as the > B2BUA can support it, thus enable it coherently across the both sides. >=20 Good point, will do. I wonder if it makes sense to also suggest "gatewaying" reduced to/from non-reduced size RTP, in case one side supports it and the other doesn't. If one is trying to use it it's probably for a good reason, and if the B2BUA can take care of that if might help. > When it comes to RTP/RTCP multiplexing, it can be used by the > Media-aware relay as well as the media terminator on each leg > independently given that it ensure that there are no conflicting RTP > payload type numbers on both sides alternatively is capable of > rewriting RTP payload type numbers to ensure no conflict in the > domain where the RTP/RTCP multiplexing is applied. >=20 Same as above, I'm wondering if, for the Media-aware and Media terminator cases, we can also state that a B2BUA can keep an rtcp-mux session on one side and a non-muxed on the other side, in case that peer doesn't support it, if it makes sure that it will multiplex/demultiplex properly on both sides and that it will take care of the negotiation accordingly. This might make sense to limit the amount of network resources used at least on one side of the communication, for just a little additional complexity to just relaying. Thanks again for this! Lorenzo=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Feb 24 01:08:23 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF581A8737 for ; Tue, 24 Feb 2015 01:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGNHGFr9EQu7 for ; Tue, 24 Feb 2015 01:08:20 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2FC1A872D for ; Tue, 24 Feb 2015 01:08:19 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-ed-54ec3f818524 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.DD.04076.18F3CE45; Tue, 24 Feb 2015 10:08:17 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Tue, 24 Feb 2015 10:08:16 +0100 Message-ID: <54EC3F74.1070309@ericsson.com> Date: Tue, 24 Feb 2015 10:08:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lorenzo Miniero References: <54EB529B.1070004@ericsson.com> <20150224090920.75735d61@lminiero> In-Reply-To: <20150224090920.75735d61@lminiero> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+JvjW6j/ZsQg8ONAhZPOg+yWGzfsoDJ 4lbzY1YHZo8lS34yeXQ8vM/u8eXyZ7YA5igum5TUnMyy1CJ9uwSujF2rWxgLWnUqNs1aztLA +EOpi5GTQ0LAROLljPPsELaYxIV769m6GLk4hASOMEpMnbeUBcJZzijxaFsvE0gVr4C2RN+7 mywgNouAqsSzV89ZQWw2AQuJmz8a2UBsUYFgicXPn7JC1AtKnJz5BKxeREBLYsbceYxdjBwc zAJuEr+vcICEhQV8JGauvgNWIiTgJ/H22R52kBJOAX2Jo12BENWaEut36YNUMAvISzRvnc0M Ua0t0dDUwTqBUXAWkl2zEDpmIelYwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMweA9u +W21g/Hgc8dDjAIcjEo8vAWKb0KEWBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8q zUktPsTIxMEp1cAYMv9s5YLZefaKfc6b53W/s++/zOho0h+hddvRbu3v5Ca25UXv0qfOaO2T vRgb8Onfd+55XjMEok+Xyu9i4r874Xpz0Mr5h8oW6Da0dPwXT5FRKImMWGm+nvXJ+68bXq+f pzhhl03YjOhtHEycKXd+nWJvusB8fCNP6dx5hZ46sdIX7y/oKDZVYinOSDTUYi4qTgQAiiCA RD8CAAA= Archived-At: Cc: straw@ietf.org, draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [straw] My comments on WGLC for draft-ietf-straw-b2bua-rtcp-03 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 09:08:22 -0000 Hi, I have responded where necessary and removed where there appear to be no need for further comments. On 2015-02-24 09:09, Lorenzo Miniero wrote: > On Mon, 23 Feb 2015 17:17:31 +0100 > Magnus Westerlund wrote: > > >> >> Section 3.2: >> At the same time, the >> ability for a media-aware B2BUA to inspect/modify RTCP packets may >> also mean such a B2BUA may choose to drop RTCP packets it can't >> parse: in that case, a media-aware B2BUA SHOULD also advertize its >> RTCP level of support in the SDP in a coherent way, in order to >> prevent, for instance, a UAC to make use of NACK messages that >> would never reach the intended recipients. >> >> I wished this was stronger. I think dropping packets only as really >> last possibility, and then only for issues that are of temporary >> nature. I would also like to make clear that when one are talking >> about dropping RTCP packets, then one only drops the offending RTCP >> packet, not the whole compound RTCP packet. >> > > > By stronger you mean turn the SHOULD to a MUST? Will clarify about just > stripping the unknown RTCP from the compound packet. > Yes, I would prefer a MUST here. A media-aware B2BUA that performs RTP level translation must understand the RTCP related to the media streams it modifies. Unknown RTCP in that case becomes a issue. That message can be directly related to the media stream it produces and thus needs translation. Thus if it is going drop to prevent inconsistencies, it really should signal its capabilities. Unfortunately the B2BUA is going to be a third party that needs support for any extension one like to use. But, that is unavoidable when it performs modifications. A Media-aware relay that only performs inspection but not modification actually works much closer to a media relay and could thus potentially accept unknown RTCP packets. However, that is likely against its role of policy enforcer. > >> Section 3.2: >> >> What about the ECN Feedback messages and RTCP XR report specified in >> RFC 6679? There are sequence numbers and SSRCs that needs to rewritten >> consistently here. >> > > > Thanks for this, I wasn't sure indeed whether we were covering all the > RTCP messages. XR are already there in general, ECN and related XR are > not, so I'll add them. > > >> >> Section 3.3: >> >> I think there should be a reference here to Section 3.2.2 of >> draft-ietf-avtcore-rtp-topologies-update. >> > > > Thanks, I'll add this. > > >> >> Somewhere: >> >> I am missing a discussion of the impact of both reduced size RTCP (RFC >> 5506) as well as RTP/RTCP multiplexing (RFC 5761). >> >> The reduced size is mostly a question if the endpoint as well as the >> B2BUA can support it, thus enable it coherently across the both sides. >> > > > Good point, will do. I wonder if it makes sense to also suggest > "gatewaying" reduced to/from non-reduced size RTP, in case one side > supports it and the other doesn't. If one is trying to use it it's > probably for a good reason, and if the B2BUA can take care of that if > might help. So for a Media Terminator, this is a no brainer, use it on each leg independently. Doing the translation in media-aware is possible but far from trivial. The reason is that a reduced size RTCP implementation can issue a higher rate of RTCP feedback messages due to the gains from the reduced size. If these messages needs timely response from the other peer the translator will have issues to get them there, unless the RTCP bandwidth is different on each side. In which case you end up with other issues, which makes me not recommend that. So I think RTP/RTCP mux is fine to gateway. Reduced Size should have a warning attached. > > >> When it comes to RTP/RTCP multiplexing, it can be used by the >> Media-aware relay as well as the media terminator on each leg >> independently given that it ensure that there are no conflicting RTP >> payload type numbers on both sides alternatively is capable of >> rewriting RTP payload type numbers to ensure no conflict in the >> domain where the RTP/RTCP multiplexing is applied. >> > > > Same as above, I'm wondering if, for the Media-aware and Media > terminator cases, we can also state that a B2BUA can keep an rtcp-mux > session on one side and a non-muxed on the other side, in case that > peer doesn't support it, if it makes sure that it will > multiplex/demultiplex properly on both sides and that it will take care > of the negotiation accordingly. This might make sense to limit the > amount of network resources used at least on one side of the > communication, for just a little additional complexity to just relaying. Yes, I think a Media-Aware B2BUA that has the PT translation capabilities doing RTP/RTCP mux gatewaying is a quite simple operation. The only important issue here is to ensure that there is room to do the PT translation, but that should not be an issue so far. But, it does put requirement on a signalling part to verify that. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Feb 24 02:31:44 2015 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8E1A8727 for ; Tue, 24 Feb 2015 02:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yclKF6HqcuEg for ; Tue, 24 Feb 2015 02:31:41 -0800 (PST) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id E61CF1A020B for ; Tue, 24 Feb 2015 02:31:40 -0800 (PST) Received: from lminiero ([87.17.90.173]) by smtpcmd01.ad.aruba.it with bizsmtp id wAXd1p01h3kQe4701AXdfm; Tue, 24 Feb 2015 11:31:39 +0100 Date: Tue, 24 Feb 2015 11:31:37 +0100 From: Lorenzo Miniero To: Magnus Westerlund Message-ID: <20150224113137.44d45092@lminiero> In-Reply-To: <54EC3F74.1070309@ericsson.com> References: <54EB529B.1070004@ericsson.com> <20150224090920.75735d61@lminiero> <54EC3F74.1070309@ericsson.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: straw@ietf.org, draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [straw] My comments on WGLC for draft-ietf-straw-b2bua-rtcp-03 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 10:31:43 -0000 Hi Magnus, thanks again for this very quick new round of feedback! I'll make sure I'll address all your points in the new version of the document. Lorenzo On Tue, 24 Feb 2015 10:08:04 +0100 Magnus Westerlund wrote: > Hi, >=20 > I have responded where necessary and removed where there appear to be > no need for further comments. >=20 > On 2015-02-24 09:09, Lorenzo Miniero wrote: > > On Mon, 23 Feb 2015 17:17:31 +0100 > > Magnus Westerlund wrote: > >=20 >=20 >=20 > >=20 > >> > >> Section 3.2: > >> At the same time, the > >> ability for a media-aware B2BUA to inspect/modify RTCP packets > >> may also mean such a B2BUA may choose to drop RTCP packets it can't > >> parse: in that case, a media-aware B2BUA SHOULD also advertize > >> its RTCP level of support in the SDP in a coherent way, in order to > >> prevent, for instance, a UAC to make use of NACK messages that > >> would never reach the intended recipients. > >> > >> I wished this was stronger. I think dropping packets only as really > >> last possibility, and then only for issues that are of temporary > >> nature. I would also like to make clear that when one are talking > >> about dropping RTCP packets, then one only drops the offending RTCP > >> packet, not the whole compound RTCP packet. > >> > >=20 > >=20 > > By stronger you mean turn the SHOULD to a MUST? Will clarify about > > just stripping the unknown RTCP from the compound packet. > >=20 >=20 > Yes, I would prefer a MUST here. >=20 > A media-aware B2BUA that performs RTP level translation must > understand the RTCP related to the media streams it modifies. Unknown > RTCP in that case becomes a issue. That message can be directly > related to the media stream it produces and thus needs translation. > Thus if it is going drop to prevent inconsistencies, it really should > signal its capabilities. >=20 > Unfortunately the B2BUA is going to be a third party that needs > support for any extension one like to use. But, that is unavoidable > when it performs modifications. >=20 > A Media-aware relay that only performs inspection but not modification > actually works much closer to a media relay and could thus potentially > accept unknown RTCP packets. However, that is likely against its role > of policy enforcer. >=20 > >=20 > >> Section 3.2: > >> > >> What about the ECN Feedback messages and RTCP XR report specified > >> in RFC 6679? There are sequence numbers and SSRCs that needs to > >> rewritten consistently here. > >> > >=20 > >=20 > > Thanks for this, I wasn't sure indeed whether we were covering all > > the RTCP messages. XR are already there in general, ECN and related > > XR are not, so I'll add them. > >=20 > >=20 > >> > >> Section 3.3: > >> > >> I think there should be a reference here to Section 3.2.2 of > >> draft-ietf-avtcore-rtp-topologies-update. > >> > >=20 > >=20 > > Thanks, I'll add this. > >=20 > >=20 > >> > >> Somewhere: > >> > >> I am missing a discussion of the impact of both reduced size RTCP > >> (RFC 5506) as well as RTP/RTCP multiplexing (RFC 5761). > >> > >> The reduced size is mostly a question if the endpoint as well as > >> the B2BUA can support it, thus enable it coherently across the > >> both sides. > >> > >=20 > >=20 > > Good point, will do. I wonder if it makes sense to also suggest > > "gatewaying" reduced to/from non-reduced size RTP, in case one side > > supports it and the other doesn't. If one is trying to use it it's > > probably for a good reason, and if the B2BUA can take care of that > > if might help. >=20 > So for a Media Terminator, this is a no brainer, use it on each leg > independently. Doing the translation in media-aware is possible but > far from trivial. The reason is that a reduced size RTCP > implementation can issue a higher rate of RTCP feedback messages due > to the gains from the reduced size. If these messages needs timely > response from the other peer the translator will have issues to get > them there, unless the RTCP bandwidth is different on each side. In > which case you end up with other issues, which makes me not recommend > that. So I think RTP/RTCP mux is fine to gateway. Reduced Size should > have a warning attached. >=20 > >=20 > >=20 > >> When it comes to RTP/RTCP multiplexing, it can be used by the > >> Media-aware relay as well as the media terminator on each leg > >> independently given that it ensure that there are no conflicting > >> RTP payload type numbers on both sides alternatively is capable of > >> rewriting RTP payload type numbers to ensure no conflict in the > >> domain where the RTP/RTCP multiplexing is applied. > >> > >=20 > >=20 > > Same as above, I'm wondering if, for the Media-aware and Media > > terminator cases, we can also state that a B2BUA can keep an > > rtcp-mux session on one side and a non-muxed on the other side, in > > case that peer doesn't support it, if it makes sure that it will > > multiplex/demultiplex properly on both sides and that it will take > > care of the negotiation accordingly. This might make sense to limit > > the amount of network resources used at least on one side of the > > communication, for just a little additional complexity to just > > relaying. >=20 > Yes, I think a Media-Aware B2BUA that has the PT translation > capabilities doing RTP/RTCP mux gatewaying is a quite simple > operation. The only important issue here is to ensure that there is > room to do the PT translation, but that should not be an issue so > far. But, it does put requirement on a signalling part to verify that. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw