Re: Problem with LRQ and LCF (GK 2.2.3-2)

[Andcop2005 Andcop2005 <andcop2005@xxxxxxxxx>]

Hi Michal,

 

I've tried this configuration. But I've forgotten to say GKs are configured as H.245/H.225 proxy.

With this option the LCF pass-through DGK, but the destination GK still rejects the originator GK SETUP and returns a RELEASE COMPLETE.

If I configure DGK as a H.225 signaling proxy it works ok, but I would not like to configure DGK  as proxy cause the call establishment could be delayed too much.

 

You can see the messagens exchanged among GK1 (caller), DGK and GK2 (cally) as follows: 

Source                Destination            Protocol             Info

Caller Client          Caller             H.225.0 RAS: admissionRequest

Caller                    DGK                H.225.0 RAS: locationRequest

DGK                    Cally                 H.225.0 RAS: locationRequest

Cally                    DGK                 H.225.0 RAS: locationConfirm

DGK                   Caller                H.225.0 RAS: locationConfirm

Caller                 Caller Client     H.225.0 RAS: admissionConfirm

Caller                Client Caller        H.225.0 CS: setup OpenLogicalChannel

Caller                  Cally                    H.225.0 CS: setup OpenLogicalChannel

Cally                    Caller                    H.225.0 CS: releaseComplete

Caller                 Caller Client         H.225.0 CS: releaseComplete

Caller Client          Caller                 H.225.0 CS: releaseComplete

Caller Client            Caller               H.225.0 RAS: disengageRequest

Caller                     Caller Client        H.225.0 RAS: disengageConfirm

 

 

 

Is there a way to solve this problem?

 

Thanks,

 

Anderson
 

On 10/10/05, Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote:

Try to configure DGK to pass-through signaling through itself,
so signaling connections are not established directly between gatekeepers
(ForwardedResponse=1).

----- Original Message -----
From: "Andcop2005 Andcop2005" <andcop2005@xxxxxxxxx>
Sent: Friday, October 07, 2005 9:02 PM


> I've got the following three scenarios. In all of them the GK don't know
> each other and need to ask DGK in due to establish calls between them.
> All GKs are configured to accept calls originated only from neighbors:
> AcceptNeighborsCalls=1
> AcceptUnregisteredCalls=0
> Scenario A work pretty well. Clients registered on A2 and A3 can establish
> calls one another with no problem.
>
> A)
> A-1) DirectoryGK (DGK): gnugk 2.0.9 or gnugk 2.2.3 or CISCO
> A-2) GK gnugk 2.0.9
> A-3) GK gnugk 2.0.9
> On scenarios B and C it does not work.
> I've already alternated the option "[RasSrv::Neighbors] / CiscoCompatible"
> to "0" and "1" on gnugk 2.0.9, and the option "[RasSrv::Neighbors] / Type"
> to "CiscoGK" and "GnuGK" on gnugk 2.2.3, but them keep not working.
> I've noticed that LRQ and LCF are performed, but the GK which sends LCF
> refuses the SETUP and the call are not established.
>  B)
> B-1) DirectoryGK (DGK): gnugk 2.0.9 or gnugk 2.2.3 or CISCO
> B-2) GK gnugk 2.2.3
> B-3) GK gnugk 2.0.9
>   C)
> C-1) DirectoryGK (DGK): gnugk 2.0.9 or gnugk 2.2.3 or CISCO
> C-2) GK gnugk 2.2.3
> C-3) GK gnugk 2.2.3
> Someone knows how can I configure scenarios B and C to work like scenario A
> does?
> Regards,
> P. Anderson



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/