Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
503
Views
0
Helpful
4
Replies

Changing the number shown

ivan aguilar
Level 1
Level 1

‎09-23-2012 11:51 AM - edited ‎03-16-2019 01:20 PM

Hi!!

I have a problem with the number shown when i make a outgoing call in the end client in certain BRI

Here is what client want:

These extension, from 4114 to 4120 they want to go to PSTN only from BRI 0/3/0 and 0/3/1 and show 91751XXXX

The rest of the company need to go to PSTN from BRI 0/0/0 .... to 0/2/1 and the rest of the extension, 4110 to 4113

These extension are registered via H.323 trunk to a CUCM sited via wan in other city. so, in the router which there are installed the BRIs only is for SRST issues, and for outgoing and ingoing calls.

In the debugs shows all right the number shown, and the Calling Party transformation Mask in the CUCM is right to in the DNA, but the BRI is not right, here is the debug:

voice translation-rule 2

rule 1 /4114/ /91751XXXX/

rule 2 /4115/ /91751XXXX/

rule 3 /4116/ /91751XXXX/

rule 4 /4117/ /91751XXXX/

rule 5 /4118/ /91751XXXX/

rule 6 /4120/ /91751XXXX/

!

!

voice translation-profile PSTN1

translate called 1

!

voice translation-profile outgoing

translate calling 2

dial-peer voice 170 pots

translation-profile outgoing outgoing

preference 1

answer-address 4114-4116,4118-4120

destination-pattern 99........

  port 0/3/0

forward-digits 9

!

dial-peer voice 180 pots

translation-profile outgoing outgoing

preference 2

answer-address 4114-4116,4118-4120

destination-pattern 99........

  port 0/3/1

forward-digits 9

dial-peer voice 171 pots

translation-profile outgoing outgoing

preference 3

answer-address .

destination-pattern 99........

  port 0/0/0

forward-digits 9

!

dial-peer voice 181 pots

translation-profile outgoing outgoing

preference 4

answer-address .

destination-pattern 99........

port 0/0/1

forward-digits 9

And for choose these extension to go to PSTN to these are the dial-peer:

dial-peer voice 170 pots
translation-profile outgoing outgoing
preference 1
answer-address 4114-4116,4118-4120
destination-pattern 99........
  port 0/3/0
forward-digits 9
!
dial-peer voice 180 pots
translation-profile outgoing outgoing
preference 2
answer-address 4114-4116,4118-4120
destination-pattern 99........
  port 0/3/1
forward-digits 9

dial-peer voice 171 pots
translation-profile outgoing outgoing
preference 3
answer-address .
destination-pattern 99........
  port 0/0/0
forward-digits 9
!
dial-peer voice 181 pots
translation-profile outgoing outgoing
preference 4
answer-address .
destination-pattern 99........
port 0/0/1
forward-digits 9

Is these right or missing things?

Debug isdn q931 show the number correctly changed when i call from extension 4114-4120 but not for BRI 0/3/0 or 0/3/1 , goes for 0/0/0

Thanks!!!

Labels:
0 Helpful
4 Replies 4

ivan aguilar
Level 1
Level 1

‎09-24-2012 07:52 AM

Correction in my previous mail, these are the 3 dial-peer configurated

dial-peer voice 170 pots

translation-profile outgoing outgoing

preference 1

answer-address 4114-4116,4118-4120

destination-pattern 99........

port 0/3/0

forward-digits 9

!

dial-peer voice 180 pots

translation-profile outgoing outgoing

preference 2

answer-address 4114-4116,4118-4120

destination-pattern 99........

port 0/3/1

forward-digits 9

!

dial-peer voice 171 pots

translation-profile outgoing outgoing

preference 3

answer-address .

destination-pattern 99........

port 0/3/0

forward-digits 9

!

dial-peer voice 181 pots

translation-profile outgoing outgoing

preference 4

answer-address .

destination-pattern 99........

port 0/3/1

forward-digits 9

The ext 4117 goes to the PSTN with another number shown.

Regards!

0 Helpful

Ayodeji Okanlawon
VIP Alumni
VIP Alumni
In response to ivan aguilar

‎09-24-2012 08:44 AM

Are you saying that calls through BRI 0/3/0 do not display the xlated number?

Can you send us

debug voip ccapi inout

debug isdn q931

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

Please rate all useful posts
0 Helpful

ivan aguilar
Level 1
Level 1
In response to Ayodeji Okanlawon

‎09-27-2012 09:10 AM

Yes, thats the problem, there are 7 ext which i need to go to PSTN from BRI 0/3/0 and 0/3/1 , and need to go with the header of the client 9175172XX

The rest of the ext in the client must to go to PSTN from the rest of BRI, and with header 9177918XX

These are the debug ccapi inout

Sep 27 15:58:49.737: //34760/80C748F19F03/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x32E74E24, Interface Type=6, Destination=, Mode=0x0,
   Call Params(Calling Number=9175172XX,(Calling Name=Virginia - 4115)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=06xxxxxxxx(TON=Unknown, NPI=Unknown), Calling Translated=FALSE, 
   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=210, Call Count On=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Sep 27 15:58:49.737: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 27 15:58:49.737: :cc_get_feature_vsa malloc success
Sep 27 15:58:49.737: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 27 15:58:49.737:  cc_get_feature_vsa count is 4
Sep 27 15:58:49.737: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Sep 27 15:58:49.737: :FEATURE_VSA attributes are: feature_name:0,feature_time:891279568,feature_id:44510
Sep 27 15:58:49.737: //34761/80C748F19F03/CCAPI/ccIFCallSetupRequestPrivate:
   SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1
Sep 27 15:58:49.737: //34761/80C748F19F03/CCAPI/ccCallSetContext:
   Context=0x3521F920
Sep 27 15:58:49.737: //34760/80C748F19F03/CCAPI/ccSaveDialpeerTag:
   Outgoing Dial-peer=210
Sep 27 15:58:49.905: //34761/80C748F19F03/CCAPI/cc_api_call_proceeding:
   Interface=0x32E74E24, Progress Indication=NULL(0)
Sep 27 15:58:53.377: //34761/80C748F19F03/CCAPI/cc_api_call_alert:
   Interface=0x32E74E24, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Sep 27 15:58:53.377: //34761/80C748F19F03/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
Sep 27 15:58:53.377: //34760/80C748F19F03/CCAPI/ccCallAlert:
   Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Sep 27 15:58:53.377: //34760/80C748F19F03/CCAPI/ccCallAlert:
   Call Entry(Responsed=TRUE, Alert Sent=TRUE)
Sep 27 15:58:53.377: //34761/80C748F19F03/CCAPI/cc_api_get_called_ccm_detected:
   CallInfo(ccm detected=0)
Sep 27 15:58:53.377: //34760/80C748F19F03/CCAPI/ccConferenceCreate:
   (confID=0xFFFFFFFF, callID1=0x87C8, gcid=0-0-0-0, tag=0x0)
Sep 27 15:58:53.377: //34761/80C748F19F03/CCAPI/ccConferenceCreate:
   (confID=0xFFFFFFFF, callID2=0x87C9, gcid=0-0-0-0, tag=0x0)
Sep 27 15:58:53.377: //34760/80C748F19F03/CCAPI/ccConferenceCreate:
   Conference Id=0xFFFFFFFF, Call Id1=34760, Call Id2=34761, Tag=0x0
Sep 27 15:58:53.377: //34760/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Sep 27 15:58:53.377: cc_api_get_xcode_stream : 4819
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/cc_api_bridge_done:
   Conference Id=0x25F0, Source Interface=0x31E18618, Source Call Id=34760,
   Destination Call Id=34761, Disposition=0x0, Tag=0x0
Sep 27 15:58:53.381: //34761/80C748F19F03/CCAPI/cc_api_bridge_done:
   Conference Id=0x25F0, Source Interface=0x32E74E24, Source Call Id=34761,
   Destination Call Id=34760, Disposition=0x0, Tag=0xFFFFFFFF
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/cc_generic_bridge_done:
   Conference Id=0x25F0, Source Interface=0x32E74E24, Source Call Id=34761,
   Destination Call Id=34760, Disposition=0x0, Tag=0xFFFFFFFF
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/ccConferenceCreate:
   Call Entry(Conference Id=0x25F0, Destination Call Id=34761)
Sep 27 15:58:53.381: //34761/80C748F19F03/CCAPI/ccConferenceCreate:
   Call Entry(Conference Id=0x25F0, Destination Call Id=34760)
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/ccConferenceCreate:

Sep 27 15:58:53.381: confID:0x25F0; callEntry1 callID1:0x87C8, type:1; callEntry2 callID2:0x87C9, type:6

Sep 27 15:58:53.381: //34761/80C748F19F03/CCAPI/cc_api_caps_ind:
   Destination Interface=0x31E18618, Destination Call Id=34760, Source Call Id=34761,
   Caps(Codec=0x1, Fax Rate=0x1, Fax Version:=0, Vad=0x1,
   Modem=0x2, Codec Bytes=20, Signal Type=3)
Sep 27 15:58:53.381: //34761/80C748F19F03/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))
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/ccCallNotify:
   Data Bitmask=0x7, Call Id=34760
Sep 27 15:58:53.381: //34761/80C748F19F03/CCAPI/cc_api_get_called_ccm_detected:
   CallInfo(ccm detected=0)
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/cc_api_get_delay_xport:
   CallInfo(delay xport=FALSE)
Sep 27 15:58:53.381: //34760/80C748F19F03/CCAPI/cc_process_notify_bridge_done:
   Conference Id=0x25F0, Call Id1=34760, Call Id2=34761
Sep 27 15:58:53.649: //34760/80C748F19F03/CCAPI/cc_api_caps_ind:
   Destination Interface=0x32E74E24, Destination Call Id=34761, Source Call Id=34760,
   Caps(Codec=0x1, Fax Rate=0x2, Fax Version:=0, Vad=0x1,
   Modem=0x0, Codec Bytes=160, Signal Type=2)
Sep 27 15:58:53.649: //34760/80C748F19F03/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))
Sep 27 15:58:53.649: //34760/80C748F19F03/CCAPI/cc_api_caps_ack:
   Destination Interface=0x32E74E24, Destination Call Id=34761, Source Call Id=34760,
   Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
   Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=4207)
Sep 27 15:58:53.649: //34761/80C748F19F03/CCAPI/cc_api_caps_ack:
   Destination Interface=0x31E18618, Destination Call Id=34760, Source Call Id=34761,
   Caps(Codec=g711ulaw(0x1), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
   Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=4207)
Sep 27 15:58:53.653: //34761/80C748F19F03/CCAPI/cc_api_voice_mode_event:
   Call Id=34761
Sep 27 15:58:53.653: //34761/80C748F19F03/CCAPI/cc_api_voice_mode_event:
   Call Entry(Context=0x3521F920)
Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/cc_api_call_disconnected:
   Cause Value=16, Interface=0x31E18618, Call Id=34760
Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/ccConferenceDestroy:
   Conference Id=0x25F0, Tag=0x0
Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/ccConferenceDestroy:

Sep 27 15:58:57.677: confID:0x25F0; callEntry1 callID1:0x87C8, type:1; callEntry2 callID2:0x87C9, type:6

Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0x25F0, Source Interface=0x31E18618, Source Call Id=34760,
   Destination Call Id=34761, Disposition=0x0, Tag=0x0
Sep 27 15:58:57.677: //34761/80C748F19F03/CCAPI/cc_api_bridge_drop_done:
   Conference Id=0x25F0, Source Interface=0x32E74E24, Source Call Id=34761,
   Destination Call Id=34760, Disposition=0x0, Tag=0x0
Sep 27 15:58:57.677: //34760/80C748F19F03/CCAPI/cc_generic_bridge_done:
   Conference Id=0x25F0, Source Interface=0x32E74E24, Source Call Id=34761,
   Destination Call Id=34760, Disposition=0x0, Tag=0x0
Sep 27 15:58:57.681: //34761/80C748F19F03/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Sep 27 15:58:57.681: //34761/80C748F19F03/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Sep 27 15:58:57.681: //34761/80C748F19F03/CCAPI/cc_api_get_transfer_info:
   Transfer Number=NULL
Sep 27 15:58:57.681: //34760/80C748F19F03/CCAPI/ccCallDisconnect:
   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
Sep 27 15:58:57.681: //34760/80C748F19F03/CCAPI/ccCallDisconnect:
   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Sep 27 15:58:57.681: //34760/80C748F19F03/CCAPI/cc_api_get_transfer_info:
   Transfer Number=NULL
Sep 27 15:58:57.689: //34760/80C748F19F03/CCAPI/cc_api_get_transfer_info:
   Transfer Number=NULL
Sep 27 15:58:57.689: //34760/80C748F19F03/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x31E18618, Tag=0x0, Call Id=34760,
   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Sep 27 15:58:57.689: //34760/80C748F19F03/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Sep 27 15:58:57.689: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Sep 27 15:58:57.689: :cc_free_feature_vsa freeing 351FDFC8
Sep 27 15:58:57.689: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Sep 27 15:58:57.689:  vsacount in free is 3
Sep 27 15:58:57.881: //34761/80C748F19F03/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x32E74E24, Tag=0x0, Call Id=34761,
   Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Sep 27 15:58:57.881: //34761/80C748F19F03/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Sep 27 15:58:57.881: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Sep 27 15:58:57.881: :cc_free_feature_vsa freeing 351FD8C8
Sep 27 15:58:57.881: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

DEBUG ISDN Q931

Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0x82

                Preferred, B2

        Calling Party Number i = 0x0081, '9175172xx'

                Plan:Unknown, Type:Unknown

        Called Party Number i = 0x80, '6xxxxxxxx'

                Plan:Unknown, Type:Unknown

        Sending Complete

Sep 27 16:04:51.617: ISDN BR0/0/0 Q931: RX <- CALL_PROC pd = 8  callref = 0xCE

        Channel ID i = 0x8A

                Exclusive, B2

Sep 27 16:04:54.325: ISDN BR0/0/0 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num 4106

Sep 27 16:04:54.325: ISDN BR0/0/0 **ERROR**: CC_CHAN_GetIdleChanbri: All channels busy

Sep 27 16:04:54.329: ISDN BR0/0/1 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num 4106

Sep 27 16:04:54.329: ISDN BR0/0/1 Q931: Sending SETUP  callref = 0x004F callID = 0x90EF switch = basic-net3 interface = User

Sep 27 16:04:54.329: ISDN BR0/0/1 Q931: TX -> SETUP pd = 8  callref = 0x4F

I put that users go to PSTN dialing to get tone the 9, and the rest of the office, the 0. but to go to PSTN need to have the 0 so, never goes to BRI 0/3/0 or 0/3/1 as i highlighted before.

Has to be another way to get some ext goes to PSTN to concret BRI.

There is H.323 trunk between CUCM and the Gw, not a MGCP

0 Helpful

ivan aguilar
Level 1
Level 1
In response to ivan aguilar

‎09-28-2012 05:15 AM

Finally i resolve the issue with the CUCM, making more partition and more route pattern.

Thanks all!

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents