Comment 24 for bug 380091

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.