Re: [rtcweb] SDP and ssrc-group,

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Wed, 22 October 2014 19:41 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ADA1AD3CC for <rtcweb@ietfa.amsl.com>; Wed, 22 Oct 2014 12:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIsWdqKKt3-q for <rtcweb@ietfa.amsl.com>; Wed, 22 Oct 2014 12:41:21 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DF11AD39E for <rtcweb@ietf.org>; Wed, 22 Oct 2014 12:41:21 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id em10so2336663wid.4 for <rtcweb@ietf.org>; Wed, 22 Oct 2014 12:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Kwpqwf2lO0pmIWpZib5YaVKmgp3qFscRA/dN/0/Cj5k=; b=IiK6Uz3am/K5ou2nv41Geu3LSkxhpk00UFhH3bCOuc8ftRWO+wfY94SfHEuEG4gz9E suWeLSn2xtK3Ymzs7ECGqfRSzKe4fbCxAZVVuzZkJLXx8WcvtWv/qxqmf91fYjWpCPdr +GCdNgOD4nB5dptzwzAg6of+BhIKlxgjXt2SKg5jtAIMRHxlR0nqzCtiMq8EBNW2/tV5 2F5RWEWvuNgbG7kZ0CAD5Ixn9q3/ds7yq1kW4WhmPJCalhrdRdNqdKpeHUYb24Gqcmld 1nfNJhdSrQLOjvpINa0rb+3N7OcUI43sfpI8XXeGXKlsZlMJTEBXwV+4j6whaBCUmf/H N+uQ==
X-Received: by 10.194.191.233 with SMTP id hb9mr335277wjc.10.1414006879867; Wed, 22 Oct 2014 12:41:19 -0700 (PDT)
Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id f7sm161120wiz.13.2014.10.22.12.41.17 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:41:19 -0700 (PDT)
Message-ID: <54480864.4050106@gmail.com>
Date: Wed, 22 Oct 2014 21:41:24 +0200
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfmH8rRyEDbJjQ=kzMv0nGC=S9gNsE7roE=kqJyVcfgy8g@mail.gmail.com> <CAJrXDUHekuQCLeCYzsnm8AuTUgiVppQHUqR7MKdQ9Q=eFFAy0w@mail.gmail.com> <CALiegfm_B5KfD5SBPzsH4YYuzD2OXdu47TtatPVmd6ihrMCh1A@mail.gmail.com> <CAJrXDUF-AXcDuQmYhH91vbgPAxLkYkB==GY9opoRk7zrEP8A7A@mail.gmail.com> <CALiegfmxnzZ6_3rKX0paNhHas6Emvu1Mekgb9caj9NLVSf_u+g@mail.gmail.com> <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com>
In-Reply-To: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com>
Content-Type: multipart/alternative; boundary="------------040300000407050108030807"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cf2Gxfc6UkbmMq1k6rLrdq-wKuU
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 22 Oct 2014 19:41:25 -0000

BTW, please, please, please, let's use the sssrc-group:FEC and send the 
FEC in its own ssrc stream, so we don't have to use RED anymore..

