Subject: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC

From: "Roni Even" <[email-masked]>
Date: Thu, 15 Mar 2012 19:18:26 +0200

Hi,

I saw in section 3.2 a reference to RFC6190 about using same SSRC in
different RTP sessions. Can you point out where it is in RFC6190, I did not
see it.

Thanks

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Mar 2012 08:41:19 +0100

On 2012-03-15 18:18, Roni Even wrote:
> different RTP sessions. Can you point out where it is in RFC6190, I did
> not see it.

No, it is not present in the RFC. In fact the RFC fails to to discuss
how to bind together the media streams between the different RTP
sessions when using MST mode. However, my analysis is that using the
same SSRC is the only feasible approach as CNAME is insufficient if you
would have more than two media sources from the same end-point present
in the same RTP session.

Section 5.2 of
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/
do have some more argumentation around this problem and proposing the
srcname as fix that takes us away from that requirement.

I talked to Jonathan Lennox about this and he agreed that this is the
logical interpretation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Mar 2012 15:41:32 +0200

Hi Magnus,
I thought that RFC5583 is used to signal the media decoding dependency
between the different sessions as mentioned in section 7.2.3 of RFC 6190.
I also think that this allows you to provide also the SSRC value of the
different RTP streams.

Roni Even

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, March 16, 2012 9:41 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-
> 01 - same SSRC
> 
> > different RTP sessions. Can you point out where it is in RFC6190, I
> > did not see it.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Mar 2012 16:06:40 +0100

> I also think that this allows you to provide also the SSRC value of the

No, to my understanding RFC 5583 only defines how the media description
grouping to indicate which m= lines that contains dependent media. And
the a=depend SDP attribute links which RTP payload types in the
respective media descriptions. There is no linking of the SSRCs. So when
there is more than one SSRC with a given CNAME you have no other defined
method than to use the same SSRC value across sessions.

Cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Sat, 17 Mar 2012 11:10:06 +0200

Hi,
I will just address the SVC multiplexing issue and start a different thread
on the session and ssrc multiplexing and the relation between RTP session
and the transport infrastructure used which is also discussed in
draft-alvestrand-rtp-sess-neutral-00.

As for the SVC example in the document, I think that the reason for MST mode
is because the idea is to use the session multiplexing based on different
UDP ports to divide the streams, for example in multicast allowing the users
to join just the relevant multicast groups. IF you want SSRC multiplexing in
SVC you can use SST (Single Session Transmission) mode and I think this is
the reason there is no need to address SSRC multiplexing using multiple
sessions to a single UDP receive port is not discussed.

What I am saying is that the example in 3.2 is not correct since it was not
addressed on purpose being non relevant use for MST.
Roni Even

> Sent: Friday, March 16, 2012 5:07 PM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> > I also think that this allows you to provide also the SSRC value of
> > the different RTP streams.
> 
> respective media descriptions. There is no linking of the SSRCs. So
> when there is more than one SSRC with a given CNAME you have no other
> defined method than to use the same SSRC value across sessions.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Mar 2012 23:03:50 +0100

> sessions to a single UDP receive port is not discussed.

Yes, I agree that MST exist so that sets of scalability layers can be
distributed over multiple multicast groups so that each receivers can
join the appropriate number of multicast groups for them.

And the discussion in section 3.2 is in this context.

> addressed on purpose being non relevant use for MST.

Sorry,

I don't understand how you come to this conclusion. What section 3.2
says around SVC is:

      Inter-relation:  SSRC belonging to the same synchronization
         context (originating from the same end-point), within or
         between RTP Sessions, are indicated through use of identical
         SDES CNAME items in RTCP compound packets with those SSRC as
         originating source.  SDP signalling can provide explicit SSRC
         grouping [RFC5576].  When CNAME is inappropriate or
         insufficient, there exist a few other methods to relate
         different SSRC.  One such case is session-based RTP
         retransmission [RFC4588].  In some cases, the same SSRC
         Identifier value is used to relate streams in two different RTP
         Sessions, such as in Multi-Session Transmission of scalable
         video [RFC6190].

What is says is that in MST there exist cases where CNAME clearly isn't
enough to make the binding between the SSRC in the different RTP session
on the differnet multicast groups. CNAME is not sufficient if multiple
video sources are sent from the same synchronization context.

Thus something additional mechanism is required. My claim is that RFC
6190 is relying on using the same SSRC value in the different RTP
Session being used to transmit the different scalability layers. However
this is not documented in the RFC.

Please don't mix SST into this case as it is not what we are talking about.

Cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Tue, 20 Mar 2012 09:30:26 +0200

Hi Magnus,
I understand now the case you were relating to as a case where at least two
MST SVC payloads are multiplexed.
Still RFC 6190 does not discussed this case and does not suggest using same
SSRC in the different session. My view is that RFC 6190 leaves it to
signaling since section 7.2.3 of RFC 6190 talks about using signaling for
media decoding dependency. I agree that the current signaling does not
address this case but claim that SSRC dependencies should be done in the
signaling.

I also think that in term of application usage I would not recommend mixing
SVC layers from different sources in MST since the major reason for using
MST was to handle BW better allowing receivers to join or receive only the
subset they need. This was the reason for mentioning SST since if there is
no application requirement for MST why use it.

Roni Even

> Sent: Tuesday, March 20, 2012 12:04 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> 01 - same SSRC for SVC
> > I will just address the SVC multiplexing issue and start a different
> > thread on the session and ssrc multiplexing and the relation between
> > RTP session and the transport infrastructure used which is also
> > discussed in draft-alvestrand-rtp-sess-neutral-00.
> >
> > As for the SVC example in the document, I think that the reason for
> > MST mode is because the idea is to use the session multiplexing based
> > on different UDP ports to divide the streams, for example in
> multicast
> > allowing the users to join just the relevant multicast groups. IF you
> > want SSRC multiplexing in SVC you can use SST (Single Session
> > Transmission) mode and I think this is the reason there is no need to
> > address SSRC multiplexing using multiple sessions to a single UDP
> receive port is not discussed.
> 
> > What I am saying is that the example in 3.2 is not correct since it
> > was not addressed on purpose being non relevant use for MST.
> 
> Sorry,
> 
> enough to make the binding between the SSRC in the different RTP
> session on the differnet multicast groups. CNAME is not sufficient if
> multiple video sources are sent from the same synchronization context.
> 
> Session being used to transmit the different scalability layers.
> However this is not documented in the RFC.
>