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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
  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/


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux