Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

[Paul Kyzivat <[e-mail]>]

On 2/19/14 7:37 PM, Christian Groves wrote:

>>>> The webrtc data channel open protocol does not take a stream ID as an
>>>> argument. It internally assigns stream IDs. Rtcweb has specified how
>>>> you can use preassigned channels without the open, but then it isn't
>>>> using the data channel protocol.
>>> [CNG] I just threw something together here without much thought. So for
>>> the case where the streamID isn't specified "data channel protocol"
>>> could be the value to indicate that it is used?
>>
>> That still requires declaring every channel in SDP doesn't it?
>> (Maybe that is your goal. But it is a non-goal for webrtc.)
> [CNG] Is it a non-goal for webrtc? Isn't
> draft-ejzak-mmusic-data-channel-sdpneg declaring channels?

The ejzak draft isn't really a mainstream rtcweb-sponsored draft.
Richard and I and some other people had a discussion about the concepts 
in this once. (I forget which meeting.) I think the draft came from that.

The main rtcweb people don't want to declare channels in SDP.
We have just managed to get to a point where they can tolerate it as an 
option.

>> My thinking is that the sctpmap attribute identifies the a discipline
>> (convention) used to assign meaning to streams. Then the specification
>> of that discipline provides the details of how streams are assigned/used.
> [CNG] I understand this but there seems to be a LOT of overlap between
> the SCTP SDP and the Ejzak SDP. The goal of both is out-of-band
> negotiation of what is running on the STCP streams.

There is overlap because Richard is trying to improve on what the 
sctp-sdp draft proposes.

But the sctp-sdp draft only intends to define the association itself, 
and some attributes of it, such as the max number of streams. It does 
nothing on a per-channel basis.

>> Then, when the discipline is webrtc-datachannel (preferably changed to
>> a better name) draft-ietf-rtcweb-data-channel spells that out. So it
>> defines how streams are grouped into channels, and defines both
>> external and internal negotiation. It *ought* to reference (or be
>> merged with) the Ejzak draft for external negotiation.
> [CNG] Yes it certainly could do with being merged.
>>
>>>> IMO, from an mmusic perspective, we need to support both the static
>>>> and dynamic assignment of channels. We just want it to be done more
>>>> clearly.
>>> [CNG] Perhaps this is key, for a particular app in a SCTP association we
>>> need to say whether or not the streamID assignment is static or dynamic
>>> via the data channel protocol".
>>
>> Again, for interop with rtcweb we are stuck with "webrtc-datachannel"
>> as the "app".
> [CNG] I don't think that's a problem so long as its declared that it
> will be used.
>>
>>>> From a CLUE perspective, we need to decide if we want to use the
>>>> static or dynamic assignment. IMO the preferred choice is not obvious
>>>> - both have their attractions. At the moment I am *slightly*
>>>> preferring the dynamic.
>>> [CNG] Dynamic is probably OK so long as we have some sort of label
>>> mechanism to help sort out mapping when you have multiple instances of
>>> the same app.
>>
>> I think we would just specify an explicit "label" that CLUE uses to
>> identify its channel.
> [CNG] Is that an "app" label? :-).

No. It is an arbitrary label. For channels opened with the channel 
protocol it shows up in the API.

> I don't think the problem is unique
> to CLUE so I think what ever is used here should be generic mechanism
> for indicating labels.

That is what it is in JSEP.

	Thanks,
	Paul

