Re: [rtcweb] [tram] Payload Types assignments

[Harald Alvestrand <[e-mail]>]

On 03/13/2014 10:02 AM, Karl Stahl wrote:
>
> For the"mission to bring quality to real-time traffic over our best 
> effort Internet" I have started 
> http://www.ietf.org/mail-archive/web/tram/current/msg00331.html
>
> [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 
> IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2]
>
> Hi Magnus,
>
> With the response just sent to Pål 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, 
> skipping all the QoS methods and functions that really does not belong 
> here when creating an "Interface to QoS", I only see the suggestion of 
> "data channel information", i.e. also marking each data channel packet 
> with traffic bandwidth and type information  to be relevant and 
> interesting. I checked with one of our developers and I think the same 
> traffic information as for RTP can be transferred in data channel 
> packets as follows:
>
> The RTP header has the following format (RFC 3550):
>
> 0                   1                   2 3
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |V=2|P|X|  CC   |M|     PT      |       sequence number         |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | timestamp                           |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |           synchronization source (SSRC) identifier            |
>
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
> |            contributing source (CSRC) identifiers             |
>
> | ....                              |
>
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
> |            RFC5285 header extension ...                      |
>
> |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |
>
> | ....                              |
>
> RTP Payload (often encrypted)
>
> A Data Channel header could have the following format:
>
> 0                   1                   2 3
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    | Data Channel Magic Cookie   |      (sequence number) |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | timestamp                           |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |           synchronization source (SSRC) identifier            |
>
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
> |            contributing source (CSRC) identifiers             |
>
> | ....                              |
>
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
> |            RFC5285 header extension ...                      |
>
> |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |
>
> | ....                              |
>
>   DTLS Header 13 bytes
>
>   SCTP
>
> The RFC5285 header extension is not in a fixed position in any of 
> these cases, but still trivial to find (especially when in  a TURN 
> flow). This could be introduced in 
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5
>
> by making room for these bytes after the UDP header, but before the 
> DTLS header.
>
> What do you think?
>


No.

We've chosen to make Data Channel a protocol within DTLS, and not use 
any unencrypted headers for it. Neither does the data channel have any 
concept resembling SSRC, CSRC or timestamp. Changing to an RTP-based 
format such as the one you propose would be a drastic revision of the spec.

There's no reason to believe such a revision at this time has any 
traction in the WG.