Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 21 October 2015 18:10 UTC

Return-Path: <christer.holmberg@ericsson.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 97BF41A875E for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 11:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 o77JHWHXi2bW for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 11:10:54 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801A71A877B for <mmusic@ietf.org>; Wed, 21 Oct 2015 11:10:46 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-d8-5627d524c19b
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.57.27359.425D7265; Wed, 21 Oct 2015 20:10:44 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 20:10:44 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "Stoetzer-Bradler, Juergen (Juergen)" <juergen.stoetzer-bradler@alcatel-lucent.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
Thread-Index: AQHRAptKOrKJQjdNlEOZxQotRUuV5J5kIoLvgAUjjgCAACJ0EIABtwMAgAKhaJeACEHygIAATbtw
Date: Wed, 21 Oct 2015 18:10:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37B82481@ESESSMB209.ericsson.se>
References: <5617C92A.4030009@alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B388F5@ESESSMB209.ericsson.se> <561CFF32.5080601@alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B41098@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACDF79BE0B@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B45C07@ESESSMB209.ericsson.se> <5627AE91.5070605@nteczone.com>
In-Reply-To: <5627AE91.5070605@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RlflqnqYwbd9OhZ/Wn8xWnx538hi 8bRtOZvF1OWPWRxYPFqf7WX1WLLkJ5PHivMzWQKYo7hsUlJzMstSi/TtErgylj9TK7heUnHp z0KWBsZ3YV2MnBwSAiYS7/83MELYYhIX7q1n62Lk4hASOMoo0dLawwzhLGaUaNy0AqiKg4NN wEKi+582SFxE4BejxO6/n1hAuoUFUiUuvFnNCmKLCKRJdE98wgRhR0ks+LSZGcRmEVCV2NHS zg5i8wr4Shz5+xFq2yxmib1rWthAEpwCOhIv7jwEK2IEOun7qTVgg5gFxCVuPZnPBHGqgMSS PeeZIWxRiZeP/7FC2EoSK7ZfYoSoN5A4t30jO4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUha ZiFpmYWkZQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwDg6uOW3wQ7Gl88dDzEKcDAq 8fAm7FQLE2JNLCuuzD3EKMHBrCTCW7JRPUyINyWxsiq1KD++qDQntfgQozQHi5I4bzPTg1Ah gfTEktTs1NSC1CKYLBMHp1QDo3LUP6dT3553e0rXuXDGXf5ck/Q0IkxFRctItoq/5eTpxD2u n9P8RVZKTePdtpK98Ockw73nvma9Pb/y3qUJRyKmHa44r7tC9nO89eXmkLp9HCebeIreS31u mKG02mH73zSexe7LFluFP1tjanr3T5qE9i7uW2c7TW6H6PxYlNaxomR3r11gohJLcUaioRZz UXEiAB81a7ifAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vvs7wyG6dSePk65A1NBZvMDIm3k>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - "a=setup" versus "a=dcsa:x setup"
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Oct 2015 18:10:57 -0000

Hi,

>The "rule of thumb" I had is covered by Juergen's text. It was basically that an endpoint only includes a=dsca:setup if it wanted a role
>different than what is indicated in a=setup. However I think Christer has a separate view.

Correct. I want a=setup to only impact the data channel itself - not what is "inside" the data channel.

>I think the original source of the problem is that RFC6135 links the MSRP establishment role to the a=setup. I.e. the active side 
>is the one that sends the first MSRP message. So these are linked. To unlink it for MSRP over DC its proposed to use a=setup (which 
>was defined for transport connection setup) in the DC (via dsca) to control the MSRP protocol setup.

You can always give a=dsca:setup the same value as a=setup.

>I think at the end of the day the decision is whether we want every WebRTC endpoint to send "a=setup" and "a=dsca:setup" every time
>it wants to set up a MSRP datachannel or whether it only has to send a=dsca:setup if wants a different role from the a=setup.

I see no problem in sending both, as they are used for different things.

