[Asterisk-Dev] Re: Inestability with H323

Adam Hart adam at teragen.com.au
Sun Apr 18 18:21:45 MST 2004


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
>>
>>
>>    
>>
>
>  
>




More information about the asterisk-dev mailing list