Hi Jan:
On Wed, Jul 22, 2015 at 7:20 PM, Jan Willamowius jan@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@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.