Subject: [MMUSIC] Preference of potential over actual configurations in SDP cap-neg

From: Simo Veikkolainen <[email-masked]>
Date: Fri, 04 Apr 2008 12:27:02 +0300

Hello,

We are working with Miguel on an update to our draft on circuit-switched 
audio streams in SDP (draft-garcia-mmusic-sdp-cs-00).

We had the following Note:

       Note that according to the SDP capabilities negotiation framework
       the potential configurations are preferred over the actual
       configurations.  In some use cases the offerer may want to offer
       two media streams as truly alternatives, and not prefer one over
       the other.  Further consideration is needed to determine how this
       is accomplished.

We would like to offer an RTP stream or a circuit-switched audio stream 
as truly alternatives in the SDP offer. According to 
draft-ietf-mmusic-sdp-capability-negotiation-08 this does not seem to be 
possible. From Section 3.6.1 of SDP cap neg:

    Note that the actual configuration is by default the least-preferred
    configuration, and hence the answerer will seek to negotiate use of
    one of the potential configurations instead. If the offerer wishes a
    different preference for the actual configuration, the offerer MUST
    include a corresponding potential configuration with the relevant
    configuration number (which indicates the relative preference
    between potential configurations); this corresponding potential
    configuration should simply duplicate the actual configuration.

Assume the actual configuration describes an RTP stream, and a potential 
configuration describes a circuit-switched stream (using media 
capabilities as defined in draft-ietf-mmusic-sdp-media-capabilities-03 
and our draft). Even if we duplicate the actual configuration to the 
list of potential configurations, there is still a preference order 
among the potential configurations.

For our use case it would be helpful to be able to define actual and 
potential configurations with equal preference, or multiple potential 
configurations with equal preference.

Could the requirement on strict preference order be relaxed?

Apologies if this has been discussed before, I'm new to the list.

Regards,
Simo Veikkolainen

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 09:28:03 -0400

I apologize for not having been following the capability negotiation 
draft, so this might not make sense as it is currently defined ...

What might be desirable here is to send an INVITE that contains SDP with 
capabilities but *no* offer. Then the recipient, having received an 
offerless invite, would generate an offer based on the capabilities 
carried in the INVITE.

The trick of course is how to convey an SDP with capabilities without it 
being considered an offer. I guess it could be handled via a different 
Content-Disposition.

A variant on this would be to send an offer with capabilities but 
without any actual media streams. Thus the answer could not contain any 
media streams. But then there could be another round of O/A using the 
capabilities to decide on what to offer.

	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Apr 2008 11:00:28 -0400

Simo Veikkolainen wrote:
> Hello,
>
> We are working with Miguel on an update to our draft on 
> circuit-switched audio streams in SDP (draft-garcia-mmusic-sdp-cs-00).
>
> We would like to offer an RTP stream or a circuit-switched audio 
> stream as truly alternatives in the SDP offer. According to 
> draft-ietf-mmusic-sdp-capability-negotiation-08 this does not seem to 
> be possible. From Section 3.6.1 of SDP cap neg:
>
> Assume the actual configuration describes an RTP stream, and a 
> potential configuration describes a circuit-switched stream (using 
> media capabilities as defined in 
> draft-ietf-mmusic-sdp-media-capabilities-03 and our draft). Even if we 
> duplicate the actual configuration to the list of potential 
> configurations, there is still a preference order among the potential 
> configurations.
>
This would wreak havoc on the current structure since the potential 
configuration number is also an indicator of the preference, and we need 
uniqueness among the potential configuration numbers.

Taking a step back though, I'm not following why it is important to be 
able to specify the same preference among two alternatives as opposed to 
different ones. At the end of the day, if the recipient supports only 
one of them, he can choose that one. If he supports both of them, then 
what difference does it make (if he truly has a preference, nothing can 
prevent him from choosing the one he actually wants) ?

-- Flemming

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 07 Apr 2008 09:49:00 +0300

Paul:

