Re: [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association

Richard Ejzak <richard.ejzak@gmail.com> Tue, 18 February 2014 14:11 UTC

Return-Path: <richard.ejzak@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20591A0673; Tue, 18 Feb 2014 06:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZBU0wCsk5ZU7; Tue, 18 Feb 2014 06:11:22 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 396721A0491; Tue, 18 Feb 2014 06:11:22 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id q8so12298300lbi.14 for <multiple recipients>; Tue, 18 Feb 2014 06:11:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+iRDEqmjrAdkGMw2OqGEqPq+ve2QuSJBbmQGHGJxiyI=; b=cS8/mWvwMmtBn5aWqhitlxdanjG1LsmbuMYZbQ51YTwkdt/lbd5hy216/QZCM+ttJY LH3uVOlsIEu2qcrMUihX4b5wDjaS6AMqPPaCElOteVi/38wzHRQN8x9DhYGpXlB9V7Dh qq3NziP16FDhQ2AecE74x0C8wUjoZeVQc0eqEhehmHqZ/PL6iN1fQ1ttXbcGuEUrCL5h oMfX0TLRR0zAHytnPS90dG7+yrrUzGu8cGiGYDsDdKv5USgqDnfrAdScXFCqwZZKWdeF YK1bPLU+Ob/3EltgYR3yw/utb7DJiHXhiLcR1w4gAWBihIWvTmjLgiVsNZ8wmB2LTWv2 ZwDQ==
MIME-Version: 1.0
X-Received: by 10.152.1.3 with SMTP id 3mr1632700lai.58.1392732678668; Tue, 18 Feb 2014 06:11:18 -0800 (PST)
Received: by 10.112.98.162 with HTTP; Tue, 18 Feb 2014 06:11:18 -0800 (PST)
In-Reply-To: <E97C33E5D67C2843AFA535DE2E5B80C157392931@SZXEMA503-MBX.china.huawei.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> <E97C33E5D67C2843AFA535DE2E5B80C157392931@SZXEMA503-MBX.china.huawei.com>
Date: Tue, 18 Feb 2014 08:11:18 -0600
Message-ID: <CAJuyhsyt9yUmC7oAXFi9KWLSaNc8dQ9GwmERuLy7kqBfKrAmWg@mail.gmail.com>
From: Richard Ejzak <richard.ejzak@gmail.com>
To: "Liuyan (Scarlett)" <scarlett.liuyan@huawei.com>
Content-Type: multipart/alternative; boundary=089e013c6ae494471104f2aed8b7
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PH7AliJ0tGgSGKO2PrkerfQnLXI
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt - the data channel's state and the SCTP association
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 14:11:30 -0000

Hi Scarlett,
Please note that this document has been replaced by
draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in datatracker)
and that discussion of the topic should be directed to the mmusic list
(although there is some obvious overlap with the data channel discussion
regarding external negotiation).  I copied both groups for this email only
- please respond only to mmusic.

" It is not clear that if the SCTP association is failed to establish, how
to we deal with the newly created data channels.
  Furthermore, how long the valid duration of the connecting state of the
newly created data channels are before the SCTP association has not yet
established ?"

This issue is common to all forms of data channel negotiation and should be
addressed by the core documents rather than this one.  It appears that a
data channel can be in the connecting state indefinitely until the peer
connection is closed.

"When there are multiple data channels with different sub-protocol per a
SCTP association,
Maybe it needs to identify how to close a single data channel, how to close
all data channels with the same sub-protocol and how to close a SCTP
association.
Of course, closing a SCTP association can just set SCTP port number zero.:-)
"

The procedure describes how to close a single data channel.  We did not see
a need to have a special way to close all data channels with the same
sub-protocol since they can just be closed individually.  I don't see a
compelling use case for this, but perhaps you have one?  The document
should point out that data channels terminate with the SCTP association and
peer connection.  Sometimes we forget to state the most obvious things!

BR, Richard


On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (Scarlett) <
scarlett.liuyan@huawei.com> wrote:

> Hi,
>
> Section 5.5.2 does say:
>
>         "o  As described in Section 4.2.2, if the SCTP association is not
> yet
>       established, then the newly created data channels are in the
>       Connecting state, else if the SCTP association is already
>       established, then the newly created data channels are in the Open
>       state."
>   .....
>   It is not clear that if the SCTP association is failed to establish, how
> to we deal with the newly created data channels.
>   Furthermore, how long the valid duration of the connecting state of the
> newly created data channels are before the SCTP association has not yet
> established ?
>
> Section 5.5.3 does say:
>        "5.2.3.  Closing a data channel
>
>       When the application requests the closing of a data channel that was
>       externally negotiated, the browser always performs an in-band SSN
>       reset for this channel.
>
>       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.
>
>       The application must also close any data channel that was externally
>       negotiated, for which the stream identifiers are not listed in an
>       incoming SDP offer."
>    ...
>    When there are multiple data channels with different sub-protocol per a
> SCTP association,
> Maybe it needs to identify how to close a single data channel, how to
> close all data channels with the same sub-protocol and how to close a SCTP
> association.
> Of course, closing a SCTP association can just set SCTP port number
> zero.:-)
>
> Regards,
> Scarlett
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>