Subject: [AVTCORE] SSRC multiplexing of RTP

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Mar 2011 16:34:02 -0700

I've been geeing a lot of questions lately about ways to multiplex RTP onto one UDP port. This would be for an environment using point to point media flows set up with SIP between endpoints or between an endpoint and centralized conferring unit. There is no multicast involved in these use cases. For example the SSRC based approach in 

http://www.jdrosen.net/papers/draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt

Now, I do recall that people felt there were problems with this type of approach but I forget what they were. Can someone help remind me what the issues are with this. 

Thanks, Cullen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Mar 2011 08:42:30 +0100

Cullen Jennings skrev 2011-03-09 00:34:
> 
> I've been geeing a lot of questions lately about ways to multiplex
> RTP onto one UDP port. This would be for an environment using point
> to point media flows set up with SIP between endpoints or between an
> endpoint and centralized conferring unit. There is no multicast
> involved in these use cases. For example the SSRC based approach in
> 
>  Now, I do recall that people felt there were problems with this type
> of approach but I forget what they were. Can someone help remind me
> what the issues are with this.
> 

I have written a summary of the issues in Section 2.1 of
http://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/

But, that has actually not considered the actual feedback when this
document was discussed. Should do some digging and see if there is
anything in that discussion that should be added to our document.

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: Gunnar Hellström <[email-masked]>
Date: Wed, 09 Mar 2011 16:11:37 +0100

Cullen

I agree. I have also got negative feedback on SSRC multiplexing.

I had it described in the draft for multi-party handling of real-time 
text in draft-hellstrom-text-conference-02.txt
in order to easily separate the streams from different sources and 
display them in a way that the receiver decides.

But the feedback was that many RTP implementations would just regard it 
to be an error if a new SSRC appeared in the session and it would cause 
problems.

SSRC multiplexing also has some trickiness in that when a new SSRC 
appears in the session, it can either be an old stream that changed SSRC 
or a new multiplexed stream. RFC 3550 mentions ways to handle that but 
there is a risk for losing initial packets before it is sorted out. 
Losing initial packets in e.g. a video stream can be fatal for the 
possibility to start proper decoding rapidly.

Taking the consequences of this, I am just about to submit a modified 
draft for the real-time text case using one stream and marking the 
source by CSRC per packet.
It will survive through most existing RTP implementations.

/Gunnar

Cullen Jennings skrev 2011-03-09 00:34:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Mar 2011 16:40:41 +0100

Hi Gunnar,

> to be an error if a new SSRC appeared in the session and it would cause 

Well, this is how you are supposed to use cases when you have multiple
sources. And text chat is case when implementations can't really say
that they don't have the rendering capabilities for it. But I do
understand that most implementations sucks at handling multiple SSRCs
which is very bad.

My hope is that we will see a bit of signalling support for handling
multiple SSRCs as part of the CLUE work. But, we do need to push that
support for multiple SSRCs, it needs to be in the stacks.

> possibility to start proper decoding rapidly.

I guess clarifications should be in place here. And your strategy for
handling it will depend a lot of what application it is and which media
one talks about.

> It will survive through most existing RTP implementations.

So your going with a mixer design, despite that for text it isn't really
needed. I think it is unfortunate, but I guess pragmatic due to poor
implementation support.

A question to implementors:

Have you tried running the tests documented in RTP testing strategies?
http://www.rfc-editor.org/rfc/rfc3158.txt

These are excellent tests to check that ones implementation handles what
it needs to.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Mar 2011 11:51:47 +0100

> support for multiple SSRCs, it needs to be in the stacks.
Seems to me that since this isn't clear from current specs, there needs 
to be a specification of what a new SSRC appearing in a session means, 
possibly agreed to at call setup time, and if both renumbering and 
multiple streams are to be supported:

- if it is a new stream, how to tell that it's a new stream
- if it is an old stream, renumbered, how to tell what the old stream was

This will certainly be an RTCWEB discussion item, so I'm happy to see 
AVTCORE pick it up to be worked on.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Mar 2011 17:17:32 +0100

> - if it is an old stream, renumbered, how to tell what the old stream was

I don't think the specs are that unclear on what is what. You do need
the CNAME to determine which case it is. Sure it can be clarified. I
mostly think the issue is with the state of the implementations. They
haven't considered the implications and need for multiple SSRC support.

