Jump to content
PortSIP PBX for Unified Communications
Lehel Medves

iOS SDK issue with outgoing calls

Recommended Posts

Hello,

I've tried the SIPSample iOS project and the following is happening whenever initiating a call from SIPSample and accepting it on the other end:

  • the call is initiated
  • the onInviteTrying comes in
  • the onInviteRinging comes in
  • the other party accepts the call
  • the onInviteAnswered comes in 2-3 seconds late
  • the onInviteConnected comes in

Besides this, between the the remote party answering the call and the onInviteAnswered coming in (that 2-3 second gap) the microphone icon is flashing in the iPhone's status bar, the sound is breaking up, like the audio session is trying on and off to be configured.

Any help with the above issue would be much appreciated. A screencast can be seen here.

Thanks and regards,
Lehel

Share this post


Link to post
Share on other sites

Hi Lehel,

   1. onInviteAnswered event delay  .

Usually caused by the client receiving the 200OK delay sent by the server.
You can check this problem in real time by capturing packets, whether the event is triggered immediately when the client receives 200OK.

Capture packet :https://useyourloaf.com/blog/remote-packet-capture-for-ios-devices/

2. party answering the call and the onInviteAnswered coming in (that 2-3 second gap) the microphone icon is flashing in the iPhone's status bar

Are you changed our SIPSample code?

 if you run our SIPSample project without any modify and it works fine ?

 

Share this post


Link to post
Share on other sites

Hey Joe,

Thank you for the quick input.

1. I will try remote packet capturing and get back to you with what I can find.

2. Yes, I have just downloaded the SipSample_swift, I have only changed the bundleId and the code signing, but it has the same behavior. Furthermore, I have downloaded the "PortSIP Softphone" application from the AppStore and it also has the same issue. It might be the PBX at fault, that I will know when I check point no.1 from above.

Thanks and regards,
Lehel

Share this post


Link to post
Share on other sites

With WireShark I managed to trace the outgoing call on the real device (SIPSample_swift calling another device also running SIPSample_swift).

34    6.011255    192.168.1.4    192.168.1.14    SIP/SDP    1029    Request: INVITE sip:234@192.168.1.14 | 
40    6.012165    192.168.1.14    192.168.1.4    SIP    459    Status: 407 Proxy Authentication Required | 
42    6.012384    192.168.1.4    192.168.1.14    SIP    323    Request: ACK sip:234@192.168.1.14 | 
43    6.012477    192.168.1.4    192.168.1.14    SIP/SDP    1282    Request: INVITE sip:234@192.168.1.14 | 
47    7.015044    192.168.1.14    192.168.1.4    SIP    502    Status: 100 Trying | 
54    7.016063    192.168.1.4    192.168.1.14    SIP/SDP    1282    Request: INVITE sip:234@192.168.1.14 | 
55    7.016170    192.168.1.14    192.168.1.4    SIP    502    Status: 100 Trying | 
56    7.016226    192.168.1.14    192.168.1.4    SIP    740    Status: 180 Ringing | 
80    12.026490    192.168.1.14    192.168.1.4    SIP/SDP    1124    Status: 200 OK | 
81    12.026579    192.168.1.4    192.168.1.14    SIP    498    Request: ACK sip:234@192.168.1.14:5060;user=phone;transport=UDP | 
95    13.029182    192.168.1.14    192.168.1.4    SIP    770    Request: INVITE sip:35@192.168.1.4:10002, in-dialog | 
114    13.030653    192.168.1.4    192.168.1.14    SIP    301    Status: 100 Trying | 
117    13.030841    192.168.1.4    192.168.1.14    SIP/SDP    1151    Status: 200 OK | 
119    13.030969    192.168.1.14    192.168.1.4    SIP/SDP    855    Request: ACK sip:35@192.168.1.4:10002 | 
621    21.078167    192.168.1.4    192.168.1.14    SIP    781    Request: BYE sip:234@192.168.1.14:5060;user=phone;transport=UDP | 
625    21.078486    192.168.1.14    192.168.1.4    SIP    456    Status: 200 OK | 

PBX address: 192.168.1.14
Outgoing call initiator device address: 192.168.1.4

What do you see? Anything unusual?

Thanks and regards,
Lehel

Share this post


Link to post
Share on other sites

56    7.016226    192.168.1.14    192.168.1.4    SIP    740    Status: 180 Ringing | 
80    12.026490    192.168.1.14    192.168.1.4    SIP/SDP    1124    Status: 200 OK | 

Received the 200OK after ringing  5 sec.  is this the delay you mentioned?

Share this post


Link to post
Share on other sites

No, that is actually the 5 seconds the phone was ringing, because the second line from your message shows when the PBX sent the "answered" event towards my application. From the trace as far as I can tell, the PBX sends the OK fast, I think the cause for the delay is inside the PortSIP framework somewhere.

Please look at the following screencast and let me know what you think. Why is the microphone icon flashing? The sounds is also flickering, like there was an issue setting or initializing the audio session: https://www.dropbox.com/s/9u2n89htna3vk3c/PortSIPOutgoingCallIssue.mov?dl=0

Thanks and regards,

Lehel

Share this post


Link to post
Share on other sites

The  microphone icon is iOS system display,  i test when the call hangup, will flashing the icon one time.

can you capture the packet on your server, make a call, send the packet file to me.

Share this post


Link to post
Share on other sites

Yes, it should flash exactly one time when the audio session is configured I guess, but in this case it flashes multiple times while audio is flickering and it seems, that the call is only connected after that flickering stops, 4 seconds after the OK has been received.

I managed to capture the communication on the PBX itself. Please let me know if I'm wrong, but this is how I read it (192.168.1.4 is the caller, 192.168.1.3 is the callee and 192.168.1.14 is the PBX😞

  • Marked line 1: PBX notifies caller, that the the call is RINGING (at 44.22s)
  • Marked line 2: callee notifies PBX, that the call has been accepted (21 seconds later, indeed, I let it ring roughly 21 seconds)
  • Marked line 3: PBX notifies the caller, that the call has been accepted (not even a tenth of a second later)
  • Marked line 4: caller notifies PBX, that it received the acceptance and the call can be connected (almost 4 seconds later <=== this is the problem)
  • Marked line 5: caller notifies PBX, that the call has ended (1 minute later, indeed, I let the call go on for roughly 1 minute)

As you can see, the red remark indicates, that the caller takes 4 seconds to reply to the PBX - why do you think this is?

Screen Shot 2020-05-22 at 9.09.40 PM.png

Share this post


Link to post
Share on other sites

When PBX Received callee answer call, why PBX send INVITE to Callee again?

image.thumb.png.8d99d04780eedd7bd9663d84a6ad7d62.png

Marked line 4: caller notifies PBX, that it received the acceptance and the call can be connected (almost 4 seconds later <=== this is the problem)

I think ID 412 66.130 is this caller response server 200OK message.

Is this one call, why are there multiple INVITE messages?

Can you send the capture file to me?

Share this post


Link to post
Share on other sites

Good question why the PBX sends multiple invites, but I do not have any control over that unfortunately. Might this be the problem? Can you see the microphone icon flashing multiple times when connecting an outgoing call when you test it with SIPSample_swift? Do you also experience the 3-4 second delay and audio flickering that I mentioned above?

Please find the pcap file here: https://www.dropbox.com/s/ev41e36h44ovlbr/log.pcap?dl=0

Share this post


Link to post
Share on other sites

Quick additional question: is there a method in the PortSIP framework, that I can use to check whether there is an existing registration? The reason I'm asking is, that if the user force-closes the application, the registration stays in the PBX and when I open the application up again, it will try to register again, even though I'm already registered.

Share this post


Link to post
Share on other sites

Solved it! It seems, that the supported/negotiated audio codec was the problem, my application added AUDIOCODEC_OPUS as the first one and so that was what the negotiation with the callee and my app agreed upon. After I changed it to AUDIOCODEC_G722, the audio session issue disappeared instantly.

Share this post


Link to post
Share on other sites

 

Usually when the call information changes, send INVITE again to update the SDP of the call Or for session-time check.

Update SDP will recreate RTP channel, When the RTP channel is frequently recreated, the call audio may be stuck. i think the microphone icon flash Is this reason.
 

I don't know why need this package

image.thumb.png.b8370279986199b8b2f2061726226688.png

 

Share this post


Link to post
Share on other sites

Actually, I was too fast to declare victory, there is still a bit of flickering and now a 2-3 second delay "only", but it doesn't seem as bad as with the other audio codec. I'll experiment with further options as well in this area.

When I start a new call and it gets answered, from where can I retrieve the time of connection in order to sort of sync clocks?

Share this post


Link to post
Share on other sites

Quick update: if I choose to set sendSdp to false when using the portSIPSDK.call method, then the microphone flickering and delay is placed on the other side, to the callee's side. What could cause this? How can this be fixed?

Share this post


Link to post
Share on other sites
10 hours ago, Lehel Medves said:

Quick update: if I choose to set sendSdp to false when using the portSIPSDK.call method, then the microphone flickering and delay is placed on the other side, to the callee's side. What could cause this? How can this be fixed?

sendSdp to false, means INVITE message without SDP, 200 OK and ACK will Bring SDP.

The reason for the microphone flashing is that the server has updated SDP, and the client needs to restart the audio channel. When the IOS system detects that the microphone is stopped, an icon will appear. If the server sends INVITE multiple times, there will be multiple flashes.

 

Share this post


Link to post
Share on other sites

I understand, thank you!

So does this mean, that the PortSIP SDK handles all this stopping and starting of the audio session?
What happens if I only advertise a single audio codec? Would that help getting rid of the flashing and the delay?

Share this post


Link to post
Share on other sites
20 minutes ago, Lehel Medves said:

I understand, thank you!

So does this mean, that the PortSIP SDK handles all this stopping and starting of the audio session?
What happens if I only advertise a single audio codec? Would that help getting rid of the flashing and the delay?

This multiple INVITE is initiated by the server, I am not sure if the server will send multiple INVITE when there is only one codec, you can use one codec test again.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...