| Author |
|
plynham
Intermediate
Joined: October 29 2005
Location: United Kingdom
Posts: 7
|
| Posted: October 31 2005 at 12:00pm | IP Logged
|
|
|
We have a customer who is frequently experiencing a gurgling sound (they say an underwater effect) and we are trying to establish the cause. We have attempted to simulate the problem by making calls on our test system to the speaking clock. The call is recorded perfectly on Asterisk as if we just play back the file, it sounds normal. It also sounds normal the first time we play it back on the client application. However, subsequent calls to play back the recording gets a distorted playback.
We think the problem may be that after the first call from the client, the congestion sound is issued by Asterisk after the recording has finished, but the call is not being hung up properly and on subsequent calls, we are getting a mix of the recording and the congestion sound. Looking at the logs we have:
31/10/2005 16:15:12 | Client: Connected
31/10/2005 16:15:12 | Raw IN:get_ext_no,,,,.
31/10/2005 16:15:12 | RAW OUT:EXTENSION_NO,10023,,,.
31/10/2005 16:15:37 | Raw IN:dial,90000F75219EDE28C8520,,,.
31/10/2005 16:15:37 | Attempting to dial: 90000F75219EDE28C8520
31/10/2005 16:15:37 | SIP: SipOutgoingCallInitializing
31/10/2005 16:15:37 | SIP: SipOutgoingCallStart
31/10/2005 16:15:37 | SIP: SipDialTone
31/10/2005 16:15:37 | SIP: SipDialing
31/10/2005 16:15:37 | SIP: SipSendInvite
31/10/2005 16:15:37 | SIP: SipStartOutgoingRing
31/10/2005 16:15:37 | SIP: SipPortTranslationError
31/10/2005 16:15:37 | SIP: SipWaitForInviteOk
31/10/2005 16:15:37 | SIP: SipInviteOkReceived
31/10/2005 16:15:37 | SIP: SipSendInviteAck
31/10/2005 16:15:37 | SIP: SipOutgoingCallConnected
31/10/2005 16:15:37 | SIP: SipInCall
31/10/2005 16:15:37 | RAW OUT:OUT_STATUS_CONNECTED,,,,.
31/10/2005 16:15:40 | Raw IN:hangup,,,,.
31/10/2005 16:15:40 | Attempting to hangup.
31/10/2005 16:15:40 | SIP: SipSendBye
31/10/2005 16:15:41 | Raw IN:dial,90000F75219EDE28C8520,,,.
31/10/2005 16:15:41 | Attempting to dial: 90000F75219EDE28C8520
31/10/2005 16:15:41 | SIP_ERR: SipCallAlreadyInProgress
31/10/2005 16:15:42 | RAW OUT:ERROR,SipCallAlreadyInProgress,,,.
31/10/2005 16:15:42 | SIP: SipByeAckNotReceived
31/10/2005 16:15:42 | SIP: SipCallComplete
31/10/2005 16:15:42 | SIP: SipOnHook
As you can see, we have attempted to hang up and then try to dial and get a SipCallAlreadyInProgress error followed by the SipByeAckNotRecieved, but this is followed finally by the SipOnHook. Subsequent checking showed the rtp stream from the Asterisk server to still be active, so as far as the Asterisk server is concerned, the SIP session never terminated.
Is this a timing issue or is there something else that we are missing?
|
| Back to Top |
|
| |
lsadmin
Administrator
Joined: October 01 2003
Location: United States
Posts: 19
|
| Posted: October 31 2005 at 1:44pm | IP Logged
|
|
|
I think your analysis is very close to correct.
The SipPortTranslationError error event is telling us something. Try posting a SIP message log from your customer (or your simulation that experiences the same problem) to this forum thread. If you are not testing the same network deployment (with same firewalls/router types) as your customer has, you will probably not see the same error when you test in your lab. Only guessing at this point but it looks like a router/firewall port translation issue at your customer's location.
It may be possible that your client app (VOIP Media Engine) is sending the SIP BYE message to some other IP address or port - not to the Asterisk box. This is possibly why the Asterisk call is not being terminated. I say this because your client app never gets a SIP ACK back from the BYE that was sent to Asterisk (SipByeAckNotReceived). This is an indication of a call termination timeout. Either Asterisk got the BYE and never responded or the BYE was not sent to Asterisk's ip:port.
Also, the subsequent call is getting the SipCallAlreadyInProgress status because the previous call termination did not finish before you tried to make another call. A new call can be made only when the line status is SipOnHook. I assume you made an asynchronous call to the TerminateCall() API proc.
Repost a SIP log so we can go further.
Support
|
| Back to Top |
|
| |
plynham
Intermediate
Joined: October 29 2005
Location: United Kingdom
Posts: 7
|
| Posted: November 23 2005 at 9:01am | IP Logged
|
|
|
Hi.
Sorry for the delay, we have been doing some more thorough testing.
We think we have pinpointed this problem down to a BYE sent to the server. We have looked at the ASTERISK sip log and can clearly see that the BYE is received by asterisk but ASTERISK is not processing the BYE, at least it is not sending a 200 OK.
This happens randomly, and appears to be a bug in Asterisk.
As a temparary workaround I am going to create a HANGUP extension and transfer calls there to be hungup. Hopefully this will get our customer off our back until we can come up with a better resolution to the problem.
Our technical department has looked at competing media libraries and at packets from our sip phones and has found that if an BYE-ACK is not received by them they tend to resend the BYE request. Lanscape ME does not do this... I wonder if it is feasible for you put this in as a feature ASAP.... Please let me know urgently.
We are going to look at putting an intelligent proxy between lanscape and Asterisk and hope that it resends BYE's which are not acknowledged.
Cheers,
Paul
|
| Back to Top |
|
| |
plynham
Intermediate
Joined: October 29 2005
Location: United Kingdom
Posts: 7
|
| Posted: November 23 2005 at 9:38am | IP Logged
|
|
|
Hi I have setup an extension which I was going to transfer calls to be hangup. The only thing now is that asterisk reports that lanscape is trying to use a depreciated sip command: BYE/ALSO. The log-file tells me to contact the vendor and ask them to implement REFER!
Cheers,
Paul
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 23 2005 at 10:21am | IP Logged
|
|
|
Hi Paul,
Thanks for posting your current results. Good information. Your observation regarding BYE retransmission has been noted. Maybe it will get into the next release. Can't make any promises at this time though. If Asterisk is receiving the BYE request (and logging it) and not processing it, Asterisk is probably not matching the BYE and the call leg info (call ID, to tag, from tag, etc) with its current list of active calls. We would be interested in seeing the received BYE SIP message from the Asterisk log.
There are plans to include other SIP message types for an upcoming release - REFER is one of the new supported message types. Bye-Also may be depricated from the RFC standpoint, but we have many customers who are using it and we will continue to support it. the Asterisk log file comment is interesting.
Support
|
| Back to Top |
|
| |
plynham
Intermediate
Joined: October 29 2005
Location: United Kingdom
Posts: 7
|
| Posted: November 23 2005 at 10:31am | IP Logged
|
|
|
I need to find a solution to this fairly urgently... could we pay you a consultancy fee to knock up a patch to retransmit the BYE? You can reply to plynham@leadgenpro.co.uk with a quote.
Cheers,
Paul
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 23 2005 at 11:19am | IP Logged
|
|
|
Paul,
Your request hase been forwarded to our engineering department. They will contact you as soon as possible.
Support
|
| Back to Top |
|
| |
plynham
Intermediate
Joined: October 29 2005
Location: United Kingdom
Posts: 7
|
| Posted: November 23 2005 at 12:57pm | IP Logged
|
|
|
We did not get very far with our transfer idea but have come up with another plan:
When we detect ByeAck not received in the CallBack method we are going to restart the sip telephony engine using a different range of RTP ports. This will mean that we will not get RTP data from our old dead call (which should have hung up) spat back at as from the PBX. (The gurgling is caused by the dead-call interfering with the next new call we want to place. We will place a 20min max call duration on Asterisk so that the dead-call will eventually be hung up.
My question to you is: Is it safe to do a ReStartSipTelephony from within the CallBack method or do I need to set a thread-safe flag and do it from the main-thread?
I hope you agree that resending BYE packets when no ACK is received is a high-priority feature / fix as we are dealing with the unreliable UDP protocol here so need to take lack of ACK's seriously, not just discard and presume the line got hung up (I know in this case that Asterisk is at fault, but what about other cases when the BYE packet might be lost on route.).
Cheers,
Paul
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 23 2005 at 2:11pm | IP Logged
|
|
|
Hi Paul,
Your plan to restart the media engine using a different RTP UDP port is an interesting approach. That’s using your head.
You must call the ReStartSipTelephony() API proc outside of the event handler callback. Call it from any thread context you want but don’t call in from within the event handler.
We agree with your point about losing UDP packets. As was previously mentioned, the media engine will continue to evolve with improved and updated capabilities as we offer new releases. Offering a way for user’s to control SIP message retries will be addressed. There are many cool things in the works and we are trying hard to get these new capabilities to our customers. Your feedback is important and appreciated.
As you stated, the problem is not UDP packet loss. I would seriously consider pulling out your favorite Linux debugger and find why Asterisk is dumping the BYE message. Did you guys built your own Asterisk image from source code? We have other customers using the media engine with Asterisk and this “ignoring the BYE” issue has not been reported until now. Hmmm…
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 07 2006 at 9:56am | IP Logged
|
|
|
Hi Paul,
We wanted to let you know that we have modified the VOIP Media Engine to resend additional BYE SIP messages when there is no "200 OK" response to the first BYE that is sent.
The new capability will be included in the upcoming version 5.11 releaase. Also note that v5.11 will also include aLaw codec support, G729/G729A, 20Ms and 30Ms iLBC low bitrate code support and a host of other improvements and features.
Thanks again for posting your original information. Very helpful.
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Corrupted playback
