Can some one kindly help me to over come this situation?
I am trying to have caller ID as +14162222222 through h323 gateway, however the h323 normal behaviour as per cisco will strip + on h323 gateway. Because of this reason I get the display as 14162222222 regardless where i put the calling party number (either in route patter or in Route Group)
I found a solution to over come the issue by putting the "+" in gateway for the appropriate calling party number type.
Incoming Calling Party Unknown Number Prefix +
and it did worked, howevere it is affecting all other call going through this gateway as its natural behaviour.
Can some one please help to over come to this situation only for the perticular route pattern or in the route group level which will impact only the perticular pattern
For your info: here is what Cisco says in the document that H323 gateway will strip the + sign regardless of the service parameter
Strip + on Outbound Calls: This parameter determines whether Cisco Unified Communications Manager strips the plus sign ( + ) from the calling and called parties for outgoing calls through MGCP gateways and SIP trunks. The plus sign signifies the International access code in a complete E.164 number format. For example, NANP numbers have an E.164 global format in the format +1 214 555 1234. The + is a leading character that gets replaced by service providers in different countries with the international access code to achieve global dial plans. If your network or far-end gateway does not recognize the plus sign as a digit, be sure that this parameter is set to False, otherwise calls could get dropped if the plus sign is sent but not recognized in-network or by the receiving gateway. Valid values specify True (strip the + sign) or False (do not strip the + sign). Ensure that calls over QSIG trunks do not utilize + because it is not supported by QSIG. This parameter has no effect on H.323 outbound calls because H.323 unconditionally strips the + sign when routing outbound calls. This is a required field. Default: False
The original behavior on Gateways was to ignore and strip the leading "+". In the past it was changed to route it based on the leading "+"
However, there was changes on the latest IOS versions to start ignoring the "+" coming from the call and send the call to CCAPI without the "+".
Here is the workaround which will fix the issue. I tested out this config and this works fine inside the lab.
At global level, configure the following:
voice translation-rule 1 rule 1 /^\+/ /+/ ---> In this case configure a dummy translation rule such that whatever is received will be retained as it is ! ! voice translation-profile voip-generic translate calling
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...