Your rating: None Average: 5 (24 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

(please add a comment if you have been able to make it work with a provider not listed above)

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

Also don't forget to restart the app after making any changes to the settings.




Application versions: 
File harbour-s1p-0.0.2-1.armv7hl.rpm2.13 MB27/05/2020 - 10:26
File harbour-s1p-0.0.3-1.armv7hl.rpm2.13 MB27/05/2020 - 23:38
File harbour-s1p-0.0.4-1.armv7hl.rpm2.14 MB29/05/2020 - 14:26
File harbour-s1p-0.0.5-1.armv7hl.rpm2.14 MB30/05/2020 - 11:04
File harbour-s1p-0.0.6-1.armv7hl.rpm2.14 MB01/06/2020 - 19:36
File harbour-s1p-0.0.7-1.armv7hl.rpm2.14 MB02/06/2020 - 22:52
File harbour-s1p-0.0.8-1.armv7hl.rpm2.15 MB04/06/2020 - 20:19
File harbour-s1p-0.0.9-1.armv7hl.rpm2.15 MB05/06/2020 - 12:22
File harbour-s1p-0.1.0-1.armv7hl.rpm2.15 MB05/06/2020 - 14:58
File harbour-s1p-0.1.1-2.armv7hl.rpm2.15 MB05/06/2020 - 23:43
File harbour-s1p-0.1.2-1.armv7hl.rpm2.15 MB06/06/2020 - 11:41
File harbour-s1p-0.1.3-1.armv7hl.rpm2.15 MB06/06/2020 - 19:01
File harbour-s1p-0.1.4-1.armv7hl.rpm2.15 MB08/06/2020 - 21:30
File harbour-s1p-0.1.5-1.armv7hl.rpm2.15 MB09/06/2020 - 11:24
File harbour-s1p-0.1.6-1.armv7hl.rpm2.16 MB09/06/2020 - 15:49
File harbour-s1p-0.1.7-1.armv7hl.rpm2.16 MB11/06/2020 - 09:29
File harbour-s1p-0.1.8-1.armv7hl.rpm2.16 MB12/06/2020 - 11:37
File harbour-s1p-0.1.9-1.armv7hl.rpm2.16 MB12/06/2020 - 21:11
File harbour-s1p-0.2.0-1.armv7hl.rpm2.16 MB13/06/2020 - 11:53
File harbour-s1p-0.2.1-1.armv7hl.rpm2.18 MB13/06/2020 - 22:21
File harbour-s1p-0.2.2-1.armv7hl.rpm2.18 MB16/06/2020 - 20:07
File harbour-s1p-0.2.3-1.armv7hl.rpm2.18 MB20/06/2020 - 11:01
File harbour-s1p-0.2.4-1.armv7hl.rpm2.18 MB21/06/2020 - 11:30
File harbour-s1p-0.2.5-1.armv7hl.rpm2.18 MB26/06/2020 - 14:31
File harbour-s1p-0.2.8-1.armv7hl.rpm2.18 MB28/06/2020 - 11:08
File harbour-s1p-0.2.9-1.armv7hl.rpm2.19 MB29/06/2020 - 16:48
File harbour-s1p-0.3.1-1.armv7hl.rpm2.18 MB04/07/2020 - 12:42
File harbour-s1p-0.3.2-1.armv7hl.rpm2.18 MB08/07/2020 - 23:56
File harbour-s1p-0.3.3-1.armv7hl.rpm2.18 MB09/07/2020 - 22:58
File harbour-s1p-0.3.4-1.armv7hl.rpm2.19 MB12/07/2020 - 12:46
File harbour-s1p-0.3.5-1.armv7hl.rpm2.19 MB15/07/2020 - 02:04
File harbour-s1p-0.3.7-1.armv7hl.rpm2.19 MB16/07/2020 - 10:34
File harbour-s1p-0.3.8-1.armv7hl.rpm2.19 MB18/07/2020 - 11:18
File harbour-s1p-0.3.9-1.armv7hl.rpm2.2 MB23/07/2020 - 17:04
File harbour-s1p-0.4.0-1.armv7hl.rpm2.2 MB25/07/2020 - 10:52
File harbour-s1p-0.4.1-1.armv7hl.rpm2.2 MB26/07/2020 - 12:06
File harbour-s1p-0.4.2-1.armv7hl.rpm2.2 MB27/07/2020 - 15:43
File harbour-s1p-0.4.3-1.armv7hl.rpm2.2 MB30/07/2020 - 22:23
File harbour-s1p-0.4.4-1.armv7hl.rpm2.2 MB31/07/2020 - 14:47
File harbour-s1p-0.4.5-1.armv7hl.rpm2.2 MB01/08/2020 - 11:01
File harbour-s1p-0.4.6-1.armv7hl.rpm2.2 MB01/08/2020 - 23:13
File harbour-s1p-0.4.7-1.armv7hl.rpm2.2 MB04/08/2020 - 10:53
File harbour-s1p-0.4.8-1.armv7hl.rpm2.2 MB06/08/2020 - 09:50
File harbour-s1p-0.4.9-1.armv7hl.rpm2.2 MB06/08/2020 - 14:06
File harbour-s1p-0.5.0-1.armv7hl.rpm2.2 MB10/08/2020 - 15:21
File harbour-s1p-0.5.1-1.armv7hl.rpm2.2 MB10/08/2020 - 15:28
File harbour-s1p-0.5.2-1.armv7hl.rpm2.2 MB13/08/2020 - 11:57
File harbour-s1p-0.5.3-1.armv7hl.rpm2.2 MB13/08/2020 - 12:08
File harbour-s1p-0.5.4-1.armv7hl.rpm2.2 MB17/08/2020 - 11:32
File harbour-s1p-0.5.5-1.armv7hl.rpm2.2 MB18/08/2020 - 17:31
File harbour-s1p-0.5.6-1.armv7hl.rpm2.25 MB22/08/2020 - 15:08
File harbour-s1p-0.5.7-1.armv7hl.rpm2.26 MB22/08/2020 - 16:04
File harbour-s1p-0.5.8-1.armv7hl.rpm2.26 MB25/08/2020 - 14:57
File harbour-s1p-0.5.9-1.armv7hl.rpm2.26 MB26/08/2020 - 00:02
File harbour-s1p-0.6.0-1.armv7hl.rpm2.26 MB26/08/2020 - 16:30
File harbour-s1p-0.6.1-1.armv7hl.rpm2.26 MB27/08/2020 - 18:26
File harbour-s1p-0.6.2-1.armv7hl.rpm2.26 MB28/08/2020 - 00:41
File harbour-s1p-0.6.3-1.armv7hl.rpm2.26 MB29/08/2020 - 11:07
File harbour-s1p-0.6.4-1.armv7hl.rpm2.26 MB30/08/2020 - 11:25
File harbour-s1p-0.6.5-1.armv7hl.rpm2.26 MB31/08/2020 - 22:19
File harbour-s1p-0.6.6-1.armv7hl.rpm2.26 MB03/09/2020 - 14:39
File harbour-s1p-0.6.7-1.armv7hl.rpm2.26 MB03/09/2020 - 22:49
File harbour-s1p-0.6.8-1.armv7hl.rpm2.26 MB04/09/2020 - 17:52
File harbour-s1p-0.6.9-1.armv7hl.rpm2.27 MB07/09/2020 - 17:20
File harbour-s1p-0.7.0-1.armv7hl.rpm2.27 MB13/09/2020 - 22:22
File harbour-s1p-0.7.1-1.armv7hl.rpm2.28 MB15/09/2020 - 12:02
File harbour-s1p-0.7.2-1.i486.rpm1.4 MB24/09/2020 - 20:25
File harbour-s1p-0.7.2-1.armv7hl.rpm2.28 MB24/09/2020 - 20:25
File harbour-s1p-0.7.1-1.i486.rpm1.39 MB24/09/2020 - 20:25

- 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


apolem's picture

At first, thanks for the work!

But at the moment I can’t test your app because the window is just white.

I get following status when starting your app on cli:

[D] unknown:0 - Using Wayland-EGL
[D] unknown:0 - Got library name:  "/usr/lib/qt5/qml/io/thp/pyotherside/libpyothersideplugin.so"
[W] unknown:49 - file:///usr/share/harbour-s1p/qml/harbour-s1p.qml:49:5: Type MainPage unavailable
         MainPage {
[W] unknown:68 - file:///usr/share/harbour-s1p/qml/pages/MainPage.qml:68:5: Type NumberInputWidget unavailable
         NumberInputWidget {
[W] unknown:63 - file:///usr/share/harbour-s1p/qml/pages/NumberInputWidget.qml:63:5: Cannot assign to non-existent property "_cursorBlinkEnabled"
         _cursorBlinkEnabled: false
library "/vendor/lib/egl/libGLESv2S3D_adreno.so" not found

SFOS on Nexus 5 (hammerhead; it’s a community build)

Let me know if it is just because of my stupidity. Thanks!

unmaintained's picture

I don't have this exact build so won't be able to replicate this issue but you could open the last file [1] and comment out this _cursorBlinkEnabled line throwing the error.

[1] /usr/share/harbour-s1p/qml/pages/NumberInputWidget.qml

ar0's picture

Worked at sipnet.ru, xa2+

emsys's picture

One way audio issue with Nokia N9

Hello again,

I did some more testing with version 0.4.6, in order to try to understand why does the audio from s1p end up on the 3CX server instead of going to N9 phone, and I think I might have found something.

I dialed in s1p from the following phones and dumped the contents of the INVITE request received at Sailfish OS with wireshark. Here is what I find:

Gigaset DX800A

o=3cxPS 19540964070653952 5169137911332865 IN IP4
c=IN IP4
m=audio 9032 RTP/AVP 9 0 8 96 97 2 18 101

Android (native)

o=3cxPS 30808849594187776 12703181402275841 IN IP4
c=IN IP4
m=audio 60294 RTP/AVP 96 97 3 0 8 127

Nokia N9

o=3cxPS 11303284778205184 16439823719989249 IN IP4
m=audio 7078 RTP/AVP 18 102 8 0 101 99
c=IN IP4


In case of Gigaset and Android clients, s1p delivers audio correctly at the IP address of the phones. However in case of Nokia N9, though s1p sends the audio to correct port number (7078), it sends it to the wrong IP address, i.e. to (IP address of PBX).

What I see different when I compare the INVITE request from N9 with those of Gigaset and Android phones is that the order of the lines m and c is reversed between N9 and the other clients.

In case of Gigaset and Android, line c comes before line m and thus audio works fine (goes to c).

In case of N9 however, c comes after m, and thus s1p picks up the IP address from the o line and port number from the m line, and ignores the c line. Audio ends up at o instead of c.

I think s1p stops looking for the IP address of the other party as soon as it parses the m line and/or reads in the port number. I hope you can find something in your code around that place in order to try to fix this issue.

unmaintained's picture

could you please check if the Nokia N9 works with version 0.4.7 or above?

emsys's picture

With version 0.4.7, audio works bothways with Nokia N9 now. Thanks for the update.

emsys's picture

Would it be possible for you to change the listening port of s1p to something other than 5060? It would add even more flexibility if you can make it into a configuration item on the Settings page.

The reason I am asking is that since I have 3CX running on a Raspberry Pi at home and my DSL router blocks all incoming and outgoing traffic destined to port 5060. The statement from the ISP is that port 5060 is reserved for their own voip gateway for customers who use their phone service in addition to Internet and thus is not available for any other use. This is also the reason my 3CX is listening on port 5061 instead of 5060.

unmaintained's picture

Could you please try it with version 0.4.4 ?
You should be able to set the bind-port on the settings page along with the bind address.

emsys's picture

Thanks for the new release. Although it turned out that the bind port was not the reason for the failure of registration. I had overlooked a fairly simple fact, i.e. trying to register s1p via data connection of the phone goes through at least one NAT layer at the network operator's infrastucture and thus the sending port is never the same as the bind port used by s1p.

Now coming to the problem, I think, the reason for registration to fail over NAT is the missing rport parameter from the Via header of REGISTER request. What happens when rport is missing, is that 3CX sends the response to register to the bind port used by s1p, which is indicated in Contact header instead of sending it back to the UDP port (of NAT) where the REGISTER requested was originally received from. I was able to capture REGISTER requests from a Nokia N9, builtin SIP stack of Android, as well as my desk phone - they all are sending the rport parameter in Via header.

Since 3CX sends the 407 Proxy Authentication Required response to a port that is non-existent, s1p never receives the response to REGISTER request. Thus s1p keeps sending REGISTER requests after a timeout which results in 3CX blocking the IP address. Which brings me to part two of this problem.

You said in an earlier message that 3CX did not let you log in due to too many failed authentication while you didn't even try to authenticate. The reason was that 3CX had added your IP address to the blacklist when s1p failed to authenticate.

The good news is that 3CX blocks an IP address for a limited amount of time and you might be able to log in again to your installation if it is still there. Alternatively, you can try to reach it from a different IP address.

Would it be possible for you to add the rport parameter?

unmaintained's picture

Beginning with version 0.4.5 you should be able to activate the rport tag as an option on the settings page

emsys's picture

Thanks for the quick update. I can now register via NAT, and can also make and receive calls when away from home.

The call hangup issues is still there and if my call ends up in a voice mailbox, I cannot hangup from s1p. I wish you could work on a solution for that issue.

unmaintained's picture

This issue should have been fixed with version 0.4.6.

emsys's picture

With version 0.4.6, s1p can indeed hangup a call without waiting for the other side to hangup. Thanks for the fix.

Trenien's picture


So far, no issue with it (version 0.4.0-1 on Xperia X)


Anybody knows how to configure the phone to be able to answer incoming calls without having to unlock it first?

unmaintained's picture

Locking the screens seems to work over dbus but it seems not to be possible to unlock it that way.

petros's picture

great app, finally we can use sip as we could do natively on N9. works perfectly with justvoip. many thanks for you work

unmaintained's picture

Thank you.
Coming from the N900 I've alse been disappointed SIP was not available on SFOS from the start.

ichthyosaurus's picture

Thank you for your work!

Just a small thing: would you mind adding new changelog entries at the top? You can use the 'tac' command on GNU/Linux to reverse the existing entries.

unmaintained's picture


llv95dno's picture

Hi, thank you for your hard work. It started to work for me through provider sip.cellip.com with version 0.3.6 (only occasional problem with hangup), but stopped with 0.3.7. Sent you a log, hopefully you can make something out of it. It says: ERROR [Sipserver-1] Invite [3ed90a39@]
INVITE (authenticated) already set

unmaintained's picture

Seems to be the same issue @emsys has with 3CX.

s1p stumbles over a "401 Unauthorized" when it does not expect it. I tried to relax this behavior in 0.3.6 but it confused the UI so I had to revert back to a more rigid scheme.

llv95dno's picture

Ok thank you. It seems that you are right. Checked with the provider and they use 3CX. 0.3.6 worked quite well for me, and if it is possible to revert (could not find 0.3.6), I would be glad to do so, until the problem is solved.

unmaintained's picture

You could try version 0.3.8 instead.

llv95dno's picture

Thanks. It works, still occasional problem with hangup.

unmaintained's picture

I'm not entirely sure where these may come from and getting a 3CX instance working to test against unfortunately proved to be super hard.

emsys's picture

Hello, First of all, I would like to congratulate you for taking this initiative for a long overdue feature of SFOS.

I tried to test your app on Xperia XA2 with a self hosted 3CX PBX installed on a Raspberry Pi in a LAN configuration. The application fails to authenticate with the PBX and gets stuck in an infinite authentication loop until SFOS flags the application as non-responsive and hence offers to terminate the application. The app gets stuck on subsequent restarts since it gets stuck in the authentication loop, and hence I cannot extract/send the log file from within the app.

However, I started the app from command line and was able to capture the debug log. What I think goes wrong is that the PBX returns a 407 Proxy Authentication Required response and s1p sends an Authorization header instead of a Proxy-Authorization header. Interesting sections in the log go like this:

b'DEBUG [SIPServer-1] Register [6696721c@] - from: 152 (, ua: s1p, to: 152\n'
b'TRACE [SIPServer-1] WritePacket: => (REGISTER) sip:;transport=UDP\n'

b'TRACE [SIPServer-1] Run - received from:\n'
b'SIP/2.0 407 Proxy Authentication Required\r\n'
b'Via: SIP/2.0/UDP;branch=z9hG4bK-7b4e7c02\r\n'
b'Proxy-Authenticate: Digest nonce="414d53595f0e1eec78:f11faae83a263976e10e57789a105ce5", algorithm=MD5,realm="3CXPhoneSystem"\r\n'

b'DEBUG [SIPServer-1] Register [6696721c@] - from: 152 (, ua: s1p, to: 152\n'
b'TRACE [SIPServer-1] WritePacket: => (REGISTER) sip:;transport=UDP\n'
b'Authorization: Digest username="ulzA7FZrKq",realm="3CXPhoneSystem",nonce="414d53595f0e1eec78:f11faae83a263976e10e57789a105ce5", uri="sip:;transport=UDP",response="3c4ce565d5733b6522c357f2d3bc9ae3",algorithm=MD5\r\n'

b'TRACE [SIPServer-1] Run - received from:\n'
b'SIP/2.0 407 Proxy Authentication Required\r\n'
b'Via: SIP/2.0/UDP;branch=z9hG4bK-189eeb98\r\n'
b'Proxy-Authenticate: Digest nonce="414d53595f0e1eec20:5b99c474226d0360da759a504a02fdea", algorithm=MD5,realm="3CXPhoneSystem"\r\n'

This ping pong continues without any delay until the app is terminated by the OS.

When I compare this with the SIP registration session of my Gigaset DX800A phone with the same PBX and same extention, I indeed see that the phone sends a Proxy-Authorization header in response to 407 Proxy Authentication Required.

Here is a link to RFC2617 that also confirms this: https://tools.ietf.org/html/rfc2617#section-3.6

I have also recorded wireshark logs for both s1p and my Gigaset phone, please let me know if there is a way I can send them to you. For further testing, please feel free to contact me.


unmaintained's picture

Could you please check if this issue occurs with version 0.3.5 as well?

emsys's picture

Thanks for the new release; I can confirm that the 0.3.5 version sends Proxy-Authorization header in response to code 407 Proxy Authentication Required during REGISTER sequence.

However, when I try to make a local call to another extension, the PBX responds again with a 407 Proxy Authentication Required code in response to the INVITE request. s1p sends ACK but never sends the INVITE again with the Proxy-Authorization header included.

When I compare this with my desk phone, I see that the phone sends the INVITE again with Proxy-Authorization header, to which the PBX then responds with 100 Trying.

I have sent the log file via s1p, log id: 28

unmaintained's picture

Thank you for providing the log dump.

Does this issue still occur with version 0.3.6 ?

emsys's picture

Thanks for the new release. With v0.3.6, I can now make and receive calls via s1p as it sends INVITE again with Proxy-Authorization header included when requested by PBX.

However, I encounter the following two issues now.

1. Call Hangup issue, log file: 29

Call hangup from within s1p does not work when a call is initiated by s1p. But if the call is terminated by the other party, then s1p can also hang up. The app status changes to "Hangup Reuqested" but the call continues on the other end unless hung up from the other side as well. s1p then returns to idle.

What I see in the wireshark logs on my PBX is that the PBX simply ignores the BYE request sent by s1p. Neither does it respond to s1p, nor does it send BYE to the other party. The call keeps going between the PBX and the other party until I end the call from the other phone. In that case, the desk phone sends BYE to PBX and PBX then sends BYE to s1p, and the call is terminated.

An interesting fact that I noted in wireshark was that if I dial s1p from my desk phone, and then end the call from the desk phone as well, I see that the phone sends Proxy-Authorization header in BYE request as well. In comparison, s1p does not include the Proxy-Authorization header when trying to terminate the call.

Another point of interest is that if s1p initiates the call, and the phone ends it, the phone does not send Proxy-Authorization header in BYE request. It only does so for the call that is initiated from the phone itself.

2.1. No Audio when receiving a call from desk phone, log file: 30

When I dial s1p from my desk phone, the call is established, but there is no call audio at all, not from the speaker, headset, or earpiece of the Xperia. There is no audio on the phone either. (Audio however works fine when the call is initiated from s1p, case 1 above)

2.2 One way audio with Nokia N9, log file: 31

I also tried to call from a Nokia N9 with its builtin SIP client. This time, there was one way audio, from N9 to s1p. However, I was able to capture the audio packets coming from s1p to the IP address of the PBX, with the PBX replying to s1p with an ICMP message that the RTP destination port is not reachable. So, instead of audio going from s1p to N9, it went from the s1p to the IP address of PBX.

In wireshark, I could see that both N9 and DX800A support the G.711 PCMA/PCMU codecs. I think something goes wrong with the RTP port exchange. I also enabled the option in the PBX to have all audio delivered via the PBX. This way, I can hear audio from both sides, but there is additional delay introduced due to extra buffering on the PBX.

Please let me know how can I assist further.