After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 330388 - Cannot make calls to host with IPv6 address
Cannot make calls to host with IPv6 address
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: general
1.99.x
Other All
: Normal normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-08 12:39 UTC by David Woodhouse
Modified: 2006-02-11 21:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Debugging output as requested. (14.85 KB, text/plain)
2006-02-08 15:11 UTC, David Woodhouse
Details

Description David Woodhouse 2006-02-08 12:39:04 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:
Comment 1 Damien Sandras 2006-02-08 12:47:26 UTC
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 ***
Comment 2 David Woodhouse 2006-02-08 12:59:31 UTC
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.
Comment 3 Damien Sandras 2006-02-08 13:03:06 UTC
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.
Comment 4 David Woodhouse 2006-02-08 13:14:22 UTC
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.
Comment 5 Damien Sandras 2006-02-08 13:19:11 UTC
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.
Comment 6 David Woodhouse 2006-02-08 13:42:00 UTC
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.
Comment 7 Damien Sandras 2006-02-08 13:49:12 UTC
Sorry but we are making too many suppositions here. 

Can you generate a -d 4 output of a call that fails using 2) ?
Comment 8 David Woodhouse 2006-02-08 14:01:31 UTC
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. 
Comment 9 David Woodhouse 2006-02-08 15:11:11 UTC
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).



Comment 10 David Woodhouse 2006-02-08 15:11:36 UTC
Created attachment 58937 [details]
Debugging output as requested.
Comment 11 Damien Sandras 2006-02-08 15:21:17 UTC
OK, it uses the IPv6 address, thanks for the report!

Reopening bug.
Comment 12 David Woodhouse 2006-02-08 15:33:51 UTC
Changing summary accordingly. 
Comment 13 Matthias Urlichs 2006-02-09 23:18:27 UTC
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.
Comment 14 Damien Sandras 2006-02-10 11:35:24 UTC
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).
Comment 15 Matthias Urlichs 2006-02-10 15:08:31 UTC
No such luck -- it still tries to sendto() to the server's IPv6 address.
Comment 16 Damien Sandras 2006-02-10 15:16:48 UTC
OK, thanks for the report :)
Comment 17 Damien Sandras 2006-02-11 21:56:13 UTC
Should be fixed in latest CVS of PWLIB/OPAL/Ekiga. If not, please reopen.