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

[Paul Kyzivat <[e-mail]>]

On 2/17/14 12:07 AM, Christian Groves wrote:
> Hello Paul,

[snip]

>>> The SCTP
>>> draft allows the specification of "app"s that relate to the SCTP
>>> association as a means of negotiating what goes in the SCTP association.
>>> One of those "app"s may be the webrtc data channel. It has its own means
>>> of negotiating of what is in the SCTP association (i.e. Richard's
>>> draft).
>>
>> I agree with your interpretation here. That doesn't mean the layering
>> is wrong - just the terminology.
>>
>> The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But
>> in reality its purpose is not at all analogous to a=rtpmap. So the
>> name confuses.
>>
>> And that mis-analogy is continued, by language that says sctpmap is
>> defining a mapping from a port number to a payload format. Again, that
>> is not what it is doing. (If it were, then you would be restricted to
>> one payload format for all the streams on the association.) AFAICT,
>> the name you are giving in sctpmap describes some sort of "convention"
>> for how all the streams in the association are to be managed and used.
>> E.g., "webrtc-datachannel" says that the streams will be managed in
>> pairs, as channels, and that webrtc data channel protocol may be used
>> to dynamically assign channels. (That is the same conclusion you have
>> reached.)
>>
>> IMO a lot of the language should be changed to be less confusing.
>>
>>> Both these methods are basically just indicating what will be in
>>> the SCTP streams.
>>
>> Both? Which? The only thing that actually says, in SDP, what will be
>> in the individual SCTP streams is Richard's draft.
> [CNG] The SCTP draft does say which "apps" will be in the association.
> That what I mean by "what's in the streams" in the general sense.

"apps" is a cop out - it is a meaningless term.

"Loosely" I am inclined to think there is only one "app" at each end of 
the association, or maybe just one distributed app at both ends of the 
association. I find it hard to consider "webrtc-datachannel" an 
"application". It is just another layer in a stack. What we are more 
likely to recognize as the "application" is above that. (We are working 
our way up, from layer 7. But I've lost count.)

But then there is some piece of application behavior associated with 
each channel. *That* is where it gets clue-specific.

This is one of the things that deserves better terminology.

>>> Rather than have two methods for negotiating what is
>>> in the SCTP association it almost seems better to have one method for
>>> negotiation of what apps there are and then to tag whether or not the
>>> webrtc data channel will be used to open it.
>>>
>>> e.g.
>>>
>>> m=application 54111 SCTP/DTLS 54111
>>> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3;
>>> webrtc-datachannel-tag
>>> a=webrtc-datachannel:max-message-size=100000 streams=1
>>>
>>> webrtc-datachannel-tag would take whether an "app" uses the webrtc data
>>> channel open protocol.
>>> a=webrtc-datachannel attribute would give the attributes of the
>>> protocol.
>>
>> There are problems with this - not for CLUE, but for webrtc, or
>> anything that doesn't want to use O/A to define every channel.
>>
>> 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.)

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.

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.

>> 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".

>> 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.

	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
>