>>     Thanks,
>>     Paul
>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>>>
>>>>>> But, never the less, it would probably be good to have an example
>>>>>> showing how things would look like using Richard's draft, until we've
>>>>>> decided whether we are going to use it or not. I'll add that.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>> Sent from my Sony Ericsson Xperia arc S
>>>>>>
>>>>>> Christian Groves <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>> Hello Christer,
>>>>>>
>>>>>> I think that for the signaling we must specify a way of
>>>>>> negotiating at
>>>>>> the SDP level whether CLUE is supported. I agree there's lots of
>>>>>> ways it
>>>>>> could be done but we need to indicate which one/s CLUE should use.
>>>>>>
>>>>>> So for the SDP O/A procedures and example I think you have to assume
>>>>>> the
>>>>>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say
>>>>>> its a CLUE data channel according to the SDP given. You're just
>>>>>> opening
>>>>>> a generic channel, which may or may not be clue. Particularly in the
>>>>>> Answerer's case, it doesn't know that the Offer is going to use the
>>>>>> channel for CLUE.
>>>>>>
>>>>>> However:
>>>>>> m=application 54111 SCTP/DTLS 54111
>>>>>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1
>>>>>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3
>>>>>>
>>>>>> would unambiguously define it as a CLUE data channel.
>>>>>>
>>>>>> Regards, Christian
>>>>>>
>>>>>> On 17/02/2014 11:16 AM, Christer Holmberg wrote:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> If you want to negotiate usage of CLUE (or, any other specific usage
>>>>>>> of a webrtc-datachannel) in SDP, one option is to use Richard's
>>>>>>> draft. The usage of that draft is listed as an open issue in the
>>>>>>> CLUE
>>>>>>> data channel draft.
>>>>>>>
>>>>>>> SIP also provides other mechanisms, e.g. media feature tags, for
>>>>>>> indicating support of features.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer
>>>>>>>
>>>>>>> Sent from my Sony Ericsson Xperia arc S
>>>>>>>
>>>>>>> Christian Groves <[e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hello Christer,
>>>>>>>
>>>>>>> With the use of webrtc-datachannel how do I negotiate via SDP
>>>>>>> whether I
>>>>>>> want to use clue or not?
>>>>>>>
>>>>>>> A SCTP association (and thus webrtc-datachannel) for example
>>>>>>> could be
>>>>>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP
>>>>>>> association to figure out that the endpoints support
>>>>>>> webrtc-datachannel
>>>>>>> put don't support the application that you want.
>>>>>>>
>>>>>>> In the example in section 4.6 there's no way of distinguishing that
>>>>>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data
>>>>>>> channel is a generic data channel.
>>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> The draft submission deadline has passed, but I still wrote some
>>>>>>>> more text, shown below, for the SDP Offer/Answer Procedures
>>>>>>>> section.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Christer
>>>>>>>>
>>>>>>>> PS. Note that I will be on vacation next week, so I will once again
>>>>>>>> do my best trying to stay away from e-mails :)
>>>>>>>>
>>>>>>>> -----------------------
>>>>>>>>
>>>>>>>> 4.  SDP Offer/Answer Procedures
>>>>>>>>
>>>>>>>> 4.1.  General
>>>>>>>>
>>>>>>>>       This section describes how the SDP media description ("m=")
>>>>>>>> line for
>>>>>>>>       a CLUE data channel is created, and how it is used in SDP
>>>>>>>> offers and
>>>>>>>>       answers.
>>>>>>>>
>>>>>>>>       NOTE: The proceudres associated with "m=" lines for other
>>>>>>>> media types
>>>>>>>>       (e.g. audio and video) used in a CLUE session are outside the
>>>>>>>> scope
>>>>>>>>       of this document.
>>>>>>>>
>>>>>>>>       OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data
>>>>>>>> Channel
>>>>>>>>       Negotiation mechanism
>>>>>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]
>>>>>>>>       will be used with the CLUE data channel.
>>>>>>>>
>>>>>>>>       NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will
>>>>>>>> be used
>>>>>>>>       with the CLUE data channel, a new associated 'sub-protocol'
>>>>>>>> value
>>>>>>>>       needs to be registered with IANA.
>>>>>>>>
>>>>>>>> 4.2.  SDP Media Description Fields
>>>>>>>>
>>>>>>>>       The field values of the "m=" line for the CLUE data channel
>>>>>>>> are set
>>>>>>>>       as following:
>>>>>>>>
>>>>>>>>
>>>>>>>> +----------------+----------------+------------------------+----------------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       |     media      |      port         |
>>>>>>>> proto               |      fmt         |
>>>>>>>>
>>>>>>>> +----------------+----------------+------------------------+----------------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       | "applicationS |   DTLS port   | "UDP/TLS/UDPTL" |   SCTP
>>>>>>>> port   |
>>>>>>>>       |                    |     value
>>>>>>>> |                             |     value       |
>>>>>>>>
>>>>>>>> +----------------+----------------+------------------------+---------------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                         Table 1: SDP "proto" field values
>>>>>>>>
>>>>>>>> 4.3.  SDP sctpmap Attribute
>>>>>>>>
>>>>>>>>       The field values of the SDP sctpmap attribute associated
>>>>>>>> with the
>>>>>>>>       CLUE data channel "m=" are set as following:
>>>>>>>>
>>>>>>>>
>>>>>>>> +---------------------+---------------------------+-----------------------+---------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       | sctpmap-number |         app |
>>>>>>>> max-message-size | stream |
>>>>>>>>
>>>>>>>> +---------------------+---------------------------+-----------------------+---------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       |  fmt value of       | "webrtc-datachannel" |
>>>>>>>> Implemenation     |  "1"     |
>>>>>>>>       | the "m=" line | |
>>>>>>>> specific             |           |
>>>>>>>>
>>>>>>>> +---------------------+---------------------------+-----------------------+---------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                         Table 2: SDP "proto" field values
>>>>>>>>
>>>>>>>> 4.4.  SDP Offerer Procedures
>>>>>>>>
>>>>>>>>       The procedures for the offerer follow the normal proceures
>>>>>>>> defined in
>>>>>>>>       [ref-to-3264].
>>>>>>>>
>>>>>>>>       When the offerer creates an offer, which contains an "m="
>>>>>>>> line
>>>>>>>> for a
>>>>>>>>       CLUE data channel, it assigns the field values to the "m="
>>>>>>>> line
>>>>>>>>       according to the procedures in Section 4.2.  In addition, the
>>>>>>>> offerer
>>>>>>>>       MUST insert an SDP sctpmap attribute associated with the "m="
>>>>>>>> line.
>>>>>>>>
>>>>>>>>       In an offer, the offerer MUST NOT insert more than one "m="
>>>>>>>> line for
>>>>>>>>       a CLUE data channel.
>>>>>>>>
>>>>>>>>       NOTE: CLUE does not support the usage of multiple CLUE data
>>>>>>>> channels.
>>>>>>>>
>>>>>>>>       The offerer MUST NOT insert more than one SDP sctpmap
>>>>>>>> attributes in
>>>>>>>>       an "m=" line for a CLUE data channel.
>>>>>>>>
>>>>>>>>       If an offerer, in a subsequent offer, wants to disable the
>>>>>>>> CLUE data
>>>>>>>>       channel, it assigns a zero port value to the "m=" line
>>>>>>>> associated
>>>>>>>>       with the CLUE data channel.  The answerer MUST NOT insert an
>>>>>>>> SDP
>>>>>>>>       sctpmap attribute associated with the "m=" line.
>>>>>>>>
>>>>>>>> 4.5.  SDP Answerer Procedures
>>>>>>>>
>>>>>>>>       The procedures for the answerer follow the normal proceures
>>>>>>>> defined
>>>>>>>>       in [ref-to-3264].
>>>>>>>>
>>>>>>>>       If the answerer receives an offer, which contains an "m="
>>>>>>>> line
>>>>>>>> for a
>>>>>>>>       CLUE data channel, and the answerer accepts the "m=" line, it
>>>>>>>> creates
>>>>>>>>       and inserts an "m=" line in the associated answer. The
>>>>>>>> answerer
>>>>>>>>       assigns the field values to the "m=" line according to the
>>>>>>>> procedures
>>>>>>>>       in Section 4.2.
>>>>>>>>
>>>>>>>>       If, in the offer, a zero port value has been assigned to the
>>>>>>>> "m="
>>>>>>>>       line for the CLUE channel, or it the answerer does not
>>>>>>>> accept the
>>>>>>>>       "m=" line, but accepts other "m=" lines in the offer (i.e.
>>>>>>>> the
>>>>>>>>       answerer will not reject the whole offer), it still
>>>>>>>> inserts an
>>>>>>>> "m="
>>>>>>>>       line for a CLUE data channel in the associated answer.  The
>>>>>>>> answerer
>>>>>>>>       then assigns a zero port value to the "m=" line. The answerer
>>>>>>>> MUST
>>>>>>>>       NOT insert an SDP sctpmap attribute associated with the "m="
>>>>>>>> line.
>>>>>>>>
>>>>>>>> 4.6.  Example
>>>>>>>>
>>>>>>>>            m=application 54111 SCTP/DTLS 54111
>>>>>>>>            a=sctpmap:54111 webrtc-datachannel
>>>>>>>> max-message-size=100000 streams=1
>>>>>>>>
>>>>>>>>              Figure 1: SDP Media Description for a CLUE data
>>>>>>>> channel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> clue mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> clue mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>
>> _______________________________________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>