Help with setting up Monitor trace please 3

[t3rm3y]

We have an issue with Gamma SIP that has started happening out of nowhere. Calls intermittently have waiting for line, The avaya is 9.1.12.0 build 213 and hasnt been changed and this is routing calls directly out via a Gamma provided router. They say no upgrades have occurred their end.
If the callee gets waiting for line the 3rd party hears ringing but it is a silent call, if 3rd party hangs up but callee has stayed on the "waiting for line" call it then rings and the call works.
This is being reported mainly on o2 mobiles - so this is the only aspect we cant check.

What tick boxes do i need to enable within monitor to trace only the SIP calls please, I just have no experience with monitor. and do we need to set any other settings to properly trace what is happening?

 

[Okkie26]

Tick ' clear all' then go to the sip tab and tick ' tab set all'

 

[TomMills]

To be honest you'll see the issue plainly in SSA.

There were recent changes on the Gamma network (over a long period of time to be fair) regarding CLI presentation. Are you presenting your CLIs correctly? It's now causing onward carriers to reject calls in some cases.

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

 

[t3rm3y]

Thanks Okkie26,
Tom we have the CLI in the Name SIP field, the username in the SIP Display Name (Alias), and the extension number in the 3rd field Contact field.
The SIP line is user internal data for local URI / Contact / Display Name and PAI
and a * for the 2nd row.

 

[janni78]

Normally you want to have the CLI in all 3 fields

"Trying is the first step to failure..." - Homer

 

[critchey]

I know I have seen a number of techs post on here that they can get SIP trunks working with a single SIP URI but I have had issues with some providers making that work so as a standard I always making two SIP URIs. One is for incoming and is *(auto on newer versions) for the fields 17 incoming group and 99 outgoing (so it doesn't get used). If they always want to present the main CallerID I specifically put that number in all fields and use 17 for both incoming and outgoing so it will still route in and be used for out. If they use different DIDs for each user I set to internal data for each field and set to 99 incoming and 17 out. ARS uses 17 and ICR uses 17. This tends to work for all but the worse SIP providers that want a SIP URI built for each DID and those providers should be avoided like the plague (Earthlink is like this...).

The truth is just an excuse for lack of imagination.

 

[t3rm3y]

Hi Critchey
Do you have a screen shot please of the set up you are doing, just so i have it right.

 

[tac84]

Hey @t3rm3y
This how my SIP lines work best, essentially what @critchey is saying.
See the screenshot below:

Thanks, Tim
Adelaide, Australia

 

[bubble727]

Hi t3rm3y

Try speaking with Gamma again, we had this issue and they ended up rolling back the changes they had done on endpoints. We had exactly the same issues you described.

Mike

 

[TomMills]

I would recommend getting it fixed on the IPO side, otherwise you're one set of Gamma maintenance away from it breaking again.

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

 

[critchey]

@tac84 If you put the number in specifically like that I would do 2 incoming and 2 outgoing otherwise it might try to use that specific number URI instead of the * URI for that specific number to route inbound and then complain there is no ICR with line group ID 0. If you did internal data instead that is how I do it though.

*sorry had a big project was working on past few days.

The truth is just an excuse for lack of imagination.