Simon:
On Wed, Jul 22, 2015 at 5:05 PM, Simon Horne s.horne@packetizer.com wrote:
Jan Yes you are correct. "##" is commonly used by polycom devices to delimitate extensions behind a gatekeeper or gateway.
So you might dial 567890##1234 which indicates you are dialing extension 1234 behind gateway/gatekeeper at number 567890.
I do not understand the use case. You dial that on a polycom phone to access something behind a ¿ polycom ? gateway/gatekeeper ? or the polycom devices automatically dial this? Because h323ep is for use in something like softphones. In softphones you can dial @ easily.
I'm seriously loathed to change the default behavior because it is widely used however I might add a setting to disable that behavior if required. I will try to have something checked in this weekend.
I will maintain my diff meanwhile, as I need to dial # ( not ## now, but # is changed to % too ).
I'm strongly against forcing this kind of behaviour on every user by default. I mean, it seems to be acommodating some devices/programs which cannot dial 1234@567890, which I understand, but on the way, on its current incarnation, is making it imposible to use ## ( and, in 1.26.5 at least, a single # ) as dialed digits, which I use, know other people that uses and think its a legitimate use of the non-digit possible values of dialedDigits ( in fact, if I hadn't look at the 1.26 sources to see if ## translation was still there ALL my routing would have failed if I had upgraded to 1.26, or 1.25.5. It seems h323+ is being tailored to some special needs disregarding its use as a building block ).
Having said it, if you want it there, and enabled by default, I would ask for a change along the lines of isolating the special handling of remoteParty into a virtual method, something like calling 'remoteParty=specialPartyNameTransformer(remoteParty)'. This makes it easy to patch it away ( which I will need to do ) or to override it in a derived class ( which, in the case I found the problem, compiling Yate with h323+, can also be done with a little patch by overriding the transformer method to return the argument in the YateH323Endpoint class ). I also think this would make the code more clear and modular. I can try to make the patch if you are too busy, I'm not as familiar as you with the H323ep inner workings but this is just string transformation stuff.
I would still like to have the code factored out even if you add a setting to disable the behaviour, as I need a ( patched ) library which respect my numbers to work with, as not all the programs I use can be easily patched / modified to change the setting. Also, if the setting is just used to conditionalize the remoteParty transformations it is easy to get confused and do something like '*#*' => '.@.' in the future and put it outside the conditional path. And also, I've found that for this kind of transformation a method is better, as once you hit the pattern of transformation you are looking for you can return the transformed value if further patterns need not be applied, or must be avoided.
Regards. Francisco Olarte.