RtpListener / mux id and RTP header extension issues #243

Closed
robin-raymond opened this Issue Sep 18, 2015 · 3 comments

Projects

None yet

2 participants

@robin-raymond
Contributor

Let's say your create an RtpListener without and RtpReceivers attached. Then an RTP packet arrives with muxid header extension assigned to header extension id of 3.

How is the listener supposed to fire an onunhandledrtp event and give the application developer the muxid value if the listener is unaware that header extension 3 means muxid?

Further, if two RtpReceivers get attached to the same RtpListener but one RtpReceiver uses header extension 3 for muxid and header extension 4 for custom-ext but second RtpReciever uses header extension 4 for muxid and header extension 3 for custom-ext and an RTP packet arrives. How does the RtpListener disambiguate between header extension 3 or 4 meaning muxid?

Finally, if two RtpReceiver are created. Once is created with muxid header extension set to 3, attached to the listener, then stopped. The second is created with muxid header extension set to 4, attached to the listener, then stopped. An new SSRC with RTP packet arrives with header extension 3 or 4. Do both header extension value 3, or 4, imply this value must be a muxid?

@aboba aboba added the 1.1 label Sep 24, 2015
@aboba
Contributor
aboba commented Sep 25, 2015
@aboba aboba removed the to-do-next-draft label Nov 20, 2015
@aboba
Contributor
aboba commented Nov 20, 2015

At the November 20 ORTC CG meeting, the question was raised about alternative resolutions, such as:

  1. Leaving header extension attributes (e.g. MID, RID) unset;
  2. Providing the header extensions in the uhandledrtp event.
@aboba aboba added a commit that referenced this issue Jan 6, 2016
@aboba aboba rtpunhandled event prior to calling receive()
If an RtpListener is constructed prior to calling receiver.receive(parameters), RTP header extensions cannot be interpreted.  This prevents the rtpunhandled event from providing the MID or RID. 

Fix for Issue #243
9c4c0f8
@aboba aboba added the PR exists label Jan 9, 2016
@aboba
Contributor
aboba commented Jan 9, 2016

Proposed fix is to leave the header extension attributes unset if they can't be interpreted.

@aboba aboba closed this Jan 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment