s1p

Rating: 
4.96
Your rating: None Average: 5 (25 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.

 

Screenshots: 

Keywords:

Application versions: 
AttachmentSizeDate
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
Changelog: 

- 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

Comments

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

amaretzek's picture

v 2.8, s1p started, no calls, 11h running, 26 minutes CPU, which makes 2.4% duty cycle. Guess this is ok.

unmaintained's picture

During a call CPU will, of course, go up but I think I've fixed the PA problem and usage should now get to normal after each call. 

amaretzek's picture

No excessive battery drain (2%/h) observed after calling with v29, around 2.5% duty cycle for s1p.

unmaintained's picture

Good to know, thank you.

mano's picture

I'd love to test, but I need to have a separate authenticating user than the sip account (number).
Do you have any plans implementing that in the near future?
Thanks a lot, shame on jolla for letting others do their work...
Maybe you'll on-board once telepathy-rakia and sofia-sip core packages will be finished? As high rated senior consultant :-)

unmaintained's picture

Auth-user should come with version 0.2.4
As to Jolla, there are maybe 10-15 users worldwide that  are interested in SIP for SFOS. The sad truth is that this would never make any economic sense to Jolla to  spend time on something such marginal compared to the much bigger issues they have to deal with (ancient browser engine comes to mind) right now.

mano's picture

Oh, and found that the registrar domain setting is also missing. Currently the resolved hostname is used. In case of a hostname provided for the registration server, I'd expect that one to be used. Setups where the domain corresponds to the IP, users can always enter the IP, instead of the hostname, but not vice versa :-)
Thanks!

unmaintained's picture

Should also come with 0.2.4

mano's picture

Incredible, thank you very much for that quick additions!
Could successfully test with my local pbx (slightly modified asterisk/chan_sip).
I noticed assymetric lag - s1p tx latency is ok, but the receiving buffer seems to be much too huge, which I estimate to be a whole second. Not qualified timed, but it's really some orders of magnitude more than the usual RTP latency with WiFi connected SIP phones here.
Has anybody else reported such a long delay for the receiving side? It doesn't matter if output is handsfree-speaker or earset - it always takes roundabout a second until the partner's audio plays back.
Thanks!

Pages