[h323plus] h323ep.cxx - Number translation problems.

Jan Willamowius jan at willamowius.de
Wed Jul 22 14:30:33 EDT 2015


Hi,

I can understand the reasoning behind adding the rewrite for
softphones.

The room at 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 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.
> 



More information about the h323plus mailing list