SIP Lines - Use Network Topology Info Question 1

[Cat5Jive]

Hi all !

Having some weird issues with SIP lately and am wondering if anyone can shed any light.

Typically when we configure SIP we tell the IP Office to use LAN2 (or LAN1) under the Network Topology drop down in the SIP line. I realize this utilizes the specified LAN interface and also uses STUN. Sometimes for whatever reason this breaks, and I have found that if we let the system use the defined IP route to the gateway by setting Topology to NONE, SIP calls will break and disconnect after 15 minutes. This has occurred with a few different SIP vendors. Can anyone shed any light on the recommended option for Topology? When we configure SIP trunking we port forward 5060 and the RTP ports as well as the STUN port on the router to the IP Office. Let me know your thoughts!

Thanks,

C5J

 

[amriddle01]

Registered trunks don't need STUN and as long as you set them to reregister every couple of mins the firewall stays open. IP authenticated trunks typically need STUN or SIP ALG correctly configured as they require the external IP in the SIP headers.

There are exceptions, there is no one size fits all solution

 

[Cat5Jive]

Hrrrm thanks amriddlr01! That is interesting.

 

[Cat5Jive]

Further to this, I discovered our issue this evening is a dead STUN server. I don't like to use the NONE topology in the SIP line as it tends to kill calls after 15 minutes as previously mentioned. All our SIP implementations have been via LAN1/LAN2 topology with port forwarding for RTP and SIP and utilizing STUN and it has worked like a charm. Because the STUN server was no longer responding to requests, the IP Office was exhibiting strange SIP behavior leading to dead calls, registration issues and patience timeout errors. The STUN server was the only other common denominator other than the SIP provider. Now spending a late night logging into all the remote IPOs out there and changing over to the new STUN server. Hopefully this helps out someone else one day!

Thanks for looking,

C5J

 

[janni78]

The reason why the NONE topology doesn't work is that in those cases you're sending your internal IP in the SIP headers.
To set the external IP in the SIP headers you use LAN1/2 topology.

STUN is used to discover your external IP/port and NAT type, if you're port forwarding 5060 and RTP to IPO there is no need for STUN as you already know this.

"Trying is the first step to failure..." - Homer

 

[amriddle01]

Even with port forwarding you often need STUN, again for the outgoing headers, port forwarding doesn't effect them.
Also registered trunk don't tend to need any port forwarding, making them easier to secure for the customer...they don't need to do anything

 

[janni78]

STUN is only used to populate the fields so if you enter the Public IP manually you've done STUNs work.
Your headers would still need to be correct on a registered trunk, unless they go only on the IP that registers.
Your RTP IP could differ from the Signaling although that isn't the case for IPO.

You could also skip port forwarding in an IP authenticated trunk by using Binding Refresh with OPTIONS.
As long as something goes out before the FW drops the port your good to go.

"Trying is the first step to failure..." - Homer

 

[Westi]

It also depends on the firewall you are using.
SIP aware firewalls are the way to go. Throw out any 10 year old firewall.
Like mentioned here before different providers may require different settings, there is no 1 size (or programming) fits all

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[Pepp77]

Two things to take into consideration

STUN and Network Topology are actually two different things in one tab.

STUN interrogates the firewall to find out the public IP address and firewall type if unknown to allow the network topology part of the tab to amend the SIP packets accordingly.
Network Topology is used to amend the SIP packets.

For most systems I do not use STUN but do use Network topology, but blanking out the STUN box, setting the firewall type to either unknown or static port block (varies between firewall brands) and entering the public IP address set up to NAT the SIP - As an example if you have a Sonicwall you can ignore network topology and turn on SIP transformations to get the same end result.

| ACSS SME |

 

[amriddle01]

The above method is what I have used. 9.1 breaks it though...at least that's what I've found

 

[critchey]

About the only time you should really need STUN is if you don't have any access to the firewall and the person in charge of the firewall wont/cant give you the information you need. Static Port Block tends to work often but as stated is not a end all solution.

The truth is just an excuse for lack of imagination.