s1p

Rating: 
4.92857
Your rating: None Average: 4.9 (14 votes)

s1p is an experimental SIP client for Sailfish OS

This is software in an early stage of development - please don't expect it to work with every type of SIP server out there.

It also needs a restart after any changes to the settings.

Successfully tested with Asterisk chan_sip.

Please reference the log-id when writing a comment after submittimg a log. The id should be displayed at the bottom of the page if the log was successfully submitted. 

 

Screenshots: 

Keywords:

Changelog: 

- 0.0.2 initial release

- 0.0.3 adds log page

- 0.0.4 fixes registering issues with antisip.com

- 0.0.5 adds ringtones

- 0.0.6 improves UI and makes hanging up calls more reliable

- 0.0.7 fixes some issues with sipgate (inbound calls still broken)

- 0.0.8 fixes inbound calls with sipgate (cancelling outbound calls still broken)

- 0.0.9 fixes issues with outbound calls through sipgate

- 0.1.0 improves UI

- 0.1.1 adds contacts page

- 0.1.2 adds log upload

- 0.1.3 improves logging and handling of audio packets

- 0.1.4 enables audio output selection buttons

- 0.1.5 fixes issues with audio output selection

- 0.1.6 enables mute button

- 0.1.7 adds volume presets

- 0.1.8 makes some changes to how audio frames are handled

- 0.1.9 fixes choppy audio on some phones

- 0.2.0 adds G.711 μ-law codec, (hopefully) fixes some call-state issues

- 0.2.1 adds DNS SRV record lookup

- 0.2.2 fixes call status being sometimes overwritten by regstration status

- 0.2.3 adds initial DTMF support

- 0.2.4 adds preferrence for domain instead of IP in SIP dialogs and adds auth-name field to SIP account settings

- 0.2.5 adds improvements to power consumption, audio handler and playback buffer

- 0.2.6 adds configuration-file options for latency and audio buffer length

- 0.2.7 adds configuration dialog options for latency and audio buffer length

- 0.2.8 fixes issues with setting latency and buffer length

- 0.2.9 enables voicemail button, fixes issues with number input

- 0.3.0 adds options for bind address and regsiter frequency

- 0.3.1 sets default register frequency to 1 hour

- 0.3.2 fixes regsitering with sip.linphone.org

- 0.3.3 fixes previously broken default settings

- 0.3.4 adds support for display name

- 0.3.5 fixes proxy-authentication

- 0.3.6 allows a more flexible approach to call progess messages

- 0.3.7 reinstates stricter approach to call progess messages

Comments

defactofactotum's picture

I set the register frequency but it makes no difference. When I change settings I press 'Accept' and it returns to the dialler page as 'not registered'. In the past it said registering and even authenticating but never succeeded. Closing the app changes nothing for me. Just in case this is a linphone thing, can someone recommend an easy to use alternative sip?

unmaintained's picture

please check if version 0.3.2 works with linphone.org

defactofactotum's picture

Hi, recent builds do not register for me with linphone (if anyone has done this please post details) and does not save settings after I press accept - it returns to not registered and settings is again blank. Help! It would be great to get this working.

unmaintained's picture

Is "Regsiter frequency" set to somethig between 3600 and 60?

Also don't forget to close the app after changing settings. 

amaretzek's picture

feature request:server reachable indicator. Or the other way round, "registered" turns red if server becomes unreachable....

unmaintained's picture

It should already indicate if registering failed but the default regstration frequency is 1h or so, means it can take while. s1p does not send any options packets yet.

amaretzek's picture

For 0.3.1 "registered" never changes, event if "regstration frequency" (which is an interval, right??) expired after loss of network. Also, the green phone gets active if you type a number, which is misleading, since there is no network. No problem for me, but for a normal user...

unmaintained's picture

After the regsitration expires nrad should re-register but based solely on time not on any changes to the network.

amaretzek's picture

Yeah. But, if register frequency is 70, presume seconds, if I wait 2 min after loosing network, I should see something. And I didn't. Somehow, I didn't wait long enough. After a while it was "registering". This is ok, but still the green phone was active while it didn't register due to lack of network. It got registered as soon as there was network, as expected. To me this means, ready to test with normal user.. Thanks a lot!

unmaintained's picture

What I mean is that if the green button is enabled or not does not depend on the registration status.

amaretzek's picture

But should, my 2 cents. The green button gets activated when a digit is typed. In my opinion, this should work the same for "server reachable" / "not reachable".

unmaintained's picture

Yes, it ets activated because without any destination to call there is no point in trying to send a sip invite but there's no way to know if at that moment the sip server is reachable or not without actively sending a packet.

amaretzek's picture

It always sends traffic through wlan0? I configured a server reachable via tun0, but packets get out on wlan0, disregarding kernel routing table.

unmaintained's picture

It's not designed to do that but maybe it has something to do which IP address it binds to? Could you check with the log if this would make sense?

amaretzek's picture

netstat says so. Why not binding to 0.0.0.0?

unmaintained's picture

I wonder if it would work if you would change the static IP address in /usr/share/harbour-s1p/qml/pages/s1p.py
line 187 (in function get_own_ip) to the IP of your SIP server (or VPN endpoint).

amaretzek's picture

Yes, it works for registering, didn't try calling, will do it later on. But I don't expect surprises... I used the VPN endpoint (on tun1).

amaretzek's picture

sip audio ok...

unmaintained's picture

Please check if this issue has been fixed in 0.2.5

amaretzek's picture

Yes, it works, at least for registering. Presume audio is ok, will check later on (tomorrow). Thanks!

unmaintained's picture

It will try to bind to the same IP for signalling and audio so I would expect ist to ether both to work or both to fail.

mano's picture

Power consumption: Hello, thanks again for taking the challange to complete the phone capabilities of Sailfish! And for this great user support!
Unfortunately I noticed a hughe battery drain on my Xperia X.
AP Infrastructure is constant for over a year here and keeping mails in sync over WiFi always needed about 30% capacity from (early) morning to (late) evening. Nothing changed in that regard, just started s1p in additon. Now I need 80% of the battery's capacity during the same time frame.
Lighthouse shows average but constant 3% of CPU usage for the s1p process.
SysMon indicates that CPUs are kept from idling and most likely even from reducing clock – but I can't verify that.
Is the power consumption known to be a fixable/optimizable problem in s1p's current state?

Thanks,
-mano

unmaintained's picture

I guess it should be fixable once I've been able to locate the cause :) I do have a few suspects but didn't have the time to look into it.

amaretzek's picture

Power consumption on my Xperia X starts after a call. Before it is ok.

unmaintained's picture

That could happen if e.g. the PulseAudio handler would not shut down properly after a call.

amaretzek's picture

Might have changed. ATM top says 12% CPU for s1p and 7% pa after start, 35%/7% during call, then back to 12/7 after call. Will look at battery drain in one hour or so.

unmaintained's picture

That could still be the PulseAudio handler. I've changed the way starting/stopping PA streams works so PA streams would not run amok after being stopped but this may use more cpu overall.
I will definitely look into it at some point. If I can make them stop when they are supposed to be stopped there should not be much left that could keep the cpu awake.

amaretzek's picture

I would say, it stops now. Battery drain s1p off: ~2.4%/h, s1p on: ~8%/h.

unmaintained's picture

Stopping PA handler should be much more reliable in 0.2.5

amaretzek's picture

2.5 looks much better, something around 2.5 to 4 %/h. Also top looks better. Will update now..

Pages