Remote Extension - Feature Request to improve deployment & reduce support calls


#1

Hello All:

With the help of GS Tech Talks videos and GS Support finally got my remote extension to work.

  1. On both local & remote firewall turned off SIG ALG
    -(office) Cisco ASA: no inspect sip
    -(remote) Bell Hub 3000: unchecked SIP ALG
  2. On local firewall (office)
    -port forwarded Public IP/Port to UCM
    -did NOT open any RTP ports
  3. On UCM:
    -PBX Settings > SIP Settings >
    –NAT tab: Entered external IP/Port, checked Use IP address in SDP & entered local subnet.
    –ToS tab: Entered 1 in RTP Keep-Alive (to create pin-hole for RTP.)
    -Extension/Trunk > Extensions (Edit remote extension)
    –Media tab: Checked NAT. Removed all codecs except PCMU & PCMA. Found that too many codecs caused fragmentation on remote side which caused UCM to discard packets!
  4. On Remote phone:
    -Pointed to Public IP/Port to UCM
    -SIP, Auth, password
    -NAT Traversal: STUN
    -STUN Server: stun.l.google.com:19302
    -Changed to static IP to override DNS to 8.8.8.8. Wanted to avoid the DNS (192.168.2.1) from DHCP which relayed DNS requests to WAN. Basically to avoid router playing with packet.

HERE’s my FEATURE REQUEST: Need a fixup for RTP without relying on STUN. GS UCM only does fixup for SIP. Why not RTP? FreeSwitch already has a solution:
https://freeswitch.org/confluence/display/FREESWITCH/NDLB#NDLB-NDLB-connectile-dysfunction
Hosted IP PBX solutions don’t require all these tweaks on the remote side.
Please consider adding this feature to reduce partner support calls from customers.
Thank you


#2

That does not appear to address RTP, as the definition provided in the link is -
" NDLB-connectile-dysfunction

Rewrites contact IP and port
Enables ‘NATHACK’"

The “contact” header addresses SIP only. For RTP it is the “connection” header. This is why the setting “NAT tab: Entered external IP/Port, checked Use IP address in SDP” is there along with the local subnet so that when the UCM sees a local IP making a request the UCM responds with a connection and contact header indicating its local IP. If it sees the request from a non-local IP, it will respond with its public IP in both the connection and contact header.

Digging a little deeper, you will see that -
"### NDLB-connectile-dysfunction

  • Rewrites contact IP and port to that of the NAT device by looking at IP address:port info from the packets reaching FreeSWITCH.
  • Forces REGISTER expiry to 30 seconds. (Unless sip-force-expires is set)

This is similar to the way Asterisk tries to deal with NAT traversal."

Basically, all the tools are already there to handle the NAT in the UCM to include RTP which the Freeswith tool does not.

Next, the FS tool does not address how the device is to know its public IP. The tool basically says ignore the connection and contact header info IN THE SIP message and instead respond to the source IP and ports as seen at the UCM NIC interface. The UCM must still respond and it will need to tell the remote device what IP and port to use and if the device is non-local it must indicate the public IP. For those that do not have a static IP nor a DDNS FQDN, then STUN is the method used. The same is true as to why GS had you put STUN in the phones. Its a 2 way street as both the PBX and remote device must know and advise as to how the other end is to communicate reliably back.

In the settings on the phone, they should have also had you enable SIP options with a frequency of 30 seconds. As I suspect that you are not port forwarding at the remote end, this will cause a pinhole so that any calls coming into the phone will still be received. I do not know what the register period is, but 30 seconds is too small a period in my opinion; hence why the options request in the SIP settings.

Finally, no the 1 setting in the TOS RTP-Keep alive is not to create a pinhole. This setting is only active during an active SDP session. It is meant to send a packet in order to avoid an RTP timeout.
This is typically used when a call has been placed on hold. The remote side is sending music or whatever, but the other end is usually quite so nothing is being sent. If there are no RTP packets sent, then the other side may have a RTP timeout enabled (the UCM also has one) that will assume that the other end has gone off-line and kill the call when the timer fires. BTW the 1 setting is far too short and is sending extraneous traffic for no good reason. 20 -30 seconds is typically a reasonable period.

There is no point in sending a packet on a RTP port for a pinhole. As the UCM is set with a default RTP range of 10000-20000 and it does not know which port the next call will use until such time as the call is being established, it would have to send a packet out each of the 10001 ports. When the SDP in an INVITE or 200OK is seen, it will then know the ports to use and will bind to same at that time, not before. You can hover your cursor over the setting description to get more detail of what the setting does (in some cases). You will see that it is only active during a session which is only established during a call.


