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 <juberti@google.com> Thu, 25 August 2011 23:15 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861A221F8C5D for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 16:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.593
X-Spam-Level:
X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXnuGTAV8+c1 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 16:15:10 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 529F921F8C5A for <rtcweb@ietf.org>; Thu, 25 Aug 2011 16:15:10 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p7PNGImq016353 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 16:16:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314314179; bh=6eyedxNEdIl5ubsJRupGA0p3Tts=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ataN67Rv6Q8bx7z9VGir8c+66h5UTkUNQ2eqmAtUJh1uDIf33zb9Cw+UdCRnwAvwN tv+AkNJrCBDHxo0oIHI7A==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Dcwnw2NiI2apWIfNvMPAA8trquFCaE2Lx1pKHJzFgaviDtdeH8FEloK3+fYXDgsxs ibJZ4vvUJsn3Cb29b5N4g==
Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by wpaz37.hot.corp.google.com with ESMTP id p7PNGHsQ019087 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Thu, 25 Aug 2011 16:16:17 -0700
Received: by gxk22 with SMTP id 22so2933553gxk.30 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 16:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=w33ckhvaXQkqGbMeQjGt6ok2/fO60Uh/BXe6cDqAKwE=; b=KkEXg5MTSosv9643136NqPNpV71nw7xH1RumtECcWFk33h5t02A7piSSF0bcnkZvEp M+uoahx+INz9EHIUPzRQ==
Received: by 10.231.26.68 with SMTP id d4mr646731ibc.66.1314314176140; Thu, 25 Aug 2011 16:16:16 -0700 (PDT)
Received: by 10.231.26.68 with SMTP id d4mr646723ibc.66.1314314176009; Thu, 25 Aug 2011 16:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.32.133 with HTTP; Thu, 25 Aug 2011 16:15:55 -0700 (PDT)
In-Reply-To: <4E565EB8.6080603@jesup.org>
References: <4E4FE6D3.3000409@alvestrand.no> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA7EE8@ESESSCMS0362.eemea.ericsson.se> <4E50F3B7.9020902@alvestrand.no> <2014B96E-BD04-4EA4-8EC2-C42C428E90E5@cisco.com> <4E54ADB7.8000800@alvestrand.no> <4E54C5FE.7030504@ericsson.com> <4E54C72F.7030004@alvestrand.no> <A444A0F8084434499206E78C106220CA0B00FDB6A1@MCHP058A.global-ad.net> <4E550112.4070601@alvestrand.no> <A444A0F8084434499206E78C106220CA0B00FDB821@MCHP058A.global-ad.net> <4E555B63.2080505@jesup.org> <A444A0F8084434499206E78C106220CA0B00FDB9E3@MCHP058A.global-ad.net> <4E565EB8.6080603@jesup.org>
From: Justin Uberti <juberti@google.com>
Date: Thu, 25 Aug 2011 19:15:55 -0400
Message-ID: <CAOJ7v-3fZO7_jXor483MTNBO2-jketaW7U+7amgy_=ciyNbzHQ@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=0015177404789597db04ab5c9dca
X-System-Of-Record: true
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, public-webrtc@w3.org
Subject: Re: [rtcweb] Mapping of media streams to RTP (Re: Query: What does "context" mean in the context (sic) of requirement A15? [ACTION-6])
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2011 23:15:11 -0000

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 <randell-ietf@jesup.org>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: public-webrtc-request@w3.org
>>> [mailto:public-webrtc-request@**w3.org <public-webrtc-request@w3.org>]
>>> On Behalf Of Randell Jesup
>>> Sent: 24 August 2011 21:13
>>> To: public-webrtc@w3.org
>>> 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
> randell-ietf@jesup.org
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>