Regards,

Christer


Regards, Christian

On 16/10/2015 9:20 AM, Christer Holmberg wrote:
> Albrecht, I can't parse what you said.
>
> If a piece of information is required in order for something to work, 
> then it must be mandatory to include that piece of information. Of 
> course, you may define an implicit default value, but the information 
> must be there.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------
> --
> From: Schwarz, Albrecht (Albrecht)
> <mailto:albrecht.schwarz@alcatel-lucent.com>
> Sent: ‎14/‎10/‎2015 20:09
> To: Christer Holmberg <mailto:christer.holmberg@ericsson.com>;
> Stoetzer-Bradler, Juergen (Juergen)
> <mailto:juergen.stoetzer-bradler@alcatel-lucent.com>; mmusic@ietf.org 
> <mailto:mmusic@ietf.org>; Christian Groves
> (Christian.Groves@nteczone.com) <mailto:Christian.Groves@nteczone.com>
> Subject: RE: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - 
> "a=setup" versus "a=dcsa:x setup"
>
> Hello Christer,
>
> such a prescriptive sentence
>
> />//If a setup value is required for the MSRP session establishment, 
> then the dcsa setup attribute must be mandatory./
>
> relates to a “*conditionally ‘mandatory’*”, i.e., an *optional* 
> tagging in general, right?
>
> @Christian, you had a good rule of thumb proposed, covering the 
> conditionality.
>
> What’s your view?
>
> Regards,
>
> Albrecht
>
> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer 
> Holmberg
> *Sent:* Dienstag, 13. Oktober 2015 15:01
> *To:* Stoetzer-Bradler, Juergen (Juergen); mmusic@ietf.org
> *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - 
> "a=setup" versus "a=dcsa:x setup"
>
> Hi,
>
> If a setup value is required for the MSRP session establishment, then 
> the dcsa setup attribute must be mandatory.
>
> Regards,
>
> Christer
>
> *From:*Juergen Stoetzer-Bradler
> [mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com]
> *Sent:* 13. lokakuuta 2015 15:55
> *To:* Christer Holmberg; mmusic@ietf.org <mailto:mmusic@ietf.org>
> *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel - 
> "a=setup" versus "a=dcsa:x setup"
>
> Hello Christer,
>
> Thank you for your comments.
>
> A dcsa embedded setup attribute does not have any MSRP transport 
> protocol related establishment role semantics.
> But an MSRP over data channel endpoint still needs to know its MSRP 
> session establishment role.
> In some data channel to TCP (or TLS) transport interworking cases, 
> which are described in section 6, this MSRP session establishment role 
> cannot always be derived from the DTLS/SCTP establishment role.
> In such cases a dcsa embedded setup attribute for MSRP seems to be 
> required.
> However, in some other interworking cases, and especially in 
> end-to-end data channel cases the MSRP session establishment role 
> could be tightly coupled with the DTLS/SCTP establishment roles and 
> hence with the "a=setup" attribute.
> If we don't allow the "a=setup" attribute to also describe the MSRP 
> session establishment role (if no "a=dcsa:x setup"
> attribute is present), then we should probably specify that a dcsa 
> embedded setup attribute is mandatory for MSRP over data channel 
> sessions.
>
> For MSRP as sub-protocol, would a mandatory "a=dcsa:x setup:<role>" 
> attribute be agreeable?
>
> Thanks,
> Juergen
>
> On 10.10.2015 06:26, Christer Holmberg wrote:
>
>     Hi.
>
>     First, I think you suggest far too much text, but that is editorial.
>
>     Second, as you say, the media level 'setup' attribute is used to
>     negotiate the SCTPoDTLS association establishment. But, I don't
>     think it should be used to negotiate the MSRP roles etc in case
>     the 'dcsa:x setup' is not present. The 'setup' attribute has
>     nothing to do with the protocol carried within the data channel -
>     the reason we defined the 'dsca' attribute was to be able to carry
>     such information.
>
>     Regards,
>
>     Christer
>
>     Sent from my Windows Phone
>
>     
> ----------------------------------------------------------------------
> --
>
>     *From: *Juergen Stoetzer-Bradler
>     <mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com>
>     *Sent: *‎09/‎10/‎2015 17:03
>     *To: *mmusic@ietf.org <mailto:mmusic@ietf.org>
>     *Subject: *[MMUSIC] draft-ietf-mmusic-msrp-usage-data-channel -
>     "a=setup" versus "a=dcsa:x setup"
>
>     Hello,
>
>     An MSRP over data channel related SDP media description will have
>     a media level "a=setup:<role>" attribute and may additionally
>     contain an "a=dcsa" encapsulated setup attribute "a=dcsa:x
>     setup:<role>". Current version
>     draft-ietf-mmusic-msrp-usage-data-channel-02
>     does not yet have any text related to the setup attribute except
>     for listing it as potential dcsa encapsulated MSRP specific attribute.
>     As the media level "a=setup" attribute is used to negotiation the
>     DTLS and SCTP establishment roles, and as the setup attribute is
>     also used
>     in MSRP over TCP cases to negotiate the "active" role of MSRP
>     session endpoints (RFCs 6135, 6714) we propose to explicitly describe
>     the semantics of dcsa encapsulated setup attributes for MSRP over
>     data channel in draft-ietf-mmusic-msrp-usage-data-channel.
>
>     We propose to add a new section 5.1.1.3 "Media Description Level
>     setup Attribute Versus Data Channel Specific setup Attribute"
>     after section 5.1.1.2 ("Use of dcsa Attribute") and to extend
>     existing section 6 ("Gateway Configuration") with setup attribute
>     related procedures.
>
>     Would the following new section 5.1.1.3 and modified section 6 be
>     agreeable?
>
>     Thanks,
>     Juergen
>
>     Proposed new Section 5.1.1.3:
>
>     5.1.1.3.  Media Description Level setup Attribute Versus Data
>     Channel Specific setup Attribute
>
>        The SDP setup attribute, as introduced in [RFC4145], can be used in
>        WebRTC data channel related SDP media descriptions as a media level
>        attribute, which is directly associated with the corresponding
>     DTLS/
>        SCTP "m" line.  In this case the setup attribute is of the form
>        "a=setup:<role>", where <role> assumes values as defined in
>        [RFC4145].  Such a setup attribute is then used as specified in
>        [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment
>        roles of the DTLS connection and the SCTP association.
>
>        Additionally, the setup attribute can be embedded in a dcsa
>     attribute
>        and hence can explicitly be associated with an MSRP session over a
>        specific data channel.  In such a case it is of the form "a=dcsa:x
>        setup:<role>", with x being the data channel's SCTP stream
>        identifier.  Such a dcsa attribute embedded setup attribute has no
>        relationship with the DTLS connection and SCTP association
>        establishment roles.
>
>        dcsa attribute embedded setup attributes are OPTIONAL for MSRP
>        sessions over data channels.
>
>        If an MSRP over data channel description contains a dcsa embedded
>        setup attribute, then this embedded setup attribute is used to
>        negotiate, which MSRP session endpoint assumes the active role
>     as per
>        Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975].
>
>        If an MSRP over data channel description does not contain a dcsa
>        embedded setup attribute, then the media description level
>     "a=setup"
>        attribute, which is associated with the data channel's DTLS
>        connection and SCTP association, is used to negotiate, which MSRP
>        session endpoint assumes the active role.
>
>        If an MSRP over data channel endpoint wants to negotiate an
>     active or
>        non-active MSRP session establishment role, which is different from
>        its DTLS connection and SCTP association establishment role,
>     then it
>        MUST include a dcsa embedded setup attribute for this MSRP session.
>        In this case this dcsa embedded setup attribute's value is
>     different
>        from the value of the DTLS/SCTP "m" line's "a=setup" attribute.
>
>
>     Proposed modified section 6:
>
>     6.  Gateway Configuration
>
>        This section describes the network configuration where one MSRP
>        endpoint uses data channels as MSRP transport, the other MSRP
>        endpoint uses TLS/TCP connections as MSRP transport, and the
>     two MSRP
>        endpoints interwork via an MSRP gateway.
>
>        Specifically, a gateway can be configured to interwork an MSRP
>        session over a data channel with a peer that does not support data
>        channel transport in one of two ways.  In one model, the gateway
>        performs as a MSRP B2BUA to interwork all the procedures as
>     necessary
>        between the endpoints.  No further specification is needed for this
>        model.
>
>        Alternately, the gateway can use CEMA procedures to provide
>     transport
>        level interworking between MSRP endpoints using different transport
>        protocols as follows.
>
>        When the gateway performs transport level interworking between MSRP
>        endpoints, all of the procedures in Section 5 apply to each peer,
>        with the following additions:
>
>        o  The endpoint establishing an MSRP session using data channel
>           transport SHALL NOT request inclusion of any relays, although it
>           MAY interoperate with a peer that signals the use of relays.
>
>        o  The gateway receiving an SDP offer that includes a request to
>           negotiate an MSRP session on a data channel can provide
>     transport
>           level interworking in the same manner as a CEMA SBC by
>     forwarding
>           TCP or TLS transport parameters in a new "m" line with the
>           appropriate attributes within the forwarded SDP offer.
>
>           *  If the received data channel side SDP offer contains a dcsa
>              embedded setup attribute for the to be negotiated MSRP
>     session,
>              then the gateway interworks this dcsa embedded setup
>     attribute
>              with the media description level "a=setup" attribute of this
>              MSRP session's "m" line in its forwarded SDP offer.
>
>           *  If the received data channel side SDP offer does not
>     contain a
>              dcsa embedded setup attribute for the to be negotiated MSRP
>              session, then the gateway interworks the media description
>              level "a=setup" attribute, which is directly associated with
>              the data channel's DTLS/SCTP "m" line, with the media
>              description level "a=setup" attribute of this MSRP session's
>              "m" line in its forwarded SDP offer.
>
>        o  Similarly, a gateway receiving an SDP offer to negotiate an MSRP
>           session using TCP or TLS transport with an endpoint that only
>           supports data channel transport for MSRP can provide transport
>           level interworking in the same manner as a CEMA SBC by
>           establishing a new data channel for the MSRP session with the
>           target endpoint.
>
>           *  In this case the gateway interworks the TCP or TLS associated
>              media description level "a=setup" attribute of the to be
>              negotiated MSRP session's received "m" line either with the
>              media description level "a=setup" attribute of the data
>              channel's DTLS/SCTP "m" line, or with the dcsa embedded setup
>              attribute of this MSRP session's new data channel.
>
>           *  If the gateway's DTLS connection and SCTP association
>              establishment role on its data channel side is equal to the
>              "a=setup" attribute's value of the received MSRP over TCP or
>              TLS "m" line, then the gateway MAY add a dcsa embedded setup
>              attribute to the description of the MSRP session's new data
>              channel in its generated data channel side offer.
>              Alternatively, in this case the gateway MAY omit adding
>     such a
>              dcsa embedded setup attribute to the description of the MSRP
>              session's new data channel in its generated data channel side
>              offer.  Otherwise, if the gateway's DTLS connection and SCTP
>              association establishment role is different from the MSRP
>     over
>              TCP or TLS associated received "a=setup" attribute's value,
>              then the gateway MUST add a dcsa embedded setup attribute to
>              the description of the MSRP session's new data channel in its
>              generated data channel side offer.
>
>           *  If the gateway adds a dcsa embedded setup attribute
>     associated
>              with this MSRP session to its data channel side SDP
>     offer, then
>              the value of this embedded setup attribute MUST be equal
>     to the
>              value of the "a=setup" attribute, which is associated
>     with this
>              MSRP session's "m" line in the received TCP or TLS side SDP
>              offer.
>