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 .

What was the fix to your issue. I am experiencing the problem.

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.

---

@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.

Hello Mate, 

Did you find a solution for this at the end? 

You will need to check that from CUCM side during call establishment