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

[Christian Groves <[e-mail]>]

Hello Paul,

Please see below.

Regards, Christian

On 18/02/2014 8:24 AM, Paul Kyzivat wrote:
> 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.
[CNG] I agree, I'm just reusing the existing term. Different protocols 
will be signaled across different SCTP streams.

>
> "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.)
[CNG] I don't think we need to make any assumptions about the number of 
apps. A endpoint could have one or more SCTP associations. In those 
associations they could have 1 or more SCTP streams carrying one or more 
protocols.

>
> 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.
[CNG] I agree.

>
>>>> 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.)
[CNG] Is it a non-goal for webrtc? Isn't 
draft-ejzak-mmusic-data-channel-sdpneg declaring channels?

>
> 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.
>
> 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? :-). 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.
>
>     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
>