> AVTCORE pick it up to be worked on.

Lets figure out what is considered the issues here.

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Mon, 14 Mar 2011 13:14:56 -0400

> haven't considered the implications and need for multiple SSRC support.

There are valid cases where multiple independent streams will have the same
CNAME -- if they're multiple sources from the same participant.  Multiple
video streams in the Telepresence/CLUE environment are probably the current
most prominent example of this, but generally, this will be the case if you
have multiple streams that all need to be synchronized together.

-- 
Jonathan Lennox
[email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 14 Mar 2011 10:30:15 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, March 14, 2011 1:15 PM
> To: Magnus Westerlund
> Cc: Harald Alvestrand; [email-masked]
> Subject: Re: [AVTCORE] SSRC multiplexing of RTP
> 

CNAME would be used to relate a source stream with its FEC stream as well. The cname guidelines document is a useful read:
http://tools.ietf.org/html/draft-ietf-avt-rtp-cnames-05

-acbegen

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 15 Mar 2011 00:14:17 +0100

The rtp-cnames document seems to give good advice.

Statements that make me want to stay away from SSRC multiplexing is for 
example what is stated in RFC 3550 RTP
in 6.2.1
  "New sites are added to the count when they are heard, and an entry 
for each SHOULD be created in a table indexed by the SSRC or CSRC 
identifier (see Section 8.2) to keep track of them. New entries MAY be 
considered not valid until multiple packets carrying the new SSRC have 
been received "

If a source is regarded not valid, I see a risk that RTP implementations 
ignore packets from that source.

/Gunnar

---

From: paromita chowdhury <[email-masked]>
Date: Tue, 15 Mar 2011 11:08:56 +0530

I have a doubt with SSRC multiplexing. When two multiplexed SSRC sessions
appear in a RTP session, do have two separate sequence number series or
share the same. Also in unicast sessions when the receiver receives two such
sessions what does it considers the two streams as?

-PC

2011/3/15 Gunnar Hellström <[email-masked]>

>  "New sites are added to the count when they are heard, and an entry for
> each SHOULD be created in a table indexed by the SSRC or CSRC identifier
> (see Section 8.2) to keep track of them. New entries MAY be considered not
> valid until multiple packets carrying the new SSRC have been received "
>
>> CNAME would be used to relate a source stream with its FEC stream as well.
>> The cname guidelines document is a useful read:

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 15 Mar 2011 07:24:14 +0100

The use is described in RFC 3550 RTP, section 7.1, about RTP Translator, 
that can be used in a conference focus to multiplex media originating 
from a number of sources into one session. We had used it in a draft for 
multi-party conference application of real-time text, because of two 
reasons.
1. Text from different sources can be separated by the receiver and 
displayed in a layout that the receiver controls.
2. RTP Sequence numbers are maintained per SSRC stream, so it is easy to 
detect what stream has been suffering from packet loss and recover that 
stream.

However, because of reactions from implementors, the draft for real-time 
text conferencing has now changed to use an RTP mixer (also see RTP 
section 7.1). It has the same SSRC, but different CSRCs. The mixer only 
has text from one source per packet and mark the packet with the 
contributing CSRC. The final result is that we achieve the same results 
as for the translator with a more widely accepted mechanism.

Gunnar

-----------

paromita chowdhury skrev 2011-03-15 06:38:
> I have a doubt with SSRC multiplexing. When two multiplexed SSRC 
> sessions appear in a RTP session, do have two separate sequence number 
> series or share the same. Also in unicast sessions when the receiver 
> receives two such sessions what does it considers the two streams as?
>
> -PC
>
> 2011/3/15 Gunnar Hellström <[email-masked] 
> <mailto:[email-masked]>>
>
>     Statements that make me want to stay away from SSRC multiplexing
>     is for example what is stated in RFC 3550 RTP
>     in 6.2.1
>      "New sites are added to the count when they are heard, and an
>     entry for each SHOULD be created in a table indexed by the SSRC or
>     CSRC identifier (see Section 8.2) to keep track of them. New
>     entries MAY be considered not valid until multiple packets
>     carrying the new SSRC have been received "
>
>     If a source is regarded not valid, I see a risk that RTP
>     implementations ignore packets from that source.
>
>     /Gunnar
>
>             From: [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of
>             [email-masked] <mailto:[email-masked]>
>             Cc: Harald Alvestrand; [email-masked] <mailto:[email-masked]>
>             On Monday, March 14 2011, "Magnus Westerlund" wrote to
>             "Harald Alvestrand, [email-masked] <mailto:[email-masked]>"
>             saying:
>
>         CNAME would be used to relate a source stream with its FEC
>         stream as well. The cname guidelines document is a useful read:
>             [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Mar 2011 07:24:54 +0100

> have multiple streams that all need to be synchronized together.
Hm. CNAME seems like it's not a stream identifier.

RFC 3550 section 6.5.1 contains lots of language saying that it is the 
user@host, which would mean that if I send two video streams and two 
audio streams, I have four streams with the same CNAME.

No matter whether these are in one RTP session or multiple RTP sessions, 
this seems problematic - in the case of layered encodings using multiple 
RTP sessions, it seems to me that if I send two video streams over four 
sessions, I will have a hard time matching each base layer with its 
corresponding higher layer if CNAME is my only correlator.

                       Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Mar 2011 15:17:39 +0100

> audio streams, I have four streams with the same CNAME.

Well, generating good quality cnames are one question and that is solved by:
https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-cnames/

The other question is how you use the CNAME to bind together streams. I
do agree that we do have cases today where you can't both get synch and
SSRC multiplexing of certain functionalities. It is definitely something
that should be included in the
https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/

> corresponding higher layer if CNAME is my only correlator.

Well, you can use the same SSRC over multiple RTP streams to achieve
quicker and clearer synchronization. I still need to read SVC payload
format, but I know that Session multiplexing of RTP retransmissions (RFC
4588) does use that method for correlation.

I am not certain that we haven't forgotten any case, but when
introducing certain type of RTP functionalities you also at the same
time restrict the possibilities in how these mechanisms can be used.

I think AVT groups should work with CLUE and RTCWEB here to address the
issues found due to the use cases these WGs have.

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Tue, 15 Mar 2011 10:27:30 -0400

> ignore packets from that source.

This recommendation made sense in the context RTP was originally written
for, i.e. Any-Source Multicast with no authentication.

It doesn't make much sense for SSRC multiplixing over unicast or
single-source multicast, or for SRTP-based authentication.

A document giving recommendations about how best to handle SSRC multiplexing
should probably mention that this recommendation should be altered in
environments when it's inappropriate.  (Particularly for video, disregarding
initial packets is a very bad idea.)

-- 
Jonathan Lennox
[email-masked]

---

From: [email-masked]
Date: Tue, 15 Mar 2011 10:37:54 -0400

> Hm. CNAME seems like it's not a stream identifier.

No -- RFC 3550 pretty clearly defines CNAME as a participant/endpoint
identifier, not a stream identifier.  The rule of thumb I use is that all
streams that need to be synchronized with each other need to have the same
CNAME.

RFC 5576 provides an SDP-based mechanism to uniquely identify streams and
their properties, and to bind streams together following an SSRC collision,
even when multiple streams have the same CNAME.

It's not clear that RTCWeb necessarily wants to use SDP, and it's also not
clear that SDP scales to all the cases that CLUE needs.  However, I think
that starting from RFC 5576 semantics, even if not necessarily its syntax,
for these other use cases would probably be a good idea.

-- 
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Mar 2011 15:43:06 +0100

> initial packets is a very bad idea.)

Fully agree, and please note the "MAY" in the RFC 3550 text. An
implementation can do so when appropriate. I think in a context where
one knows source addresses of one peer etc, those are better protection
than RTP and RTCP packet based validation before accepting an SSRC. In
the implementations I have done of RTP/RTCP we have set the number of
packets needed before adding SSRC to 0. Because dropping the initial
packets are degrading quality to much.

Cheers

Magnus Westerlund

---

From: Thomas Schierl <[email-masked]>
Date: Tue, 15 Mar 2011 16:10:30 +0100

Hi Magnus,

> issues found due to the use cases these WGs have.

In the RTP payload format for SVC, we assumed Session Multiplexing plus 
using the same SSRC for the layers of the same source.

-- 
Visit us at

Web 2.0 / March 28-31 / San Francisco, Moscone West, USA / booth 824
www.web2expo.com/webexsf2011

NAB Show 2011/ April 11-14 / Las Vegas, Nevada, USA / booth C8444 (Bavarian Pavillon)
www.hhi.fraunhofer.de/nab