ASTERISK-28551: IPv4 address in SDP o= is (null) when configured for NAT using pjsip

[Home]

Summary: ASTERISK-28551: IPv4 address in SDP o= is (null) when configured for NAT using pjsip

Reporter: Brian J. Murrell (brian_j_murrell) Labels: fax pjsip

Date Opened: 2019-09-23 08:59:00 Date Closed: 2019-09-24 11:17:35

Priority: Major Regression?

Status: Closed/Complete Components: pjproject/pjsip

Versions: 13.28.1 Frequency of
Occurrence Constant

Related
Issues:

Environment: Attachments:

Description: If I configure my pjsip transport to handle NAT from the Internet:

{noformat}
[transport-tcp]
type=transport
protocol=tcp
bind=10.75.22.8:5060
local_net=10.75.22.0/24
external_media_address=[external address redacted]
external_signaling_address=[external address redacted]
{noformat}

When a call comes from a TCP registered SIP client on the Internet,
Asterisk is setting the IPv4 address in the {{o=}} and {{c=}} lines of the
SDP ICE payload to {{(null)}}:

{noformat}
v=0
o=- 3654 548 IN IP4 (null)
s=Asterisk
c=IN IP4 (null)
{noformat}

IPv4 addresses in all of the {{a=}} lines are still correct.

This {{(null)}} of course causes the caller to fail to complete the call.

Comments: By: Asterisk Team (asteriskteam) 2019-09-23 08:59:01.436-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].

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.
By: Asterisk Team (asteriskteam) 2019-09-23 08:59:02.556-0500

The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process.
By: George Joseph (gjoseph) 2019-09-23 13:05:17.737-0500

Can you paste the output of {{pjsip show endpoint <endpoint>}} for the endpoint involved. Also do you have any ice_host_candidates defined in rtp.conf?

By: Brian J. Murrell (brian_j_murrell) 2019-09-23 19:17:55.640-0500

{noformat}
server*CLI> pjsip show endpoint brian_h8

Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.>
I/OAuth: <AuthId/UserName...........................................................>
Aor: <Aor............................................> <MaxContact>
Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................>
Identify: <Identify/Endpoint.........................................................>
Match: <criteria.........................>
Channel: <ChannelId......................................> <State.....> <Time.....>
Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......>
==========================================================================================

Endpoint: brian_h8 Not in use 0 of inf
InAuth: brian_h8/brian_h8
Aor: brian_h8 1
Contact: brian_h8/sip:brian_h8@10.75.22.32:57886;tr 3a9cc4d1c3 Unknown nan

ParameterName : ParameterValue
=========================================================
100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (ulaw|gsm)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
aors : brian_h8
asymmetric_rtp_codec : false
auth : brian_h8
bind_rtp_to_media_address : false
call_group :
callerid : <unknown>
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
contact_acl :
context : internal-sip
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : true
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
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 : pbx.example.com
from_user :
g726_non_standard : false
ice_support : true
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_mwi_mailbox :
language :
mailboxes : 2000
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context : messages
moh_suggest : default
mwi_from_user : 2003
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording : false
outbound_auth :
outbound_proxy :
pickup_group :
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : false
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
send_connected_line : yes
send_diversion : true
send_pai : false
send_rpid : false
set_var :
srtp_tag_32 : 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 : 0
tos_video : 0
transport :
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : true
use_ptime : false
user_eq_phone : false
voicemail_extension :
{noformat}

It's not lost on me that {{transport:}} above is empty. But that's because I don't want to assign a specific transport but allow the client to decide what to use.

I did try assigning the specific transport from the *Description* to the endpoint in question with:

{{transport=transport-tcp}}

but that didn't seem to resolve the issue.

No {{ice_host_candidates}} defined in {{rtp.conf}}.
By: Brian J. Murrell (brian_j_murrell) 2019-09-24 05:04:28.680-0500

OK. Figured out the issue:

{noformat}
; You can have more than one of any type of transport, as long as it doesn't
; use the same resources (bind address, port, etc) as the others.
{noformat}

In all of the messing around to get it figure out, I had both a {{transport-tcp-ipv4-nat}} and {{transport-tcp}} defined with the same bind addresses.

Additionally, it seems changing transports, particularly things to do with {{local_net}} requires an Asterisk restart, not just a {{pjsip reload}}.

Of course, having both {{transport-tcp-ipv4-nat}} and {{transport-tcp}} defined is not really necessary as as Asterisk will determine if the client is across the NAT from it and therefore needs to employ }{{external_media_address}} and/or {{external_signaling_address}}.

As an aside, if either of the {{external_*_address}} values is a hostname, when is that name resolved to an IP address?

Perhaps some other result than invalid SDP would be better in this type of case. I would think that if that value ends up being {{(null)}} some kind of error or warning on the console would be useful. It took quite some digging to even figure out that was the symptom.

By: George Joseph (gjoseph) 2019-09-24 11:17:21.112-0500

The hostnames are resolved when the transport loads then at the interval specified in the dnsmgr.conf file.

Good point about the warning/error. I'll create an internal issue for that.