Re: [MMUSIC] New draft version: draft-ietf-mmusic-msrp-usage-data-channel-01

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

Hello Christian,

Regarding your comment and question to section 5.1.5:

> 5.1.5: This section indicates that closing is done as per I-D.ietf-mmusic-data-channel-sdpneg. 
> However clause 5.2.4/I-D.ietf-mmusic-data-channel-sdpneg indicates that closure is sub-protocol 
> specific. Its not clear to me whether this the sub-protocol should indicate the use of the SCTP 
> reset or the use of SDP O/A?
>
> [Juergen] The intention in 5.1.5 is to refer to the generic data channel closure procedure based on
> the SCTP stream reset mechanism, and that additionally per new SDP offer / answer exchange
> the a=dcmap and a=dcsa attribute lines associated with the MSRP session need to be removed
> from the DTLS/SCTP based media description.
> Would you agree if we explicitly said:
> “The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
> removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
> the associated DTLS/SCTP based media description.
> This results in the associated data channel being closed as well as per 
> [I-D.ietf-mmusic-data-channel-sdpneg].”
>
> [CNG] This wording is better. Is the SCTP reset at the same time as the SDP Offer? 

[Juergen] Actually, current text in section 5.2.4 of draft-ietf-mmusic-data-channel-sdpneg-01 
recommends (using SHOULD)
closing the data channel "after a successful SDP answer is sent/received".
In the MSRP case we would propose not to change this default behavior, which would result in the SDP 
answerer triggering
the reset procedure of its associated outgoing SCTP stream right after having accepted the received 
SDP offer with the data channel's
a=dcmap and a=dcsa attribute lines being removed, and close to the point in time it sends its SDP 
answer back to the SDP offerer.
I would assume that typically the SDP offerer would then see an outgoing SCTP stream reset request 
on its associated
incoming SCTP stream  before it receives the SDP answer.
Thus we could add this information and say:

“The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
the associated DTLS/SCTP based media description.
This results in the associated data channel being closed as well as per 
[I-D.ietf-mmusic-data-channel-sdpneg],
where the actual data channel closure procedure is typically initiated by the SDP answerer right 
after having
accepted the SDP offer.”

Thanks again,
Juergen


On 12.03.2015 03:19, Christian Groves wrote:
> Hello Juergen,
>
> No problem, please see my responses below.
>
> Regards, Christian
>
> On 12/03/2015 2:41 AM, Juergen Stoetzer-Bradler wrote:
>> Hello Christian,
>>
>> Thanks much for your comments.
>> Please see my remarks inserted below.
>>
>> Thanks,
>> Juergen
>>
>> On 10.03.2015 04:25, Christian Groves wrote:
>>> Hello Juergen,
>>>
>>> Thanks for the update. Some comments:
>>> 5.1.1.1 - The section indicates that the max-retr, max-time and
>>>    ordered parameters shall not be used. I take it then that the SCTP Stream used for MSRP must 
>>> be DATA_CHANNEL_RELIABLE? If so it might be better to say what is used rather than what is not.
>>
>> [Juergen] Agree. Would propose to replaced current sentence "The max-retr, max-time and ordered 
>> parameters shall not be used" with
>> "Ordered and reliable data channels MUST always be used, such that the 'max-retr' and 'max-time' 
>> parameters SHALL NOT be used.
>> If the 'ordered' parameter is used, then its value MUST be equal to 'true'."
> [CNG] OK
>>
>> ..snip..
>>
>>>
>>> 5.1.1.2: MSRP "max-size" would it be worth to note that this must be less than the SCTP SDP 
>>> max-message-size value?
>>
>> [Juergen] That's a good point. As far as I understand the a=max-message-size value
>> is related to the “maximum message size that an SCTP endpoint is willing to receive”
>> as per draft-ietf-mmusic-sctp-sdp-14, sec 6.1, whereas the MSRP specific a=max-size attribute
>> refers to the maximum MSRP message size an endpoint is willing to accept (as per 4975, sec 8.6),
>> thus is not related to the maximum MSRP message chunk size.
>> Would you be OK if we added a sentence to 5.1.1.2 saying that an MSRP session endpoint
>> MUST NOT send MSRP message chunks larger than  the peer’s a=max-message-size value?
> [CNG] Yes.
>>
>>>
>>> 5.1.1.2: "Setup" is this relevant for MSRP using data channel? The SCTP-SDP draft etc. give 
>>> rules as to which endpoint establishes different parts of the transport connection?
>>
>> [Juergen] Good point, too. The msrp-usage draft requires MSRP UAs using data channel transport
>> to support the MSRP CEMA extension as described in RFC 6714. This again refers to RFC 6135,
>> which uses the a=setup attribute value to determine the "active" MSRP UA, which is responsible 
>> for sending
>> the initial MSRP SEND message (which might be empty).
>> Also msrp-usage draft's section 5.1.2 currently requests the "active" MSRP endpoint to send an
>> MSRP SEND message as as soon as the associated data channel instance is opened.
>> Per draft-ietf-mmusic-sctp-sdp-14 the "a=setup" attribute contained in the DTLS/SCTP based media 
>> description
>> is used to determine the TCP (if used) and DTLS client/server roles. But this usage of the 
>> "a=setup" attribute
>> is different than the usage of "a=setup" as described in RFC 6135's section 4.2.
>> I assume we may have to describe more explicitly in msrp-usage how it is determined if an MSRP 
>> endpoint
>> becomes "active" (and sends the initial MSRP SEND message).
> [CNG] Yes I think its important to cover the this aspect.
>>
>>>
>>> 5.1.1.3: a=sctp-port 5000 should have a colon e.g. a=sctp-port:5000
>>
>> [Juergen] Thanks. We'll correct this.
>>
>>>
>>> 5.1.5: This section indicates that closing is done as per I-D.ietf-mmusic-data-channel-sdpneg. 
>>> However clause 5.2.4/I-D.ietf-mmusic-data-channel-sdpneg indicates that closure is sub-protocol 
>>> specific. Its not clear to me whether this the sub-protocol should indicate the use of the SCTP 
>>> reset or the use of SDP O/A?
>>
>> [Juergen] The intention in 5.1.5 is to refer to the generic data channel closure procedure based on
>> the SCTP stream reset mechanism, and that additionally per new SDP offer / answer exchange
>> the a=dcmap and a=dcsa attribute lines associated with the MSRP session need to be removed
>> from the DTLS/SCTP based media description.
>> Would you agree if we explicitly said:
>> “The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
>> removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
>> the associated DTLS/SCTP based media description.
>> This results in the associated data channel being closed as well as per 
>> [I-D.ietf-mmusic-data-channel-sdpneg].”
> [CNG] This wording is better. Is the SCTP reset at the same time as the SDP Offer?
>>
>>>
>>> Regards, Christian
>>>
>>>
>>
>> [snip]
>>