1. What happens when you put the call from PSTN on hold ? Does it work?
2. What is the busy trigger set under the directory number on CUCM? Is it set to 1?
3. What is the error message?
4. At what point of time does the call fail? Does it fail as soon as you press the transfer or conference button or it lets you dial the number and fails when you try to complete the transfer or conference?
Thanks for update
1. incoming MOH is working fine
2. Busy trigger number is 2.
3. Calls getting disconnected when we tried to confrence and when we do transfer any calls then message showing transfer successfully but call disconnected.
4. its not failed when we press conference button its fails when both calls are initiated but that time try to press CONF button then its fails.
What is the setting you have for Rerouting CSS on the SIP trunk?
Let's try to collect information in the proper way.
Make a test call, and provide, calling, called number time of the call, scenario that you triggering (like transfer and to which number you are transferring etc).
For the time of the test please colelct CUCM and CUBE traces:
> From CUBE debug ccsip messgaes
> From CUCM Callmanager traces:
After collecting traces attach them here with description.
From what your describing it sounds like the classic case of a CODEC mis-match, looking at your trace I see the call is using the G729 CODEC, which will require some form of transcoding if your only using the CUCM conferening resources.
Do You have transcoding resources? Where are the conference resources located, are you using the CUCM only or do you have hardware conference bridges too?
It is most likely related to MTP and Conference resource allocation on the SIP trunk from CUCM to CUBE. Please ensure MTP and conference bridge resources are allocated in the MRGL of the SIP trunk. If the issue persists please get the "debug ccsip messages" from CUBE for a test call with an issue.
Looking at one of the failed calls in the debugs that you attached the signaling is captured in the pic that I attached to this post. It is similar to the one in the following post
My suggestion is to check if the "SIP Rel1XX Options" option is set to disabled on the SIP profile associated with the SIP trunk, it seems to match the following bug