[jitsi-dev] RTP payload type usage in jitsi-videobridge


#1

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?

Regards,
Gavin Llewellyn

···

________________________________
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.


#2

Hey Gavin,

(inline)

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.

Indeed there is a recognised chance of asymmetry here. It is something we explicitly handle in Jitsi (client).

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?

Nope, you have it right. There is no way to specify PT asymmetry right now and supporting that would require a little extra work.

The one work around at this point would be to have your offers generated by clients, although if you do that and you are using Google's WebRTC stack, then this would make them the ICE controlling agent and they do some live candidate switching that can sometimes put you in an undesirable situation with Jitsi Videobridge.

Emil

···

On 15.01.15 16:08, Llewellyn, Gavin wrote:

------------------------------------------------------------------------

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.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

hi,

am looking for api for java. any thing like this ? Jitsi should be able to
compete with telegram

thanks

···

On Thu, Jan 15, 2015 at 11:08 PM, Llewellyn, Gavin < gavin.llewellyn@acision.com> wrote:

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?

Regards,

Gavin Llewellyn

------------------------------

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.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

[...]

The one work around at this point would be to have your offers generated
by clients, although if you do that and you are using Google's WebRTC
stack, then this would make them the ICE controlling agent and they do
some live candidate switching that can sometimes put you in an
undesirable situation with Jitsi Videobridge.

have you ever filed an issue for this?


#5

Their behaviour is allowed by 5245 so there is really no reason to file an issue.

Emil

···

On 16.01.15 13:32, Philipp Hancke wrote:

[...]

The one work around at this point would be to have your offers generated
by clients, although if you do that and you are using Google's WebRTC
stack, then this would make them the ICE controlling agent and they do
some live candidate switching that can sometimes put you in an
undesirable situation with Jitsi Videobridge.

have you ever filed an issue for this?

--
https://jitsi.org


#6

so not handling the undesirable situation is a bug in the bridge?

···

Am 16.01.2015 um 06:00 schrieb Emil Ivov:

On 16.01.15 13:32, Philipp Hancke wrote:

[...]

The one work around at this point would be to have your offers generated
by clients, although if you do that and you are using Google's WebRTC
stack, then this would make them the ICE controlling agent and they do
some live candidate switching that can sometimes put you in an
undesirable situation with Jitsi Videobridge.

have you ever filed an issue for this?

Their behaviour is allowed by 5245 so there is really no reason to file
an issue.


#7

... sort of yes. it is a corner case that is not handled by ice4j

···

On Fri, Jan 16, 2015 at 4:30 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 16.01.2015 um 06:00 schrieb Emil Ivov:

On 16.01.15 13:32, Philipp Hancke wrote:

[...]

The one work around at this point would be to have your offers generated
by clients, although if you do that and you are using Google's WebRTC
stack, then this would make them the ICE controlling agent and they do
some live candidate switching that can sometimes put you in an
undesirable situation with Jitsi Videobridge.

have you ever filed an issue for this?

Their behaviour is allowed by 5245 so there is really no reason to file
an issue.

so not handling the undesirable situation is a bug in the bridge?

--
https://jitsi.org


#8

any ETA for a fix? Is there a JVB issue for tracking this?

···

Am 16.01.2015 um 07:40 schrieb Emil Ivov

have you ever filed an issue for this?

Their behaviour is allowed by 5245 so there is really no reason to file
an issue.

so not handling the undesirable situation is a bug in the bridge?

... sort of yes. it is a corner case that is not handled by ice4j


#9

have you ever filed an issue for this?

Their behaviour is allowed by 5245 so there is really no reason to file
an issue.

so not handling the undesirable situation is a bug in the bridge?

... sort of yes. it is a corner case that is not handled by ice4j

any ETA for a fix?

Not really, I am afraid. It is not a problem for any of the Jitsi
projects so it is relatively low priority.

Is there a JVB issue for tracking this?

It's actually not a JVB but an ice4j issue and no, there is no issue for it.

Emil

···

On Tue, Jan 20, 2015 at 5:01 AM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 16.01.2015 um 07:40 schrieb Emil Ivov

--
https://jitsi.org