[h323plus] h323ep.cxx - Number translation problems.

[Francisco Olarte]

Hi Jan:

On Wed, Jul 22, 2015 at 7:20 PM, Jan Willamowius <jan at willamowius.de> wrote:
> Simon,
> different kinds of applications have different needs:
> Softphone type applications will probably want the rewrite, while
> gateway type applications probably don't (and will be somewhat
> surprised by the new 'feature'). Both use the Endpoint class. Thus
> we'll need a way to select the behavior.

That was what I was trying to explain / inquiry about.

Even in a softphone, I do not see the point, softphones have a
keyboard and can directly dial a at B instead of B##a. If the softphone
wants a 'polycom mode' because polycom phones do that translation when
dialing on a keypad, it should do it before passing the number to the
H323endpoint ( it may derive & wrap, but I do not think that is
correct ).

I do not even understand where the @ is used. If it is used in some
kind of polycom gateway/pbx then this chunk of code would only be
useful to be able to dial into it from an h323+ app which receives
pure dialed digits ( like, let's say, an h323-isdn gw ). This
application could very easily do it before passing the remoteParty
into makeCall. I fail to see a real use case for this.

And, if a gateway is using it, it should do the translation by itself.

I find this kind of magic transformations deeply disturbing, as they
forbid by default ( and in the current case, unless patched ) the
usage of perfectly legal ( and used, at least we've been routing all
calls here using them ) combinations. Luckily for me I could manage to
redesign my routing prefixes to avoid ## when I was bitten. But 1.26
also forbids #, which it translates to %. I doubt I can transform all
the routing patterns we've been putting in place during the last 15
years to avoid '#'. I could try '*', but it may be the next victim.

My position would be more along the way of putting a couple of empty
virtual hooks in the H323Endpoint class and, as a concession to the
polycom users, include a H323polycomEndpoint derived class with the
magic in place, so library users are perfectly aware of what they can
expect. This seem like we are tailoring the library, mutilating it to
accomodate some special cases. To me it feels like if we patched libC
to make strlen ( and strcmp/cpy ) ignore trailing spaces because some
users do not know how to rtrim() their strings.

Regards.
   Francisco Olarte.