Voxalot / SIP Broker Support Forums

Voxalot / SIP Broker Support Forums (http://forum.sipbroker.com/index.php)
-   SIP Broker Support (http://forum.sipbroker.com/forumdisplay.php?f=9)
-   -   Sipbroker pSTN gateway misroutes ACK (http://forum.sipbroker.com/showthread.php?t=1994)

telenerd 07-30-2007 11:01 PM

Sipbroker pSTN gateway misroutes ACK
When using a sipbroker access number or webcall to my voxalot account the call is not established correctly resulting in no voice. In my set
up I use an outgoing proxy because my phones are behind a NAT and also I use multiple phones with the same username.

I did a message trace. The incoming INVITE had two RECORD-ROUTE with lr on, including the one from my proxy. The phone that answered sent ou
t the 200 OK with the same RECORD-ROUTE as well as its CONTACT. The far end now sent ACK. This is where the problem lies. The REQUEST URI of
the ACK was for the AOR/proxy not the CONTACT. This is in violation of RFC3261.

The PSTN gateway is an Asterisk. A search revealed that his problem had been reported to Digium ( developers of Asterisk ) quite some time a
go and had been supposedly fixed. The messages from this Asterisk did not reveal its version. This long ago trouble report describes the pro
blem thoroughly and provides references to the pertinent sections of the RFC. Here is a link to that trouble report -
bugs.digium.com/view.php?id=2687]0002687: ACK sent to wrong address - Digium Issue Tracker[/url]

I would like the moderator to pass this report to those that that can correct the problem.
Thank you

martin 07-31-2007 01:25 AM

When you say you are using the PSTN gateway which number(s) specifically are you referring to?

Some of you numbers are hosted by the sponsors themselves while others are hosted on our PSTN gateway server which is running Asterisk 1.2.1

You also mention webcall which is completely different and I would like to better understand this issue.

telenerd 07-31-2007 01:46 AM

I suppose I should have said virtual toll free. The PSTN access number I am using is 604-628-4266 which is in the Vancouver area of British Columbia. Incidentally the BYE message suffers the same fate as the ACK if the release is initiated from the PSTN end. The UA never receives it.

martin 07-31-2007 05:06 AM


Originally Posted by telenerd (Post 11072)
I am using is 604-628-4266

This is a LES.NET number that is hosted on one of our servers. As I mentioned, our PSTN access numbers are hosted on an Asterisk 1.2.1 installation.

Looking at the links you provided unless i'm mistaken the bug you mention should have been fixed in this version.

Am I correct in understanding that the ACK and BYE are hitting your proxy rather than contact host?

telenerd 07-31-2007 05:44 PM

You are correct. If I understand the RFC correctly when strict routing is in effect the contact URI would be the last URI in the route set and if loose routing is in effect the contact URI would be in the request line. In this instance the contact URI is missing entirely.

If I did this correctly there should be an attachment with this reply showing the message sequence as seen at the outgoing proxy.

telenerd 07-31-2007 05:52 PM

1 Attachment(s)
Let's try it with a file name extension of txt

telenerd 08-01-2007 06:51 PM

1 Attachment(s)
It appears that solving this problem involves more than simply upgrading an Asterisk box. To aid in trouble shooting I am adding some details which I omitted earlier.

After the initial exchange of INVITE and 200 OK the PSTN gateway sends an ACK that the UA does not receive. The UA re-sends the 200 OK repeatedly and the gateway re-sends the ACK repeatedly. This continues for seven seconds. During this interval there is two way audio.

Weird part 1
A proper ACK with the contact in the request line finally arrives and is delivered to the UA. The UA is now happy and stops sending 200 OK.

Weird part 2
Although the UA is happy, the listener is not. At the same moment that the gateway sent a proper ACK, it also turned off its audio.

For completeness I am attaching an example of the proper ACK as seen entering and leaving the proxy.

910198 08-21-2007 04:55 PM

Same problem!
1 Attachment(s)
I have the same problem, Telenerd. The incoming calls from PSTN to my VoXalot number are dropped after 30 seconds, because of the lack of ACK message. I have tried to call to different VoXalot numbers, from different PSTN access numbers and the problem was the same. Attached is a file with the sequence of messages INVITE/SD, 100 Trying, 180 Ringing, 200 OK/SD 11 times and BYE. It is worthy to say that everything worked fine unitil the last month. I would like to ask the moderator to pass this problem to those can help to fix it.

Thank you.

910198 08-24-2007 01:59 AM

More details
1 Attachment(s)
I tried to put my PC directly connected on Internet and I discovered an interesting clue. Tha call setup (Invite, 100 Trying, 180 Ringing and 200 OK) was negotiated all the time with the server, but, surprisingly, the ACK came from other server, Thatīs why the SIP Phone on the private network does not receive the ACK. The firewall waited for the ACK from the server, but it came from and then it was blocked. Attached is a file with the details about what I said above. I kindly ask someone at SIP Broker to check this situation and give me an answer about what I should do, please. It is worth remind that everything worked VERY FINE some weeks ago.

910198 08-26-2007 11:31 PM

Now it is possible to receive calls from PSTN normally. The ACK problem was solved, but to do this I had to apply a workaround. The solution was to create a inbound port forwarding to UDP and TCP port 5060 to one IP address on the routerīs firewall.
I consider this not a solution, but a workaround because I now there is a static mapping to a specific IP address. Some weeks ago everything worked smoothly without this configuration and was possible to answer calls on any IP address/machine on the network, as soon it was registered to voxalot.

I would like to know if this procedure is normal and really necessary or it is possible to have a dynamic condition as was before. :confused:


All times are GMT. The time now is 09:50 AM.

Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.