IETF Logo Mail Archive

Re: [rtcweb] SDP and ssrc-group,

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 21 October 2014 20:14 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 97AC41A6F3E for <rtcweb@ietfa.amsl.com>; Tue, 21 Oct 2014 13:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.409
X-Spam-Level:
X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 FfjB-yoy4vZ5 for <rtcweb@ietfa.amsl.com>; Tue, 21 Oct 2014 13:14:57 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BAA1A01F9 for <rtcweb@ietf.org>; Tue, 21 Oct 2014 13:14:25 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4EF19E44971FB; Tue, 21 Oct 2014 20:14:20 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9LKEKGF031872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 16:14:23 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:14:23 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Iñaki Baz Castillo <ibc@aliax.net>, Peter Thatcher <pthatcher@google.com>
Thread-Topic: [rtcweb] SDP and ssrc-group,
Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw7JCgA///BDVA=
Date: Tue, 21 Oct 2014 20:14:22 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E5EAE2A@US70UWXCHMBA02.zam.alcatel-lucent.com>
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>
In-Reply-To: <CALiegfmxnzZ6_3rKX0paNhHas6Emvu1Mekgb9caj9NLVSf_u+g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EAE2AUS70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9sevlTAeL3v5d4W15L2U7SnzN1g
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
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: Tue, 21 Oct 2014 20:14:58 -0000

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?

<Raju >

Right. Firefox may have a different interpretation.

If a=ssrc-group and retransmissions are negotiated at SDP answer, then the order of ssrcs probably does not matter as the RTP payload values can determine the retransmission vs. original payloads.

If answerer wants to know the original ssrc for rejecting a=ssrc-group and retransmission payload then it need to know the original ssrc.



http://tools.ietf.org/html/rfc5576#section-6.3 defines a=ssrc with format. In the example below,

won’t having the following SDP line be sufficient to assign 2693756249<tel:2693756249> for retransmission and, indirectly, assign  345259865 for original .

a=ssrc:2693756249<tel:2693756249> fmtp:96

--------------------------
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
-------------------------------

On the question of what if there are 3 ssrcs?

Per my understanding, there is only one ssrc for original payload and another for retransmission. So, a=ssrc-group containing 3 ssrcs is probably invalid.



</Raju>



BR

Raju

v2.23.0 | Report a Bug | By Email