[Bug 380091] Re: 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.
** Changed in: ekiga (Ubuntu) Importance: Undecided = Low -- 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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 380091] Re: 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.
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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 380091] Re: 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.
** Changed in: ekiga Status: In Progress = New -- 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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 380091] Re: 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.
Thanks for looking into this at all. I wasn't expecting this to be easy. If it was something that could be solved with a few hours of pounding one's head into solid objects, I would have done that already and put the solution up on my blog, along with a thank you to the responsible party for making me a little less sane. If an Ekiga developer can't explain log #1, that means I haven't lost all sanity just yet. :) So I guess the solution for now is to experiment with the codecs. Have the user enable codecs one-by-one on a one-and-only-one basis, keep notes, and enable only those that will work. Not the best way to do things, but a work-around is a work-around. What I suspect is happening now: Ekiga established UDP connection Ekiga negotiates codecs with SIP server Ekiga uses first mutually-agreeable codec without checking if resulting UDP packet sizes might result in a drop Packets get dropped Ekiga says, Hey, I tried! User goes WTF? Devs grumble What I suspect will happen with TCP support: Ekiga negotiates TCP or UDP with SIP server If both are supported, Ekiga uses TCP because of the problems with UDP. Ekiga negotiates codecs with SIP server Ekiga uses first mutually-agreeable codec Packets get fragmented instead of dropped Ekiga works. Both users and devs happy happy Scenario I'm afraid of with TCP support: Ekiga negotiates UDP or TCP with SIP server Ekiga finds a UDP-only SIP server Ekiga negotiates codecs with SIP server Ekiga uses first mutually-agreeable codec without checking if resulting UDP packet sizes might result in a drop Packets get dropped Ekiga says, Hey, I tried! Users and devs both go, WTF? The addition of TCP support would definitely minimize the impact of UDP packet sizes, and admittedly knock the priority of the bug way down on the list due to that minimized impact. But someone, somewhere, is going to run into that last scenario. I'll bet an entire case of Monster (or your favorite) energy drinks on it. -- 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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 380091] Re: 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.
** Summary changed: - Ubuntu 9.04 Ekiga 3.2.0 Obeys Local Machine MTU Settings, Tries Nothing Else + 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. -- 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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 380091] Re: 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.
Hi, Even if it is not directly related to the issue in the first log, TCP support in Ekiga will probably solve Alvin issue as well as the issue in the first log. Thus I link the upstream bug related to TCP support here. Best regards, Yannick ** Also affects: ekiga via http://bugzilla.gnome.org/show_bug.cgi?id=341518 Importance: Unknown Status: Unknown ** Changed in: ekiga Status: Unknown = In Progress ** Changed in: ekiga (Ubuntu) Status: Confirmed = In Progress -- 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 Desktop Bugs, which is subscribed to ekiga in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
