[Asterisk-Dev] h323 + asterisk.

[Derek Smithies]

Hi,
 working with Peter Nixon, I have been endeavouring to make h323 calls to
asterisk. Sorry about this long bug report, but, well, it is long.

Following the instructions, asterisk was compiled with the correct version
of openh323.

On a second computer, ohphone (a simple H323 command line gui) ran.
With experimentation, I found that ohphone had to be set with fast start
off, h245 tunnelling off. it seemed sensible to add --gsmframes 1, so 
ohphone would only put one gsm audio frame in each ethernet packet. This 
is the same packing style as used by iax/asterisk.

Following Peters advice (Thanks) I set asterisk up to receive the incoming
h323 call, and play some demo audio. It was cool, you could make a call to
asterisk, enter 500 on the dtmf keypad, and get put through to digium. 

Now, the problem I was looking at was reported earlier by Peter, of
Asterisk crashing after 200 calls. The very first warning messages were
from lines 537 and 873 of file.c, current cvs code.

Some more work.
With just one ohphone running
ohphone -n -q0 -Tf --gsmframes 1 --autorepeat 200000 --autodisconnect 1 ast
Which means,
   no h323 gk search,
   use quicknet card
   No h245 tunnelling, no fast start
   1 gsm audio frame per ethernet packet
   do the call 200000 times
   disconnect the call 0.1 seconds after the connection is made
   make a call to the box with ip address as found by dns lookup of ast

On average, it makes a call every 4 seconds.
There is a very short burst of sound heard at the ohpone end.
This sound is recoginisable as the start of the demonstration message.

Leave running for a couple of hours.
On the box which is running asterisk, run other programs (compiler etc) to
load it. After a while, (10 minutes or so), the first warning
messages are generated. The first warning messages are described above.
At about this point, no audio is heard at the ohphone end.

Some time later, ohphone dies, and asterisk is no longer taking h323 calls.

=====
Now, I am not running any asterisk hardware on the box with asterisk.
===========================================
To the logs..
h.323 trace 8
h.323 debug
With logging on, the error described above does not happen as quickly.

However, it seems to be that the chan_h323 code uses 
   *openh323 to do all the h323 signalling.
   *asterisk to send, receive and process the h323 rtp packets 
          (which each contain one gsm frame)
The h.323 side of things seems to be shutting down the call (and 
associated data structures) before the rtp side of things has finished.
When this happens, things are not good.
When the rtp side shuts down first, all is fine..

Going back to the above comment, logging slows down the onset of problems.
Logging is primarily in the signalling code, so it will take longer for
the signalling code to execute. Thus, there is more time available for the
rtp side to exit at the end of the call. Yes, next test. Put logging in 
the rtp side, slow rtp down, remove logging from signalling code, and look 
for onset of error.

Comment?
Any one prepared to explain what actually happens, and then it can be 
fixed/proven etc???

==
Oh, when the call starts up, you can get messages about the frame being in 
the future, (sorry, did not make a note of this).

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