s1p
s1p is an experimental SIP client for Sailfish OS
Successfully tested with:
- Asterisk
- 3CX
- Yate
- FritzBox
- sipgate.de
- sipgate.co.uk
- sipnet.ru
- easyfone.de
- linphone.org
- cellip.com
- easybell.de
- eventphone.de
- nfon.com
- voip.ms
- voipraider.com
- peoplefone.de
- messagenet.com
- linkspace.it
(please add a comment if you have been able to make it work with a provider not listed above)
Please don't forget to restart the app after making any changes to the settings.
New Salfish versions block access to the contacts database for 3rd party apps. To be able to see your contacts in s1p you have to copy the database file (as root) into the s1p data directory:
devel-su cp -r ~/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db ~/.local/share/harbour-s1p/
Screenshots:
Category:
Keywords:
Application versions:
Changelog:
- 0.9.9 disables sandboxing to fix startup issues
- 0.9.8 allows dialing numbers saved in notes field (and X-SIP field) from contacts.
- 0.9.7 fixes account description, disables issues tracker
- 0.9.6 fixes audio output selection issues introduced with Sailfish 4.1.0.23
- 0.9.5 added direct access to contacts.db, user accessible database may be not up to date, though
- 0.9.4 minor imporvements to input fields, copying numbers from call history
- 0.9.3 fixes issues with early media
- 0.9.2 fixes some issues with FritzBox
- 0.9.1 fixes some issues with linphone.org
- 0.9.0 fixes default primary account setting
- 0.8.9 adds support for multiple active accounts
- 0.8.8 adds auto-answer
- 0.8.7 opens active account section (instead of always the first section) in settings dialog.
- 0.8.6 adds avatar image for ongoing calls
- 0.8.5 fixes disappearing hangup cover action after a call has been answered
- 0.8.4 fixes double entries in call history, fixes lookup of contacts in call history
- 0.8.3 improves audio routing, removes annoying switch to pre-call audio state with last samples still being played.
- 0.8.2 adds log upload to issues tracker
- 0.8.1 introduces (optional) log file (~/.local/share/harbour-s1p/s1p.log)
- 0.8.0 fixes issues with additional incoming calls during an already establiched call
- 0.7.9 introduces changes to the binary size for faster startup
- 0.7.8 fixes deleting call history, adds remorse timer to delete
- 0.7.7 fixes adding SIM calls to history when disabled, adds experimental issues tracker.
- 0.7.6 adds cellular call history integration
- 0.7.5 adds better notification handling, bringing UI to foreground on incoming calls
- 0.7.4 fixes double notifications
- 0.7.3 adds notifications, changes the way SIP daemon and UI communicate enabling background operations in the future.
- 0.7.2 fixes microphone input with headsets
- 0.7.1 fixes issue with receiving rtp traffic when local IP changes
- 0.7.0 changes to external IP address handling, crash handling, length of call-id and tags
- 0.6.9 fixes screen unlock on incoming calls
- 0.6.8 adds support for hardware/headset buttons to configuration page
- 0.6.7 fixes server port data type
- 0.6.6 adds support for additional SIP accounts (only one at a time can be active)
- 0.6.5 testing FritzBox 7590 compatibility
- 0.6.4 adds less used DTMF digits (A-D,F) to pulley menu, reduces ambiguity with status messages
- 0.6.3 minor visual changes to the cover page
- 0.6.2 adds contact name lookup by phone number
- 0.6.1 adds minor visual improvements to the call history and contacts pages
- 0.6.0 adds minor visual improvements to the contacts page
- 0.5.9 adds voicemail icon and counter
- 0.5.8 adds default audio port selector to settings dialog
- 0.5.7 adds Yate compatibility
- 0.5.6 adds audible ringback tone
- 0.5.5 adds compatibility with Easybell
- 0.5.4 testing compatibility with Easybell
- 0.5.3 fixes issues with saving display names in call history
- 0.5.2 adds display name to call history
- 0.5.1 fixes phone number in history page
- 0.5.0 adds call history page
- 0.4.9 adds small visual improvements to the UI
- 0.4.8 improves compatibility with pjsip
- 0.4.7 fixes error in media description parser
- 0.4.6 improves compatibility with 3CX
- 0.4.5 adds rport option
- 0.4.4 allows to set bind port on the settings page
- 0.4.3 adds support for buttons on wired headsets to allow answering / hanging-up calls
- 0.4.2 adds display activation on incomming calls
- 0.4.1 fixes misleadling log entries related to RTP destination address
- 0.4.0 adds codec selector in settings dialog
- 0.3.9 adds locking down to one of the available codecs when answering a call
- 0.3.8 adds workaround for 3cx
- 0.3.7 reinstates stricter approach to call progess messages
- 0.3.6 allows a more flexible approach to call progess messages
- 0.3.5 fixes proxy-authentication
- 0.3.4 adds support for display name
- 0.3.3 fixes previously broken default settings
- 0.3.2 fixes regsitering with sip.linphone.org
- 0.3.1 sets default register frequency to 1 hour
- 0.3.0 adds options for bind address and regsiter frequency
- 0.2.9 enables voicemail button, fixes issues with number input
- 0.2.8 fixes issues with setting latency and buffer length
- 0.2.7 adds configuration dialog options for latency and audio buffer length
- 0.2.6 adds configuration-file options for latency and audio buffer length
- 0.2.5 adds improvements to power consumption, audio handler and playback buffer
- 0.2.4 adds preferrence for domain instead of IP in SIP dialogs and adds auth-name field to SIP account settings
- 0.2.3 adds initial DTMF support
- 0.2.2 fixes call status being sometimes overwritten by regstration status
- 0.2.1 adds DNS SRV record lookup
- 0.2.0 adds G.711 μ-law codec, (hopefully) fixes some call-state issues
- 0.1.9 fixes choppy audio on some phones
- 0.1.8 makes some changes to how audio frames are handled
- 0.1.7 adds volume presets
- 0.1.6 enables mute button
- 0.1.5 fixes issues with audio output selection
- 0.1.4 enables audio output selection buttons
- 0.1.3 improves logging and handling of audio packets
- 0.1.2 adds log upload
- 0.1.1 adds contacts page
- 0.1.0 improves UI
- 0.0.9 fixes issues with outbound calls through sipgate
- 0.0.8 fixes inbound calls with sipgate (cancelling outbound calls still broken)
- 0.0.7 fixes some issues with sipgate (inbound calls still broken)
- 0.0.6 improves UI and makes hanging up calls more reliable
- 0.0.5 adds ringtones
- 0.0.4 fixes registering issues with antisip.com
- 0.0.3 adds log page
- 0.0.2 initial release
Comments
unmaintained
Sat, 2020/08/01 - 11:02
Permalink
Beginning with version 0.4.5 you should be able to activate the rport tag as an option on the settings page
emsys
Sat, 2020/08/01 - 21:19
Permalink
Thanks for the quick update. I can now register via NAT, and can also make and receive calls when away from home.
The call hangup issues is still there and if my call ends up in a voice mailbox, I cannot hangup from s1p. I wish you could work on a solution for that issue.
unmaintained
Mon, 2020/08/03 - 10:38
Permalink
This issue should have been fixed with version 0.4.6.
emsys
Mon, 2020/08/03 - 11:23
Permalink
With version 0.4.6, s1p can indeed hangup a call without waiting for the other side to hangup. Thanks for the fix.
Trenien
Sun, 2020/07/26 - 12:24
Permalink
Excellent!
So far, no issue with it (version 0.4.0-1 on Xperia X)
Thanks!!!
Anybody knows how to configure the phone to be able to answer incoming calls without having to unlock it first?
unmaintained
Wed, 2020/07/29 - 13:39
Permalink
Locking the screens seems to work over dbus but it seems not to be possible to unlock it that way.
petros
Thu, 2020/07/23 - 12:22
Permalink
great app, finally we can use sip as we could do natively on N9. works perfectly with justvoip. many thanks for you work
unmaintained
Sun, 2020/07/26 - 12:09
Permalink
Thank you.
Coming from the N900 I've alse been disappointed SIP was not available on SFOS from the start.
ichthyosaurus
Fri, 2020/07/17 - 13:47
Permalink
Thank you for your work!
Just a small thing: would you mind adding new changelog entries at the top? You can use the 'tac' command on GNU/Linux to reverse the existing entries.
unmaintained
Fri, 2020/07/17 - 14:35
Permalink
done
llv95dno
Thu, 2020/07/16 - 20:46
Permalink
Hi, thank you for your hard work. It started to work for me through provider sip.cellip.com with version 0.3.6 (only occasional problem with hangup), but stopped with 0.3.7. Sent you a log, hopefully you can make something out of it. It says: ERROR [Sipserver-1] Invite [3ed90a39@10.6.179.208]
INVITE (authenticated) already set
unmaintained
Fri, 2020/07/17 - 14:44
Permalink
Seems to be the same issue @emsys has with 3CX.
s1p stumbles over a "401 Unauthorized" when it does not expect it. I tried to relax this behavior in 0.3.6 but it confused the UI so I had to revert back to a more rigid scheme.
llv95dno
Sat, 2020/07/18 - 00:20
Permalink
Ok thank you. It seems that you are right. Checked with the provider and they use 3CX. 0.3.6 worked quite well for me, and if it is possible to revert (could not find 0.3.6), I would be glad to do so, until the problem is solved.
unmaintained
Sat, 2020/07/18 - 11:21
Permalink
You could try version 0.3.8 instead.
llv95dno
Sun, 2020/07/19 - 11:18
Permalink
Thanks. It works, still occasional problem with hangup.
unmaintained
Sun, 2020/07/26 - 12:12
Permalink
I'm not entirely sure where these may come from and getting a 3CX instance working to test against unfortunately proved to be super hard.
emsys
Wed, 2020/07/15 - 01:03
Permalink
Hello, First of all, I would like to congratulate you for taking this initiative for a long overdue feature of SFOS.
I tried to test your app on Xperia XA2 with a self hosted 3CX PBX installed on a Raspberry Pi in a LAN configuration. The application fails to authenticate with the PBX and gets stuck in an infinite authentication loop until SFOS flags the application as non-responsive and hence offers to terminate the application. The app gets stuck on subsequent restarts since it gets stuck in the authentication loop, and hence I cannot extract/send the log file from within the app.
However, I started the app from command line and was able to capture the debug log. What I think goes wrong is that the PBX returns a 407 Proxy Authentication Required response and s1p sends an Authorization header instead of a Proxy-Authorization header. Interesting sections in the log go like this:
This ping pong continues without any delay until the app is terminated by the OS.
When I compare this with the SIP registration session of my Gigaset DX800A phone with the same PBX and same extention, I indeed see that the phone sends a Proxy-Authorization header in response to 407 Proxy Authentication Required.
Here is a link to RFC2617 that also confirms this: https://tools.ietf.org/html/rfc2617#section-3.6
I have also recorded wireshark logs for both s1p and my Gigaset phone, please let me know if there is a way I can send them to you. For further testing, please feel free to contact me.
Thanks
unmaintained
Wed, 2020/07/15 - 02:05
Permalink
Could you please check if this issue occurs with version 0.3.5 as well?
emsys
Wed, 2020/07/15 - 12:21
Permalink
Thanks for the new release; I can confirm that the 0.3.5 version sends Proxy-Authorization header in response to code 407 Proxy Authentication Required during REGISTER sequence.
However, when I try to make a local call to another extension, the PBX responds again with a 407 Proxy Authentication Required code in response to the INVITE request. s1p sends ACK but never sends the INVITE again with the Proxy-Authorization header included.
When I compare this with my desk phone, I see that the phone sends the INVITE again with Proxy-Authorization header, to which the PBX then responds with 100 Trying.
I have sent the log file via s1p, log id: 28
unmaintained
Wed, 2020/07/15 - 12:53
Permalink
Thank you for providing the log dump.
Does this issue still occur with version 0.3.6 ?
emsys
Wed, 2020/07/15 - 18:36
Permalink
Thanks for the new release. With v0.3.6, I can now make and receive calls via s1p as it sends INVITE again with Proxy-Authorization header included when requested by PBX.
However, I encounter the following two issues now.
1. Call Hangup issue, log file: 29
Call hangup from within s1p does not work when a call is initiated by s1p. But if the call is terminated by the other party, then s1p can also hang up. The app status changes to "Hangup Reuqested" but the call continues on the other end unless hung up from the other side as well. s1p then returns to idle.
What I see in the wireshark logs on my PBX is that the PBX simply ignores the BYE request sent by s1p. Neither does it respond to s1p, nor does it send BYE to the other party. The call keeps going between the PBX and the other party until I end the call from the other phone. In that case, the desk phone sends BYE to PBX and PBX then sends BYE to s1p, and the call is terminated.
An interesting fact that I noted in wireshark was that if I dial s1p from my desk phone, and then end the call from the desk phone as well, I see that the phone sends Proxy-Authorization header in BYE request as well. In comparison, s1p does not include the Proxy-Authorization header when trying to terminate the call.
Another point of interest is that if s1p initiates the call, and the phone ends it, the phone does not send Proxy-Authorization header in BYE request. It only does so for the call that is initiated from the phone itself.
2.1. No Audio when receiving a call from desk phone, log file: 30
When I dial s1p from my desk phone, the call is established, but there is no call audio at all, not from the speaker, headset, or earpiece of the Xperia. There is no audio on the phone either. (Audio however works fine when the call is initiated from s1p, case 1 above)
2.2 One way audio with Nokia N9, log file: 31
I also tried to call from a Nokia N9 with its builtin SIP client. This time, there was one way audio, from N9 to s1p. However, I was able to capture the audio packets coming from s1p to the IP address of the PBX, with the PBX replying to s1p with an ICMP message that the RTP destination port is not reachable. So, instead of audio going from s1p to N9, it went from the s1p to the IP address of PBX.
In wireshark, I could see that both N9 and DX800A support the G.711 PCMA/PCMU codecs. I think something goes wrong with the RTP port exchange. I also enabled the option in the PBX to have all audio delivered via the PBX. This way, I can hear audio from both sides, but there is additional delay introduced due to extra buffering on the PBX.
Please let me know how can I assist further.
unmaintained
Thu, 2020/07/16 - 10:46
Permalink
Issue 1. should be fixed in 0.3.7 possibly breaking 3CX compatibility again.
3CX seems to request authentication at a stage in the call when s1p does not expect it to happen and allowing that without making significant changes to the internal logic would mess up things quite a bit (as happened with 1.)
emsys
Thu, 2020/07/16 - 23:12
Permalink
When trying to make a call with s1p, PBX sends a 407 Proxy Authentication Required in response to INVITE, but the behavior in version 0.3.7 has become inconsistent compared to 0.3.6. In the previous version, s1p was always resending an INVITE with a Proxy-Authorization header and the call could go through. However in version 0.3.7, s1p sometimes resends the INVITE with a Proxy-Authorization header while other times, it logs the following error in the debug log and the call fails with the screen staying at "Trying".
So, the behaviour has become inconsistent with this new version.
On the other hand, issue 1, i.e. the call hangup issue did not improve since s1p still sends BYE without a Proxy-Authorization header included; 3CX simply ignores the BYE request and the call continues between 3CX and the other party.
If I were to compare this version with the previous one, I would call 0.3.6 more consistent and more usable than this one.
unmaintained
Sat, 2020/07/18 - 11:22
Permalink
Are there any changes to this behavior in version 0.3.8 ?
emsys
Mon, 2020/07/20 - 13:50
Permalink
I did some more digging into the issues I reported earlier; here is a little more information on that. Also sent you two more debug logs, 34 and 35.
1. Call Hangup issue
Same behaviour as in version 0.3.6. s1p sends the BYE request with Proxy-Authorization header not inlcuded when trying to terminate the call, 3CX simply ignores this request. s1p initiated call can only be hung up if the other party hangs up too. In that case, s1p simply reacts to BYE sent by 3CX and hangs up the call. If the call from s1p lands in a voice mailbox, then there will be no hanging up, and the call will continue forever.
I think to maintain compatibility with other PBX systems, you might add a condition to send Proxy-Authorization in BYE only if the PBX responded earlier with 407 Proxy Authentication Required during INVITE and thus it was included with the INVITE request when initiating a call, and omit it otherwise.
2.1 No audio with Gigaset DX800A, debug log 34
In this scenario, s1p receives a call from Gigaset DX800A. DX800A lists the following codecs in SDP INVITE request in this specific order:
G722, PCMA, PCMU, G726-32, and a few more.
s1p responds with the following list of codecs in this specific order:
PCMU, PCMA
If you look closely, you will see that the desk phone and s1p have both listed PCMU and PCMA, but in reverse order.
s1p picks PCMA for the RTP stream while the desk phone picks PCMU (the first common codec listed by s1p), and hence no side can hear the audio of the other side.
If I exclusively limit the phone to use either PCMU or PCMA, then both sides pick up the only common codec and audio works perfectly fine.
I repeated this experiment with making a call from Twinkle (on a Ubuntu machine) to s1p. Surprisingly, Twinkle lists the codecs in the same order as the DX800A phone which is in reverse order of the s1p's list of codecs. s1p picks up PCMA, while Twinkle picks up PCMU. I can clearly hear audio from both sides since both s1p and Twinkle can use two different codecs to decode and encode audio simultaneously. Wireshark also records two different streams with different codecs.
I think this behaviour can easily be improved if s1p picks up only one of the common codecs offered during INVITE, either PCMU, or PCMA and sends that in response to INVITE. This is what I see in all those other SIP clients doing when they receive a call.
2.2 One way audio with Nokia N9, debug log 35
This issue happens when the call is initiated from Nokia N9 and received on s1p.
There are two things going wrong here. First issue is the same as above issue 2, i.e. audio codecs listed in reverse order and hence one side picking up PCMU while the other picking up PCMA.
A second thing that goes wrong here is that s1p picks up the IP address of the PBX instead of the N9 phone for delivery of the RTP stream and hence the audio from s1p ends up on the PBX, and never reaches the Nokia N9. While the audio from the Nokia N9 lands perfectly in s1p and can be heard on the Xperia XA2.
IP address of PBX is 192.168.1.201, and that of Nokia N9 is 192.168.1.104
These are the contents of the INVITE sent by 3CX and received at s1p.
unmaintained
Sun, 2020/07/26 - 11:36
Permalink
With issue 2.2 something strange must be happening:
o=3cxPS 30352679154745344 16403140152655873 IN IP4 192.168.1.201
c=IN IP4 192.168.1.104
s1p will always prefer the value of c over o and use the IP extracted from the latter only as a fall back.
Have you seen the RTP stream going to 192.168.1.201 or could it be a completely different issue?
I know, s1p may state somewhere audio: 192.168.1.201:7078 but this was a bug in the log output.
unmaintained
Thu, 2020/07/23 - 17:06
Permalink
Are there any changes to issue 2.1 with version 0.3.9?
emsys
Fri, 2020/07/31 - 00:12
Permalink
I updated to version 0.4.3 today and I can confirm that issue 2.1 (no audio) is resolved with this version. Sorry for the late response since I haven't been able to find time for testing lately. The call hangup issue is still there, I hope you can work on that issue some time.
The one way audio issue with N9 is also there but it is not that urgent; it is more of a matter of interoperability with just another SIP client.
Too bad to know that 3CX set up did not work out for you, please let me know if I can help with something.
There is one more thing, but I would rather start another thread for it since this one has grown too long.
unmaintained
Thu, 2020/07/23 - 14:36
Permalink
I've tried to get a 3CX cloud setup working to be able to replicate this but I had to give up eventually. There was no way to even register, neither with s1p nor Zoiper etc.
The final staw was when I've got locked out of the UI, and no, I havn't tried to log in more than once:
Login access denied. Too many incorrect login attempts.
unmaintained
Fri, 2020/07/17 - 02:22
Permalink
Yes, 0.3.7 reverts to the former behavior of expecting when the autentication request has to take place which works well with many other platforms but, obviously, not 3CX. Unfortunately relaxing this caused some problems with the UI so a more substantial change will be needed to address this.
Pages