Avaya Aura CM SIP - External MoH invites

[whiteta]

Hello, I am working with a third party vendor who is using a SIP PBX software package to act as a CTI solution in our environment. The software is known as "CrossX", and it is set up to take data from a SIP header and use it to perform screen pops to our call center agents. They are doing some application tuning on their CrossX servers and have asked me to disable music on hold invites coming from my Avaya CM. I have never heard of this nor do I know of any system parameter that would disable sending MoH invites in the SIP header. Has anyone heard of this?

This is from the vendor:

"We are getting MoH invites from Avaya which overrides Avaya MoH and plays CrossX default music on hold. This will also increases load on CrossX. Please cancel sending of MoH invites from Avaya."


When I asked for more details they told me this:

"There will be option to turn off external MoH invite from PBX as we see in logs that an INVITE is received when the MoH is triggered on Avaya."

 

[kyle555]

Dear CrossX, why don't you behave like a normal passive CTI app, do your job, and not make me change my PBX? Why don't you turn off your MOH?

Presuming it's an inbound call center call, let's just pretend CrossX is using the FROM header to look up my caller ID in your SFDC and pops the account information.

Also, let's presume they want you to stop sending invites for MOH. That implies you've already sent a 200OK to answer the invite from the CO.

The initial flow you be something like 'invite' from the carrier, 200 from CM for landing in a vector. CM will send a new invite any time it needs to change up media endpoints in the call. So, if you happened to have the announcement of "thanks for calling" on gateway 1 and 'music' on gateway 2 and 'we're experiencing unusually high call volume' on gw 3, then a call that lands in a vector and hears 30s of music and then the 'unusually high call volume' announcement and then 30s music, and repeat would always have invites generated to change the media endpoint because the audio sources are on 2 different gateways/IPs

Further, even when a call lands in a vector, it'll be 2 way audio to listen to dtmfs from the caller. When you put on hold, you send a reinvite with a a=sendonly attribute. You sending that a=sendonly means you're telling the caller not to send audio because you're not listening and you're just sending music. The same would happen on a SIP DID call that you press hold/unhold on.

Or, to be brief, there's no real way to say "make your PBX stop sending these SIP messages". You have control over how the PBX is configured. The PBX then decides what H323, ISDN and SIP messages to send out to accomplish that.

What messages is CrossX tapping? I'd think they'd need to be more flexible. Avaya AES has protocols to do this exact thing, but if CrossX wants to be generic and vendor agnostic and work off raw SIP, then they should be ready to deal with whatever's coming their way and hold music isn't exactly exotic.

 

[whiteta]

That's pretty much what I thought, I haven't been able to google anything or find anything in the manuals about an option to shut that off. They are looking in the SIP header, pulling ANI, and UUI data that is passed along from a third party IVR system. Here's the call flow:

Incoming call (from external parties' IVR) >> My Oracle SBC >> CrossX Server (SIP header data mining takes place here) >> My Oracle ECB >> My Avaya CM (contact center agent gets call, gets screen pop in desktop app via AES TSAPI / CrossX transaction).

So, yeah........

Thanks for the post!

 

[kyle555]

OK then...

The way I understand a normal screenpop app to work...

-You can TSAPI monitor a VDN and an agent. It'll take 2 TSAPI licenses to do this.
-You monitor the call coming into the VDN - you get UCID - the unique call identifier - and UUI - the thing from the IVR - its like a bookmark for the agent application to know where you are. Like, you entered your client number, entered an order number to be tracked and pressed 0 for help
-The app monitors the call coming into the VDN and the agents. When it finds which agent got the call, it tells the app on the agent desktop to pop the required information

You can do all sort of CTI without AES if you want to rough it and guess off SIP messages, but if you're already using TSAPI on the agent side in your application, I can't understand why you'd avoid using it on the incoming leg of the call hitting the ACD to get the information you need. If you already know how to write an app to use TSAPI, it doesn't make sense to me why you'd do it the hard way and sniff SIP messages and complain that the PBX put people on hold.

 

[whiteta]

Well, unfortunately none of this was my decision. This is what the business chose to do from a third party developer. I just get to make sure that everything can talk to each other on the appropriate ports and all that fun firewall stuff. This CrossX solution includes a Web server, database for statistical tracking of whats going on within the solution. At least I can pretty much shrug this off then as there is no system parameter that does what they are asking.

:0 )