Odd issue with EC500 when a call is transferred from front desk.

[vulcanccit]

We have a core system in Phoenix and 37 gateways around the country. On certain users, and it seems to be intermittent, if the front desk transfers a call from the front desk to the desk phone of a user that EC500 enabled to a cellphone, the call will complete but then drop after 30 seconds. A call trace shows no errors, shows call was transferred. Other users it is fine. We all have the same cell carrier, which is ATT.
It doesn't matter if the call is transferred from the core, or from the remote site's receptionist phone.

any ideas?

 

[AvayaTier3]

Hardware platform? CM software version? Currently activated Service Pack?

Front desk is transferring what call?
How did the front desk get the call?
Front desk transfers call to station (ec500 enabled), call answered at station? Both called party and
calling party can talk, then drops after 30 seconds.

When you figure out this much, you should be able to do list trace station xxxx (xxxx is front desk)
Make a call that is answered by the front desk and transferred.
Once duplicated, you may want to verify same incoming call to different stations (ec500 enabled)
and see which are working and which are not.

List trace at transferred to station and watch for denial event or the drop and the connected parties

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[vulcanccit]

Im not able to check versions as I am offsite now, but it is the Aura one x and I believe we are at 6.3 fully patched.
Front desk transfers a call from the outside.
call is answered on the Cell, not at the station. Both parties connect then after 30 seconds it drops.

I have done a list trace on the station but not on the front desk. I will try that out when it happens again and I will see what it says.

 

[kyle555]

What kind of trunks? Maybe a SIP trunk requires Passerted identity on an outbound call to be a valid subscriber (like buddy with the cell's desk DID). Maybe because the receptionist at one site doesn't use the same SIP trunks - or SIP trunks at all - the EC500 forwarding out a SIP trunk gets the call setup from "receptionists extension"@yourcompany.com" to the SIP PSTN.

I've seen that on some SIP trunks - some use FROM as CLID, and PAI must be a valid subscriber of the trunk to get out. There's some SIP manipulation scripts in the Avaya SBC in their interop notes for various SIP vendors to accommodate stuff like that.

Even if EC500 guy is on ISDN trunks, who knows if they're ISDN to the CO or turned into SIP on prem to get back to the carrier.

You can try turning on SA8983 (

https://downloads.avaya.com/css/P8/documents/100171717)

to set the CPN to his own desk extension for calls forwarded to him (if you have maintenance permissions on the switch) and see if that changes anything. Otherwise, ask the carrier what their requirements/restrictions are if you're sure its not on the PBX that its dropping.

 

[vulcanccit]

kyle555 yes, each site has its own sip trunk, but all the same ISP. We use the ISP's SBC as they have a vpn tunnel to us. We do pass caller I.D. the same way in all markets. What is weird is it only happens to a few users, and not all of the time. I use EC500 the exact same way and it has never happened to me. I do like the idea of list trace on the reception phone as opposed to the destination desk phone.

Another thought, would this be a Off-Net Trunk access issue? like some kind of security issue?

Now a few users said it only happens when they transfer to the cell directly. One user today said it has happened when transferred to the desk.

So odd.

 

[kyle555]

Get a SIP trace! whether its your SM to their SBC, or your own, get a trace. Someone is sending a disconnect, probably the carrier.

And just cause its the same carrier doesn't mean it's the same treatment in each rate center/CO switch they have. 30 seconds smells suspiciously like a SIP problem and I'll bet ya its to do with the call forwarding.

 

[vulcanccit]

Kyle555 I agree, the reason it might be intermittent and only affect certain people, is the ISP is GTT. They are just a reseller of phone service, so the route the call takes could change as they move routes around (which they do often). I can get them to do a trace.

 

[kyle555]

Do you have a SM or are you SIP direct CM to the carrier's SBC?
A traceSM would be very helpful.

Even a list trace station will have a < or a > to indicate whether CM sent or received the message. I'll bet ya it's got to do with the PAI/From/something the carrier requires.

 

[vulcanccit]

We do have an SM, however I have never done a trace with it. how do you trace the SM?

 

[kyle555]

Ssh in, traceSM
Once in, you can filter by pressing 'f' and filter on '-u 1234' to drill down to only user 1234 or '-i 1.2.3.4' to filter only on that ip. When you're done, press s to stop and w to save as as file. You can open it again in traceSM or unzip and open I wireshark.