[cisco-voip] CCM3.3(3) with gk-controlled hh25 trunk

[Giovanni Coriasco]

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 
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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20040610/ea4708ca/attachment-0001.html