Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review

Ari Keranen <> Mon, 17 December 2012 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0195221F889B for <>; Mon, 17 Dec 2012 07:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B24d8Wol3Zeq for <>; Mon, 17 Dec 2012 07:36:37 -0800 (PST)
Received: from (unknown [IPv6:2001:14b8:400:101::2]) by (Postfix) with ESMTP id 53C0A21F886B for <>; Mon, 17 Dec 2012 07:36:37 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F324A4E6FA; Mon, 17 Dec 2012 17:36:35 +0200 (EET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wVoEUdhIcKA6; Mon, 17 Dec 2012 17:36:35 +0200 (EET)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTPSA id 665C54E6F8; Mon, 17 Dec 2012 17:36:35 +0200 (EET)
Message-ID: <>
Date: Mon, 17 Dec 2012 17:36:35 +0200
From: Ari Keranen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc:, mmusic <>
Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Dec 2012 15:36:38 -0000

Hi Magnus,

On 12/6/12 5:03 PM, Magnus Westerlund wrote:
> On 2012-12-05 22:22, Ari Keranen wrote:
>> 3.  Solution Overview
>>          The client then installs the STUN servers on each of
>>          the local candidates transport addresses it has gathered
>> I would rather say "The client then prepares to act as a STUN server on
>> each [...]"
> Sure, maybe "runs STUN servers" is better than both "installs" and
> "act". They are STUN server, but with limited utility. Act as STUN
> servers sounds like it is impersonating STUN, rather than actually being
> STUN servers.

"runs" sounds good to me.

>>          If the server has a public
>>          IP address, then a single candidate per address family
>> In some cases (e.g., certain ISPs, I've heard) even "public" IP address
>> does not mean you're not behind a NAT. Maybe it's better to say here "If
>> the server is not behind a NAT". Same issue in step 8.
> Sure, maybe we need to define what we mean with not being behind a NAT.
> It is a matter of being reachable from the top anchorin address domain
> in regards to the clients.

Yes, that would be good.

>>     Aggressive nomination SHALL be used with RTSP.  This doesn't have the
>>     negative impact that it has in offer/answer as media playing only
>>     starts after issuing a PLAY request.
>> But it does have the downside of possibly selecting a lower-priority
>> pair due to single dropped (e.g., due to congestion) connectivity check
>> message for a higher priority pair. That said, probably SHALL is
>> appropriate here, just wanted to make sure the implications are understood.
> Yes, but with ICE-RTSP you will retransmit the higher priority also,
> thus if that works and you get a response that alternative is nominated
> and will be used. But we probably should clarify what it means when
> multiple candidate pairs are nominated, and in worse case the server
> will use different paths for different media streams.

According to ICE RFC, if multiple pairs end up nominated due to 
aggressive nomination, the highest priority one will be used (you get 
some transient behavior).

But do you mean that you will keep retransmitting on a higher priority 
pair even if a lower priority pair has been (aggressively) selected and 
all check lists are in Completed state?