Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Juergen Stoetzer-Bradler <> Sun, 14 February 2016 10:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D3711B3C9A for <>; Sun, 14 Feb 2016 02:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.7
X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcvTwF1SDr87 for <>; Sun, 14 Feb 2016 02:48:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 277711B3C98 for <>; Sun, 14 Feb 2016 02:48:52 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 86DB8857B4882; Sun, 14 Feb 2016 10:48:48 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u1EAmoMF006657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Feb 2016 10:48:50 GMT
Received: from ( []) by (GMO) with ESMTP id u1EAmoiY004263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Feb 2016 11:48:50 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Sun, 14 Feb 2016 11:48:49 +0100
To: EXT Paul Kyzivat <>, Flemming Andreasen <>,, "DRAGE, Keith (Keith)" <>, "Makaraju, Maridi Raju (Raju)" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Juergen Stoetzer-Bradler <>
Message-ID: <>
Date: Sun, 14 Feb 2016 11:48:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090805020501040504070607"
X-Originating-IP: []
Archived-At: <>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Feb 2016 10:48:56 -0000


In your case 2) I would agree that the usage of dcsa embedded attributes seems questionable. After 
all, the dcsa attribute is defined in sdpneg as encapsulating a subprotocol specific attribute. If 
the subprotocol may dynamically change over time without further (SDP offer/answer) negotiation, 
then a negotiation of dcsa embedded attributes may indeed not be very helpful.

In your case 1), I am wondering how would the SDP answerer know which subprotocol to use for which 
data channel, if the subprotocol id is not added to the data channel's dmap attribute (at least if 
multiple data channels are negotiated)? Conceivably via some provisioning, or via a mutual 
understanding of a certain subprotocol to SCTP stream id mapping, or via a certain a priori agreed 
label usage. I hadn't thought of such cases when raising the question if the subprotocol should 
actually be mandatory.
But such use cases would certainly go beyond a pure SDP offer/answer negotiation use case and I 
would argue that such use cases would also go beyond the scope of the sdpneg draft.

I could now imagine the sdpneg draft saying that an SDP offerer should add a subprotocol identifier 
to an offered data channel's dcmap attribute, if it also adds dcsa embedded subprotocol attributes. 
And that an implementation would be on its own, if it does not follow that recommendation (for 
whatever reasons).
Further, similar as for non-dcsa embedded attributes, we could explicitly add text to the sdpneg 
draft saying that a recipient of an an SDP offer or answer should ignore dcsa embedded attributes 
not only if they are completely unknown, but also if their semantics related to the subprotocol is 
not known.
(The current draft says in sec 5.2.3 that the SDP answerer "/Parses and applies the SDP offer.  Note 
that the typical parser normally ignores unknown SDP attributes, which includes data channel related 
attributes./" I think we could make this clearer and explicitly refer to dcsa embedded subprotocol 


On 12.02.2016 17:58, EXT Paul Kyzivat wrote:
> Juergen,
> You bring up a point that perhaps needs further discussion: what does it mean when the subprotocol 
> is not specified?
> IIUC there are at least a couple of reasons this might come about:
> 1) The protocol to be used is not standardized. There is no globally unique name for it. The two 
> ends know what protocol to use based on context.
> 2) The protocol to be used on the channel is not determined via SDP negotiation. The applications 
> want to establish the channel, and then dynamically decide what protocol to use with it. (And that 
> protocol may change over time.)
> I guess that it still might be meaningful to use dcsa with (1), but there would be no way to 
> determine by examination of the SDP whether the usage was compatible with the protocol. In this 
> case the usage of the attributes would be "off label" - being adapted to the proprietary protocol 
> in a way that hopefully the two ends agree.
> I don't see how dcsa makes much sense for (2). If you don't know what protocol will be used then 
> how do you know what attributes to use?
>     Thanks,
>     Paul
> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
>> Flemming, Paul,
>> The current a=dcmap related text in
>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the
>> 'subprotocol' parameter must always be present - rather it is specified
>> as an optional parameter. Thus, current sdpneg text would allow to
>> create an SDP offer for a data channel, which contains one a=dcmap
>> attribute and potentially multiple a=dcsa attributes without the
>> subprotocol actually being given. Based on this discussion I am
>> wondering if the subprotocol parameter should actually be mandatory.
>> In the specific case of MSRP, the msrp-usage-data-channel draft says in
>> that the dcmap attribute includes the label and subprotocol
>> parameters. The current text could possible be made more explicit by
>> saying that the 'subprotocol="MSRP"' parameter must always be present.
>> Have just submitted version 04 of the msrp-usage-data-channel draft,
>> which proposes to add subprotocol identifier "MSRP" to the WebSocket
>> Subprotocol Name registry. This registry would then associate
>> subprotocol id "MSRP" with the msrp-usage-data-channel document.
>> There, in section the MSRP specific usages of the a=dcsa
>> attribute are specified. And there the MSRP specific SDP attributes,
>> which can be dcsa embedded, are described.
>> 'setup' is an attribute, whose semantic changes when being dcsa embedded
>> and associated with subprotocol MSRP, as compared to the meaning of an
>> "a=setup" media level attribute of a TCP/MSRP m-line. Hence these
>> semantical differences are explicitly addressed in the
>> msrp-usage-data-channel draft.
>> Regarding sdpneg, I also think that the current text in sdpneg seems to
>> be sufficient regarding the usage of dcsa encapsulated SDP attributes as
>> being bound to the data channel's subprotocol.  But as the semantic of a
>> dcsa encapsulated attribute may be subprotocol specific (like 'setup'),
>> I'd now tend to consider the subprotocol parameter in the dcmap
>> attribute as being mandatory, as mentioned above. As already discussed,
>> the Websocket subprotocol registry would then refer to the document,
>> which specifies the subprotocol specific usage of dcsa encapsulated
>> parameters.
>> Thanks,
>> Juergen
>> On 11.02.2016 21:52, Flemming Andreasen wrote:
>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote:
>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote:
>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote:
>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote:
>>>>>>> Isn't this the approach we're taking today?
>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific
>>>>>>> drafts are used to describe protocols that use the mechanism (i.e.
>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel &
>>>>>>> draft-ietf-clue-datachannel).
>>>>>> It remains to be seen if that will be enough. E.g., there currently
>>>>>> aren't any iana considerations in
>>>>>> draft-ietf-mmusic-msrp-usage-data-channel.
>>>>>> Suppose I encounter some sdp that uses msrp over a data channel, but
>>>>>> that usage is unknown to me. How do I find the spec (the reference to
>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?
>>>>>> I would like to think that the iana registries will allow me to trace
>>>>>> back to the relevant specs.
>>>>> No disagreement on that part, however having taken another look at both
>>>>> sdpneg and the msrp-usage documents, I still don't agree with your
>>>>> original request for all (existing and new) attributes to specify how
>>>>> they may or may not be used with the dcsa attribute defined by sdpneg.
>>>>> As Christian noted, the sub-protocol specifics are defined in
>>>>> individual
>>>>> documents (like msrp-usage), which calls your the parameters that
>>>>> are at
>>>>> least needed to be supported for that usage. Taking MSRP as an example,
>>>>> why isn't that enough, and how do you see the resulting set of
>>>>> attributes that may or may not be used with MSRP differ between use
>>>>> in a
>>>>> data-channel (and hence encapsulated in dcsa) or as a regular media
>>>>> stream ?
>>>> Based on this discussion, I conclude that it should be sufficient for
>>>> this draft to say that before an attribute can be used with dcsa,
>>>> such usage must be defined somewhere. This could be either:
>>>> - as part of the definition of the attribute, OR
>>>> - as part of the definition of the protocol referenced on the m-line.
>>> We are getting closer, but it's still not obvious to me that you
>>> cannot use an attribute with dcsa if it has not been explicitly
>>> defined for the attribute in question. Clearly, there are attributes
>>> that wouldn't make sense over data channels, just like there are
>>> attributes that don't make sense over particular media descriptions.
>>> Again, I'd like to hear from more people on this, including the authors.
>>> Thanks
>>> -- Flemming
>>>>     Thanks,
>>>>     Paul
>>>>> Also, it would be good to hear from more people on this, including the
>>>>> document authors.
>>>>> Thanks
>>>>> -- Flemming
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>> Regards, Christian
>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we need to
>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it
>>>>>>>>> should be
>>>>>>>>> part of the IANA registry. What I am not agreeing with at this
>>>>>>>>> point is
>>>>>>>>> that there is indeed a need to explicitly speficy these
>>>>>>>>> interactions as
>>>>>>>>> opposed to relying on a more general algorithmic approach (plus the
>>>>>>>>> offerer being responsible for generating a valid offer if he
>>>>>>>>> wants to
>>>>>>>>> establish a data channel).
>>>>>>>> Well, an obvious one is that the protocol(s) the attribute
>>>>>>>> pertains to
>>>>>>>> need to be defined to work over data channels.
>>>>>>>>     Thanks,
>>>>>>>>     Paul
>>>>>>>> _______________________________________________
>>>>>>>> mmusic mailing list
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> .
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> .