IOS based MGCP gateway with overlap sending - strange Q931 debug messages!

[pcantore]

We're implementing a remote gateway (in Germany with CCM hosted in UK). Overlap sending works in my test environment, but on site after a variable number of digits dialled we get the following debug output:-

Jan 8 09:22:17: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8006

Cause i = 0x82E49870 - Invalid information element contents

Jan 8 09:22:17: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8006

Cause i = 0x82D1 - Invalid call reference value

Jan 8 09:22:17: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8006

Cause i = 0x82D1 - Invalid call reference value

And the call attempt fails! I suspect that it's an IE option setting under CallManager, but has anyone seen this and know how to fix it? What does the "invalid call reference value" point to? We have raised a TAC case but you never know eh?

Ta.... pdc

[benng]

Hi,

As far as I could see from what you've posted, telco switch send us a release_complete first because it does not like some of the IEs in our previous Q931 message.

Could you zip up the ccm trace of the entire call and email to to me at benng@cisco.com?

About the invalid call reference value, it is most likely caused by the fact that the telco switch considered the call with call reference value (00 06) terminated after sending us the first release_complete, but received a few more msgs about that call afterwards.

-ben

[dgoodwin]

Hi,

Can you please send the entire debug, starting with the SETUP message? I think the first RELEASE_COMP message is complaining about something not being valid in the Called party number IE.

[pcantore]

Hi, appologies for the time delay - where I am it's actually 10am on the 9th, the posting will read 2am, just the 8 hours!

Here is the debug for an enbloc call out of this PRI:-

Jan 9 09:26:17: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0005

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Calling Party Number i = 0x0080, '06929729997'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '00442074645720'

Plan:Unknown, Type:Unknown

Jan 9 09:26:18: ISDN Se1/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x8005

Channel ID i = 0xA9839F

Exclusive, Channel 31

Jan 9 09:26:20: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8005

Jan 9 09:26:27: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x0005

Cause i = 0x8090 - Normal call clearing

Jan 9 09:26:28: ISDN Se1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x8005

Jan 9 09:26:28: ISDN Se1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0005

And all is good with this!

And here is the debug for an overlap sending call on the same PRI:-

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Calling Party Number i = 0x0080, '06929729997'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80

Plan:Unknown, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x8004

Channel ID i = 0xA9839F

Exclusive, Channel 31

Progress Ind i = 0x8288 - In-band info or appropriate now available

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0x84, '0'

Plan:Telex, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0x84, '0'

Plan:Telex, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0x84, '4'

Plan:Telex, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0x84, '4'

Plan:Telex, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0x84, '2'

Plan:Telex, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0xD0, '0'

Plan:Unknown, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0xD0, '7'

Plan:Unknown, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0xD0, '4'

Plan:Unknown, Type:Unknown

Jan 9 09:13:10: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0xD0, '6'

Plan:Unknown, Type:Unknown

Jan 9 09:13:11: ISDN Se1/0:15 Q931: TX -> INFORMATION pd = 8 callref = 0x0004

Called Party Number i = 0xD0, '4'

Plan:Unknown, Type:Unknown

Jan 9 09:13:11: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8004

Cause i = 0x82E49870 - Invalid information element contents

Jan 9 09:13:11: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8004

Cause i = 0x82D1 - Invalid call reference value

[pcantore]

We got to the bottom of this one....

If you look at the SETUP message, the both the "Plan" and "Type" are "Unknown", but the first overlap digit sent CCM has changed the Plan to "Telex" - why? No idea, but the work around is to go to the gateway config on CCM and change the called and calling IE number type and plan type settings from "Cisco CallManager" to "Unknown".

What is strange is that in our test-bed this works perfectly using the same hardware, IOS and CCM versions without the need for this work around!

Then we hit the cannot redial known problem, so take out the route list and point the route pattern to go direct to the gateway. And are just left with some timer issues - but that's another story.....