I’m glad to hear that you found a workaround. That is not expected behavior though. Assuming you do not see an existing defect published for the firmware version you are running, I suggest opening a TAC case to get this fixed/patched - for yourself and other customers. ... View more

I don’t recall a feature introduction in CUCM that would intentionally change this behavior. Does the CUCM SDL trace show the SCCP event arriving from the phone? If not, does the phone console log recognize the button press? Those answers would help you decide whether to open a TAC case against the phone firmware or CUCM itself. ... View more

Jabber multi-line has both client and server requirements. https://community.cisco.com/t5/collaboration-voice-and-video/jabber-multiline-is-here/ta-p/3643644 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_0/cjab_b_feature-configuration-for-cisco-jabber-120/cjab_b_feature-configuration-for-cisco-jabber-120_chapter_011.html#reference_08DB2E9280C0A8ABF98E1B329604E883 ... View more

That SFTP server is not supported. You really shouldn’t be relying on that for a production system. Supported options are OpenSSH (ie any Linux box), Cygwin, or Titan FTP. https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/intelligence_suite/intelligence_suite_1105/maintain_and_operate/guide/CUIC_BK_A573F861_00_administration-console-user-guide-for/CUIC_BK_A573F861_00_administration-console-user-guide-for_chapter_01001.html ... View more

Not exactly. UCCX would still require a CUCM cluster and at least agent phones registered to that cluster to function. The Local Gateway option for Webex Calling would allow you to route calls internally between the two systems though as well as reuse your existing PSTN circuit and DIDs. ... View more

This information is easily accessible through a Google search. Here’s the first result: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_compatibility/matrix/pcce_11_6_comp_matrix.html ... View more

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