<!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">
Hi.<br>
Thanks, but that architecture is not the one I'm interested in. I need
a gatekeeper, and it must be placed in DMZ...<br>
<br>
Ciao,<br>
Giovanni<br>
<br>
Oleg Shevtsov wrote:<br>
<blockquote cite="mid20040610102908.GC47871@interexc.com" type="cite">
<pre wrap="">Hi Giovanni,
thank you for your realy big and full description.
Seems that smoke kills Cisco developers;).
Call proceeding message failure says that PIX 2 probably is
not adopted to handle one call crossing PIX twice.
GK logs can contain very usefull information about the h225.
Becase opening h225 and h245 using two different network paths,
throught the PIXes is a real trouble.
I can't estimate time you are going to loose with all that 2 PIXes,
but I can strongly recommend to stop with this architecture and
find softswitch or session board controller which implements
GK functions and real proxy.
Using proxy your scheme can be easy transformed to:
|------| |---------| |------------| |--------------|
| PSTN +----+ AS 5300 | | CM cluster | | H.323 Client |
|------| |----+----| |------+-----| |------+-------|
| | |
-----------------+----------------------
|
internal softswitch interface |
|------+-----|
| Softswitch |
|------+-----|
|
external softswitch interface |
In this case you will have authorization and billing center at the
softswitch, and your CM will be IP PBX, connected to the Softswitch.
Internal calls can be easy routed in the internal network.
Most natural several-interfaces-work implementation is in IXC
softswitch: softswitch sends packets from interface to which inbound
call was connected(to the originator) and establishes outgoing signalling
and sends packets using hunt interface group.
This is the main features, can be very usefull in your case.
Sorry for long email.
On Thu, Jun 10, 2004 at 11:09:18AM +0200, Giovanni Coriasco wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
I'm sorry because this is gonna be a very long mail...
I'm using a voip architecture with the following devices:
- 2 Cisco CallManager 3.3(3)sr4a in CLUSTER
- Cisco AS5300 IOS 12.2(10b)
- Gatekeeper GnuGk version 2.0.7
- H.323 Client OpenH323 OpenPhone version 1.9.1
- Cisco PIX Firewall version 6.3(3)
The network logical configuration looks like the following:
|------| |---------| |------------| |--------------|
| PSTN +----+ AS 5300 +-----+ CM cluster | | H.323 Client |
|------| |---------| |---------+--| |------+-------|
| |
| |
| |
|--------------------------------------------------------------|
| internal network |
| |
| PIX 1 |
| |
| external network |
|--------------------------------------------------------------|
| |
| |
| |
|--------------------------------------------------------------|
| external network |
| |
| PIX 2 |
| |
| DMZ |
|--------------------------------------------------------------|
| |
| |
|---+------------------+--|
| Gatekeeper |
|-------------------------|
The device configuration is the following:
- The gatekeeper resides in DMZ, while the other devices are in the
internal network
- The gatekeeper works in Gatekeeper-routed mode (with no H.245 routing)
- The H.323 Client registers to the gatekeeper
- The CallManager registers to the gatekeeper through an H.225 Trunk
- The AS5300 is declared on the CallManager as an H.323 gateway
The scenario is when the H.323 Client places a call the must be routed
toward the PSTN.
In this case, when the client starts the call, H.225 protocol routed
</pre>
</blockquote>
<pre wrap=""><!---->>from the client, to the gatekeeper, then to the CallManager (through the
</pre>
<blockquote type="cite">
<pre wrap="">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.
NOW LET'S COME INTO MY TWO PROBLEMS (sorry for the VERY LONG introduction!).
- THE FIRST PROBLEM:
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:
H225 message CALL PROCEEDING received from <gk_ip_address>/<gk_tcp_port>
to <client_ip_address>/<client_tcp_port> before SETUP
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!
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!!)
- THE SECOND PROBLEM:
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).
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.
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 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).
Could anyone explain to me the cause of at least one of these problems?
Thanks in advance.
Giovanni Coriasco
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>