[h323plus] Previous bug report...

Francisco Olarte folarte at peoplecall.com
Wed Nov 13 05:58:59 EST 2013


On Wed, Nov 13, 2013 at 10:58 AM, Jan Willamowius <jan at willamowius.de> wrote:
> what I fixed was a different issue where H323Plus endpoints wouldn't
> try to re-register. Francisco issue is which endpoint id is used.

Thanks, I was trying to analyze that commit ( which seemed totally
unrelated ) when your message popped, that saved me a lot of work.

> I can reproduce the issue Francisco reports with GnuGk when I set
> AcceptEndpointIdentifier=0. With that setting H323Plus endpoints will
> keep sending their old endpoint identifier, even if the gatekeeper
> assigned them a new identifier after a full RRQ.

I will then consider this a bug. Presently we have made our gatekeeper
resistant to this behaviour by implementing something like your
AcceptEndpointIdentifier flag in our gatekeeper, it basically is a one
(logical) line modification of
H323GateKeeperServer::CreateRegisteredEndpoint in gkserver.cxx ( plus
one boolean member and a little logic to set it from our config file
). I've shamelessly copied you idea of controlling it via a flag. In
case it is useful for someone our new method is:

H323RegisteredEndPoint *
gk_server::CreateRegisteredEndPoint(H323GatekeeperRRQ & request) {
  return new reg_ep(*this,
                    CSTR(accept_ep_identifier &&
                         ? request.rrq.m_endpointIdentifier.GetValue()
                         : CreateEndPointIdentifier()

( gk_server and reg_ep are our derived classed )
I analized the code paths to assert that no endpoint with RRQ
endpointIdentifier could be in the gatekeeper when this method is
reached, which seemed correct.

I think the same behaviour could be bolted into the standard
gkserver.cxx, making it more robust on the presence of undisciplined
endpoints, by just adding the flag to it and using the appropiate

With this behaviour our system works with both h32plus v1.18 ( some
legacy code we have ), v1.24, v1.25 and v1.25 with patches 1.23&24
reverted in gkclient and with the one I previously sent ( which I'm
considering reverting it, as my patch contains an if(!empty) which I
think is erroneous, as EndpointIdentifier seems to be defined as

EndpointIdentifier      ::=     BMPString (SIZE(1..128))

which means it will never be empty, and it should fail on decoding.

> I believe the change in gkclient.cxx should be reverted so the
> endpointIdentifier provided by the gatekeeper in RCF should
> unconditionally be used, not only if the id was empty before.

FWIW, before modifying my gatekeeper I reverted patches v1.23 & 24
from h323plus 1.25, and it worked fine, the endpoints started working.
So presently I'm doubly protected, as my patched h323plus sends the
endpointIdentifier received in the LAST RCF, instead of the first, and
my gatekeeper uses the endpointIdentifier passed from the endpoint if

I think the wording is unclear in the little documents I have, they
just says "endpointIdentifier – A gatekeeper assigned terminal
identity string; shall be echoed in subsequent
RAS messages.", but omits to say what to do if the endpoint has
received more than one. Even though, I think the logical thing to do
in this protocolos is to always echo the last one.

I'll continue on upgrading all our machines to v1.25, patched, and our
gatekeepers to the new release. If you want some test or any other
thing, I'll monitor this and try to do what I can.

Francisco Olarte.

More information about the h323plus mailing list