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.
Regards, Jan
Simon Horne 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'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.
Simon
-----Original Message----- From: h323plus [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Jan Willamowius Sent: Thursday, July 23, 2015 12:51 AM To: h323plus@lists.packetizer.com Subject: Re: [h323plus] h323ep.cxx - Number translation problems.
Hi Francisco,
I would agree that this kind of transformation should not be forced onto every application.
My suggestion would be that you make a patch so applications can decide if they want the transformation or not. And then we add the patch into H323Plus instead of you keeping a permanent diff.
Simon, maybe you can weight in. I'm pretty sure you know applications that rely on the current behavior. ;-)
Regards, Jan
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
Francisco Olarte wrote:
A little background info: We use yate with h323plus to make calls, currently h323+ 1.25.0, yate 5.5.
In our system we use '#' extensively to delimit routing info ( as we use variable length prefixes, this makes them unique and we can distinguish between 10+347... and 103+47....).
But one day we used ## in a special prefix and the calls began to fail. We saw yate thar when dialing "0##666#88820334661" we ended up with the following ( every phne number redacted, cut last six numbers of phones for privacy ) pdu in the gatekeeper:
admissionRequest { requestSeqNum = 32114 callType = pointToPoint <<null>> endpointIdentifier = 12 characters { .... } destinationInfo = 1 entries { [0]=url_ID "666%2388820334661@0" } ..... }
which lead to a rejected call. We expected something on the line ( from another PDU without double hash ):
admissionRequest { ... destinationInfo = 1 entries { [0]=dialedDigits "100#00543414" } ... }
like:
destinationInfo = 1 entries { [0]=dialedDigits "0##666#88820334661" }an url instead of "0#34666666666" to the gatekeeper. After further examination we found the following in h323+ 1.25.0:
[src]$ fgrep -R -C7 '"##"' h323plus/ h323plus/src/h323ep.cxx-PBoolean H323EndPoint::ParsePartyName(const PString & _remoteParty, h323plus/src/h323ep.cxx- PString & alias, h323plus/src/h323ep.cxx- H323TransportAddress & address) h323plus/src/h323ep.cxx-{ h323plus/src/h323ep.cxx- PString remoteParty = _remoteParty; h323plus/src/h323ep.cxx- h323plus/src/h323ep.cxx- // Support [address]##[Alias] dialing h323plus/src/h323ep.cxx: PINDEX hash = _remoteParty.Find("##"); h323plus/src/h323ep.cxx- if (hash != P_MAX_INDEX) { h323plus/src/h323ep.cxx- remoteParty = "h323:" + _remoteParty.Mid(hash+2) + "@" + _remoteParty.Left(hash); h323plus/src/h323ep.cxx- PTRACE(4, "H323\tConverted " << _remoteParty << " to " << remoteParty); h323plus/src/h323ep.cxx- } h323plus/src/h323ep.cxx- h323plus/src/h323ep.cxx- //check if IPv6 address h323plus/src/h323ep.cxx- PINDEX ipv6 = remoteParty.Find("::");
Well, it seems some function which should ( IMO ) be in the gatekeeper or the dialer as been grafted inside the generic endpoint code. Not too big a problem. We just developed a patch to zap the code patch and followed on. But then, we had a look ar h323plus 1.25.4 and found:
PString remoteParty = _remoteParty; // Support [address]##[Alias]
dialing
PINDEX hash = _remoteParty.Find("##"); if (hash != P_MAX_INDEX) { remoteParty = "h323:" + _remoteParty.Mid(hash+2) + "@" + _remoteParty.Left(hash); PTRACE(4, "H323\tConverted " << _remoteParty << " to " << remoteParty); } PINDEX phash = _remoteParty.Find("#"); if (phash != P_MAX_INDEX) { remoteParty.Replace("#","%"); PTRACE(4, "H323\tAdjusted " << remoteParty); } //check if IPv6 address PINDEX ipv6 = remoteParty.Find("::");
Which is worst, now we can even use a single #. I wonder what is the rationale for doing this kind of transformations. We are developing another patch for this, but fear the future. For me it looks like this is trying to overcome the limitations of some device so the user can dial URLs ? IP ? from the phone keyboard, but on the way they are destroying our routing, and as they are buried deep inside the lib ( where I personally think they shouldn't be ) they are tricky to detect and fix.
Shouldn't this kind of legal-number-destroying functionality be relegated to an overridable method, or just delegated to the client code? Is this going to go on ( I mean, more exotic translations on otherwise legal dialedDigits ) ? And I'm not the only one using '#' in the digits, some of our providers do it too.
Regards. Francisco Olarte.