Subject: [MMUSIC] draft-ietf-mmusic-data-channel-sdpneg - Description of SCTP Stream Id and of Data Channel Reliability Negotiation

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 2 Mar 2015 14:31:49 +0100

Hello,

In draft-ietf-mmusic-data-channel-sdpneg-00 section 5.1 is dedicated to the SDP syntax
of the two new attributes "a=dcmap" and "a=dcsa".
Section 5.2 then describes procedural aspects related to these two new attributes.
However, current Section 5.1.1 already contains some text regarding data channel reliability
negotiation, which we think should rather be moved to section 5.2, as this is not
related to SDP syntax aspects but rather to related SDP offer/answer procedures.

We would suggest to move the reliability negotiation related text to an own new sub-section of 5.2
as proposed below (new section 5.2.2 "Negotiating WebRTC Data Channel Parameters").

Also, in section 5.1.1's first paragraph the "a=dcmap" attribute parameters are informally
introduced before they are formally defined with ABNF rules in sub-section 5.1.1.1.
Except for parameter 'dcmap-stream-id' all parameters are then individually
described in further sub-sections starting from 5.1.1.2.

We would propose to create an own new sub-section of 5.1.1 explicitly dedicated
to the 'dcmap-stream-id' parameter (new section 5.1.1.2 "dcmap-stream-id Parameter").

With this information removed the updated section 5.1.1 could read as follows.

What do think of these potential updates?

Thanks,
Juergen

*Proposed shortened section 5.1.1:*

*5.1.1.  SDP Attribute for WebRTC Data Channel Parameter Negotiation*
    Associated with the SDP "m" line that defines the SCTP association
    for WebRTC data channels (defined in Section 4), each SDP offer and
    answer includes one "a=dcmap:" attribute that defines the WebRTC data
    channel parameters for each WebRTC data channel to be negotiated.
    Each such attribute line specifies the following parameters for a
    WebRTC data channel: SCTP stream identifier, sub-protocol, label,
    reliability, order of delivery, and priority.

    The intention of exchanging these attributes is to create WebRTC data
    channels on both the peers with the same set of attributes without
    actually using [I-D.ietf-rtcweb-data-protocol].  It is assumed that
    the WebRTC data channel properties (reliable/partially reliable,
    ordered/unordered) are suitable per the sub-protocol transport
    requirements.

*Proposed new section 5.1.1.2:*
/(Next section would then be 5.1.1.3 "label Parameter".)/

*5.1.1.2.  dcmap-stream-id Parameter*
The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
within the SCTP association used to form the WebRTC data channel.

*Proposed new section **5.2.2:*
/(Except for the first sentence this text is identical to the reliability related text //
//which currently is contained in -00's section 5.1.1.)//
/
*5.2.2.  Negotiating WebRTC Data Channel Parameters*
    Conveying a reliable WebRTC data channel is achieved by including
    neither 'max-retr' nor 'max-time' in corresponding SDP offer's or
    answer's a=dcmap attribute line.  Conveying a partially reliable
    WebRTC data channel is achieved by including only one of 'max-retr'
    or 'max-time'.  By definition max-retr and max-time are mutually
    exclusive, so only one of them can be present in a=dcmap.  If an SDP
    offer contains both of these parameters then such an SDP offer will
    be rejected.  If an SDP answer contains both of these parameters then
    the offerer may treat it as an error and may assume the associated
    SDP offer/answer failed and may take appropriate recovery actions.
    These recovery options are outside the scope of this specification.

    The SDP answer shall echo the same subprotocol, max-retr, max-time,
    ordered parameters, if those were present in the offer, and may
    include a label parameter.  They may appear in any order, which could
    be different from the SDP offer, in the SDP answer.

    The same information MUST be replicated without changes in any
    subsequent offer or answer, as long as the WebRTC data channel is
    still opened at the time of offer or answer generation.

    WebRTC data channel types defined in [I-D.ietf-rtcweb-data-protocol]
    are mapped to SDP in the following manner:

    DATA_CHANNEL_RELIABLE
          a=dcmap:2 subprotocol="BFCP";label="channel 2"

    DATA_CHANNEL_RELIABLE_UNORDERED
          a=dcmap:2 subprotocol="BFCP";label="channel 2";\
                    ordered=0

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
          a=dcmap:2 subprotocol="BFCP";label="channel 2";\
                    max-retr=3

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
          a=dcmap:2 subprotocol="BFCP";label="channel 2";\
                    max-retr=3;ordered=0;

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
          a=dcmap:2 subprotocol="BFCP";label="channel 2";\
                    max-time=10000;

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
          a=dcmap:2 subprotocol="BFCP";label="channel 2";\
                    max-time=10000; ordered=0