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.
hi all i have problems with incoming calls from other ip phones to 8851 cisco ip phone with Newrock OM series ip pbx as the main pbx server!!outgoing calls from my 8851 ip phone are ok!!i tried reinstalling firmware but that wasn't helpful!i'm curren...
Hello, I am a final user who´s traying to find out some source of knowledge for some issues I am facing with my new Cisco 8845 3PCC connected to an Issabel PBX/Asterisk. I am coming from a “yeahlink” user experience, so It´s been quite a change in ab...
Hello, I have about 15 remote sites and 2 data centers. The data-centers both have CUBES that connect to the PSTN via provider SIP trunks. Each remote site also has an SRST. I have always assigned MTP via the MRG list for each site ...
Hi Peeps, I'm running a 12.0 cluster, and using solarwinds to monitor it. We constantly get "alerts" for phone registration rejected. I've argued with management to disable this useless alert, but they believe it to be valid. So I'm...