Within Cisco's defect tracking system a severity of 6 is used for enhancement requests.
These enhancements can be filed by TAC or anyone else within Cisco and as such are not guaranteed to be implemented in any version.
This document was created to encourage community discussion of this enhancement request. If you know of a workaround, similar feature, or other fix for the problem this enhancement attempts to address please add it in the discussion thread at the bottom of the document. Particularly good comments can and will be incorporated into the document.
A redirect performed by a Cisco or 3rd party application via CTI/QBE may use an unexpected Calling Search Space which results in unexpected or blocked call routing behavior.
A JTAPI application can explicitly specify the Calling Search Space (CSS) of a Redirect using any one of the following three values.
ADDRESS_SEARCH_SPACE This indicates that the redirect should be done using the search space of the redirect controller's address.
CALLINGADDRESS_SEARCH_SPACE This indicates that the redirect should be done using the search space of the calling address.
DEFAULT_SEARCH_SPACE This indicates that the redirect should be done using the search space that is the default for the implementation. The default is to use the calling address's search space.
Otherwise, the application can leave the CSS parameter of the Redirect to a null value which will also result in CUCM using the original calling device's CSS.
By default, when an application does not explicitly set the CSS of a Redirect to ADDRESS_SEARCH_SPACE or CALLINGADDRESS_SEARCH_SPACE, CUCM will use the original calling device's CSS.
This behavior is NOT intuitive and not known and/or understood by 99% of the customer/partner architects/administrators who design/implement these solutions. This knowledge gap is likely due to the fact that this behavior is not well documented (if documented at all).
Therefore, most Cisco Unified Communications customer/partner architects/administrators would assume that the CSS of the device which is performing the redirect (ie CTI RP, CTI Port, Agent Phone, etc) would be used rather than the CSS for the original calling device.
It seems that the application should always explicitly set the CSS within the redirect if they want to guarantee that the correct CSS is used. But when the application sets the Redirect CSS to "DEFAULT_SEARCH_SPACE" or leaves it null CUCM should have the ability to decide (via a new configuration parameter) if the original calling device CSS or redirecting device CSS is used.
This is a request for an enhancement which would allow a CUCM administrator to configure which CSS CUCM should use (original calling device CSS or redirecting device CSS) IF the CSS parameter of a Redirect is NOT explicitly set to "ADDRESS_SEARCH_SPACE" or "CALLINGADDRESS_SEARCH_SPACE" by the application. The default setting of the new configuration parameter should be set to a value which results in the current default behavior of using the CSS of the original calling device.
Some applications have a configuration parameter which be set to specify weather to use the original calling device CSS or redirecting device CSS. Otherwise, a redesign of the CUCM dial plan may be required to achieve expected call routing for CTI redirects.
Can someone explain the difference between---voice gateways?) H.3232) MGCP3) SIP (CUBE)how do you know when to use what type of configuration for your voice gateway? Also, if I am looking at VG, how do I know it is configured with MGCP, H323 or CUBE? ...
I have this xml document and try to get the data from this xml document: <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><m:CapitalCityResponse xmlns:m="http:...
Hi AllI have a cop file installation problem which is conntuniously installing so how can we cancel it ? admin:utils system upgrade cancel iscocm.preUpgradeCheck-00024.copCanceling the upgrade. Please wait...Installation of a Cisco Options Package (C...
Hi Guys, I looking for the MSI switch to enable Accessible Status Icons during the installation process or to enable it trough jabber-config.xml. Does anyone know a way to enable it without asking the user to enable it by himself in the Jab...