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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Wed, 26 February 2014 20:31 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C561A0111 for <mmusic@ietfa.amsl.com>; Wed, 26 Feb 2014 12:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db-sZ96zVLWa for <mmusic@ietfa.amsl.com>; Wed, 26 Feb 2014 12:31:45 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0016E1A00D7 for <mmusic@ietf.org>; Wed, 26 Feb 2014 12:31:44 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1QKVeAe028885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 14:31:40 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1QKVbWk028526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 15:31:39 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 15:31:39 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Richard Ejzak <richard.ejzak@gmail.com>
Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel
Thread-Index: Ac8y9K3pwn95tj5YT7SqspOdgSm1jf///isA///d/LCAADx9gP//qDPA//9J3TA=
Date: Wed, 26 Feb 2014 20:31:38 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFFB63C@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1BC4D7@ESESSMB209.ericsson.se> <CAJuyhsyQ6i9jj+T=x=fSJnEAAqjHoTa98X5X-Boyk+EZGbFycw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1BC7FC@ESESSMB209.ericsson.se> <CAJuyhswb4WZKHk-2FkC5YVP0pBuP4Zs4XozAXi7c50vrXk-uzw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BCD0C@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFFB63CUS70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xi3zxegadyKWCVwojGnYBBJf4iI
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external closing of channel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 20:31:49 -0000

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

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