ASTERISK-29235: res_pjsip_nat: Contact is rewritten on REGISTER responses with external_signaling

[Home]

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]