Re: [rtcweb] SDP and ssrc-group,

"Roni Even" <ron.even.tlv@gmail.com> Wed, 29 October 2014 15:14 UTC

Return-Path: <ron.even.tlv@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 CF6941A0439 for <rtcweb@ietfa.amsl.com>; Wed, 29 Oct 2014 08:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_15=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 0va42VfuWkpl for <rtcweb@ietfa.amsl.com>; Wed, 29 Oct 2014 08:14:24 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABFD1A049A for <rtcweb@ietf.org>; Wed, 29 Oct 2014 08:14:17 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id n3so1992182wiv.0 for <rtcweb@ietf.org>; Wed, 29 Oct 2014 08:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=ZJFeUqquq1G1w60aAbeGG5yiRLUtV2jbBnzQO/d/F2o=; b=nOnq226X1MdTS47kuz9DJfyVCT8fsup+Qfv7kbUCU0LHGfYB/V5FQQ3vLKRV1aSUkA 5a0r74vveMSeDslKNIk/pxIH12lXWSsiqvnjqyKkngTe+Iep4ZNqsPvWYk/vi9SBY7w3 0nxgmllq6xd+fucuQ1kBXkEFFpQEVI5uZIHLIOncrEE3h5ZwhdS2WNxrxHCLofzWvg6g w6YpbABbDHPK52yB7aeqe/aRaBI0X6q5bIiAth0iqUh+znvhinhXMZmlU+TzzD5MynQ4 ZSqtWnvEDVM1q2f1Q949Oj1rPJaq8bXqE5Cb+Xu1cBfW7HYhWcI3a/o5WQdUp4TemYiB fFYw==
X-Received: by 10.194.82.104 with SMTP id h8mr13369418wjy.44.1414595655755; Wed, 29 Oct 2014 08:14:15 -0700 (PDT)
Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id fr6sm5860297wic.1.2014.10.29.08.14.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 08:14:14 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Sergio Garcia Murillo' <sergio.garcia.murillo@gmail.com>, rtcweb@ietf.org
References: <CALiegfmH8rRyEDbJjQ=kzMv0nGC=S9gNsE7roE=kqJyVcfgy8g@mail.gmail.com> <095701cff34c$ad1089c0$07319d40$@gmail.com> <5450DDDE.5020802@gmail.com>
In-Reply-To: <5450DDDE.5020802@gmail.com>
Date: Wed, 29 Oct 2014 17:14:11 +0200
Message-ID: <09a801cff38a$ffb28640$ff1792c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIdm2glshlU301gGbh4Wgrmbmu/awLmGMkxAjjC642bguTR0A==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zbY7EssOnVVvFRT6nhcqOcqD84s
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, 29 Oct 2014 15:14:26 -0000

Hi,
In the application token proposal we were trying to address two FEC issues:

1. You assume that the SDP layer will know the SSRCs of the streams when making an offer. This may be true for point to point call but there are topologies (https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-04) where the SSRCs may not be known to a Mixer who projects incoming RTP streams as is. This was the reason for the application token. (this is a general issue with other use cases when using SSRC in SDP and bundle tried to address part of it for identifying the received RTP streams using the SDP group mid values)

2. For this case instead of using ssrc-group we proposed appId-group and define the mapping between an appId and the pt number to help identify the relation in the SDP between the FEC streams and the source streams.


We had the feeling that the using the SSRC in SDP was causing multiple issues and by using a token that does not have an RTP layer semantics we can have a cleaner solution.


Roni

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia
> Murillo
> Sent: 29 October, 2014 2:30 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] SDP and ssrc-group,
> 
>  From a formal perspective, I don't feel it is correct to describe the semantical
> meaning of an ssrc by referring to a payload.
> 
> Best regards
> Sergio
> On 29/10/2014 8:48, Roni Even wrote:
> > Hi,
> > We discussed this mapping issue in a previous version of the application token
> draft http://tools.ietf.org/html/draft-even-mmusic-application-token-02
> example in section 1.
> > We thought of having a mapping from appId to "pt" (section 3.3.1) Roni
> >
> >> -----Original Message-----
> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz
> >> Castillo
> >> Sent: 21 October, 2014 7:26 PM
> >> To: rtcweb@ietf.org
> >> Subject: [rtcweb] SDP and ssrc-group,
> >>
> >> Hi,
> >>
> >> May I know which SSRC (345259865 or 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
> >> 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 cname:erS7E/KHLYKTejNs
> >> a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> c0134f05-e7c2-4afd-a979-4e224de5eb91
> >> a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> a=ssrc: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>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb