Summary: | ASTERISK-29235: res_pjsip_nat: Contact is rewritten on REGISTER responses with external_signaling_address | ||
Reporter: | Brian Paboojian (braptor) | Labels: | fax webrtc |
Date Opened: | 2021-01-05 19:37:37.000-0600 | Date Closed: | 2021-03-03 12:08:33.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_pjsip_nat Resources/res_pjsip_registrar |
Versions: | 13.36.0 16.13.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Freepbx 15 distro | Attachments: | ( 0) eth1-EM.pcap ( 1) eth1-NAT.pcap |
Description: | I am testing SD-Wan with my Ribbon Edgemarc. The phone is sending the registration to the eSBC and then the SBC forwards the registration onto the Freepbx 15 system. Asterisk is rewriting the contact header when it sends the registration back to the phone and the Edgemarc is blocking it because this rewrite is a violation of RFC 3261. I have turned off contact rewrite in extension advanced settings. In reviewing the pcap reveal the contact header is still being rewritten.
I have confirmed this setting in the config file Pjsip.endpoint.conf; rewrite_contact=no I worked with a Freepbx Engineer and he agrees this is an Asterisk bug. | ||
Comments: | By: Asterisk Team (asteriskteam) 2021-01-05 19:37:39.455-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. 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-01-06 03:40:25.511-0600 Please provide the output of "pjsip show endpoint <name>" as well as the packet capture or output of "pjsip set logger on" showing the issue. By: Ross Beer (rossbeer) 2021-01-06 04:55:31.435-0600 I believe this may be related to ASTERISK-29200 By: Joshua C. Colp (jcolp) 2021-01-06 05:05:52.970-0600 [~rossbeer] If after investigation it is determined to be then they will be linked as appropriate. Until configuration confirmation and logging occurs, it's premature for any relationship - there's just not even information here. In fact I just tested and am not seeing the behavior described in this issue with "rewrite_contact" set to "no". By: Brian Paboojian (braptor) 2021-01-06 17:14:12.257-0600 I have attached 2 pcaps from the WAN side of the “eSBC†(Edgemarc 2900E) and a simple “NAT†device (Mikrotik). Asterisk IP: 192.168.60.239 SIP phone behind the eSBC:192.168.1.151 SIP phone behind the NAT: 192.168.6.253 eSBC WAN IP: 192.168.60.228 NAT WAN IP: 192.168.60.102 eSBC file name: eth1-EM.pcap shows 192.168.60.228 to 192.168.60.239 contact header as sip:1000@192.168.60.228:5060;transport=udp The return 200 OK contact header is sip:1000@192.168.60.239:5060;transport=udp NAT pcap file name eth1-NAT.pcap shows 192.168.60.102 to 192.168.60.239 contact header as sip:1000@192.168.60.102:5060;transport=udp The return 200 OK contact header is sip:1000@192.168.60.239:5060;transport=udp According to the Ribbon support engineer this is a violation of the RFC 3261. When not using the SD-wan the eSBC just passes the information. But when using SD-Wan all traffic must go through the B2BUA and that logic causes the registration to drop because the contact header is being rewritten on the way back. I have verified this in both Asterisk 16 and 13. By: Joshua C. Colp (jcolp) 2021-01-06 17:36:52.154-0600 Please provide the CLI output of "pjsip show endpoint 1000" as well as a SIP trace from the CLI using "pjsip set logger on" to confirm both configuration, and what Asterisk is actually sending. By: Joshua C. Colp (jcolp) 2021-01-06 17:39:52.355-0600 I should also add that the "rewrite_contact" option rewrites it to the source IP address and port, which is not happening here. It is being changed to the IP address and port of Asterisk which is different, and not something I've ever seen chan_pjsip do within a REGISTER like this. Do you have NAT configuration applied on the PJSIP transport? By: Brian Paboojian (braptor) 2021-01-06 17:50:33.760-0600 Endpoint: 1000/1000 Unavailable 0 of inf InAuth: 1000-auth/1000 Aor: 1000 1 ParameterName : ParameterValue ============================================================== 100rel : yes accept_multiple_sdp_answers : false accountcode : acl : aggregate_mwi : true allow : (ulaw|alaw|gsm|g726|g722) allow_overlap : true allow_subscribe : true allow_transfer : true aors : 1000 asymmetric_rtp_codec : false auth : 1000-auth bind_rtp_to_media_address : false bundle : false call_group : callerid : "Ext 1000" <1000> callerid_privacy : allowed_not_screened callerid_tag : connected_line_method : invite contact_acl : context : from-internal cos_audio : 5 cos_video : 4 device_state_busy_at : 0 direct_media : true direct_media_glare_mitigation : none direct_media_method : invite disable_direct_media_on_nat : false dtls_auto_generate_cert : No dtls_ca_file : dtls_ca_path : dtls_cert_file : dtls_cipher : dtls_fingerprint : SHA-256 dtls_private_key : dtls_rekey : 0 dtls_setup : active dtls_verify : No dtmf_mode : rfc4733 fax_detect : false fax_detect_timeout : 0 follow_early_media_fork : true force_avp : false force_rport : true from_domain : from_user : g726_non_standard : false ice_support : false identify_by : username,ip ignore_183_without_sdp : false inband_progress : false incoming_mwi_mailbox : language : en mailboxes : max_audio_streams : 1 max_video_streams : 1 media_address : media_encryption : no media_encryption_optimistic : false media_use_received_transport : false message_context : moh_passthrough : false moh_suggest : default mwi_from_user : mwi_subscribe_replaces_unsolicited : no named_call_group : named_pickup_group : notify_early_inuse_ringing : false one_touch_recording : true outbound_auth : outbound_proxy : pickup_group : preferred_codec_only : false record_off_feature : apprecord record_on_feature : apprecord refer_blind_progress : true rewrite_contact : false rpid_immediate : false rtcp_mux : false rtp_engine : asterisk rtp_ipv6 : false rtp_keepalive : 0 rtp_symmetric : true rtp_timeout : 30 rtp_timeout_hold : 300 sdp_owner : - sdp_session : Asterisk send_connected_line : yes send_diversion : true send_history_info : false send_pai : true send_rpid : false set_var : srtp_tag_32 : false stir_shaken : false sub_min_expiry : 0 subscribe_context : suppress_q850_reason_headers : false t38_udptl : false t38_udptl_ec : none t38_udptl_ipv6 : false t38_udptl_maxdatagram : 0 t38_udptl_nat : false timers : yes timers_min_se : 90 timers_sess_expires : 1800 tone_zone : tos_audio : 184 tos_video : 136 transport : trust_connected_line : yes trust_id_inbound : true trust_id_outbound : false use_avpf : false use_ptime : false user_eq_phone : false voicemail_extension : webrtc : no By: Brian Paboojian (braptor) 2021-01-06 17:59:15.067-0600 From the eSBC; <--- Transmitting SIP response (501 bytes) to UDP:192.168.60.228:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.60.228:5060;rport=5060;received=192.168.60.228;branch=z9hG4bKaaee5f51365725e40 Record-Route: <sip:1000@192.168.60.228;transport=udp;lr> Call-ID: 61d0382ae00b720d From: <sip:1000@192.168.60.239>;tag=77de8a3de3 To: <sip:1000@192.168.60.239>;tag=z9hG4bKaaee5f51365725e40 CSeq: 103061152 REGISTER Date: Wed, 06 Jan 2021 23:57:47 GMT Contact: <sip:1000@192.168.60.239:5060;transport=udp>;expires=3599 Server: FPBX-15.0.17.12(16.15.1) Content-Length: 0 By: Brian Paboojian (braptor) 2021-01-06 18:04:53.657-0600 From the NAT device; <--- Transmitting SIP request (449 bytes) to UDP:192.168.60.102:5060 ---> OPTIONS sip:1000@192.168.60.102:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.60.239:5060;rport;branch=z9hG4bKPj87b2c3e3-d523-43cc-b8e6-8c420031903d From: <sip:1000@192.168.60.239>;tag=e217a666-54ab-454d-aa44-a9662ce5e317 To: <sip:1000@192.168.60.102> Contact: <sip:1000@192.168.60.239:5060> Call-ID: 0086d5ee-cdbf-4848-83bb-67e0a42b0b52 CSeq: 53638 OPTIONS Max-Forwards: 70 User-Agent: FPBX-15.0.17.12(16.15.1) Content-Length: 0 By: Brian Paboojian (braptor) 2021-01-06 18:09:43.724-0600 SIP settings; [0.0.0.0-udp] type=transport protocol=udp bind=0.0.0.0:5060 external_media_address=192.168.60.239 external_signaling_address=192.168.60.239 allow_reload=no tos=cs3 cos=3 By: Joshua C. Colp (jcolp) 2021-01-06 18:13:47.224-0600 If external_media_address and external_signaling_address are removed, the issue won't be present. There is a bug in that functionality. By: Brian Paboojian (braptor) 2021-01-06 19:30:47.103-0600 That fixed the problem. I set it like this; [0.0.0.0-udp] type=transport protocol=udp bind=0.0.0.0:5060 allow_reload=no tos=cs3 cos=3 The headers are no longer being rewritten and B2BUA and now working properly. Thank you very much for your help. By: Ross Beer (rossbeer) 2021-02-24 08:07:58.413-0600 Will the patch on Gerrit also resolve ASTERISK-29200? These appear to be related By: Joshua C. Colp (jcolp) 2021-02-24 08:13:32.786-0600 Do you have external_signaling_address set? If not, then no. By: Ross Beer (rossbeer) 2021-02-24 08:18:08.554-0600 No, we don't use that setting, however, it is a similar issue breaking the same RFCs as this ticket. By: Joshua C. Colp (jcolp) 2021-02-24 08:21:19.718-0600 This specific issue is in regards to external_signaling_address being applied to the signaling when it shouldn't. The patch resolves that issue. If you are not using external_signaling_address then the patch would have no effect. By: Friendly Automation (friendly-automation) 2021-03-03 12:08:34.279-0600 Change 15495 merged by Joshua Colp: res_pjsip_nat: Don't rewrite Contact on REGISTER responses. [https://gerrit.asterisk.org/c/asterisk/+/15495|https://gerrit.asterisk.org/c/asterisk/+/15495] By: Friendly Automation (friendly-automation) 2021-03-03 12:08:42.998-0600 Change 15516 merged by Joshua Colp: res_pjsip_nat: Don't rewrite Contact on REGISTER responses. [https://gerrit.asterisk.org/c/asterisk/+/15516|https://gerrit.asterisk.org/c/asterisk/+/15516] By: Friendly Automation (friendly-automation) 2021-03-03 12:27:34.627-0600 Change 15515 merged by Joshua Colp: res_pjsip_nat: Don't rewrite Contact on REGISTER responses. [https://gerrit.asterisk.org/c/asterisk/+/15515|https://gerrit.asterisk.org/c/asterisk/+/15515] By: Friendly Automation (friendly-automation) 2021-08-12 10:21:58.408-0500 Change 16279 merged by Friendly Automation: res_pjsip_nat: Don't rewrite Contact on REGISTER responses. [https://gerrit.asterisk.org/c/asterisk/+/16279|https://gerrit.asterisk.org/c/asterisk/+/16279] |