SIP on Sailfish/Aurora with s1p

fixed in 0.9.7 by removing issues tracker

Yes, SFOS no longer allows 3rd party apps to access the contacts database, copying it over to a different directory may help:

devel-su cp -r ~/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db ~/.local/share/harbour-s1p/

Removing spaces from the phone number may help.

Correct. Convincing Jolla to change the phone app may help.

It does not pass it into the text field but should start the call regardless.

Most likely a SIP signalling issue which I won’t be able to address without a SIP trace.

Should be fixed in 0.9.7

1 Like

What a pain. Whisperfish is able to use the contacts (tested), so you might be able to copy it.

Indeed. But since the phonebook numbers do contain spaces, s1p should strip them, (or warn of an invalid number)

I’ll send them a quarter of dolly mixture.
but while we are waiting…

It happened on long calls that had several dropouts (call has no audio for n seconds, then resumes), but not on short calls.

Since this is also what happens when you put a space into the number, then ensuring that the hangup can still work in that case, might fix the other case. [Closing s1p and restarting it resumes operation OK]

The way Whisperfish accesses contacts is through QML and an unsupported API. It’s anything from perfect, and may not be a preferable approach. As far as I know, Jolla committed before to keep the contacts.db file more or less intact for third party apps, but apparently they’re breaking that promise now :frowning:

Hopefully when the firejail system becomes more polished with inclusion of permissions for all apps it might be accessible again for those apps who are granted access to contacts.

Well, it’s technically still intact just not containing any contacts :slight_smile:

1 Like

I think these will be just two completely different causes that culminate in the same outcome, like e.g. s1p losing the call status for some reason.

Well, right now you have to copy the contacts over every time you add/edit a contact but I guess it’s better than nothing:

1 Like

Well, I’ve learned something interesting . . . contacts.db only contains contacts I’ve manually created on the phone or imported from contact card entries. None of my sync’d contacts from gmail are in that db. I guess that’s why they’re not backed up and restored with SFOS backup, either . . .

But now I can see my (local) contacts thanks unmaintained’s work-around, so that’s good! I also realize the Jolla contacts database doesn’t have a field that can be used specifically for a SIP address and there’s no way to enter john.smith@sipservice.org into a phone number. So that’s not quite as good, but I guess a Jolla problem, not really a s1p problem. Bummer.

Thanks to unmaintained for the continued updates so s1p. At this point I think I need to investigate using other service providers with it besides linphone as a backup in case volte support doesn’t materialize in SFOS before 3g goes away, soon™.

2 Likes

If there is another field that is accessible to the app I could maybe add that one, too.

There’s a field called ‘Note’ that accepts free text like: “sip:john.smith@sipservice.org”.

Do I understand it correctly, you need the complete string to be saved as is and sipservice.org is not just the sip domain of the service your phone is registered to?

Have you already tried dialing either john.smith or john.smith@sipservice.org from s1p and did either of them work?

Sorry, that wasn’t clear above. If I’m logged into linphone with s1p, just the username works fine without the domain (@sip.linphone.org) when dialing another linphone user. I can dial and connect successfully with s1p that way.

Interestingly the contacts app seem to be able to display SIP addresses if they’re imported from a vcard, there seem to be just no way to edit them afterwards.

BEGIN:VCARD
VERSION:2.1
REV:2021-07-17T00:00:00Z
EMAIL;ENCODING=QUOTED-PRINTABLE:john.smith=40mailservice.org
EMAIL;ENCODING=QUOTED-PRINTABLE;HOME:john.smith=40gmail.com
X-SKYPE:john.smith
X-SIP;ENCODING=QUOTED-PRINTABLE:john.smith=40sipservice.org
X-JABBER;ENCODING=QUOTED-PRINTABLE:john.smith=40jabber.org
TEL;CELL;WORK:+13134567890
TEL;WORK;VOICE:+13134560000
FN:John Smith
N:Smith;John;;;
END:VCARD
4 Likes

Yes, that is in (ERM: out) since Jolla started (let me think/calculate: some almost decade?).
I have lots of old imported contacts with ‘instant messaging’ detail which is displayed but cannot be altered/entered :frowning:
You could export a VCF, modify it manually and re-import (or even modify the contacts.db directly)! How user friendly? But as one cannot really make use of it…

If you would now make use of this field in S1P then above workaround would be the only option(s).

In earlier times (Jolla1/C) one could even use the native messaging app to chat via jabber et al. I still have a few remnants of conversations as memory in my messaging history :wink:

2 Likes

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

2 Likes

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

2 Likes

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.

4 Likes

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

11 Likes

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.