Your rating: None Average: 4.9 (29 votes)

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

(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.




Application versions: 
File harbour-s1p-0.7.9-1.i486.rpm1.85 MB08/10/2020 - 17:24
File harbour-s1p-0.7.9-1.armv7hl.rpm1.82 MB08/10/2020 - 17:24
File harbour-s1p-0.8.0-1.i486.rpm1.85 MB08/10/2020 - 22:46
File harbour-s1p-0.8.0-1.armv7hl.rpm1.82 MB08/10/2020 - 22:46
File harbour-s1p-0.8.1-1.i486.rpm1.85 MB13/10/2020 - 11:40
File harbour-s1p-0.8.1-1.armv7hl.rpm1.82 MB13/10/2020 - 11:40
File harbour-s1p-0.8.2-1.i486.rpm1.86 MB14/10/2020 - 00:37
File harbour-s1p-0.8.2-1.armv7hl.rpm1.82 MB14/10/2020 - 00:37
File harbour-s1p-0.8.3-1.i486.rpm1.86 MB17/10/2020 - 11:16
File harbour-s1p-0.8.3-1.armv7hl.rpm1.82 MB17/10/2020 - 11:16
File harbour-s1p-0.8.4-1.i486.rpm1.9 MB21/10/2020 - 23:00
File harbour-s1p-0.8.4-1.armv7hl.rpm1.87 MB21/10/2020 - 23:00
File harbour-s1p-0.8.5-1.i486.rpm1.9 MB22/10/2020 - 09:43
File harbour-s1p-0.8.5-1.armv7hl.rpm1.87 MB22/10/2020 - 09:43
File harbour-s1p-0.8.6-1.i486.rpm1.9 MB25/10/2020 - 17:08
File harbour-s1p-0.8.6-1.armv7hl.rpm1.87 MB25/10/2020 - 17:08
File harbour-s1p-0.8.7-1.i486.rpm1.9 MB27/10/2020 - 23:32
File harbour-s1p-0.8.7-1.armv7hl.rpm1.87 MB27/10/2020 - 23:32
File harbour-s1p-0.8.8-1.i486.rpm1.91 MB31/10/2020 - 13:41
File harbour-s1p-0.8.8-1.armv7hl.rpm1.87 MB31/10/2020 - 13:41
File harbour-s1p-0.9.0-1.i486.rpm1.91 MB14/11/2020 - 23:12
File harbour-s1p-0.9.0-1.armv7hl.rpm1.88 MB14/11/2020 - 23:12
File harbour-s1p-0.9.1-1.i486.rpm1.92 MB24/11/2020 - 18:57
File harbour-s1p-0.9.1-1.armv7hl.rpm1.88 MB24/11/2020 - 18:57
File harbour-s1p-0.9.2-1.i486.rpm1.92 MB27/11/2020 - 13:14
File harbour-s1p-0.9.2-1.armv7hl.rpm1.88 MB27/11/2020 - 13:14
File harbour-s1p-0.9.3-1.armv7hl.rpm1.88 MB19/03/2021 - 16:46
File harbour-s1p-0.9.3-1.i486.rpm1.93 MB19/03/2021 - 16:46
File harbour-s1p-0.9.4-1.i486.rpm1.93 MB24/03/2021 - 17:31
File harbour-s1p-0.9.4-1.armv7hl.rpm1.88 MB24/03/2021 - 17:31
File harbour-s1p-0.9.5-1.i486.rpm1.93 MB26/03/2021 - 14:35
File harbour-s1p-0.9.5-1.armv7hl.rpm1.89 MB26/03/2021 - 14:35

- 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


olf's picture

@unmaintained, the point is (I think @zapotroin and @ichthyosaurus were also aiming in this direction), that a public source code repository at a proper source hoster (e.g., gitlab.com or github.com) would allow:

  • to collaborate easily, i.e. support you by enhancing code (bugfixes and contributions).
    As long as you do not grant commit rights to others, this has to happen in the form of Merge Requests (MRs), which provides you with full control of what you accept, adapt or reject.
    The fact, that the source code of s1p's QML files can be viewed, when deployed locally by installing it, is not a feasible base for collaboration.
  • to have a proper issue tracker at hand (optional), instead of filing and discussing bugs in this forum.
    I strongly recommend using an issue tracker sooner or later, because this forum discussion has already become quite lengthy (8 pages) and convoluted.
  • to have a proper wiki at hand (optional), in case there is more to document than the app description here at Openrepos is suitable for.

You lose nothing (AFAICS), except you were hoping to offer s1p as a paid app for SailfishOS some day.  But even that can be worked around (though I do not think it is worth the effort, as still no infrastructure for paid apps for SFOS exists), with the right licensing scheme (GPL / LGPL and compulsory CLA, as Digia (now "The Qt company") does it).

BTW, as there currently does not seem to be any indication of a specific license, at least the QML files are basically being placed in the public domain.  Any proper Free Software license (approved by the Open Source Initiative (OSI)), offers better protection of the author's and the users' interests.

P.S.: If it is helpful for you, I can provide some guidance for choosing a license, which fits s1p and your aims well.

unmaintained's picture

I'm not planning to release s1p as a paid app. As you mentioned, there is neither the infrastructure in place nor the user base available that would support this anyway.
The "juicy bits" are in the SIP libraries, etc. which are shared with my other projects outside the Sailfish realm and can't be open-sourced on a whim without considering possible, negative effects this may create. Developers have to eat, too :)

olf's picture

[...]  The "juicy bits" are in the SIP libraries, etc. which are shared with my other projects outside the Sailfish realm and can't be open-sourced on a whim without considering possible, negative effects this may create. Developers have to eat, too :)

This is well understandable; thank you for explaining the background.
Side note: Thoroughly understanding Digia's (now "The QT company") licensing and contribution model really might be helpful for evaluating the possibilities of "open sourcing" your SIP libraries in the distant future, then.  Their customers can freely choose between GPL / LGPL or a proprietory, paid license, plus contributors must sign a "Contributor Licensing Agreement (CLA)", which grants Digia the right to relicense contributions (i.e., using them for their proprietory Qt, plus changing the license of the Free Software Qt) but also guarantees contributors, that a Free Software Qt will always be maintained and published by Digia.  This is working really well for Digia for years (looking at their financial reports), because many of Digia's customers prefer to pay for a proprietory license than being oblieged by the (L)GPL to provide the source code of their own adaptions upon their customers' request.  Actually, the dire situation of Qt on SFOS is a direct consequence of this: Digia changed the licenses of their Free Software Qt (only feasible due to their CLA) from (L)GPLv2 to (L)GPLv3 years ago, and because Jolla does neither want to use (L)GPLv3 Software or pay for a proprietory Qt license, we are stuck at a completely outdated and unmaintained Qt version (v5.6, IIRC) on SFOS.
But "Yes", such a step has to be carefully considered, evaluated and designed, hence definitely cannot be done "in a whim".

Still I suggest to open a project at Github.com or Gitlab.com, in order to structure issues (technical ones and others, as this one) and to optionally employ a wiki (in which users could document their experiences / settings with various SIP providers, after granting all Git{hub|lab}-users edit-rights to specific wiki-pages or the whole s1p-wiki).  Maybe even without any source code at the beginning, until you decided upon a license for s1p's QML-components (my quick&dirty sugggestion is LGPLv2.1 for these).

Background: As you can gather from this TJC post there has been massive interest in the past 7 years to get SIP working (and VoLTE in the long run) on SFOS, but Jolla's slow development of this from the start seems to have halted since SFOS 2.0.0 in 2015.  You resolved this within weeks and a have also shown to be an excellent software maintainer: Kudos to you!

bc77's picture


I am interested. I am using sipgate.de als SIP Provider..

unmaintained's picture

Have you tried it with sipgate?
You will have to use their IP address instead of sipgate.de, though.

dubliner's picture

I am also extremely interested. In fact, it's the major thing missing for me with SFOS. However, I have been unable to get it working.

On my Asterisk server I keep getting "SIP/2.0 401 Unauthorized" (pjsip logger) while the status on s1p never changes from "network_ready" no matter how simple a password I choose.

So, I tried registering s1p with Antisip. Here the status on s1p changed from "network_ready" to "not_allowed".

Of course, I verified username and password in both situations several times.

Any hints?

unmaintained's picture

Do you have a way to start it from the command line and to analyze the optput?

sailfish-qml harbour-s1p

Please be aware before posting things that the output could contain IPs, usernames and the password in clear text.

dubliner's picture

I just installed harbour-s1p-0.0.3-1 and this is what I see when I try to connect to Antisip:

b'ERROR [SIPServer-1] CreateDialog [4273f45e@] - on request: REGISTER, cseq: , from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'
b'DEBUG [SIPServer-1] Register [4273f45e@] - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'
b'DEBUG [SIPServer-1] HandleRequestRegister [4273f45e@] - REGISTER declined - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'
b'DEBUG [SIPServer-1] WritePacket - out: => (405 Method Not Allowed)\n'
b'DEBUG [SIPServer-1] AnswerAck [4273f45e@] - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'
b'DEBUG [SIPServer-1] WritePacket - out: => (ACK) sip:#hidingMyNumber#@\n'
b'DEBUG [SIPServer-1] HandleRequestAck [4273f45e@] - ACK - ignored - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'
b'DEBUG [SIPServer-1] HandleRequestAck [4273f45e@] - ACK - ignored - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber# => (REGISTER) sip:sip.antisip.com:5060\n'
[1] rec: b'{"event":"not_allowed","from_peer":"#hidingMyNumber#","to_peer":"#hidingMyNumber#","outbound":true}\n'

[1] INFO handle_stdout - event frame: {'event': 'not_allowed', 'from_peer': '#hidingMyNumber#', 'to_peer': '#hidingMyNumber#', 'outbound': True}
[1] INFO handle_event_frame - frame: {'event': 'not_allowed', 'from_peer': '#hidingMyNumber#', 'to_peer': '#hidingMyNumber#', 'outbound': True}
[D] :15 - 1 handle_event_frame - event: not_allowed
b'ERROR [RTPServer-2] Run - read error: read udp recvmsg: interrupted system call\n'

So, it's 405 Method not allowed in this case. Not sure why port 9004 shows up, though.

BTW, which service are you connecting to in your setup?

unmaintained's picture

Someting got totatlly confused here, the following line means that it's basically speaking to itself: 

out: =>

What is the local IP address and what should be the IP of the SIP registrar?

Port 9004 is the default RTP port and can be ignored for now as it has nothing to do with the register attempt.

dubliner's picture

That's exactly what I thought. The phone is trying to connect to itself which makes no sense at all. The phone's IP was the

I also use Asterisk 16/FreePBX. However, debugging is a little more difficult since that server is also on a network, just like the phone when I plug in USB.

Are you using the plain standard pjsip extension on FreePBX for your s1p setup?

P.S. When I change sip.antisip.com into it stops at "network_ready". Can't give any further info as I am not at my PC now.

unmaintained's picture

I'm using an ancient FreePBX with chan_sip :)

Coud be pjsip is handling something differently.
I'll try to check out antisip later.

dubliner's picture

Indeed, chan_sip is working. Too bad it's considered deprecated (the current FreePBX doesn't leave any doubts about that). I really wonder what's keeping s1p from working with pjsip? I have a variety of devices successfully connected just using the standard pjsip settings.