You are referring to another use case. For the circuit-switched 
descriptions draft we don't want to do the equivalent of an empty offer 
with only capabilities. No. What we want is to say: Here is my RTP audio 
stream, which has preference, but you can also use CS if you wish.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Simo Veikkolainen <[email-masked]>
Date: Mon, 07 Apr 2008 09:54:03 +0300

See below.

> prevent him from choosing the one he actually wants) ?

That would be fine for us. But doesn't this sentence in sdp-cap-neg 
(Section 3.6.2) mandate the answerer to prefer the most preferred 
configuration?

    For each media description where capability negotiation is to be
    performed (i.e. all required capability negotiation extensions are
    supported and at least one valid potential configuration attribute
    is present), the answerer MUST attempt to perform capability
    negotiation by using the most preferred potential configuration that
    is valid to the answerer. A potential configuration is valid to the
    answerer if:

-Simo

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 07 Apr 2008 10:00:40 +0300

Simo Veikkolainen wrote:
>>> draft-ietf-mmusic-sdp-media-capabilities-03 and our draft). Even if 
>>> we duplicate the actual configuration to the list of potential 
>> configuration number is also an indicator of the preference, and we 
>> need uniqueness among the potential configuration numbers.
>>
>> able to specify the same preference among two alternatives as opposed 
>> to different ones. At the end of the day, if the recipient supports 
>> only one of them, he can choose that one. If he supports both of them, 
>> then what difference does it make (if he truly has a preference, 
>> nothing can prevent him from choosing the one he actually wants) ?
> 

The requirement for the CS draft is either not having any preference (it 
is a local implementation decision of the answerer) or if there is a 
preference, it has to be explicitly written in the SDP. The current text 
that Simo just quoted mandates an implicit preference. This implicit 
preference works nicely for offering RTP and SRTP, where the alternative 
(SRTP) is always preferred, but might not be supported.

In the CS draft we want to signal RTP in the m= line for higher 
compatibility. The alternative (a CS bearer) is typically less preferred 
than RTP.

So, we either remove preferences from the SDP Capability Negotiation or 
we explicitly signal them.

/Miguel

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 7 Apr 2008 09:20:39 +0200

Hi

Not sure that I follow the discussion and what the problem actually is,
but wouldn't an SDP offer like the below solve this issue ?

c=creq:cs-v0 (don't find any creq for the ccap extension in the draft)
m=audio 49999 RTP/AVP 0
c=IN IP4 10.0.0.1
a=tcap:1 RTP/AVP CS
a=ccap:1 IN xxxxx
a=ccap:2 CS xxxxx 
a=pcfg:1 t=1 c=1
a=pcfg:2 t=2 c=2

This would give CS a lower preference than RTP (which is also the
default).

/Ingemar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Miguel Garcia
Sent: den 7 april 2008 09:01
To: Simo Veikkolainen
Cc: Flemming Andreasen; [email-masked]
Subject: Re: [MMUSIC] Preference of potential over actual configurations
inSDP cap-neg

Simo Veikkolainen wrote:
>>> draft-ietf-mmusic-sdp-capability-negotiation-08 this does not seem 
>>> to be possible. From Section 3.6.1 of SDP cap neg:
>>>
>>> configurations, there is still a preference order among the 
>>> potential configurations.
>>>

>>> potential configurations with equal preference, or multiple 
>>> potential configurations with equal preference.
>>>
>> Taking a step back though, I'm not following why it is important to 
>> be able to specify the same preference among two alternatives as 
>> opposed to different ones. At the end of the day, if the recipient 
>> supports only one of them, he can choose that one. If he supports 
>> both of them, then what difference does it make (if he truly has a 
>> preference, nothing can prevent him from choosing the one he actually
wants) ?

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 07 Apr 2008 10:53:40 +0300

Hi Ingemar:

Thanks for your comment. You raised two different issues here.

1) Missing creq attribute in the draft. I acknowledge it, and the next 
version of it will define the cs-v0 capability.

