Re: [h323plus] h323ep.cxx - Number translation problems.

-- 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. >