Re: Translation outgoing not work

akram.root · ‎12-22-2020

Hello all,

I have a configured a CUCM with Two gateway ISR 4321 with mode H.323.

I have on each Gateway ISR4321 one BRI (line not grouped), i configured the two gateway are fine , on the incoming call work fine each line have their extention , but on the outgoing translation the call start work just by the BRI on the gateway 1.

How can i make outgoing call translation by each gateway .

Best regards

Akram

Nithin Eluvathingal · ‎12-22-2020

can you take the debug when making outside calls and share it here

akram.root · ‎12-22-2020

Thank you for your reply,

Here you are :

ISR4321-1#
ISR4321-1#deb
ISR4321-1#debug voi
ISR4321-1#debug voic
ISR4321-1#debug voice cc
ISR4321-1#debug voice ccapi inou
ISR4321-1#debug voice ccapi inout
voip ccapi inout debugging is on
ISR4321-1#ter
ISR4321-1#terminal moni
ISR4321-1#terminal monitor
ISR4321-1#
ISR4321-1#
Dec 22 13:54:46.337: //-1/80DCB33E1000/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=
----- ccCallInfo IE subfields -----
cisco-ani=999
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=0638884592
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Dec 22 13:54:46.337: //-1/80DCB33E1000/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7F81B62C8E50, Call Info(
Calling Number=999,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=0638884592(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=0, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=170
Dec 22 13:54:46.337: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.337: :cc_get_feature_vsa malloc success
Dec 22 13:54:46.337: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.337: cc_get_feature_vsa count is 1
Dec 22 13:54:46.337: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.337: :FEATURE_VSA attributes are: feature_name:0,feature_time:140195106164244,feature_id:170
Dec 22 13:54:46.337: //170/80DCB33E1000/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=999(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=0638884592(TON=Unknown, NPI=Unknown))
Dec 22 13:54:46.338: //170/80DCB33E1000/CCAPI/cc_process_call_setup_ind:
Event=0x7F81B782AB38
Dec 22 13:54:46.338: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 0638884592
Dec 22 13:54:46.338: //170/80DCB33E1000/CCAPI/ccCallSetContext:
Context=0x7F81BFBC3DD8
Dec 22 13:54:46.338: //170/80DCB33E1000/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 170 with tag 0 to app "_ManagedAppProcess_Default"
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=6, Params=0x7F81BFBCF398, Progress Indication=ORIGINATING SIDE IS NON ISDN(3)
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCheckClipClir:
In: Calling Number=999(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCheckClipClir:
Out: Calling Number=999(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCallSetupRequest:
Destination Pattern=0[567]T, Called Number=0638884592, Digit Strip=TRUE
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/ccCallSetupRequest:
Calling Number=999(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=0638884592(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=, Final Destination Flag=TRUE,
Guid=80DCB33E-3831-9148-1000-61010AD41606, Outgoing Dial-peer=6
Dec 22 13:54:46.339: //170/80DCB33E1000/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=
----- ccCallInfo IE subfields -----
cisco-ani=999
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=0638884592
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Dec 22 13:54:46.340: //170/80DCB33E1000/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x7F81BADEBAB8, Interface Type=6, Destination=, Mode=0x0,
Call Params(Calling Number=999,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=0638884592(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=6, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Dec 22 13:54:46.340: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.340: :cc_get_feature_vsa malloc success
Dec 22 13:54:46.340: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.340: cc_get_feature_vsa count is 2
Dec 22 13:54:46.340: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Dec 22 13:54:46.340: :FEATURE_VSA attributes are: feature_name:0,feature_time:140195106164020,feature_id:171
Dec 22 13:54:46.340: //171/80DCB33E1000/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1
Dec 22 13:54:46.340: //171/80DCB33E1000/CCAPI/ccCallSetContext:
Context=0x7F81BFBCF318
Dec 22 13:54:46.340: //170/80DCB33E1000/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=6
Dec 22 13:54:46.358: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/2/0:0, TEI 69 changed to up
Dec 22 13:54:46.876: //171/80DCB33E1000/CCAPI/cc_api_call_proceeding:
Interface=0x7F81BADEBAB8, Progress Indication=NULL(0)
Dec 22 13:54:50.276: //171/80DCB33E1000/CCAPI/cc_api_call_alert:
Interface=0x7F81BADEBAB8, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Dec 22 13:54:50.276: //171/80DCB33E1000/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccCallAlert:
Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccCallAlert:
Call Entry(Responsed=TRUE, Alert Sent=TRUE)
Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/cc_api_get_called_ccm_detected:
CallInfo(ccm detected=0)
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccConferenceCreate:
(confID=0xFFFFFFFFFFFFFFFF, callID1=0xAA, gcid=0-0-0-0, tag=0x0)
Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/ccConferenceCreate:
(confID=0xFFFFFFFFFFFFFFFF, callID2=0xAB, gcid=0-0-0-0, tag=0x0)
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccConferenceCreate:
Conference Id=0xFFFFFFFFFFFFFFFF, Call Id1=170, Call Id2=171, Tag=0x0
Dec 22 13:54:50.277: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.277: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/cc_api_bridge_done:
Conference Id=0x34, Source Interface=0x7F81B62C8E50, Source Call Id=170,
Destination Call Id=171, Disposition=0x0, Tag=0x0
Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/cc_api_bridge_done:
Conference Id=0x34, Source Interface=0x7F81BADEBAB8, Source Call Id=171,
Destination Call Id=170, Disposition=0x0, Tag=0xFFFFFFFFFFFFFFFF
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/cc_generic_bridge_done:
Conference Id=0x34, Source Interface=0x7F81BADEBAB8, Source Call Id=171,
Destination Call Id=170, Disposition=0x0, Tag=0xFFFFFFFFFFFFFFFF
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x34, Destination Call Id=171)
Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x34, Destination Call Id=170)
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/ccConferenceCreate:

Dec 22 13:54:50.277: confID:0x34; callEntry1 callID1:0xAA, type:1; callEntry2 callID2:0xAB, type:6

Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/cc_api_caps_ind:
Destination Interface=0x7F81B62C8E50, Destination Call Id=170, Source Call Id=171,
Caps(Codec=0x1, Fax Rate=0x1, Fax Version:=0, Vad=0x1,
Modem=0x2, Codec Bytes=20, Signal Type=3)
Dec 22 13:54:50.277: //171/80DCB33E1000/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Dec 22 13:54:50.277: //170/80DCB33E1000/CCAPI/cc_api_get_delay_xport:
CallInfo(delay xport=FALSE)
Dec 22 13:54:50.278: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.278: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.278: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.278: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.278: //170/80DCB33E1000/CCAPI/cc_process_notify_bridge_done:
Conference Id=0x34, Call Id1=170, Call Id2=171
Dec 22 13:54:50.302: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.302: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.303: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.303: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.303: //170/80DCB33E1000/CCAPI/cc_api_caps_ind:
Destination Interface=0x7F81BADEBAB8, Destination Call Id=171, Source Call Id=170,
Caps(Codec=0x10000000, Fax Rate=0x80, Fax Version:=0, Vad=0x1,
Modem=0x0, Codec Bytes=160, Signal Type=2)
Dec 22 13:54:50.304: //170/80DCB33E1000/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Dec 22 13:54:50.304: //170/80DCB33E1000/CCAPI/cc_api_caps_ack:
Destination Interface=0x7F81BADEBAB8, Destination Call Id=171, Source Call Id=170,
Caps(Codec=g722-64(0x10000000), Fax Rate=FAX_RATE_14400(0x80), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6583)
Dec 22 13:54:50.304: //170/80DCB33E1000/CCAPI/cc_api_caps_ind:
Destination Interface=0x7F81BADEBAB8, Destination Call Id=171, Source Call Id=170,
Caps(Codec=0x10000000, Fax Rate=0x80, Fax Version:=0, Vad=0x1,
Modem=0x0, Codec Bytes=160, Signal Type=2)
Dec 22 13:54:50.304: //170/80DCB33E1000/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Dec 22 13:54:50.304: //170/80DCB33E1000/CCAPI/cc_api_caps_ack:
Destination Interface=0x7F81BADEBAB8, Destination Call Id=171, Source Call Id=170,
Caps(Codec=g722-64(0x10000000), Fax Rate=FAX_RATE_14400(0x80), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6583)
Dec 22 13:54:50.304: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.304: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.304: //171/80DCB33E1000/CCAPI/cc_api_caps_ack:
Destination Interface=0x7F81B62C8E50, Destination Call Id=170, Source Call Id=171,
Caps(Codec=g722-64(0x10000000), Fax Rate=FAX_RATE_14400(0x80), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6583)
Dec 22 13:54:50.304: //171/80DCB33E1000/CCAPI/cc_api_caps_ack:
Destination Interface=0x7F81B62C8E50, Destination Call Id=170, Source Call Id=171,
Caps(Codec=g722-64(0x10000000), Fax Rate=FAX_RATE_14400(0x80), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=6583)
Dec 22 13:54:50.306: //171/80DCB33E1000/CCAPI/cc_api_voice_mode_event:
Call Id=171
Dec 22 13:54:50.306: //171/80DCB33E1000/CCAPI/cc_api_voice_mode_event:
Call Entry(Context=0x7F81BFBCF318)
Dec 22 13:54:50.307: //171/80DCB33E1000/CCAPI/cc_api_voice_mode_event:
Call Id=171
Dec 22 13:54:50.307: //171/80DCB33E1000/CCAPI/cc_api_voice_mode_event:
Call Entry(Context=0x7F81BFBCF318)
Dec 22 13:54:50.308: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.308: cc_api_get_xcode_stream : 4983
Dec 22 13:54:50.308: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:50.308: cc_api_get_xcode_stream : 4983
Dec 22 13:54:54.622: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:54.622: cc_api_get_xcode_stream : 4983
Dec 22 13:54:54.622: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:54.622: cc_api_get_xcode_stream : 4983
Dec 22 13:54:54.626: //170/80DCB33E1000/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x7F81B62C8E50, Call Id=170
Dec 22 13:54:54.626: //170/80DCB33E1000/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
Dec 22 13:54:54.626: //170/80DCB33E1000/CCAPI/ccConferenceDestroy:
Conference Id=0x34, Tag=0x0
Dec 22 13:54:54.626: //170/80DCB33E1000/CCAPI/ccConferenceDestroy:

Dec 22 13:54:54.626: confID:0x34; callEntry1 callID1:0xAA, type:1; callEntry2 callID2:0xAB, type:6

Dec 22 13:54:54.627: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:54.627: cc_api_get_xcode_stream : 4983
Dec 22 13:54:54.627: //170/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Dec 22 13:54:54.627: cc_api_get_xcode_stream : 4983
Dec 22 13:54:54.627: //170/80DCB33E1000/CCAPI/cc_api_bridge_drop_done:
Conference Id=0x34, Source Interface=0x7F81B62C8E50, Source Call Id=170,
Destination Call Id=171, Disposition=0x0, Tag=0x0
Dec 22 13:54:54.627: //171/80DCB33E1000/CCAPI/cc_api_bridge_drop_done:
Conference Id=0x34, Source Interface=0x7F81BADEBAB8, Source Call Id=171,
Destination Call Id=170, Disposition=0x0, Tag=0x0
Dec 22 13:54:54.627: //170/80DCB33E1000/CCAPI/cc_generic_bridge_done:
Conference Id=0x34, Source Interface=0x7F81BADEBAB8, Source Call Id=171,
Destination Call Id=170, Disposition=0x0, Tag=0x0
Dec 22 13:54:54.629: //171/80DCB33E1000/CCAPI/ccCallDisconnect:
Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Dec 22 13:54:54.629: //171/80DCB33E1000/CCAPI/ccCallDisconnect:
Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Dec 22 13:54:54.629: //171/80DCB33E1000/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Dec 22 13:54:54.630: //170/80DCB33E1000/CCAPI/ccCallDisconnect:
Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
Dec 22 13:54:54.630: //170/80DCB33E1000/CCAPI/ccCallDisconnect:
Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Dec 22 13:54:54.630: //170/80DCB33E1000/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Dec 22 13:54:54.662: //170/80DCB33E1000/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Dec 22 13:54:54.663: //170/80DCB33E1000/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x7F81B62C8E50, Tag=0x0, Call Id=170,
Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Dec 22 13:54:54.663: //170/80DCB33E1000/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Dec 22 13:54:54.663: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Dec 22 13:54:54.663: :cc_free_feature_vsa freeing 7F81B7808E08
Dec 22 13:54:54.663: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Dec 22 13:54:54.663: vsacount in free is 1
Dec 22 13:54:54.876: //171/80DCB33E1000/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x7F81BADEBAB8, Tag=0x0, Call Id=171,
Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Dec 22 13:54:54.876: //171/80DCB33E1000/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Dec 22 13:54:54.876: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Dec 22 13:54:54.876: :cc_free_feature_vsa freeing 7F81B7808D28
Dec 22 13:54:54.876: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Dec 22 13:54:54.876: vsacount in free is 0

Roger Kallberg · ‎12-22-2020

Please post your configuration of the BRI ports and dial peers on both gateways and please explain the call flow you have in as much details as you can for us to understand that call scenario to be able to give you advice.

The debug provided shows that you hit dial peer 0 inbound, “Incoming Dial-peer=0”, this is never a good thing. You should make sure you have created the needed configuration for this to not happen. Have a look at this document for how dial peer matching and number manipulation works. https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html

Nithin Eluvathingal · ‎12-22-2020

I can see calling number 999, are you trying to translate 999 to something else ?? . as @Roger Kallberg mentioned, post your configuration and provide bit more details of call flow.

Roger Kallberg · ‎12-22-2020

To do translation at the gateway level you configure voice translation rules and profiles on the gateway itself. Please post the configuration you have for this so that we can verify it.

Also please give a little bit of more details on the call flow at hand, so that we can understand the use case you have.

akram.root · ‎12-22-2020

Thank you for your reply ,

attached you find the configuration of two gateway .

My goal is to translate outgoing call by each extension

the problem taht i have is when i do a outgoing call , the call start just by gateway isr1 .

Best regards

Nathan Gageby · ‎12-22-2020

I see you are attempting to apply the translation here:

dial-peer voice 6 pots
description ## appels vers national ##
translation-profile outgoing Appels_Sortants
destination-pattern 0[567]T
progress_ind setup enable 3
progress_ind alert enable 8
direct-inward-dial
port 0/2/0
forward-digits all

This calls the profile here:

voice translation-profile Appels_Sortants
translate calling 2

and then this rule:

voice translation-rule 2
rule 1 /555/ /0537635766/

The dial-peers here are less than ideal. I am not sure I totally understand your issue but I would recommend you consider using the ^ at the beginning of the matched string and the $ at the end to limit overlap. I would recommend you turn off all the debugging and just debug the translation rules. Then when the call connects use the command show call active voice compact or show call active voice brief to identify the dial-peer used by each call leg.

to rule out a dial-peer matching issue I would make a dial-peer that is an exact match for the test number and is an outgoing only.

Example:

dial-pee voi 8888 pots

description ## appels dial-peer verification ##
translation-profile outgoing Appels_Sortants
destination-pattern ^0638884592$
progress_ind setup enable 3
progress_ind alert enable 8
port 0/2/0

forward-digits all

This should match the number from your sample and allow you to eliminate a dial-peer matching issue as the trouble. If you want to send the debug of just the translation profile and the show call active command we can investigate further. If this helps please rate.

Nithin Eluvathingal · ‎12-22-2020

your calling number is 999 and outgoing dial-peer match is 6. The translation profile applied on dial-peer 6 is Appels_Sortants. But this rule has no translation defined to match 999.

dial-peer voice 6 pots
description ## appels vers national ##
translation-profile outgoing Appels_Sortants
destination-pattern 0[567]T
progress_ind setup enable 3
progress_ind alert enable 8
direct-inward-dial
port 0/2/0

voice translation-rule 2
rule 1 /555/ /0537635766/ >>> add another rule to match 999.

Roger Kallberg · ‎12-22-2020

To sort out the problem with using dial peer 0 inbound from CUCM add this dial peer.

dial-peer voice 10 voip
description Use for inbound calls from CUCM

incoming called-number .

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

To match both directory numbers in your translation rule modify it to this.

voice translation-rule 2

rule 1 /^555$/ /0537635766/

rule 2 /^999$/ /0537635777/

Apart from this you have this command on all your outbound POTS dial peers, direct-inward-dial. This is only needed on the inbound POTS dial peer. This is not related to the problem at hand, but it would be good if you remove it from the dial peers where it’s not needed.

akram.root · ‎12-23-2020

Hello all,

I have tested your recommendation but the problem still perssist , when i start a call by iphone extenssion 999 , the call outgoing start by line 1 : 0537635766 here you find in attachement the debug.

For more clarification i use two gateway ISR4321 , each one have a BRI .

ISR 1 : BRI with line : 0537635766

ISR2: BRI with line : 0537635777

Best regards

Roger Kallberg · ‎12-23-2020

So you want to have calls for the 999 DN to use the 2:nd gateway as the first option and the other way around for DN 555? If so that’s really not what you originally asked about.

That would be really easy, you’d have to create 2 route groups for that, one with GW1 as the 1:st and GW2 as the 2:nd in the list and set with Top Down processing. Then you create another one that is set as the reverse. For the route pattern that you use for egress calls select it to use the route list for standard local route list. Then have each of the phones put into separate device pools that is set to use one of the two RGs you previously created, for the DP used by the phone that has DN 555 set the RG that has GW1 as the first option and the opposite for the DP that is for the phone with DN 999.

Nithin Eluvathingal · ‎12-23-2020

what I understood is when making calls from 999, if it use gateway 1 the calling number should be translated to 0537635766 and if going through gateway 2 it should be translated to 0537635777

Use below configuration

Gateway 1

voice translation-rule 2
rule 1 /555/ /0537635766/

rule 2 /^999$/ /0537635766/

akram.root · ‎12-23-2020

Hello all Thank you for your reply,

My goal is to translate outgoing call for 555 to 0537635766 .

And translate outgoing call for 999 to 0537635777

I have configured two gateway with route list : isr1 and isr2 on mode top down.

When i make a call with extension 999 the call outgoing by 0537635766 always on isr1.

Roger Kallberg · ‎12-23-2020

If you have the appropriate translation configuration in both gateways to handle both DNs and you still don’t get the proper calling number it’s likely the telco that masks the calling number to the one that belongs to the circuit where call egress. This is very common that telcos does that. You can easily verify that this is the case if you look at the output of a debug isdn q931. If you see that you send the expected numbers for each DN to your telco, but you get the calling number of the circuit the telco is changing the number.

If you have a route list with top down processing set and GW1 is first in list what does make you think that the call from the DN 999 would use GW2? For that to happen you need to send the call out via configuration that has GW2 as the first option.