why was this feature implemented in early versions (like 2.0.9), and it is not implemented in the current ones (2.2.X)?
Is there any specific reason for this?
Do you plan to implement this feature in new versions?
P. Anderson.
On 10/12/05, Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote:
The old (2.0.9) version kept a "siblings list", which was filled
with IP addresses found in LCFs. Therefore, unknown neighbors
were often seen as neighbors after receiving an LRQ from them
(sibling IP was extracted from the replyAddress field).
This simple solution has some drawbacks:
1. It does not work until the first LRQ is received from that neighbor
(which usually means you cannot call this neighbor until you have received
the first LRQ from it).
2. It does not work, when LRQ/LCF travel step-by-step back (ForwardResponse=1),
as the replyAddress in the LRQ is changed in DGK.
A solution to this problem could be using some kind of access tokens,
which are sent in LCF and inserted then into Setup. This is also not the best
solution (as there is not standarized method of doing this), but as long
as all gatekeepers are from the same vendor, it will work.
----- Original Message -----
From: "Andcop2005 Andcop2005" <andcop2005@xxxxxxxxx>
Sent: Tuesday, October 11, 2005 8:30 PM
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/
