An interesting this is that H.323 specs introduce a concept of access tokens, but do not define it precisely. And the problem is more serious, as each endpoint vedor will copy or not selected tokens from ACF/LCF into Setup. Maybe someone did more tests regaring this issue.
My idea is that access tokens is everything inside clear tokens and nestedCryptoTokens that is not an H.235 stuff or a vendor specific stuff and therefore should be copied transparently from xCF messages into Setup.
----- Original Message ----- From: "Tamas J" <thomasj@xxxxxxxxx>
Sent: Tuesday, February 01, 2005 5:23 PM
Tuesday, February 1, 2005, 5:03:45 PM, Zygmuntowicz wrote: ZM> I am not sure if I understood you correctly. GW2 HAS ZM> to ask GK2 for admission EACH TIME it is making ZM> or receiving a call. I assume it is registered with GK2. Yes, in case it is registered under GK2. Hmm, from this I see, that GW2 has no chance to know if the call was previously accepted by GK2 (only in case there is token or any mark from GK2). I just wanted to find a simpler case, but looks like it's the same case, just in my case GW2 is a GNUgk. Your previouse idea [putting some access token into LCF] would need the ability to handle (or pass through) such tokens on the remote side, right? [which is not known - can be another type of GK]. What do standards say about such case? [Unfortunately I'm don't know h.323 into deep details]
ZM> You can take a look at OSP protocol. Both gatekeepers ZM> could communicate with an OSP server to validate a single ZM> access token. In fact, if GW2 would be a permanent endpoint ZM> (not actually registered with GK2) and support OSP, it could ZM> ask the OSP server in the very same way as GK2. ZM> It's possible that we will have OSP support soon, if I find some ZM> time and system to test. Yes, I noticed that openh323 has OSP support now, took a look for some overviews about OSP and it can be interesting. However using OSP in GK will require to use an OSP server as well, IMO. As far as I know, there is not any open-source OSP server (I only know TransNexus's implementation which I guess is not open-source, maybe some client parts?). (good old days when we used as5300 with OSP :)
ZM> In general, any method with a single token and a single auth ZM> server should allow such calls (maybe H.501 can do that too, ZM> like OSP). OSP is a fairly standard protocol and seems to become ZM> widespreaded in carrier networks. I will look again for OSP and maybe for H.501 as well.
Thanks for suggestions and ideas!
Tamas
ZM> ----- Original Message ----- ZM> From: "Tamas J" <thomasj@xxxxxxxxx>
ZM> Sent: Tuesday, February 01, 2005 4:48 PM
Tuesday, February 1, 2005, 3:53:13 PM, Zygmuntowicz wrote: ZM> I think the correct implementation would return some access tokens ZM> in LCF, which then should be put into ACF and finally land inside ZM> a Setup sent to the gatekeeper. Then the gatekeeper can grant an access ZM> based on the token.
Does it mean that no such thing is implemented yet? In a simpler scenario: gw1->gk1->gk2->gw2 when both GKs are in direct mode, how can gw2 know that the call (setup) coming from gw1 was accepted in case gw2 is not registered under gk2 (so gw2 won't ask gk2 back)? How other gatekeepers/systems solve such case?
Regards, Tamas
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
