03-19-2017 07:04 AM - edited 03-15-2019 06:28 AM
HI All
We use UCCX 11 and CUCM 10.5
Several times , some calls are dropped as soon as the agent picks up the call.
It may be codec mismatch or not ? we enable 722 advertise .
you can check our script attached.
BR
Remon
03-19-2017 07:36 AM
Indeed sounds like a codec issue if phone rings, but call drop upon answer. You will need to review the MIVR logs from CCX and CUCM SDL logs.
03-20-2017 05:18 AM
unfortunately ,at the time of this issue we didn't turn on traces .
but there are some other issues with this main issue .
1- some time this error message appear on finesse when agent try to answer call "This operator can't be part of call"
2-some time call drop after agent pickup call and once it ring it dropped .
3-some times after agent answer call ,agent listen to MOH not customer .
08-23-2018 11:54 AM
Are there multiple DNs configured on the phone? If so, you may need to turn off "Always Use Prime Line" on the Phone level.
07-05-2019 02:40 AM
09-10-2019 07:55 AM
What was the fix to your issue. I am experiencing the problem.
09-10-2019 10:40 AM
I had a similar issue that was coming and going I struggled with for a long time. I don't know that this would be a fix, but I will share what we found.
We had Verizon SIP trunks come into 2 different CUBEs at 2 different geographic locations. For the most part, we had from years prior, all calls coming in and going to g729 for most sites. We did have calls going to the region our UCCX servers were on set to go to g711 which is what UCCX requires, but some of our scripts hold music were on g729 and connections from UCCX to the agents partitions at g711.
It wound up being really tricky as only every so often, for about a day or 2, we would suddenly have this issue and after months of not being able to hit this with TAC at the same time of it happening, we finally saw with TAC, them saying that Verizon was not answering the handshake on codec, and then go to Verizon on that and them saying they are not getting a handshake. Nobody really had an answer other than that as the codec changes, someone was not responding with that handshake as we went to MOH (g729) back to UCCX prompts (g711) and back to MOH (g729) and then to an agent (g711) so we had no audio and calls drop.
Finally; I went through and flattened them all to be g711 all the way through. I edited every script to not access our MOH on g7.29 which I learned g729 was not meant for music anyway and used ones we had within g711 or via built in prompts. No more handshakes from flipping codecs back and forth. Was a huge relief.
09-17-2019 02:35 AM
09-17-2019 04:53 AM
@Scelo wrote:
Thank you,
Indeed a tricky one and considering I play MOH when agents are busy, one might need to look into that. You say your solution was to rather reference to another script with music instead or how did you exclude MOH?
I do think this will help us a lot and might have a role in all this, we are however using PRIs to receive external traffic.
Kind regards,
In place of the Call hold, delay, Call unhold steps; I play a prompt. For some and quick remedy; I used the UCCX built in SP[ICM/ICMMusic_60.wav] which is conveniently named for lasting about 60 seconds, and for others where it made sense, we used some public music and dubbed some company advertisements over top and uploaded the WAV to UCCX.
09-17-2019 02:37 AM
05-15-2020 07:08 AM
Hello Mate,
Did you find a solution for this at the end?
05-15-2020 07:47 AM
You will need to check that from CUCM side during call establishment
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide