directionality of rtp headerextensions? #442

Closed
fippo opened this Issue Mar 26, 2016 · 6 comments

Projects

None yet

3 participants

@fippo
Contributor
fippo commented Mar 26, 2016
@robin-raymond
Contributor

I don't believe we need it since you can achieve this functionality by controlling the direction and setting the streams uri to active or not. Or am I missing a subtle point?

@fippo
Contributor
fippo commented Mar 26, 2016

I think this was designed for cases where one side wants to receive a header extension but never wants to send it. Which seems overkill to me, the pragmatic choice is not to send it.

@robin-raymond
Contributor

Since you can tell ORTC sender or receiver about the extension or not (i.e. activate the extension or not in that manner) it will effectively be unidirectional if you tell one side and not the other so I think it's still can be supported (and I agree, it's a bit overkill). The use cases to me maybe more if a personal wanted to indicate client-to-mixer in one direction only and mixer-to-client in the other direction only. Feels very SDP-ish and not needed in ORTC.

@aboba aboba added the 1.0 label Mar 27, 2016
@aboba
Contributor
aboba commented Mar 27, 2016

@robin-raymond @fippo

Agree that an application developer can provide the functionality of the "direction" parameter in RFC 5285 in the following way:

sendonly: Include the header extension only when calling sender.send(parameters).
recvonly: Include the header extension only when calling receiver.receive(parameters).
sendrecv: Include the header extension when calling sender.send(parameters) and receiver.receive(parameters).
inactive: Don't include the header extension when calling either sender.send(parameters) or receiver.receive(parameters).

@aboba
Contributor
aboba commented Mar 27, 2016

@robin-raymond Do we need to add text to explain how to emulate the "direction" parameter?

@aboba aboba added a commit that referenced this issue Mar 27, 2016
@aboba aboba directionality of rtp headerextensions
Fix for Issue #442
f3fbbec
@robin-raymond
Contributor

Resolved by adding text describing how developer can support this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment