Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Subject Topic: Missing SIP messages from log files - possible packet loss? Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: January 28 2010 at 4:44pm | IP Logged Quote ajdiaz

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 View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: January 28 2010 at 5:34pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: January 29 2010 at 4:24pm | IP Logged Quote ajdiaz

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 View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: January 29 2010 at 6:51pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: February 03 2010 at 11:50am | IP Logged Quote ajdiaz

Hi Randal,

Any insight on this?

Thanks in advance.

-AJ
Back to Top View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: February 03 2010 at 12:12pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: February 03 2010 at 1:39pm | IP Logged Quote ajdiaz

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 View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: February 03 2010 at 2:31pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: February 04 2010 at 4:06pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: February 04 2010 at 8:01pm | IP Logged Quote ajdiaz

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 View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: February 05 2010 at 2:27pm | IP Logged Quote support

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 View support's Profile Search for other posts by support Visit support's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum






Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights