Comment 25 for bug 380091

Hi,

You do not need to enable just 1 codec, SIP is a negotiation mechanism; it will find an agreement if you enable several codecs. There is also priority order: in Ekiga preferences the more you push a codec on top of the list, the more it get higher priority.

The issue here is a threshold issue: the standard MTU is set to 1500 (with some exceptions). If there is too much codecs the packet size will be higher than that threshold and the packet will not reach the destination, thus preventing the negotiation leading to a failure.

Adding TCP support will remove this threshold, thus you'll be able to select all the codecs. The workaround for now is not to enable just 1 codec, the workaround is to disable a few codecs (I'm not sure about the exact number, maybe 2 or 3 will be enough).

It seems you are confusing the SIP negociation mechanism, which is clear test based and goal is to control/negotiate and the communication mechanism (the audio and video streams during a call) which use a completely different mechanism based on the RTP protocol http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

AFAIK there is no issue with RTP related to MTU size. The sample rate of a codec (8 kHz, 16 kHz, etc.) is not related with your issue.

The standard define strategies for dealing with the MTU:
http://tools.ietf.org/html/rfc3261#section-18.1.1
"If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed. This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages. However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size. For UDP, this size is 65,535 bytes, including
   IP and UDP headers."
(I will add this to the upstream bug)

Thus, as of now, Ekiga is not standard compliant in this matter. It is a hard question to have Ekiga dealing gracefully in case of a connection to a non-standard compliant client. The standard itself, which is already very complexe (SIP is way much more than a single RFC, there is many texts (i.e. RFCs) defining the standard), was written to deal with capabilities negotiation. Adding more cases in situation of non-standard compliant clients (i.e. obscure behaviour) is really hard.

As we have limited resources (really), our efforts are mainly to stick to the standard and try our best to be compliant. Make no mistake, I'm not refusing any such tricks. We have done some changes like that already in the past (i.e. changing Ekiga behaviour to deal with not fully compliant clients, Ekiga remaining compliant). My point is: this a much more complex than just let's downgrade gracefully. Change has to remain standard compliant or it will lead to a situation where it will improve the situation for some people and will be a regression for other. In practice, it is often a best effort to narrow the issue window until there is no more issue.

Best regards,
Yannick