I can confirm with Alvin, insofar as I did not install any additional codecs (knowingly). Granted I haven't gone so far as to test a fresh install, so there exists a possibility that additional codecs were available to me as a side-effect of installing other packages on top of the default ubuntu install. Here's what I got (all enabled):
* Speex 8/16 kHz, PCMA, PCMU, G726-16/24/32/40, GSM, MS-GSM, G722 Ekiga can connect to the Echo Test and work as expected when the local machine's MTU is set to 1500. Funny things happen when the the local machine's MTU is set too high (common on machines that are on a local gigabit network but also connect to the Internet.) I take exception with the view that Ekiga must honor the user's wish to use whatever codecs the user specifies. The view by itself is justified and agreeable, but ignores the ultimate wish of every user of every program ever in existence -- the user wants the program to actually work. If those two ideals happen to collide, the latter should take precedence over the former. Having said that, I don't think the following would be a problem: * Offer a checkbox that will offer to limit UDP packet sizes to the standard size found on the Internet in the same place where users can enable/disable codecs. * Warn users that this may disable the use of some codecs the user has chosen to use which might result in not being able to connect to some SIP servers/peers. * When the user makes a call and is unable to negotiate the use of a codec with the SIP server/peer, tell them so. Don't tell them "user not available." That's how this thread started in the first place. Tell them with as much specificity as you can -- "unable to negotiate codec with server" or something similar. While Ekiga gets TCP support, there very well could be some servers that are UDP-only. This is the only reason I'm going into the diatribe. I've seen too many bug reports and release notes for SIP-related software/firmware. For varying reasons, shortcuts get taken. To the user, if one implementation works and another does not, the non-working implementation looks broken even when the non-working implementation is not at fault. And last but not least, I just want to make sure that it's understood that I'm not holding anyone personally responsible for my gripes with Ekiga -- Yannick or otherwise. After taking a few read-overs on this post, I realized what I wrote could be taken that way. ** Tags added: ekiga ** Tags added: 1500 mtu pdu udp -- Ubuntu 9.04 Ekiga 3.2.0 Does not work behind double-NAT 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
