[asterisk-dev] chan_h323 status in 1.8 branch ?

[Pavel Troller]

Hi!

> Breakage in chan_h323 is probably due to the port to IPv6 (sorry about
> that). chan_h323 itself is still IPv4-only, but it relies on core APIs
> that have been ported to IPv6. In any case, the changes that are needed
> in chan_h323 to fix the bugs you have found would probably be minor. I
> would encourage you to use the bug tracker.

OK, I will open some bugs there.

> 
> On 2011-03-02 07:04, Pavel Troller wrote:
> >   2) Without a patch, it doesn't accept peers, always complaining that ai_family
> > is not supported. The following patch fixes it:
> > 
> > Index: channels/chan_h323.c
> > ===================================================================
> > --- channels/chan_h323.c	(revision 309090)
> > +++ channels/chan_h323.c	(working copy)
> > @@ -1542,6 +1542,8 @@
> >  			{
> >  				struct ast_sockaddr tmp;
> >  
> > +				tmp.ss.ss_family = AF_INET;
> > +
> >  				if (ast_get_ip(&tmp, v->value)) {
> >  					ast_log(LOG_ERROR, "Could not determine IP for %s\n", v->value);
> >  					ASTOBJ_UNREF(peer, oh323_destroy_peer);
> 
> This is OK. When chan_h323 is ported to IPv6 we'll s/AF_INET/AF_UNSPEC/
> but for now it's OK.

Understand.

> 
> >   3) Incoming calls are complaining similarly - that address family is not
> > supported by protocol - when a RTP socket has to be opened. Asterisk then
> > immediately crashes again. The following (experimental) patch is fixing it:
> > Index: res/res_rtp_asterisk.c
> > ===================================================================
> > --- res/res_rtp_asterisk.c      (revision 309090)
> > +++ res/res_rtp_asterisk.c      (working copy)
> > @@ -413,6 +413,9 @@
> > 
> >  static int create_new_socket(const char *type, int af)
> >   {
> >   +       if (af != AF_INET6)
> >   +               af = AF_INET;
> >   +
> >           int sock = socket(af, SOCK_DGRAM, 0);
> > 
> > 	          if (sock < 0) {
> > 
> >   My first version tested for af == AF_UNSPEC but it didn't help, it looks
> > that some garbage is coming in the af but not just zero. Now I'm allowing just
> > inet6 (for other protocols, i.e. SIP) and inet. I didn't find a real cause of
> > this problem.
> 
> This is wrong. The bug is in chan_h323, not in res_rtp_asterisk. What is
> needed is to figure out why garbage is being passed to
> create_new_socket() and fix the root cause.

Of course. I've made this just as a quick hack to find, whether I'm in a good
place. (This is why I called this patch just as "experimental". 
  If it would be the only problems, I would continue, but then I've found some
issues with signalling, which discouraged me from continuation.

With regards, Pavel