Re: PBX

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:[email protected]:5060;user=phone;transport=udp
> 20:42:50.248 2 SIPC-000082 SIPDATA-004380 INVITE sip:[email protected]: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:[email protected];user=phone
> 20:42:50.035 2 SIPDATA-004374 created SIPS-004258
> 20:42:50.035 2 SIPS-004258 SIPDATA-004374 INVITE sip:[email protected];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:[email protected];user=phone
> 20:42:50.036 3 SIGNAL-004224 rejecting INVITE from [email protected] 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:[email protected];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:[email protected];user=phone
> 20:42:50.243 2 SIPDATA-004378 created SIPS-004260
> 20:42:50.243 2 SIPS-004260 SIPDATA-004378 INVITE sip:[email protected];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:[email protected];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:[email protected];user=phone via sip:[email protected];user=phone
> 20:42:50.248 2 SIGNAL-004226 [email protected] has 1 registration(s)
> 20:42:50.248 2 SIGNAL-004226 SIPS-004260: {1/1} sent to SIPC-000082: INVITE sip:[email protected]:5060;user=phone;transport=udp
> 20:42:50.248 2 SIPC-000082 SIGNAL-004226 INVITE sip:[email protected]: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 [email protected] 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:[email protected]:5060;user=phone;transport=udp
> 20:42:50.248 2 SIPC-000082 SIPDATA-004380 INVITE sip:[email protected]: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.

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[email protected]>
To switch to the DIGEST mode, E-mail to <[email protected]>
To switch to the INDEX mode, E-mail to <[email protected]>
Send administrative queries to  <[email protected]>