[Home]

Summary:ASTERISK-26617: res_rtp_asterisk: Can't bind on systems without IPv6
Reporter:Guido Falsi (madpilot)Labels:
Date Opened:2016-11-22 05:16:04.000-0600Date Closed:2016-12-01 15:51:39.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Resources/res_rtp_asterisk
Versions:13.13.0 Frequency of
Occurrence
Constant
Related
Issues:
is duplicated byASTERISK-26625 All PJSIP calls rejected with 'Unable to allocate RTP socket: Address family not supported by protocol'
is duplicated byASTERISK-26636 pjsip stopped workinh on lastest update
Environment:FreeBSD 11.0-RELEASE, no IPV6 configured on machine.Attachments:
Description:While everything worked fine with Asterisk 13.12.2 on this machines.

Upgrading to 13.13.0-RC for routine testing, with all other factors the same, causes calls to be rejected with the following errors output to the console:

[Nov 22 10:49:26] WARNING[101105]: res_rtp_asterisk.c:2400 int
create_new_socket(const char *, int): Unable to allocate RTP socket:
Protocol not supported
[Nov 22 10:49:26] WARNING[101105]: res_rtp_asterisk.c:2665 int
ast_rtp_new(struct ast_rtp_instance *, struct ast_sched_context *,
struct ast_sockaddr *, void *): Failed to create a new socket for RTP
instance '0x805647c30'
[Nov 22 10:49:26] ERROR[101105]: res_pjsip_sdp_rtp.c:184 int
create_rtp(struct ast_sip_session *, struct ast_sip_session_media *):
Unable to create RTP instance using RTP engine 'asterisk'

Some further testing indicates asterisk is trying to open an INET6 socket, while it should be using INET4 on this machines, which has no INET6 configured. This is just a first finding, I'm still investigating more.

At a first look the problem looks related to this commit:

https://github.com/asterisk/asterisk/commit/bb982480d815fb0d5059fbfa86682cd30846556c
Comments:By: Asterisk Team (asteriskteam) 2016-11-22 05:16:05.477-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Guido Falsi (madpilot) 2016-11-22 06:08:43.419-0600

I'm not an expert about socket programming, so I could be wrong, but looking at the code, after the commit I referenced it's using

ast_sockaddr_parse(&address_rtp, "::", 0);

to initialize the rtp address used to create sockets.

By doing this it's unconditionally getting an IPV6 address in the address_rtp structure, which is then used as a basis for all future sockets.

Right now I cannot see a way to fix this apart from reverting, at least in part to the old code.

By: Kevin Harwell (kharwell) 2016-11-22 10:59:06.231-0600

Under Linux we're able to bind to both using this method, even without IPv6 being configured. This doesn't appear to work under FreeBSD as you've discovered. Since FreeBSD is not a core supported platform we're not going to have it block this current release but it has been put into the queue to get looked at. If you'd like to look at it yourself it would be possible to have it do a runtime check for binding, with a fallback to IPv4 only. This should work perfectly fine as you'd have no IPv6 PJSIP transports. Finally if there's any additional patches you are using that you have written and can be contributed back they would also be welcome so in the future the number of patches can be reduced on your side.

By: Guido Falsi (madpilot) 2016-11-22 11:34:05.585-0600

Thanks for the feedback, I just noticed it.

In the while I made a patch which does what you suggest, checking when actually creating the socket and reallocating the correct structure.

I submitted it as a gerrit review.

This patched code is working fine on my machine, I hope it's acceptable for inclusion on your end.

By: Jean-Denis Girard (jdg) 2016-11-25 20:13:32.670-0600

I got exactly the same problem on a Linux machine with IPV6 disabled in kernel (4.8.7 from kernel.org locally compiled without IPV6 support). The system is Fedora 24. Applying the patch proposed by Guido resolved the issue for me, thanks Guido! So this is not FreeBSD specific.

By: Guido Falsi (madpilot) 2016-11-27 04:33:11.640-0600

If this also applies to linux then the commit I reference in the report should be really checked out.

It removes a useful option (forcing a peer on IPv6) and actually creates a problem where IPV6 is not available.

My patch is more an hack than a real fix to the original problem.

By: Friendly Automation (friendly-automation) 2016-12-01 15:51:40.477-0600

Change 4540 merged by Joshua Colp:
res_rtp: Fix regression when IPv6 is not available.

[https://gerrit.asterisk.org/4540|https://gerrit.asterisk.org/4540]

By: Friendly Automation (friendly-automation) 2016-12-01 17:13:43.279-0600

Change 4539 merged by Joshua Colp:
res_rtp: Fix regression when IPv6 is not available.

[https://gerrit.asterisk.org/4539|https://gerrit.asterisk.org/4539]

By: Friendly Automation (friendly-automation) 2016-12-01 18:46:28.197-0600

Change 4487 merged by Joshua Colp:
res_rtp: Fix regression when IPv6 is not available.

[https://gerrit.asterisk.org/4487|https://gerrit.asterisk.org/4487]

By: Private Name (falves11) 2016-12-09 12:45:50.068-0600

The version 13.13.1 has the same issue. I updated and had to go back to 13.12.2


By: Private Name (falves11) 2017-01-08 16:26:39.980-0600

Are there any plans to issue a release with this problem fixed?


By: Joshua C. Colp (jcolp) 2017-01-08 16:32:10.466-0600

There is no explicit timeframe for a release, but it will be done as soon as it can be.

By: Ludovic Gasc (Eyepea) (gmludo) 2017-03-18 16:42:29.029-0500

This bug is fixed in 13.14.0, but it's still present in 13.13-cert2.

Is it planned to backport this patch in 13.13-cert3 ?

By: Joshua C. Colp (jcolp) 2017-03-18 16:48:11.550-0500

Not as of this time.