As for connecting to Antisip using their IP address, this resulted in status "400 Content-Length mis-match":

b'ERROR [SIPServer-1] CreateDialog [5f4f351f@] - on request: REGISTER, cseq: , from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'

b'DEBUG [SIPServer-1] Register [5f4f351f@] - from: #hidingMyNumber# (, ua: s1p, to: #hidingMyNumber#\n'

b'DEBUG [SIPServer-1] WritePacket - out: => (REGISTER) sip:\n'

b'DEBUG [SIPServer-1] HandleResponseUnhandled [5f4f351f@] - unhandled response ignored - from: #hidingMyNumber# (, ua: , to: #hidingMyNumber#\n'

b'TRACE [SIPServer-1] HandleResponseUnhandled [5f4f351f@] - payload: => (400 Content-Length mis-match)\n'
unmaintained's picture

Registering to Antisip works for me in 0.0.4 now. I have no Idea if it is able to make any calls, though.

dubliner's picture

Just a quick note: Registration with Antisip only works when their IP is inserted. Adding "sip.antisip.com" fails (i.e. the phone seems to be trying to connect to itself).
Phone calls are signalled but no audio is transported. Additionally it was impossible to end the call. I had to close s1p.
Anyway, I really enjoy seeing rapid progress here! Keep it up, please!

unmaintained's picture

Audio issues could be NAT related. There's no STUN support in s1p yet. Asterisk seems to just send the audio back to the IP/port combination (when NAT is enabled) the incoming packets are coming from but I don't know how antisip are handling that.
Also the only codec supportet at this moment is alaw but this should not be an issue I think.

dubliner's picture

My SIP devices as well as Asterisk are able to connect to Antisip and other providers through NAT without using STUN. So, there must be another option merely through configuration. I am clearly not an expert, so I'll just try to provide reference:


chan_sip has a setting NAT=yes which never caused any problems.

unmaintained's picture

Yes, you have to use the IP address as it's not resolving domain names at this point. I'll change the description to make this clearer.

unmaintained's picture

Thank you, i'll check the marshaller if it's mayby adding one \n too many or so and chan_sip just doesn't care.

unmaintained's picture

I'm using Asterisk (FreePBX) to test s1p against but I'll try to check out antisip.com tomorrow.

amaretzek's picture

I'm *very* interested! Can contribute with translation to pt_PT, some testing too...