Subject: Re: [MMUSIC] Question about bundling SDP m=lines

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 08 Nov 2006 03:19:52 +0200

Hi,

yes, it would be good to know whether folks have more requirements that 
could be met by a general solution. Can anybody think of additional use 
cases where SDP descriptions need to carry constrains (e.g., do not 
accept this SDP unless you accept stream 1 and 3).

Cheers,

Gonzalo

Paul Kyzivat wrote:
> This seems to be one more example of a whole family of cases where SDP 
> and offer/answer aren't sufficient to state the criteria desired for a 
> call. Other examples are:
> - several codecs can be supported but only one at a time, so any
>   answer listing more than one codec is unacceptable. (Unless of
>   course there are two and one of them is telephone-events.)
> 
> - I'd like an audio call or a fax call, but not both
> 
> One solution to this is to come up with a new notation to express each 
> new kind of constraint, and add it to SDP.
> 
> Another possible solution might be to use an attribute to characterize 
> media streams as "required" or "optional", with the expectation that a 
> call should not be completed unless the "required" streams can be 
> established.
> 
> Yet another possible solution is to use preconditions. I haven't thought 
> out the details, but it seems it would be possible to define a 
> precondition type related to media sufficiency. This would delay 
> alerting while the offerer gets to see the initial answer. At that point 
> the offerer can call things off if the answer isn't sufficient. This 
> would avoid the need to express all possible types of constraints, 
> reducing it to a case of "I'll know if its good when I see it".
> 
> Unfortunately, it seems that use of preconditions has not caught on. So 
> this kind of solution isn't likely to be very popular.
> 
>     Paul
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> yes, you could use the grouping framework to group a few streams 
>> together so that they should be accepted or rejected as a group. As 
>> you point out, none of the current 'semantics' does this. Therefore, 
>> you would need to define new 'semantics' for the framework.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> [email-masked] wrote:
>>> Folks,
>>>
>>> I hope I would like to ask an question on SDP offer/answer model.
>>>
>>> Imagine the case where the offerer initiates a video call.
>>> Is there any parameter which indicates offerer doesn't want
>>> answerer to answer an SDP with video medium only,
>>> without an audio medium?
>>>
>>> An SDP offer for video call includes two m=lines, m=audio and 
>>> m=video. According to RFC4566/3264, the answerer may read
>>> each m=line independently, and may return a SDP answer
>>> with port 0 in either of the two m=lines.
>>> Session may be established with video only, without audio,
>>> which is not the caller's intention.
>>>
>>>   offerer                             answerer
>>>      |                                  |
>>>      | INVITE (m=video & m=audio)       |
>>>      |--------------------------------->|
>>>      | 200 OK (m=video & m=audio port 0)|
>>>      |<---------------------------------|
>>>      |     RTP session (video only)     |
>>>      |<================================>|
>>>      |                                  |
>>>
>>> To avoid this, offerer have to tell the answerer that
>>> m=audio and m=video are bundled and that it doesn't
>>> want to establish with either of the media.
>>>
>>> I hope I would like to ask you how to express the offerer's intention.
>>>
>>> I guess this should be achived by m=line group attribute
>>> defined by RFC3388, because it says in Chapter 1 that "expression of 
>>> how different media streams within a session description relate to 
>>> each other." I guess that this would make it possible to express
>>> that m=audio and m=video are bundled.
>>>
>>> What the "semantics" field should be set, if I use a group attribute 
>>> in this way? Four values, "LS", "FID", "SRF" and "ANAT" are 
>>> registered on IANA,
>>> but none of them seems to be intended to influence UA's offer/answer.
>>> Is a new semantics parameter needed to meed the requirement?
>>>
>>> Please let me know your advice.
>>>
>>> Does this topic match to another mailing list more?
>>> I apologize if this subject is off-topic for this mailing list.
>>>
>>> Thank you,
>>> Jun Koshiko
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
> 

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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 08 Nov 2006 13:08:52 -0500

There is some potential overlap here with the SDP capability negotation 
work (draft-andreasen-mmusic-sdp-capability-negotiation-01.txt). Support 
of codecs as alternatives on a per media stream basis is part of that 
framework, however inter-media stream constraints are not. Examples of 
those would be media stream dependencies as well as constraints on codec 
combinations between media streams. Also, mandatory and optional 
capabilities are declared out of scope. In the interest of managing 
complexity, I'm quite happy with keeping the scope that way, and 
consider use of the grouping framework here instead, however it's 
probably important to understand all of the requirements in this space 
to make sure we draw the line the right place.

-- Flemming

Gonzalo Camarillo wrote:

> Hi,
>
> yes, it would be good to know whether folks have more requirements 
> that could be met by a general solution. Can anybody think of 
> additional use cases where SDP descriptions need to carry constrains 
> (e.g., do not accept this SDP unless you accept stream 1 and 3).
>
> Cheers,
>
> Gonzalo
>
> Paul Kyzivat wrote:
>
>> This seems to be one more example of a whole family of cases where 
>> SDP and offer/answer aren't sufficient to state the criteria desired 
>> for a call. Other examples are:
>> One solution to this is to come up with a new notation to express 
>> each new kind of constraint, and add it to SDP.
>>
>> Another possible solution might be to use an attribute to 
>> characterize media streams as "required" or "optional", with the 
>> expectation that a call should not be completed unless the "required" 
>> streams can be established.
>>
>> Yet another possible solution is to use preconditions. I haven't 
>> thought out the details, but it seems it would be possible to define 
>> a precondition type related to media sufficiency. This would delay 
>> alerting while the offerer gets to see the initial answer. At that 
>> point the offerer can call things off if the answer isn't sufficient. 
>> This would avoid the need to express all possible types of 
>> constraints, reducing it to a case of "I'll know if its good when I 
>> see it".
>>
>> Unfortunately, it seems that use of preconditions has not caught on. 
>> So this kind of solution isn't likely to be very popular.
>>
>>     Paul
>>
>> Gonzalo Camarillo wrote:
>>
>>> Hi,
>>>
>>>> defined by RFC3388, because it says in Chapter 1 that "expression 
>>>> of how different media streams within a session description relate 
>>>> to each other." I guess that this would make it possible to express
>>>> What the "semantics" field should be set, if I use a group 
>>>> attribute in this way? Four values, "LS", "FID", "SRF" and "ANAT" 
>>>> are registered on IANA,

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Nov 2006 14:08:08 -0500

Flemming,

I was going to make my own comment that this discussion was starting to 
overlap with some of those others, but I never got around to it.

I agree with you that there are a bunch of requirements and mechanisms 
being discussed, and that while we probably need more than one mechanism 
to support all the requirements the number needed is probably less than 
what has been proposed.

	Paul

---

From: "Dostal, Pavel" <[email-masked]>
Date: Mon, 13 Nov 2006 13:02:08 +0100

Hi,

An additional use case of the media type constrains is to ensure that
after multiparty multimedia SIP session set up done according RFC4353
all the session participants share common media types.

Let's consider the following use case:

A user (user A) would like to show a holiday clip (audio and video) with
subtitles (text messaging) to his friends (user B and C). The holiday
clip (audio and video) is important for the user A while the subtitles
(text messaging) are only nice to have.

Without the dependencies, the inviting user (user A) initiates a SIP
session (as in RFC4353) with SDP offer containing multiple media types
(m=audio, m=video, m=message) to multiple invited users (user B and C).
Each invited user can accept any combination of the offered media types.
Let's say user B accepts audio and video only (e.g. user B does not have
display big enough for the subtitles) and user C accepts text messaging
only (e.g. because user C is at a meeting and configured his client not
to accept anything apart from text messaging). So although the user A
wanted to show a holiday clip (audio and video) to both his friends,
user A can only show the audio and video part to the user B and
subtitles to the user C. The result is not what the user A originally
expected - possibility to show a holiday clip (audio and video) with
subtitles (text messaging) to user B and C. Also in this configuration,
although that all tree users are connected to one multiparty multimedia
session, user C can not communicate with user B directly (only via user
A), because they do not share any common media.
 
To prevent such case, the inviting user should be able to define the
dependencies between the offered media types. The inviting user (user A)
would state that
- audio mandatory depends on video, and
- video mandatory depends on audio, and
- message mandatory depends on video, and      
- video optionally depends on message.
Since the dependencies must be honored by the invited users, the invited
users (user B and user C) can accept the session only when they accept
both audio and video, accepting of the subtitles (text messaging) is
optional. Given the user B and user C conditions above, the session is
set up only with user B, user C was busy.

Regards,

Pavel

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 2:20 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] Question about bundling SDP m=lines

Hi,

Cheers,

Gonzalo

> Yet another possible solution is to use preconditions. I haven't
thought 
> alerting while the offerer gets to see the initial answer. At that
point 
> Unfortunately, it seems that use of preconditions has not caught on.
So

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 13 Nov 2006 15:06:40 +0200

Pavel,
Your description is one way to address the issue.

RFC4353 talks about central conferencing. So the conference server is in
charge of the conference mode. The conference server establishes a
signaling connection with each participant, in this case A, B, C.
If the conference mode defines that all participants must have all media
to join than the conference server will not connect parties that could
not support all the media. 

In your example you would like party A to be the central point. I assume
it can use caller preferences (RFC3841 & RFC4596) or to use the Option
method to find which media can be used.

Roni Even

> From: Dostal, Pavel [mailto:[email-masked]]
> Sent: Monday, November 13, 2006 2:02 PM
> To: Gonzalo Camarillo; [email-masked]
> Subject: RE: [MMUSIC] Question about bundling SDP m=lines
> 
> Hi,
> 
that
> > This seems to be one more example of a whole family of cases where
SDP
> > One solution to this is to come up with a new notation to express
each
> > Another possible solution might be to use an attribute to
characterize
> >>> defined by RFC3388, because it says in Chapter 1 that "expression
of
> >>> What the "semantics" field should be set, if I use a group
attribute
> >>> I apologize if this subject is off-topic for this mailing list.
************************************************************************
**
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
************************************************************************
**
> **********

---

From: "Dostal, Pavel" <[email-masked]>
Date: Wed, 15 Nov 2006 21:27:57 +0100

Roni,

The idea described bellow is based on using conference server.  The
conference server establish the conference with user B and C on behalf
of user A. The user A needs to have the possibility to inform the
conference server that other users can join the conference only if they
support at least audio and video.
Media type constrains may allow configuration where all conference
participants share at least one common media that can be used for
communication among all of them. For example if all media types in the
multimedia conference depend on audio, every conference participant must
support audio but some of them can in addition support video, messaging
or any other media type. If you want to provide some information to all
conference participants you have to use audio and it is sure that each
conference participant receives the information. 
In my opinion this cannot be done using only caller preferences.

Regards,
Pavel

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 2:07 PM
To: Dostal, Pavel; Gonzalo Camarillo; [email-masked]
Subject: RE: [MMUSIC] Question about bundling SDP m=lines

Pavel,

Roni Even

that
SDP
each
characterize
of
attribute
computer

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 19 Nov 2006 17:06:10 +0200

Pavel,
This is not a SDP issue. Typically when you create an ad-hoc conference
the policy for the conference is pre-defined on the conference server.
Another method would be to use a protocol to the conference sever like
the one developed at XCON.
Roni

> Sent: Wednesday, November 15, 2006 10:28 PM
> To: Even, Roni; [email-masked]
> > dependencies between the offered media types. The inviting user
(user
> A)
> > > and offer/answer aren't sufficient to state the criteria desired
for
> a
> > > media streams as "required" or "optional", with the expectation
that
> a
computer

---

From: "Dostal, Pavel" <[email-masked]>
Date: Thu, 23 Nov 2006 15:14:52 +0100

Roni,

The RFC4353 defines a framework for conferencing with the SIP where
offer/answer model is used for media negotiation. The ad-hoc conference
(short-lived) is not pre-defined and so there is no appropriate policy
to be used. According to this framework, the client can also send a
REFER request to the focus, asking it to send an INVITE to the
participant that should be added into the conference. For this I see
possible need for mechanism how to define media dependencies in the SDP.

E.g. if multiple media types (X,Y,Z) are used in the ad-hoc conference
and a new user is invited by a session participant using REFER, the
focus offers in the INVITE to the invited participant the used media
types. 
Let's say that the two users B and C are invited.

If SDP offer in INVITE sent to invited user does not include media types
dependencies, the invited user may accept any combination (X, Y, Z, X&Y,
X&Z, Y&Z, X&Y&Z) of the offered media types. User B may accept media
type X only and user C may accept media type Y only. Thus, the users B
and C will not be able to communicate with each other.

If SDP offer in INVITE includes media types with media types
dependencies, the offer would contain the media type dependencies (Y
only with X, Z only with Y) and invited user may accept only allowed
combination (X, X&Y, X&Y&Z) of the offered media types (or reject the
INVITE). Thus, all the users will be able to communicate with each other
at least using media type X.

I tried to find the solution in XCON documents but according to the
draft-ietf-xcon-framework-05 "The details of the conference control
protocol are provided in separate documents [references TBD]." Any idea
how the dependencies can be used in case of dial out conferences?

Pavel 

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, November 19, 2006 4:06 PM
To: Dostal, Pavel; [email-masked]
Subject: RE: [MMUSIC] Question about bundling SDP m=lines

Pavel,

(user
for
that
computer