Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

directionality of rtp headerextensions? #442

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

directionality of rtp headerextensions? #442

fippo opened this issue Mar 26, 2016 · 6 comments

Comments

@fippo
Copy link
Contributor

fippo commented Mar 26, 2016

http://ortc.org/wp-content/uploads/2015/11/ortc.html#rtcrtpheaderextension*
http://ortc.org/wp-content/uploads/2015/11/ortc.html#rtcrtpheaderextensionparameters*

https://tools.ietf.org/html/rfc5285#section-7 shows a definition with an optional direction attribute. Not that I have ever seen that in practice but do we need it?

@robin-raymond
Copy link
Contributor

robin-raymond commented Mar 26, 2016

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
Copy link
Contributor Author

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
Copy link
Contributor

robin-raymond commented Mar 26, 2016

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
Copy link
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
Copy link
Contributor

aboba commented Mar 27, 2016

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

@robin-raymond
Copy link
Contributor

robin-raymond commented Mar 29, 2016

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
Projects
None yet
Development

No branches or pull requests

3 participants