[Asterisk-Dev] H.323 channel driver problems

Chih-Wei Huang cwhuang at citron.com.tw
Fri Mar 18 04:19:23 MST 2005


joachim wrote:
> Thank you for your contributions!!!!
> Please post all of this on bugs.digium.com (look at the bug and diff
> guidelines), this way jeremy and others will be able to reply to your
> findings and fixes.

Thank your for the comment.
I have just registered on bugs.digium.com, but not get password yet.

I continue my reports here.

* RTP problem:

On starting up a logical channel, the local IP of RTP is always
0.0.0.0. After tracing the source, I found external_rtp_create
use bindaddr specified in h323.conf. I didn't notice the newest
h323.conf.sample say one has to put a valid IP address for bindaddr.
My fault.
However, this requirement is totally unnecessary.
What if I have two or more network intetfaces? What if I use DHCP?
The local IP should be deduced from the stack instead specified by hand.
Since asterisk rtp stack always bind to 0.0.0.0 as I traced,
(ast_rtp_new, ast_rtp_new_with_bindaddr)
the only way I know to find the local IP is from Openh323.
I noticed in the old version (1.0.5), the local IP did deduce from
Openh323 stack by

	connection.GetControlChannel().GetLocalAddress()...

This is a correct and appropriate way. I don't know why Jeremy gave up
this way and adopt an unsmart one.

Besides, the way that external_rtp_create returns the IP is dangerous
and non-reenterable. The IP string is stored in a static buffer.
There are alternate ways to solve the problem:

 - allocate a dynamic buffer in external_rtp_create and have the caller
   free it

 - why not just pass back sockaddr_in in rtp_info? i.e., re-define it to

  typedef struct rtp_info {
        struct sockaddr_in rtp_addr;
  } rtp_info_t;

  it contains both IP and port information in a safe way.

 - as explained previous, external_rtp_create doesn't really find the
   local IP. So why bother to return the useless IP 0.0.0.0?
   Returning the RTP port is just enough.

I like the last one.


* Makefile problem:

There are two problems I found. First, it requires a particular version
of PWLib and Openh323, which is not the latest library.
This is unnecessary. In fact the H323 driver does compile
with latest Openh323 development(Atlas) and stable(Mimas RC2) version.
Just use a minimal required version is enough.

Second, it touchs chan_h323.c everytime I compile the source.
It's unsmart and always causes problems(e.g., vi will complain that file
be changed when I compile and edit it simutaneously)
You do not need to touch the source file since
make can take care the dependency problem.

I attach a patch that fixed these problems.


-- 
   ~     Chih-Wei Huang (cwhuang at citron.com.tw)
  'v'    CTO, Citron Network Inc. ( http://www.citron.com.tw/ )
 // \\   GnuGK Project : http://www.gnugk.org/    (Developer)
/(   )\  HomePage      : http://www.linux.org.tw/~cwhuang/
 ^`~'^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.diff
Type: text/x-patch
Size: 1894 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20050318/9c156bb7/make.bin


More information about the asterisk-dev mailing list