Mailing List CGatePro@mail.stalker.com Message #106179
From: Technical Support <support@stalker.com>
Subject: Re: PBX
Date: Fri, 9 Sep 2016 10:43:47 +0300
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
Hello,

On 2016-09-05 07:54, Roberto Michelena wrote:
I made a lot of tests - on a separate email will report the results of using browsers as VoIP Pronto clients, which I guess is not a priority for most users of CGPro’s VoIP functionality.

I managed to get audio in the calls by removing the WAN IP from CGPro’s config.
Which shouldn’t be the case and surely will bring some trouble on other fronts.
Details below, please what am I doing wrong?

Now I do have audio between two Cisco phones, between a GoIP device and a Cisco phone, and between an iOS Pronto client and a Cisco phone. The only thing I had to do was remove the “WAN IP” from CGPro’s settings. So, question is then, why did I have to do that?

Because the media packets sent by the server to the clients in WAN are coming either from another IP (your NAT firewall is multihomed) or from ports other than CGPro chose for media (there's no 1:1 port mapping rules on your NAT firewall for the port range specified in CGPro Settings -> Network -> LAN IPs -> Port allocation).

The main purpose for WAN IP setting in CGPro is to hint the server which IP it should specify in SDP payloads sent to clients in WAN.
(Another purpose - to understand that some MX in DNS points back to the server in cases when teh server is behind a firewall).

My network configs are as follows:
- One CGPro server with two ethernet interfaces: one to a switch that manages the data network (email, etc.) and one to a PoE switch that handles the VoIP network (a few Cisco phones, one GoIP GSM Gateway, one Grandstream PSTN gateway)

This is generally not recommended for CGPro. The only network separation it usese is WAN vs LAN - to act as an SBC and a smart media proxy.

- each switch is also connected to each port of a Mikrotik router that NATs the internet

NAT with VoIP is always tricky. When CGPro is behind a NAT firewall, the WAN IP address setting should match the WAN IP of the firewall (the default IP, if NAT is multihomed) and some ports (SIP and mdeia proxy/channel) should be mapped 1:1 to the ports on the CGPro's IP in the internal network. 1:1 here means that everything received on port 5060 from WAN should be delivered to port 5060 on CGPro without a vchange of the source address, and everything send from port 5060 by CGPro should leave the NAT firewall from the same port number 5060 and WAN IP as the source address.

- two network address ranges: 10.10.10.x (data) and 192.168.15.x (VoIP) ; for each network there is a server address and a gateway address.

Note that local networks attached to CGPro are expected to be transparently routable to each other (only one LAN is supported).

- so the CGPro server has one address on each interfase, belonging to each network. It has 10.10.10.5 and 192.168.15.5 ; and each also has it’s associated DNS and Gateway address, which in fact point to the same router which has an address on each port.

In the Network configs of CGPro webadmin, under settings->network->LAN IP both ranges have been included; they’ve also been included in the Client IPs tab although supposedly the “Process LAN IP Addresses as Clients” tab should handle that.

Client IPs list governs only relaying and access. Generally I would recommend to keep it empty as most clients are capable of authentication for relaying and with proper network/software config relaying without authentication can be avoided. Though, maintaing Client IPs ranges may be useful sometimes - just because some settings provide different behavior for clients vs non-clients.

And the WAN IP was filled with the actual public (internet) IP of which the router sends everything to the CGPro server (a DMZ).
And “server LAN IP Address” popup is set to “Disabled"

SO HERE COMES THE WEIRD THING
- as long as there’s a WAN address, CGPro seems to tell the SIP clients to go send their audio packets there; calls connect but no audio.

Because the port ranges CGPro offers for audio must be mapped on the firewall back to CGPro (see above).

- if I remove the WAN address, suddenly it all works

External clients realize that CGPro is behind a NAT and may be applying their NAT-traversal techniques or some SIP ALG on the NAT firewall gets into the picture (and generally that should be off).

- if I change the “server LAN IP Address” popup to the server’s address on the VoIP network, calls don’t even connect.

So why does CGPro, when the WAN IP address is filled, sends the SIP clients on a wild goose chase pointing them to the internet? both ends of the call have registered from local addresses, with account and password… and yes, those addresses are NATed whenever a call comes from/to the internet, but not when calling each other within the local network…

the relevant portion of the logs, where it’s telling the clients to send the audio to the WAN, seems to be here:

20:42:50.248 2 MEDIAPROXY-000014 created for DIALOG-000009
20:42:50.248 2 UDPPROXY-000028 created (port=60000/2) for MEDIAPROXY-000014
20:42:50.248 2 UDPPROXY-000028 processing started
20:42:50.248 2 MEDIAPROXY-000014 audio: UDPPROXY-000028 created
20:42:50.248 2 UDPPROXY-000028 [192.168.15.248]:24156:24157 by SDP <-> [0.0.0.0]:0:0(flex)
20:42:50.248 2 DIALOG-000009 MEDIAPROXY-000014 created (NAT) initial
20:42:50.248 2 UDPPROXY-000028 60000: started(high pty)
20:42:50.248 2 SIPC-000082 request SDP (initial offer) modified
20:42:50.248 2 UDPPROXY-000028 60001: started

* so what was that line above about NAT? and offer modified? and in this next lines below, the WAN address (190.117.85.50) is suddenly involved

20:42:50.248 2 SIPDATA-004380 out: req [190.117.85.50]:5060 -> udp[192.168.15.227]:5060 INVITE(1354 bytes) sip:118@192.168.15.227:5060;user=phone;transport=udp
20:42:50.248 2 SIPC-000082 SIPDATA-004380 INVITE sip:118@192.168.15.227:5060;user=phone;transport=udp sent [190.117.85.50]:5060 -> udp[192.168.15.227]:5060

Because that's what had been specified as WAN address - the server puts it also into the Via headers of SIP requests going out to WAN.

Roberto

(commented log of the whole transaction below)

**USER ACTION: ext 119 (ip 192.168.15.248) dials ext 118 (ip 192.168.15.227)

20:42:50.035 2 SIPDATA-004374 inp: req [0.0.0.0]:5060 <- udp[192.168.15.248]:50493 INVITE(968 bytes) sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.035 2 SIPDATA-004374 created SIPS-004258
20:42:50.035 2 SIPS-004258 SIPDATA-004374 INVITE sip:118@pbx.infinitek.com.pe;user=phone from udp[192.168.15.248]:50493
20:42:50.036 2 SIPDATA-004375 out: rsp [0.0.0.0]:5060 -> udp[192.168.15.248]:5060 100-INVITE(345 bytes)
20:42:50.036 2 SIPS-004258 SIPDATA-004375 100-INVITE(trying) sent [0.0.0.0]:5060 -> udp[192.168.15.248]:5060
20:42:50.036 2 SIPS-004258 SIGNAL-004224 created
20:42:50.036 2 SIGNAL-004224 SIPS-004258: INVITE(101) sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.036 3 SIGNAL-004224 rejecting INVITE from roberto@infinitek.com.pe w/o authentication
20:42:50.036 2 SIGNAL-004224 401 generated
20:42:50.036 2 SIGNAL-004224 401-INVITE reporting
20:42:50.036 2 SIGNAL-004224 releasing
20:42:50.036 2 SIPDATA-004376 out: rsp [0.0.0.0]:5060 -> udp[192.168.15.248]:5060 401-INVITE(494 bytes)
20:42:50.036 2 SIPS-004258 SIPDATA-004376 401-INVITE(final) sent [0.0.0.0]:5060 -> udp[192.168.15.248]:5060
20:42:50.174 2 SIPDATA-004377 inp: req [0.0.0.0]:5060 <- udp[192.168.15.248]:50524 ACK(357 bytes) sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.174 2 SIPDATA-004377 sent to SIPS-004258
20:42:50.174 2 SIPS-004258 SIPDATA-004377 ACK suppl-request
20:42:50.174 2 SIPS-004258 SIPDATA-004377 confirmed: ACK received
20:42:50.243 2 SIPDATA-004378 inp: req [0.0.0.0]:5060 <- udp[192.168.15.248]:50493 INVITE(1238 bytes) sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.243 2 SIPDATA-004378 created SIPS-004260
20:42:50.243 2 SIPS-004260 SIPDATA-004378 INVITE sip:118@pbx.infinitek.com.pe;user=phone from udp[192.168.15.248]:50493
20:42:50.243 2 SIPDATA-004379 out: rsp [0.0.0.0]:5060 -> udp[192.168.15.248]:5060 100-INVITE(345 bytes)
20:42:50.243 2 SIPS-004260 SIPDATA-004379 100-INVITE(trying) sent [0.0.0.0]:5060 -> udp[192.168.15.248]:5060
20:42:50.243 2 SIPS-004260 SIGNAL-004226 created
20:42:50.243 2 SIGNAL-004226 SIPS-004260: INVITE(102) sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.243 2 DIALOG-000009 created for SIGNAL-004226:[192.168.15.248]
20:42:50.243 2 SIGNAL-004226 DIALOG-000009 created
20:42:50.244 2 SIGNAL-004226 INVITE sip:118@pbx.infinitek.com.pe;user=phone via sip:118@pbx.infinitek.com.pe;user=phone
20:42:50.248 2 SIGNAL-004226 leandro@infinitek.com.pe has 1 registration(s)
20:42:50.248 2 SIGNAL-004226 SIPS-004260: {1/1} sent to SIPC-000082: INVITE sip:118@192.168.15.227:5060;user=phone;transport=udp
20:42:50.248 2 SIPC-000082 SIGNAL-004226 INVITE sip:118@192.168.15.227:5060;user=phone;transport=udp
20:42:50.248 2 MEDIAPROXY-000014 created for DIALOG-000009
20:42:50.248 2 UDPPROXY-000028 created (port=60000/2) for MEDIAPROXY-000014
20:42:50.248 2 UDPPROXY-000028 processing started
20:42:50.248 2 MEDIAPROXY-000014 audio: UDPPROXY-000028 created
20:42:50.248 2 UDPPROXY-000028 [192.168.15.248]:24156:24157 by SDP <-> [0.0.0.0]:0:0(flex)
20:42:50.248 2 DIALOG-000009 MEDIAPROXY-000014 created (NAT) initial
20:42:50.248 2 UDPPROXY-000028 60000: started(high pty)
20:42:50.248 2 SIPC-000082 request SDP (initial offer) modified
20:42:50.248 2 UDPPROXY-000028 60001: started

      * so what was that line above about NAT? and offer modified? and in this next line below, the WAN address (190.117.85.50) is suddenly involved

The logs are not detailed enough for SIP{ Transport, but I can imagine that the SIP{ device fro leandro@infinitek.com.pe was registered from WAN> so CGPro applied its NAT-traversal techniques and created a media proxy. The requests going out to WAN  side will need to have the media address modified to that of the WAN side of the media proxy object.

20:42:50.248 2 SIPDATA-004380 out: req [190.117.85.50]:5060 -> udp[192.168.15.227]:5060 INVITE(1354 bytes) sip:118@192.168.15.227:5060;user=phone;transport=udp
20:42:50.248 2 SIPC-000082 SIPDATA-004380 INVITE sip:118@192.168.15.227:5060;user=phone;transport=udp sent [190.117.85.50]:5060 -> udp[192.168.15.227]:5060
20:42:50.412 2 SIPDATA-004381 inp: rsp [0.0.0.0]:5060 <- udp[192.168.15.227]:50062 100-INVITE(621 bytes)
20:42:50.412 2 SIPDATA-004381 sent to SIPC-000082
20:42:50.412 2 SIPC-000082 SIPDATA-004381 100-INVITE received
20:42:50.412 3 SIPC-000082 2 Record-Route field(s) in non-starting response, clearing
20:42:50.544 2 SIPDATA-004382 inp: rsp [0.0.0.0]:5060 <- udp[192.168.15.227]:50062 180-INVITE(660 bytes)
20:42:50.544 2 SIPDATA-004382 sent to SIPC-000082
20:42:50.544 2 SIPC-000082 SIPDATA-004382 180-INVITE received
20:42:50.544 2 DIALOG-000009 provisioned
20:42:50.548 2 SIPDATA-004383 out: rsp [0.0.0.0]:5060 -> udp[192.168.15.248]:5060 180-INVITE(595 bytes)
20:42:50.548 2 SIPS-004260 SIPDATA-004383 180-INVITE(provisioning) sent [0.0.0.0]:5060 -> udp[192.168.15.248]:5060



**USER ACTION: ext 118 picks up - call is supposedly established, but NO AUDIO

No audio because RTP packets from the WAN side can't reach CGPro. (Sent to a wrong address or blocked by CGPro).

[]

--
Best regards,
Dmitry Akindinov

=======================================================================
When answering to letters sent to you by the tech.support staff, make
sure the original message you have received is included into your
reply.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster