Re: [rtcweb] Mapping of media streams to RTP (Re: Query: What does "context" mean in the context (sic) of requirement A15? [ACTION-6])

[Justin Uberti <[e-mail]>]

SSRCs are the easiest thing to demux on, and everything will be much simpler
if we exchange the SSRCs in signaling. Nothing to get lost, a clear ack from
the other side, and we can perform groupings that simply are not possible
without some form of signaling. RFC 5576 details these cases, such as
grouping of SSRCs for RTX and FEC purposes. We have implementation
experience that this works quite well in point-to-point and multi-user
scenarios.

So I agree with Harald:
- PeerConnection is a "session", with 1 SDP description, describing 1...N
RTP sessions, each containing 1...N RTP sources. It is identified by some
application-specific session-id used in the application-specific signaling
protocol.
- MediaStream is a grouping of 1...N RTP sources with the same CNAME,
intended to be synchronized at playout. It is identified by CNAME, but
additional presentation information could be specified by something like
a=content (type of stream) and a=label (display name)
- MediaTrack is a single RTP source. It is identified by 1...N SSRCs
(typically 1, but could be more if SSRC multiplexing is used for RTX/FEC)

Sample SDP, using RFC 5576, illustrating a SDP for a PeerConnection with 2
MediaStreams (one for audio/video, one for presentation), and 3 MediaTracks.
It uses RTP multiplexing, RTCP multiplexing, and SSRC multiplexing for RTX.
As a result it 1 RTP session, with 2 CNAMEs, and 5 SSRCs.
The only thing I invented here was how to attach a content=  to individual
streams, where I simply added a content: attribute to the a=ssrc lines.

<non-media stuff omitted>
a=group:TOGETHER audio video
m=audio 49168 RTP/AVP 0
a=mid:audio
a=ssrc:1111 cname:ABCD1234 content:speaker
a=rtcp-mux
m=video 49170 RTP/AVP 96 98
a=mid:video
a=rtpmap:96 H264/90000

a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 2222 2223

a=ssrc:2222 cname:ABCD1234 content:speaker
a=ssrc:2223 cname:ABCD1234 content:speaker


a=ssrc-group:FID 3333 3334

a=ssrc:3333 cname:BCDE2345 content:slides
a=ssrc:3334 cname:BCDE2345 content:slides
a=rtcp-mux

On Thu, Aug 25, 2011 at 10:39 AM, Randell Jesup <[e-mail]>wrote:

> On 8/25/2011 3:50 AM, Elwell, John wrote:
>
>> Randell,
>>
>> Good point - if the first RTCP packet gets dropped, it will be a long time
>> before the next one arrives, and in the meantime no CSRC to SSRC mapping
>> will be available.
>>
>
> Well, we are looking at AVPF which allows (though does not mandate) faster
> RTCP,
> and I think we're suggesting the "fast sync" rfc as well, so that might
> cover it
> - but there still can be a delay before the RTCP gets through successfully.
>
>
>
>  -----Original Message-----
>>> From: [e-mail]
>>> [mailto:public-webrtc-request@**w3.org <[e-mail]>]
>>> On Behalf Of Randell Jesup
>>> Sent: 24 August 2011 21:13
>>> To: [e-mail]
>>> Subject: Re: Mapping of media streams to RTP (Re: Query: What
>>> does "context" mean in the context (sic) of requirement A15?
>>> [ACTION-6])
>>>
>>> On 8/24/2011 11:47 AM, Elwell, John wrote:
>>>
>>>> RTCP doesn't have a delay if a SR is the first thing sent on
>>>>> a session,
>>>>> as recommended in draft-perkins-avt-rapid-rtp-**sync-03
>>>>>
>>>> section 2.1.1 -
>>>
>>>> this is permitted by RFC 3550 too, it notes.
>>>>>
>>>> [JRE] OK, so CNAME can be used to map an RTP stream to a
>>>>
>>> given media description in SDP. CNAME alone does not indicate
>>> the purpose of an RTP stream - it would still need something
>>> else to map it to "game" or "agent", and that is where
>>> a=content comes in.
>>>
>>> Don't count on RTCP getting received...  Start of a session
>>> might even
>>> be the worst place for it.
>>>
>>>  --
> Randell Jesup
> [e-mail]
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>