[Asterisk-Dev] Re: Inestability with H323

[Jeremy McNamara]

Derek Smithies wrote:

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

Why should I waste time responding to nonsense?  ...when I could just 
address the problem at hand.


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


Um no... This is the EXACT reason why I created chan_h323, as there is 
no need to waste time buffering frames over to Open H.323's RTP stack, 
when we can simply let Asterisk deal with all audio and codec 
translations (which Asterisk is damn efficient at).  Then how to you 
plan on making native bridging (endpoint-to-endpoint RTP) to work if 
your sending RTP frames over to Open H.323?

Anyways all of this is moot...Eventually chan_h323 will be rewrote 
completely using a radically new design a few of us have cooked up, when 
I find the time (or motivation)


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


chan_h323 has been updated to work with the Open H.323 Janus release and 
is now not compatible with any lesser version of Open H.323.


> d)you don't need to worry about exploits in the openh323 code.
>  iax2 has many more exploits than openh323.
>  
>


How about proof? ...or do you just like to flame?



Jeremy McNamara