<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<tt>Hi all,<br>
I'm sorry because this is gonna be a very long mail...<br>
<br>
<br>
I'm using a voip architecture with the following devices:<br>
<br>
- 2 Cisco CallManager 3.3(3)sr4a in CLUSTER<br>
- Cisco AS5300 IOS 12.2(10b)<br>
</tt><tt>- Gatekeeper GnuGk version 2.0.7<br>
- H.323 Client OpenH323 OpenPhone version 1.9.1<br>
- Cisco PIX Firewall version 6.3(3)<br>
<br>
The network logical configuration looks like the following:<br>
<br>
<br>
|------| |---------| |------------| |--------------|<br>
| PSTN +----+ AS 5300 +-----+ CM cluster | | H.323 Client |<br>
|------| |---------| |---------+--| |------+-------|<br>
| |<br>
| |<br>
| |<br>
|--------------------------------------------------------------|<br>
| internal network |<br>
| |<br>
| PIX 1 |<br>
| |<br>
| external network |<br>
|--------------------------------------------------------------|<br>
| |<br>
| |<br>
| |<br>
|--------------------------------------------------------------|<br>
| external network |<br>
| |<br>
| PIX 2 |<br>
| |<br>
| DMZ |<br>
|--------------------------------------------------------------|<br>
| |<br>
| |<br>
|---+------------------+--|<br>
| Gatekeeper |<br>
|-------------------------|<br>
<br>
<br>
The device configuration is the following:<br>
<br>
- The gatekeeper resides in DMZ, while the other devices are in the
internal network<br>
- The gatekeeper works in Gatekeeper-routed mode (with no H.245 routing)<br>
- The H.323 Client registers to the gatekeeper<br>
- The CallManager registers to the gatekeeper through an H.225 Trunk<br>
- The AS5300 is declared on the CallManager as an H.323 gateway<br>
<br>
The scenario is when the H.323 Client places a call the must be routed
toward the PSTN.<br>
In this case, when the client starts the call, H.225 protocol routed
from the client, to the gatekeeper, then to the CallManager (through
the 2 PIX firewalls) and finally to the AS5300. Then, H.245 protocol
takes almost the same path with the difference that does not go throgh
the PIX and the gatekeeper but is exchanged directly between the
CallManager and the client.<br>
<br>
NOW LET'S COME INTO MY TWO PROBLEMS (sorry for the VERY LONG
introduction!).<br>
<br>
- THE FIRST PROBLEM:<br>
<br>
If the client starts the call using FastConnect (or FastStart if you
prefer...) in H.225 SETUP, then everything works fine, if I remove the
2 PIX between the gatekeeper and the inetrnal network. In case the 2
PIX are present, they do not recognize the FastConnect SETUP as a H.225
SETUP and then blocks the following H.225 messages on the TCP
connection established while sending th SETUP: "PIX 2" issues the
following error:<br>
<br>
H225 message CALL PROCEEDING received from
<gk_ip_address>/<gk_tcp_port> to </tt><tt><client_ip_address>/<client_tcp_port></tt><tt>
before SETUP<br>
<br>
I also tried to create static access lists on the 2 PIX (in order to
allow all IP traffic between client and gatekeeper) and to deactivate
H.323 FixUp on both PIX, BUT NOTHING CHANGES!<br>
What is more strange is that the gatekeeper routes the FastConnect
SETUP to the CallManager, but "PIX 1" doesn't block the following
CallProceeding (I have to say that the 2 PIX configurations are almost
exactly symmetrical!!)<br>
<br>
- THE SECOND PROBLEM:<br>
<br>
I tried to deactivate FastConnect feature on the client (and thus on
the gatekeeper), but thus the CallManager works in a strange way
(strange at least for me).<br>
In that case everything works till when the gateway send the H.225
PROGRESS message containing its H245Address: after that the H.245
channel is opened and then the Logical Audio Channel too (so that I can
hear in-band pre-connect media, such us ringing tones); when the called
party answers the call, the gateway sends an H.225 CONNECT message
(with the same H245Address) to the CallManager. This CONNECT message
looks correct to me, but the CallManager seems not to care about it
and, after a 7 seconds timeout, sends a H.245 EndSession and a H.225
RELEASECOMPLETE messages to the gateway, thus dropping the call.<br>
To avoid this, I configured the gatekeeper IP address on the
CallManager also as a H.323 client. In this case, the CallManager does
not care about the </tt><tt>H245Address in the PROGRESS from the
gateway but only about the one in the CONNECT: thus, the H.245 channel
and the Logical Audio Channel are opened only when the called party
answers the call (thus loosing all in-band pre-connect media), but the
call remains up after the CONNECT. Another strange thing is that this
works with only one of the two CallManager in the cluster (the other
CallManager keeps having the problem desribed above).<br>
<br>
<br>
<br>
Could anyone explain to me the cause of at least one of these problems?<br>
<br>
Thanks in advance.<br>
<br>
Giovanni Coriasco<br>
</tt>
</body>
</html>