While every call has two dial-peers for the incoming and outgoing call legs, in the case of CME the incoming call leg for an outbound call for an IP Phone would be the POTS dial-peer of that ePhone DN. All of the items I described above are doable on a single VoIP dial-peer selected as the outbound call leg. I believe CME will generate PAI if you enable it using the command I specified above; however, that is a really old platform and I'll admit that my recollection of which features existed in those IOS versions is fading. You comment about incoming calls needing two, I presume, VoIP dial-peers doesn't make sense either. The call should be routed based on the Request URI header, not the To header so you should not need a SIP Profile for that. Note that current versions of IOS do support applying a SIP Profile on an incoming dial-peer; however, the ISR G1 hardware falls well short of supporting those releases. https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/118825-technote-sip-00.html#anc7 ... View more

CUCM will do what you’re asking for a proper cold/blind/direct transfer. For a warm/consult transfer the calling party information during the consult step is the CUCM DN, not the original calling party. I’m not aware of a setting to cleanly accomplish what you want out of the box. ... View more

For a warm transfer from the agent DN son CUCM, I believe the call path between you and the vendor is going to need support for Connected Party Information for this to happen. You can ask your carrier if they support this, either as a chargeable feature or if they will pass it through to the far-end by default. A TLS-protected SIP Trunk from CUBE via the internet would be another option.   The problem here will be that the consult leg from CUCM to CUBE will not include the original calling party info, depriving you of “fixing” this with a SIP Profile by overwriting/copying the value.   A very long shot idea might be a TCL script using the Session ID header to lookup the original calling info since that header _should_ be the same as the original call leg, but this is pretty advanced. TCL also has a meaningful impact on CUBE sizing. ... View more

If your CUCM cluster only services a single national fixed-length numbering plan, such as the NANP, you can create Application Dial Rules. These are processed client-side before the SIP INVITE is sent to CUCM. https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_6_1/ccmcfg/bccm-861-cm/b03adial.html   Because those rules are cluster-wide you usually cannot use them for clusters servicing multiple countries. In that scenario your only option is a separate CSS/Partitions/Route Patterns that do not require the off-bet access prefix. Be aware that Jabber is not exempt from the T.302 inter-digit time-out of CCM DigitAnalysis. ... View more

1. Either a voice translation-profile for the called number or the classic strip/forward digit commands would get this done. 2 & 3. What is the call control platform behind CUBE? CUCM? The easier approach is to have the source set the PAI header for you. CUCM supports this on the SIP Trunk and CUBE supports it under voice service voip, sip, asserted-id pai. 4. This likely warrants a SIP Profile since a translation rule/profile for calling number would likely impact FROM, PAI, and RPID. Cisco has a tool to test syntax with: https://cway.cisco.com/tools/SipProfileTest/ ... View more

You define the registrar and credentials under sip-ua and then point the dial-peer session target registrar. Here are a few search results: https://community.cisco.com/t5/collaboration-voice-and-video/handle-cube-registration-authentication-like-a-boss/ba-p/3660492 https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/voice_cube_-_ent/cube-ent_wip/cube_tips/cube_sipsip/fts-11097_boron.pdf ... View more

Unfortunately, Nuance remains the only supported vendor: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/uccxcompat12_0_1.html#ASR_and_TTS Of course, you could try pulling logs from one or both platforms to see if you can spot an issue. Hopefully this is a lab scenario where you can tinker and learn; I would have heartburn about a production deployment knowing Cisco won’t support it. ... View more

Did you read this log yourself and draw any conclusions or hypothesis on what is happening? It appears the first outbound call begins on line 4339 from CUCM 10.111.182.50 to CUBE 10.111.182.58, calling number 5601, called number 0359108974, call ID a68aa980-d061fae8-4c6690-32b66f0a. This appears to match incoming dial peer 1000 and outgoing dial peer 2011. CUBE sends that call to the ITSP starting on line 4584 from 14.177.64.96 to 125.235.28.182, calling number 02466648888, called number 0359108974, call ID D6AE4C7F-8FDE11E9-A1BAAAED-A173211D. The ITSP responds on line 4655 with a 100 Trying so we know they got the INVITE. This message was received at 02:31:25.892. The next message in the ITSP-facing SIP dialog is received on line 6709 at 02:33:25.846, exactly two minutes later, as a 408 Request Timeout. CUBE relays this fatal error response back to CUCM. Looking solely at this debug I would say your carrier owes you an explanation for where the remaining provisional responses are (e.g. 180 Ringing) as well as the 200 OK if the call actually connected. The next thing you would have owed that dialog is an ACK (assuming the missing 180 message didn't require PRACK) after receiving the 200 OK; presumably the 408 error is them giving up on that expected response from you. Since you have a working example to compare with that may offer additional clues. ... View more

You did not mention this was intermittent on the same phone. If that's the case you would want to pull either console logs from the phone, a packet capture, or both to understand what's going on. You can read more about ITL operations here: https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116232-technote-sbd-00.html ... View more

HTTPS will fail unless you use a proper DNS FQDN; certificates do not include the IP address in the CN or SAN. Do the ITL thumbprints match between a working and non-working phone? Does “show itl” work from the TFTP nodes? Are the TVS server certificates not expired and present in the ITL? ... View more

This is a technical support forum. You should direct quoting-related questions to your Cisco partner; they will need to transact the order anyway. ... View more

The most likely cause is the audio codec being used for the call isn’t supported by MediaSense. That would include Opus, G.722.1 or G.722.2 (aka AMR-WB). There is an Enterprise Parameter to disable Opus for recording-enabled devices. The equivalent parameter for G.722 does not include the annexes such as .1 or .2 - an oversight on the developer’s part. To avoid using those you would need to punt them to the bottom of the Audio Codec Preference List and change the clusterwide default list under Service Parameters. ... View more

You should not need MTP Required as CUCM should detect the mismatch between CCX CTI Port and the codec offered by the carrier to invoke the MTP automatically. As for the inability to call out when the MTP is engaged, the only way to troubleshoot this is to look at logs. Personally, I would start at CUBE since it will let you see both “sides” of the SIP dialog and who decided to tear down the call. If you see the call never made it to CUBE or that CUCM decides to abort you would want to move your attention to the CUCM SDI/SDL traces. ... View more