Subject: [MMUSIC] SDP Capability Negotiation: Solution Document

From: Flemming Andreasen <[email-masked]>
Date: Tue, 02 Jan 2007 13:45:29 -0500

Greetings

Based on our updated requirements for SDP capability negotiation, I have 
just submitted an updated solution document as 
draft-ietf-mmusic-sdp-capability-negotiation-00.txt, which you can 
retrieve from 
http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-00.txt 
until it appears in the archives.

We will discuss this document on our next SDP Capability Negotiation 
design team call (1/9/07). Note that there are some open issues in the 
document currently (look for "Editor's note"), in particular in the area 
of supporting media capabilities at both the session level and the media 
level, which is not terribly elegant or even clear in the current 
document. Comments, suggestions, and other feedback on this as well as 
the rest of the document is hereby solicited.

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Tue, 2 Jan 2007 15:59:12 -0800

Flemming,

>          ... Another issue here is that
>           payload type numbers, which really have only media-level  
> scope, are
>           ill-suited to be used at the session-level or across  
> multiple media
>           streams (as is being done here). However, an alternative  
> (and more
>           proper) solution seems to involve significantly more work  
> and
>           deviations from the current SDP framework. This in turn  
> makes it
>           more difficult to automatically use new media types,  
> formats,
>           protocols, etc. defined elsewhere within this framework,  
> and that
>           is a major disadvantage. Another option is to forgo the  
> session-
>           level media capabilities as well as the ability to  
> reference across
>           media streams - it will make the solution less efficient  
> though and
>           difficult to express latent capabilities for media  
> streams not
>           included in the offer or answer.]

It is noted in a few places in your document that session-level  
scoping of the attributes are in certain cases confusing or not  
suitable.  I recall going through the exercise of trying to put  
security descriptions at the session level and deciding that it added  
too much complexity.  Is there a compelling need to even have a  
session-level scope for your attributes?

Mark

On Jan 2, 2007, at 10:45 AM, Flemming Andreasen wrote:

> Greetings
>
> Based on our updated requirements for SDP capability negotiation, I  
> have just submitted an updated solution document as draft-ietf- 
> mmusic-sdp-capability-negotiation-00.txt, which you can retrieve  
> from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- 
> capability-negotiation-00.txt until it appears in the archives.
>
> We will discuss this document on our next SDP Capability  
> Negotiation design team call (1/9/07). Note that there are some  
> open issues in the document currently (look for "Editor's note"),  
> in particular in the area of supporting media capabilities at both  
> the session level and the media level, which is not terribly  
> elegant or even clear in the current document. Comments,  
> suggestions, and other feedback on this as well as the rest of the  
> document is hereby solicited.
>
> Thanks
>
> -- Flemming
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Jan 2007 10:41:24 -0500

I don't understand why anyone wants to *ban* the use of at attribute at 
session level. Session level attributes can be understood as simply 
defaults when there is no media stream level attribute for a media 
stream. As long as viewed that way, I don't see the issue with using 
*any* attribute at session level.

It may of course be the case that the semantics of a particular 
attribute are such that applying it to more than one media stream makes 
no sense. In that case there won't be any benefit to using the attribute 
at session level, but it doesn't require that using the attribute at 
session level be banned.

The challenge is defining attributes in such a way that there *is* some 
benefit to using it at session level. That clearly isn't possible for 
all attributes.

	Paul

Mark Baugher wrote:
>>           proper) solution seems to involve significantly more work and
>>           more difficult to automatically use new media types, formats,
>>           protocols, etc. defined elsewhere within this framework, and 
>> that
>>           level media capabilities as well as the ability to reference 
>> across
>>           difficult to express latent capabilities for media streams not
> It is noted in a few places in your document that session-level scoping 
> of the attributes are in certain cases confusing or not suitable.  I 
> recall going through the exercise of trying to put security descriptions 
> at the session level and deciding that it added too much complexity.  Is 
> there a compelling need to even have a session-level scope for your 
> attributes?
> 
> Mark
> 
>> have just submitted an updated solution document as 
>> document currently (look for "Editor's note"), in particular in the 
>> area of supporting media capabilities at both the session level and 
>> the media level, which is not terribly elegant or even clear in the 
>> current document. Comments, suggestions, and other feedback on this as 
>> well as the rest of the document is hereby solicited.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 3 Jan 2007 08:34:38 -0800

I did not say anything about banning session-level attributes.  You  
should read my note again.

Mark

On Jan 3, 2007, at 7:41 AM, Paul Kyzivat wrote:

> I don't understand why anyone wants to *ban* the use of at  
> attribute at session level. Session level attributes can be  
> understood as simply defaults when there is no media stream level  
> attribute for a media stream. As long as viewed that way, I don't  
> see the issue with using *any* attribute at session level.
>
> attribute are such that applying it to more than one media stream  
> makes no sense. In that case there won't be any benefit to using  
> the attribute at session level, but it doesn't require that using  
> the attribute at session level be banned.
>
> The challenge is defining attributes in such a way that there *is*  
> some benefit to using it at session level. That clearly isn't  
> possible for all attributes.
>
> 	Paul
>
> Mark Baugher wrote:
>> Flemming,
>>>           payload type numbers, which really have only media- 
>>> level scope, are
>>>           streams (as is being done here). However, an  
>>> alternative (and more
>>>           protocols, etc. defined elsewhere within this  
>>> framework, and that
>>>           media streams - it will make the solution less  
>>> efficient though and
>> security descriptions at the session level and deciding that it  
>> added too much complexity.  Is there a compelling need to even  
>> have a session-level scope for your attributes?
>> Mark
>>> Based on our updated requirements for SDP capability negotiation,  
>>> I have just submitted an updated solution document as draft-ietf- 
>>> in particular in the area of supporting media capabilities at  
>>> both the session level and the media level, which is not terribly  
>>> suggestions, and other feedback on this as well as the rest of  
>>> the document is hereby solicited.
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Jan 2007 14:55:43 -0500

> should read my note again.

Sorry, I guess I wasn't clear. You seem to be recommending that in some 
cases it might not be feasible or worth the trouble to define a session 
level attribute - that the attribute could instead be defined only for 
media level.

My point is that I don't understand why it is ever necessary to specify 
that an attribute be usable only at media level. (Though RFC 4566 
defines several that are.) The real issue is to identify those cases 
where the same attribute definition cannot meaningfully appear in more 
than one media field - either by being repeated or by by being defaulted 
into more than one media field from session level.

For example, a=rtpmap is defined as only media level, but it could be 
quite useful in some cases to use it as a session level attribute. E.g. 
(some lines omitted)

             m=audio 49001 RTP/AVP 96 97
             a=rtpmap:96 L8/8000
             a=rtpmap:97 L16/8000
             m=audio 49002 RTP/AVP 96 97
             a=rtpmap:96 L8/8000
             a=rtpmap:97 L16/8000

could be written as follows if a=rtpmap were allowed as a session level 
attribute:

             a=rtpmap:96 L8/8000
             a=rtpmap:97 L16/8000
             m=audio 49001 RTP/AVP 96 97
             m=audio 49002 RTP/AVP 96 97

Even in cases where the same attribute value doesn't make sense in 
multiple media fields, there would be no real harm in allowing the 
attribute at session level. For example, the following would be equivalent:

             m=audio 49001 RTP/AVP 96 97
             a=label:english
             m=audio 49002 RTP/AVP 96 97
             a=label:spanish

             a=label:english
             m=audio 49001 RTP/AVP 96 97
             m=audio 49002 RTP/AVP 96 97
             a=label:spanish

Conversely the following both have the same nonsensical meaning:

             m=audio 49001 RTP/AVP 96 97
             a=label:english
             m=audio 49002 RTP/AVP 96 97
             a=label:english

             a=label:english
             m=audio 49001 RTP/AVP 96 97
             m=audio 49002 RTP/AVP 96 97

Its too late now to state that existing attribute definitions that 
specified to be only media level, for reasons of backward compatibility. 
But I think it would make sense to stop defining *new* attributes that 
are only valid at media level.

	Paul

>> I don't understand why anyone wants to *ban* the use of at attribute 
>> at session level. Session level attributes can be understood as simply 
>> makes no sense. In that case there won't be any benefit to using the 
>> attribute at session level, but it doesn't require that using the 
>> attribute at session level be banned.
>>
>> some benefit to using it at session level. That clearly isn't possible 
>> for all attributes.
>>
>>     Paul
>>
>> Mark Baugher wrote:
[snip]

---

From: Mark Baugher <[email-masked]>
Date: Wed, 3 Jan 2007 12:55:48 -0800

On Jan 3, 2007, at 11:55 AM, Paul Kyzivat wrote:

>
>
> Mark Baugher wrote:
>> I did not say anything about banning session-level attributes.   
>> You should read my note again.
>
> Sorry, I guess I wasn't clear. You seem to be recommending that in  
> some cases it might not be feasible or worth the trouble to define  
> a session level attribute - that the attribute could instead be  
> defined only for media level.

Right, that happened to be the case for SDP security descriptions.  I  
don't know if it's the case for capability negotiation.

>
> My point is that I don't understand why it is ever necessary to  
> specify that an attribute be usable only at media level.

In the case of SDP security descriptions, the attribute specified a  
key for the media stream and we decided not to share keys between  
media streams.  Hence, the attribute was strictly media level.  It  
was still possible to put common parameters at the session level, but  
that turned out to be more complex - in the case of security  
descriptions.

> (Though RFC 4566 defines several that are.) The real issue is to  
> identify those cases where the same attribute definition cannot  
> meaningfully appear in more than one media field - either by being  
> repeated or by by being defaulted into more than one media field  
> from session level.

This is related to my original question: What do we gain by doing  
this?  Fewer lines? If the SDP is largely machine-generated and  
machine-read, this does not seem to be a compelling reason if it  
makes the specification more complex, e.g. requiring rules for over- 
riding session defaults in media entries, for example.

>
> For example, a=rtpmap is defined as only media level, but it could  
> be quite useful in some cases to use it as a session level  
> attribute. E.g. (some lines omitted)
>
> could be written as follows if a=rtpmap were allowed as a session  
> level attribute:
>
>             a=rtpmap:96 L8/8000
>             a=rtpmap:97 L16/8000
> specified to be only media level, for reasons of backward  
> compatibility. But I think it would make sense to stop defining  
> *new* attributes that are only valid at media level.

Your examples are good ones.  But there are cases when it's either  
necessary or simpler to tolerate some redundancy.  As a rule, it's  
probably better to keep the SDP message as small as possible so I  
didn't mean to suggest that session-level attributes should be  
banned.  Just questioned.

Mark
>>> The challenge is defining attributes in such a way that there  
>>> *is* some benefit to using it at session level. That clearly  
>>> isn't possible for all attributes.
>>>
>>>     Paul
>>>
>>> Mark Baugher wrote:
> [snip]

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 03 Jan 2007 20:20:22 -0500

> session-level scope for your attributes?
It's really driven by two things:
1. A desire to provide a more compact overall encoding. By listing 
capabilities only once and them referencing some of them in potential 
configurations in more than one "m=" line (typically of the same type, 
e.g. "audio"), we cut down on the overall message size.
2. We currently have a requirement to express latent capabilities for 
media streams that are not part of the offer (or answer). This requires 
a listing of media capabilities at the session level.

-- Flemming

>> design team call (1/9/07). Note that there are some open issues in 
>> the document currently (look for "Editor's note"), in particular in 
>> the area of supporting media capabilities at both the session level 
>> and the media level, which is not terribly elegant or even clear in 
>> the current document. Comments, suggestions, and other feedback on 
>> this as well as the rest of the document is hereby solicited.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 03 Jan 2007 20:33:04 -0500

Paul Kyzivat wrote:
> some cases it might not be feasible or worth the trouble to define a 
> session level attribute - that the attribute could instead be defined 
> only for media level.
>
> specify that an attribute be usable only at media level. (Though RFC 
> 4566 defines several that are.) The real issue is to identify those 
> cases where the same attribute definition cannot meaningfully appear 
> in more than one media field - either by being repeated or by by being 
> defaulted into more than one media field from session level.
>
> quite useful in some cases to use it as a session level attribute. 
> E.g. (some lines omitted)
>
The problem with that particular approach is that RTP payload types 
apply to individual media streams and hence e.g. payload type 96 can be 
mapped to different codecs in different media streams. Once you start 
using it at the session level, you need at a minimum to require 
uniqueness at the session level (i.e. across media stream types), which 
may not get you as far as you want considering the limited payload 
number space. You  also have to consider how to handle overlap between 
payload type numbers provided at the session and media level. Add 
"rtpmap" and "fmtp" attributes, both of which are linked to a payload 
type number, and the situation quickly becomes less than clear.
The whole thing is further complicated by the fact that the 
interpretation of <fmt> (payload type in this case) part of the "m=" 
line depends on the <proto> (RTP/AVP in this case). For example, I can 
specify

    m=image 49001 tcp t38

which clearly is unambiguous because I actually use proper MIME type and 
subtype and hence does not suffer the problem that payload types does. 
Take a look at MSRP instead, and you get something like

    m=message 7654 TCP/MSRP *

which is yet another variant on the whole scheme.
>             m=audio 49002 RTP/AVP 96 97
I'm not sure those are semantically equivalent per RFC 4566, but I 
understand your point (having session level attributes apply as defaults 
at the media level).
>             m=audio 49002 RTP/AVP 96 97
Depends on what those two audio streams are for, but again I understand 
your point.
> compatibility. But I think it would make sense to stop defining *new* 
> attributes that are only valid at media level.
I'm not so sure about that. It depends on the attribute in question.

-- Flemming