2) You said that it is possible to create two potential configurations 
and prioritize them. I believe this is correct, and will mostly solve 
the issue. There is still a doubt with the "MUST attempt" text in the 
following paragraph of SDP cap-neg:

The problem here is that the "MUST attempt" does not consider any local 
policy or, in our case, network conditions, that the SDP answerer would 
have. This is the missing item. So, in the example of RTP and CS, the 
SDP answer will support RTP and CS, and CS will only be used if the 
network does not offer enough bandwidth or QoS to send RTP audio over 
it. So, I would like to see that the capability negotiation draft 
considers endpoint preferences/policy before applying the "MUST attempt" 
in the previous text.

/Miguel

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 9 Apr 2008 08:44:59 +0200

Hi

Perhaps I am making things too simple but this is the way I see it. 
I see no reason to why local or network policy would not play a role in
this aspect even with the present formulation in the draft, "MUST
attempt to" does not in my mind mean "MUST use". 

For instance one could imagine that there are several potential video
configurations, say 2Mbps, 384kbps and 64kbps in preference order.
Network policy at session setup does not allow for 2Mpbs, thus the
negotiation framework will try the next alternative and so on. Local
policy issues may be that a low end cellphone cannot run a high
complexity video + audio decoder in parallel due to restrictions in
hardware, thus it must skip a few potential configurations either for
audio or video or both.

In the same way one can argue that if network policies does not allow
RTP at session setup then this potential configuration will be sorted
out and the next potential confuration (CS) is tried instead.
 
/Ingemar 

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: den 7 april 2008 09:54
To: Ingemar Johansson S
Cc: Simo Veikkolainen; Flemming Andreasen; [email-masked]
Subject: Re: [MMUSIC] Preference of potential over actual configurations
inSDP cap-neg

Hi Ingemar:

     negotiation by using the most preferred potential configuration
that

in the previous text.

/Miguel

Ingemar Johansson S wrote:
> Hi
> 
> Not sure that I follow the discussion and what the problem actually 
> is, but wouldn't an SDP offer like the below solve this issue ?
> 

> m=audio 49999 RTP/AVP 0 c=IN IP4 10.0.0.1
> a=tcap:1 RTP/AVP CS
> a=ccap:1 IN xxxxx
> a=ccap:2 CS xxxxx
> a=pcfg:1 t=1 c=1
> a=pcfg:2 t=2 c=2
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Miguel Garcia
> Subject: Re: [MMUSIC] Preference of potential over actual 
> configurations inSDP cap-neg
> 
> Simo Veikkolainen wrote:
>> See below.
>>

> The requirement for the CS draft is either not having any preference 
> (it is a local implementation decision of the answerer) or if there is

> a preference, it has to be explicitly written in the SDP. The current 
> text that Simo just quoted mandates an implicit preference. This 
> implicit preference works nicely for offering RTP and SRTP, where the 
> alternative
> compatibility. The alternative (a CS bearer) is typically less 
> preferred than RTP.
> 
> So, we either remove preferences from the SDP Capability Negotiation 
> or we explicitly signal them.
> 
> /Miguel
> 
> 
>> -Simo
>>
>>> -- Flemming
>>>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 Apr 2008 12:16:58 +0300

Inline.

> attempt to" does not in my mind mean "MUST use". 

Well, this is the key question. I don't know that "MUST attempt" means. 
Further more, the fact that the verb is "attempt", does not seem to have 
an impact on the protocol design. I am thinking whether this is really a 
MUST, or it is something like a "SHOULD", and then indicate that policy, 
configuration, user preferences, etc,. may constitute exceptions to the 
SHOULD strength.

> hardware, thus it must skip a few potential configurations either for

I agree with you.

> out and the next potential confuration (CS) is tried instead.

Right. I think this reinforces my complain on the MUST strength.

/Miguel

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 09 Apr 2008 17:28:55 -0400

I believe MUST strength is correct, but agree that the "attempt" part is 
less than clear. How about we change it to:

For each media description where capability negotiation is to be 
performed (i.e. all required capability negotiation extensions are 
supported and at least one valid potential configuration attribute is 
present), the answerer MUST perform capability negotiation by using the 
most preferred potential configuration that is valid to the answerer, 
subject to any local policies.

-- Flemming

Miguel Garcia wrote:
>> Perhaps I am making things too simple but this is the way I see it. I 
>> see no reason to why local or network policy would not play a role in
> Well, this is the key question. I don't know that "MUST attempt" 
> means. Further more, the fact that the verb is "attempt", does not 
> seem to have an impact on the protocol design. I am thinking whether 
> this is really a MUST, or it is something like a "SHOULD", and then 
> indicate that policy, configuration, user preferences, etc,. may 
> constitute exceptions to the SHOULD strength.
>
>>
>> From: Miguel Garcia [mailto:[email-masked]] Sent: den 7 april 
>> 2008 09:54
>> To: Ingemar Johansson S
>>>>>> draft-ietf-mmusic-sdp-capability-negotiation-08 this does not 
>>>>>> seem to be possible. From Section 3.6.1 of SDP cap neg:
>>>>>>
>>>>>> potential configuration describes a circuit-switched stream 
>>>>>> (using media capabilities as defined in
>>>>> This would wreak havoc on the current structure since the 
>>>>> potential configuration number is also an indicator of the 
>>>>> preference, and we need uniqueness among the potential 
>>>>> configuration numbers.
>>>>>
>>>>> Taking a step back though, I'm not following why it is important 
>>>>> to be able to specify the same preference among two alternatives 
>>>>> as opposed to different ones. At the end of the day, if the 
>>>>> recipient supports only one of them, he can choose that one. If he 
>>>>> supports both of them, then what difference does it make (if he 
>>>>> truly has a preference, nothing can prevent him from choosing the 
>>>>> one he actually
>>> wants) ?
>>> a preference, it has to be explicitly written in the SDP. The 
>>> current text that Simo just quoted mandates an implicit preference. 
>>> This implicit preference works nicely for offering RTP and SRTP, 
>>> where the alternative

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 09 Apr 2008 17:48:21 -0400

Miguel Garcia wrote:
>>>> For our use case it would be helpful to be able to define actual 
>>>> and potential configurations with equal preference, or multiple 
>>> preference, nothing can prevent him from choosing the one he 
>>> actually wants) ?
>>
> a preference, it has to be explicitly written in the SDP.
Again, I think this distinction is rather subtle and given the severe 
impact it would have on the current structure, I'd rather not change to 
allowing for equal preferences.

> The current text that Simo just quoted mandates an implicit preference. 
In what way ?
> This implicit preference works nicely for offering RTP and SRTP, where 
> the alternative (SRTP) is always preferred, but might not be supported.
>
They are signalled explicitly already - from Section 3.5.1:
<quote>
   The potential configuration attribute can be provided at the media-
   level only and there can be multiple instances of it within a given
   media description. The attribute includes a configuration number,
   which is an integer between 1 and 2^31-1 (both included). The
   configuration number MUST be unique within the media description
   (i.e. it has media level scope only). The configuration number also
   indicates the relative preference of potential configurations; lower
   numbers are preferred over higher numbers. Consecutive numbering of
   the configuration numbers in different "pcfg" attributes in a media
   description is not required.
</quote>

The one exception is the actual configuration, which implicitly always 
has the lowest preference. However, there is a way to get around that - 
again from Section 3.5.1:
<quote>
   A potential configuration list is normally provided after the
   configuration number. When the potential configuration list is  
   omitted, the potential configuration equals the actual
   configuration.
</quote>

Does this address your concerns ?

-- Flemming

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 10 Apr 2008 09:31:41 +0300

The text you suggested is fine. Thanks.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 10 Apr 2008 09:36:20 +0300

Below

> Does this address your concerns ?

Yes. Once we learned that the trick is repeating the actual 
configuration as a potential configuration, then we can allocate a lower 
preference to that one.

/Miguel