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

[Paul Kyzivat <[e-mail]>]

Inline

On 2/16/14 7:56 PM, Christian Groves wrote:
> Hello Christer,
>
> I think that for the signaling we must specify a way of negotiating at
> the SDP level

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

Yes. That is one way.

Another way is to signal CLUE support in SIP (e.g., feature tag), and 
then open the actual channel dynamically using the rtcweb data channel 
protocol.

	Thanks,
	Paul

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