W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

RE: [ortc] Proposal: RtpListener for unsignalled ssrcs (#32)

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Tue, 18 Feb 2014 23:42:13 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: "public-orca@w3.org" <public-orca@w3.org>
Message-ID: <96ecc78fa57246e38a7a9415c87cd6a2@SN2PR03MB031.namprd03.prod.outlook.com>
BTW, I think I've noticed a potentially unintended consequence in the definition of RTCRtpEncodingParameters. 

Because RTCRtpEncodingParameters.SSRC is not nullable, this implies that SSRC(s) MUST be specified for an RTCRtpReceiver object to receive a stream via RTCRtpReceiver.receive. 

In other words, in an audio scenario there is no way to just set RTCRtpCodec.payload-id to enable an RTCRtpReceiver object to receive an incoming audio stream without also configuring the SSRC and/or receive-appId.   For a (legacy) audio scenario where there is no receive-appId, this seems like it could result in some audio loss.  

It seems like it would be desirable to be able to specify the payload-id and have the RTCRtpReceiver object receive a single stream right from the start without needing to handle an unsignaled SSRC event. 
Received on Tuesday, 18 February 2014 23:42:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC