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 -- Ubuntu 9.04 Ekiga 3.2.0 If PDU is way larger than standard MTU (1500), even if local MTU is large enough (7000), connection timeout. https://bugs.launchpad.net/bugs/380091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
