Jump to content
PortSIP PBX for Unified Communications

Lehel Medves

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The flickering is not happening if only one audio codec is sent upon registration. It still happens every now and then, but it usually does not.
  2. The issue is solved if there is only a single audio codec sent to the PBX, that is what I've experienced just now, but I'll get back to you if I find anything else.
  3. 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?
  4. Hello, Sure. The issue is the following: user A calls user B, when user B is not registered in PBX (closed the app for example) a VoIP push notification wakes the application of user B, which then registers with the PBX and receives the INVITE for some reason the media negotiation fails right after user B answers the invite Some additional information: user A registers with 3 audio codecs user B registers with the same 3 audio codecs after user B answers the call, on user A's side the onInviteUpdated is called with just one codec
  5. Quick update: if I choose to set sendSdp to false when using the portSIPSDK.call method, then the call is connected even in the first described scenario. How should the call method be invoked?
  6. 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?
  7. Hello, I am developing a VoIP application for iOS and I've run into the following problem: Caller is registered in the PBX Callee is not registered in the PBX Caller initiates outgoing call Callee receives a VoIP push notification, which starts the application in the background Callee performs the registration Callee receives the invitation even before the onRegisterSuccess callback Callee answers the call by invoking portSIPSDK.answerCall Callee gets 0 as the result of the previous call Caller instead of a 200 OK gets a 504 timeout Two notes on the above issue: If the same experiment is run while the callee is registered, then it works, the call gets connected The PBX logs state the following error: Timeout during media negotiation for call Thanks and regards, Lehel
  8. 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?
  9. 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.
  10. 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.
  11. 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
  12. Understood, thank you very much for your input, will rely on VoIP pushes instead.
  13. 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?
×
×
  • Create New...