| Summary: | ASTERISK-27024: nat/external_media settings ignored in 14.4.1 | ||||||
| Reporter: | Christopher van de Sande (cvandesande) | Labels: | pjsip | ||||
| Date Opened: | 2017-05-30 12:37:52 | Date Closed: | 2017-06-15 13:53:53 | ||||
| Priority: | Major | Regression? | Yes | ||||
| Status: | Closed/Complete | Components: | Resources/res_pjsip_session | ||||
| Versions: | 14.4.1 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | Alpine Linux 3.6 (Docker image) | Attachments: | |||||
| Description: | Post upgrade from 14.3.1 to 14.4.1 rtp is not received by an enpoint behind a nat. The problem appears to be in the SDP headers sent from Asterisk.
Rolling back to 14.3.1 solves the issue. Asterisk is behind a shorewall firewall on a private natted network. It has a single interface eth0. Relevant pjsip.conf: {noformat} [transport-tls-nat] type=transport protocol=tls method=sslv23 ;sslv23 enables tls1.2 because reasons cert_file=XXX ;removed priv_key_file=XXX ;removed bind=0.0.0.0:5061 external_media_address=x.x.x.x ;public ip external_signaling_address=x.x.x.x ;public ip local_net=192.168.0.0/16 [endpoint-common](!) type=endpoint context=users disallow=all allow=g722,ulaw,h264 dtmf_mode=info [endpoint-sdes](!) media_encryption=sdes [aor-common](!) type=aor remove_existing=yes max_contacts=1 maximum_expiration=160 qualify_frequency=60 [207](endpoint-common,endpoint-sdes) ;Linphone callerid=Chris <PSTN number> auth=207 aors=207 mailboxes=201@default use_avpf=yes rtp_symmetric=yes media_use_received_transport=yes force_rport=yes [207] type=auth auth_type=userpass password=supersecretpassword username=207 [207](aor-common) {noformat} See pastbin logs referenced below. The SDP headers on 14.4.1 issue the private ip instead of the public ip: 14.3.1: {noformat} v=0 o=- 3705154152 3705154155 IN IP4 192.168.1.88 s=Asterisk c=IN IP4 198.48.203.62 t=0 0 m=audio 13310 RTP/SAVP 9 a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:FA++mhDadUmqknBzPIWDUI1RlQc0ZNsMwCx2MevLypTQdxXFB5ATHU+ltRXH7g== a {noformat} 14.4.1: {noformat} v=0 o=- 3705154685 3705154688 IN IP4 192.168.1.88 s=Asterisk c=IN IP4 192.168.1.88 t=0 0 m=audio 11764 RTP/SAVP 9 a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:STqxjT14RMJ19JB3GV0S+wD/mCBB9B4iPCv2yzGnRu894T058Q3zi41w55qK1w== a {noformat} | ||||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-05-30 12:37:53.411-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. 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: Rusty Newton (rnewton) 2017-05-31 17:46:40.963-0500 Are you able to reproduce the issue in a similar scenario, but with a non-TLS connection? Or is that possible in your environment? If you , can you provide the configuration for that as well, along with a debug log? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Florian Floimair (f.floimair) 2017-06-01 04:47:41.188-0500 I'm having exactly the same problem in my setup (which is not using TLS). Please let me know if I can also provide viable information to get this fixed. Thx. By: Florian Floimair (f.floimair) 2017-06-01 09:33:27.056-0500 I narrowed down the issue to Matt Jordan's commit fixing ASTERISK-26879 using 'git bisect': {quote} commit 486abb4210079fa29ec14e34189d959fa7d08f6d Author: Matt Jordan <mjordan@digium.com> Date: Thu Mar 16 10:39:00 2017 -0500 res/res_pjsip_session: Only check localnet if it is defined {quote} I also verified by checking out the latest commit on the 14 branch and reverting the mentioned commit. After the revert everything worked fine. By: Rusty Newton (rnewton) 2017-06-01 09:42:43.975-0500 [~f.floimair] , we haven't been able to reproduce. Probably due to our environment or some config piece we are missing. Can you provide a simplified set of configs that you use to reproduce the issue, along with a step by step play of what you do, and debug logs of the working and non-working scenarios? I realize that is a lot to ask, but we may need it to solve the issue, as a developer has already looked at the commit briefly and didn't see an obvious reason why it would cause the failure. Being able to reproduce it would give us an edge. By: Christopher van de Sande (cvandesande) 2017-06-01 09:42:48.334-0500 While this maybe redundant given Florian's comments, I have enabled TCP mode and reproduced the same issue. pjsip sip log is here: https://pastebin.com/WDJtcUHM By: Christopher van de Sande (cvandesande) 2017-06-01 09:49:32.399-0500 Simplified pjsip.conf in TCP mode: https://pastebin.com/g3PVqP0Y By: Florian Floimair (f.floimair) 2017-06-01 09:58:24.310-0500 No problem, I have already captured a log file as pointed out in your link to your wiki article: Here is my Configuration: {code:title=pjsip.conf|borderStyle=solid} [transport-udp] type=transport protocol=udp bind=0.0.0.0 ;symmetric_transport=yes local_net=172.17.217.0/24 external_media_address=13.94.254.95 external_signaling_address=13.94.254.95 ;external_signaling_port=5060 [transport-tcp] type=transport protocol=tcp bind=0.0.0.0 ;symmetric_transport=yes local_net=172.17.217.0/24 external_media_address=13.94.254.95 external_signaling_address=13.94.254.95 ;external_signaling_port=5060 [transport-udp-ipv6] type=transport protocol=udp bind=:: ;symmetric_transport=yes [transport-tcp-ipv6] type=transport protocol=tcp bind=:: ;symmetric_transport=yes [transport-ws] type=transport protocol=ws bind=0.0.0.0 ;symmetric_transport=yes local_net=172.17.217.0/24 external_media_address=13.94.254.95 external_signaling_address=13.94.254.95 ;external_signaling_port=5060 [transport-ws-ipv6] type=transport protocol=ws bind=:: ;symmetric_transport=yes {code} {code:title=extensions.conf|borderStyle=solid} [general] static=yes writeprotect=no clearglobalvars=no [globals] [default] exten => echo,1,Answer same => n, Echo exten => _[1-9,a-z,A-Z]., 1, Progress() same => n, Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})}) {code} My users are created using ARI as is explained in the wiki. They are all using the default context in the dialplan Everything is running on a VM in Microsoft Azure with an external IP address not directly visible to the VM, therefore the NAT settings in pjsip.conf. The log output can be found here: https://pastebin.com/CAJD6v3Y By: Christopher van de Sande (cvandesande) 2017-06-02 13:38:19.760-0500 Just in case the question comes up, I have the same problem with Asterisk 14.5.0 By: Florian Floimair (f.floimair) 2017-06-06 10:34:47.040-0500 Well, I finally found the source of the bug. It's the change in res/res_pjsip_session.c The comparison there used for the ast_apply_ha() function used to compare for NOT being AST_SENSE_ALLOW. After Matt Jordan's commit it is checking whether the returned value IS AST_SENSE_ALLOW. So this simple patch fixes the problem: {code:title=AST-27024.patch|borderStyle=solid} diff --git a/res/res_pjsip_session.c b/res/res_pjsip_session.c index e775a45..6ba1a6a 100644 --- a/res/res_pjsip_session.c +++ b/res/res_pjsip_session.c @@ -3160,7 +3160,7 @@ static void session_outgoing_nat_hook(pjsip_tx_data *tdata, struct ast_sip_trans if (!transport_state->localnet || (transport_state->localnet - && ast_apply_ha(transport_state->localnet, &addr) == AST_SENSE_ALLOW)) { + && ast_apply_ha(transport_state->localnet, &addr) != AST_SENSE_ALLOW)) { ast_debug(5, "Setting external media address to %s\n", transport->external_media_address); pj_strdup2(tdata->pool, &sdp->conn->addr, transport->external_media_address); } {code} By: Florian Floimair (f.floimair) 2017-06-06 10:35:31.808-0500 Christopher van de Sande can you please verify as well? By: Christopher van de Sande (cvandesande) 2017-06-06 18:17:56.858-0500 Awesome Florian, I ran the patch against 14.5.0 and can have incoming sound again behind the nat! And moreso SDP headers look correct. {noformat} CSeq: 21 INVITE Server: Asterisk PBX 14.5.0 Contact: <sip:198.48.203.62:5070;transport=TCP> Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Content-Type: application/sdp Content-Length: 194 v=0 o=- 873 2407 IN IP4 192.168.8.38 s=Asterisk c=IN IP4 198.48.203.62 t=0 0 m=audio 18000 RTP/AVPF 9 0 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=maxptime:150 a=sendrecv {noformat} By: George Joseph (gjoseph) 2017-06-13 11:55:46.003-0500 Florian, Can you sign a license agreement so we can include your patch? It's only 1 line but we'd still like the agreement. By: Florian Floimair (f.floimair) 2017-06-13 12:10:09.561-0500 I just signed the license agreement. By: Friendly Automation (friendly-automation) 2017-09-06 09:45:43.829-0500 Change 6395 merged by Jenkins2: res/res_pjsip: Standardize/fix localnet checks across pjsip. [https://gerrit.asterisk.org/6395|https://gerrit.asterisk.org/6395] By: Friendly Automation (friendly-automation) 2017-09-06 10:10:31.362-0500 Change 6396 merged by Jenkins2: res/res_pjsip: Standardize/fix localnet checks across pjsip. [https://gerrit.asterisk.org/6396|https://gerrit.asterisk.org/6396] By: Friendly Automation (friendly-automation) 2017-09-06 10:15:37.028-0500 Change 6397 merged by Joshua Colp: res/res_pjsip: Standardize/fix localnet checks across pjsip. [https://gerrit.asterisk.org/6397|https://gerrit.asterisk.org/6397] By: Friendly Automation (friendly-automation) 2017-09-06 10:19:16.070-0500 Change 6398 merged by Jenkins2: res/res_pjsip: Standardize/fix localnet checks across pjsip. [https://gerrit.asterisk.org/6398|https://gerrit.asterisk.org/6398] | ||||||