SIP on Sailfish/Aurora with s1p

0.9.8 should allow dialing arbitrary text saved in the Notes field.


0.9.8 should strip invalid characters from phone numbers (including spaces)


0.9.8 should allow dialing from this field now, in addition to the Notes field which allows arbitrary text and can be edited in the People app.


@unmaintained I have dozens of improvements for S1P which I maintain myself locally. If you opensource S1P I can issue some pull requests on those. Everything I’ve done is essentially to make SIP a temporary full stack replacement for VoLTE in SFOS. This helps enable USA users to continue using SFOS. I’d like to next implement SRTP and TLS, but I need the sources to do those modifications to the main SIP server. Let me know if you’re open to that. If not, I’ll be forced to just create a competing SIP application- not ideal for the limited number of us SFOS developers.


I’m not generally against it, I just didn’t have the time to look into releasing the code yet.
Also the daemon is written entirely in Go, hope that’s not an issue?

@unmaintained That’s great. I’d be happy to do some of that lifting if it would help. Go is no problem. Ideal, really, so as to avoid library problems.

I can’t release it right away as there are some parts I have to clean up first.
I “recycled” some parts from another of my projects that has to remain closed due some stupid contractual obligations but the SIP/RTP part is not covered by that so it just means making sure it still compiles without all the unnecessary bloat around it :slight_smile:
I try to look into it tomorrow.


When you have time. Thank you!

1 Like

Just a heads-up, that s1p stopped working in 4.4, probably another sandboxing victim, because adding [X-Sailjail] section with Sandboxing=Disabled to .desktop works (haven’t had time to investigate, what specific privileges would be necessary). Without it, launch results in briefly “spinning” cover and following entries in log:

kwi 02 14:12:38 xonia invoker[22268]: warning: enforcing sandboxing for '/usr/bin/s1p'
kwi 02 14:12:38 xonia lipstick[4947]: Error: can't chdir to privileged
kwi 02 14:12:38 xonia lipstick[4947]: constructing /run/firejail/mnt/privileged: Images ...
kwi 02 14:12:38 xonia lipstick[4947]: mounting /run/firejail/mnt/privileged @ /home/defaultuser/.local/share/system/privileged
kwi 02 14:12:38 xonia lipstick[4947]: hiding /run/firejail/mnt/privileged
kwi 02 14:12:39 xonia lipstick[4947]: Error: can't chdir to privileged
kwi 02 14:12:39 xonia lipstick[4947]: FATAL s1p could not start QML process:exec: "sailfish-qml": executable file not found in $PATH
kwi 02 14:12:39 xonia booster-generic[4871]: *** signal=17 pid=4871
kwi 02 14:12:39 xonia /usr/libexec/mapplauncherd/booster-generic[4871]: warning: Boosted process (pid=20695) exit(1)
kwi 02 14:12:39 xonia /usr/libexec/mapplauncherd/booster-generic[4871]: warning: Daemon: sending exit(1) to invoker(22268)
kwi 02 14:12:39 xonia invoker[22268]: warning: application (pid=-1) exit(1) signal(0)

Also, starting from terminal even without .desktop modification by

s1p --qml harbour-s1p

works OK.

Thank you.
I’ve released version 0.9.9 with sandboxing disabled in harbour-s1p.desktop
I think the strange way s1p start up is performed (starting the s1p daemon first which in turn then tries to run the QML part by invoking sqilfish-qml) is not compatible with Sailjail.


As the internal issues tracker got nuked, is there a way to check issues? I have some minor annoyances, but wanted to check first if someone mentioned them already…

Nevertheless, here they are:

  • when, during the SIP call, some other person SIP-calls me, the first call gets muted temporarily, then comes back, mutes again, back again and so on; it persists until the second caller gives up. (“muted” does not mean switching the in-app controls, I just cannot hear my interlocutor).
    A wild guess is that it has something to do with sound routing – the app tries to make some sound to notify me of second call; while it does not, it mutes the first call in process. I’d be perfectly fine with completely ignoring the second call, busy is busy, no need to interfere with the call already in progress.
    Also, after that I have multiple (usually 10+) second-caller entries in history, even if he made just one call. This multiplication is of least annoyance, I mention it just to complete the picture.

  • when I talk thru “normal” phone, (that is builtin phone app, no SIP), and the SIP call comes, the phone call is switched to loudspeaker. Lesser problem than the muting described above, but may be embarrassing in some circumstances :wink:

  • ah, and I forgot – when during SIP call comes “normal” one, I get the ringer straight into ear. Ouch. Can the phone be somehow signalled, that there is another call in progress? Again, blocking/ignoring the second call entirely would be fine.