| Author |
|
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: January 28 2010 at 4:44pm | IP Logged
|
|
|
We are placing outbound calls and some of our recipients are reporting that:
(1) they hear our message (wave files being played) for a few seconds and then the call abruptly ends.
(2) they do not hear our wave files being played at all and therefore they hang up.
After analyzing the SIP logs this is what we noticed.
Here is specific scenario #1.
Lanscape | Provider(Bandwidth.com)
|
INVITE-> |
| <-100 (Giving a try)
| <-183 or 180 (Session Progress)
| <-200 OK (Connect)
ACK-> |
| <-200 OK (Another 200 OK is seen in the log files, even though one was sent already. Far end will continue to send them because maybe it never got the ACK response)
| <-200 OK (Rending…)
| <-BYE (Call hangs up after about 13 seconds)
One likely scenario is that the far end did not receive the ACK probably due to packet loss. Are there any other probable causes?
What can we do here? Can the LME resend an ACK when the provider resends the 200 OK(connect)? How can the LME helps us deal with packet loss?
Here is specific scenario #2.
Lanscape | Provider(Bandwidth.com)
|
INVITE-> |
| <-100 (Giving a try)
| <-200 OK(Connect), but where is the 183 session? It's missing from the log files.
ACK-> |
| <-BYE (User hangs up)
One likely scenario in this one is that the 183 session was lost. Are there any other probable causes?
This looks like the user waits a few seconds to hear something and hanging up the phone when they do not hear anything. How will the LME handle this scenario?
How can the LME helps us deal with packet loss?
Thanks.
-AJDiaz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 28 2010 at 5:34pm | IP Logged
|
|
|
Hello Aj,
It is good to hear from you again – thanks for your post.
I read your post – Yes it would appear that the terminating equipment at Bandwidth.com is either not receiving the final INVITE ACK or their equipment is rejecting it.
I am just about to leave for the day. I am sorry but I will have to work on this immediately in the morning.
SIP Log from the media engine:
Is it possible that you can upload to your LS support FTP account the actual SIP log for a failed call? This will help very much.
1)
We need to know that the final ACK is being sent to the proper IP:port for the call at Bandwidth.com.
2)
Also, I need to see the actual SIP ACK message the media engine is transmitting. I need to see if it is malformed in any way.
Matt should have the login info to your LS support FTP account. Your FTP account is enabled for upload of data.
Here’s a bit of a stinger:
Your group’s last support agreement was from 1-1-09 until 12-31-09. If you can, speak with Matt and see if we can renew this again. We are behind in sending out January LS support invoices and that is why you have not received a renewal as of yet. This year’s support can use the same terms as last year. Please see item #3 from last year’s LS invoice #081230-1408.
Thank you Aj,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: January 29 2010 at 4:24pm | IP Logged
|
|
|
Hi Randal,
Two SIP files were uploaded to the FTP account.
I will bring up the support agreement here. I doubt I can get a copy of last year’s LS invoice #081230-1408. Sorry.
Thanks for your help on this question.
AJDiaz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 29 2010 at 6:51pm | IP Logged
|
|
|
Hello AJ,
I will be working this weekend so I will be review the SIP logs either Saturday or Sunday. Good work and thanks for uploading these files!
Thank you,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: February 03 2010 at 11:50am | IP Logged
|
|
|
Hi Randal,
Any insight on this?
Thanks in advance.
-AJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 03 2010 at 12:12pm | IP Logged
|
|
|
Hello AJ,
Wow... that’s weird. I was just looking at your SIP log files.
The SIP traffic looks good. The ACK going back to the server does not appear to be malformed.
The one item that may be causing the grief is the ACK’s “Route:” header.
Code:
Route: <sip:216.82.224.202;lr;ftag=2df39c5c>,<sip:+18137823323@209.247.16.221>
|
|
|
The route header contains the server’s ip:port and the ip:port that was in the “200 OK” contact header. I bet the server is not processing the ACK properly – instead, the server is probably sending the ACK back to 209.247.16.221 which is making the server think that he did not receive the ACK for the call.
You can perform a simple test in your code:
In your VOIP app’s source code, intercept the transmitted ACKs and manually remove the contact’s ip:port in the route header. In other words, make your ACK’s route header look like this:
Code:
Route: <sip:216.82.224.202;lr;ftag=2df39c5c>
|
|
|
…and see if it solves the issue.
Another alternative would be for your code to completely remove the ACK’s route header and see if that solves your problem.
Note:
It would be very, very helpful for your group to renew your annual support so that we may assist fully when SIP inter-op issues arise. Let me reiterate the importance of you being one of my customers – we greatly appreciate you.
Thank you,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: February 03 2010 at 1:39pm | IP Logged
|
|
|
Hi Randal,
Thanks for the info.
Because most calls are OK and only a few are having this issue, we first believed that the ACK message is OK, but that maybe it was lost and never received. Same thing with the 183 message, it is completely missing from the log files, so we think that it was lost. You don't think there is a likelihood?
Say for arguments sake that packets are being lost, what solutions or alternatives would we have or the media engine provide? Whether it is the ACK not received by the far end or the 183 not received by the media engine?
We will try your suggestion, but it would not address the issue with the missing 183 message.
Regarding the support agreement, I will email you separately about that.
Thanks again,
AJD
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 03 2010 at 2:31pm | IP Logged
|
|
|
Hello Aj,
Ahhh…. I see your point regarding the complete loss of the ACK due to the behavior of UDP packets and the network.
This might be a good question for the SIP trunk provider. I assume they terminate the call if the INVITE’s ACK is not received – just like you are seeing.
1)
Is it possible the SIP trunk provider can allow the call to exist even if the INVITE’s ACK goes missing? Probably not…. Funny thing – the media engine can be configured to allow calls on missing ACK…
If you are right about the lost ACK message, you can do something about this yourself.
Here is what you can do:
Have your VOIP app intercept the call’s ACK message using the ModifySipMessage event.
In the ModifySipMessage event handler code, call the SendUdpDatagramUsingSipPort() API procedure to transmit one or more copies of the ACK to the server. After you call the SendUdpDatagramUsingSipPort() API procedure, the media engine will transmit its copy of the final ACK when the ModifySipMessage event handler code returns control back to the media engine.
Doing this and running your VOIP system for a while should tell you if you are on the right track. Think of this technique as your own “ACK message retry” fix.
You could also have some other idle thread in your VOIP app perform the retransmits.
Please repost later with results.
Thank you Aj,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 04 2010 at 4:06pm | IP Logged
|
|
|
Hello Aj,
I have been giving this issue additional thought in addition looking at your SIP log files further.
You know what we want – we need to update the media engine to simply resend the final INVITE ACK if it receives additional “200 ok” responses from the server. Handling the issue this way would make the media engine more robust and almost certainly resolve this issue for your group.
Now the question is – how do we get there. :)
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: February 04 2010 at 8:01pm | IP Logged
|
|
|
Thanks Randal,
I will discuss with my supervisors regarding the options you've made available and let you know.
Now, the ACK is one issue, and it looks like your suggestion would solve it, but it would not address the issue with the missing 183 Session message.
I think I need a solution that would address both, or minimize or compensate for packet losses.
Thanks again,
AJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 05 2010 at 2:27pm | IP Logged
|
|
|
Hello AJ,
Does your VOIP app have some kind of dependency on receiving the lost SIP “183 Session Progress” message?
What I mean is: Does your VOIP app actually use the “183 Session Progress” message?
The 1xx series SIP messages as per SIP RFC3261 are not guranteed to be delivered or retried. So if they are lost because of the network (UDP packets), the packet loss is not supposed to create any “hard core” issues for the call’s session setup.
Here is the provisional response text from the RFC:
21.1 Provisional 1xx
Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions.
Please let me know if I am missing something or failing to see your point.
Thank you,
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Missing SIP messages from log files - possible packet loss?
