Hi,
I created a patch for this.
Under config.ini I added new field SourceInfoIsGKID. If 1 then it will use GkID Otherwise if 0 endpoint alias id.
[RasSrv::LRQFeatures]
NeighborTimeout=5
;ForwaredHopCount=2
;AlwaysForwardLRQ=0
;AcceptForwardedLRQ=1
;IncludeDestinationInfoLCF=1
ciscoGKCompatible=1
SourceInfoIsGKID=1
In RasSrv.cxx I added
bool NeighborList::Neighbor::InternalSendLRQ(int seqNum, const H225_AdmissionRequest & obj_arq, H323RasSrv *RasSrv, const endptr & e) const
{
PIPSocket::Address ip = m_ip;
if (m_dynamic && !ResolveName(ip))
return false;
H225_RasMessage obj_ras;
obj_ras.SetTag(H225_RasMessage::e_locationRequest);
H225_LocationRequest & obj_lrq = obj_ras;
obj_lrq.m_requestSeqNum.SetValue(seqNum);
obj_lrq.m_replyAddress = RasSrv->GetRasAddress(ip);
obj_lrq.m_destinationInfo = obj_arq.m_destinationInfo;
// tell the neighbor who I am
obj_lrq.IncludeOptionalField(H225_LocationRequest::e_sourceInfo);
//*********Patch Starts Here**********************
if(Toolkit::AsBool(GkConfig()->GetString(LRQFeaturesSection, "SourceInfoIsGKID", "0")))
{
PStringArray gkIDName(RasSrv->GetGKName());
H323SetAliasAddresses(gkIDName,obj_lrq.m_sourceInfo);
}
else
obj_lrq.m_sourceInfo = e->GetAliases();
//**************Patch Ends Here********
obj_lrq.IncludeOptionalField(H225_LocationRequest::e_gatekeeperIdentifier);
obj_lrq.m_gatekeeperIdentifier = RasSrv->GetGKName();
RasSrv->GetGkClient()->SetPassword(obj_lrq, Toolkit::GKName());
.
.
.
.
}
Regards,
Freddy
-----Original Message-----
From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of
Zygmuntowicz Michal
Sent: Saturday, July 17, 2004 5:55 AM
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: LRJ from Cisco Gk
Thanks for this information. I think it will be good to have
an option to put gatekeeper name in LRQ sourceInfo instead
of copying source info from ARQ (especially when it is an answering
ARQ, which can contain in srcInfo anything).
This makes more sense with H.225 version 5, which introduced
a new LRQ field sourceEndpointInfo, which should contain
aliases copied from ARQ.
Also, after reading docs, it seems to me that the gatekeeperIdentifier
field is designed to be put in LRQ only by an endpoint to signal which
gatekeeper it is registered with and sourceInfo is the correct field
to put the gatekeeper identifier, when sending an LRQ by the gatekeeper.
Can anyone comment on this?
----- Original Message -----
From: "Freddy Parra" <fparra@xxxxxxxxxx>
Sent: Friday, July 16, 2004 4:41 PM
Hi,
I spoke to one of my providers that had told me recently that Gnugk was working fine with his 7200 Cisco Gatekeeper, which I had
posted on this list as working. Well it turns out that this is not the case, and its actually a 7206 Gatekeeper which I have
problems with like the other Provider Gatekeeper I am having problems with too. I"m actually sending traffic to his Cisco
Gatekeepers 3640 and 3660 which work fine. He says that he has many interpretability problems with Nextone and Gnugk sending to the
7206 Cisco Gatekeeper. I just like to clarify that mistake.
Here is some info I came across when conducting some test with one of my Provider's 7206 Cisco Gatekeeper:
I got Gnugk to receive back a LCF instead of a LRJ from my provider's 7206 Cisco Gatekeeper.What I did was install ohphone and
registered it with Gnugk with the same gatekeeper identifier as Gnugk. This works I don't know why but look at the sourceInfo and
gatekeeperIdentifier parameters below, they must both be gatekeeper identifier id's which my provider has set in their Cisco's
Gatekeeper. Now if I register the terminal with any other id that's not in the providers configuration list I get LRJ as is the case
with my Cisco since I have it set to an H323-id of AS5400MIA. But this should not matter(or should it?) for sourceinfo or does the
Cisco gatekeeper look at this sourceinfo also to determine access? I guess the bottom line here is whether sourceinfo plays a role
in determining whether I get back a LCF or a LRJ, which seems to be the case here for the 7206 Gatekeeper.
If this is the case then I can see two solutions to this problem:
1.) The provider must add all my gateway endpoint h323-ids in there configuration along with my gatekeeper identifier .
2.) Change the sourceinfo to be the same as the Gatekeeper Identifier before forwarding the LRQ to the Provider's Gatekeeper, but
I'm not sure what impact this will have on other different types of Gatekeeper.
I could not test this with any of my Cisco's since that would had required me to change my Cisco's h323 Id to the gatekeepers
identifier and currently I am running live traffic on it.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&opÌk
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49
Homepage: http://www.gnugk.org/
