[asterisk-dev] chan_h323 status in 1.8 branch ?

[Simon Perreault]

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.

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.

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

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca