Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel

Sorry, hit the send button by accident.  Comments inline.

From: Makaraju, Maridi Raju (Raju)
Sent: Wednesday, February 26, 2014 2:32 PM
To: Christer Holmberg; Richard Ejzak
Cc: mmusic@ietf.org
Subject: RE: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel

Hi,
Comments inline.

Hi,
 You also need to be more clear on whether sending of SSN reset is mandatory when using your draft (you only say that "browsers will send it").

The text should refer to protocol stack behavior rather than to the browser since it's supposed to also apply to data channel usage outside the context of WebRTC.  (We intended to fix all th browser references in this draft and missed this one.)  So, yes, SSN reset is mandatory.

Then you also need to cover that in the procedures.

For example, when an entity receives an Offer removing a channel, it MUST send a SSN reset.
[Raju] Sure, we will make that clear. Thanks. As I already commented on other thread, the section "4.3.2 Closing data channel" needs more description.

Also, what to do if an entity receives an SSN reset, but not an associated Offer.
[Raju] Also as noted in other email thread, SDP offerer who wants to close a data channel should close the data channel ONLY when successful SDP answer is received. The above mentioned SSN reset case happens when SDP answerer starts closing channel right after sending SDP answer. SDP offer side data channel stack needs to handle such a case anyway (we will have this scenario with inband DCP too) and informs the application via onClose() or equivalent API. Then at SDP answer, offerer do not have to explictly close the data channel. Lastly, SSN reset
[Raju] If SSN reset is received on a side which did not having a pending SDP answer (to remove the stream) or the stream was not closed earlier via SDP offer/answer then a new SDP offer has to be generated to remove the stream via external negotiation. Otherwise no new SDP offer is needed as the stream is being removed or was removed already.
We will add this text to section 4.3.2.

Thanks
Raju

Thanks
Raju

These kind of error situations often cause troubles at interop testings, so let's try to cover them from the beginning :)

Regards,

Christer

From: Richard Ejzak [mailto:richard.ejzak@gmail.com<mailto:richard.ejzak@gmail.com>]
Sent: 26. helmikuuta 2014 16:08
To: Christer Holmberg
Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel

Hi Christer,
Another good catch.  Although it is implied that closed data channels are removed from subsequent offers, this should be stated explicitly.

BR, RIchard

On Wed, Feb 26, 2014 at 7:19 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

Section 5.2.3 says:

"It is specific to the sub-protocol whether this closing must in
                addition be signaled to the peer via a new SDP offer/answer exchange."

Shouldn't the draft define how it is done using an SDP offer/answer exchange?

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic