11-04-2011 08:52 AM - edited 03-16-2019 07:53 AM
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
11-04-2011 09:45 AM
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
11-04-2011 11:27 AM
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
11-04-2011 11:41 AM
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.
11-04-2011 01:22 PM
11-04-2011 01:18 PM
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
11-04-2011 01:26 PM
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.
11-04-2011 01:51 PM
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
11-07-2011 01:33 AM
11-07-2011 03:46 AM
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
11-07-2011 04:50 AM
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
11-07-2011 05:53 AM
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,
11-07-2011 06:46 AM
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
11-07-2011 06:49 AM
On CUCM 10.131.14.30 does the GW says
unknown
unknown
Or
unknown
[ip address of the GW]
Thanks,
11-07-2011 06:51 AM
unknown 10.131.14.30
Greetings
Manfred
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: