Re: [AVT] Rtp session with multiple sender streams.

[Magnus Westerlund <[e-mail]>]

Hi,

I think you are a bit confused over the basics and I think the only 
reasonable approach to answer this is to have include a short tutorial 
over how things connects together. Then you can follow up with any 
remaining questions after having gone back and read RFC 3550 once more.

An RTP session consists of a SSRC (Sender Source) space. Each SSRC 
indicates an entity sending packets, either RTP and/or RTCP. Thus both 
senders and receivers need to have a SSRC (I call the joint group of 
senders and receivers for participants). For an host sending media, it 
might require multiple SSRCs to represent different sources of the 
media. Like from two different video cameras or microphones. Each media 
stream of RTP packets will indicate which SSRC it comes from.

RTCP is used for a number of different purposes and that is why each 
sent RTCP packet is a compound packet to allow for the necesary parts to 
be included. A media sender will send Sender Reports to incidicate that 
it is sending media and how that is progressing. A Receiver will send 
Receiver reports to indicate which RTP streams from which SSRC it is 
receiving. As media senders commonly also are media receivers the Sender 
Reports include the same receiver reporting as the receiver reports.

The CNAME (Canonical Name) exist to provide two features. 1) To provide 
a binding between different RTP sessions for media that should be 
synchronized. 2) To be an better unique identifier to detect collisions 
with than the SSRC itself. Thus each SSRC has its own unique CNAME in 
the session.

Everything in RTP and RTCP is built around that each entity doing 
something is identified with its SSRC. From that one can add additional 
information like the SDES information on a per SSRC basis. The receiver 
reporting provides information from each receiver on how they see the 
reception quality of all the sources seen.

I also think you can benefit from reviewing two drafts:

- The RTP topologies draft that will probably make you think a bit more 
about the different usages RTP can be applied in:
http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-05.txt

- The HOW TO write RTP payload formats that contain some of the basic 
concepts written in somewhat other terms than what is written in RFC 3550.
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-02.txt

You could also consider buying Colin Perkins book "RTP: Audio and Video 
for the Internet" that explains most aspects of RTP.

Best Regards

Magnus

Ivar skrev:
> 
> Thakns for the answer.
> 
> But i need some more confirmations, before i get the whole picture.
> (I have most RTP implementation done (packets parsing,interval 
> calculation,...), but i can't relate some object dependencies)
> 
>  >Each source needs to send its own RTCP compound packets with an SR for 
> itself an containing reports on all the other sources it currently 
> receives data from.
> Ok dummy question what is source ? If RTP sesion has 2 sending streams 
> and receives data from xxx count of sources, then we have 3 sources (2 
> sending source and 1 receiving source) ?
> Does RTP session may have only 1 receiver SSRC what will be added to RR 
> reports ?
> Has each sending source has own CNAME ?
> 
> The problem is can't relate source,participant relation ship.
> The confusing parts are like:
>    Each source needs to send its own RTCP compound packets
>    and now
>    As each session participant sends its own compound packets
> Even the term participant is some how confusing, like participant may 
> have multiple streams, may be in multiple sessions, ... .
> I have readed rfc 3550 over and over during 2 weeks,  i can't get such 
> simple stuff.
> 
> I need to idea of this simple case:
> SSRC are just exmples, in realife randoms.
> 
> RTP_Session
>    SendStreams
>       SendStream1  SSRC   = 1 (source in your term if i get right)
>       SendStream2  SSRSC = 2
> 
>    ReceiveStreams - Receive streams is like receiver and has SSRC = 3 
> .... ?
>      ReceiveStream1 SSRC = 100 (source in your term if i get right)
>      ReceiveStream2 SSRC = 101
> 
> Now RTCP interval reaches, Both sending streams has sent data.
> What actually happnes what we must compose here ?
> 
> 2 x SR ?
> RR 1 -  SSRC = 1
> ... no report blocks
> RR 2 -  SSRC = 2
> ... no report blocks
> 
> Ok probably RR
> SSRC = 3
> report block 1
> SSRC = 100
> ... report block data
> report block 2
> SSRC = 101
> ... report block data
> 
> now SDES ... ?
> 
> 
> Thanks
> 
> 
> Magnus Westerlund wrote:
>> Ivar skrev:
>>> Hi,
>>>
>>> RFC 3550 3. says that session may have multiple sending streams, but 
>>> all must have it's own SSRC.
>>>
>>> Now for example session is receiver and there are 2 sending streams, 
>>> how compound RTCP packet is composed ?
>>> Has 2 SR reports if both sender streams have sent data, has 1 SR if 
>>> only 1 stream sent data ? (each SR report has reported sender stream 
>>> SSRC)
>>
>> Each source needs to send its own RTCP compound packets with an SR for 
>> itself an containing reports on all the other sources it currently 
>> receives data from. To avoid throwing off any quality report user, 
>> also SSRCs co-located in the same host needs to include report blocks 
>> on each other.
>>
>>> And what SSRC is used for RR, if there are more than 31 remote 
>>> senders or no local RTP sent during last RTCP interval? 
>>
>> All senders or receivers have their own SSRC. That is always used as 
>> reporting the source of the RR. The content of the report block is 
>> round-robined in case there are more than 31 active sources.
>>
>> (generate local receiver SSRC for that ?)
>>
>> Not certain what you mean with this. But if you mean that a receiver 
>> that isn't sending media, it still needs to have an SSRC. Any sender 
>> or receiver do need to have an SSRC. The only one that can live 
>> without an SSRC is a completely passive receiver, i.e. do not send 
>> RTCP or RTP.
>>
>>
>>> Also how all this affects SDES, because there are more than 1 SSRC 
>>> for RTP session ?
>>
>> As each session participant sends its own compound packets they shall 
>> include the SDES CNAME item for themselves. In addition mixers may 
>> include SDES items from contributing sources.
>>
>>> (One of the SSRC will send all sdes items, other SSRCs only 
>>> CNAME(which will map SSRC to participant))
>>
>> Well this is allowed but doesn't make much sense. As the SDES item 
>> describe the indicated SSRC, and says nothing about the others. No 
>> assumption can really be made with the possible exception between 
>> different media streams and for the SSRCs in the different sessions 
>> that indicate the same CNAME value.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director & TSVWG Chair
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM/M
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone [phone]
>> Torshamsgatan 23           | Fax   [phone]
>> S-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
> 
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt