Still does not work...
 

Dear SipBroker Support Team

I am user of SipBroker/VoXalot for almost 1 year. Since the beginning I regarded the service amazing and everything worked smoothly for incoming as well as outgoing calls.

Do not know why, since the last week of July, the incoming calls from PSTN were dropped after something like 30 seconds. Nothing were done on my network. No changes, absolutely nothing and the incoming calls from PSTN simply stoped to work. :confused:

I made a trace and I discovered an interesting clue. The call setup (Invite, 100 Trying, 180 Ringing and 200 OK) was negotiated all the time with the server 64.34.163.35, but, the ACK came from other server, 64.34.162.221. The firewall waited for the ACK from the server 64.34.163.35, but it came from 64.34.162.221 and then it was blocked. The type of NAT is "Restricted Cone NAT".

I even made a workaround applying a static port forwarding on the router, but this "solution" was not good because the lack of mobility. It is not possible to make a static port forwarding on every network that I use. Most of the home networks use modem/routers with "Restricted Cone NAT". I have friends (users of SipBroker) with the same problem.

I kindly beg to someone at SipBroker to analyze this case and give me an answer about what is wrong. I completely willing to provide more information as necessary.

Thanks in advance. Best regards,

André Silveira

Hi, André Silveira
Are you an vox premium user? What is "Invite, 100 Trying, 180 Ringing and 200 OK"

Are you using an ATA?

Which access number are you using. The contact IP address is:

200.152.246.50

Which is not one of ours!

The user agent is also:

EasyPABX

Again not ours!
.

A couple of other things to note:

1. The ACK message originates from an end point and *not* the proxy. In this case the end point is SIP Broker. The following diagram is from the SIP RFC and should help you visualise:

The ACK is sent to the CONTACT defined by the other user agent. In your case, SJ Phone. If you have a look at the 200 OK message just before the ACK you will see that your SJ Phone is sending:

I'm guessing you are behind a firewall. If so, then I suspect your problem is with SJ Phone STUN handling. There are a few other posts in the forum with people having similar ACK problems using SJ Phone.
.

More information
 

Dear Martin,

Thank you for your answer. I would like to make some comments in order to gather more information to solve this problem:

1- As you requested, the access numbers that I have tried are +55-11-3511-5700, +55-21-3521-2840 (VoIP Sharing in Brazil) and +34-91-771-1720 (Adam Telefonia IP in Spain).

2- I do not believe in a problem with SJPhone, because the problem is exactly the same with SJPhone, X-Lite and with my ATA.

3- I use the STUN server of VoXalot (stun.voxalot.com). I do not believe in a problem with STUN because the audio stream is established normally for some seconds (30 seconds), but is torn down because the ACK timeout.

4- Yes, there is a Stateful Inspection Firewall on the router, but I do not believe in a problem on the firewall, because the phone rings normally. It means that the firewall permits the SIP messages to be passed from Internet to the UA on the internal network. As I stated before, the problem seems to be on the fact that the firewall waits the ACK from the same IP address of the other messages, but it comes from a different IP address. As I said previously, everything always worked fine, and, without any change, the incoming calls from PSTN stopped to work.

5- I agree with you about what the RFC 3261 says, but if you briefly take a look on the file that I have sent, you will see the diagram below. This is scenario of the problem. Pay special attention on the ACK message.

This is what I suppose happened before the problem, when everything worked properly.

I thank you again for your attention and ask you to help me to solve this problem. If you need more information, please let me know.

Sincerely,

André Silveira

Hello André,

Exactly.

If you take a closer look:

200.152.246.50 (the PSTN provider) is sending the ACK to sipbroker.com instead of sending it directly to 201.13.48.4 (see my diagram)

sipbroker.com is forced to be part of the route by the PSTN provider. This part of the problem needs to be addressed by the PSTN provider.

The reason sipbroker.com bypasses voxalot.com is because we fixed a loose route problem back in July http://forum.voxalot.com/sip-broker-...html#post10989 where SIP Broker was placing itself in the dialog when it should not have been.

Either way, the solution is to allow ACKs from all of the end points you want to communicate with. Take another look at the RFC diagram I posted and you will see that ACKs come to you *directly* from the end point and not via proxies.

Once again the only reason that sipbroker.com is getting the ACK is because the PSTN provider is sending it there.

Hope this makes sense.
.

Please reconsider
 

Hi Martin,

Thank you again. Now at least I know that actually something changed on SipBroker/VoXalot configuration in July. Now there is a consistent explanation to the problem.

But the point is that the problem still exists for me and for all people that have the same scenario: home networks. This way you became VoXalot a service only for specialists that know how to configure a firewall. I guess you want to make the things easier so that any kind of user can subscribe and use the service smoothly.

What about when am I in a airport or hotel? Should I spoke to the Airport/Hotel Network Administrator: "Could you please create a static port forwarding to my IP address on your firewall so that I can receive incoming calls to my VoXalot number"?

What about the mobility?

What about when are there more than one endpoint on a private network? Most of the firewalls of these small routers does not support more than one static port forwarding to the same port (5060), but to different IP addresses.

I understood that you have made a change according to the RFC: nothing wrong. Nevertheless I believe that you fixed a small problem, but a bigger problem was created. The consequence is that many users like me now have problems on incoming calls from PSTN.

I humblely beg you to reconsider this decision. Sometimes I thought about to upgrade my account to premium, but with this problem is not worth.

Sincerely,

André Silveira

More tests
 

Hello Martin,

Just to add more information in order to help to solve this problem, I made more tests during a business travel I had. I made tests on the airport network, on the hotel network and on the customer network. In all of them, the result was the same: incoming calls from PSTN did not work.

The main point is that if there were more Sip Broker users in these places, none of them could receive incoming calls from PSTN.

I kindly ask tou to analyze this issue once more, please, so that we can have this service (incoming calls from PSTN) running back again.

Thank you!

André

Hello André,

I assure you the PSTN access numbers are working for the vast majority of end points that are SIP compliant. As such, there is nothing for us to "fix".

As I mentioned in my post:

It should be noted that the logs show these numbers are successfully used 1000's of times per day. In fact we use them for conference calls with clients and never have problems.

You need to fix your end point to accept the ACKs
.

Hello Martin,

Thank you for your response.

Concerning what you said

unfortunately I can not agree with you. The reason is in everything we wrote on this thread until now. The endpoint (SIP Phone) would accept the ACKs if them arrived on it. But they do not arrive because of what is described some messages above. It does not depend on the end point configuration to work. For the ACK to arrive it is necessary to create some mappings on the firewall. This is simply impossible on public networks. If the ACK came from the same IP address of the INVITE, the ACK would arrive, because the mapping would be created dynamically by the stateful inspection firewall.

I also assure you that before the change occurred in July described at http://forum.voxalot.com/sip-broker-...necessary.html everything worked well.

I guess my point would be clear enough if you made a test on a public network, like airport or some hotel, where you do not have any administrator autonomy to change configuration.

Thank you once more. Regards,

André

This is not true. In your case you are expecting the ACK to come back on port 5060 because your device is instructing the other end point to do so via the CONTACT information it is passing in the OK message. This is why you are forced to modify the firewall rules.

Normally when a device is sitting behind a firewall, and using something like STUN, the CONTACT header will contain a front facing port (that the firewall knows to forward to the internal IP) as determined by the STUN protocol. Depending on whether you are sitting behind a full cone NAT, restricted cone NAT, port restricted cone NAT or symmetric NAT router this port can vary (something like 53451 for example).

If you choose not to use STUN or open up your firewall, the other option is to register your device with a server (like Voxalot) that has server based NAT handling. In this case the proxy will do the NAT handling on your behalf and the SIP messaging will be proxied.

As a simple test, turn off NAT handling (this is extremely important) on your device and register it with Voxalot. Using one of the access numbers, dial *010xxxxxx where xxxxxx is your Voxalot number.

In this scenario, you will see the ACK message come from the Voxalot proxy you are registered against. Once again, this is due to the fact that Voxalot is performing the NAT handling on your behalf

So just to re-iterate, if you want to properly receive the ACK message from the other end point, and you are behind a firewall, you must either:

1. Use a protocol like STUN to perform client side NAT handling (Note: STUN is broken in SJPhone and needs to be disabled. Make sure the "Use discovered addresses in SIP" is unchecked. I suspect this is half your problem)
2. Open up your firewall ports and forward to your device
3. Register your device with a proxy that has built-in NAT handling capabilities.
.

Test results
 

Hi Martin,

About your guidelines, I did exactly as you recommended:

1- For the first option, I tested with X-Lite client with STUN enabled. The result was the same: no success. Incoming call from PSTN was dropped after something like 30 seconds. I captured the messages on the outside interface of the firewall (directly connected on Internet). As you can see on the file, there is no ACK message to the endpoint (X-Lite), though several 200 OK messages were sent.

2- The second option denies me the benefit of mobility, because I can not configure every firewall of every network that I use.

3- For the third option, as you asked I unchecked the "Use discovered addresses in SIP" option on SJ Phone and, consequently, it was used the NAT handling of VoXalot. The result was also the same: no success. I again captured the messages on the firewall outside interface (directly connected on Internet). As you can see on the file, address used at Contact field of 200 OK message is a private address (192.168.0.100), because it relies on the NAT handling of VoXalot. In this test the ACK message arrived on the outside interface, but did not reach the endpoint on the private network. The reason, as I have said previously, seems to be because the IP address of the ACK message was different of that of INVITE message.

Just to remind
Thank you for your interest in help me. I am willing to make as many tests as necessary to identify the why of this issue.

Regards,

André

Still need help
 

Hi Martin,

Any idea about what else should I do to check this issue?

The tests I have already done:

1- On home network, hotel, airport, work and other networks
2- With X-Lite, SJ Phone, Talk Express and ATA endpoints
3- With and without STUN; with and without NAT handling of VoXalot

All tests have failed.

All discussion aside, the point is: incoming calls from PSTN are still dropped after something like 30 seconds. I still need your help.

Thanks a lot,

André

PS: I read the following page about Nat Types.
Network address translation - Wikipedia, the free encyclopedia
According to the definitions, except for Full Cone NAT, for all other cases a message from an external host can only go inside the network if an internal host had previously sent a message to the external host first. It matches with what I think is happening, because since July the ACK message comes from a different IP address of the INVITE message, forcing the stateful firewall drop the ACK message.

Hello André,

The TShooting logs you have attached look like they are calls originating from the Brazilian numbers.

As these numbers are hosted by voipsharing I can pass the diagnostics onto them for comment.

If you are able to provide similar logs for both X-Lite and SJPhone calls originating from any of the U.S. access numbers, I will be able in a better position to comment as these numbers are hosted on our infrastructure.

Thanks.
.

Not only VoIP Sharing
 

Hi Martin,

I do not have a trace of a call from a PSTN access number in USA, but I can assure you that this issue happened not only in Brazil (VoIP Sharing), but also on a PSTN access number in Madrid, Spain (Adam Telefonia IP).

I must confess you that I do not understand which difference makes if the PSTN access number is either A or B. In my point of view this issue is related with an incompatibility of the type of NAT (Restricted, Port Restricted, Symmetric) and the implementation of the Loose Routing feature that causes the ACK message be delivered directly from that UA-Server to the UA-Client. Consequently, the source IP address of the ACK message is different (then unknown by the firewall) of the source IP address of the INVITE message that initiated the call setup. This is exactly what is happening since July. Do you agree with me?

As I said in another message, I guess you could clearly understand this issue if you made a test on a public network (typically in airport or hotel) with NAT type Restricted, Port Restricted or Symmetric.

Thank you once more.

André

Hi Martin,

The problem still exists. Any idea how to solve it? Every time I use a new network I make a test to check if there is something different. In all cases, when the NAT type is Restricted, Port Restricted or Symmetric, incoming calls from PSTN do not work.

I ask you to analyse this issue so that some decision may be taken for the benefit of all VoXalot users.

Thanks,

André

It appears that the ACK problem still existed on 1.2.1 of asterisk.

We were able to re-produce your problem and have since upgraded the PSTN gateway servers version of asterisk which seems to have resolved this issue.

We would appreciate it if you could confirm this also?

Thanks for your patience.
.

Hi Martin
What version of asterisk is being used now.
I think I may have a new variation on the missing ACK problem. I may start another thread when I know the version but I will try to research it first.
Thanks

Suggestion
 

Hi Martin,

I would like to give you a suggestion to help handle this issue:

- Voxalot could offer an option to the user choose if she/he wants Loose Routing or Strict Routing. It would be done the same way as the "Symmetric NAT Handling" and "Optimize Path" option. The default answer for this option would be Loose Routing. If the answer was Strict Routing, the user would register at a specific Proxy Server with Strict Routing support. This way it would be solved the problem of users like me, who needs strict routing for incoming calls do not be dropped.

Regards,

André

Are you misinterpreting the meaning of strict and loose in this context. A proxy will add a Record-Route into a message if it wants to remain in the path for any subsequent requests within the dialogue. Whether or not the proxy declares itself to be a loose router should not affect this path.

In the trace you provided, one of the proxies that inserted a RR into the INVITE was not visited when the ACK was sent. The preceding proxy misrouted it. If it had been visited it would have removed itself from the route set but it was still there when the message arrived at your firewall.

Edit: The offending proxy was not in the RR list so why did the ACK traverse it. Perhaps the far end UA was configured to use it as its outgoing proxy. Anyway it screwed up.

Strict or loose routing all about how a proxy interprets the route set and the request URI but the end result should be the same.

See RFC 3261
16.12.1.2 Traversing a Strict-Routing Proxy

This forum software does not seem to let me reproduce it here. It says I have too many images????

Anyway...
 

Hi Telenerd,

Thank you. Your explanation is likely right.

Anyway, the point that I am totally sure is:

Regards,

André

Hello,

FYI we have added the record-route line back for now. We will closely monitor this change before deciding if it remains permanently.

It worked!!!
 

Hi Martin,

Just to tell you that everything is working now.

Thank you!

André