[h323plus] h323ep.cxx - Number translation problems.

Jan Willamowius jan at willamowius.de
Wed Jul 22 13:20:19 EDT 2015


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 at lists.packetizer.com] On Behalf Of
> Jan Willamowius
> Sent: Thursday, July 23, 2015 12:51 AM
> To: h323plus at 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 at 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 at 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.
> > 



More information about the h323plus mailing list