02-02-2009 01:23 PM - edited 03-15-2019 03:56 PM
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
02-02-2009 01:27 PM
Hi,
you should look at the complete trace to see if router actually is referencing and invalid value.
02-02-2009 01:31 PM
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
02-02-2009 01:42 PM
It must match the value in the setup message. Note, messages for user to network always set call value rightmost bit to 1.
02-02-2009 06:24 PM
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
02-03-2009 06:31 AM
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
02-03-2009 06:44 AM
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.
02-03-2009 06:57 AM
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
02-03-2009 07:36 AM
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
02-03-2009 07:38 AM
Perhaps the call goes to a forwarded phone, hunt group, or RP with transformation ?
02-03-2009 07:51 AM
it is going into a ucm translation pattern, but so was the good call.
rob
02-03-2009 08:08 AM
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
02-03-2009 08:49 AM
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
02-05-2009 01:41 PM
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
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: