Re: [AVTCORE] SSRC multiplexing of RTP

[Gunnar Hellström <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>>
>
>     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
>
>     Ali C. Begen (abegen) skrev 2011-03-14 18:30:
>
>
>             -----Original Message-----
>             From: [e-mail] <mailto:[e-mail]>
>             [mailto:[e-mail]
>             <mailto:[e-mail]>] On Behalf Of
>             [e-mail] <mailto:[e-mail]>
>             Sent: Monday, March 14, 2011 1:15 PM
>             To: Magnus Westerlund
>             Cc: Harald Alvestrand; [e-mail] <mailto:[e-mail]>
>             Subject: Re: [AVTCORE] SSRC multiplexing of RTP
>
>             On Monday, March 14 2011, "Magnus Westerlund" wrote to
>             "Harald Alvestrand, [e-mail] <mailto:[e-mail]>"
>             saying:
>
>                     - 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
>
>                 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.
>
>             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.
>
>         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
>
>             --
>             Jonathan Lennox
>             [e-mail] <mailto:[e-mail]>
>             _______________________________________________
>             Audio/Video Transport Core Maintenance
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/avt
>
>         _______________________________________________
>         Audio/Video Transport Core Maintenance
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/avt
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/avt
>
>