directionality of rtp headerextensions? #442

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

Comments

Projects
None yet
3 participants
@fippo
Contributor

fippo commented Mar 26, 2016

@robin-raymond

This comment has been minimized.

Show comment
Hide comment
@robin-raymond

robin-raymond Mar 26, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@fippo

fippo Mar 26, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@robin-raymond

robin-raymond Mar 26, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@aboba

aboba Mar 27, 2016

Contributor

@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).

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

This comment has been minimized.

Show comment
Hide comment
@aboba

aboba Mar 27, 2016

Contributor

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

Contributor

aboba commented Mar 27, 2016

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

@robin-raymond

This comment has been minimized.

Show comment
Hide comment
@robin-raymond

robin-raymond Mar 29, 2016

Contributor

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

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