[MMUSIC] New draft version: draft-ietf-mmusic-data-channel-sdpneg-01

[Juergen Stoetzer-Bradler <[e-mail]>]

Hello,

Have submitted version -01 of draft-ietf-mmusic-data-channel-sdpneg.
The changes as compared to version -00 are listed below and are related to corresponding recent 
email list discussions.
This list is also copied to the change log section 10.1.

Thanks,
Juergen


    o  In Section 3 "WebRTC data channel" was defined as "A bidirectional
       channel consisting of paired SCTP outbound and inbound streams."
       Replacement of this definition with "Data channel: A WebRTC data
       channel as specified in [I-D.ietf-rtcweb-data-channel]", and
       consistent usage of "data channel" in the remainder of the
       document including the document's headline."

    o  In Section 4 removal of following note: 'OPEN ISSUE: The syntax in
       [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.
       In particular we expect "webrtc-datachannel" to become a more
       general term.'

    o  Consistent usage of '"m" line' in whole document as per [RFC4566].

    o  In Section 5.1.1 removal of the example dcmap attribute line
       'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are
       already four examples right after the ABNF rules in
       Section 5.1.1.1.  Corresponding removal of following related note:
       "Note: This document does not provide a complete specification of
       how to negotiate the use of a WebRTC data channel to transport
       BFCP.  Procedures specific to each sub-protocol such as BFCP will
       be documented elsewhere.  The use of BFCP is only an example of
       how the generic procedures described herein might apply to a
       specific sub-protocol."

    o  In Section 5.1.1 removal of following note: "Note: This attribute
       is derived from attribute "webrtc-DataChannel", which was defined
       in old version 03 of the following draft, but which was removed
       along with any support for SDP external negotiation in subsequent
       versions: [I-D.ietf-mmusic-sctp-sdp]."

    o  Insertion of following new sentence to the beginning of
       Section 5.1.1.1: "dcmap is a media level attribute having
       following ABNF syntax:"

    o  Insertion of new Section 5.1.1.2 containing the dcmap-stream-id
       specifying sentence, which previously was placed right before the
       formal ABNF rules.  Removal of the sentence 'Stream is a mandatory
       parameter and is noted directly after the "a=dcmap:" attribute's
       colon' as this information is part of the ABNF specification.

    o  In Section 5.1.1.1 modification of the 'ordering-value' values
       from "0" or "1" to "true" or "false".  Corresponding text
       modifications in Section 5.1.1.7.

    o  In Section 5.1.1.1 the ABNF definition of "quoted-string" referred
       to rule name "escaped-char", which was not defined.  Instead a
       rule with name "escaped" was defined.  Renamed that rule's name to
       "escaped-char".

    o  Insertion of a dedicated note right after the "a=dcmap:4"
       attribute example in Section 5.1.1.1 regarding the non-printable
       "escaped-char" character within the "label" value.

    o  In Section 5.1.2's second paragraph replacement of "sctp stream
       identifier" with "SCTP stream identifier".

    o  In first paragraph of Section 5.2.1 replacement of first two
       sentences 'For the SDP-based external negotiation described in
       this document, the initial offerer based "SCTP over DTLS" owns by
       convention the even stream identifiers whereas the initial
       answerer owns the odd stream identifiers.  This ownership is
       invariant for the whole lifetime of the signaling session, e.g. it
       does not change if the initial answerer sends a new offer to the
       initial offerer.' with 'If an SDP offer / answer exchange (could
       be the initial or a subsequent one) results in a UDP/DTLS/SCTP or
       TCP/DTLS/SCTP based media description being accepted, and if this
       SDP offer / answer exchange results in the establishment of a new
       SCTP association, then the SDP offerer owns the even SCTP stream
       ids of this new SCTP association and the answerer owns the odd
       SCTP stream identifiers.  If this "m" line is removed from the
       signaling session (its port number set to zero), and if usage of
       this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is
       renegotiated later on, then the even and odd SCTP stream
       identifier ownership is redetermined as well as described above.'

    o  In Section 5.2.3 the first action of an SDP answerer, when
       receiving an SDP offer, was described as "Applies the SDP offer.
       Note that the browser ignores data channel specific attributes in
       the SDP."  Replacement of these two sentences with "Parses and
       applies the SDP offer.  Note that the typical parser normally
       ignores unknown SDP attributes, which includes data channel
       related attributes."

    o  In Section 5.2.3 the second sentence of the third SDP answerer
       action was "Note that the browser is asked to create data channels
       with stream identifiers not "owned" by the agent.". Replacement
       of this sentence with "Note that the agent is asked to create data
       channels with SCTP stream identifiers contained in the SDP offer
       if the SDP offer is accepted."

    o  In Section 5.2.4 the third paragraph began with "A data channel
       can be closed by sending a new SDP offer which excludes the dcmap
       and dcsa attribute lines for the data channel.  The port value for
       the m line should not be changed (e.g., to zero) when closing a
       data channel (unless all data channels are being closed and the
       SCTP association is no longer needed), since this would close the
       SCTP association and impact all of the data channels.  If the
       answerer accepts the SDP offer then it MUST also exclude the
       corresponding attribute lines in the answer. ..." Replacement of
       this part with "The intention to close a data channel can be
       signaled by sending a new SDP offer which excludes the "a=dcmap:"
       and "a=dcsa:" attribute lines for the data channel.  The port
       value for the "m" line SHOULD not be changed (e.g., to zero) when
       closing a data channel (unless all data channels are being closed
       and the SCTP association is no longer needed), since this would
       close the SCTP association and impact all of the data channels.
       If the answerer accepts the SDP offer then it MUST close those
       data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were
       excluded from the received SDP offer, unless those data channels
       were already closed, and it MUST also exclude the corresponding
       attribute lines in the answer."

    o  In Section 5.2.4 the hanging text after the third paragraph was
       "This delayed close is to handle cases where a successful SDP
       answer is not received, in which case the state of session should
       be kept per the last successful SDP offer/answer." Replacement of
       this sentence with "This delayed closure is RECOMMENDED in order
       to handle cases where a successful SDP answer is not received, in
       which case the state of the session SHOULD be kept per the last
       successful SDP offer/answer."

    o  Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
       Section 5.1.1 contained already procedural descriptions related to
       data channel reliability negotiation.  Creation of new
       Section 5.2.2 and moval of reliability negotiation related text to
       this new section.