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

Why are we having this discussion on the RTCWEB mailing list rather than
the MMUSIC mailing list?   This document was dispatched to MMUSIC at
IETF-88: http://trac.tools.ietf.org/wg/dispatch/trac/wiki
And, the nifty datatracker tool tells us that this (expired) document has
been replaced by an individual draft that has been submitted to the MMUSIC
WG:
http://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/

It seems there's a lot of interest in this document, so if folks want it to
be considered for adoption in the MMUSIC WG, PLEASE move the discussion to
the MMUSIC WG list.  The chairs need the discussion there in order to get a
sense of WG interest, so you might want to include a link to this thread of
discussion in a NEW email to the MMUSIC WG mailing list and point this
discussion to that thread. But, please do not crosspost.

Thanks,
Mary.

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.
>
>
>
>
>
> *Q2:*
>
>
>
> Would it be possible, for subprotocol values, use the same IANA
> registry/values as for the WebRTC Data Channel Protocol?
>
>
>
>
>
> *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.
>
>
>
>
>
> *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.
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>