Subject: [MMUSIC] RFC 6190 Single Session Transport

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jun 2013 10:20:21 -0700

At the virtual interim, a question arose about RFC 6190 Single Session Transport. 
Here is what RFC 6190 Section 1 says:
   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions. Section 1.2.2 clarifies the usage scenarios of SST and MST: 
   SST should be used in point-to-point unicast applications and, in
   general, whenever the potential benefit of using multiple RTP
   sessions does not justify the added complexity...  

   MST should be used in a multicast session when different receivers
   may request different layers of the scalable bitstream.  Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both peers support BUNDLE, since otherwise distinct RTP ports would be required for each layer, which is incompatible with SST.    Today, existing SST implementations typically utilize a single m line.  As Jonathan noted, some implementations utilize the same SSRC for multiple layers, while others utilize distinct SSRCs.  Utilization of the same SSRC is possible, since separation of the layers can be handled within the H.264/SVC implementation.

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Jun 2013 12:32:46 -0500

On 6/17/13 12:20, Bernard Aboba wrote:
> Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both peers support BUNDLE, since otherwise distinct RTP ports would be required for each layer, which is incompatible with SST.

I don't think that assertion has a basis in reality, but I could simply 
be misunderstanding what you're trying to say.

English is imprecise, and it's clear that we're not having a meeting of 
minds here. Let's try a different language. You send an e-mail to the 
list containing the SDP currently exchanged by SIP endpoints for SST. 
I'll send SDP in an e-mail reply that shows how it works under Plan A.

Sound good?

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 17 Jun 2013 18:38:54 +0000

My understanding of 6190 SST is a single SSRC for all layers, not multiple SSRCs (one per layer) within one RTP session. 6190 doesn't state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how receivers put packets into decoding order from multiple streams based on timestamps or Cross-Session Decoding Order Numbers (CS-DON).

I think you may be referring to the common industry practice of MST using the same port and thus the same RTP session, i.e. Multi-SSRC (rather than Session) Transmission. That is not standardized in 6190, but often used in practice. This often uses a single m-line, so it has no BUNDLE dependency. If it used multiple m-lines, your argument would be true for that case. BUNDLE (or some similar mechanism to mux m-lines onto one port) would be required for that type of MST to use the same port. But that does not seem to be a limitation of Plan A, since some mux mechanism is always required to do that type of MST regardless of Plan A.

Mo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, June 17, 2013 1:20 PM
To: [email-masked]
Subject: [MMUSIC] RFC 6190 Single Session Transport

   scalability layers are transported on different RTP sessions.

Section 1.2.2 clarifies the usage scenarios of SST and MST:

   may request different layers of the scalable bitstream.

Today, existing SST implementations typically utilize a single m line.  As Jonathan noted, some implementations utilize the same SSRC for multiple layers, while others utilize distinct SSRCs.  Utilization of the same SSRC is possible, since separation of the layers can be handled within the H.264/SVC implementation.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jun 2013 11:40:10 -0700

> list containing the SDP currently exchanged by SIP endpoints for SST. 
[BA] Several examples are provided in RFC 6190 Section 7.3. 
Section 7.3.1:  Offer of both H.264/AVC and H.264/SVC on the same m-line.Section 7.3.2:  Offer of H.264/SVC with a single payload type. Section 7.3.5:  Offer of H.264/SVC with multiple payload types, supporting differing levels and packetization modes. 
Note that none of the examples use either a=ssrc or multiple m lines to describe the layers. 
> I'll send SDP in an e-mail reply that shows how it works under Plan A.

[BA] OK.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 17 Jun 2013 15:34:12 -0400

This was certainly my understanding of RFC 6190 as well, from heavy participation in its standardization in AVT.

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.

On Jun 17, 2013, at 2:38 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

My understanding of 6190 SST is a single SSRC for all layers, not multiple SSRCs (one per layer) within one RTP session. 6190 doesn’t state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how receivers put packets into decoding order from multiple streams based on timestamps or Cross-Session Decoding Order Numbers (CS-DON).

Mo

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernard Aboba
Sent: Monday, June 17, 2013 1:20 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] RFC 6190 Single Session Transport

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

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