Calls to External Number - Stop hearing anything after so long


#1

Hello-

I am having an issue where we are forwarding a call after no answer to an external number. If I go in and make a change to something or disable / reenable the trunk, the call forwards fine and both callers can hear each other. After a select amount of time (I don’t know what that time is yet) but the calls will continue to forward, but no voice can be heard on either end. It seems if it may be a setting on the watchguard firewall that is closing a port and not reestablishing? I’ve do have ports 11000 through 12000 forwarded to the UCM. I’ve tried various providers thinking that was the issue… all the same thing. I’m just not exactly sure where to look to see why the rtp traffic isn’t being forwarded after so long… Thanks for any help!


#2

Hi you mention watchdog firewall look for a setting that allows you to incorase the udp timeout and change it to comething like 120 or increase it form what ever it is.

Futher you do not need to open ports on the firwall unless youhave remote extensions ( inbound nat)

if all you extensions are on the lan the ucm will sned a registration request to your provider and the ports will open by way of being a new connection and for as long has the regsitration s alive the connection will be established all required ports will remain open.


#3

Telcom -

What you indicate about the provider and open ports is not necessarily true. A registration packet is sent and and expiry time is established. As long as there is no call in between the time of the register and expiry then there is no expectation of communications between the two and the firewall may very well close as nothing is being sent to keep it open.

However, if keep alives are enabled or a heartbeat/qualify is set, and as long as the send frequency is less than the firewall UDP closure, then it will remain open as long as the packets continue to be sent.


#4

Basic firewall rules any new connection sent from internal ( client to server) where the rules of the firewall allows all lan traffic to initiate a new coonection is allowed once that is allowed the connection is then considerd established. So a UCM initiates a new conncetion with ITSP ( sip sever) This is a new connection when the traffice leaves the ucm out the firewall any return traffice will be mapped back to the device that created the New connection ahs per the nat table entry. Hence there is no need to open any ports on the firewall for any new connection from with your lan outwards unless you specifically also block your lan subnet form creating a new connection.

With regard to the expiery this is why there is a refesh of the registration yes if the refresh does not ouccur for example if the regsiration expires prior to a refesh of the of the registraion the ports will close.
This is why I asked him to check the firewall he noted being wacth gaurd for a setting on the udp time out which is closing the udp port beifre the registration refresh.
All our sonic wall firewall have this issue has they are set with the udp timeout of 60 and increasing this to 120 sec solves the oone way audio problem. We also use Sophos firewalls which does not need the udp time out changed.

Opening up ports is not required if you initiate a new conenction from the Lan yes if your rgeistration expires and you do not send a re-rgeister than agreeed the connection will close and if this is the case you will then have to open up ports.

I Also noted for has long has the registration is alive the connection will remain in an established state and thus no need to open ports. Basicly you said the same thing I did but with the view that the sip registration will expire where as I said that for has long has the connection is established there is no need to open ports.


#5

Sorry, but here is where I take issue - “the ucm will sned a registration request to your provider and the ports will open by way of being a new connection and for as long has the regsitration s alive the connection will be established all required ports will remain open.”

The registration period being alive is dependent upon the expiry. As long as it is “alive” then there is no need for any traffic as neither side expects to hear from the other as both sides consider the other to be alive and able to accommodate calls. The router has no understanding of “for as long as the…”, it only knows that packets are egressing thru the port at which point it will maintain it open using NAT/PAT tables in conjunction with the UDP idle timeout or if the idle timeout is reached, it will close.

  1. We do not know that a registration port is in play. It could be peer. The post made no mention of which is used. It does sound like a register trunk given the reboot, but it is not explicitly stated.

  2. If register, the expiry could be 3600 seconds. Both sides think the other is aware and ready. After some period of time the ports on the client firewall close, but do so before the registration expires. A call comes into the provider who then attempts to send to the client, but the client firewall not having passed any traffic outbound to open the port, will not allow the incoming packets to pass to the UCM on the other side. The registration has not expired and is therefore considered alive.

  3. There is no difference from a firewall perspective between open ports for remote phones or a provider. The only difference is that the role of UA is reversed, thereby making the UCM the server rather than the client for the phone. Granted the phone will generate the register request, but the point is that in order for a provider or a phone to reach the UCM, the ports must be open and available for the UCM to see the messaging. The register attempts from the UCM may force the ports open for a bit, but it has nothing to do with the registration per se, but the sending of a packet be it a registration, keep alive packet of heartbeat/qualify prior to the expiry of the UDP port idle time so that it stays open in the event unsolicited but valid messaging is sent from whatever the remote is using.

So, I think we are saying mostly the same thing, but what I am trying to get across is that a register has a lifetime based upon an expiry of which the router is not aware. As long as the registration period has not expired, it is considered live. Its a wording thing mostly, but a number of folks without knowing all the nuances will take a statement and then assume that a best practice is to not open the ports and then wonder why calls stopped flowing later on.

In any event, the original post is somewhat different I think. There is never the issue that the call does not get thru on the SIP side, regardless of timing. It is that the audio fails to flow, but only after some time.

So, how is the remote side set with its firewall? Forwarded ports, SIP ALGS off, static private IP on the phone, using random ports, NAT IP Address used? It takes 2 to tango.