asterisk users - Jul 2004 - Hack to make * -> (H323) -> CCM -> IOS GW work

The hack below is for OpenH323, not Asterisk. This is not an Asterisk
problem AFAICT. I am posting it here so that any other Asterisk user with a
similar problem might benefit from it. I may or may not post it to an
OpenH323 list, but since both variants of the H.323 channel in Asterisk
use non-current OpenH323 versions, it may not be of any benefit to anyone
anytime soon if I went that route! I've not checked newer OpenH323 source
to see if the hack below can be shifted into the application either.


I've been messing with the companys CCM PBX, which has an IOS based gateway
box with a PRI behind it, and talking to it from my * box with H.323.
For the most part it works. It's in Lonodn UK, I'm (currently) in
Boston,
MA, USA. It's all VPNed. People being able to call me has made working
remotely that much easier.

However, placing outgoing calls that went via the GW had issues - if they
weren't answered within a few milliseconds of ringing, then the call would
fail - sometimes you'd get one way audio, sometimes none at all, and the
GW or the CCM always sent a RELEASE within a few seconds, even if not
answered. If you answered the call quckly, within ms of ringing, the call
worked fine.

Any other call (ie, that didn't use the PSTN gateway for outgoing calls)
would work fine too, which was the most baffling. Even incoming via the
PSTN gateway were fine.

The chan_h323 in CVS and chan_oh323 both exhibited the same behaviour.

I'd come accross a number of message in Mantis, this lists archives and
by googling in general suggesting that "H.323 via CCM" "Cisco
GWs" and
other combinations of Cisco and H.323 don't work, have less functionality,
need faststart, needs faststart disabled, needs other things doing to it
and generally won't be fixed without money, etc etc. 

So I spent some time pouring over traces, and noticed one difference between
calls that were answered unreasonably quickly and those not. After the
call has been setup and the H.323 neighbors have exchanged their
capabilities, a few tens of ms pass, and then the CCM sends an
openlogicalchannel, so it can pass the audio of the ringing. However,
when answered, the CCM/GW doesn't send back any open message indicating
its RTP address/port.

If you answer it early - the channel messages work as expected in both
directions, and thus it works.

So I hunted down an option to make the CCM not do this. And (eventually)
came across mediaWaitForConnect in the OpenH323 source. It's not something
you can change easily from client applications that I can see, but doing
this:

--- h323.cxx.old        2004-07-23 16:04:45.109780688 -0400
+++ h323.cxx    2004-07-23 16:04:49.577950415 -0400
@@ -2797,6 +2797,8 @@
   if (hasVideoOrData)
     setupPDU.GetQ931().SetBearerCapabilities(Q931::TransferUnrestrictedDigital,
6);
 
+  setup.m_mediaWaitForConnect = TRUE;
+
   if (!OnSendSignalSetup(setupPDU))
     return EndedByNoAccept;
 
and rebuilding the OpenH323 libraries made my problem "go away".
The CCM doesn't insist on trying to send me any audio until the call is
answered, and when answered the audio streams in both directions get
setup as expected. 

Hopefully someone here will point out an easy way to set this option from
ast_h323.cpp or something - while my C voodoo is strong, C++ is just foo
to me.

YMMV.

Cheers,
Chris.
-- 
== chrisy@flirble.org

Chris Luke wrote:
> The chan_h323 in CVS and chan_oh323 both exhibited the same behaviour.

I have setup chan_h323 to talk to CCM without any trouble, after someone 
informed me we had to override the External RTP object, which is part of 
cvs -head now.  I highly doubt the obsolete -stable has it.


Try again.


Jeremy McNamara