#3

Thanks for detailed response.

My goal is to reduce, as much as possible, the dependencies on the remote extension end. And I can tell you hosted IP PBX solutions do not require any NAT config for STUN, etc. to make audio work.

For UCM remote extensions to work, we rely on SIP AND RTP fixups to replace remote local IP in the SIP & SDP packets (Connection Information for RTP) with the remote public IP from the L3 Header.

That’s what the NAT setting in Extension is supposed to do. For SIP, it works. But NOT for RTP. The UCM does NOT replace the remote local IP in SDP packet. The outcome is that audio gets sent to local IP which will not work. So STUN is absolutely required to be configured at the remote extension end to ensure the SDP packet contains the remote public IP before sending to UCM.

As for the RTP config, not to open RTP ports 10000-20000 and set the RTP keep-alive to 1, I got that idea from GS Tech Talk #1 (39 min mark https://youtu.be/sGdVZdvbqdY?t=2340) where Abdel Jaibar from GS Tech Support explains & demos this alternative.


#4

You are correct in that hosted PBX systems do not typically require STUN. I have quite a few hosted systems in play. They almost always sit behind NAT and have been programmed or made aware of what their public IP is, so STUN is not needed on their end. It is the phone sitting behind NAT that have dynamic public IPs that need STUN and was apparently the same in your case when GS had you put a Google STUN server in the phone. Had you had a fixed public IP, then instead of STUN, you would have inserted your public IP in the NAT IP field setting in the phone. As the phone is both the SIP and media (RTP) server for the remote device, when STUN determines the public IP , the phone will use same in both the contact and connection header.

I have no idea where you may have gotten the impression that I somehow suggested the UCM influences the messaging of the remote device - “The UCM does NOT replace the remote local IP in SDP packet.”. I never suggested or hinted in any way that the UCM has anything to do with the messaging of the remote device. I clearly stated that it takes 2 to tango and that each side must be programmed to that the other knows how to respond back. and each side must tell the other what it expects so that they can communicate reliably.

So, your statement of - “So STUN is absolutely required to be configured at the remote extension end to ensure the SDP packet contains the remote public IP before sending to UCM” was never in doubt or questioned by me. I agree that if the remote does not have a static public IP, then STUN is indeed needed and was exactly as I stated earlier "For those that do not have a static IP nor a DDNS FQDN, then STUN is the method used. The same is true as to why GS had you put STUN in the phones. Its a 2 way street as both the PBX and remote device must know and advise as to how the other end is to communicate reliably back.".

As far as 1 second keep-alive, it matters not to me if you wish to use. I only pointed out that it only comes into play when a call is active and that to me the frequency with which the keep-alive packet is sent is too frequent. Most commercial level firewalls allow some form of adjusting the port closure timeout for TCP and/or UDP traffic. Most will keep the hole open for 30 seconds whereas others for as long as 300 seconds. I chose to forward the ports as the ports represent no threat being open as they are not subject nor will they respond to any attack. They only become active when in a call and the port is bound to the RTP stream. I have numerous PBX makes around the country whose sites must also maintain PCI compliance and they all pass despite the open ports as again, they won’t respond to a port scan or other when idle. I also set the usable port range for the UCM to its minimal amount of 250 ports which is more than enough for perhaps all but the 6510.

As with most things, there is more than one way to accomplish the end goal. Me, I try and use the most reliable and simple method. I have clients that have large numbers of remote phones of various makes since covid has emerged. I have no issue with any of them other than the occasional consumer level firewall that does not like to play nice. As always, there are exceptions as to how some employ SIP, but if it works and works well, then use it.


#5

Thanks again for reply. The following points were particularly helpful.

  1. You’re right in that FS docs only mention fixup for SIP contact header. Looks like something else at the ITSP make the fixups for the RTP in the SDP message, maybe a SIP proxy or SBC.
  2. Using NAT IP setting in endpoint (when remote has public static IP hence no STUN required).
  3. TOS Keep-Alive vs opening ports. Caveat about too frequent keep-alive is a good point. Also using a narrower range like 250 ports make sense.

Q. For most cases with dynamic IP, do you agree that SDP (RTP) fixup for remote extension would be a nice to have in the UCM instead configuring STUN on remote end points?

Q. Those configs of remote extensions are a lot of work. Do you leverage GDMS for provisioning?