Some hours ago I've reported what I thought, and still think, is a bug
in the treatement of endpoint identifiers on received RCF in
gkclient.cxx.
As the gatekeeper which is having problems with them is one of mine,
which is derived from gkserver.cxx, I decided to investigate further.
I tried to look at what gnugk does in it's sources, and it seems it
uses the received endpoint identifier and thus avoids this problem,
but I've not been able to totally verify it.
But looking at gkserver.cxx, which I know a little better, I've
noticed that the first time it receives a keepalive after a reboot it
does not know the endpoint, so it requests a full registration, so far
so good.
Then when the new full registration arrives OnFullRegistration ends up doing
// Need to create a new endpoint object
info.endpoint = CreateRegisteredEndPoint(info);
Which leads to:
H323RegisteredEndPoint *
H323GatekeeperServer::CreateRegisteredEndPoint(H323GatekeeperRRQ &)
{
return new H323RegisteredEndPoint(*this, CreateEndPointIdentifier());
}
If this method is changed to something like:
return new H323RegisteredEndPoint(*this,
info.rrq.HasOptionalField(H225_RegistrationRequest::e_endpointIdentifier)
? info.rrq.m_endpointIdentifier
: CreateEndPointIdentifier()
);
My Gatekeeper ( and any gatekeeper built using h323plus gkserver )
will accept this kind of behaviour ( ie, where the endpoint DOES NOT
USE the endpoint id received in the RCF as I think it should do ) ( in
the line of be strict in what you send and tolerant in what you accept
).
Does this seem correct? If so I can send make a send a patch for this
( basically, the above line after testing ).
Francisco Olarte.
