Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Intermittent issue with incoming calls

Hey all, I have an issue with incoming calls at one of our sites. It's an intermittent issue, so its making it hard to track it down. We have one site that is not always manned, so we have the incoming calls to their main number forwarding to one of our other sites with the "connection plar" command. What is happening is some calls are coming in and ringing once or twice, then nothing. It will do this 3 or 4 times, likes its in a loop. The ladies have answered it before and it's dead air. I have attached the show run command ouput from the two routers that are involved. I currently have the debug voip ccapi inout dumping output to a syslog server waiting for it to happen again. Can you all think of any other debugs I should be running?                  

Everyone's tags (4)
7 REPLIES
New Member

Intermittent issue with incoming calls

I have the output from failed and successful calls, but don't want to paste the output.  How can I attach the log files?

Re: Intermittent issue with incoming calls

Click on "Use Advanced Editor" on the top-right of the windows and so attach a file.

Regards.

New Member

Re: Intermittent issue with incoming calls

  Thanks for the info.  Here are the two scenarios.                  

New Member

Intermittent issue with incoming calls

Anyone have any ideas?

Cisco Employee

Re: Intermittent issue with incoming calls

Hi,

Looked into th failed scenario, call was released by  far end Telco/PBX switch.

Looks like this is the call flow:-

FXO-----GW---h225-----unknonwn

++ Looks like we only  have voip ccapi and h225 q931, we see call was accepted via incoming dial-peer 60091103, on port

port 0/1/2, which is configured for PLAR, so it will ring the far end

3040.

//2012-04-27 13:04:06          Local7.Debug          10.127.55.253          10818: Interface=0x47DDA4CC, Call Info(

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10819:    Calling Number=6109028808,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10820:    Called Number=3040(TON=Unknown, NPI=Unknown),

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10821:    Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10822:    Incoming Dial-peer=60091103, Progress Indication=ORIGINATING SIDE IS NON ISDN(3), Calling IE Present=TRUE,

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10823:    Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1

// IOS finds the outbound dial-peer 2219 for the number 3040.

Interface=0x4769ACC0, Interface Type=1, Destination=, Mode=0x0,

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10890:    Call Params(Calling Number=6109028808,(Calling Name=Philadelphia)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10891:    Called Number=3040(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10892:    Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE, Outgoing Dial-peer=2219, Call Count On=FALSE,

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10893:    Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10897: 003197: Apr 27 13:03:54 EDT: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

// H225 setup send.

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10910: Protocol Discriminator : 0x08

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10911: CRV Length             : 2

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10912: CRV Value              : 0x031D

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10913: Message Type           : 0x05: SETUP

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10914:  Bearer Capability: Length Of IE=3

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10915:  Data 9090A3

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10916:  Display: Length Of IE=12

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10917:  Data 5068696C6164656C70686961

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10918:  Calling Party Number: Length Of IE=11

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10919:  Data 8036313039303238383038

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10920:  Called Party Number: Length Of IE=5

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10921:  Data 8033303430

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10922:  User-User: Length Of IE=325

++ Far end send proceeding/ alerting and notify.

++ After that, we release complete going towards the h323 peer at far end with cause value x8290, which is normal call clearing.

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11000:   Q931 Message IE Decodes

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11001: Protocol Discriminator : 0x08

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11002: CRV Length             : 2

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11003: CRV Value              : 0x031D

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11004: Message Type           : 0x5A: RELEASE_COMP

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11005:  Cause: Length Of IE=2

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11006:  Data 8290

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          11007:  User-User: Length Of IE=34

++ The reason I am saying Telco released the call is ccapi call reference for the first leg is 5748, and I see ccapi disconnect for 5748  prior to h225 release complete and also call-ref for h225 leg is 5749 from the debugs.

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10980: 003217: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/cc_api_call_disconnected:

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10981:    Cause Value=16, Interface=0x47DDA4CC, Call Id=5748

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10982: 003218: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/cc_api_call_disconnected:

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10983:    Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)

2012-04-27 13:04:07          Local7.Debug          10.127.55.253          10984: 003219: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/ccGenerateToneInfo:

++ So call is getting release even before the far end has sent the connect message. And we don't know what happened in h245 layer as we dont have debugs for that.

++ Since telco is releasing the call first, will you be able to involve them to see why are they releasing the call.

++ And in successful call, we receive Connect message on h225 leg, which is not coming in the non-working scenario,  but I think the call is been released from the far end prior to that. We can confirm that if you have complete set of debugs:-

++ debug vpm sig

++ debug voip ccapi inout

++ debug h225 asn1

++ debug h245 ans1

++ debug h225 q931

and if possible

++ debug cch323 all

Thanks,

Murali

VIP Super Bronze

Re: Intermittent issue with incoming calls

Hi,

From the trace here is the analysis,

After Call setup was completed, we get a call proceeding on the outbound call leg callid= 5749

2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10934: 003205: Apr 27 13:03:54 EDT: //5749/CDE5B3999FC3/CCAPI/cc_api_call_proceeding:

Next we get a call alert and a ring back..Indicating the called end is ringing

2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10949: 003208: Apr 27 13:03:54 EDT: //5749/CDE5B3999FC3/CCAPI/cc_api_call_alert:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10950:    Interface=0x4769ACC0, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10951: 003209: Apr 27 13:03:54 EDT: //5749/CDE5B3999FC3/CCAPI/cc_api_call_alert:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10952:    Call Entry(Retry Count=0, Responsed=TRUE)

Next we get an alert on the inbound call leg to notify the calling party that the called end is ringing.. (call leg id-5748)

2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10953: 003210: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/ccCallAlert:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10954:    Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10955: 003211: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/ccCallAlert:

After a few notify, we get the following disconnect on the inbound call leg. Callid=5748 and a cause code =16

2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10980: 003217: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/cc_api_call_disconnected:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10981:    Cause Value=16, Interface=0x47DDA4CC, Call Id=5748
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10982: 003218: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/cc_api_call_disconnected:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10983:    Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10984: 003219: Apr 27 13:03:54 EDT: //5748/CDE5B3999FC3/CCAPI/ccGenerateToneInfo:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10985:    Stop Tone On Digit=FALSE, Tone=Null,
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10986:    Tone Direction=Network, Params=0x0, Call Id=5748
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10987: 003220: Apr 27 13:03:54 EDT: //5749/CDE5B3999FC3/CCAPI/ccCallDisconnect:
2012-04-27 13:04:07 Local7.Debug 10.127.55.253 10988:    Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

 

Its difficult to know why the Telco is disconeccting the call before the called end attempts to connect the call. we didnt see a connect from the called end.

We may need to look at h225 and h245 debugs to see whats going on with capabilities negotioation...

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Intermittent issue with incoming calls

Thanks, this is great info from both of you.  I have these debugs running now:

H.225:

  H.225 Q931 IE Details debugging is on

  H.225 ASN1 Messages debugging is on

H.245:

  H.245 ASN1 Messages debugging is on

Voice Port Module signaling debugging is on

CCAPI:

  debug voip ccapi inout is ON (filter is OFF)

CCH323 SPI: H225 State Machine tracing is enabled (filter is OFF)

CCH323 SPI: H245 State Machine tracing is enabled (filter is OFF)

CCH323 SPI: RAS State Machine tracing is enabled (filter is OFF)

CCH323 SPI: NXE transport tracing is enabled

CCH323 SPI: Session tracing is enabled (filter is OFF)

CCH323 SPI: Error debug is enabled

CCH323 SPI: Rawmsg debug is enabled (filter is OFF)

CCH323 SPI: Call Capacity Information tracing is enabled (filter is OFF)

CCH323 SPI: Preauth debug is enabled (filter is OFF)

CCH323 SPI: IP-to-IP call debug is enabled (filter is OFF)

CCH323 SPI: H245 Video tracing is enabled (filter is OFF)

CCSIP SPI: SIP Call Message tracing is enabled  (filter is OFF)

Once we get a failed call, I'll post the output.  Thanks for all of your help!

673
Views
0
Helpful
7
Replies
CreatePlease login to create content