Hi,
I think changing the behavior of gkserver to work around a bug in gkclient doesn't make much sense.
The gatekeeper has the right to assign an endpoint ID and the endpoints should be prepared to accept it. Since gkserver is probably only used in legacy code, I would try to avoid changing the behavior.
Regards, Jan
Francisco Olarte wrote:
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.