SIP calls no longer work (Incompatibility with telepathy-sofiasip)

Bug #409103 reported by Eric Drechsel on 2009-08-04
58
This bug affects 12 people
Affects Status Importance Assigned to Milestone
telepathy-sofiasip
Won't Fix
Medium
telepathy-sofiasip (Debian)
New
Unknown
telepathy-sofiasip (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: empathy

I've tested behind several NAT connections, although not with a public IP. I'm unable to call out or receive calls using gizmo (sipphone.com) and ekiga.net although incoming calls ring. I've tested using the Jaunty packages and am currently running the Telepathy PPA packages in Jaunty. Can others please test with your SIP services/network configurations and report results?

BTW, I have tested behind a NAT router with DMZ turned on, so it's an optimally-configured NAT.

Eric Drechsel (ericdrex) wrote :

The upstream issue in #2 and https://bugs.launchpad.net/telepathy-sofiasip/+bug/294994 indicate failure to register, whereas I am experiencing failure to initialize in/out calls, with registration working fine behind NAT with both services. Separate issues?

Eric Drechsel (ericdrex) wrote :

This is the exact issue, same debug logs I get: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796

affects: empathy (Ubuntu) → telepathy-sofiasip (Ubuntu)
Eric Drechsel (ericdrex) wrote :

Found the same issue reported in the upstream tracker: https://bugs.freedesktop.org/show_bug.cgi?id=21973

Also attached the output of "TPORT_LOG=true SOFIASIP_DEBUG=all SOFIASIP_PERSIST=true \
 /usr/lib/telepathy/telepathy-sofiasip". I think the relevant line is:
** (telepathy-sofiasip:15045): DEBUG: tpsip_media_stream_error: StreamHandler.Error called: 0 Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist

Brian Curtis (bcurtiswx) wrote :

Thanks for the bug report and helping to make Ubuntu better. Please add comments to the bug this is marked as a duplicate of. https://bugs.edge.launchpad.net/telepathy-sofiasip/+bug/294994

Eric Drechsel (ericdrex) wrote :

Actually bug #294994 is about REGISTER failing with certain providers and network configurations, but this bug is about telepathy-sofiasip being out of sync with the telepathy APIs so that calls hang (but register works). Note that this is with the Jaunty packages in https://launchpad.net/~telepathy/+archive/ppa.

summary: - gizmo/sofia-sip calls fail to connect behind NAT
+ SIP calls no longer work (Incompatibility with telepathy-sofiasip)
Jorge Castro (jorge) on 2009-09-02
Changed in telepathy-sofiasip (Ubuntu):
status: New → Triaged
Changed in telepathy-sofiasip (Ubuntu):
importance: Undecided → Medium
tags: added: regression-release

Created an attachment (id=29981)
empathy.log

I set up one of my SIP account in empathy and can receive calls, but I'm unable
to place any calls. Ekiga works just fine with the same account.

When I call an SIP contact, a connection window opens and it says
"Connecting..." in the status bar for about a minute, and then "Disconnected".

I attached debug logs from both empathy and telepathy-sofiasip, with my phone
number masked out.

I originally reported this as https://bugzilla.gnome.org/show_bug.cgi?id=596887 but was asked to report it again here.

Created an attachment (id=29982)
sogiasip.log

Changed in telepathy-sofiasip (Debian):
status: Unknown → New

The proxy responds with 480 request timeout. Probably the VoIP gateway becomes terminally confused with your SDP offer. Which, among other interesting things, contains two DTMF payloads with different bitrates. I'll file a Farsight bug about this.

As a possible workaround, try to switch off the funky 16 bit codecs such as SPEEX and SIREN.

(In reply to comment #3)
> As a possible workaround, try to switch off the funky 16 bit codecs such as
> SPEEX and SIREN.

I mean the 16kbps codecs, of course.

Thanks for looking into this. I just disabled SPEEX and SIREN by editing the non-configuration file /usr/share/empathy/codec-preferences. It doesn't change anything. The codecs now appear as follows in the debug log, but everything else remains the same.

(empathy:15241): tp-fs-DEBUG: New stream, stream_id=0, media_type=0, direction=2
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) get_all_properties_cb: Adding STUN server (old API) 217.10.79.2:10000
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: called (send_local:1 send_supported:0)
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: 0: audio PCMU clock:8000 channels:0
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: 8: audio PCMA clock:8000 channels:0
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: 3: audio GSM clock:8000 channels:0
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: 99: audio telephone-event clock:8000 channels:0 events=0-15
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) fs_codecs_to_tp: adding codec PCMU [0]
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) fs_codecs_to_tp: adding codec PCMA [8]
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) fs_codecs_to_tp: adding codec GSM [3]
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) fs_codecs_to_tp: adding codec telephone-event [99]
(empathy:15241): tp-fs-DEBUG: stream 0 0x191e180 (audio) _tf_stream_try_sending_codecs: calling MediaStreamHandler::Ready

So, if this is listed as 'notourbug', whose bug is it?

(In reply to comment #6)
> So, if this is listed as 'notourbug', whose bug is it?

The gateway's, or the proxy's, if my assumption is right.
It should ignore the payloads in SDP it does not support.

(In reply to comment #5)
> Thanks for looking into this. I just disabled SPEEX and SIREN by editing the
> non-configuration file /usr/share/empathy/codec-preferences. It doesn't change
> anything. The codecs now appear as follows in the debug log, but everything
> else remains the same.

Try also disabling the GSM codec.
It might be also the telephone-event payload (DTMF) that's causing trouble, I don't remember how to disable it.

Alright, I disabled both telephone-event and GSM, and I still can't connect. Attached are my latest logs from empathy and telepathy-sofiasip, and my codec-preferences file. This is also with the latest packages from debian unstable, i.e. empathy 2.28.1.1-1 and telepathy-sofiasip 0.5.18-1.

Created an attachment (id=30776)
New Empathy Log

Created an attachment (id=30777)
New Sofiasip Log

Created an attachment (id=30778)
coded-preferences

To get a useful log from tp-ssip, you need to set TPORT_LOG=1
Also, when you attach files, please set the right mime-type (in this case, text/plain)

Thanks for mentioning the tport debug option. Looking at these logs, I see a "407 Proxy Authentication Failed" message. I'm investigating with my sip provider to figure out what's going on.

Wouldn't it be nice if empathy would pass this error on to the user?

Lyle Underwood (lyleunderwood) wrote :

As of right now I'm current on the Lucid beta, and I'm affected by this bug. telepathy-sofiasip is essentially useless. I register flawlessly every time, but calls hang until I force the process to end. Debug output is the same as above.

Eric Drechsel (ericdrex) wrote :

Fixed in Lucid, by my testing (also confirmed upstream)

Changed in telepathy-sofiasip (Ubuntu):
status: Triaged → Fix Released
Changed in telepathy-sofiasip:
importance: Unknown → Medium
status: Unknown → Won't Fix
Changed in telepathy-sofiasip:
importance: Medium → Unknown
Changed in telepathy-sofiasip:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.