W3C home > Mailing lists > Public > public-ortc@w3.org > December 2015

Re: Issue 265: Missing RID in RtpListener unhandled event

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 2 Dec 2015 00:17:09 +0000
To: "public-ortc@w3.org" <public-ortc@w3.org>
CC: Robin Raymond <robin@hookflash.com>
Message-ID: <BY2PR03MB1607A3947457EFB0B26D407EC0E0@BY2PR03MB160.namprd03.prod.outlook.com>
In the November ORTC API Editor's draft, an optional header extension argument was added to the RTCRtpListener constructor in order to resolve Issue 265:

[Constructor(RTCDtlsTransport transport, optional sequence<RTCRtpHeaderExtensionParameters> headerExtensions)]
interface RTCRtpListener {
    readonly        attribute RTCDtlsTransport transport<http://ortc.org/wp-content/uploads/2015/11/ortc.html#widl-RTCRtpListener-transport>;
                    attribute EventHandler?    onunhandledrtp;

This argument was added to handle the situation where an RTP packet with header extensions is received prior to calling receiver.receive().

In such a situation, RTCRtpHeaderExtensionParameters would not be available to the RTP stack so that parameters such as the muxId and rid could be determined.

During the ORTC CG meeting, some questions were raised about this, such as:

1.      Is it necessary to support the case where no RtpReceiver objects are created prior to reception of RTP packets?   Couldn't developers be encouraged to call receiver.receive() to permit reception of RTP packets compatible with what they signaled they are willing to receive?

2.      If there are no RtpReceiver objects created prior to reception of RTP packets and the muxId and rid cannot be determined, should these attributes be unset in the unhandledrtp event?   Or does the RtpListener need an onerror eventhandler that would fire in this situation?
Received on Wednesday, 2 December 2015 00:17:44 UTC

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