Re: Incomming ISDN Call fails - Page 2

m.ranger · ‎11-04-2011

Hello all,

I did an Update from CUCM 7.0.1 to 8.6.1.20000-1 and have now a problem with some incomming ISDN calls. I have a H.323 gateway to PSTN with IOS 12.4.24T5.

Calls from Telekom or Swisscom as Serviceprovider are working without any problems

Calls from Orange or Sunrise as Serviceprovider do not work. They end after 6 seconds with Disconnect cause "destination out of order".

What I can see that the two setup messages differ in ISDN Bearer Capability, the good one is 9090A3 and the bad one is 8090A3.

For detailed debugs see attached files please.

The customer told me that we have this problem since the update to CUCM 8.6.

ISDN Setup of a bad call:

Nov 4 15:51:03.035 CET: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x00BA

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839E

Exclusive, Channel 30

Calling Party Number i = 0x0181, '0787966866'

Plan:ISDN, Type:Unknown

Called Party Number i = 0x81, '3000'

Plan:ISDN, Type:Unknown

High Layer Compat i = 0x9181

Nov 4 15:51:03.035 CET: ISDN Se0/1/0:15 Q931: Received SETUP callref = 0x80BA callID = 0x0023 switch = primary-net5 interface = User

chwscuvg01#

Nov 4 15:51:03.051 CET: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x80BA

Channel ID i = 0xA9839E

Exclusive, Channel 30

chwscuvg01#

Nov 4 15:51:18.271 CET: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x80BA

Cause i = 0x809B - Destination out of order

Nov 4 15:51:18.415 CET: ISDN Se0/1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x00BA

Nov 4 15:51:18.415 CET: ISDN Se0/1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x80BA

ISDN Setup of a good call:

Nov 4 15:12:50.179 CET: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x009C

Sending Complete

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839E

Exclusive, Channel 30

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

Calling Party Number i = 0x0183, '0629222133'

Plan:ISDN, Type:Unknown

Called Party Number i = 0x81, '3265'

Plan:ISDN, Type:Unknown

Nov 4 15:12:50.183 CET: ISDN Se0/1/0:15 Q931: Received SETUP callref = 0x809C callID = 0x0005 switch = primary-net5 interface = User

chwscuvg01#

Nov 4 15:12:50.199 CET: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x809C

Channel ID i = 0xA9839E

Exclusive, Channel 30

chwscuvg01#

Nov 4 15:13:05.603 CET: ISDN Se0/1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x809C

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

Nov 4 15:13:05.871 CET: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x809C

Nov 4 15:13:05.899 CET: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x009C

chwscuvg01#

Any Ideas?

Thanks for your response!

Best regards

Manfred Ranger

luirami2 · ‎11-07-2011

Is the GW on CUCM webpage configured with the IP address 10.201.30.11?

Thanks,

m.ranger · ‎11-07-2011

Yes, see screenshots

Regards

Manfred

luirami2 · ‎11-07-2011

Can you check if you have any other Gw with the same IP address configured?

also try this.

interface GigabitEthernet0/0

h323-gateway voip interface

exit

Reset the GW on CUCM.

If after that, it is still with the same problem, get detailed CUCM traces.

The most important would be capi and h225.

Thanks,

m.ranger · ‎11-07-2011

Hi Luis,

I added the command to gig0/0 and did a reset to the gateway - without any change.

Attached are the detailed CUCM traces.

I did two testcalls which are visible in the CUCM Traces

Calling Nr: ...7966844
Called Nr: 1942241 which is a IP Phone
Calling Nr: ...7966844
Called Nr: 1942294 which is a CTI Route Point (CUCX Trigger)

Thanks a lot for your great support

Best regards

Manfred

luirami2 · ‎11-07-2011

M.range,

Did you get the traces in CUCM server 10.131.14.30.

They don.t look the same.

On these traces I could find the called number 1942294 but here CUCM is responding and connecting the call.

Let me know since debugs and traces don't match.

Thanks,

Luis Ramirez.

m.ranger · ‎11-08-2011

Hi Luis,

yes, I got the traces from CUCM 10.131.14.30.

My analysis gave me another info. I was able to see incoming setup messages from gw to cucm, but cucm isn´t answering the setups.

Yesterday I opened a TAC Case for this. At the moment it seems that I am the victim of an bug. TAC found out that that CSCtq55529 is our problem.

TAC is doing some more research and will come back. Perhaps I can update CUCM today evening. I will post the result here.

Best regards

Manfred

luirami2 · ‎11-08-2011

It is great to hear that.

That might be the case I looked at today but it finished in a CUCM Team where the engineer took a sniffer trace.

if not, just coincidence.

Well good add to the support forum.

Thanks,

Luis Ramirez,

m.ranger · ‎11-09-2011

Hi all,

today in the evening I did an update to the 8.6.1 CUCM. I updated it to version 8.6.2a (8.6.2.20000-2) and fixed my problem. Now all incomming calls are answered by the callmanager. It seems that I really stuck in Bug CSCtq55529

Thanks to all supporting persons here in supportforum and spezially the SEs from TAC who did the long troubleshooting session with me to get the problem fixed.

Cheers

Manfred