Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > SIP Broker Forums > SIP Broker Support

SIP Broker Support Support for the SIP Broker service.

 
 
Reply
Thread Tools Display Modes
Unread 09-13-2007, 01:33 AM   #11
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

Quote:
Originally Posted by 910198 View Post
For the ACK to arrive it is necessary to create some mappings on the firewall. This is simply impossible on public networks.
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.
.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 09-17-2007, 12:12 AM   #12
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default Test results

Hi Martin,

About your guidelines, I did exactly as you recommended:

Code:
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.
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
Code:
I also assure you that before the change occurred in July described at http://forum.voxalot.com/sip-broker-...necessary.html everything worked well.
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é
Attached Files
File Type: txt TShooting-SIP-X-Lite.txt (13.3 KB, 8 views)
File Type: txt TShooting-SIP-SJPhone.txt (15.4 KB, 0 views)
910198 is offline   Reply With Quote
Unread 09-22-2007, 02:59 AM   #13
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default 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.
910198 is offline   Reply With Quote
Unread 09-22-2007, 11:53 PM   #14
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 09-24-2007, 02:24 AM   #15
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default 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é
910198 is offline   Reply With Quote
Unread 09-30-2007, 11:21 PM   #16
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default

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é
910198 is offline   Reply With Quote
Unread 10-14-2007, 12:27 AM   #17
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

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.
.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 10-29-2007, 05:28 PM   #18
telenerd
Junior Member
 
Join Date: Jul 2007
Posts: 23
Thanks: 2
Thanked 1 Times in 1 Posts
telenerd is on a distinguished road
Default

Quote:
Originally Posted by martin View Post
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.

.
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
telenerd is offline   Reply With Quote
Unread 11-02-2007, 01:59 PM   #19
910198
Member
 
Join Date: May 2007
Posts: 34
Thanks: 2
Thanked 1 Times in 1 Posts
910198 is on a distinguished road
Send a message via Yahoo to 910198 Send a message via Skype™ to 910198
Default 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é
910198 is offline   Reply With Quote
Unread 11-02-2007, 06:15 PM   #20
telenerd
Junior Member
 
Join Date: Jul 2007
Posts: 23
Thanks: 2
Thanked 1 Times in 1 Posts
telenerd is on a distinguished road
Default

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????

Last edited by telenerd; 11-02-2007 at 06:30 PM.
telenerd is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can this work this way?! andrerio Voxalot Support 2 08-29-2007 06:29 AM
Help getting SipBroker numer to work latinhawk SIP Broker Support 1 07-22-2007 03:27 AM
Calling Blueface No from Voxalot does not work using Grandstream, works from SJ-phone kurun Voxalot Support 0 12-30-2006 07:53 PM
Sticky Topic :: Voip servers that work amroe Voxalot Support 3 10-20-2006 01:18 PM
Can't get call forward to work??? pmerrill Voxalot Support 2 07-14-2006 03:52 AM


All times are GMT. The time now is 04:46 PM.


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