November 2013 - h323plus - lists.packetizer.com

H.235 sample
by Cláudio Palludetti 22 Jan '14

22 Jan '14

Hi, We are developing an H.323 EP and we need to use the H.235. Is there any example using this? We are using h323plus V1.24.0 and we enabled the H.235. Thanks Claudio

4 7

My test results.
by Francisco Olarte 16 Nov '13

16 Nov '13

Well, after the exchanges regarding gkclient, and although the results are all the expected for this simple patches, I'll summarise my tests in case they are useful for anyone. I've done and tested this things to avoid my gkerver/gkclient problems. I expected no problems, and did not find any. 1.- Roll back 1.23&24 in gkclient.cxx against h323plus v1.25, basically unconditionallizing again the only endpointIdentifier assignement. All tests ok, as this leaves v1.25 behaving more or less like v1.24 2.- Apply the 1.48 in gkclient.cxx against v1.25, making it clear the endpoint identifier on full registration required. All tests ok again. This is the one I'll stick to while waiting for v1.26, as I expect to be able to get rid of it in the future. 3.- Both 1 and 2. I knew they are redundant but wanted to assert they worked in the test setup, all good again. Also I modified my gatekeeper as I posted to make it conditionally accept the endpoint identifier passed from the endpoint. All tests above worked with and without accepting endpoint identifiers. I'll keep this patch in case I encounter and endpoint with the unpatched v1.25 behaviour, as some of my endpoints are closed source. Bear in mind all tests are done in a simple scenario of a single ras only gatekeeper with endpoints registered on it, rebooting endpoints and gatekeeper in the middle. Francisco Olarte.

1 0

SonicWall/Dell wreck of a NAT
by Marek Podgorny 15 Nov '13

15 Nov '13

I have a problem with firewall that I cannot replace or reconfigure. The FW is a SonicWall, public IP on Internet side (of course), NAT on the LAN side, gatekeeper on a public address outside FW. Calls from EPs on NAT to outside world work but incoming calls fail. I wiresharked the traffic and found that the Q.931 setup ServiceControlIndication packet bounces from the FW. The reason for this is that while this particular packet is sent to UDP port previously used by the NATed EP RRQ, the FW fails to preserve NAT mapping table. SonicWall also ignores port preservation setting. Astonishingly, bi-directional access to UDP port 1719 works (SonicWall claims to support H.323 and it is possible to "activate" it. Maybe port 1719 becomes special). Therefore, here is my question: Is it possible to order H323Plus to only use outgoing UDP port 1719 for RAS signalling? Marek Podgorny +1 315 373-6345 >

2 3

Repository conversion
by Francisco Olarte 14 Nov '13

14 Nov '13

Hello everybody. After getting frustated with MY inability to view 'changesets' in the CVS repository for h323plus I decided to give cvs2svn a try, just to see how it came out. I've done a rsync dump of the 59Mb cvs repo at sourceforce and did a plain 'cvs2svn --encoding=latin_1', which seems seems to came out nicely. I can to be comming out nicely, it generated a trunk, a pboolean branch and several tags: ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/branches pboolean/ ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/tags plus_1_20/ v04/ v1_19_5/ v1_19_6/ v1_19_7/ v1_20_0/ v1_20_1/ v1_20_2/ v1_21_0/ v1_22_0/ v1_23/ v1_24_0/ v1_25_0/ ~/conv$ svn list file:///home/folarte/conv/h323plus-svn/trunk CVSROOT/ applications/ extensions/ h323plus/ As it is it serves my needs ( helping me see related files for backporting things into releases, and given the time it took I can ), but, as I think developers must be somehow familiar with subversion, ( as ptlib and lots of other projects use it ) I wonder if someone will be interested in converting the main repo. In this case I can try to build and tune a conversion script for better processing of things like the CVSROOT scripts and build a svn dump which could be tested and, if desired, imported. Francisco Olarte

3 2

gkserver does not use received endpoint identifier.
by Francisco Olarte 13 Nov '13

13 Nov '13

