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.