Hi,
I can understand the reasoning behind adding the rewrite for softphones.
The room@IP (or IP##room) syntax is used a lot when dialing into MCUs for example (a lot as as in 80% of what some users dial). Since there is no consensus between the major vendors what is the 'right' syntax, most end users are utterly confused what to use. So even when the are able to dial the @, they might dial ## because they always did before...
Changing existing behavior in a framework is a very tricky decision. And H323Plus has always put a lot of effort into maintaining compatibility. But it is also a good thing if not every application has to code the same thing and the framework provides these bits and pieces that many applications want.
My preferred solution would be to factor rewrites as this one into a separate endpoint method ("ConvenienceRewrites()" ?) and have a switch if its called or not. I would default the switch to not do the rewrite, but since none of my apps is hurt either way, I'll leave it to you guys to battle out the implementation. ;-)
Regards, Jan
Francisco Olarte wrote:
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.