Bug 1699 - Can't use french sip provider "free" (freephonie.net)
: Can't use french sip provider "free" (freephonie.net)
Status: RESOLVED FIXED
Product: Chat & Call & SMS
SIP
: 3.2
: N800 All
: Low normal with 2 votes (vote)
: 4.0
Assigned To: rtcomm@maemo.org
:
:
: moreinfo
:
:
  Show dependency tree
 
Reported: 2007-07-20 12:00 UTC by Fred Lefévère-Laoide
Modified: 2007-12-19 12:12 UTC (History)
6 users (show)

See Also:


Attachments
SIP and STUN tcpdump trace (12.65 KB, application/octet-stream)
2007-07-23 23:33 UTC, Christophe Teyssier
Details
Tcpdump trace of outgoing call with Twinkle (8.89 KB, application/octet-stream)
2007-07-24 23:26 UTC, Christophe Teyssier
Details
Modified telepathy-sofiasip package (60.76 KB, application/x-deb)
2007-08-03 17:29 UTC, Mikhail Zabaluev
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Fred Lefévère-Laoide (reporter) 2007-07-20 12:00:52 UTC
I can't seem to use my french sip provider with rtcomm. I have it configured
and working with gizmoproject on the N800 and several others sip client on PC.
How can I get logs to help find where the problem lies ?
Thanks for your great work
Fred
Comment 1 Christophe Teyssier 2007-07-20 15:04:44 UTC
I can confirm the bug. Here are some more details:
- registration works
- for outgoing calls, everything seems normal on the N800 the ringing tone is
played, but the callee doesn't actually ring
- for incoming calls, the N800 rings, but answering the call doesn't actually
open the line, the ringing tone is still heard by the caller.

This is all from behind a NAT done by the provider's box. The SIP account can
be used normaly with eg Twinkle on a desktop.

Using Gizmo on the N800, I can make calls but receiving calls leads to the same
problem as with rtcomm.

I'll try and make a tcpdump trace tonight.
Comment 2 Christophe Teyssier 2007-07-21 01:09:26 UTC
Comparing traces from Twinkle with those of rtcomm, here is the main difference
I see for outgoing calls.

In the contact header of the INVITE twinkle uses <sip:account@local_address>
while rtcomm uses <sip:account@public_address:local_port;transport=udp>. I see
the same behaviour with "Discover public address" checked or unchecked. There
is no answer to the INVITE from the server.

I'm not sure that's really what is causing the problem, the same header is used
in REGISTER and we do get a status 200 OK for it. Anyway, if "Discover public
address" is unchecked the public address probably shouldn't appear anywhere.

The Twinkle INVITE also includes a Proxy-Authorization header which is absent
from rtcomm's.

(Note that the freephonie SIP server is a Cirpack.)
Comment 3 Mikhail Zabaluev nokia 2007-07-23 12:04:00 UTC
Thanks for the insightful reporting.
Can you post the trace for N800 as an attachment (provided you have no secrets
to keep in there)?
The use of local port is suspicious. What does the proxy's Via header say in
responses to REGISTER?

P.S. I cannot get to a freephonie.net website. Is there a free registration
page (in English preferably)?
Comment 4 Fred Lefévère-Laoide (reporter) 2007-07-23 13:00:01 UTC
What kind of trace would you like ?
The sip account is provided with an broadband connection, it means that there
are more than 2 millions SIP account with freephonie.net but there's no mean to
get an account outside France (except maybe by contacting directly free.fr ?)
May be you can contact someone via the newsgroup proxad.free.adsl.telephonie
... 
If you need help with translation, let me know ...
Thanks
Comment 5 Frederic Crozat 2007-07-23 20:28:52 UTC
in Advanced SIP setting, try disabling "Detect automatically STUN server" and
set "stun.ekiga.net" as STUN server.

I've contacted Free engineers to see if they could install a STUN server with
relevant SRV DNS record to get it automatically detected. I'm waiting for their
answer.
Comment 6 Christophe Teyssier 2007-07-23 23:33:10 UTC
Created an attachment (id=494) [details]
SIP and STUN tcpdump trace

Ignore traffic on ports 2154 and 2159, they are leftovers from previous
sessions.

The filter used was "host freephonie.net or host stun.ekiga.net".
Comment 7 Christophe Teyssier 2007-07-23 23:35:31 UTC
I've tried using the ekiga stun server, but I'm getting the same result.

About the local port, from the REGISTER reply it seems that the firewall uses
the same source port.

See attachement above for a full trace.
Comment 8 Frederic Crozat 2007-07-24 00:12:02 UTC
I've compared with a registration with Ekiga on freephonie.net and it seems
"Discover public address" isn't working at all (as stated by Christophe), which
is causing an incorrect "Via" during registration, since private IP is sent to
the SIP server.
Comment 9 Mikhail Zabaluev nokia 2007-07-24 17:14:08 UTC
(In reply to comment #6)
> Created an attachment (id=494) [details] [details]
> SIP and STUN tcpdump trace

Thanks a lot. The port in the outbound-augmented Contact: URI is as reported by
in the rport parameter of Via: in responses to REGISTER. If that's incorrect,
blame the proxy or some middleman ALG that might rewrite the header.
Sofia-SIP won't use STUN to discover its public address and port, as it's
discouraged in favor of rport.

NB. the "Cirpack Keep Alive Packet" garbage sent back by the proxy may
contribute to the interop problems.
Comment 10 Mikhail Zabaluev nokia 2007-07-24 17:20:52 UTC
(In reply to comment #8)
> I've compared with a registration with Ekiga on freephonie.net and it seems
> "Discover public address" isn't working at all (as stated by Christophe), which
> is causing an incorrect "Via" during registration, since private IP is sent to
> the SIP server.

AFAIK, it's not wrong to set a private address in Via:, so long as the SIP
stack recognizes this address as its own.

Our "Discover public address" doesn't in fact do anything except appending an
empty "rport" parameter in the Via: for the proxy to fill in; if the proxy
stamps rport/received regardless, it's used by Sofia-SIP no matter what the
setting was. Maybe it's wrong to trust the proxy after all...
Comment 11 Christophe Teyssier 2007-07-24 23:24:11 UTC
> Thanks a lot. The port in the outbound-augmented Contact: URI is as reported by
> in the rport parameter of Via: in responses to REGISTER. If that's incorrect,
> blame the proxy or some middleman ALG that might rewrite the header.

Actually rport is correct. I've run some tests with nmap and the firewall does
use the same source port whenever possible, the headers don't seem to be
fiddled with. Sending back packets works as expected too.

I don't see how the keepalive packets could be the cause of it, it's not the
stack not seing the answer to the INVITE, the answer just never reaches us.

I'm creating a new attachment with a trace from Twinkle in case that may help.
Comment 12 Christophe Teyssier 2007-07-24 23:26:14 UTC
Created an attachment (id=496) [details]
Tcpdump trace of outgoing call with Twinkle
Comment 13 Mikhail Zabaluev nokia 2007-07-25 13:59:46 UTC
So the main difference being, Twinkle doesn't modify Contact: to refer to the
discovered external address, and we do. That might confuse the proxy.
We can implement the "don't discover public address" option in a somewhat
stronger way and disable the Contact modification behavior in Sofia-SIP, but as
the current implementation is, that shuts off keepalive management as well.

Could forcing the transport to TCP (if the proxy supports) be of any help?
Comment 14 Frederic Crozat 2007-07-25 14:32:30 UTC
unfortunately, freephonie.net doesn't support TCP connections.
Comment 15 Mikhail Zabaluev nokia 2007-08-01 14:31:13 UTC
Can you get the source package into Maemo Scratchbox/SDK environment?
The apt source line for the repository is the same as for binaries with change
from deb to deb-src.

If you can grab telepathy-sofiasip source deb, change "use-rport" to "natify"
in src/sip-connection-helpers.c, rebuild the package, install the binary
package onto the device and see if it makes any difference. I would very
appreciate that.
Comment 16 Mikhail Zabaluev nokia 2007-08-03 17:29:46 UTC
Created an attachment (id=508) [details]
Modified telepathy-sofiasip package

OK, here's an updated package to try.

Unchecking the "Discover public address" will put the SIP stack into
NAT-unaware mode (RTP might still work with STUN though). After testing if that
helps, you might want to set the keepalive mechanism to REGISTER, to keep some
connection renewal requests going.
Comment 17 Fred Lefévère-Laoide (reporter) 2007-08-03 17:39:16 UTC
Sorry can't install can't install telepathy-sofiasip_0.3.27 over 0.3.26 ...
Comment 18 Mikhail Zabaluev nokia 2007-08-03 17:44:22 UTC
(In reply to comment #17)
> Sorry can't install can't install telepathy-sofiasip_0.3.27 over 0.3.26 ...

Why so? What's in the log?
Can you do it in a terminal or an SSH shell with 'dpkg -i'?
Comment 19 Fred Lefévère-Laoide (reporter) 2007-08-03 17:49:37 UTC
Section is not user/
<Quote> Package must have "Section: user/FOO" to be considered compatible
Comment 20 Fred Lefévère-Laoide (reporter) 2007-08-03 17:53:24 UTC
I could install it via dpkg -i
Comment 21 Mikhail Zabaluev nokia 2007-08-03 18:11:00 UTC
(In reply to comment #20)
> I could install it via dpkg -i

Unfortunately, it's the only way to install the modified package ATM.
Comment 22 Frederic Crozat 2007-08-03 18:43:28 UTC
using red pill mode allows to install the package using Application Manager ;)

I've just tested here (behind a NAT firewall) with outgoing calls, with both
Discovery Public address enabled or not (and STUN server configured on
ekiga.net), without any luck.

I can't give you tcpdump unfortunately.
Comment 23 Frederic Crozat 2007-08-03 23:53:46 UTC
I've upgrade the entire stack with rtcomm 1.0.3 released today (in addition to
telephaty-sofiasip package provided by Mikhail), still no luck.
Comment 24 Mikhail Zabaluev nokia 2007-09-10 15:39:18 UTC
After looking through the logs again, maybe it's the problem with address in
the outgoing call (can't see any anomaly otherwise).
Can you create your SIP contact as a full SIP URI in the N800 address book,
e.g. 'sip:<number>@freephonie.net'?
Comment 25 Frederic Crozat 2007-09-11 00:56:15 UTC
Just tested, I get the same problem.
Comment 26 Mikhail Zabaluev nokia 2007-09-11 10:37:24 UTC
Sorry, I'm out of ideas.
As this seems to be rather unique, I'd like somebody from technical staff at
the operator shed some light on the nature of the problem.
Comment 27 Rodrigo Linfati 2007-12-02 07:10:36 UTC
With http://www.voipdiscount.com/ is the same, connect, but not call
Comment 28 Saturn 2007-12-02 14:18:52 UTC
Hi, 

Can confirm that it behaves similarly to both www.voipdiscount.com and
www.voipbuster.com. 

That is, you can connect, people see you connected but no call out/in can be
made. I'm 100% that the settings are the same I used to have with 2007OS which
worked daily. 

My new N800/2008OSBeta installation is minimal (no
gizmo,skype,python,multimedia programs etc) and without a recovered backup.

Thanks for your efforts and don't hesitate to ask me to test any of your tries.

Chris
Comment 29 Mikhail Zabaluev nokia 2007-12-03 13:59:34 UTC
(In reply to comment #28)
> Can confirm that it behaves similarly to both www.voipdiscount.com and
> www.voipbuster.com. 

Isn't it one of those small SIP service providers which all seem to run the
same web frontend and the same SIP proxy/GW software?
Good chances are that you can make voip[catchyword].com work by disabling the
iLBC codec. Here's how to do it in the on-screen terminal or an SSH shell (the
red pill mode might be helpful here).

1. sudo gainroot
2. cd /usr/lib/gstreamer-0.10
3. mv libgstdspilbc.so libgstdspilpbc.so.off
Comment 30 Rodrigo Linfati 2007-12-03 14:14:58 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Can confirm that it behaves similarly to both www.voipdiscount.com and
> > www.voipbuster.com. 
> 
> Isn't it one of those small SIP service providers which all seem to run the
> same web frontend and the same SIP proxy/GW software?
> Good chances are that you can make voip[catchyword].com work by disabling the
> iLBC codec. Here's how to do it in the on-screen terminal or an SSH shell (the
> red pill mode might be helpful here).
> 
> 1. sudo gainroot
> 2. cd /usr/lib/gstreamer-0.10
> 3. mv libgstdspilbc.so libgstdspilpbc.so.off

Work OK, now i can call in my nokia n800 :)

/me happy
Comment 31 Laurent GUERBY 2007-12-08 19:36:48 UTC
I assume no solution yet for freephonie?
Comment 32 Frederic Crozat 2007-12-09 09:31:07 UTC
IT 2008 works on "freephonie" when using internal SSID "freephonie" (available
since last wednesday) which doesn't use any NAT.

This validates the fact NAT handling in sofiasip is broken with "free" Cirpack
SIP stack.
Comment 33 Saturn 2007-12-09 16:17:11 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Can confirm that it behaves similarly to both www.voipdiscount.com and
> > www.voipbuster.com. 
> 
> Isn't it one of those small SIP service providers which all seem to run the
> same web frontend and the same SIP proxy/GW software?

Don't know if this is irony or question; in case this is a question: I wouldn't
say small (at least in europe). They use the same/similar frontends as they get
support by the same company or some of them belong to one company with
different 'free-call' countries.

> Good chances are that you can make voip[catchyword].com work by disabling the
> iLBC codec. Here's how to do it in the on-screen terminal or an SSH shell (the
> red pill mode might be helpful here).
> 
> 1. sudo gainroot
> 2. cd /usr/lib/gstreamer-0.10
> 3. mv libgstdspilbc.so libgstdspilpbc.so.off
> 

It seems to do the trick. 

Mikhail, thanks a lot for looking into this and giving us a solution.
Comment 34 Mikhail Zabaluev nokia 2007-12-10 13:28:37 UTC
*** Bug 2508 has been marked as a duplicate of this bug. ***
Comment 35 fremwi 2007-12-11 16:35:24 UTC
Hello,
I just join the discussion.
My IAP is Free, and I try to gain access to the SIP account.
The box is on IP/ADSL with fix IP and router activated (a desktop, a notebook,
a network printer and the n800 have access to the internet) through wired or
wireless interface.

I rename libgstdspilbc.so without effect.
I hear the ringing tone, but the correspondant doesn't hear anything.
For incoming calls, I receive the ringing tone, but nothing when I hang up.

I put a router/wifi behind the freebox. I suppose I can't get the benefit of
the freephonie ssid (the wifi is connected to the ethernet port of the
freebox).

What to do?
Comment 36 Frederic Crozat 2007-12-18 23:43:30 UTC
good news : I've just tested IT2008 2007.50-2 n800 image and everything is now
working fine with Free freephonie.net cirpack SIP server. It appears sofia SIP
has been fixed with NAT transversal. 

I'll need to do some additional tests from a several AP.

Could other people test too ?
Comment 37 fremwi 2007-12-19 04:47:13 UTC
Great! It works fine with the last image on n800 with the config described on
#35 (the worst).
Well done...
The bug seems to be solved.
Comment 38 Fred Lefévère-Laoide (reporter) 2007-12-19 11:16:56 UTC
It works for me too ... I'll try it with the freephonie network as soon as I
get close to one ...
A big thanks to the team !!!

Fred
Comment 39 Mikhail Zabaluev nokia 2007-12-19 11:20:51 UTC
Thanks for the good news.
Does it work with plain defaults, or did you have to tweak anything in the
Advanced settings of the SIP account?
Comment 40 Frederic Crozat 2007-12-19 12:12:22 UTC
it works perfectly with default settings, no need to change anything.