[Asterisk-Dev] Re: Inestability with H323

Sun Apr 18 18:38:18 MST 2004

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

-- 
Derek Smithies Ph.D.                           This PC runs pine on linux for email
IndraNet Technologies Ltd.                     If you find a virus apparently from me, it has
Email: derek at indranet.co.nz                    forged  the e-mail headers on someone else's machine
ph +64 3 365 6485                              Please do not notify me when (apparently) receiving a
Web: http://www.indranet-technologies.com/     windows virus from me......