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