22 Jan
2016
22 Jan
'16
1:58 p.m.
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@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