[Home]

Summary:ASTERISK-29402: res_pjsip_t38: Socket is bound to IPv4/IPv6 but platform does not support it
Reporter:Matthew Kern (mkernalcon)Labels:fax patch
Date Opened:2021-04-22 14:32:16Date Closed:2021-10-05 12:48:01
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_t38
Versions:18.3.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Running as a Linux binary on FreeBSD's Linux emulation layer.Attachments:( 0) t38_bind_fixes.patch
Description:On environments such as this, sockets bound to ipv6 addresses cannot be used to pass ipv4 traffic (I am unsure of the exact deeper issue here, but it seems to do with the bind() address, not the call to socket()). ast_check_ipv6() (from main/utils.c) only detects whether an AF_INET6 socket can be opened at all (which it can in this env, so ast_check_ipv6() returns 1 by default).

According to a quick search, ast_check_ipv6() is only called in two spots - the load_module() for res_pjsip_t38.c and res_pjsip_sdp_rtp.c

The sdp/rtp module works fine this way, but only with the bind_rtp_to_media_address option set (i.e. since I'm forcing the socket to bind() to an ipv4 address, ipv4 packets can pass. Without this option I get similar EINVAL sends).

Unfortunately, there is no equivalent option for the T38 module. Working around this, either so that ast_check_ipv6() always returns 0, or disabling the check in load_module and forcing address to "0.0.0.0", yields a fully working system.

Please either implement a configuration option to force ast_check_ipv6() to return 0, or implement a configuration option to set the bind() address for the T38 module (e.g. bind_t38_to_media_address would be a legitimate solution here), for the sake of other systems with this particular problem.
Comments:By: Asterisk Team (asteriskteam) 2021-04-22 14:32:16.759-0500

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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

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

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

By: Joshua C. Colp (jcolp) 2021-04-22 14:35:43.271-0500

I've marked this as open, but it is not a platform supported by Sangoma and is up to the community.

By: Matthew Kern (mkernalcon) 2021-07-14 09:11:01.247-0500

I've worked on this a little, and I came up with a patch which essentially copies the initialization code from res_pjsip_sdp_rtp.c into res_pjsip_t38.c. Basically, instead of always binding to the address determined in load_module(), this adds a "t38_bind_udptl_to_media_address" option for pjsip endpoints, and falls back to using the transport's bind address (before falling back to the current behavior) - almost word-for-word out of res_pjsip_sdp_rtp.c.

When I test on my setup, the bind to media address works for the internal endpoint (the fax ATA), but it uses the transport address for the trunk side. This is identical to the behavior I see in the RTP side for voice calls, as you might expect. This fixes my problem, since both endpoints end up binding to the intended ipv4 address.

Please bear with me while I try to work through the patch submission process - it's been many years since I've done a patch for an OSS project.

By: Matthew Kern (mkernalcon) 2021-07-14 09:14:11.262-0500

The patch I described. I'll be submitting on Gerrit for code review - in particular, I don't think I caught every spot that the new config option needs to be added, and I'm not so sure on the debug level for those messages.

By: Friendly Automation (friendly-automation) 2021-10-05 12:48:02.470-0500

Change 16546 merged by Friendly Automation:
res_pjsip_t38: bind UDPTL sessions like RTP

[https://gerrit.asterisk.org/c/asterisk/+/16546|https://gerrit.asterisk.org/c/asterisk/+/16546]

By: Friendly Automation (friendly-automation) 2021-10-06 08:54:33.601-0500

Change 16156 merged by George Joseph:
res_pjsip_t38: bind UDPTL sessions like RTP

[https://gerrit.asterisk.org/c/asterisk/+/16156|https://gerrit.asterisk.org/c/asterisk/+/16156]

By: Friendly Automation (friendly-automation) 2021-10-06 08:54:48.736-0500

Change 16178 merged by George Joseph:
res_pjsip_t38: bind UDPTL sessions like RTP

[https://gerrit.asterisk.org/c/asterisk/+/16178|https://gerrit.asterisk.org/c/asterisk/+/16178]

By: Friendly Automation (friendly-automation) 2021-10-06 08:55:06.237-0500

Change 16547 merged by George Joseph:
res_pjsip_t38: bind UDPTL sessions like RTP

[https://gerrit.asterisk.org/c/asterisk/+/16547|https://gerrit.asterisk.org/c/asterisk/+/16547]