Some hours ago I've reported what I thought, and still think, is a bug in the treatement of endpoint identifiers on received RCF in gkclient.cxx. As the gatekeeper which is having problems with them is one of mine, which is derived from gkserver.cxx, I decided to investigate further. I tried to look at what gnugk does in it's sources, and it seems it uses the received endpoint identifier and thus avoids this problem, but I've not been able to totally verify it. But looking at gkserver.cxx, which I know a little better, I've noticed that the first time it receives a keepalive after a reboot it does not know the endpoint, so it requests a full registration, so far so good. Then when the new full registration arrives OnFullRegistration ends up doing // Need to create a new endpoint object info.endpoint = CreateRegisteredEndPoint(info); Which leads to: H323RegisteredEndPoint * H323GatekeeperServer::CreateRegisteredEndPoint(H323GatekeeperRRQ &) { return new H323RegisteredEndPoint(*this, CreateEndPointIdentifier()); } If this method is changed to something like: return new H323RegisteredEndPoint(*this, info.rrq.HasOptionalField(H225_RegistrationRequest::e_endpointIdentifier) ? info.rrq.m_endpointIdentifier : CreateEndPointIdentifier() ); My Gatekeeper ( and any gatekeeper built using h323plus gkserver ) will accept this kind of behaviour ( ie, where the endpoint DOES NOT USE the endpoint id received in the RCF as I think it should do ) ( in the line of be strict in what you send and tolerant in what you accept ). Does this seem correct? If so I can send make a send a patch for this ( basically, the above line after testing ). Francisco Olarte.

3 2

Previous bug report...
by Francisco Olarte 13 Nov '13

13 Nov '13

Hello everyone. In my previous mail I blamed my problems on commit http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… while it seems is due to a combination of that and the previous one: http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… It seem the endpointdidentifier assignement was removed in the 1.23 rev ( although the comment talks about gatekeeper identifier ) and reinstated conditionalized in 1.24 ( which comment i do not fully understand, seems like a partial revert of the previous one ). Regards. Francisco Olarte

3 3

Gkclient problem ( regression ) in h233plus 1.25
by Francisco Olarte 12 Nov '13

12 Nov '13

Hi everybody. I think h323plus gkclient.cxx does not correctly process reregistration after a gatekeeper reboot in 1.25. My scenario is the following. We have several h323 endpoint programs ( yate instances and homebrew ones ) registered to a gatekeeper. As part of a scheduled maintenance ew rebooted the gatekeeper. Every endpoint compiled against h323plus 1.24 reregisterd correctly and kept working, but a single one compiled with h323plus 1.25 ( and part of the maintenance is upgrading to 1.25 ) did not. The problem was the endpoint sent a keepalive RRQ with the old gatekeeper data. The new gk instance replied with an RRJ with a full registration required cause. The endpoint sent a full registration, the gatekeeper replied with a RCF with a NEW ENDPOINT IDENTIFIER. All the 1.24 programs then proceeded to send the new Ep Id, but the 1.25 one kept sending the old ones. I suspect it also sends it in ARQs, so it was unable to call ( will verify it later ). I've been debugging the source code and didn't notice any difference in the clients, so I looked at the 1.25-1.24 diffs, in gkclient.cxx http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… I noticed a difference in endpoint identifier handling, which I narrowed to this commit: http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… which does not store a new endpoint indentifer from an rrq if one is set, but does not do further tests, and seems to be what is causing my problem. I assume there is a reason for not storing the new endpoint identifier, but I think it should at least be checked. Also I think when receiving a fullregistrationrequired in a registration the stored fields should be reset. Actually I've seen it's processed like this: case H225_RegistrationRejectReason::e_fullRegistrationRequired : registrationFailReason = GatekeeperLostRegistration; // Set timer to retry registration reregisterNow = TRUE; monitorTickle.Signal(); break; but I've been unable to find more actions than signalling an immediate retry, I think in this case, if not in the general registration reject case, the endpoint identifier should be cleared, as it shouldn't be valid after a failed registration. I've also studied the differences between tag v1.25 and HEAD http://h323plus.cvs.sourceforge.net/viewvc/h323plus/h323plus/src/gkclient.c… and haven't found any differences in the relevant areas. Summarising, I think endpoint identifier, and maybe some mor registration data should be cleared on registration rejects. And also stored endpoint identifier should be tested again a potential inconsistency against registration confirm data, althoguh this can be problematic ( what to do if they do not match ? ) and can be left off as it's not going to interfre with normal operations. I can try to make a patch, in my case probabley clearing endpointIdentifier on registration reject will work, but I fear it may broke other parts. Francisco Olarte. P.S. I cannot provide detailed packet traces at the moment, as they need some rather involved setup, but I can try to do it if someone think it's neccessary. F.O.

1 0