Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01

Harald Alvestrand <> Thu, 03 October 2013 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F410321F9BA4 for <>; Thu, 3 Oct 2013 12:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Stf5V0lW84Bh for <>; Thu, 3 Oct 2013 12:04:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 651D221E805F for <>; Thu, 3 Oct 2013 11:54:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0916A39E27D; Thu, 3 Oct 2013 20:54:58 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RmMtdeWNMqCO; Thu, 3 Oct 2013 20:54:57 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7813A39E222; Thu, 3 Oct 2013 20:54:56 +0200 (CEST)
Message-ID: <>
Date: Thu, 03 Oct 2013 20:54:54 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <006401cebf96$7db7a4f0$7926eed0$>, <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Oct 2013 19:05:03 -0000

I've modified my copy of the transport draft as follows:

   ICE TCP candidates, either using TURN [RFC6062] or not [RFC6544] MAY
   be supported; this may allow applications to achieve peer-to-peer
   communication across UDP-blocking firewalls.

   NOTE IN DRAFT: The profile used is RTP/SAVPF.  RFC 4571 registers the
   profile "TCP/RTP/AVP", but there's no registration for "TCP/RTP/
   SAVPF", which corresponds to the RTP/SAVPF profile recommended
   elsewhere in the RTCWEB specifications.  RFC 6544 shows examples both
   with and without the TCP/ prefix.  Should we suggest that in general,
   the prefix should not be used?  If the prefix should be used, TCP/
   RTP/SAVPF needs to be registered.

I must admit that I don't follow the logic behind RTP profile names in
SDP these days; they seem to vaccilate between transport protocol and no
transport protocol.
I think I prefer "no transport protocol", keeping the profile name
constant across different transports, but this is probably a subject
that either rtp-usage or jsep needs to tackle explicitly.