Bug 29970

Summary:	Remain in "connecting" state when make a Voice over IP call
Product:	Farstream	Reporter:	Sebastien Cayetanot <sebastien.cayetanot>
Component:	Core	Assignee:	Olivier Crête <olivier.crete>
Status:	RESOLVED NOTOURBUG	QA Contact:
Severity:	normal
Priority:	medium	CC:	sebastien.cayetanot
Version:	unspecified
Hardware:	x86 (IA32)
OS:	other
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=28124 https://bugs.freedesktop.org/show_bug.cgi?id=29805
Whiteboard:
i915 platform:		i915 features:
Attachments:	Empathy logs

Description Sebastien Cayetanot 2010-09-02 03:23:40 UTC

Created attachment 38383 [details]
Empathy logs

My test is to make a Voice over IP call using the empathy/telepathy/SIP
solution. 

My device "A" used empathy 2.30.1 and telepathy-sofiasip-0.6.0

I use 2 remote devices:
- one, named "B" on Windows using X-Lite
- one, named "C" on Ubunutu using empathy/sip solution and LinPhone

I use an internal server named officesip server but same issue is seen using
iptel.org sip provider.

I make a call from device "A" to the device "C". Both are using empathy
solution.

On device "C" the incoming call event appears and I accept the call. In that
case "C" swith from "connecting" to "connected" status but device "A" remain in
'connecting' status until the device "C" disconnect the call due to a Time-out.

The same behavior is observed when the device "A" try to call the windows sip
client "B" or device "C" using linphone. 

I have made a quick test. LinPhone call X-lite and everything works fine. The
issue appears when the telepathy solution is used.

This bug has been previously open on telepathy-sofiasip database and the analysis provided on the log show that issue is coming from farsight

https://bugs.freedesktop.org/show_bug.cgi?id=28124 (most of analysis on latest comments)
duplicate : https://bugs.freedesktop.org/show_bug.cgi?id=29805




Log attached

Comment 1 Sebastien Cayetanot 2010-09-09 01:12:56 UTC

Change product & component family

Comment 2 Sebastien Cayetanot 2010-09-15 07:26:12 UTC

This issue is linked to the uPnP router support.

If the uPnP support is enable the IP address is updated by the uPnP. If there is no uPnP router, the IP adress stay at 0.0.0.0

After the uPnP negociation we should check the IP address. If it's 0.0.0.0 that mean the there is no uPnP router and in that case the IP address should updated with the IP adresse of the device.

As the IP address is still 0.0.0.0 farsight reject the "communication"

Comment 3 Olivier Crête 2010-09-15 07:56:59 UTC

GUPnP-IGD version 0.1.7 and later check for 0.0.0.0 and ignore it.

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.