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.
