[jitsi-users] Issue: Handling of SIP-UDP messages above MTU size 1500 (Example: INVITE) - UDP package corruption

Archive
#1

Hi,

we encountered an issue with a customer using the default Jitsi (stable build 2.2 Mac or Windows or even Windows nightly build Jitsi 2.3.4951 Windows 7) when Jitsi tries to make a SIP call – Example:
Protocol: UDP
The SIP-Proxy requires proxy authentication, so Jitsi tries to send a new INVITE containing the additional authentication parameters plus the SDP.
As the default settings in Jitsi include many codecs, the new INVITE SIP message contains now more than 1500 bytes (in that example 1552 bytes) so on the network layer only a frame of ca. 53 bytes is created. This package does not appear on the SIP-proxy side as SIP package - no further INVITE can be seen from the proxy, the call setup fails (Jitsi tries to resend the INVITE however the problem of size stays the same) .

Workaround:

  1. change to TCP protocol (not preferred)
  2. or disable some codecs (overwriting global codec settings) to reduce the size of the SDP so that it fits in one single MTU frame

Why an issue?
There is no easy way for a service provider who usually does not have access to the user's client to find the cause of the problem as the "lost" SIP messages cannot be traced on the SIP proxy side.
Additionally there is no warning for the Jitsi user that the message size exceeds standard network settings – normal users will never find the cause of the problem as they are trusting the standard setup of Jitsi.

Possible solutions: Either a proper warning (e.g. reduce number of codecs), changing the default settings for selected codecs or an active handling of the SDP container to adapt to message sizes.

Best regards
Thomas

#2

Hey Thomas,

Hi,

we encountered an issue with a customer using the default Jitsi (stable
build 2.2 Mac or Windows or even Windows nightly build Jitsi 2.3.4951
Windows 7) when Jitsi tries to make a SIP call – Example:
Protocol: UDP
The SIP-Proxy requires proxy authentication, so Jitsi tries to send a
new INVITE containing the additional authentication parameters plus the SDP.
As the default settings in Jitsi include many codecs, the new INVITE SIP
message contains now more than 1500 bytes (in that example 1552 bytes)
so on the network layer only a frame of ca. 53 bytes is created. This
package does not appear on the SIP-proxy side as SIP package - no
further INVITE can be seen from the proxy, the call setup fails (Jitsi
tries to resend the INVITE however the problem of size stays the same) .

Workaround:

1. change to TCP protocol (not preferred)
2. or disable some codecs (overwriting global codec settings) to reduce
    the size of the SDP so that it fits in one single MTU frame

Right. You might find that issue summarized here:

https://jitsi.org/faq/frag

Why an issue?
There is no easy way for a service provider who usually does not have
access to the user's client to find the cause of the problem as the
"lost" SIP messages cannot be traced on the SIP proxy side.

There is however an easy way for a provider to privilege TLS and/or TCP and make sure that only legacy clients would fallback to UDP.

Additionally there is no warning for the Jitsi user that the message
size exceeds standard network settings – normal users will never find
the cause of the problem as they are trusting the standard setup of Jitsi.

I very much doubt that normal users would be better off with a warning here. I do agree that at least they would have something to read to their maintenance technician over the phone or describe in a mail. The thing is that there is no easy way for Jitsi to know that there will be fragmentation weither ... and even less so that fragmentation wouldn't be properly handled by network equipment on the way to the server.

Possible solutions: Either a proper warning (e.g. reduce number of
codecs),

Right ... I am not in love with this option but I wouldn't object a patch either.

changing the default settings for selected codecsor an active

> handling of the SDP container to adapt to message sizes.

This wouldn't be possible for two reasons:

1. Codecs are not the only thing that adds to the size of a message. There are also SDES keys, RTP hdr ext options, ZRTP ... and wait till we add ICE!

2. It's very hard for Jitsi to do such adaptation reliably so while I am not against a warning I think I would actually object to this.

Why don't you just set your SRV and/or NAPTR records accordingly? That would allow for a much more elegant solution that already works with vanilla Jitsi.

Cheers,
Emil

···

On 05.12.13, 15:50, Thomas Odorfer wrote:

--
https://jitsi.org