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

[Paul Kyzivat <[e-mail]>]

Christer,

inline

On 2/15/14 9: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       |
>     +----------------+----------------+------------------------+----------------+
>     | "application"  |   DTLS port    | "UDP/TLS/UDPTL"        |   SCTP port    |
>     |                |     value      |                        |     value      |
>     +----------------+----------------+------------------------+----------------+
>
>                       Table 1: SDP "proto" field values

Note: AFAIK it doesn't matter what value is used for SCTP port number.
(Or does rtcweb require a particular value?)

*In principle* there should be no reason why there couldn't be more than 
one SCTP Port Value, though only one would be used for CLUE. IMO we 
should follow rtcweb on this.

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

I don't think we should specify "1" be used for stream. That means that 
the CLUE stream would be the *only* stream - preventing use of the 
association for anything else.

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

The m-line isn't solely for a CLUE data channel. I see no reason to 
forbid more than one SCTP m-line. All we need to do is specify which one 
is used for the CLUE channel if there is more than one. Again I think we 
can follow rtcweb on this. (I don't know if it forbids more than one.)

>     NOTE: CLUE does not support the usage of multiple CLUE data channels.

Agreed. But we didn't get to the part that actually specifies the clue 
channel.

>     The offerer MUST NOT insert more than one SDP sctpmap attributes in
>     an "m=" line for a CLUE data channel.

Same comment as above. If there were multiple SCTP ports then there 
would be multiple sctmap attributes.

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

The mechanics specified here are ok, but the reason for them is not.

While this would *work*, by preventing the association that is needed 
for the clue channel, it is too extreme to require as the only way to 
indicate lack of desire for CLUE. (Might just want to use the SCTP for 
something else.)

	Thanks,
	Paul

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