GNOME Bugzilla – Bug 544209
Codec negotiation problem
Last modified: 2008-09-15 18:16:22 UTC
With all audio and video codecs enabled, I cannot call 500@ekiga.net. It says: "Could not connect to the remote host" If I select only PCMA, iLBC, and h261 codecs, a call is successfully established.
The problem is that with all codecs selected, the PDU is too large to be sent over UDP. What can we do? :(
1) limit the number of codec ; 2) push the PDU in several payloads.
2) is impossible
3) http://www.ietf.org/rfc/rfc5049.txt ???
Hello, I'm not sure the problem is too much codecs: I can not reproduce. (using today SVN) I've 10 sip audio codecs (+ ms-gsm, but it is only for h323, i checked it also) and 5 video codecs. With this setup i can call 500... Regards, Yannick
It probably depends on the network conditions. On a LAN it will work, for example.
I can confirm that with the latest nightly build I can establish a testcall to 500@ekiga.net with all audio and video codecs selected. That's true for two different networks (home and university)
Well, is it FIXED then ?
No, with the version from July 25, again, the problem persists as described. Maybe Damien is right and it depends on some network conditions? I'll check again from the university network and report back.
can you provide a ekiga -d 4 output? I think we should not run in the too many codecs problem since the uncompressed RFC 4175 codecs have been blacklisted (they had quite some fmtp lines)...
just after a full recompilation of ptlib/opal/ekiga with respective versions 20641/20641/6540 I had three successfull connections wih 500@ekiga.net with all audio and video codecs enabled.
any update? any log output to analyse?
-d 4 would be nice
Created attachment 116256 [details] Attempt to connect to 500@ekiga.net with all codecs enabled
Comment on attachment 116256 [details] Attempt to connect to 500@ekiga.net with all codecs enabled This is a debug log for starting ekiga, trying to call 500@ekiga.net, and then quitting ekiga again.
Created attachment 116257 [details] Attempt to connect to 500@ekiga.net with all audio codecs enabled Same as above, except that while all audio codecs are enabled, h261 is the only video codec enabled with all other disabled.
Depending on which codecs I enable, I get two different error messages: * All audio and video codecs enabled, ekiga complains "Could not connect to remote host", the debug log for this is attachment id 116256. * All audio codecs enabled, h261 enabled as only video codec, ekiga says "Local user cleard the call" directly after clicking on call. the debug log for this is attachment id 116257 HTH
According to rfc 3261, section 18.1, the first 4 paragraphs: "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." So TCP must be used in this case... opal/src/sip/sippdu.cxx:1974 (year of my birth :o) This is related to bug http://bugzilla.gnome.org/show_bug.cgi?id=341518 (TCP support for SIP) and partially to http://bugzilla.gnome.org/show_bug.cgi?id=537155 .
I've been trying with a 800 MTU , it actually fails. Maybe the best way would be to test the MTU and not send some rare codecs ?
When there are too many codecs, with switch to the compressed headers form of SIP. There is nothing more we can do :( There is already another bug report to implement TCP support. Marking this one as DUP. *** This bug has been marked as a duplicate of 341518 ***