GNOME Bugzilla – Bug 330388
Cannot make calls to host with IPv6 address
Last modified: 2006-02-11 21:56:13 UTC
Please describe the problem: Trying to connect to sip:echotest@woodhou.se fails -- it seems to ignore the SRV record for _sip._udp.woodhou.se and use the A record for woodhou.se instead -- and that machine isn't the SIP server. Trying to connect to sip:echotest@obelisk.infradead.org _also_ fails -- no clue why. There's some DNS traffic but no attempt to contact the server. Only when I specify sip:echotest@81.187.2.163 does it connect. You can call those SIP urls if you want -- it's just an echo test. You can probably work out the required username to actually ring the real telephone, but please don't use it :) Steps to reproduce: 1. Call sip:echotest@woodhou.se 2. Call sip:echotest@obelisk.infradead.org 3. Call sip:echotest@81.187.2.163 Actual results: Failure, Failure, Success. In that order. Expected results: Success, success, success. In any order. Does this happen every time? yes Other information:
1. It is a known problem. It is a DUP of bug #328340. 2. and 3. both work from here. I have never had any problem, and nobody reported problems calling 500@ekiga.net (which is also an echo test based on Asterisk). So I guess you have a local problem. *** This bug has been marked as a duplicate of 328340 ***
Can you try (2) from a machine which is IPv6-capable? Although I still only expect the SIP call to use IPv4, it doesn't seem to attempt to connect at all using either IPv4 or IPv6.
I don't have a machine which is IPv6-capable, but I know people who have called 500@ekiga.net from a machine which is. IPv6 is not supported. Probably looking at your -d 4 debug output might help you tracing down the problem.
Not sure of the relevance of the comparison -- ekiga.net doesn't have an IPv6 address. I'll reboot into Fedora rawhide again and try with -d 4.
So you mean that obelisk.infradead.org has an IPv6 address and that it would be the problem? It is just blind guessing without more information. The only thing I can tell you is : - it works here - it works for others Which doesn't mean there is no problem, but it is probably not what you think.
Yes, I think it's possible that this problem only occurs when both client and server are IPv6-capable. I think it's probably attempting to connect to the appropriate port on the IPv6 address, then failing to fall back to IPv4 when that doesn't work. I can adjust the SRV record to point to a name which has only A and not AAAA records, but I didn't think that should have been necessary -- I thought the fallback was mandatory.
Sorry but we are making too many suppositions here. Can you generate a -d 4 output of a call that fails using 2) ?
Yes, I'll do that shortly -- I'm just tying up a bunch of things I was in the middle of doing so that I can reboot my workstation into Fedora rawhide.
Connecting to sip:echotest@obelisk.infradead.org fails; connecting to sip:echotest@obelisk.ipv4.infradead.org works. There is no IPv6 traffic in the former case -- it just fails without even attempting to connect (not that my Asterisk server is actually IPv6-capable anyway).
Created attachment 58937 [details] Debugging output as requested.
OK, it uses the IPv6 address, thanks for the report! Reopening bug.
Changing summary accordingly.
SIP Registration to an ipv6-capable registrar also fails. Creating an IPv4 socket and then calling sendto() with the registrar's IPv6 address generally tends not to work, unfortunately.
Can you test the following : * Edit src/endpoint/manager.cpp in ekiga sources, * Find the block of instructions with #if P_HAS_IPV6 #endif * Remove it and replace it by : PIPSocket::SetDefaultIpAddressFamilyV4(); It should work. (There was some old ipV6 code and assumptions coming from gnomemeeting, ooops).
No such luck -- it still tries to sendto() to the server's IPv6 address.
OK, thanks for the report :)
Should be fixed in latest CVS of PWLIB/OPAL/Ekiga. If not, please reopen.