Subject: [MMUSIC] Grouping m= lines for alternatives

From: Joerg Ott <[email-masked]>
Date: Fri, 05 Aug 2005 10:51:30 +0200

Folks,

we made a remark in the sttaus overview of the MMUSIC session
this week that I would like to send to the list:

Presently, with RFC3388, we have the basis for a grouping
mechanisms for m= lines in SDP in place.  This is being
used for lipsync (LS) and flow identification (FID),
for alternative address types (ANAT, RFC4091), and for FEC.

We came across another need for grouping: we may need to
indicate that two streams are alternatives to each other,
e.g., use alternative RTP profiles.  This is conceptually
similar to ANAT in that only one alternative will actually
be chosen but the sematics apparently differ.

Presently, SDP provides some text that allows for implicit
description of alternatives if and only if the same transport
addresses are used for both.  This was included in SDP to
document some current practice (previously only described in
the offer-answer-examples draft).

--------------------------------------------------------------------
[excerpt from sdp-new-25]

   The combination of ports specified in "m=" lines and IP addresses
   specified in "c=" lines MUST comply with the following rules for
   RTP-based media streams (other protocols SHOULD define similar
   rules):

   1.  If two media sessions have the same transport address (i.e.
       identical IP address and port numbers), the associated payload
       types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be in
       conflict, i.e. the same payload type MUST NOT be mapped to
       different media types.

   2.  If two media sessions have the same transport address, they
       MUST use compatible media (e.g. both audio or both video).

   3.  If two media sessions have the same transport address, they
       SHOULD operate under the same RTP profile.  The sessions MAY
       use two different RTP profiles only if those profiles are
       specifically designed to be compatible.

   4.  If two media sessions have the same RTP transport address,
       they MUST also use the same RTCP address and vice versa.

   Two media sessions with the same transport address indicate
   alternatives for the same media stream, i.e. all profiles, media
   types, and payload types provided in any of the "m=" lines are
   valid.
-------------------------------------------------------------------

It would be nicer to provide the desired semantics explicitly
and use the grouping mechanism to indicate alternatives.  Rather
than limiting this to alternative profiles it would be nicer
to go for a solution that can cover also other scenarios that
may come up.

Therefore this simply poll: anybody who is aware of other
requirements for signaling strict alternatives in SDP, please
send mail to the list.

Thanks,
Joerg

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

---

From: "Anders Klemets" <[email-masked]>
Date: Mon, 8 Aug 2005 14:04:43 -0700

> requirements for signaling strict alternatives in SDP, please

It would be nice to be able to specify that media descriptions differ
only based on their bit rate (i.e, b=AS and/or b=TIAS).

It would also be nice to be able to specify that media descriptions
differ based on the language used in the stream (a=lang).

Anders

---

From: [email-masked]
Date: Tue, 9 Aug 2005 13:59:01 +0300

For offering of scalable video stream alternatives in SDP, in addition
to bitrate, at least frame rate (for temporal scalability) and frame
size (for spatial scalability) may also differ. Are there any other SDP
ways to offer scalable streams than using the alternative mechanism?

Regards,
Ye-Kui Wang,
Nokia

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Anders Klemets
>Sent: 09 August, 2005 00:05
>To: Joerg Ott; [email-masked]
>Subject: RE: [MMUSIC] Grouping m= lines for alternatives
>
>
>requirements 
>> for signaling strict alternatives in SDP, please send mail to the 
>> list.
>
>It would be nice to be able to specify that media descriptions 
>differ only based on their bit rate (i.e, b=AS and/or b=TIAS).
>
>It would also be nice to be able to specify that media 
>descriptions differ based on the language used in the stream (a=lang).
>
>Anders
>
>