Thanks for the explanation.
We had overseen the obvious one in the FAQ.
By adapting our DNS SRV records to provide a SRV entry for TCP _sip._tcp
instead of UDP the problem does not occur again.
Jitsi was actually the first client we encountered this message size issue.
Am 06.12.13 03:01 schrieb "Emil Ivov" unter <email@example.com>:
On 05.12.13, 15:50, Thomas Odorfer wrote:
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:
The SIP-Proxy requires proxy authentication, so Jitsi tries to send a
new INVITE containing the additional authentication parameters plus the
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) .
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:
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
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
Right ... I am not in love with this option but I wouldn't object a
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
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