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

[Christer Holmberg <[e-mail]>]

Hi,

I will read and comment on this at another moment, but to me it seems like this discussion belongs to the MMUSIC (and perhaps RTCWEB) list.

Regards,

Christer

________________________________________
From: clue [[e-mail]] on behalf of Christian Groves [[e-mail]]
Sent: Monday, 17 February 2014 7:07 AM
To: [e-mail]
Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

Hello Paul,

On 17/02/2014 3:09 PM, Paul Kyzivat wrote:
> On 2/16/14 8:35 PM, Christian Groves wrote:
>> Hello Christer,
>>
>> Please see below.
>>
>> Regards, Christian
>>
>> On 17/02/2014 12:11 PM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> If the offerer offers a data channel, AND also some way indicates
>>> support of CLUE, we can always specify that the offerer MUST be able
>>> to use the data channel for CLUE. The WebRTC data channel protocol can
>>> then be used to open the channel for CLUE.
>> [CNG] I agree.
>>
>> I'm still uncomfortable with the way these drafts are layered.
>
> I'm troubled too, but maybe not exactly the same way you are.
> IMO it isn't that the layering is so wrong. Rather it is that the
> terminology used is confusing.
[CNG] Yes the terminology isn't helping either.

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

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