Created attachment 35679 [details] Attached is the debug log for when I receive a call and it just says "connecting". When I place a call to sip:18004664411@tf.voipmich.com (google voice) via my either of my SIP accounts (sipgate.com or iptel.org) the call works perfectly. However, if I try to call myself from another phone empathy rings for me, and I answer, and it just says "connecting" but the call does not work (neither end can hear anything).
Created attachment 35680 [details] Attached is the debug log for when I place a call and it works perfectly (both logs include answering and hanging up the call).
Created attachment 35681 [details] screenshot showing what happens when I receive a call (all it says is "connecting")
Created attachment 35682 [details] screenshot showing what happens when I place a call (it works perfectly, both ends can hear and you can see the timer for the call "0:02" rather than "connecting")
Please export TPSIP_DEBUG=all and TPORT_LOG=1 in telepathy-sofiasip's environment. I thought Empathy will collect the logs anyway, though.
I'm on a different network now and it's working. The other network I was on had two NAT's that all connections have to pass through. So I'm thinking it's a network issue, however receiving a call worked with ekiga but not empathy/sofiasip with the same settings. When I get back to the other location where I can test the call on the network where there are issues I will post the results (in the next few weeks probably).
Created attachment 35765 [details] The same scenario does work on a different network (does not have to pass through 2 NAT's)
The logs are not very informative again. With Empathy, can you switch to "sofiasip" in the debug window and save the resulting log? Also, either logs with TPORT_LOG=1 or packet dumps would bring necessary information.
I came across exactly the same problem: outbound calls work fine but on inbound calls empathy gets stuck during "Connecting..." when I am behind my NAT-enabled router. Sniffing the communication between empathy and my sip provider revealed the cause of the problem: On outbound calls empathy starts sending RTP packets as soon as the connection is established; on inbound calls, however, it waits for the first incoming RTP packet before sending any RTP packets itself. But since I am behind a NAT no packet will ever be received unless something is sent first. This is not a problem with the STUN configuration which is working fine. Empathy also uses the correct IP addresses and port numbers. The only problem is that it does not always send an RTP packet and thus fails to traverse restricted cone NATs.
Can you reproduce it with telepathy-sofiasip 0.6.3?
(In reply to comment #9) > Can you reproduce it with telepathy-sofiasip 0.6.3? No, it's working fine with telepathy-sofiasip 0.6.3 in both directions. I'm sorry for not having tested the latest version in the first place.
(In reply to comment #10) > (In reply to comment #9) > > Can you reproduce it with telepathy-sofiasip 0.6.3? > > No, it's working fine with telepathy-sofiasip 0.6.3 in both directions. I'm > sorry for not having tested the latest version in the first place. We can consider this fixed in or before 0.6.3, then. Thanks for re-testing.
*** Bug 29805 has been marked as a duplicate of this bug. ***
I re-open the bug as on my point it still failing. I'm using a telepathy-sofiasip 0.6.3 on MeeGo and Ubuntu. - Telepathy-sofiasip-0.6.3 rpm package coming from MeeGo repository - telepathy-sofiasip-0.6.3 src files built for my Ubuntu
(In reply to comment #13) > I re-open the bug as on my point it still failing. Please submit detailed logs as described in comment #7.
I have attached 2 logs. localsip and distantsip. The test is: - local call distant. - distant accept the call - both stay in "connecting..."
Created attachment 38298 [details] SIP Log of the caller (local)
Created attachment 38299 [details] SIP log of the called part (distant)
(In reply to comment #16) > Created an attachment (id=38298) [details] > SIP Log of the caller (local) Thanks. The logs look like a normal session is negotiated, but there seem to be no media received. Is IP address 10.255.13.233 reachable from the caller? That's what the callee knows for its address, while the caller's address is set to a public one. I'd like to see traffic dumps, collectable either with tcpdump or by adding TPORT_LOG=1 to telepathy-sofiasip environment. Make sure no SIP connection is on and telepathy-sofiasip is not running, then run in desktop user's shell: export TPORT_LOG=1 TPSIP_PERSIST=1 /usr/lib/telepathy/telepathy-sofiasip Then reproduce the failing call and collect logs from the Empathy window.
Did you still need the telepathy SIP log ? or another one from the "Empathy" debug capability list ?
(In reply to comment #19) > Did you still need the telepathy SIP log ? or another one from the "Empathy" > debug capability list ? Yes, the "sofiasip" log, but with message dumping enabled.
Created attachment 38331 [details] Empathy lodgs New logs
(In reply to comment #21) > Created an attachment (id=38331) [details] > Empathy lodgs > > New logs Perfect, thanks. I see flip-flopping between TCP and UDP in the messages we send. Please set the transport to TCP in your SIP account settings and see if it helps.
This look a odd to me, too: (empathy:1393): tp-fs-DEBUG: stream 0 0x8792630 (audio) cb_fs_local_candidates_prepared: candidate->ip = '0.0.0.0' (empathy:1393): tp-fs-DEBUG: stream 0 0x8792630 (audio) cb_fs_local_candidates_prepared: candidate->ip = '192.168.10.161' cb_fs_new_active_candidate_pair: called: c:1 local: L1 0.0.0.0:7078 remote: L1 192.168.10.187:53288 (empathy:1393): tp-fs-DEBUG: stream 0 0x8792630 (audio) cb_fs_new_active_candidate_pair: called: c:2 local: L1 192.168.10.161:7079 remote: L1 192.168.10.187:53289
the candidate=0.0.0.0 was a bug in an old version of gupnp-igd I think.. Maybe there is a similar bug somewhere else ...
(In reply to comment #24) > the candidate=0.0.0.0 was a bug in an old version of gupnp-igd I think.. Maybe > there is a similar bug somewhere else ... Should we have an option to disable IGD after all? It's insecure by design, it breaks VoIP for unwitting SIP users in a local network, and it introduces this kind of hard-to-triage bugs whenever there is a box that doesn't quite do it right. Even if we implement ICE where it mostly works, this will not help the case when the proxy does not understand ICE, which is still overwhelmingly common.
Could it be possible to get more details on gupnp-igd ? Thx
GUPnP-igd is a gupnp based library to tell UPnP routers to open up ports. Versions before 0.1.7 didn't check for invalid addresses returned by some UPnP routers and so returned 0.0.0.0 was an address. Now it explicits checks for 0.0.0.0 and rejects it. Which distribution are you using ?
I use on MeeGo the version 0.1.7 and on Ubuntu 0.1.3
I have tried by forcing TCP or UDP as transport protocol but it still remain on "disconnecting" status.
(In reply to comment #28) > I use on MeeGo the version 0.1.7 and on Ubuntu 0.1.3 I'm a Telepathy maintainer-in-the-making for MeeGo and I don't yet know how to test VoIP calls there. How do you do it? :) Anyway, this looks like the bug cause is in farsight. I can't just repurpose this bug because it was originally filed with other underlying cause. If you can't solve your problem by disabling UPnP on your network gateway, I suggest you file a bug on Farsight to investigate the bogus transport address problem.
I will try to downgrade the uPnP on my MeeGo release first. For VoIP, I'm only connected on my home network using the set-up box provided by my ISP. Feel free to contact me on my email @intel.com for additional information on how I set-up a VoIP on MeeGo
By farsight, you mean telepathy-farsigth ?
(In reply to comment #32) > By farsight, you mean telepathy-farsigth ? It's rather libfarsight2 (category Farsight in this Bugzilla) that has the code in question, and might offer an option to disable UPnP.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.