Re: DataChannels API

On 09/11/2012 03:47 PM, Ejzak, Richard P (Richard) wrote:
> The SDP only solution (2a) would easily support the use of additional
> offer/answer exchanges to add/delete data channels from an existing
> SCTP association.  The first offer/answer exchange that includes any
> data channels would cause creation of the SCTP association and
> subsequent offer/answer exchanges would allow any reconfiguration of
> those data channels to be executed.  Such reconfiguration requires no
> SCTP traffic until one of the changed data channels is actually used,
> so the cost on the wire to make changes is actually lower with this
> approach when two or more data channels are changed at a time.  And
> this approach always has a lower cost on the wire to set up the
> initial set of data channels.
>
> This approach requires a little bit more work for the JS app since
> data channel changes won't be executed until the next offer/answer
> exchange.  But this just makes management of data channels more
> consistent with the way in which audio and video tracks are managed,
> which I consider to be an advantage.

Personally I am torn on which approach is better. If you had asked me 
before Vancouver I would have said add/remove channels to/from an 
existing SCTP association should be done using some in-band signaling 
(e.g. an SCTP channel reserved for this purpose). My reason would be to 
avoid time and resource consuming SDP o/a exchanges (that would block 
other changes to the session until done).

But in Vancouver SDP o/a was adopted as the way to signal changes in 
video resolution (to signal if the displaying client starts showing the 
video in a larger or smaller sized window) instead of using signaling 
based on RTCP. And if we think that SDP o/a is agile enough for that 
purpose, I don't think we could say "it is not suitable for 
adding/removing SCTP channels".

As Christer pointed out, this will lead to a much more frequent SDP o/a 
than what is traditional, but I don't know if that is a problem or not.

(I see that Randell just made some input on this subject as well.)

Stefan

>
> Richard
>
>> -----Original Message----- From: Adam Bergkvist
>> [mailto:adam.bergkvist@ericsson.com] Sent: Tuesday, September 11,
>> 2012 6:22 AM To: Ejzak, Richard P (Richard) Cc:
>> public-webrtc@w3.org Subject: Re: DataChannels API
>>
>> On 2012-09-08 00:26, Ejzak, Richard P (Richard) wrote:
>>> Among the options for DataChannel API, I prefer 2a.
>>>
>>> There is almost no cost to establishing and maintaining as many
>>> DataChannels as might be needed in advance using SDP, whereas
>>> there is extra signaling and delay to establish one on the fly.
>>> It would also be useful to verify all at once that the needed set
>>> of DataChannels can be established by the application.
>>>
>>> The tradeoff is between implementing the control protocol versus
>>> implementing the SDP extensions.  I think the SDP extensions are
>>> more efficient and generally more useful so would prefer that we
>>> start with them and only add the control protocol later if
>>> necessary.
>>>
>>
>> A clarifying question: are you voting for a solution where data
>> channels only can be set up when the SCTP association is created?
>> Or would it be OK to add more channels later (with an extra SDP
>> exchange)?
>>
>> I would say that our API is optimized for creating new channels on
>> the fly.
>>
>> /Adam
>>
>>> This approach would also make it easier to signal in advance the
>>> desire to use a DataChannel for other protocols, such as MSRP,
>>> BFCP, T.140 or perhaps any new telepresence control protocols to
>>> be defined in CLUE.  We don't yet have RFC's describing how to
>>> use DataChannel transport with these protocols, but that should
>>> be pretty straightforward.  We need a clean extensibility
>>> mechanism to support these other non-audio/non-video protocols.
>>>
>>> Using a DataChannel for T.140, for example, should not change
>>> the basic API for data transfer between the JS and the browser.
>>> All that is needed is to be able to signal use of t140 on a
>>> DataChannel in the SDP, and to specify the ProtocolID for use in
>>> SCTP (the browser should not need to know anything about t140 to
>>> do this).  These could even potentially be signaled to the
>>> browser during set local via the SDP without impacting the API
>>> itself, although it would be cleaner to pass the protocol name
>>> and ProtocolID to the browser when creating the DataChannel.
>>>
>>> Richard
>>>
>>>
>
>

Received on Tuesday, 11 September 2012 14:08:30 UTC