Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

On Mon, Feb 24, 2014 at 7:18 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> A few questions on  draft-ejzak-dispatch-webrtc-data-channel-sdpneg:
>
>
>
> *Q1:*
>
>
>
> Instead of defining a new SDP webrtc-DataChannel attribute, would it be
> possible to define the parameters as extension parameters to the SDP
> sctpmap attribute (yes, I know the ABNF currently does not allow that)?
>
>
>
> Example:
>
>
>
> *a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"*
>
>
>
> I am not saying this would be good or bad - at this point I just want to
> understand whether it would work.
>

It might work, but you would still need a different mechanism to negotiate
multiple data channels.  Why bother with two different formats when one
will do?

>
>
>
>
> *Q2:*
>
>
>
> Would it be possible, for subprotocol values, use the same IANA
> registry/values as for the WebRTC Data Channel Protocol?
>

This is really more a question for the data channel design itself.  A
decision has been made to use the PPID for framing rather than protocol
identification.  There is some discussion of this in another thread.

>
>
>
>
> *Q3:*
>
>
>
> It would be good to clarify, if only one data channel is requested (or,
> even required), that the stream value must be the same in the Offer and
> Answer.
>

I thought this also came up in an earlier thread and that it is documented
(or should be documented) in the core data channel docs.  My understanding
is that the stream id is always the same in both directions for a
particular data channel.

>
>
>
> *Q4:*
>
>
>
> I have issues with the max_retr, max_time and unordered parameters.
>
>
>
> First, they seem to specify SENDING capabilities, rather than RECEIVING
> capabilities.
>
>
>
> Second, they seem to describe characteristics associated with the
> subprotocol, in which case they could be specified in the associated
> subprotocol specification.
>

This should be a topic for discussion in London.  As it is currently
written, these parameters are of the "take it or leave it" variety, i.e.,
the answerer either accepts the options listed in the offer or rejects the
data channel outright.  This is true for the in-band control protocol
(please correct me if I am wrong on this), so we adopted the same approach
for the SDP-negotiated case.  Some have suggested that we should allow more
flexibility in negotiation of these parameters when using SDP.  If there is
general agreement that it should be done this way, I see no problem with
defining parameter negotiation rules for SDP in the next version of the
draft.

BR, Richard

>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>