Page 1 of 1

mod_h323 on FreeSWITCH

Posted: Fri Apr 25, 2014 5:52 am
by Sharath
I am setting up a h323 trunk between FreeSWITCH and Avaya. I figured this is probably a better place to discuss it than any other forum.

First of all, it works pretty well. But there are niggles. I am using mod_h323.cpp Version 0.0.58 on FreeSwitch 1.2.22 for now.

1) First I wanted to ensure there are no memory leaks. But that was impossible to figure out since mod_h323 was disabled from unloading. So I enabled unloading. Well, it unloads eventually, but takes about 2-3 minutes to do so. Does anyone know why it takes so long? Is some thread is locked?

2) But the late unloading allowed for a VLD report. I noticed couple of memory leaks right away.

Code: Select all

SWITCH_MODULE_SHUTDOWN_FUNCTION(mod_h323_shutdown)
{
	switch_safe_free(mod_h323_globals.context);
	switch_safe_free(mod_h323_globals.dialplan);
	switch_safe_free(mod_h323_globals.codec_string);
	switch_safe_free(mod_h323_globals.rtp_timer_name);  // This one was missing, leading to a leak.
.
.
}
And this one:

Code: Select all

void FSH323Connection::AttachSignalChannel(const PString & token,
                                         H323Transport * channel,
                                         PBoolean answeringCall)
{
.
	tech_pvt->token = strdup((const char *)token);     // This is not freed later.
.
.
}
So I added switch_safe_free(tech_pvt->token) as the last line in FSH323Connection::~FSH323Connection(). The VLD log shows no leaks any more.

3) When I increase the number of simultaneous calls, the module goes into some strange state. It sometimes crashes the freeswitch or just hangs there doing nothing. I'll start looking into this.

Suggestions and hints are welcome...

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 1:20 am
by GHhost
Hi, i put you changes in FS git now.
P.S. in future if you fix something it's better to provide patch instead of just description.

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 5:28 am
by Sharath
GHhost wrote:Hi, i put you changes in FS git now.
Thank you very much.
GHhost wrote:P.S. in future if you fix something it's better to provide patch instead of just description.
I apologize, I am not familiar with the process. What do you mean by provide patch, should I attach the whole .cpp file?

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 7:05 am
by GHhost
oh, you can read man patch, or short answer - just make diff -ruN dir_with_old_version dir_with_new_version ad post output, and finally if you cannot do this for some reason yes - you can send me whole file, but think it's better to do it directly via email.

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 9:08 am
by Sharath
Ah, okay. I mainly develop on Visual Studio, therefore it was not obvious to me. I'll read up on patch.

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 10:02 am
by GHhost
visual studio means windows, i have no expirience with this platform, but i think there should be some tool for this.

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 2:35 pm
by shorne
I use winmerge. winmerge.org
You can integrate it as diff editor with tortoiseCVS or tortoiseSVN.
menu > Tools > Generate Patch.

Re: mod_h323 on FreeSWITCH

Posted: Sat Apr 26, 2014 4:46 pm
by Sharath
I use tortoiseGit and it does have something like that. I'll look it up.

Re: mod_h323 on FreeSWITCH

Posted: Sat May 03, 2014 2:38 pm
by Sharath
Just putting my thoughts out there about the handling of end of a call in mod_h323.
  • In the h323plus library, the destructor of H323Connection gets called when a call is terminated. You can do your cleanup in the derived class destructor like ~FSH323Connection().
  • In the Freeswitch platform, the function stored at switch_state_handler_table.on_hangup gets called. This is where freeswitch expects you to do cleanup.
In the mod_h323 implementation, both the above methods are employed. When a call drops, both ~FSH323Connection and on_hangup() methods are called simultaneously in different threads. Both are retrieving h323_private_t session data and using it and changing it. And I don't see any mutex locking to synchronize the functions. This can lead to very uncertain behavior.

I feel only one cleanup function should be employed, not both. The function ~FSH323Connection() is out of our control since it is triggered from within the H323Plus library. But on_execute is optional. I feel it should be avoided and all cleanup should be done within ~FSH323Connection(). Or you can do very little in ~FSH323Connection() and do all cleanup in on_hangup and on_destroy functions.

Would like to hear alternative views on this.