Calls transferred to stations with EC500 disconnect after 30 seconds

[vulcanccit]

We have a core Aura CM in Phoenix with 39 LSP sites. All sites have a local Sip trunk which is a century link voice cloud. I am starting to get complaints that when a receptionist transfers an incoming call to the internal extension, which has EC500 enabled, the call will ring the user's cell phone as expected.

User answers... call continues but at 30 seconds it drops. Out of the 39 sites, I have heard of this happening in 3 markets. If it is happening in others I have not heard about it. I have our BP looking into it, but I thought I would toss it out to you folks to see if you have seen this.

 

[LoPath]

30 seconds seems odd... is there possibly a SIP registration timer that's expiring?

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4, Xpressions, Contact Center

 

[vulcanccit]

Im not sure... in about 2 months we will be transitioning this system into Windstream's cloud based Avaya solution UCasS so it won't be my problem much longer lol.

 

[kyle555]

traceSBC

30 seconds is always telltale for a signaling message not being answered. The carrier is probably sending you a 'bye' because it sent you a message you didn't answer.

So, leg1: outsider, in the SBC-->SM-->CM reception (just a 9600 with sidecar or One-X Attendant? there's a big difference!)
leg2: reception (if not 1xa) makes a new call to the ec500 station. Upon completing the transfer, you should have 2 channels up - original in the SBC, second out the SBC to the cell.

Now, your CM and SBC have to juggle both legs of that call to keep the carrier happy with the signaling. Add to it that if you have shuffling enabled, you're going to have CM tell the SBC to do "direct audio" between "inside interface port A for in the inbound leg" and "inside interface port B for the outbound leg"

One dirty trick is maybe to, in off-pbx station-mapping, to have ec500 point to a different trunk group for the SBC with no shuffling to force a CM DSP in between. It'd at least get you a different media path to test.

Now, on a national carrier, they'd usually have something you interface your IP trunking with (obviously...) but now the numbers you dial would go to whatever switching they have for those areas. To say, if they tie in to the mobile carrier by IP in market A, then you're ec500 in market A is end-to-end IP and the signaling might look different than when you do it in market B where they're on a TDM backend to the same carrier.

Are your trunks dedicated, or are you shared registration through the internet? Is there something the SBC is mungling up in there?

Sometimes a sigma script to remove record-route headers can be helpful. Those record-routes basically are a list of the proxies you must go through in order to get back to the server that sent the message. Sometimes the Avaya SBC can mess that up with the complicated call legs you've got, and it's possible only certain PSTN calling scenarios expose that.

If you can 'fix' it by using a dedicated trunk and statically map that in off-pbx station-mapping on a non-shuffling trunk rather than sending it to ars, you'd have something to work with the carrier on. Good luck though. It'll probably be a long haul before they tell you that you broke something on your side and to call Avaya

*edit: why do you think being on Windstream's UCaaS will be any different

 

[vulcanccit]

Kyle, lol because once it is in their hands, they support it and not me lol.

So I just talked to the 1st market that had the issue. We do not have an SBC, as our ISP has the SBC, and has a VPN tunnel to us. In the case of this market they receptionist device was a 301D attendant console. We just swapped that out last week to a 9650 and all is well on the transfers. We have a 301D in Phoenix and they complain as well so maybe it is something going on with that since it is digital and not IP based. All other calls are ip to ip transfers after call setup.

I have 2 other markets with 9650s complaining as well but I need to get details on what is going on. All I have heard is "the call disconnects'. I dont know where they are transferring it to/from, etc. I will keep you posted.

Also when we go to Windstream, they will be the ISP as well and not our current carrier which is a reseller for Century Link, GTT is the company, formally Onesource Networks.

Kyle your info was super helpful I thank you!

 

[kyle555]

Yeah, been around the block a few times on this

Regardless, doing voodoo end-to-end SIP is a recipe for problems like the ones you have.

So, if your ISP has an SBC, they're providing you SIP trunking. If you don't have an SBC and you're direct to theirs, there's not much you can do to tweak the signaling at that single choke point that a SBC provides.

That said, an attendant console is a pass-through. So, the 301d (or one-x attendant) is not "placing a call" like any other TDM or IP set but in fact passing along the call it received. It's an important distinction about old console stuff. If the transfers through "not a console" work, then you've got a way forward.

So, uhh...once you get on the Windstream UCaaS, what are you going to do with your receptionists and consoles? I see them being a little bored
If you're going to be all SIP on that, word of warning - the less key-system like features you use, the better!

 

[vulcanccit]

im not sure, I am leaving that all up to the people that wear ties and make the decisions lol. Most of our markets have a vector to a coverage answer group so we do not have many receptionist anymore.