Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

From: "Roni Even" <[email-masked]>
Date: Thu, 22 Aug 2013 12:05:13 +0300

Hi Jonathan,

Maybe if you want to use FEC only on the base layer and not on all layers.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Lennox
Sent: 19 July, 2013 5:54 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

On Jul 18, 2013, at 10:02 PM, Bernard Aboba <[email-masked]>
wrote:

Jonathan said: 

"I don't understand how single-session multi-source transmission will work
without either a) signaling "a=ssrc-group DDP" decoding dependencies, or b)
making various implementation-specific assumptions about the structure of
the SVC streams."
 
[BA] In terms of SDP choices for expressing layering within a single m line,
you can either go the a=ssrc-group:DDP route, or use distinct payload types
for each layer and RFC 5583 a=group:DDP (this is what "Unified Plan" Section
4.7 appears to advocate).  

I'm not sure how "MST within a single session" could be expressed in SDP
without BUNDLE.  Was the idea to use multiple m lines and group them
together but use the same port? 

I think the authors of RFC 6190 didn't see a use case for MST within a
single RTP session -- all of the interesting MST use cases they saw involved
separate transport flows for the separate layers, and if you're sending all
the layers on a single transport flow, SST is significantly simpler.

What requirement are you trying to achieve that's met by MST in a single
session, but not by SST?

--

Jonathan Lennox
[email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 22 Aug 2013 20:06:05 +0000

Selective forwarding of layers at a switch is simpler with MST versus SST, since SST requires rewriting timestamps and sequence numbers to drop layers. RTCP reporting per layer is another benefit of MST. These advantages stem from using multiple SSRCs independent of whether they use the same or separate transport flows.

I think the entire nomenclature of SST/MST should evolve to Single/Multiple SSRC (not Session) Transport, since that is really what matters. BUNDLE and UP make this evolution inevitable. Note that MST is already widely deployed this way, which is non-standard. So  updating the nomenclature would align with both current deployments and future standards like BUNDLE/UP.

Mo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Thursday, August 22, 2013 5:05 AM
To: 'Jonathan Lennox'; 'Bernard Aboba'
Cc: [email-masked]
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

Hi Jonathan,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 19 July, 2013 5:54 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

On Jul 18, 2013, at 10:02 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

Jonathan said:
"I don't understand how single-session multi-source transmission will work without either a) signaling "a=ssrc-group DDP" decoding dependencies, or b) making various implementation-specific assumptions about the structure of the SVC streams."

[BA] In terms of SDP choices for expressing layering within a single m line, you can either go the a=ssrc-group:DDP route, or use distinct payload types for each layer and RFC 5583 a=group:DDP (this is what "Unified Plan" Section 4.7 appears to advocate).

I'm not sure how "MST within a single session" could be expressed in SDP without BUNDLE.  Was the idea to use multiple m lines and group them together but use the same port?

I think the authors of RFC 6190 didn't see a use case for MST within a single RTP session -- all of the interesting MST use cases they saw involved separate transport flows for the separate layers, and if you're sending all the layers on a single transport flow, SST is significantly simpler.

What requirement are you trying to achieve that's met by MST in a single session, but not by SST?

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>