directionality of rtp headerextensions?

[fippo]

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]

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]

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]

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]

@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]

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

[robin-raymond]

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