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

Incomming ISDN Call fails

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#

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#

chwscuvg01#

Any Ideas?

Thanks for your response!

Best regards

Manfred Ranger

22 REPLIES
Green

Incomming ISDN Call fails

Manfred,

Looks like an issue re overlap signalling

In the bad call we see

High Layer Compat i = 0x9181

can you try adding this to your isdn "D" chanel

!

int ser 0/1/0:15

isdn overlap-receiving T302 2000

!

Retest

HTH

Alex

Regards, Alex. Please rate useful posts.
New Member

Incomming ISDN Call fails

hi Mr. Ranger,

Can you try enabling " debug voice translation" to check actually which translation rule (if any) is being matched and what actually is the message there ? I think this can help in furthur troubleshooting.

Thanks

Anil Sharma

Cisco Employee

Incomming ISDN Call fails

Hi m.ranger,

To give you the proper answer, i would appreciate if yuo send this information.

show run

show ver

show dial-peer voice summ

Also please colect these debugs atthe same time for a working call and a non working call.

debug isdn q931

debug voip ccapi inout

debug h225 asn1

debug h245 asn1

Let us know the calling and called number for the working and non working call.

Thanks,

Luis Ramirez.

New Member

Re: Incomming ISDN Call fails

Hi Luis,

the debugs are already attached to my first posting. The requested show commands are attached to this posting.

Best regards

Manfred

New Member

Incomming ISDN Call fails

Hi Alex,

sorry, i missed to attach my config. I will post the whole configuration.

Your suggestion for overlap receiving is already configured.

I configured

isdn overlap-receiving T302 6000.

The router config was working until I updated CUCM to version 8.6.

Thanks

Manfred

Cisco Employee

Incomming ISDN Call fails

m.ranger

I know the debugs are there, but you have a lot of unnecesary debugs and also there are a lot of lines lost.

Get the debugs on the router's buffer by using these commands and make sure are only the debugs i mentioned.

conf t

service sequence

service timestamps debug datetime msec

logging buffered 10000000 7

no logging con

no logging mon

voice iec syslog

end

In order to get the debug outout run a show logg.

Thanks,

Luis Ramirez.

New Member

Incomming ISDN Call fails

Hi Luis,

ok, I understand but I can´t get new debugs at the moment because it is friday evening 10pm and I need the customer to make testcalls, at least for the bad call.

On Monday morning I will collect the traces and post them.

Thanks a lot for your support until now.

Have a nice day.

Best regards

Manfred

New Member

Re: Incomming ISDN Call fails

Hello Luis,

today I could get the requested traces.

    Calling Party Number i = 0x0181, '0786351611'

    Called Party Number i = 0x81, '3000'

Please have a look to the traces.

Thank you very much for your support.

Best regards

Manfred

Green

Incomming ISDN Call fails

Manfred,

The incoming dialled number :-

3000 this is translated to 1942294

This 1942294 matches dial peer 1001and fails to find a destination on the CUCM

It retries on dial peer 1002 and again fails to find a match at the CUCM

What is 1942294 defined as in the CUCM ?

regards

Alex

Regards, Alex. Please rate useful posts.
New Member

Re: Incomming ISDN Call fails

Hi Luis,

1942294 is a CTI Route Point. The incomming 3000 is translated to this internal number via a voice translation-rule on the router.

The CTI Route Point is used by a CUCX as trigger for a script.

The funny thing is that this configuration worked fine with the old CUCM Version. Since the update to CUCM

8.6.1.20000-1 we have these problems. But only if the caller comes from Orange or Sunrise as Service Provider. If the caller comes from Telekom or Swisscom we do not have any problems.

Best regards

Manfred

Cisco Employee

Re: Incomming ISDN Call fails

Mranger,

You should be looking at CUCM, and the way it receives the call.

If you look at the debugs the GW matches the outgoing dial-peer 1001 and sends the call to CUCM, wich means TCP between GW and CUCM is coming UP.

The issue is that CUCM is no responding and it just times out.

Setup is sent to CUCM at "234935: Nov  7 09:14:42.863: H225.0 OUTGOING PDU ::="

GW sends the reject at "234939: Nov  7 09:14:57.871: H225.0 OUTGOING PDU ::="

And it is even telling you why "Internal Error (No Usr Responding, H225 timeout)"

For some reason CUCM (10.132.13.19) is responding and the answer coming from CUCM is "Destination out of order".

What to look in order to fix this?

Access CUCM server (10.131.14.30) and make sure the H.323 GW says unknown and the IP address of the GW (10.201.30.11).

For the disconnection that comes from the second server, I would say it is finding the destinatin number but something is failing, you might want to get CUCM traces.

Thanks,

New Member

Re: Incomming ISDN Call fails

Hi Luis,

CUCM 10.132.13.19 is an CUCM which is not "up to date" at the moment. It is running still with Version 6 and has no phones registered. For this it works as expected. I deleted all dial-peers to CUCM 10.132.13.19 without any change in our problem.

On CUCM 10.131.14.30 the H.323 GW says unknown.

Can you tell me please to which CUCM traces I should have to look at?

Best regards

Manfred

Cisco Employee

Re: Incomming ISDN Call fails

On CUCM 10.131.14.30 does the GW says

unknown

unknown

Or

unknown

[ip address of the GW]

Thanks,

New Member

Re: Incomming ISDN Call fails

unknown          10.131.14.30

Greetings

Manfred

Cisco Employee

Re: Incomming ISDN Call fails

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

Thanks,

New Member

Re: Incomming ISDN Call fails

Yes, see screenshots

Regards

Manfred

Cisco Employee

Re: Incomming ISDN Call fails

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,

New Member

Re: Incomming ISDN Call fails

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

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

Thanks a lot for your great support

Best regards

Manfred

Cisco Employee

Re: Incomming ISDN Call fails

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.

New Member

Re: Incomming ISDN Call fails

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

Cisco Employee

Re: Incomming ISDN Call fails

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,

New Member

Re: Incomming ISDN Call fails

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

4524
Views
0
Helpful
22
Replies
CreatePlease login to create content