Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06

Ari Keränen <> Fri, 17 May 2013 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0319221F95FF for <>; Fri, 17 May 2013 08:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.789
X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EhlmaATwiepV for <>; Fri, 17 May 2013 08:49:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8BA321F9602 for <>; Fri, 17 May 2013 08:49:38 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-8c-519651910dd4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 92.8D.06701.19156915; Fri, 17 May 2013 17:49:37 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server id; Fri, 17 May 2013 17:49:37 +0200
Received: from ( []) by (Postfix) with ESMTP id 2BBD123E9; Fri, 17 May 2013 18:49:37 +0300 (EEST)
Received: from (localhost []) by (Postfix) with ESMTP id 15FF455018; Fri, 17 May 2013 18:49:36 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost []) by (Postfix) with ESMTP id 8889254438; Fri, 17 May 2013 18:49:35 +0300 (EEST)
Message-ID: <>
Date: Fri, 17 May 2013 18:49:36 +0300
From: Ari Keränen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre7EwGmBBs/3q1vc7X3BZDF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStjYusCtoKbghVb/u9mamDcw9vFyMkhIWAi 8eroIXYIW0ziwr31bF2MXBxCAqcYJVpuP2OGcDYAOW9ms0I4uxklVu7dB1W2jlFi1ZtbjCD9 QgIrGCU+f6wAsXkFNCUOntwA1M7BwSKgKvFqtxlImE3AXuLmhOtg60QFkiWW7lzKBlEuKHFy 5hMWEFtEwELi+pR3zCA2s4CMxIyzjUwgtrCAn0TfoZ1MEKs0JHp2bAKbwwm0auaXmUwQ9bYS F+ZcZ4Gw5SW2v53DDPGamsTVc5uYIXpVJa7+e8U4gVF0FpLVs5C0z0LSvoCReRUje25iZk56 ufkmRmDYH9zy22AH46b7YocYpTlYlMR5+7SnBgoJpCeWpGanphakFsUXleakFh9iZOLglGpg bDX9mcTb4JDx0sVTnHXrn+faXnot8fk7Nz6RzpM8Nn2ywQY3vmOpf160GJ35xPciQPDWB1ER 7eO3VcqnFj6rfzR1z8pfctUtXlXzz81uvOZXxDhJ/8irisUn9nPHezH9eiZjEDtp2VH+fB9P 4f6VJVM/+jCtPFy02JL51Kplm+9mOLr8PLdaUYmlOCPRUIu5qDgRAI/F97FJAgAA
Cc: mmusic <>
Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06
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: Fri, 17 May 2013 15:49:44 -0000


I had a quick read over the draft and have a few comments:

3.  Requirements on NAT-Traversal

    1.  Must work for all flavors of NATs, including NATs with address
        and port restricted filtering.

The term used by RFC 4787 is "Address and Port-Dependent Filtering"

3.  Requirements on NAT-Traversal

    The list of feature requirements for RTSP NAT solutions are given

I guess this should say "RTSP NAT traversal solutions".

        *  Address discovery for NAT traversal should take automatically,
           if possible

I assume this means the discovery of the address assigned by the NAT? 
Maybe say that explicitly, e.g., "Discovery of the address(es) assigned 
by NAT should happen automatically if possible".

4.7.4.  Security Considerations

    An ALG will not work whit deployment of end-to-end RTSP signaling

Typo: whit

4.9.1.  [TURN] Introduction

    On the external side this is
    limited to the source address/port pair of the first packet arriving
    on the binding.  After the first packet has arrived the mapping is
    "locked down" to that address.  Packets from any other source on this
    address will be discarded.

This doesn't sound right. This behavior was changed (eventually into 
using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See for up-to-date behavior. 
Check also steps 5 & 7 in the next section and section 4.9.4 for more 
lock down text.

6.  Comparison of NAT traversal techniques

    C2:  How Robust is the solution to changing NAT behaviors

Since the answer is yes/no, maybe this should be "is the solution robust..."

10.  Informative References

               "Open Source STUN Server and Client, http://
               June 2007.

This site seems to be unavailable nowadays. Better reference would be 
"". And of course, there are plenty 
of other open source STUN implementations, but likewise there are for 
ICE (PJNATH, libnice, ice4j, etc.) if we want to use that as an argument.

Ari (as individual)