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

Magnus Westerlund <> Mon, 17 December 2012 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8559B21F8B44 for <>; Mon, 17 Dec 2012 08:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.212
X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6nd0iR0DV03P for <>; Mon, 17 Dec 2012 08:07:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C4AB321F8B3B for <>; Mon, 17 Dec 2012 08:07:38 -0800 (PST)
X-AuditID: c1b4fb25-b7fb26d000006129-fe-50cf4349f3e4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5E.ED.24873.9434FC05; Mon, 17 Dec 2012 17:07:37 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 17 Dec 2012 17:07:37 +0100
Message-ID: <>
Date: Mon, 17 Dec 2012 17:07:37 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ari Keranen <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja6n8/kAgxX39S3a3vxis2h/c4TJ YuryxywOzB5Llvxk8uhcFO3x5fJntgDmKC6blNSczLLUIn27BK6MXTu/sBY0Slc8uHWLtYFx kWgXIyeHhICJxMebV5ggbDGJC/fWs3UxcnEICZxklJh6bD1YQkhgOaPE6Y8GIDavgLbEpQtP wOIsAqoSN388Zgax2QQsgOxGNhBbVMBXYtaeX0wQ9YISJ2c+YQGxRQR0JLq33QWLMwu4Sxw9 9B2sV1jASmL/u35WiF35Ep9ffmXsYuTg4BTQk3i9xwPiNkmJRdM6WSBa9SSmXG1hhLDlJZq3 zmaGaNWWaGjqYJ3AKDQLyeZZSFpmIWlZwMi8ipE9NzEzJ73caBMjMHQPbvmtuoPxzjmRQ4zS HCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsMltSpjYnd4n5j5SdH3afmsF8 pvdBwpn2pvx7AQ8rCtpnPa7QnaX1SsMzgd2wmut10iJOnVMPpu59XtXkO93d5MXM6z4n28XF Na6VJt57Y+T8Tk9je0aB8Iv56v17HBZ4ZO5TP++YmSlmwfDgGtM1fR//vOe6c74YG20r2KMp N9ePn0d50WwlluKMREMt5qLiRADyD/qfKwIAAA==
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 16:07:40 -0000

On 2012-12-17 16:36, Ari Keranen wrote:
> 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.

OK, so far I haven't actually done such an addition to the modified
texts. But I will see what I can do before submitting the update.

> [...]
>>>     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?

I guess this needs to be expanded a bit. What I mean is that if due to
some reason one get a lower prioritized pair to respond and then get an
answer from the more prioritized then it actually makes sense to unlock
the full checklist for the more prioritized and let it run to completion
prior to sending the PLAY request.


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: