From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: AW: AW: How does mmt grouping work with multiple streams of the
 same type?
Thread-Index: AQHNp760LlzeyMAvekOpo0q27dYr2pe0Np8ngAAAnTA=
Date: Fri, 12 Oct 2012 07:58:01 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE120128C17C@MCHP04MSX.global-ad.net>
References: <F81CEE99482EFE438DAE2A652361EE120128BCF2@MCHP04MSX.global-ad.net>
 <5076CC50.7000103@alvestrand.no>
 <F81CEE99482EFE438DAE2A652361EE120128BD71@MCHP04MSX.global-ad.net>
 <5076DB5F.5030205@alvestrand.no>
 <F81CEE99482EFE438DAE2A652361EE120128BDAA@MCHP04MSX.global-ad.net>
 <5076E2AB.2070507@alvestrand.no>
In-Reply-To: <5076E2AB.2070507@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic WG <mmusic@ietf.org>,
 Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the
 same type?
Precedence: list

inline

> -----Urspr=FCngliche Nachricht-----
> Von: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Gesendet: Donnerstag, 11. Oktober 2012 17:16
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: AW: AW: How does mmt grouping work with multiple=20
> streams of the same type?
>=20
> On 10/11/2012 04:55 PM, Stach, Thomas wrote:
> > inline
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
> >> Gesendet: Donnerstag, 11. Oktober 2012 16:45
> >> An: Stach, Thomas
> >> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >> Betreff: Re: AW: How does mmt grouping work with multiple
> >> streams of the same type?
> >>
> >> On 10/11/2012 04:13 PM, Stach, Thomas wrote:
> >>> Harald,
> >>>
> >>> thanks for the reply.
> >>> It helps for my second question, but not for my main question.
> >>> How can the answerer recognize (from the m=3Danymedia line
> >> alone) that multiple video streams need to be set up in the
> >> same RTP session?
> >> If each video stream is signalled by the presence of=20
> SSRC-associated
> >> signalling for that video stream, you count the number of
> >> video streams signalled.
> > Could that be done by e.g. enhancing the new a=3Dmmtype with=20
> an ssrc element?
> > E.g.
> >
> >         a=3Dmmtype: 0 audio ssrc=3D1
> >         a=3Dmmtype: 8 audio ssrc=3D1
> >         a=3Dmmtype: 97 audio ssrc=3D2
> >         a=3Dmmtype: 31 video ssrc=3D3
> >         a=3Dmmtype: 32 video ssrc=3D4
> >
> > would mean 2 audio streams and 2 video streams, whereas
> >
> >         a=3Dmmtype: 0 audio ssrc=3D1
> >         a=3Dmmtype: 8 audio ssrc=3D1
> >         a=3Dmmtype: 97 audio ssrc=3D1
> >         a=3Dmmtype: 31 video ssrc=3D2
> >         a=3Dmmtype: 32 video ssrc=3D2
> >
> > means 1 audio and 1 video stream based on the number of=20
> different SSRCs?
>=20
> On the principle of "don't invent new stuff if you already=20
> have stuff",=20
> I think we should continue to use RFC 5576 for this purpose:
>=20
> a=3Dssrc:1 <something follows>

I haven't thought about that, but yes it would work for as well.
For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it would loo=
k like this?=20

   a=3Drtpmap:0 PCMU/8000
   a=3Drtpmap:8 PCMA/8000
   a=3Drtpmap:97 iLBC/8000
   a=3Dmmtype: 0 audio=20
   a=3Dmmtype: 8 audio=20
   a=3Dmmtype: 97 audio
   a=3Dssrc:12345 fmtp:0=20
   a=3Dssrc:12345 fmtp:8=20
   a=3Dssrc:67890 fmtp:97=20


>=20
> The suggestion above wouldn't work for the case of two SSRCs=20
> both using the same payload type.
Well it would if you duplicated the a=3Dmmtype attribute with different ssr=
c elements in that case.
     a=3Dmmtype: 0 audio ssrc=3D1
     a=3Dmmtype: 0 audio ssrc=3D2
Would you do something else for a=3Dssrc?



Regards
Thomas


>=20
> >
> >>> Regards
> >>> Thomas
> >>>
> >>>> -----Urspr=FCngliche Nachricht-----
> >>>> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
> >>>> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> >>>> An: Stach, Thomas
> >>>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >>>> Betreff: Re: How does mmt grouping work with multiple streams
> >>>> of the same type?
> >>>>
> >>>> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> >>>>> Christer, Harald, Jonathan,
> >>>>>
> >>>>> I have the impression that the
> >>>> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
> >>>> Jonathan's proposal
> >>>>> to have an explicit desrciption for the bundled streams as
> >>>> proposed in
> >>>>>=20
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >>>>>
> >>>>> Among other points the following is stated:
> >>>>> * The m=3Dbundle is a complete description of an entirely
> >>>> separate m-line; if it's used, the other m-lines in the group
> >>>> are rejected and the information they carry is ignored.
> >>>>> I think this a desirable property
> >>>>>
> >>>>> Now, consider a case were you have 4 streams, i.e. 4
> >>>> m-lines (e.g. 2 audio and 2 video).
> >>>>> How would that be mapped to the m=3Danymedia line?
> >>>>> How does mmt grouping work with multiple streams of the=20
> same type?
> >>>>>
> >>>>>    From the currently proposed syntax for the m=3Danymedia line
> >>>> I cannot deduce that multiple audio or video streams are offered.
> >>>>> I would have to look into the "legacy" m-lines to=20
> recognize this.
> >>>>> In case that e.g. the video stream use different codecs, I
> >>>> could also learn that only from the legacy m-lines.
> >>>>
> >>>> In the case where it's desirable to carry multiple video
> >>>> streams in one
> >>>> RTP session, and have different descriptions in SDP for
> >> the different
> >>>> video streams, there has to be some signalling that tells the
> >>>> recipient
> >>>> which description applies to which video stream.
> >>>>
> >>>> The video streams will have different SSRCSs. Therefore, the only
> >>>> reasonable answer in the MMT grouping case seems to be
> >>>> SSRC-associated
> >>>> signalling.
> >>>>
> >>>> In the other variants, it's actually unclear to me how the
> >>>> video streams
> >>>> described by the different m=3D lines would be detected by the
> >>>> recipients;
> >>>> I'd been assuming SSRC-associated signalling for other
> >>>> reasons, so only
> >>>> when this discussion resurfaced, I started thinking about
> >> this again,
> >>>> and discovered that I didn't have an answer.
> >>>>
> >>>> That is, in the description
> >>>>
> >>>> a=3Dgroup:bundle foo bar baz
> >>>> m=3Dvideo 4270
> >>>> a=3Dmid:foo
> >>>> a=3Dproperty-x:1
> >>>> m=3Dvideo
> >>>> a=3Dmid:bar
> >>>> a=3Dproperty-x:2
> >>>> m=3Dvideo
> >>>> a=3Dmid:baz
> >>>> a=3Dproperty-x:3
> >>>>
> >>>> one would expect a single RTP stream to be set up; when
> >> the recipient
> >>>> gets 3 video streams with SSRCS 234, 235 and 236, how does he
> >>>> know which
> >>>> stream should have which value for "property-x"?
> >>>> One can solve it with SSRC-associated signalling in this=20
> case too:
> >>>>
> >>>> a=3Dssrc:234 property-x:1
> >>>>
> >>>> but then you're back to doing SSRC-associated signalling, and
> >>>> if you're
> >>>> already doing that, we're not very different from the MMT
> >> description
> >>>> anyway.
> >>>>
> >>>> That's how I think of it at the moment, anyway - YMMV.
> >>>>
> >>>>
> >>>>
>=20
> =