Re: [OSL | CCIE_Voice] CCIE_Voice Digest, Vol 37, Issue 96 Call from PSTN to BR-2 (H.323) failed

Sun, 15 Mar 2009 01:52:11 -0700 

Cause i = 0x809B - Destination out of order

80
Normal Disconnect
The call disconnects normally.
9B
Destination out of order
The destination is not reachable because of an interface malfunction. In addition, a signaling message cannot be delivered. This condition can be temporary. However, the condition can last for an extended period in some cases. 


This cause indicates that a signaling message could not be delivered to the 
remote user. For example, a physical layer or data link layer fails at the 
remote user end, and the user equipment is off-line (turned off).

--------------------------------------------------------
first situation for this problem occurance

if This problem occuring on one single DID out of define range of block,try 
to delete all the instance of this DID,even from Num Plan Report.if still 
there's problem need to cycle service on call Manager.


second Situation of problem occurance

if you have a call session is open and another call comes in, is your first 
call disconnected and get this debug message.check with your Flow.

regards
Faisal

----- Original Message ----- 
From: <ccie_voice-requ...@onlinestudylist.com>

To: <ccie_voice@onlinestudylist.com>
Sent: Sunday, March 15, 2009 1:34 AM
Subject: CCIE_Voice Digest, Vol 37, Issue 96



Send CCIE_Voice mailing list submissions to
ccie_voice@onlinestudylist.com

To subscribe or unsubscribe via the World Wide Web, visit
http://onlinestudylist.com/mailman/listinfo/ccie_voice
or, via email, send a message with subject or body 'help' to
ccie_voice-requ...@onlinestudylist.com

You can reach the person managing the list at
ccie_voice-ow...@onlinestudylist.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CCIE_Voice digest..."


Today's Topics:

  1. Re: Call  from PSTN to BR-2  (H.323)  failed (Cliff McGlamry)
  2. Re: Trouble loading CUPS (Girard, Jeffrey COL MIL USA)
  3. 3xxx call from HQ to BR2 through GK (Scott ODonnell)
  4. Re: 3xxx call from HQ to BR2 through GK (basant yadav)


----------------------------------------------------------------------

Message: 1
Date: Sat, 14 Mar 2009 22:25:37 -0400
From: "Cliff McGlamry" <cl...@mcglamry.net>
Subject: Re: [OSL | CCIE_Voice] Call  from PSTN to BR-2  (H.323)
failed
To: <e_er...@yahoo.com>, <ccie_voice@onlinestudylist.com>
Message-ID: <009201c9a515$550ab0b0$0428f...@forsythe.com>
Content-Type: text/plain; charset="iso-8859-1"


Can mean several things.  It can be that the call attempted to use a B 
channel that isn't lit, the D channel may be down, or you may be 
attempting to route to an endpoint that's not working and/or configured.



Check the debug q931 trace on the H323 gateway to see what it's doing at 
the time this happens.
 ----- Original Message ----- 
 From: Erwan Erwan

 To: ccie_voice@onlinestudylist.com
 Sent: Saturday, March 14, 2009 10:21 PM
 Subject: [OSL | CCIE_Voice] Call from PSTN to BR-2 (H.323) failed



       hi,


       anybody have idea, call from PSTN to Branch-2 (H.323) sometimes 
did not go thru and hv this error msg from PSTN GW


       Cause i = 0x809B - Destination out of order


       thks

-------------- next part --------------
An HTML attachment was scrubbed...

URL: 
http://onlinestudylist.com/pipermail/ccie_voice/attachments/20090314/989cb6d1/attachment-0001.htm


------------------------------

Message: 2
Date: Sat, 14 Mar 2009 22:07:19 -0600
From: "Girard, Jeffrey COL MIL USA" <jeffrey.gir...@us.army.mil>
Subject: Re: [OSL | CCIE_Voice] Trouble loading CUPS
To: <ccie_voice@onlinestudylist.com>
Message-ID:
<0b08c95ff256e9418a7229385ae0ba90059...@blis100be000102.nasw.ds.army.mil>

Content-Type: text/plain; charset="utf-8"


I just tried to load CUC on a new/separate VM on the same host machine and 
ran into the exact same problem



Here is a thought/question....when the install asks me about whether this 
install is the first node in the cluster - I am answering the question NO 
as I already have a Pub installed. Is each type of server (CUCM, CUPS, 
CUC, UXCC) considered as separate clusters? Should I be answering YES to 
first node in the cluster question?


________________________________


From: ccie_voice-boun...@onlinestudylist.com 
<ccie_voice-boun...@onlinestudylist.com>

To: ccie_voice@onlinestudylist.com <ccie_voice@onlinestudylist.com>
Sent: Sat Mar 14 20:17:39 2009
Subject: [OSL | CCIE_Voice] Trouble loading CUPS



I have installed 2 copies of CUCM Version 7 - both in VMWare on the same 
host. On another host, also inside VMWare, I am trying to load CUPS 
Version 7



I created an ISO from the istall disk and created the guest VM. Specs 
used - 1.3 GB RAM, 75 GB HD. Initial install of Red Hat Linux goes well


On another machine, I opened up a browser to the CUCM Pub at 10.10.210.10


On the Pub, I added the CUPS server using the IP as the name. This is the 
same process that I used while loading up the Sub.



In the second phase of the CUPS install, I receive the following error 
message.  Have repeated these steps twice with the same results, so its a 
consistent error


Configuration validation with CMPublisher (10.10.210.10) failed
Configured deployment cups does not match the deployment at 10.10.210.10

It then asks me if CMPublisher is the correct first node


If I select the option to correct the error, I am taken back to the screen 
where I define the first node information (machine name, IP address, 
password). I have gone through this loop twice with no changes


From the host I amable to ping both the CUCMs with no problems

Any ideas?

-------------- next part --------------
An HTML attachment was scrubbed...

URL: 
http://onlinestudylist.com/pipermail/ccie_voice/attachments/20090314/b7968f04/attachment-0001.htm


------------------------------

Message: 3
Date: Sun, 15 Mar 2009 00:34:37 -0400
From: Scott ODonnell <scott.odonn...@gmail.com>
Subject: [OSL | CCIE_Voice] 3xxx call from HQ to BR2 through GK
To: OSL Group <ccie_voice@onlinestudylist.com>
Message-ID:
<f0e3fd8b0903142134i2f0c0cf6xb99658dbcc980...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I'm having a problem getting a call from HQ to BR2 through the GK.

I'm assuming the DCF indicated in the debug RAS means some part of the 
setup

between UCM and BR2 is not working
but can't pinpoint it.

-


debug gatekeeper main 10 indicates the request is coming from UCM

: gk_rassrv_arq: arqp=0x83E0AD08, crv=0xB, answerCall=0
: gk_dns_query: No Name servers
: rassrv_get_addrinfo: (1#3001) Matched tech-prefix 1#
: rassrv_get_addrinfo: (1#3001) Matched zone prefix 3 and remainder 001
: rassrv_arq_select_viazone: about to check the source side,
src_zonep=0x83E0EFB0
rassrv_arq_select_viazone: matched zone is UCM, and z_invianamelen=0
: rassrv_arq_select_viazone: about to check the destination side,
dst_zonep=0x83E0EFB0
: rassrv_arq_select_viazone: matched zone is UCM, and z_outvianamelen=0
gk_rassrv_arq: arqp=0x83B6CA74, crv=0x10, answerCall=1

AND debug RAS on BR 2 indicates the request is making it to the GW


Mar 15 04:13:46.770: %FAN-3-FAN_FAILED: Fan 3 had a rotation error 
reported.

Mar 15 04:13:47.522: h323chan_chn_process_read_socket
Mar 15 04:13:47.522: h323chan_chn_process_read_socket: fd=0 of type
LISTENING has data
Mar 15 04:13:47.526: h323chan_chn_process_read_socket

Mar 15 04:13:47.526: h323chan_chn_process_read_socket: fd=3 of type 
ACCEPTED

has data
Mar 15 04:13:47.526:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=3
h323chan_dgram_send:Sent UDP msg. Bytes sent: 134 to 104.255.1.1:1719 fd=2

Mar 15 04:13:47.526: RASLib::GW_RASSendARQ: ARQ (seq# 5788) sent to
104.255.1.1
Mar 15 04:13:47.534: h323chan_chn_process_read_socket
Mar 15 04:13:47.534: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:47.534:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2


Mar 15 04:13:47.534: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719] 
on

fd=2

Mar 15 04:13:47.534: ACF (seq# 5788) rcvdh323chan_dgram_send:Sent UDP msg.
Bytes sent: 103 to 104.255.1.1:1719 fd=2

Mar 15 04:13:47.538: RASLib::GW_RASSendDRQ: DRQ (seq# 5789) sent to
104.255.1.1
Mar 15 04:13:47.542: h323chan_chn_process_read_socket
Mar 15 04:13:47.542: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:47.542:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2


Mar 15 04:13:47.542: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719] 
on

fd=2

Mar 15 04:13:47.542: DCF (seq# 5789) rcvd
Mar 15 04:13:47.550: h323chan_chn_process_read_socket

Mar 15 04:13:47.550: h323chan_chn_process_read_socket: fd=3 of type 
ACCEPTED

has data
Mar 15 04:13:47.550:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=3
h323chan_dgram_send:Sent UDP msg. Bytes sent: 81 to 104.255.1.1:1719 fd=2

Mar 15 04:13:48.522: RASLib::GW_RASSendRRQ: RRQ (seq# 5790) sent to
104.255.1.1
Mar 15 04:13:48.526: h323chan_chn_process_read_socket
Mar 15 04:13:48.526: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:48.526:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2


Mar 15 04:13:48.526: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719] 
on

fd=2

Mar 15 04:13:48.526: RCF (seq# 5790) rcvd




BR2
Int loop 0
h323-gateway voip interface
h323-gateway voip id UCM ipaddr 104.255.1.1 1719
h323-gateway voip h323-id CME-GW
h323-gateway voip tech-prefix 1#
h323-gateway voip bind srcaddr 104.255.3.1

dial-peer voice 2 voip
translation-profile incoming pstn-in
incoming called-number .
dtmf-relay h245-alphanumeric

HQ-GK

gatekeeper
zone local UCM ipexpert.com 104.255.1.1
zone prefix UCM 1... gw-priority 10 cmtrunk_2
zone prefix UCM 1... gw-priority 9 cmtrunk_1
zone prefix UCM 1.......... gw-priority 9 cmtrunk_2
zone prefix UCM 1.......... gw-priority 0 CME-GW
zone prefix UCM 2... gw-priority 10 cmtrunk_2
zone prefix UCM 2... gw-priority 9 cmtrunk_1
zone prefix UCM 34* gw-priority 10 CME-GW
zone prefix UCM 34* gw-priority 0 cmtrunk_2 cmtrunk_1
zone prefix UCM 3... gw-priority 10 CME-GW
zone prefix UCM 3... gw-priority 0 cmtrunk_2 cmtrunk_1
no shutdown
-------------- next part --------------
An HTML attachment was scrubbed...

URL: 
http://onlinestudylist.com/pipermail/ccie_voice/attachments/20090315/1f9e2d24/attachment-0001.htm


------------------------------

Message: 4
Date: Sun, 15 Mar 2009 05:47:34 +0100
From: basant yadav <basant.ya...@gmail.com>
Subject: Re: [OSL | CCIE_Voice] 3xxx call from HQ to BR2 through GK
To: Scott ODonnell <scott.odonn...@gmail.com>
Cc: OSL Group <ccie_voice@onlinestudylist.com>
Message-ID:
<4a2451a70903142147w54cf8636yba89ae61d40f2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Scott

I do not much about RAS messages but coming to the basics here, I see the
following in the Gatekeeper Debugs:-

: rassrv_get_addrinfo: (1#3001) Matched zone prefix 3 and remainder 001

which means GK did found the path for the call correctly using zone prefix
of "3".

Now first thing, we should check here is whether the incoming call is
hitting the correct dial-peer on CME GW (In your case its '2"). I am
assuming it does since you have "incoming called-number" set as "." in

there. But what is the "translation-profile incoming pstn-in" converting 
the

"1#3001" to? Remember GK nevers strips anything so on CME-GW, you should
have received "1#3001" and it should get converted to DN "3001" using the
translation profile.

HTH

- Basant


On Sun, Mar 15, 2009 at 5:34 AM, Scott ODonnell 
<scott.odonn...@gmail.com>wrote:



I'm having a problem getting a call from HQ to BR2 through the GK.
I'm assuming the DCF indicated in the debug RAS means some part of the
setup between UCM and BR2 is not working
but can't pinpoint it.

-


debug gatekeeper main 10 indicates the request is coming from UCM

: gk_rassrv_arq: arqp=0x83E0AD08, crv=0xB, answerCall=0
: gk_dns_query: No Name servers
: rassrv_get_addrinfo: (1#3001) Matched tech-prefix 1#
: rassrv_get_addrinfo: (1#3001) Matched zone prefix 3 and remainder 001
: rassrv_arq_select_viazone: about to check the source side,
src_zonep=0x83E0EFB0
 rassrv_arq_select_viazone: matched zone is UCM, and z_invianamelen=0
: rassrv_arq_select_viazone: about to check the destination side,
dst_zonep=0x83E0EFB0
: rassrv_arq_select_viazone: matched zone is UCM, and z_outvianamelen=0
 gk_rassrv_arq: arqp=0x83B6CA74, crv=0x10, answerCall=1

AND debug RAS on BR 2 indicates the request is making it to the GW

Mar 15 04:13:46.770: %FAN-3-FAN_FAILED: Fan 3 had a rotation error
reported.
Mar 15 04:13:47.522: h323chan_chn_process_read_socket
Mar 15 04:13:47.522: h323chan_chn_process_read_socket: fd=0 of type
LISTENING has data
Mar 15 04:13:47.526: h323chan_chn_process_read_socket
Mar 15 04:13:47.526: h323chan_chn_process_read_socket: fd=3 of type
ACCEPTED has data
Mar 15 04:13:47.526:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=3

h323chan_dgram_send:Sent UDP msg. Bytes sent: 134 to 104.255.1.1:1719 
fd=2


Mar 15 04:13:47.526: RASLib::GW_RASSendARQ: ARQ (seq# 5788) sent to
104.255.1.1
Mar 15 04:13:47.534: h323chan_chn_process_read_socket
Mar 15 04:13:47.534: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:47.534:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2

Mar 15 04:13:47.534: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719]
on fd=2


Mar 15 04:13:47.534: ACF (seq# 5788) rcvdh323chan_dgram_send:Sent UDP 
msg.

Bytes sent: 103 to 104.255.1.1:1719 fd=2

Mar 15 04:13:47.538: RASLib::GW_RASSendDRQ: DRQ (seq# 5789) sent to
104.255.1.1
Mar 15 04:13:47.542: h323chan_chn_process_read_socket
Mar 15 04:13:47.542: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:47.542:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2

Mar 15 04:13:47.542: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719]
on fd=2

Mar 15 04:13:47.542: DCF (seq# 5789) rcvd
Mar 15 04:13:47.550: h323chan_chn_process_read_socket
Mar 15 04:13:47.550: h323chan_chn_process_read_socket: fd=3 of type
ACCEPTED has data
Mar 15 04:13:47.550:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=3
h323chan_dgram_send:Sent UDP msg. Bytes sent: 81 to 104.255.1.1:1719 fd=2

Mar 15 04:13:48.522: RASLib::GW_RASSendRRQ: RRQ (seq# 5790) sent to
104.255.1.1
Mar 15 04:13:48.526: h323chan_chn_process_read_socket
Mar 15 04:13:48.526: h323chan_chn_process_read_socket: fd=2 of type
CONNECTED has data
Mar 15 04:13:48.526:  h323chan_chn_process_read_socket: h323chan
accepted/connected fd=2

Mar 15 04:13:48.526: h323chan_dgram_recvdata:rcvd from [104.255.1.1:1719]
on fd=2

Mar 15 04:13:48.526: RCF (seq# 5790) rcvd




BR2
Int loop 0
 h323-gateway voip interface
 h323-gateway voip id UCM ipaddr 104.255.1.1 1719
 h323-gateway voip h323-id CME-GW
 h323-gateway voip tech-prefix 1#
 h323-gateway voip bind srcaddr 104.255.3.1

dial-peer voice 2 voip
 translation-profile incoming pstn-in
 incoming called-number .
 dtmf-relay h245-alphanumeric

HQ-GK

gatekeeper
 zone local UCM ipexpert.com 104.255.1.1
 zone prefix UCM 1... gw-priority 10 cmtrunk_2
 zone prefix UCM 1... gw-priority 9 cmtrunk_1
 zone prefix UCM 1.......... gw-priority 9 cmtrunk_2
 zone prefix UCM 1.......... gw-priority 0 CME-GW
 zone prefix UCM 2... gw-priority 10 cmtrunk_2
 zone prefix UCM 2... gw-priority 9 cmtrunk_1
 zone prefix UCM 34* gw-priority 10 CME-GW
 zone prefix UCM 34* gw-priority 0 cmtrunk_2 cmtrunk_1
 zone prefix UCM 3... gw-priority 10 CME-GW
 zone prefix UCM 3... gw-priority 0 cmtrunk_2 cmtrunk_1
 no shutdown


-------------- next part --------------
An HTML attachment was scrubbed...

URL: 
http://onlinestudylist.com/pipermail/ccie_voice/attachments/20090315/152b9ff0/attachment.htm


------------------------------

_______________________________________________
CCIE_Voice mailing list
CCIE_Voice@onlinestudylist.com
http://onlinestudylist.com/mailman/listinfo/ccie_voice


End of CCIE_Voice Digest, Vol 37, Issue 96

****************************************** 
















    











					Reply via email to