cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6214
Views
5
Helpful
2
Replies

Call is getting 487 Request Cancel after being answered and hearing MOH

AnnM410
Level 1
Level 1

The problem is with any call to our Helpdesk from an IP Phone and getting "MOH". The caller hears our helpdesk "Greeting"but if the call is given MOH treatment after 60 sec's we get "your party is not answering"and the call terminates. If an agent is available the call gets the greeting, transfers to an agent and there is no issue.

One other note: the IP Phone doesn't clock the time on the bad call but does clock the time on the good call. 

We tried to do some local tests and capture what is running when this happens.

What we can see, is that SIP connection progress (INVITE, TRYING and so on..), and that SACIN/TDP GW generates a “SIP SESSION PROGRESS” (183) which is perfectly valid and is used to open a one only way RTP audio channel to send the MOH… once the agent is able to get the call, PBX would send an OK generating a 2 way RTP flow (normal one)… 

The problem is that although the SIP SESSION PROGRESS is sent, the callers CUCM after 60 secs sends a SIP CANCEL terminating the connection. We don´t know whether the cancel is progress from PSTN, or locally generated by the CUCM, but taking into account that doing tests from a local IP Phone you obtain same results, I would say that CUCM by any reason is not processing correctly the SIP 183 packet being sent. Could you please analyze what could be happening? see attached debugs

1. The Voip1.pcap & Voip2.pcap files were taken from where the call is calling out of. These are 2 calls Voip1 was successful (answered with greeting, transferred to agent, no MOH treatment) and Voip2 was unsuccessful (answered with greeting but was given MOH treatment)

2. The SACIN file contains:

     A packet capture of the traffic in and out the SBC in Spain.

     172.20.24.130 is the voice gateway that connects with a PRI port to DITEL PBX

     172.20.24.140 is the Acme SBC

     10.117.119.13 is the CUCM at Avangrid

 

2 Replies 2

As you can see in your trace, seems that the CUCM doesn't understand this EARLY media response:

trace.jpg

 

I don't know why. The SIP signalling seems OK.

You can try to ask your provider to send all answer in LATE media or you can try to create an internetworking "early to late" in your ACME.

Or you can try to investigate why your CUCM doesn't understand the 183 message. In this case enable the debug on the call manager and add the result to this post.

 

Regards.

 

 

Did you manage to find any solution to the issue?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: