[cisco-voip] [EXTERNAL] Finesse dropping calls upon answer

Fri Jan 17 17:36:29 EST 2020

Additional to Nicks’ response….  Check the SIP configuration and make sure that you have BEST Effort MTP enabled.   That way if it needs the MTP and it can’t get one, DTMF might not work, but your call remains.

Also, I have seen this with Delayed/Early offer on some setups and phones.   We had to force early offer to resolve it.  (But that could be what a carrier is doing as well)

ALSO!!!

If this is a new setup…. Check the codec order!!!

When we set ours up, G711 was perferred, but when the carrier sent a G729 call it term’d.  We were forced to swap the codec order to resolve.   (This was 8 years ago, and things have gotten better, but…)

DEBUG CCSIP MESSAGING is your friend on the cube….   Don’t use debug ccsip all, if can really mess things up at the CPU side.

CUCM logs to your trunk should tell you what’s going on.

> On Jan 17, 2020, at 3:30 PM, Nick Britt <nickolasjbritt at gmail.com> wrote:
> 
> Are you using external media resources  MTP's  (i.e. on the cube) or are you simply using the software MTP's on the CUCM ?
> 
> In my experience, I have seen a leg of the call from CUCM to UCCX via SIP provider invoke an MTP due to a DTMF Mismatch. 
> 
> Then CUCM software MTP resources can randomly drop calls even when they have the capacity, which matches what you are stating. 
> 
> If it was a codec mismatch I would imagine all calls would be dropped. 
> 
> I would check software MTP services (System - > servicer parameter - > select active server - > Cisco IP Voice Media Streaming App (active) then the call count and run flag under Media termination point. 
> 
> If this is enabled and you are not using external mtp resources this could be your issue. 
> 
> 
> On Fri, Jan 17, 2020 at 2:18 PM Jonatan Quezada <jonatan.quezada at chemeketa.edu <mailto:jonatan.quezada at chemeketa.edu>> wrote:
> outstanding, thank you all for insight on where maybe to look, or rather start looking.
> 
> ill see the CTI command from finess via logs, though yeah? ill have to set up capture I think.
> 
> for codec mismatches? Im setting those up on my cube, MediaResourcesInstance also on my cube?
> 
> MTP on the SIP trunk checked.
> 
> On Fri, Jan 17, 2020 at 2:09 PM Kent Roberts <kent at fredf.org <mailto:kent at fredf.org>> wrote:
> Remember, call drops is not a finesse issue.     Finesse is just a control piece for the user.    Look into  CUCM/ivr.    What is sending the disco request?    Should be carrier/IVR/or UCM.    Now if you see finesse send a CTI command to hang up the phone, thats a different issue.
> 
> Most of the time on answer drops can be a sign of codec mismatch.
> 
> Post some cucm logs, with call examples.
> 
>> On Jan 17, 2020, at 2:52 PM, Nick Britt <nickolasjbritt at gmail.com <mailto:nickolasjbritt at gmail.com>> wrote:
>> 
>> What's the call volume? is MTP required ticked on the CUCM SIP trunk?
>> 
>> In RTMT can you check your software MTP resources?
>> 
>> On Fri, Jan 17, 2020 at 1:48 PM Jonatan Quezada <jonatan.quezada at chemeketa.edu <mailto:jonatan.quezada at chemeketa.edu>> wrote:
>> UCCX version: 10.6.1.11003-29 (ES02-11)
>> CUCM Version: 11.5.1.15900-18
>> 
>> caller--->xxxxxx7899--(cube)-->CUCM---->uccxTriggerAndApplication--->HelpDeskDevices---->all88xx phones---->calHandled
>> 
>> upon answering the call drops, but not every call! Very challenging
>> 
>> I imagine there are plenty of reasons why this is a thing, but in our case its hard to diagnose since no network changes are in effect nor have we changed configuration for the help desk.
>> 
>> what are we seeing as the top 5 or 6 reasons or rather things to re-verify regarding the configuration.
>> 
>> please advise
>> 
>> -- 
>> For immediate assistance please reach out to our IT help Desk 5033997899
>> or visit our IT Help center, located here:
>> https://projects.chemeketa.edu/servicedesk/customer/portals <https://projects.chemeketa.edu/servicedesk/customer/portals>
>> 
>> Johnny Q
>> Voice Technology Analyst II
>> Chemeketa Community College
>> Johnny.Q at chemeketa.edu <mailto:Johnny.Q at chemeketa.edu>
>> Building 22 Room 130
>> Work 5033995294
>> SIP 5035406689
>> FAX 5033995549
>> 
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip <https://puck.nether.net/mailman/listinfo/cisco-voip>
>> 
>> 
>> -- 
>> - Nick
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip <https://puck.nether.net/mailman/listinfo/cisco-voip>
> 
> 
> 
> -- 
> For immediate assistance please reach out to our IT help Desk 5033997899
> or visit our IT Help center, located here:
> https://projects.chemeketa.edu/servicedesk/customer/portals <https://projects.chemeketa.edu/servicedesk/customer/portals>
> 
> Johnny Q
> Voice Technology Analyst II
> Chemeketa Community College
> Johnny.Q at chemeketa.edu <mailto:Johnny.Q at chemeketa.edu>
> Building 22 Room 130
> Work 5033995294
> SIP 5035406689
> FAX 5033995549
> 
> 
> 
> -- 
> - Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200117/fcec9976/attachment.htm>