[cisco-voip] Re: CCM3.3(3) with gk-controlled hh25 trunk
Giovanni Coriasco
giovanni.coriasco at csp.it
Thu Jun 10 07:29:31 EDT 2004
Hi.
Thanks, but that architecture is not the one I'm interested in. I need a
gatekeeper, and it must be placed in DMZ...
Ciao,
Giovanni
Oleg Shevtsov wrote:
>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:
>
>
>>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
>>
>>
>
>
>
>>_______________________________________________
>>cisco-voip mailing list
>>cisco-voip at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20040610/a20dce56/attachment-0001.html
More information about the cisco-voip
mailing list