Subject: [MMUSIC] New ID, related to media stream dependencies

From: "Schmidt, Christian" <[email-masked]>
Date: Fri, 19 Jan 2007 13:03:33 +0100

> Dear editor,
> 
> we would like to submit a new  Internet Draft related to work in the
> MMUSIC  Working Group (although it is not an official product of the WG).
> 
> >  <<draft-schmidt-mmusic-media-dependency-00.txt>> 
> 
> Abstract:
> The Session Description Protocol (SDP) was intended for describing
> multimedia sessions for the purposes of session announcement, session
> invitation, and other forms of multimedia session initiation.
> Together with Offer/Answer model it defines a mechanism, how two
> entities can reach a common view of a multimedia session between
> them.
> 
> In certain cases, there are dependencies between media streams, for
> example a text stream for subtitling make sense only together with a
> video stream.  To avoid senseless connections, the SDP mechanism can
> be extended with a new Session Description Protocol (SDP) media-level
> attribute: "dependency".  The "dependency" attribute allows the
> offerer to define dependencies of media streams.  The updated offer/
> answer mechanism used with new "dependency" attribute can be used
> furthermore, that in a multi-party SIP session all participants share
> at least one common media type. 
> 
> Mit freundlichen Grüßen
> Christian Schmidt
> 
> Siemens Networks GmbH & Co. KG
> St.-Martin-Str. 76
> 81541 München, Germany
> Tel.: +49 89 636-75192
> Fax: +49 89 636-75577
> [email-masked]
>  
> Siemens Networks GmbH & Co. KG
> Geschäftsführer: Joachim Malterer, Roland Meinzer, Christian Unterberger
> Sitz der Gesellschaft: München
> Registergericht: München, HRA 88537
> WEEE-Reg.-Nr. DE 52984304
> Persönlich haftende Gesellschafterin: Siemens Networks Management GmbH
> Sitz der Gesellschaft: München
> Registergericht: München, HRB 163416
>  
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 19 Jan 2007 10:40:38 -0800

(removed internet-drafts from CC list.)

Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same
functionality?

-d

> -----Original Message-----
> From: Schmidt, Christian [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 4:04 AM
> To: [email-masked]
> Cc: MMusic; Joerg Ott
> Subject: [MMUSIC] New ID, related to media stream dependencies
> 
> Dear editor, 
> 
> [email-masked] <mailto:[email-masked]>  
>

---

From: "Robert R. Gilman" <[email-masked]>
Date: Fri, 19 Jan 2007 16:15:59 -0700

Dan-
As it stands now, the capneg definitions don't support that.  Requirements 150
and 160 of the requirements draft say:

         REQ-150: It SHOULD be possible to specify valid combinations of media
         lines.

            For example, an entity may be able to support audio and video or
            audio and IM, but not video and IM (or all three).

         REQ-160: It SHOULD be possible to specify valid combinations of media
         formats between media streams.

            For example, there may be constraints on which combinations of
            audio and video codecs can be supported.

I've been thinking about some session-level constraints that might be used
for REQ-160.  For example, one might define a ccons: attribute that
listed acceptable combinations of codecs - I was considering the processing-
power constraints between specific codecs (e.g., codec a1 and codec v1 or
codec a2 and codec v2).  Christian's goal is described by REQ-150 - making
sure the responder doesn't do something silly like open a subtitles stream
with no video stream.  In that particular case, it's not clear to me that
the responder wouldn't know better even without the constraint from the
offeror.  On the other hand, it would be nice to be able to say "I'll take
audio without the video" or "Don't give me audio without the video" - so the 
problem doesn't go away.  IIRC, we made these requirements "SHOULD" rather
than "MUST" because we weren't sure if anyone needed or used them at present.

I'll remind folks that the next meeting of the capability negotiation group
is Tues, January 23 at 1000 Eastern Standard Time.  We expect to discuss
some of the configuration proposals that have been put forward, and we can
also discuss the constraints between streams.
The bridge info is:
	US toll free: 866-902-7870 (outside the 408 area code.)
	everywhere else: +1 408 902 7870
	meeting ID: 737227634
All interested parties are invited to attend.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Schmidt, Christian" <[email-masked]>
Date: Mon, 22 Jan 2007 13:43:14 +0100

Hi Robert and Dan,
 
the example with the subtitle may be not the best one, but I can imagine cases, where the offerer has dependency information, not available to the receiver. For example in case of media streaming, the key for decryption could be send via instant messaging. In this case, the offerer can provide this information via dependency attribute. The receiption of video media without the proper decryption information would make no sense. 
 
Furthermore, a possible application for the dependency attribute could be used for the selection of mendatory media streams, all participants of a conference are able to share.
 
The dependency information can be seen as capability negotiation, therefore it would make sense to include it to the current activites for capability negotation. What do you think? The related requirement could look like:
 
REQ-155: It SHOULD be possible to specify dependencies between media lines, based on the decision of the offerer. The receiver should accept media lines only if he is willing and able to accept all mandatory dependent media lines as well. This could avoid redundant call attempts and for example increase interoperability in conferences.
 
On Tuesday, I will try to attend the planned confcall.

Best Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: Robert R. Gilman [mailto:[email-masked]] 
Gesendet: Samstag, 20. Januar 2007 00:16
An: Dan Wing
Cc: Schmidt, Christian; 'MMusic'
Betreff: Re: [MMUSIC] New ID, related to media stream dependencies

Dan-

---

From: "Robert R. Gilman" <[email-masked]>
Date: Mon, 22 Jan 2007 10:00:20 -0700

Christian-
I interpret REQ-150 to include your REQ-155.  For example, if 'a' and 'b' are
media streams, then the valid combinations might be a+b and a, which would
exclude "b without a".  Also, remember that either party may wish to express
dependencies, especially for latent capabilities.
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

Schmidt, Christian wrote:
> 
> Hi Robert and Dan,
> 
> the example with the subtitle may be not the best one, but I can imagine
> cases, where the offerer has dependency information, not available to the
> receiver. For example in case of media streaming, the key for decryption
> could be send via instant messaging. In this case, the offerer can provide
> this information via dependency attribute. The receiption of video media
> without the proper decryption information would make no sense.
> 
> Furthermore, a possible application for the dependency attribute could be
> used for the selection of mendatory media streams, all participants of a
> conference are able to share.
> 
> The dependency information can be seen as capability negotiation, therefore
> it would make sense to include it to the current activites for capability
> negotation. What do you think? The related requirement could look like:
> 
> REQ-155: It SHOULD be possible to specify dependencies between media lines,
> based on the decision of the offerer. The receiver should accept media lines
> only if he is willing and able to accept all mandatory dependent media lines
> as well. This could avoid redundant call attempts and for example increase
> interoperability in conferences.
> 
> Best Regards Christian Schmidt
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht----- Von: Robert R. Gilman
> [mailto:[email-masked]] Gesendet: Samstag, 20. Januar 2007 00:16 An: Dan Wing 
> Cc: Schmidt, Christian; 'MMusic' Betreff: Re: [MMUSIC] New ID, related to
> media stream dependencies
> 
> Dan- As it stands now, the capneg definitions don't support that.
> Requirements 150 and 160 of the requirements draft say:
> 
> REQ-150: It SHOULD be possible to specify valid combinations of media lines.
> 
> For example, an entity may be able to support audio and video or audio and
> IM, but not video and IM (or all three).
> 
> REQ-160: It SHOULD be possible to specify valid combinations of media formats
> between media streams.
> 
> For example, there may be constraints on which combinations of audio and
> video codecs can be supported.
> 
> for REQ-160.  For example, one might define a ccons: attribute that listed
> acceptable combinations of codecs - I was considering the processing- power
> constraints between specific codecs (e.g., codec a1 and codec v1 or codec a2
> and codec v2).  Christian's goal is described by REQ-150 - making sure the
> responder doesn't do something silly like open a subtitles stream with no
> video stream.  In that particular case, it's not clear to me that the
> responder wouldn't know better even without the constraint from the offeror.
> On the other hand, it would be nice to be able to say "I'll take audio
> without the video" or "Don't give me audio without the video" - so the 
> is Tues, January 23 at 1000 Eastern Standard Time.  We expect to discuss some
> of the configuration proposals that have been put forward, and we can also
> discuss the constraints between streams. The bridge info is: US toll free:
> 866-902-7870 (outside the 408 area code.) everywhere else: +1 408 902 7870 
> meeting ID: 737227634 All interested parties are invited to attend. -Bob 
> ---------------------------------------------------- Bob Gilman
> [email-masked]      +1 303 538 3868
> 
> Dan Wing wrote:
> 
>>> -----Original Message----- From: Schmidt, Christian
>>> [mailto:[email-masked]] Sent: Friday, January 19, 2007
>>> 4:04 AM To: [email-masked] Cc: MMusic; Joerg Ott Subject:
>>> [MMUSIC] New ID, related to media stream dependencies
>>> 
>>> Dear editor,
>>> 
>>> Abstract: The Session Description Protocol (SDP) was intended for
>>> describing multimedia sessions for the purposes of session announcement,
>>> session invitation, and other forms of multimedia session initiation. 
>>> Together with Offer/Answer model it defines a mechanism, how two entities
>>> can reach a common view of a multimedia session between them.
>>> 
>>> video stream.  To avoid senseless connections, the SDP mechanism can be
>>> extended with a new Session Description Protocol (SDP) media-level 
>>> attribute: "dependency".  The "dependency" attribute allows the offerer
>>> to define dependencies of media streams.  The updated offer/ answer
>>> mechanism used with new "dependency" attribute can be used furthermore,
>>> that in a multi-party SIP session all participants share at least one
>>> common media type.
>>> 
>>> Mit freundlichen Grüßen Christian Schmidt
>>> 
>>> Siemens Networks GmbH & Co. KG St.-Martin-Str. 76 81541 München, Germany
>>>  Tel.: +49 89 636-75192 Fax: +49 89 636-75577 
>>> Siemens Networks GmbH & Co. KG Geschäftsführer: Joachim Malterer, Roland
>>> Meinzer, Christian Unterberger Sitz der Gesellschaft: München 
>>> Registergericht: München, HRA 88537 WEEE-Reg.-Nr. DE 52984304 Persönlich
>>> haftende Gesellschafterin: Siemens Networks Management GmbH Sitz der
>>> Gesellschaft: München Registergericht: München, HRB 163416
>>> 
>>> 
>>> 
>> 
>> 
>> _______________________________________________ mmusic mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
>

---

From: "Schmidt, Christian" <[email-masked]>
Date: Tue, 23 Jan 2007 08:52:54 +0100

Bob

>For example, if 'a' and 'b' are
>exclude "b without a". 

Thats correct, it is the case, when b is mandatory dependent from a.

>I interpret REQ-150 to include your REQ-155.

Good point, the requirement should be extended to reflect this new feature:

"REQ-150: It SHOULD be possible to specify valid combinations of media lines.
Media lines in those combination can be optional or mandatory."

>Also, remember that either party may wish to express 

With the dependency attribute, this should be possible.

Regards Christian

-----Ursprüngliche Nachricht-----
Von: Robert R. Gilman [mailto:[email-masked]] 
Gesendet: Montag, 22. Januar 2007 18:00
An: Schmidt, Christian
Cc: Dan Wing; MMusic
Betreff: Re: AW: [MMUSIC] New ID, related to media stream dependencies

Christian-

---

From: Colin Perkins <[email-masked]>
Date: Sun, 28 Jan 2007 15:14:42 +0000

Christian,

Can you comment on how this relates to the work on signalling for  
layered codecs? draft-schierl-mmusic-layered-codec-02.txt

Colin

On 19 Jan 2007, at 12:03, Schmidt, Christian wrote:
> <draft-schmidt-mmusic-media-dependency-00.txt>

-- 
Colin Perkins
http://csperkins.org/