Re: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtp-compatible-data-00.txt

Randell Jesup <> Wed, 06 July 2011 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A565621F8717 for <>; Tue, 5 Jul 2011 20:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7DOOsMt36Yz4 for <>; Tue, 5 Jul 2011 20:20:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D94321F884F for <>; Tue, 5 Jul 2011 20:20:49 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QeIfR-0005Y7-0o for; Tue, 05 Jul 2011 22:20:49 -0500
Message-ID: <>
Date: Tue, 05 Jul 2011 23:17:34 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtp-compatible-data-00.txt
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: Wed, 06 Jul 2011 03:20:51 -0000

On 6/29/2011 8:50 PM, Matthew Kaufman wrote:
> I wrote up a method for sending unreliable datagrams to the same port 
> as is being used for RTP, RTCP and STUN that does not conflict with 
> this usage. It also addresses the security issues involved in allowing 
> arbitrary datagrams to be sent.

|    One alternative considered was to encapsulate the arbitrary datagrams
|    within RTP as an RTP payload type.  However the semantics associated
|    with RTP are not always appropriate, depending on the type of
|    arbitrary data being transmitted.

This needs to be expanded on.  Why are they not appropriate?  (Not 
disagreeing, but state it please.)

If this data traverses various SBC/midboxes/NATs-with-ALGs/etc, will the 
apparent "invalid" nature cause possible breakage?

| 5.  Security Considerations
|    The contents of these messages SHOULD be encrypted.  Reuse of the
|    keying used for an associated RTP session that is using the same IP
|    address and port MAY be an acceptable method of key specification and
|    cryptosystem choice.

I'd say "The User Message Data of these messages"... to avoid confusion 
about encryption of the
all-zeros 4-byte header.

Also: should it say anything about authentication?

Congestion control needs to be discussed, even if it's to say that it's 
the job of a higher or application layer to define.  I do want to as 
part of rtcweb design make congestion handling be unified, whether or 
not we use a single port (though we probably should use 1 port).

Randell Jesup