Gamma SIP issue IP Office 11.1 2

[Scuzzie2k]

Good Morning to you all, been watching this forum for a while and its been very helpful, I need help this time. We have several IP office 500 rls 11.1 all using gamma sips, all setup identical, same firewalls, same port forward, but a couple of newer sites we have done we are getting alot of 'Waiting for Lines' some numbers we cannot dial on them ever, but can on older ones we setup. Gamma have checked the trunks all working fine, and if we use a onsite 3cx to test they work. Any suggestions? One number we use for testing Gamma say they are not getting a response from the IP office and sent this imag

 

[derfloh]

Check IPO monitor why it doesn’t answer the 200 OK messages. Or check the firewall off or forwards those messages to IPO.

Hopefully the left IP in your screenshot is not the IP of the IPO.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[critchey]

Anytime I hear the phrase "they are not getting a response from the IP office" for SIP trunks I assume it is SIP_ALG, SIP Transformations, SIP Helper (or whatever your firewall wants to call it). Make absolutely sure you have this shut off in your firewall. If you can't find the setting for it look it up most firewalls have this and sometimes it is buried(I think it is command line only in some).

The truth is just an excuse for lack of imagination.

 

[Scuzzie2k]

We have made sure ALP is off on the Draytek, still nothing, Gamma are use less. The other ones are on Watchguard Firewall. I am loosing the plot with this, just cannot get it to work. I have 5060 & 5061 forwarded along with the media ports all to the IP Office

 

[Ekster]

Ask Gamma support for the actual PCAP trace of the failed call (the image you have is the call flow from it), they should provide it for you.

You need to look deeper into the SIP packets. In particular, the SDP info.

The contact IP address or ports may be getting changed somewhere.

“Some humans would do anything to see if it was possible to do it.
If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH'.
The paint wouldn't even have time to dry.”

Terry Pratchet

 

[Scuzzie2k]

Have requested this. Will feedback shortly

 

[Scuzzie2k]

Little update I have sorted the issue with the IPO that was not working at all, the other system still cannot dial some numbers saying waiting for line. As a test this weekend I factory reset the IPO, rebuild the SD Card and still the same..... Ihave asked them for the PCAP trace its strange. We even put the IPO in the DMZ, monitored all traffic on the firewall, nothing is being blocked, all other calls work most of the time.

 

[Scuzzie2k]

Not sure if anyone can help, but the Avaya engineer has noticed this back on the calls that have issues:

100 trying is received from far end to the Invite, but one odd thing I noticed is the From header of Invite is modified while coming back from service provider side, not sure if this is some account code, we need to see why far end sends like this and if this is causing the issue.
13:35:06 86492270mS SIP Rx: UDP 88.xxx.xxx.xxx:5060 -> 172.16.8.8:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 51.xxx.xxx.xxx:5060;rport=5060;received=51.xxx.xxx.xxx;branch=z9hG4bKbce15880f1cb5914c9cb751448fb9e43
From: sip:#131212#0145xxxxxx@88.xxx.xxx.xxx;tag=31e2217ad11445e6
To: sip:03449xxxxx@88.xxx.xxx.xxx
Call-ID: 75e5da3790ddc3200199be9627d0cd75
CSeq: 1871122714 INVITE
Content-Length: 0

 

[biglebowski]

We have Gamma SIP but on Avaya CM8 and I get similar on the 100 from Gamma, ours looks like this:

From: <sip:9876543210@88.xxx.xxx.xxx:5060>;tag=ACU-1c99-36c11a44

The SBC modifies it and sends it on to the SM in the format I would expect to see (where domain.local is our internal sip domain)

From: <sip:domain.local>;tag=ACU-1c99-36c11a44

Biglebowskis Razor - with all things being equal if you still can't find the answer have a shave and go down the pub.

 

[Scuzzie2k]

Really loosing the Plot with this, cannot get it to work, one number will not dial, randomly it did once yesterday, not it wont again keeps saying waiting on line.

 

[Ekster]

We have seen this before.

The code "#131212#" is a token added by Gamma to allow routing of calls on their core network. Contact them, show them this example, and they should remove the token from the messages that are sent to you.

The annoying thing about this is the Avaya just rejects and drops the packet, you don't see it in the monitor trace and think it's not getting to the IPO! You can only pick it up from a PCAP.

“Some humans would do anything to see if it was possible to do it.
If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH'.
The paint wouldn't even have time to dry.”

Terry Pratchet

 

[Scuzzie2k]

do you think this is what is the issue?

 

[Scuzzie2k]

I notice we have it on calls that work also

 

[Ekster]

We had similar issues, some calls were OK, some not. Once the token was removed by Gamma, the issue went away.

You can't do any harm asking, the token is for Gamma internal use and removing it will not affect the IPO.

“Some humans would do anything to see if it was possible to do it.
If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH'.
The paint wouldn't even have time to dry.”

Terry Pratchet

 

[Johnhyde]

We experience the same issue with some of the systems.

Removing the #131212# resolved most of the issues.

However, we still have issues (random) calling with waiting for line, redial a few times, and its works.
Gamma support was unhelpful and useless.

The only way we were to resolve this issue was to move the SIP to a different provider and all has been working fine.

This did prove that there is something on the Gamma network that stops some calls from working, hence we don't use them anymore!

Thanks

 

[CMUK]

Got screen shots of your SIP Line config?
I've got around 100+ IPO500 With Gamma SIPs out there

Calum M
ACSS

 

[Scuzzie2k]

I agree gamma support is hopeless, 6 weeks this has been going, saying there is nothing wrong, asking them to compare trunks with our other customers that work, I am IT & Comms not SIP Engineer. In the end Avaya Support helped out, and pointed out this extra line in the header. Looked at 8 Systesm I have out there, all with the extra header have issues all the ones that work fine dont. Not untill this has been pointed out over and over again are they looking into it.

 

[Scuzzie2k]

Just to follow up, Gamma removed that header, all the lines are working fine now. Anyone else has this issue make sure you keep on at them, when they looked back at old tickets it had been flagged before. 2.5 Months for them to sort this...

 

[TomMills]

Good fix.

One thing to watch for, very occasionally these custom settings (we had some custom ptime settings for one customer, not IPO) can be removed or readded or reset depending on how you look at it, when Gamma do their routine maintenance, so you may need to do this again.

Their support used to be serviceable, but recently has been very poor.


APSS/ACIS/ACSS-SME
not arrogant, just succinct.

 

[derfloh]

Gamma seems not to be the best option from what I read here. Probably cheap?

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN