IETF Logo Mail Archive

Re: [rtcweb] SDP and ssrc-group,

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Wed, 22 October 2014 20:05 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 8AC6D1A1A0A for <rtcweb@ietfa.amsl.com>; Wed, 22 Oct 2014 13:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 nIZBCgtHo3eS for <rtcweb@ietfa.amsl.com>; Wed, 22 Oct 2014 13:05:39 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 5F6BB1A1A1E for <rtcweb@ietf.org>; Wed, 22 Oct 2014 13:05:38 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6F4B0AD543762; Wed, 22 Oct 2014 20:05:34 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9MK5YKs002710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 16:05:34 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:05:34 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Suhas Nandakumar <suhasietf@gmail.com>, Bernard Aboba <bernard.aboba@gmail.com>
Thread-Topic: [rtcweb] SDP and ssrc-group,
Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw8eqhMgABHJ4D//8kqMA==
Date: Wed, 22 Oct 2014 20:05:33 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E5EC923@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> <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <CAMRcRGQ6yfWqXhevnFJDXWq20wJbfimrxhe9M_E3LrBTjmHU=w@mail.gmail.com>
In-Reply-To: <CAMRcRGQ6yfWqXhevnFJDXWq20wJbfimrxhe9M_E3LrBTjmHU=w@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_E1FE4C082A89A246A11D7F32A95A17828E5EC923US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ViZfl6BvHKfPoJsCcAOwPluD7Lw
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: Wed, 22 Oct 2014 20:05:42 -0000

Just thinking loud
 As long as there is enough information to unabigously map the incoming streams to the SDP, i dont see we need any more information to be added.

I feel the combination of SSRC and Payload Type in the RTP packet is good enough to find the mapping to the appropriate media line (if the PTs are not repeated) when needed.

So in the initial examples above, ssrc-group communicated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs and the associated payload type has all the needed info for the receiver to demux at the rtp level as well as map at the SDP level. Thus i dont see a need for specifying PT association explicitly in SDP for the ssrc-groups.
<Raju>
For a simple SDP offer/answer case it is probably not needed. But think of a case where SDP answerer does not support a=ssrc-group:FID and also associated retransmission ‘apt’ payload then it will not include them in SDP answer. But it needs to know which ssrc is associated to the original payload so that it allows only that ssrc.

</Raju>

BR
Raju

v2.23.0 | Report a Bug | By Email