cause code - Invalid call reference value

rvincent · ‎02-02-2009

customer has a as5400 gateway w/ t3 and ucm 6.1. while testing incoming DID calls, some calls are failing and q931 msg shows telco release being received after as5400 sends connect.

the cause is "Invalid call reference" weird thing is some calls work fine while others fail with this msg.

2027181: *May 8 2001 12:17:33.081 UTC: ISDN Se7/0:16:23 Q931: TX -> CONNECT pd

= 8 callref = 0x800E

2027182: *May 8 2001 12:17:33.101 UTC: ISDN Se7/0:16:23 Q931: RX <- RELEASE_COM

P pd = 8 callref = 0x000E

Cause i = 0x80D1 - Invalid call reference value

when telco was sending in 4-digits, all calls worked. now they are sending 10-digits, as customer requested, and the above is happening.

doesn't seem to be any consistancy with dialed number, or channel, etc.

does anyone know what telco is saying and how to correct?

thanks

rob

paolo bevilacqua · ‎02-02-2009

Hi,

you should look at the complete trace to see if router actually is referencing and invalid value.

rvincent · ‎02-02-2009

the callref the router references looks to be different each time - is that what you are referring to?

how do you know if its invalid?

thanks

rob

paolo bevilacqua · ‎02-02-2009

It must match the value in the setup message. Note, messages for user to network always set call value rightmost bit to 1.

Nicholas Matthews · ‎02-02-2009

It's possible there's something wrong on the gateway. You will see this error message if you try referencing a call value that doesn't exist, or has already been disconnected.

The most significant bit in the 16 bits gets toggled based on direction (add 8 to the first value). In this case it's 800E and 000E. You can search your q931 logs for the last 3 values, and see if it should be a valid call or not.

It's possible the provider is loosing calls, and it's also possible we're asking for calls that don't exist. I've seen this particularly frequent with MGCP PRI's controlled by a CUCM on the fritz. H323/SIP is generally more stable, but anything is possible.

hth,

nick

rvincent · ‎02-03-2009

guys:

thanks

gateway is h323.

below is what was captured when call failed. can anything be told from this or do I need another capture?

2026931: *May 8 2001 09:44:05.689 UTC: ISDN Se7/0:27:23 Q931: RX <- SETUP pd =

8 callref = 0x0004

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band inf

o

Calling Party Number i = 0x2180, '7195351300'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '9727935836'

Plan:ISDN, Type:National

2026932: *May 8 2001 09:44:05.701 UTC: ISDN Se7/0:27:23 Q931: TX -> CALL_PROC p

d = 8 callref = 0x8004

Channel ID i = 0xA98381

Exclusive, Channel 1

2026933: *May 8 2001 09:44:05.809 UTC: ISDN Se7/0:27:23 Q931: TX -> ALERTING pd

= 8 callref = 0x8004

2026934: *May 8 2001 09:44:06.701 UTC: ISDN Se7/0:27:23 Q931: TX -> ALERTING pd

= 8 callref = 0x8004

2026935: *May 8 2001 09:44:12.561 UTC: ISDN Se7/0:27:23 Q931: TX -> CONNECT pd

= 8 callref = 0x8004

2026936: *May 8 2001 09:44:12.589 UTC: ISDN Se7/0:27:23 Q931: RX <- RELEASE_COM

P pd = 8 callref = 0x0004

Cause i = 0x80D1 - Invalid call reference value

thanks

Rob

paolo bevilacqua · ‎02-03-2009

router is sending the correct call reference value. check "show controller T3" for any error or slip. If all good, matter should be reported to telco with the trace above.

If no problems when telco sendidn 4 digits DNIS, you can easily add the leading ones in router or CM.

Nicholas Matthews · ‎02-03-2009

Hi Rob,

It's possible your provider is erroring on the double Alerting. It's valid Q931, but it doesn't mean that their switch is acting correctly.

Either way, you will need to start a conversation with them and tell them that they're out of spec for q931 in this call flow.

-nick

rvincent · ‎02-03-2009

guys

thanks for the feedback.

regarding the double alert, I looked at a trace from a good call and there is no double alert.

Is the double alert a router issue or should telco handle it either way?

why would router send double alert msg?

thanks

Rob

paolo bevilacqua · ‎02-03-2009

Perhaps the call goes to a forwarded phone, hunt group, or RP with transformation ?

rvincent · ‎02-03-2009

it is going into a ucm translation pattern, but so was the good call.

rob

rvincent · ‎02-03-2009

guess it does not have to do w/ double alert msg as I found another q931 trace of a ng call and it did not have a double alert msg:

2027172: *May 8 2001 12:17:14.421 UTC: ISDN Se7/0:17:23 Q931: RX <- SETUP pd =

8 callref = 0x0006

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band inf

o

Calling Party Number i = 0x00C3, N/A

Plan:Unknown, Type:Unknown

Called Party Number i = 0xA1, '9727935826'

Plan:ISDN, Type:National

2027173: *May 8 2001 12:17:14.437 UTC: ISDN Se7/0:17:23 Q931: TX -> CALL_PROC p

d = 8 callref = 0x8006

Channel ID i = 0xA98381

Exclusive, Channel 1

2027174: *May 8 2001 12:17:14.541 UTC: ISDN Se7/0:17:23 Q931: TX -> ALERTING pd

= 8 callref = 0x8006

2027175: *May 8 2001 12:17:20.961 UTC: ISDN Se7/0:17:23 Q931: TX -> CONNECT pd

= 8 callref = 0x8006

2027176: *May 8 2001 12:17:20.981 UTC: ISDN Se7/0:17:23 Q931: RX <- RELEASE_COM

P pd = 8 callref = 0x0006

Cause i = 0x80D1 - Invalid call reference value

rob

Nicholas Matthews · ‎02-03-2009

Hi Rob,

This is about the extent that we can help from a Cisco side - rest is all provider.

Good luck :) These debugs should help force them to take responsibility.

-nick

rvincent · ‎02-05-2009

Just to put closure to this...

problem turned out to be in the carrier's Wide Band Digital Cross Connect equipment.

thanks for your help

Rob