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

Flemming Andreasen <> Wed, 03 February 2016 22:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C42881B3600 for <>; Wed, 3 Feb 2016 14:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.902
X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZfuxUTWw9Vu for <>; Wed, 3 Feb 2016 14:42:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBDBE1B35FE for <>; Wed, 3 Feb 2016 14:42:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4493; q=dns/txt; s=iport; t=1454539330; x=1455748930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DGUuNjbjXpC4ute2uuDfG++Y1kno+DFBqMpaUNa1snw=; b=Rk1V/I+ibjQCPEaENgVl973SBYsM1RkA4ILalx1FwdRGPr6L9Rj8MdMS /ANgyGrB0Pd2Sb1R3YLbwbM0wA9P3pOQxBXWM6RXRG74nMkrqZEhuUArc L1vuoCSku0nKHH+pqsiuBNCJGIYWeUxIzVxzPkIU5bkcnQPhAU+Doixlk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,392,1449532800"; d="scan'208";a="234003492"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 22:42:10 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id u13Mg9fG005401; Wed, 3 Feb 2016 22:42:09 GMT
To: Paul Kyzivat <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Flemming Andreasen <>
Message-ID: <>
Date: Wed, 03 Feb 2016 17:42:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 03 Feb 2016 22:42:12 -0000

On 2/3/16 2:13 PM, Paul Kyzivat wrote:
> On 2/2/16 5:35 PM, Flemming Andreasen wrote:
>> On 1/29/16 10:30 AM, Paul Kyzivat wrote:
>>> We *could* rethink this, and reduce the information put in IANA for
>>> attributes. It would be sufficient for the IANA registry to give the
>>> attribute name, and a reference to the document where it is defined.
>>> (As long as we are assured that the information is present in the
>>> referenced document. It may be that this is not the case for some
>>> older attributes.)
>>> But we should be consistent about this.
>> I'm not concerned about the IANA registration. What I am concerned about
>> is that we are heading down the path of explicitly thinking about and
>> specifying interactions between different attributes. Again, I'm not
>> convinced that it is really necessary here and that you couldn't solve
>> the issue for dcsa with a more algorithmich approach similar to what we
>> did for capability negotiation.
> Are you referring to:
>    When the attribute capability contains a session-level attribute,
>    that "acap" attribute can only be provided at the session level.
>    Conversely, media-level attributes can be provided in attribute
>    capabilities at either the media level or session level.  The base
> I don't see the parallel. capneg is really a "macro" mechanism, so it 
> is really up to the user to ensure that all possible expansions of a 
> macro are valid.
I'm referring to CapNeg's "conceptual" construction of SDPs based on 
potential configurations - see e.g. Sections 3.1, 3.5.1 and 3.6.2 in RFC 

> But I see a direct analogy to the a=ssrc attribute. That one also is 
> an attribute that recursively contains another attribute. But not all 
> attributes "work" (or make sense) with a=ssrc. Only those whose effect 
> can be narrowed to a particular RTP stream are valid. So it 
> established a registry for those that do work with it.
> The a=dcsa attribute is very similar to that. Again not every 
> attribute works with it. Only those that can be applied to a 
> particular data channel apply.
Right, but what are the constraints on a particular data channel that 
may or may not make them work with a data channel ? Why is this 
fundamentally different than specifying parameters for a media stream ?

> Rather than keeping separate registries for session level, media 
> level, and "source" (a=ssrc) level, we have agreed to merge them and 
> add a column to indicate which level(s) apply to each attribute. That 
> makes it easier to add yet another (dcsa) "level".
>> Can you (and/or the authors) elaborate on why such an approach would not
>> work ?
> It isn't strictly necessary to have this information in IANA. It would 
> be sufficient to have it in the documents that define each attribute. 
> (As long as they really do have it.)
> And, if it was there and not in the registry, then each document could 
> decide whether applicability can be specified via an algorithm, or if 
> it must be done by enumeration.
> But, if that is the case, then it should apply for all the distinct 
> contexts where attributes might be used: session level, media level, 
> source level, dcsa level, and capneg level. (Every distinct place that 
> <attribute> can appear.)
> And there is a downside to this. Each time a new "level" is defined 
> (e.g., when a=dcsa is defined) then either it has to provide a rule 
> for every attribute, current and future, or else the definition of 
> every attribute, current and future, will need to specify 
> applicability to this new level.
> Consider a=ssrc. When some new attribute is defined, will it be usable 
> with a=ssrc? Without the registry, how would anyone find out?
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).


-- Flemming

>     Thanks,
>     Paul
> _______________________________________________
> mmusic mailing list
> .