Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 17 February 2014 00:16 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45B1A0024 for <clue@ietfa.amsl.com>; Sun, 16 Feb 2014 16:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
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 lfUbaWbfFNIb for <clue@ietfa.amsl.com>; Sun, 16 Feb 2014 16:16:28 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC51A01E9 for <clue@ietf.org>; Sun, 16 Feb 2014 16:16:26 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-5c-530154d7c4e2
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 9B.F4.04853.7D451035; Mon, 17 Feb 2014 01:16:23 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 01:16:23 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres
Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2WgBELw4AAAOFnDE=
Date: Mon, 17 Feb 2014 00:16:22 +0000
Message-ID: <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>
References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com>
In-Reply-To: <53014B44.60600@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvje71EMZgg2cd5hZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mo4/mUGY8Fjw4pV7+4wNTA+U+li5OSQEDCR 2DdjMhuELSZx4d56IJuLQ0jgBKNE99bt7BDOEkaJk9NPs3YxcnCwCVhIdP/TBmkQEQiX6Nh2 hRHEFhZwktiy+C8jRNxZYm3DDHYI20riVNsnFhCbRUBV4uuZV0wgNq+Am8TzVb/A4kIC2RI7 5jawgticAloSJ2e0g81hBDro+6k1YPXMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWp0JBbs /sQGYWtLLFv4mhlil6DEyZlPWCYwisxCMmoWkpZZSFpmIWlZwMiyilGyOLW4ODfdyEAvNz23 RC+1KDO5uDg/T684dRMjMC4ObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCWlK+0FJq4UragKTCmVOry/hdSL8rmL0pw+bK0czLPHL56GV+rg0ezb6jk fTuS+SX/wJE9kem2fts7lWy32dx/ynUr6xpzvCnfypBrqy7zZKssSX8s0PKkVmZbU+HTbRqT trmJSx54OdHYNuZX1hmVSb9fTmV5xyO9LaOhzvOesf9ZQVmlBjslluKMREMt5qLiRABn9JMO WQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qBNStHKbjR2xZhBi_GRlcOO1-Ro
Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 00:16:30 -0000

Hi Christian,

If you want to negotiate usage of CLUE (or, any other specific usage of a webrtc-datachannel) in SDP, one option is to use Richard's draft. The usage of that draft is listed as an open issue in the CLUE data channel draft.

SIP also provides other mechanisms, e.g. media feature tags, for indicating support of features.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Christian Groves <Christian.Groves@nteczone.com> wrote:


Hello Christer,

With the use of webrtc-datachannel how do I negotiate via SDP whether I
want to use clue or not?

A SCTP association (and thus webrtc-datachannel) for example could be
used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP
association to figure out that the endpoints support webrtc-datachannel
put don't support the application that you want.

In the example in section 4.6 there's no way of distinguishing that
description for CLUE vs BFCP vs anything else. Its not a CLUE data
channel is a generic data channel.

Regards, Christian

On 16/02/2014 1:03 AM, Christer Holmberg wrote:
> Hi,
>
> The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section.
>
> Regards,
>
> Christer
>
> PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :)
>
> -----------------------
>
> 4.  SDP Offer/Answer Procedures
>
> 4.1.  General
>
>     This section describes how the SDP media description ("m=") line for
>     a CLUE data channel is created, and how it is used in SDP offers and
>     answers.
>
>     NOTE: The proceudres associated with "m=" lines for other media types
>     (e.g. audio and video) used in a CLUE session are outside the scope
>     of this document.
>
>     OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel
>     Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]
>     will be used with the CLUE data channel.
>
>     NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used
>     with the CLUE data channel, a new associated 'sub-protocol' value
>     needs to be registered with IANA.
>
> 4.2.  SDP Media Description Fields
>
>     The field values of the "m=" line for the CLUE data channel are set
>     as following:
>
>     +----------------+----------------+------------------------+----------------+
>     |     media      |      port         |      proto               |      fmt         |
>     +----------------+----------------+------------------------+----------------+
>     | "applicationS |   DTLS port   | "UDP/TLS/UDPTL" |   SCTP port   |
>     |                    |     value       |                             |     value       |
>     +----------------+----------------+------------------------+---------------+
>
>                       Table 1: SDP "proto" field values
>
> 4.3.  SDP sctpmap Attribute
>
>     The field values of the SDP sctpmap attribute associated with the
>     CLUE data channel "m=" are set as following:
>
>     +---------------------+---------------------------+-----------------------+---------+
>     | sctpmap-number |         app                  | max-message-size | stream |
>     +---------------------+---------------------------+-----------------------+---------+
>     |  fmt value of       | "webrtc-datachannel" |  Implemenation     |  "1"     |
>     | the "m=" line      |                                |     specific             |           |
>     +---------------------+---------------------------+-----------------------+---------+
>
>                       Table 2: SDP "proto" field values
>
> 4.4.  SDP Offerer Procedures
>
>     The procedures for the offerer follow the normal proceures defined in
>     [ref-to-3264].
>
>     When the offerer creates an offer, which contains an "m=" line for a
>     CLUE data channel, it assigns the field values to the "m=" line
>     according to the procedures in Section 4.2.  In addition, the offerer
>     MUST insert an SDP sctpmap attribute associated with the "m=" line.
>
>     In an offer, the offerer MUST NOT insert more than one "m=" line for
>     a CLUE data channel.
>
>     NOTE: CLUE does not support the usage of multiple CLUE data channels.
>
>     The offerer MUST NOT insert more than one SDP sctpmap attributes in
>     an "m=" line for a CLUE data channel.
>
>     If an offerer, in a subsequent offer, wants to disable the CLUE data
>     channel, it assigns a zero port value to the "m=" line associated
>     with the CLUE data channel.  The answerer MUST NOT insert an SDP
>     sctpmap attribute associated with the "m=" line.
>
> 4.5.  SDP Answerer Procedures
>
>     The procedures for the answerer follow the normal proceures defined
>     in [ref-to-3264].
>
>     If the answerer receives an offer, which contains an "m=" line for a
>     CLUE data channel, and the answerer accepts the "m=" line, it creates
>     and inserts an "m=" line in the associated answer.  The answerer
>     assigns the field values to the "m=" line according to the procedures
>     in Section 4.2.
>
>     If, in the offer, a zero port value has been assigned to the "m="
>     line for the CLUE channel, or it the answerer does not accept the
>     "m=" line, but accepts other "m=" lines in the offer (i.e. the
>     answerer will not reject the whole offer), it still inserts an "m="
>     line for a CLUE data channel in the associated answer.  The answerer
>     then assigns a zero port value to the "m=" line.  The answerer MUST
>     NOT insert an SDP sctpmap attribute associated with the "m=" line.
>
> 4.6.  Example
>
>          m=application 54111 SCTP/DTLS 54111
>          a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1
>
>            Figure 1: SDP Media Description for a CLUE data channel
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue