Using the built-in telepathy-rakia for SIP calls

I’ve really been wanting to use my Sailfish device to make SIP calls. I’ve looked at https://together.jolla.com/question/415/sip-voip-native-integration/ where I managed to set up the account, get it registered with my asterisk server and am now trying to make a call.

I don’t see any INVITE messages arriving on my server. What I do see arriving is:

REGISTER without authentication, which asterisk answers with 401 Unauthorized
REGISTER with authentication, which is answered with a 200 OK
OPTIONS for a REGISTRATION PROBE, which gets a 404

I use the following dbus command:

gdbus call -e -d org.nemomobile.voicecall -o / -m org.nemomobile.voicecall.VoiceCallManager.dial /org/freedesktop/Telepathy/Account/sofiasip/sip/sip_5 <number>

The dialer overview shows an active call, stuck on 0 seconds and a hangup button, the dialer app when opened does not change, however.

What could be the reason the call is not going out?

1 Like

I think you might want to check out s1p. If I understood correctly, unmaintained implemented the missing ‘glue’ between the telepathy components and the UI/a dialer

1 Like

I have actually tried s1p, but that one seems even less functional than the built-in telepathy-rakia. s1p simply refuses to register. It does send a REGISTER request, but does not include a digest, and when asterisk sends it a 401 back with a request for a digest, s1p simply resends the request without a digest.

I’m not looking for a GUI-solution. I would like to use the built-in SIP account functionality, but the call just seems to get stuck at some point. Maybe there is a way to get debug output from it? I was unable to find any.

I’m using s1p with Asterisk every day.
When have you tried it the last time?
New versions are being released basically every other day. Also worth reporting the issue.

I update regularly - installed it through Storeman. Just updated it to 0.4.6-1. It still shows me the same behaviour. I get something like this:

<--- SIP read from UDP:PUBLIC-PHONE-IP:61159 --->
REGISTER sip:ASTERISK-HOSTNAME;transport=UDP SIP/2.0
Via: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-d1e68d7;rport
From: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=7b4e7c02
To: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>
Call-ID: 49c7e2d0@INTERNAL-PHONE-IP
CSeq: 1 REGISTER
Allow: INVITE, ACK, CANCEL, BYE
Contact: <sip:REGEXTEN@INTERNAL-PHONE-IP:5060>
Expires: 3600
Max-Forwards: 69
User-Agent: s1p
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to PUBLIC-PHONE-IP:61159 (NAT)

<--- Transmitting (NAT) to PUBLIC-PHONE-IP:61159 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-d1e68d7;received=PUBLIC-PHONE-IP;rport=61159
f: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=7b4e7c02
t: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=as2e83d04e
i: 49c7e2d0@INTERNAL-PHONE-IP
CSeq: 1 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="ASTERISK-HOSTNAME", nonce="44f88aa0"
l: 0

<------------>

<--- SIP read from UDP:PUBLIC-PHONE-IP:61159 --->
REGISTER sip:ASTERISK-HOSTNAME;transport=UDP SIP/2.0
Via: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-392a079f;rport
From: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=7917001d
To: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>
Call-ID: 22c5d293@INTERNAL-PHONE-IP
CSeq: 2 REGISTER
Allow: INVITE, ACK, CANCEL, BYE
Contact: <sip:REGEXTEN@INTERNAL-PHONE-IP:5060>
Expires: 3600
Max-Forwards: 69
User-Agent: s1p
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to PUBLIC-PHONE-IP:61159 (NAT)
Sending to PUBLIC-PHONE-IP:61159 (NAT)

<--- Transmitting (NAT) to PUBLIC-PHONE-IP:61159 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-392a079f;received=PUBLIC-PHONE-IP;rport=61159
f: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=7917001d
t: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=as2ed9a744
i: 22c5d293@INTERNAL-PHONE-IP
CSeq: 2 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="ASTERISK-HOSTNAME", nonce="1e142280"
l: 0

<------------>

<--- SIP read from UDP:PUBLIC-PHONE-IP:61159 --->
REGISTER sip:ASTERISK-HOSTNAME;transport=UDP SIP/2.0
Via: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-15ea4626;rport
From: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=189eeb98
To: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>
Call-ID: 73885d03@INTERNAL-PHONE-IP
CSeq: 3 REGISTER
Allow: INVITE, ACK, CANCEL, BYE
Contact: <sip:REGEXTEN@INTERNAL-PHONE-IP:5060>
Expires: 3600
Max-Forwards: 69
User-Agent: s1p
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to PUBLIC-PHONE-IP:61159 (NAT)
Sending to PUBLIC-PHONE-IP:61159 (NAT)

<--- Transmitting (NAT) to PUBLIC-PHONE-IP:61159 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-15ea4626;received=PUBLIC-PHONE-IP;rport=61159
f: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=189eeb98
t: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=as1f13d600
i: 73885d03@INTERNAL-PHONE-IP
CSeq: 3 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="ASTERISK-HOSTNAME", nonce="76e282ec"
l: 0


<------------>

<--- SIP read from UDP:PUBLIC-PHONE-IP:61159 --->
REGISTER sip:ASTERISK-HOSTNAME;transport=UDP SIP/2.0
Via: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-7cb4ad0a;rport
From: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=3a527935
To: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>
Call-ID: 3c571d3@INTERNAL-PHONE-IP
CSeq: 4 REGISTER
Allow: INVITE, ACK, CANCEL, BYE
Contact: <sip:REGEXTEN@INTERNAL-PHONE-IP:5060>
Expires: 3600
Max-Forwards: 69
User-Agent: s1p
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to PUBLIC-PHONE-IP:61159 (NAT)
Sending to PUBLIC-PHONE-IP:61159 (NAT)



<--- Transmitting (NAT) to PUBLIC-PHONE-IP:61159 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/UDP INTERNAL-PHONE-IP:5060;branch=z9hG4bK-7cb4ad0a;received=PUBLIC-PHONE-IP;rport=61159
f: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=3a527935
t: <sip:REGEXTEN@ASTERISK-HOSTNAME;transport=UDP>;tag=as22600957
i: 3c571d3@INTERNAL-PHONE-IP
CSeq: 4 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="ASTERISK-HOSTNAME", nonce="74e20ff1"
l: 0


<------------>

It just keeps sending the same REGISTER request, but it refuses to authenticate, despite me putting in an Authentication User and Password

That could be an indication it does not receive the

response somehow.

You could check on the s1p log page if it’s receiving anything from the SIP server.

s1p is a standalone app deliberately bypassing all the various not officially supported components.

1 Like

I have just send the logs from the log page to the developer, which I guess means you.

From what I can tell, s1p fails to find the right dialog when it gets the 401 and therefore discards it. It gives the following error:

ERROR [SipServer-1] HandleResponseUnauthorized [] - dialog not found

It seems like a bug in s1p. The request has a Call-ID header, which is included in the response in the i header field. Perhaps s1p expects the header to be named differently?

0.4.6 is ancient by s1p standards :slight_smile:
Could you please try with version 0.4.8

1 Like

Well, it was the last version when I checked yesterday…

Anyways, the latest version does indeed register and I managed to successfully make a call, so all seems to work well.

Is your plan to eventually get s1p part of sailfish itself? It would be really nice to have something which is integrated with the rest of the system. It’s strange that I cannot make calls with the built-in SIP support, not even from the CLI when others have reported that it works. I wanted to see if I could make a patch for the People and Dialer apps.

Anyways: Thanks for making s1p, and for fixing the bug. Now I can finally make those free SIP calls from my SFOS device!

That’s why I attached this guy :slight_smile: to the statement.

Negative. I would rather see it develop into a full-featured SIP client application than a half-assed (see XMPP) integration into the base system that requires everyone working on it to sign a NDA with Jolla.

I’ve waited for this since 2013 :neutral_face:

Turns out my excitement was shortlived. I managed to make exactly one call with s1p, which worked great. Later calls I tried were unsuccessful since there was no sound either way.

Interestingly, the logs (which I have submitted under id 43 BTW), show a lot of

TRACE [RTPServer-2] PlaybackSamples - playback disabled - samples: xxx, closed: false

which might be related. Also, registration apparantly also still does not work, but that’s no longer apparant from the dialer page. Somehow the generated digest is not accepted. I calculated the digest myself for the given nonce and it’s indeed different. Not completely sure about that, might be using the wrong input for my hashes.

BTW: Used this as script to calculate digest, perhaps @unmaintained will know whether it’s correct

 #!/usr/bin/env python2

from md5 import md5


login = '<username>'
uri = 'sip:<domain>'
nonce = '4fc79bb2'
realm = '<domain>'
password = '<password>'

str1 = md5("{}:{}:{}".format(login,realm,password)).hexdigest()
str2 = md5("REGISTER:{}".format(uri)).hexdigest()
str3 = md5("{}:{}:{}".format(str1,nonce,str2)).hexdigest()
print(str3)

Have you calculated both, the one used for REGISTER and the one for INVITE as the latter seems to be accepted just fine? (can’t check it myself without knowing your password)

Also, does this mean at least one call did work with functioning audio both ways? And was it the same version as the one that fails?

It indicates s1p is still receiving some RTP traffic after it sent the BYE request which is normal as the server will need some time to react to the BYE and stop sending samples.
This also means audio packets must have been received up until the very end of the call.

I only calculated the one used for the REGISTER call. If it helps, I could temporarily set the password to something silly, make a call and send you the logs and a PM with the temporary password.

And yes, the very first call I made did indeed work. This was with version 0.4.9. I have, of course, tried downgrading s1p to see whether it is caused by a regression of some sort, but to no avail.