Gamma Setup

[benratty]

Can anyone confirm how to setup Gamma Telecom in 3cx V14? I need to check.
Anyone know what happened to this link or any instructions for setting up Gamma on v14 so I can check
http: //www.3cx.com/blog/voip-howto/gamma-voip-provider-trunk/ -NO LONGER AVAILABLE

Cannot find any setup instructions at all for Gamma on 3cx and above link is dead now

 

[NickD_3CX]

In V14 Gamma is a supported provider, so all you need to do is add the Gamma Trunk using the Wizard in the Management Console, so all you should need to know is this:
http://www.3cx.com/docs/adding-voip-provider-sip-trunks/

 

[benratty]

Yes I have used the wizard. We have two v12 3CX systems, no real issues with them and they are pretty stable. We have a version 14 system which is causing no end of problems, the slightest disruption to its internet connection and it we starting getting No RTP Packets received from Gamma and then they tell us we are not sending the external IP address.

The system is exposed on the firewall, the IP address is set in SIP VIA Header and correct everywhere else I can see yet the slightest change for no reason at all like today there was brief interruption to internet connection and it just stops working. The Gamma trunks don't work at all and VOIPUnlimited trunks start coming back with No ACK received and 30sec max call length.

The two other systems also had same interruption to internet connection, when the connection cam back on they registered and worked fine all day. We are having some real problems with version 14, but Gamma trunks don't work with version 12.

 

[benratty]

Just further update on these issues.

I have SIP trunks on my system from two different providers
VOIPUnlimited - registered trunks by username and password
Gamma - Authenticated by IP Address

What I have found after quite a bit of testing is that if for any reason the VOIPUnlimited trunks cannot register about 10 mins later the Gamma trunks stop functioning properly. Not allowing calls in the only occasionally allowing them out.

The Gamma SIP trunk only starts working again when the VOIPUnlimited trunks register successfully. Then it takes some time before they work fully again.

The two problems we have so far encountered in both cases VOIPUnlimited Trunks failed to register, on the first occasion the trunk provider had an issue and the second occasion the internet connection was interrupted causing the VOIPUnlimited trunks not to register and it wasn't until they where registered even though internet connectivity was restored that the Gamma SIP trunk started to function again.

Any thoughts anyone had similar issues with two different providers and different registration methods?

 

[NickD_3CX]

So what happens when the VoIP Unlimited trunk is down on the Gamma trunk exactly, can you not receive calls on the later, make outbound calls or both?

What do you see in the packet captures? Is the 3CX Server sending the correct Public IP address in the Contact (or Via header in the Gamma case) header?
You mention that this also sometimes happens when there is a short internet outage. Do you have a Static Public IP of is it a dynamic one?

 

[benratty]

I am just testing it right now.

I have removed the passwords from the VOIPUnlimited Trunk so they fail to register, calls for about 10 mins worked on Gamma and then would not work at all inbound and intermittently outbound (by outbound as I am not in the office I am using 3CX phone app to test those outbound calls) and last few outbound have worked. But the inbound calls to the Gamms trunk do not work.

I have tried removing the Gamma SIP trunk from the system, restarting the services and no change. Still not working inbound, the call disconnects.

16-Jun-2016 19:45:03.616 [MS105000] C:22.2: No RTP packets were received:remoteAddr=127.0.0.1:12032,extAddr=0.0.0.0:0,localAddr=127.0.0.1:7046
16-Jun-2016 19:45:03.496 [MS105000] C:22.1: No RTP packets were received:remoteAddr=88.215.55.12:27062,extAddr=0.0.0.0:0,localAddr=PUBLICIP:9062
16-Jun-2016 19:45:02.001 Leg L:22.2[Ivr] is terminated: Cause: BYE from PBX
16-Jun-2016 19:45:02.001 [CM503008]: Call(C:22): Call is terminated
16-Jun-2016 19:45:02.001 Leg L:22.1[Line:10000<<07875009XXX] is terminated: Cause: BYE from 88.215.55.11:5060
16-Jun-2016 19:45:01.931 [CM503007]: Call(C:22): Ivr:8006 has joined, contact <sip:[email protected]:5483>
16-Jun-2016 19:45:01.929 [CM503007]: Call(C:22): Line:10000<<07875009XXX has joined, contact <sip:[email protected]:5060>
16-Jun-2016 19:45:01.928 L:22.2[Ivr] has joined to L:22.1[Line:10000<<07875009XXX]
16-Jun-2016 19:45:01.928 NAT/ALG check:L:22.2[Ivr] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
16-Jun-2016 19:45:01.768 [CM503025]: Call(C:22): Calling T:Ivr:8006@[Dev:sip:[email protected]:5483;rinstance=e4fe3bc3251ce641] for L:22.1[Line:10000<<07875009XXX]
16-Jun-2016 19:45:01.760 [CM503027]: Call(C:22): From: Line:10000<<07875009XXX ("CALLERNAME" <sip:[email protected]:5060>) to T:Ivr:8006@[Dev:sip:[email protected]:5483;rinstance=e4fe3bc3251ce641]
16-Jun-2016 19:45:01.760 [CM503004]: Call(C:22): Route 1: from L:22.1[Line:10000<<07875009XXX] to T:Ivr:8006@[Dev:sip:[email protected]:5483;rinstance=e4fe3bc3251ce641]
16-Jun-2016 19:45:01.759 [CM505003]: Provider:[Gamma Trunk 1] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sipUBLICIP:5060]
16-Jun-2016 19:45:01.759 [CM503001]: Call(C:22): Incoming call from Line:10000<<07875009XXX to <sip:[email protected]:5060>
16-Jun-2016 19:45:01.758 Line limit check: Current # of calls for line Lc:10000(@Gamma Trunk 1[<sip:[email protected]:5060>]) is 1; limit is 64
16-Jun-2016 19:45:01.758 NAT/ALG check:L:22.1[Line:10000<<07875009XXX] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop
Media session IP ('c=' attribute) is not equal to the IP specified in contact header:
Media session IP:88.215.55.12
Contact IP:88.215.55.11
Media session IP ('c=' attribute) is not equal to the SIP packet source(IPort):
Media session IP: 88.215.55.12
Received from: 88.215.55.11
16-Jun-2016 19:45:01.757 [MS006000] C:22.1: connection address is enforced to PUBLICIP
16-Jun-2016 19:45:01.754 [CM503012]: Inbound any hours rule (unnamed) for 10000 forwards to DN:8006

 

[NickD_3CX]

OK, so the Inbound Calls never work Inbound when the VoIP Unlimited trunk is down. The logs you posted seem to be an Inbound Call that seems to have been connected to the server to 8006, and then it seems that the BYE (call termination) request came from 88.215.55.11:5060.

Was this a failed inbound call? If yes what is IP 88.215.55.11?

 

[benratty]

Yes all the inbound calls are failing. The 88.215.55.11 is Gamma Telecom address.

8006 is just a digital receptionist that plays hold music back I am just using this to test.

When I have asked Gamma, they just say they don't receive the external IP address so the call fails.
16-Jun-2016 19:45:03.616 [MS105000] C:22.2: No RTP packets were received:remoteAddr=127.0.0.1:12032,extAddr=0.0.0.0:0,localAddr=127.0.0.1:7046
16-Jun-2016 19:45:03.496 [MS105000] C:22.1: No RTP packets were received:remoteAddr=88.215.55.12:27062,extAddr=0.0.0.0:0,localAddr=PUBLICIP:9062

This part of the log is what appears when the calls fail, with extAddr not having the external IP, but the external IP does appear in localAddr field as shown above which I have just masked out for now.

 

[NickD_3CX]

This is one of the cases you would want to run a packet capture, because the log does not show you all the SIP packets and their content, so I would recommend capturing with Wireshark, make an Inbound Call, let it fail, stop it, then filter with something like 'ip.addr==88.215.55.11' and focus on the content of the INVITE and 200 OK messages to see what the 3CX Server sends back to Gamma in response to their INVITE.

 

[benratty]

Ran Wireshark see clip

 

[NickD_3CX]

OK, I can't see the content of the packets, but if you highlight packet 290, then expand the "Session Initiation Protocol" and then the "Message Header" in the lower pane of Wireshark, you should be able to see the SIP response contents that the 3CX Server sent in response to the incoming INVITE.

In this packet you should be able to see the 'Via' header that is sent. If it looks correct, call Gamma and tell them you are sending it correctly. Even better, you could send them the actual capture file and ask them what they see wrong with it.

 

[benratty]

Thanks Nick, just see attached does this look correct?

And just out of interest, our firewall is managed by ISP we use. Could the IP be getting lost through this?

 

[NickD_3CX]

In the Gamma SIP Trunk Advanced settings, what do you have in the "Put Public IP in the VIA Header" field, your own Public IP or the Gamma Server IP?

There you should see your own Public IP.

 

[benratty]

My own public IP address.

 

[benratty]

See image.

 

[benratty]

FYI I added the VOIPUnlimited trunks back in about 1 hour approx. ago - and just now Gamma trunks started working on inbound calls again.

 

[benratty]

I ran some more traces through wireshark this morning and both inbound and outbound calls worked, yet the logs looked the same as the ones I tried last night that did not work.

The document provided by Gamma states that in the From Header there should be number registered to the endpoint and IP address of public facing interface. When I look at the From header to me I can see registered number at the endpoint but then it contains Gammas public facing sip registration address and not the public ip address of our 3cx system.

 

[NickD_3CX]

Although that does not sound right, you should be able to adjust all of this from the "Outbound Parameters" tab in the Provider settings, you have all the SIP field in the left column and which value to populate it with in the right-column.

Don't forget though that all these settings will mainly affect the Outbound Calls (initiated from the 3CX Server), not Inbound. For the Inbound Calls I am at a bit of a loss....

 

[benratty]

Yes it is really only inbound that is biggest issues when this happens. As suggested I have passed all the logs to Gamma and our ISP to make sure that checkpoint firewall isn't messing with anything. Just cannot understand how only happens with I remove the other provider and why it takes so long to start working again.

I am also setting up another system, complete fresh install with just Gamma trunks on it to test.