Yes, please. Log #72
And there is no audio both ways?
I see no indication why not at least one side should work assuming the FritzBox does not have to NAT as it will be it’s own DSL/cable router.
Unfortunately s1p does not (yet) log the RTP (audio) packets going in/out so there is not much we may see without a full trace (e.g. tcpdump).
1 Like
Yes, but as said above another SIP client (linphone one) has the same problem.
Yes, assumption and analysis correct.
But logging all RTP would be against the law to ask for permission before recording calls, or? And it would make use of quite extensive disk space?
After some more testing in bed space and this morning it seems related to my operator blocking audio packet on cellular data.
With another SIM in the Android phone it works perfectly via cellular data.
So I may test that when I have opportunity to get to another WLAN (not behind a FRITZ!), which can be delayed, virus caused.
Hmm, you mean like deliberately filtering them out? That’s a rather nasty thing to do.
You should maybe think about a VPN or something.
unmaintained
Does s1p support encryption (tls and srtp)?
…
Not yet.
Is it planned to implement such features? I am also strongly interested about! 
While I’m certainly not opposed to it there is yet no schedule for implementing encryption if you mean that.
With last s1p version (0.9.3-1) now it works with my fritzbox.
Thank you very much!
1 Like
With 0.9.3 there should be less issues when behind NAT as well, as s1p now starts sending audio packets immediately after it receives a SDP inside a “Progress” message from the server, in turn enabling it to figure out which address/port combination it has to use, should they differ from what was provided inside the SDP message.
2 Likes
Unfortunately it doesn’t fully work on my Fritz!box 7412, I can register and make a call, the other party can her me, however I don’t her the other party and also incoming calls are not recognised.
Since this fritz!box has been provided by my DSL operator it is still on FritzOS 6.x so the ancient OS version may be a cause for my issue.
SIP has been around for quite a while (I work in VoIP for over 20 years) so ancient FB firmware does not necessarily have to be the problem here.
You could try opening an issue and uploading a log trace.
1 Like
Where are we at on supporting a background daemon?
Has not progressed any further as Jolla are keeping us developers busy with shenanigans like removing access to contacts for non-privilleged apps etc.
2 Likes
That sucks, if Jolla had better relations with the US, I’d definitely sell phones with SailfishOS installed
Or maybe, if I make a company, provide hardware for SailfishOS and other Linux OSs
Just closed s1p, reconnected my BT headset, restarted s1p: incoming calls and incoming audio work now, so everything is fine with me and my (aged) Fritz.box
2 Likes
I guess they must have their reasons for blocking US customers.
Some US companies also block access from European IPs because of various overreaching European regulations that would require them to follow European law even if they aren’t operating in Europe, maybe this also works the other way round and Jolla would have to comply with some obscure US laws if they allowed people from the US to purchase from their site.
1 Like
I think it would definitely help more than hurt.
I know plenty of people who’d love to own a SailfishOS phone, but are either forced to buy an international unlocked phone already flashed, or to install it from an unofficial source. Although, you can bypass Jolla’s country restriction for purchasing via PayPal…