On 22/10/2014 21:01, Bernard Aboba wrote:
> SDP specifies payload types for RED/ULPFEC/RTX so as to allow 
> differentiation within an ssrc-group. So while an fmtp: attribute 
> could be used to denote a media stream on an a:ssrc line, it is not 
> necessary.
>
> RFC 5176 Example 3 gives an example with two cameras in which there 
> are two ssrc-group lines (one for each camera), with payload type used 
> to differentiate between H.264 and RTX in each ssrc-group:
>
>
>     m=video 49174 RTP/AVPF 96 98
>   a=rtpmap:96 H.264/90000
>   a=rtpmap:98 rtx/90000
>   a=fmtp:98 apt=96;rtx-time=3000
>   a=ssrc-group:FID 11111 22222
>   a=ssrc:11111 cname:user3@example.com  <http://example.com>  
>   a=ssrc:22222 cname:user3@example.com  <http://example.com>  
>   a=ssrc-group:FID 33333 44444
>   a=ssrc:33333 cname:user3@example.com  <http://example.com>  
>   a=ssrc:44444 cname:user3@example.com  <http://example.com>
>
> I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8:
>
> When used with the SDP Offer/Answer Model [RFC3264  <http://tools.ietf.org/html/rfc3264>], SDP source-specific attributes describe only the sources that each party is
>     willing to send (whether it is sending RTP data or RTCP report
>     blocks).  No mechanism is provided by which an answer can accept or
>     reject individual sources within a media stream; if the set of
>     sources in a media stream is unacceptable, the answerer's only option
>     is to reject the media stream or the entire multimedia session.
>
> Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all:
>
>   v=0
>   o=mascha 2980675221 2980675778 IN IP4host.example.net  <http://host.example.net>  
>   c=IN IP4 192.0.2.0
>   m=video 49170 RTP/AVPF 96 97
>   a=rtpmap:96 MP4V-ES/90000
>   a=rtcp-fb:96 nack
>   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
>   a=rtpmap:97 rtx/90000
>   a=fmtp:97 apt=96;rtx-time=3000
>
> The situation would be the same for FEC groups created via 
> ssrc-group:FEC. From
> https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux  :
>
>        The FEC and the payload MAY also be multiplexed by SSRC into one
>        single RTP session, with separate SSRC values, if the association
>        between FEC and payload streams are communicated to all members of
>        the session.  If SDP is used, this association MAY be communicated
>        through the FEC ssrc-group semantic [RFC5576  <https://tools.ietf.org/html/rfc5576>]; other mechanisms
>        are also possible.  Receivers MUST NOT attempt to interpret FEC
>        streams for which they do not have information to associate them
>        with the corresponding payload streams.
>
>
>
> On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo <ibc@aliax.net 
> <mailto:ibc@aliax.net>> wrote:
>
>> I hope I can rule my SDP logic based on standards rather than on how 
>> Chrome implements some features.
>>
>> My question was generic: if I receive the above SDP, how do I know 
>> which payloads each ssrc is supposed to transport?
>>
>> On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com 
>> <mailto:pthatcher@google.com>> wrote:
>>
>>     I'm not sure where it's specified, but here's where it's implemented:
>>
>>     https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108
>>
>>     It only supports 2 SSRCs for a FID group.  It would ignore any
>>     more than that.
>>
>>     On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo
>>     <ibc@aliax.net <mailto:ibc@aliax.net>> wrote:
>>
>>         How is that? Where is that specified? What about if I include
>>         3 ssrc values in the ssrc-group? What is each one for?
>>
>>         On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com
>>         <mailto:pthatcher@google.com>> wrote:
>>
>>             345259865 is "real"
>>             2693756249 <tel:2693756249> is rtx
>>
>>             On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo
>>             <ibc@aliax.net <mailto:ibc@aliax.net>> wrote:
>>
>>                 Hi,
>>
>>                 May I know which SSRC (345259865 or 2693756249
>>                 <tel:2693756249>) will be used for the
>>                 real media stream (plus RED and FEC) and which SSRC
>>                 will be used for
>>                 RTX?
>>
>>
>>
>>                 --------------------------
>>                 m=video 62164 RTP/SAVPF 100 116 117 96
>>                 a=mid:video
>>                 a=rtpmap:100 VP8/90000
>>                 a=rtpmap:116 red/90000
>>                 a=rtpmap:117 ulpfec/90000
>>                 a=rtpmap:96 rtx/90000
>>                 a=fmtp:96 apt=100
>>                 a=ssrc-group:FID 345259865 2693756249 <tel:2693756249>
>>                 a=ssrc:345259865 cname:erS7E/KHLYKTejNs
>>                 a=ssrc:345259865
>>                 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>                 c0134f05-e7c2-4afd-a979-4e224de5eb91
>>                 a=ssrc:345259865
>>                 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>                 a=ssrc:345259865
>>                 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>                 a=ssrc:2693756249 <tel:2693756249> cname:erS7E/KHLYKTejNs
>>                 a=ssrc:2693756249 <tel:2693756249>
>>                 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>                 c0134f05-e7c2-4afd-a979-4e224de5eb91
>>                 a=ssrc:2693756249 <tel:2693756249>
>>                 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>                 a=ssrc:2693756249 <tel:2693756249>
>>                 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>                 -------------------------------
>>
>>
>>
>>
>>                 RFC 5576 does not clarify it at all:
>>
>>                 http://tools.ietf.org/html/rfc5576#section-4.2
>>
>>                 --------------------------------------------------
>>                 4.2.  The "ssrc-group" Media Attribute
>>
>>                    a=ssrc-group:<semantics> <ssrc-id> ...
>>
>>                    [..]
>>
>>                    The <semantics> parameter is taken from the
>>                 specification of the
>>                    "group" attribute [RFC3388].  The initial semantic
>>                 values defined for
>>                    the "ssrc-group" attribute are FID (Flow
>>                 Identification) [RFC3388]
>>                    and FEC (Forward Error Correction) [RFC4756].  In
>>                 each case, the
>>                    relationship among the grouped sources is the same
>>                 as the
>>                    relationship among corresponding sources in media
>>                 streams grouped
>>                    using the SDP "group" attribute.
>>                 --------------------------------------------------
>>
>>
>>
>>                 The referenced RFC 3388 neither clarifies it:
>>
>>                 ---------------------------------------------------
>>                 7.4 FID Semantics
>>
>>                    Several "m" lines grouped together using FID
>>                 semantics form a media
>>                    flow.  A media agent handling a media flow that
>>                 comprises several "m"
>>                    lines MUST send a copy of the media to every "m"
>>                 line part of the
>>                    flow as long as the codecs and the direction
>>                 attribute present in a
>>                    particular "m" line allow it.
>>
>>                    It is assumed that the application uses only one
>>                 codec at a time to
>>                    encode the media produced.  This codec MAY change
>>                 dynamically during
>>                    the session, but at any particular moment only one
>>                 codec is in use.
>>
>>                    The application encodes the media using the
>>                 current codec and checks
>>                    one by one all the "m" lines that are part of the
>>                 flow.  If a
>>                    particular "m" line contains the codec being used
>>                 and the direction
>>                    attribute is "sendonly" or "sendrecv", a copy of
>>                 the encoded media is
>>                    sent to the address/port specified in that
>>                 particular media stream.
>>                    If either the "m" line does not contain the codec
>>                 being used or the
>>                    direction attribute is neither "sendonly" nor
>>                 "sendrecv", nothing is
>>                    sent over this media stream.
>>                 ----------------------------------------------------
>>
>>
>>
>>
>>                 So, how is the usage of ssrc-group? Where is it
>>                 really defined?
>>
>>                 Can I put more than 2 ssrc together in the same
>>                 ssrc-group line?
>>
>>                 How should the receiver interpret it?
>>
>>                 Does a ssrc-group always mean RTX usage? Where is
>>                 that specified in
>>                 the above SDP?
>>
>>                 Does not the above SDP look a complete mixture of
>>                 hacks and workarounds?
>>
>>
>>
>>
>>                 --
>>                 Iñaki Baz Castillo
>>                 <ibc@aliax.net <mailto:ibc@aliax.net>>
>>