×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Outbound call failure log

Outbound call failure log

Outbound call failure log

(OP)
I'm running Call Manager 9.1

I have a location with Cisco 2911 router as my VoIP Gateway, running the H.323 protocol. There are 2 FXO cards and 8 POTS lines between those 2 cards. The router is configured to make outbound calls on all lines except the main line. Up until yesterday, they were working fine. Today I was told they are having problems making outbound calls - getting a busy signal. Since they only have 8 lines, my thought is that they simply had too many inbound calls and there were no free lines on which to make an outbound call. However, I need to prove that.

I did a "show log" on the router, but didn't see anything regarding call setup failure. Is there any "outbound call log" on Call Manager that can tell me why these calls failed? Is there any report in RTMT that could help me find that information? Are there any H.323 logs on the router that could tell me what happened?

Thanks for any information you can give.

RE: Outbound call failure log

Probably one of those things you will need to catch when it is happening. When it is, you can do a sh voice port sum to see what the ports are doing.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
So they tell me this happens when someone is on a conference call and they are receiving lots of calls on the main line. When someone is on a conference call, would take up one POTS line for every person connected to that conference - or would it use up just one line?

RE: Outbound call failure log

If you have outside callers, and 8 pots lines in a hunt. It will use a different line for each outside caller. So you can do 8 total outside calls.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
The Telco (AT&T) provides the hunt. The main line (line 1) will roll over to line 2 and then line 3, but that's it. The other lines should stay open. Lines 1, 2 and 3 in call manager then forward to an internal extension - 9999 to be handled. That way, no one has to manage 3 lines. That's why I wondered if a conference call could suck up the remaining 5 POTS lines. I'll bet it can. Time to test that theory...

RE: Outbound call failure log

If you are only using 3 lines for incoming then you can only have 3 incoming calls at any given time.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
Correct - but that is only for the main line. The other lines are direct dial numbers that go directly to phones.

Anyway - I found my problem: All outbound calls all want to go out the 1st port: 0/1/0; they don't use the remaining 7. What's goofy is that I configured that router to specifically deny calls going out the 1st port. I've got a bad router configuration problem - I just can't see it. Would this be a translation rule, translation profile or dial peer? Hmmmm.....

RE: Outbound call failure log

Post all 3 so that we can take a look.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
I will if Cisco is hopeless. I've opened up a TAC with them and they didn't see anything wrong with my config. They are asking me to send them several debugs from the router.

RE: Outbound call failure log

(OP)
OK - Cisco said I need to add a trunk group to push the calls out the other ports. I don't have this configured for any other location, and they admit to me this is a workaround because supposedly I'm missing a dial-peer. I'm running call manager 9.1, my gateway is a Cisco 2911 router and the protocol is H.323. Here's what I have at this location:

8 POTS lines on FXO slots (the phone numbers were changed slightly):
Main Line / Teller* 414-291-7947 0/1/0
Manager 414-291-7918 0/1/1
Supervisor 414-291-7943 0/1/2
Investing 414-291-7926 0/1/3
Banker 1 414-291-7931 0/2/0
Banker 2 414-291-7932 0/2/1
Main Line - Hunt 1* 414-291-7934 0/2/2
Main Line - Hunt 2* 414-963-4184 0/2/3

The lines with the "*" are actually in a round-robin hunt group , and the hunt is configured on AT&T's side. Each of those lines routes to an internal extension: 0739999.

The problem: All outbound calls want to use port 0/1/0. If that port is occupied by an inbound call for example, then no other outbound calls can be made.

My experiment: I made a call to the main line to occupy it, then had a user make an outbound call.
As expected, it failed. Here are the results of the trace. The relevant results are in BOLD

ct 19 13:06:19: //-1/00A5AF177800/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=0739999
----- ccCallInfo IE subfields -----
cisco-ani=0739999
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
[b]dest=96400501
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
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

Oct 19 13:06:19: //-1/00A5AF177800/CCAPI/cc_api_call_setup_ind_common:
Interface=0x226AF5BC, Call Info(
Calling Number=0739999,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=96400501(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
[b]Incoming Dial-peer=801, Progress Indication=NULL(0), Calling IE Present=TRUE,


- As you can see, somehow an outbound call is oddly using an incoming dial-peer, which cannot be correct. Furthermore, Cisco said that because there is no dial-peer for 0739999, that is why the call doesn't route properly. What's odd is that I have xxx9999 (where x = location number) lines that receive hunt calls configured for other H.323 locations, and have no issue with outbound calling whatsoever.

Below is my phone config; please tell me what I've overlooked. Maybe something is wrong on the Call Manager side?



!
! *** BEGINNING OF VOICE CONFIG ***

voice-card 0
dspfarm
dsp services dspfarm
!
!
!Call SURVIVABILITY WHEN CONNECTION TO CUCM IS LOST

voice service voip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
no h225 timeout keepalive
!

!
! CODEC PREFERNCES

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
! VOICE CLASS WITH TIMEOUT OF 2 SECONDS
! TO SWITCH FROM ONE CALL LEG TO THE NEXT

!

voice class h323 1
h225 timeout tcp establish 2
h225 timeout setup 2
call preserve
!
!
! TRANSLATION RULES TO SEND OUTBOUND CALLS TO THE
! APPROPRIATE VOICE PORTS

!
voice translation-rule 11
rule 1 /^9/ /19/
!
voice translation-rule 12
rule 1 /^9/ /29/
!
voice translation-rule 13
rule 1 /^9/ /39/
!
voice translation-rule 20
rule 1 /^9/ /49/
!
voice translation-rule 21
rule 1 /^9/ /59/
!
voice translation-rule 22
rule 1 /^9/ /69/
!
voice translation-rule 23
rule 1 /^9/ /79/
!
!
voice translation-profile 11
translate called 11
!
voice translation-profile 12
translate called 12
!
voice translation-profile 13
translate called 13
!
voice translation-profile 20
translate called 20
!
voice translation-profile 21
translate called 21
!
voice translation-profile 22
translate called 22
!
voice translation-profile 23
translate called 23
!
!
!
!
!
!
!
! BIND H323 GATEWAY TO THE LOOPBACK INTERFACE
!
interface Loopback0
ip address 172.18.73.201 255.255.255.252
!
interface Loopback1
ip address 172.18.73.205 255.255.255.252
h323-gateway voip interface
h323-gateway voip bind srcaddr 172.18.73.205
!
!
!
control-plane

! VOICEPORT CONFIGURATIONS
!
!
voice-port 0/1/0
connection plar opx 0737947
description Main Line - 414.291.7947
caller-id enable
!
voice-port 0/1/1
connection plar opx 0737918
description AIS - 414.291.7918
caller-id enable
!
voice-port 0/1/2
connection plar opx 0737943
description UB1-Consult - 414.291.7943
caller-id enable
!
voice-port 0/1/3
connection plar opx 0737926
description UB2-Consult - 414.291.7926
caller-id enable
!
voice-port 0/2/0
connection plar opx 0737931
description Supervisor - 414.291.7931
caller-id enable
!
voice-port 0/2/1
connection plar opx 0737932
description Manager - 414.291.7932
caller-id enable
!
voice-port 0/2/2
connection plar opx 0737934
description Hunt 1 from main - Hunt by AT&T
caller-id enable
!
voice-port 0/2/3
connection plar opx 0734184
description Hunt 2 from main - Hunt by AT&T
caller-id enable
!
!
!
!
!
!
mgcp profile default
!
! DEFINES THE LIST OF AVAILABLE SERVERS TO
! WHICH THE VOICE GATEWAY CAN REGISTER

!
sccp local Loopback0
sccp ccm 172.17.5.9 identifier 1 priority 1 version 4.1
sccp ccm 172.19.5.9 identifier 2 priority 2 version 4.1
sccp
!
!
! SCCP CCM GROUP BINDS THE LOOPBACK INTERFACE TO THE CUCM GROUP,
! ASSOCIATES DSP FARM PROFILE TO CUCM GROUP
! AND REGISTERS THE TRANSCODER IN CUCM.

!
sccp ccm group 1
bind interface Loopback0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register 073txcode
!
dspfarm profile 1 transcode
codec g729r8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 1
associate application SCCP
!
!
! INBOUND DIAL PEERS
! TWO DIAL PEERS FOR EACH NUMBER (131 AND 132, 201 AND 202, ETC)
! FIRST 2 DIGITS CORRESPOND WITH VOICE-PORT (I.E. 0/1/3 = 13)
! LAST DIGIT CORRESPONDS WITH CUCM SERVER PREFERENCE FOR REDUNDANCY

!
!
dial-peer voice 111 voip
translation-profile incoming 11
preference 1
answer-address 4142917918
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 121 voip
translation-profile incoming 12
preference 1
answer-address 4142917943
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 131 voip
translation-profile incoming 13
preference 1
answer-address 4142917926
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 201 voip
translation-profile incoming 20
preference 1
answer-address 4142917931
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 211 voip
translation-profile incoming 21
preference 1
answer-address 4142917932
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
!dial-peer voice 221 voip
translation-profile incoming 22
preference 1
answer-address 4142917934
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
!dial-peer voice 231 voip
translation-profile incoming 23
preference 1
answer-address 4149634184
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 112 voip
translation-profile incoming 11
preference 2
answer-address 4142917918
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 122 voip
translation-profile incoming 12
preference 2
answer-address 4142917943
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 132 voip
translation-profile incoming 13
preference 2
answer-address 4142917926
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 202 voip
translation-profile incoming 20
preference 2
answer-address 4142917931
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 212 voip
translation-profile incoming 21
preference 2
answer-address 4142917932
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad

!
dial-peer voice 222 voip
translation-profile incoming 22
preference 2
answer-address 4142917934
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 232 voip
translation-profile incoming 23
preference 1
answer-address 4149634184
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad

!
!
! GENERIC DIAL PEERS
!
dial-peer voice 801 voip
preference 1
destination-pattern 0......
progress_ind setup enable 3
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 802 voip
preference 2
destination-pattern 0......
progress_ind setup enable 3
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 901 voip
preference 1
destination-pattern [0,1-8]T
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!
dial-peer voice 902 voip
preference 2
destination-pattern [0,1-8]T
session target ipv4:172.19.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad
!

!
!
! OUTBOUND DIAL PEERS WHICH ALIGN WITH TRANSLATION RULES AND PROFILES
! TO SEND OUTBOUND CALLS OUT THE PROPER VOICE PORT

!
!
dial-peer voice 10 pots
destination-pattern 9T
port 0/1/0
!
dial-peer voice 11 pots
destination-pattern 19T
port 0/1/1
!
dial-peer voice 12 pots
destination-pattern 29T
port 0/1/2
!
dial-peer voice 13 pots
destination-pattern 39T
port 0/1/3
!
dial-peer voice 20 pots
destination-pattern 49T
port 0/2/0
!
dial-peer voice 21 pots
destination-pattern 59T
port 0/2/1
!
dial-peer voice 22 pots
destination-pattern 69T
port 0/2/2
!
dial-peer voice 23 pots
destination-pattern 79T
port 0/2/3
!
!
! RTP TIMEOUT TO CLEAR HANGING CONNECTIONS
! RANGE FROM 180 TO 1800. DEFAULT IS 1200.


gateway
timer receive-rtp 600
!
!
!
gatekeeper
shutdown
!
! FOR CUCM FALLBACK MODE FOR SRST
! WITH MAX OF 42 PHONES REGISTERED

!
call-manager-fallback
secondary-dialtone 9
max-conferences 4 gain -6
transfer-system full-consult
timeouts interdigit 4
ip source-address 172.18.73.205 port 2000
max-ephones 42
max-dn 144 dual-line preference 2
application default
voicemail 18666924371
call-forward busy 18666924371
call-forward noan 18666924371 timeout 10
!
!




RE: Outbound call failure log

Personally, I would get rid of this:

voice translation-rule 11
rule 1 /^9/ /19/
!
voice translation-rule 12
rule 1 /^9/ /29/
!
voice translation-rule 13
rule 1 /^9/ /39/
!
voice translation-rule 20
rule 1 /^9/ /49/
!
voice translation-rule 21
rule 1 /^9/ /59/
!
voice translation-rule 22
rule 1 /^9/ /69/
!
voice translation-rule 23
rule 1 /^9/ /79/
!


And use your outbound dial-peers like this:


dial-peer voice 10 pots
destination-pattern 9T
port 0/1/0
preference 0
!
dial-peer voice 11 pots
destination-pattern 9T
port 0/1/1
preference 1

So on and so forth.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
gnrslash4life: Understood. However, this is a standard config that we use across all 30+ locations, so I don't want to get into one-off's all over the place. Will the dial-peer preference options work even if I don't remove the voice-translation rules? I would've thought we needed to keep those rules.

RE: Outbound call failure log

Understandable.

I looked more closely at your debug and config this time and dial-peer 801 is definitely the closest match. You dont have inbound/outbound dial-peers. You have dial-peers that can do inbound/outbound. Your translations aren't even coming into play according to that debug output.

I ran into an issue recently where I had 2 CUBE routers with the same dial-peer config and for some reason 1 was having routing issues and the other wasn't. My point is, same configs can do different things if they are too generic in matching.

To answer your question, yes you could leave them in.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
gnrslash4life. Thank you. You've just shone a bright light into the cloud of my confusion: "You don't have inbound/outbound dial-peers. You have dial-peers that can do inbound/outbound" That is the answer to the question I didn't know how to ask.

Oh wise one....How do I understand the difference between dial-peers that can do inbound/outbound and true inbound/outbound dial peers?

Also - Can you show me how dial-peer 801 is the closest match? In my previous debug, the user called an external number: 96400501 ("9" of course is an outside line). The only way I know how to test is to type in the following: test voice translation rule ## 96400501.

Below are 2 outputs from the router:

073-Glendale#test voice translation-rule 11 96400501
Matched with rule 1
Original number: 96400501 Translated number: 196400501
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

073-Glendale#test voice translation-rule 12 96400501
Matched with rule 1
Original number: 96400501 Translated number: 296400501
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

However, it doesn't show me what dial-peer is being used. How do I walk through a config and see what dial-peer is being used?

RE: Outbound call failure log

I am going to take some of your actual dial-peers and use them as an example:

dial-peer voice 100 voip
preference 1
incoming called-number .
progress_ind setup enable 3
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad

You could specifically use this to send all outside incoming calls to your CM.


801 is the closest match because while your translations are correct, they are not assigned to any dial-peer. So would match 801 with 10 being second because it sees .... wildcards more precise than T as a wildcard.

You can use "sh call active voice sum" to show you your call legs and what dial-peer they are using.








Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

RE: Outbound call failure log

(OP)
"....while your translations are correct, they are not assigned to any dial-peer." Help me understand, as I'm confused...

All of the dial-peers should reference the associated translation profile, as well as the answer-address/port. I would think these would match up first before matching up with the Generic Dial Peers. Below are the related ones for voice-port 0/1/1. What is not matched? I was using these Cisco docs as a reference:
http://www.cisco.com/c/en/us/support/docs/voice/ca...


Voice Port Config:
voice-port 0/1/1
connection plar opx 0737918
description AIS - 414.291.7918
caller ID enable

Outbound Dial Peer:
dial-peer voice 11 pots
destination-pattern 19T
port 0/1/1

Translation Rule and Profile:
voice translation-rule 11
rule 1 /^9/ /19/

voice translation-profile 11
translate called 11

Inbound Dial Peer:
dial-peer voice 111 voip
translation-profile incoming 11
preference 1
answer-address 4142917918
session target ipv4:172.17.5.9
voice-class codec 1
voice-class h323 1
dtmf-relay cisco-rtp h245-signal h245-alphanumeric
no vad


RE: Outbound call failure log

(OP)
Really stupid question: Does it matter what ORDER the peers and translation profiles appear in the router config? For instance, in my router config the Generic Dial Peers are listed before the outbound dial peers.

RE: Outbound call failure log

Appear? No. However dial-peer 100 is going to be before dial-peer 200. Doesn't matter what order you put them in.

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close