Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

[Randell Jesup <[e-mail]>]

On 3/11/2013 5:20 PM, MARCON, JEROME (JEROME) wrote:
>
> > Assuming that some day a spec defines the transport of T.140 (or 
> whatever similar protocol) over RTCWeb data channels
> > - with a registered subprotocol
> > - with multiple reliability options supported
> > - requiring some new data channel properties
> > - of which some are assymetric between the endpoints (like the 
> "characters per second" defined in [RFC4103].
> >
> > Then (in the current version of your proposal) it seems to me that
> > * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> > - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
> Why is it not extensible? We have a message type and you could simply
> define another message...
>
> [JM1]. Mmh, then the spec defining T.140 (or whatever) over data 
> channels (and willing to add a new property like "cps") would have to 
> define a new message type - and more less its own DATA_CHANNEL_OPEN 
> structure? That's a costly extensibility.

It you need to do a more complex negotiation, you have several choices.  
One would be:

Open a reliable data channel for negotiation (0 RTT) (flagged by label & 
protocol).  Over that channel, immediately send a message that sets up 
an offer for T.140 (take your pick on format. A JS app would likely use 
JSON), with a channel which was preset with the appropriate options ("I 
expect to receive data on this channel with these options").  The 
answerer can send back the response (on the negotiation channel), and 
also say "I expect data on this channel with these options").  At this 
point, the T.140 channel is open, and as soon as the response is 
received by the offerer, both sides know it.

If this sounds very much like "fast-path re-negotiation" for JSEP, it 
is.  Once you have DataChannels, you can leverage them to do a lot of 
things.  This sort of sequence is enabled by the ability added to allow 
external negotiation.  This is as fast as any other mechanism (and 
faster than any that goes via a signaling server) - 3 messages, 1 RTT 
total.  (Open, Offer -> Answer)

You can do this in SDP if you wish (and are willing to parse SDP, or 
whatever limited SDP  you need).  As mentioned, I normally would suggest 
JSON or something like that for JS Apps.)

You can also do external negotiation over whatever channel and method 
you like.

-- 
Randell Jesup
[e-mail]