Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt

Flemming Andreasen <fandreas@cisco.com> Mon, 29 October 2012 18:39 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551F21F8711 for <mmusic@ietfa.amsl.com>; Mon, 29 Oct 2012 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wq9ZYYASxed for <mmusic@ietfa.amsl.com>; Mon, 29 Oct 2012 11:39:13 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFB21F8720 for <mmusic@ietf.org>; Mon, 29 Oct 2012 11:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4847; q=dns/txt; s=iport; t=1351535952; x=1352745552; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2PuQuexzVf7aw+s6tlMkDWlbQsAdaXddQ0dCJHcS0KY=; b=lc0ADOYczubCt3MouhUAuZApOY4O3+EMWkYkSiSx7LA2p2qBVue+71T6 c2up1iEX7DqMnQHRbTN80x+07vnJg9ruu4Cxassg0B27qXmrd9zq7xC7R +yKdb2mcV3ae6dm3jO20cYUHHw10efqGHHAJ/jHbF0xrrqtu+txLmTn5k E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAP/MjlCtJXHA/2dsb2JhbABEwn+BCIIeAQEBAwEMBgEfAQUzDgUJAgsYCR4HDwIKKxEGDQEFAgEBHodeBpwPn3MEkk4DlXSOV4Frgws
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="136572952"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2012 18:39:08 +0000
Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9TId7DT008756; Mon, 29 Oct 2012 18:39:08 GMT
Message-ID: <508ECD4B.60404@cisco.com>
Date: Mon, 29 Oct 2012 14:39:07 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <20120507075517.12573.64357.idtracker@ietfa.amsl.com> <4FA78A27.4040004@ericsson.com> <507724C4.5090601@cisco.com> <50894F35.1060601@ericsson.com>
In-Reply-To: <50894F35.1060601@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 18:39:14 -0000

On 10/25/12 10:39 AM, Magnus Westerlund wrote:
> Hi Flemming and WG,
>
> Thanks for the detailed review. As you might have seen we managed to
> update this document to address your comments.
Thanks for the update Magnus - responses below, incl. a request for more 
people to weigh in.

> Below is answers to these
> questions.
>
> On 2012-10-11 21:57, Flemming Andreasen wrote:
>> Hi Magnus
>>
>> I have taken a look at the document and, the only real technical
>> comments I have at this point are:
>>
>> - Section 6.3 (Non-Supporting Proxies), last paragraph says that:
>> <quote>
>> This variance in results is the reason
>>     we don't recommend the usage of the Proxy-Require header. Instead we
>>     recommend the usage of the Supported header to force proxies to
>>     include the feature tags they support in the proxy-supported which
>>     will provide a positive indication when all proxies in the chain
>>     between the client and server support the functionality.  Even if not
>>     explicitly indicating support, any SETUP response including a
>>     transport specification with "D-ICE" will be implicit indication that
>>     the proxy chain supports at least passthrough of this media.
>> </quote>
>>
>> I didn't follow the inferred logic in the last sentence (how does the
>> response convey support for the entire chain). Can you elaborate on that
>> part ?
> We have reformulated this to hopefully make it clear. But the logic is
> like this.
>
> If a client includes a transport specification with protocol D-ICE, and
> that reaches the server and that supports it and provide that transport
> spec in its answer that again reaches the client then you know that the
> D-ICE is supported. This would only occur if any proxies are either
> explicitly supporting it or are of the pass-through version.
>
> That needs to be compared with a proxy-require where the passthrough
> would be forced to negatively answer that. Also a supported header value
> will be stripped by a passthrough proxy as it is not explicitly
> supporting the functionality.
>
> That is why you have cases where trying and see if it works might be the
> best option.

The updated text makes it much clearer.

>> - Section 8 (Fallback)
>> Section title and overall description is a bit confusing (it seems to be
>> about about backwards compatibility with non-ICE supporting RTSP entities).
>> Also, the section recommends use of defunct (obsolete) behavior defined
>> in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we
>> be based on RFC 5389) ?
> This fallback text is intended as a discussion of what would happen if a
> ICE enabled client would try to use its capabilities to facilitate
> NAT/FW traversal when the server is non ICE capable.
>
> The second thing to remember is that a SETUP request normally provides
> multiple transport offers, rather than doing try, error, re-try other
> alternative.
>
> Thus I at least think it is worth talking what it would mean to use STUN
> derived reflex ports as transport identifier and then be willing to send
> STUN checks towards the server. So far you actually don't need to do a
> attempt to determine the mapping behavior. If one would try it could
> reveal the failure mode earlier.
The updated text makes the brittleness issue clearer and also notes that 
RFC3489 based NAT type detection may not work, so I'm ok with that.

> But, maybe we should re-structure this section to say that like ICE the
> best fallback addresses from functionality point of view would be a
> relay address. Barring that one can attempt using a STUN derived one.
> This may however fail, and have unexpected impact on server.
>
I think it would be worthwhile including that (but would welcome other 
points of view).

Also, apart from this, I think we are ready to issue WGLC on this one.

> I do agree that we should not depend on the classification behavior of
> the old STUN spec. But, the text really is a warning that this is brittle.
The updated text makes this clearer.
>> Also, we could really use another set of eyes on it (preferably by
>> somebody that has both ICE and RTSP expertise)
> Me to.
Can we get any volunteers (or suggested names we can bug :-) ?

Thanks

-- Flemming


> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> .
>