[h323plus] H323EndPoint::ParsePartyName issue

[Jan Willamowius]

Hi Iurii,

I would argue that h323:@192.168.1.1:1726 is an invalid party name
(but we could still parse it better).

If you want to propose a fix, it would be great if we could have all
the code changes in H323Plus, because we can't keep up with the ever
changing PTLib.

Regards,
Jan

-- 
Jan Willamowius, Founder of the GNU Gatekeeper Project
EMail  : jan at willamowius.de
Website: http://www.gnugk.org
Support: http://www.willamowius.com/gnugk-support.html

Relaxed Communications GmbH
Frahmredder 91
22393 Hamburg
Geschäftsführer: Jan Willamowius
HRB 125261 (Amtsgericht Hamburg)
USt-IdNr: DE286003584

Iurii Gordiienko wrote:
> Hi, 
> I'm working with ForwardCall functional and have found a bug if we have forward URL which contains PORT number. For example, for h323:@192.168.1.1:1726 input string H323EndPoint::ParsePartyName will make address string like ip$192.168.1.1:1726:1726. 
> The fix is trivial (may be I've not covered all cases): 
>   // get the various parts of the name   PString hostOnly = PString();   PINDEX userPos = remoteParty.Find('@');   if (userPos != P_MAX_INDEX) {     if (gatekeeper != NULL)       alias = url.AsString();     else {       alias = remoteParty.Left(userPos);       PINDEX portPos = remoteParty.FindLast(':', portPos + 1);       PINDEX len = (portPos != P_MAX_INDEX) ? (portPos - userPos - 1) : P_MAX_INDEX;       hostOnly = remoteParty.Mid(userPos+1, len);     }   } else {      alias = url.GetUserName();      hostOnly = url.GetHostName();   }    address = hostOnly; 
> 
> 
> Also we have similar issue for input string without '@' character. In this case PTLIB::PURL class wrong parse the string (uses 192.168.1.1:1726:1726 as USER). 
> To fix this issue we need look PTLIB::PURL class futher. 
> Thanks -- Iurii Gordiienko