Re: Takes 3 calls to connect

Nathan Hardman · ‎06-07-2011

Hi Cisco Community,

Its me again

We have a customer who is saying that it is taking 3 times for someone to make a call and the first 3 times the phones keep beeping, similar to engaged tone, straight after dialling number.

Any Idea's

Thanks

Nathan

This is a CME installation

paolo bevilacqua · ‎06-07-2011

Suppose that you are asked this same question, without any additonal detail like "who calls who ?" "what type of lines", "when it started happening". And of course, no debugs of any kind.

Would you be able to help ? Or you think in CME there's a command like "fix-one-third-calls-failure" ?

Nathan Hardman · ‎06-07-2011

Hi Paolo,

Your sarcasam is not need in my discussions as im looking for some help and guidence to resolve and issue, If only there was a command on the CME.

I understand that i should of provided more information but regarding debugs i don't know what debugs people require.

The phones use ISDN.

It is an issue for all phones

Internal/Inbound no issues what so ever

Outbound this happens all the time i.e every number.

It started happening recently

i have found this error in the logs but could be something seperate.

8132977: Jun 7 2011 14:41:57: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:06/07/2011 14:41:33.185,cgn:5607,cdn:,frs:0,fid:224675,fcid:12B42AF3904B11E08181F47ED6CE3077,legID:35687,bguid:12B42AF3904B11E08181F47ED6CE3077

8132978: Jun 7 14:41:57.017: voice_file_acct_initiate_dump_to_file: Both file modes have failed in earlier attempt

8132979: Jun 7 14:41:57.017: Use file-acct reset when the problem is recovered

paolo bevilacqua · ‎06-07-2011

What you call sarcasm is due to the totally incomplete and unprofessional manner in which have presented the problem in your first post and seems just natural - try reading you post again and honestly answer my question instead of pointing to the way it's written ?

Now regarding your case. Still insufficient information. ISDN PRI/BRI, or what ? Need to see "debug isdn q931" for failed calls. Has anybody touched configuration ? Has a reload been tried?

Nathan Hardman · ‎06-07-2011

Hi Paolo,

Its ISDN PRI

I don't believe anybody has touched the config.

No a reload hasn't been tried (Would you advise this first?)

Here is the Debug;

YSP-CCB-CME01#sho log

Syslog logging: enabled (0 messages dropped, 4 messages rate-limited,

0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 5825732 messages logged, xml disabled,

filtering disabled

Monitor logging: disabled

Buffer logging: level debugging, 7038143 messages logged, xml disabled,

filtering disabled

Logging Exception size (4096 bytes)

Count and timestamp logging messages: disabled

Persistent logging: disabled

Trap logging: level notifications, 318813 message lines logged

Logging to 10.17.11.10 (udp port 514, audit disabled,

authentication disabled, encryption disabled, link up),

318813 message lines logged,

0 message lines rate-limited,

0 message lines dropped-by-MD,

xml disabled, sequence number disabled

filtering disabled

Log Buffer (4096 bytes):

smitBytes 0, ReceivePackets 0, ReceiveBytes 0

8137207: Jun 7 2011 15:34:41: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:06/07/2011 15:34:34.825,cgn:5619,cdn:,frs:0,fid:225170,fcid:7B1BDDCA905211E0867AF47ED6CE3077,legID:35869,bguid:7B1BDDCA905211E0867AF47ED6CE3077

8137208: Jun 7 15:34:41.345: voice_file_acct_initiate_dump_to_file: Both file modes have failed in earlier attempt

8137209: Jun 7 15:34:41.345: Use file-acct reset when the problem is recovered

8137210: Jun 7 15:34:53.337: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 01212135619

8137211: Jun 7 15:34:53.337: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x6CEA callID = 0x8670 switch = primary-net5 interface = User

8137212: Jun 7 15:34:53.337: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x6CEA

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9838A

Exclusive, Channel 10

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0x0180, '01212135619'

Plan:ISDN, Type:Unknown

Called Party Number i = 0x81, '01495764009'

Plan:ISDN, Type:Unknown

8137213: Jun 7 15:34:53.481: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xECEA

Channel ID i = 0xA9838A

Exclusive, Channel 10

8137214: Jun 7 15:34:55.681: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0xECE7

8137215: Jun 7 2011 15:34:55: %ISDN-6-CONNECT: Interface Serial0/0/0:7 is now connected to 01291431606 N/A

8137216: Jun 7 15:34:55.681: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x6CE7

8137217: Jun 7 15:34:55.829: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0xECEA

Progress Ind i = 0x8482 - Destination address is non-ISDN

8137218: Jun 7 2011 15:34:57: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId 77806791905211E08674F47ED6CE3077, SetupTime 15:34:28.779 GMT Tue Jun 7 2011, PeerAddress 5616, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 15:34:55.689 GMT Tue Jun 7 2011, DisconnectTime 15:34:57.269 GMT Tue Jun 7 2011, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 1078, TransmitBytes 172480, ReceivePackets 0, ReceiveBytes 0

8137219: Jun 7 2011 15:34:57: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:06/07/2011 15:34:28.773,cgn:5616,cdn:,frs:0,fid:225167,fcid:77806791905211E08674F47ED6CE3077,legID:35866,bguid:77806791905211E08674F47ED6CE3077

8137220: Jun 7 15:34:57.269: voice_file_acct_initiate_dump_to_file: Both file modes have failed in earlier attempt

8137221: Jun 7 15:34:57.269: Use file-acct reset when the problem is recovered

8137222: Jun 7 2011 15:34:57: %ISDN-6-DISCONNECT: Interface Serial0/0/0:7 disconnected from 01291431606 , call lasted 1 seconds

8137223: Jun 7 15:34:57.285: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x6CE7

Cause i = 0x8090 - Normal call clearing

8137224: Jun 7 15:34:57.581: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0xECE7

8137225: Jun 7 15:34:57.581: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x6CE7

8137226: Jun 7 2011 15:34:57: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId 77806791905211E08674F47ED6CE3077, SetupTime 15:34:33.631 GMT Tue Jun 7 2011, PeerAddress 901291431606, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 15:34:55.681 GMT Tue Jun 7 2011, DisconnectTime 15:34:57.581 GMT Tue Jun 7 2011, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 1081, TransmitBytes 172960, ReceivePackets 1078, ReceiveBytes 181104

8137227: Jun 7 2011 15:34:57: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:06/07/2011 15:34:33.477,cgn:01212135616,cdn:901291431606,frs:0,fid:225169,fcid:77806791905211E08674F47ED6CE3077,legID:35868,bguid:77806791905211E08674F47ED6CE3077

8137228: Jun 7 15:34:57.581: voice_file_acct_initiate_dump_to_file: Both file modes have failed in earlier attempt

8137229: Jun 7 15:34:57.581: Use file-acct reset when the problem is recovered

Would you require anything else?

paolo bevilacqua · ‎06-07-2011

The debug shows the call goes through when sent to ISDN but doesn't show where the failed calls go.

You need to look at debug voip dialpeer to see what DPs are hit when calling. You may find misconfiguration.

A reload is unlikely to fix this particular problem, altough I cannot exclude it.

Nathan Hardman · ‎06-07-2011

Hi Paolo,

Ive just spoke to the customer and this isn't happening all the time she says that it pehaps happens once in every 5 calls, does this change anything?

When we just tested this she phoned me 3 times and all 3 connected first attempt. She has assured me that this is not a user error as it happens for all the phones.

paolo bevilacqua · ‎06-07-2011

Ok I'd try a reload then. Then if you can load 15.0(1)M5, that is very stable.

And check show controller T1 for any error.