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

[Randell Jesup <[e-mail]>]

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.
http://www.ietf.org/id/draft-kaufman-rtp-compatible-data-00.txt

|    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
[e-mail]