I'm a bit confused by RTP payload type usage in Jitsi Videobridge, and I suspect that it does not behave properly in certain cases.
In RFC3264, section 5.1 (generating unicast offers), it is indicated that payload type numbers may differ in each direction in a sendrecv stream:
For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.
I'm using the REST (JSON) interface to control the Videobridge, and my signalling focus needs to be able to cope with both incoming and outgoing sessions (and thus generate both offers and answers).
* In the case of an incoming session (assuming it contains an offer), the offered payload types can be associated with the new Videobridge Endpoint, and used in both directions. The answer just has to specify the same payload type mapping. There should be no problem here.
* In the case of an outgoing session, the Videobridge provides the transport details, and a default set of codecs and payload type mappings are included in the outgoing offer. However, we have no control over whether the resulting answer uses the same mappings. Which mapping should be provided to the Videobridge?
I am assuming that Videobridge is attempting to send and receive RTP using the same payload type mapping - if it instead expects a fixed payload type mapping for incoming RTP then we only need to provide it with the remote party's mapping, and everything should work. However, this is not the impression I get from initial digging into the code.
The MediaStream implementation in libjitsi appears to have support for asymmetric mappings (see the method addDynamicRTPPayloadTypeOverride), but I don't think this is used by the Videobridge.
Is this a problem, or have I missed/misunderstood something?
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.