Really Confusing Bug

Found something wrong ?
Post Reply
Malcolm Merlyn
Posts: 1
Joined: Sun Sep 10, 2017 1:38 pm

Really Confusing Bug

Post by Malcolm Merlyn » Sun Sep 10, 2017 1:57 pm

Sometimes when I make a call using Sip Sorcery I get weird lag, and whats stranger if I restart the program by completely exiting and opening it again I sometimes get the same lag except I can still hear the end of the last call as well as the new call. Here is an example: https://www.youtube.com/watch?v=VZrfNwopgb0

This has happen on 2 separate computers and on various internet connections, my computers and internet shouldn't be a problem (i7 6700k, 16GB DDR4 RAM and so on).

User avatar
Aaron
Site Admin
Posts: 4563
Joined: Thu Jul 12, 2007 12:13 am

Re: Really Confusing Bug

Post by Aaron » Sun Sep 17, 2017 11:45 pm

It should be straight forward to track down the call set up lag. The areas to focus on are:

1. DNS lookups (most likely culprit).There are lotsoof log messages but an even quicker way to check is to make the call with an IP address ainstead of a host name,

2. Server response time. A 100 Trying response should be received within about a second of the initial INVITE request being sent. If not it could be that the serve is under load,

3. If the lag happens in between the 100 Trying response and the 180 Ringing response it could be that the SIP device at the other end of the call is taking a bit of time to respond.

> Here is an example: https://www.youtube.com/watch?v=VZrfNwopgb0

That's what can happen with UDP. If you don't ask the other end of the call to stop sending audio (using a BYE request) it could keep sending for quite a while. Eventually it should time out when it doesn't receive any audio back or it gets an ICMP error message.

In this case where you restart the process within a short space of time the audio from the first call is still being sent and your second call assumes it's the new audio. Ideally you should send the BYE request to end the first call before ending the process. You could also use a random RTP port range to mitigate the issue, the approach I use is to use a set range which starts at the same point every time the application starts.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest