[Asterisk-Dev] Re: Inestability with H323

[Michael Manousos]

Hi,


Derek Smithies wrote:
> Hi,
>  I have not looked at  asterisk-oh323 driver..
> 
> Where is it ?


asterisk-oh323 can be downloaded from:
http://www.inaccessnetworks.com/projects/asterisk-oh323

I'm one of the authors of this module so feel free to ask me
whatever you want to know about it.

Michael.

PS: I have a semi-finalized version which works with the latest
versions of OpenH323/Pwlib libraries. Expect a release soon.



> 
> Derek.
> ===========================
> On Sun, 18 Apr 2004, Eric Wieling wrote:
> 
> 
>>Have you looked at the asterisk-oh323 driver?  That doesn't use
>>Asterisk's RTP stack.
>>
>>On Sun, 2004-04-18 at 20:38, Derek Smithies wrote:
>>
>>>Adam,
>>>
>>>
>>>>Should we try and make the required changes to chan_h323 so it can 
>>>>compile with the latest open.H323. Derek, you're the OpenH.323 pro, 
>>>>fancy giving it a spin. Although it may not fix this bug, there's a few 
>>>>other bugs it will.. specifically the known exploits in the old openh323.
>>>
>>>I am happy to fix the h.323 side of asterisk.
>>>Here are the problems I would face, should I take this job on.
>>>
>>>a)the lack of response from others on this list who have been involved
>>>  with chan_h323.c   There is knowledge there that I want to tap into.
>>>  To be honest, I am not keen to "reinvent the wheel". I want to learn 
>>>  from others, and learn what trials/tribulations they had.
>>>
>>>b)I have an architecture reorganisation in my mind that will mean 
>>>  chan_h323.c receives/sends encoded audio frames from/to the h323 stack
>>>  Currently, there appears to be the asterisk does all rtp handling. This
>>>   is not necessary, and is unwise in my view. I just need some clues as
>>>   to how to "connect" the encoded audio frames to asterisk.
>>>
>>>c)upgrade of the chan_h323 to work with current  openh323 code.
>>>  Add sentences to the readme.
>>>   cvs co -r tagname pwlib
>>>   cvs co -r tagname openh323
>>> 
>>>d)you don't need to worry about exploits in the openh323 code.
>>>  iax2 has many more exploits than openh323.
>>>
>>>Derek.
>>>=====================================================================
>>>On Mon, 19 Apr 2004, Adam Hart wrote:
>>>
>>>
>>>>Derek Smithies wrote:
>>>>
>>>>
>>>>>Peter Nixon wrote:
>>>>>
>>>>> 
>>>>>
>>>>>
>>>>>>[*] Anyone who thinks otherwise is welcome to setup a copy of Asterisk running 
>>>>>>chan_h323 and tell me the IP. I guarantee that I can crash it for you in 
>>>>>>under 5 minutes, using only inbound H323 calls
>>>>>>   
>>>>>>
>>>>>
>>>>>
>>>>>Yep, and if you don't want Peter crashing your *for you, I will do it.
>>>>>
>>>>>I have detailed in a previous email how to do this. With just one external 
>>>>>computer, generating one call at a time, guaranteed failure.
>>>>>
>>>>>Peter Nixon also wrote:
>>>>> 
>>>>>
>>>>>
>>>>>>Until chan_h323 is fixed I would not rely on it for commercial
>>>>>>operation.
>>>>>>   
>>>>>>
>>>>>
>>>>>I will not rely on * + h323 for commercial operation either.
>>>>>
>>>>> 
>>>>>
>>>>
>>>>Should we try and make the required changes to chan_h323 so it can 
>>>>compile with the latest open.H323. Derek, you're the OpenH.323 pro, 
>>>>fancy giving it a spin. Although it may not fix this bug, there's a few 
>>>>other bugs it will.. specifically the known exploits in the old openh323.
>>>>
>>>>
>>>>
>>>>>Derek.
>>>>>
>>>>>=====================================================================
>>>>>On Mon, 19 Apr 2004, Peter Nixon wrote:
>>>>>
>>>>> 
>>>>>
>>>>>
>>>>>>On Sunday 18 April 2004 11:16, sales at minixel.com wrote:
>>>>>>   
>>>>>>
>>>>>>
>>>>>>>I get this error every time when I reach 33 open calls
>>>>>>>using H323:
>>>>>>>-- Executing Dial("SIP/16468370490-0751",
>>>>>>>"H323/16468370490 at 192.168.85.100/16468370490") in new
>>>>>>>stack
>>>>>>>   -- Called 16468370490 at 192.168.85.100
>>>>>>> 0:14.917         H225 Answer:41802ba8
>>>>>>>assert.cxx(105)   PWLib   Assertion fail: Invalid array
>>>>>>>index, file /root/pwlib/include/ptlib/contain.inl, line
>>>>>>>423, Error=22
>>>>>>>
>>>>>>>
>>>>>>>I checked the header file referenced on the error and
>>>>>>>there is an object array being queried, and the object
>>>>>>>is not there. The question is: is this something
>>>>>>>fixable on our code, or in the pwlib libraries, or
>>>>>>>both? Any suggestion? I need to provide Sip-to-H323
>>>>>>>services. This feature is what makes my client be
>>>>>>>interested. In order to test this problem I generated a
>>>>>>>simple loop within Asterisk, sending the callback into
>>>>>>>Asterisk via H323:
>>>>>>>exten => _X.,1,ChanIsAvail(Sip/${EXTEN})
>>>>>>>exten => _X.,2,Dial(Sip/${EXTEN})
>>>>>>>exten =>
>>>>>>>_X.,102,Dial(H323/${EXTEN}@192.168.85.100/${CALLERIDNUM})
>>>>>>>
>>>>>>>By the way I have captured around 20 Core Dumps. What
>>>>>>>is exactly what I am supposed to look at? Sorry for my
>>>>>>>lack of expertise, but I figured out the ODBC problem
>>>>>>>and fixed it. I am getting there.
>>>>>>>     
>>>>>>>
>>>>>>
>>>>>>The chan_h323 is still horribly unstable for any type of inbound bulk calls. * 
>>>>>>It may or may not be stable for originating bulk h323 calls but I wouldn't 
>>>>>>bet on it.
>>>>>>
>>>>>>I believe Jeremy is working on the issue. Until chan_h323 is fixed I would not 
>>>>>>rely on it for commercial operation. If you need a SIP-H323 proxy there are 
>>>>>>plenty available other than asterisk. If you need the extra "PBX" features of 
>>>>>>Asterisk, then unfortunately you have to wait..
>>>>>>
>>>>>>[*] Anyone who thinks otherwise is welcome to setup a copy of Asterisk running 
>>>>>>chan_h323 and tell me the IP. I guarantee that I can crash it for you in 
>>>>>>under 5 minutes, using only inbound H323 calls
>>>>>>
>>>>>>
>>>>>>   
>>>>>>
>>>>>
>>>>> 
>>>>>
>>>>
>>>>_______________________________________________
>>>>Asterisk-Dev mailing list
>>>>Asterisk-Dev at lists.digium.com
>>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>>To UNSUBSCRIBE or update options visit:
>>>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>>
>>>>
>>>>
>>
> 

-- 
./M