[asterisk-users] PJSIP Losing knowledge of external_media_address

[George Joseph]

On Fri, Aug 18, 2023 at 10:09 AM Mark Murawski <markm-lists at intellasoft.net>
wrote:

> I've seen this happen three times in the wild now.  I've been trying to
> isolate the source of the issue, but so far it seems like there's not
> enough debug output to know why this occurs.
>
> Long story short:
> - Start Asterisk
> - PJSIP Handles receiving INVITE from ITSP via WAN (Asterisk is behind
> NAT).  SIP is handled correctly, Asterisk responds OK with RTP media
> address of external_media_address
> - After 30 minutes to an hour or sometimes months later after startup,
> upon receiving INVITE from ITSP via WAN, Asterisk responds OK with
> INTERNAL LAN IP instead of external_media_address
> - I've observed this occur after 30 minutes from startup with no
> configuration changes that were made or any pjsip reloads done during
> this period
>

Any network change activity going on at the time?  VPN coming up or down?
Network interface flapping? DNS availability issue (could still be an issue
even though you're using ip addresses for local_net)?

One way to get more information would be to modify
that ast_sip_transport_is_local block in
res_pjsip_session:session_outgoing_nat_hook to print more debug info if the
ast_sip_transport_is_local check fails and the destination is your itsp.
If you want really detailed info, you could compile with DONT_OPTIMIZE and
put an abort() in there then run ast_coredumper when asterisk crashes to
get the backtrace.  That's a service disruption of course.



>
> pjsip
> -------------
> [global]
> endpoint_identifier_order = username,ip,anonymous
>
> [system]
> type=system
> threadpool_initial_size=30
> threadpool_auto_increment=5
> threadpool_idle_timeout=0
> threadpool_max_size=100
>
> [transport-udp]
> type                       = transport
> symmetric_transport        = yes
> protocol                   = udp
> bind                       = 0.0.0.0:5060
> external_media_address     = 152.X.Y.Z
> external_signaling_address = 152.X.Y.Z
> external_signaling_port    = 5060
> allow_reload               = no
> tos                        = cs3
> cos                        = 3
> local_net                  = 127.0.0.1/24
> local_net                  = 192.168.50.0/24
> local_net                  = 192.168.1.0/24
> local_net                  = 10.3.2.0/24
> local_net                  = 10.20.1.0/24
> local_net                  = 10.10.41.0/24
> local_net                  = 10.5.1.0/24
>
> pjsip_wizard
> -------------
>
> [isoft-sr-in-1]
> type = wizard
> transport = transport-udp
> remote_hosts = 192.81.237.20
> aor/max_contacts = 1
> aor/remove_existing = yes
> aor/qualify_frequency = 60
> aor/qualify_timeout = 2000
> endpoint/ice_support = no
> endpoint/disallow = g723,slin,ilbc,lpc10,g729,speex,g726aal2,g722
> endpoint/allow = ulaw,alaw,adpcm,gsm
> endpoint/direct_media = no
> endpoint/force_rport = yes
> endpoint/rewrite_contact = yes
> endpoint/rtp_keepalive = 30
> endpoint/rtp_symmetric = yes
> endpoint/rtp_timeout = 60
> endpoint/rtp_timeout_hold = 60
> endpoint/send_pai = yes
> endpoint/send_rpid = yes
> endpoint/trust_id_inbound = yes
> endpoint/trust_id_outbound = yes
> endpoint/trust_connected_line = no
> endpoint/send_connected_line = no
> endpoint/context = trunkhandler_pbx-sip-t1
>
>
> Attached sip sessions and debug log... the only thing I found
> interesting was finding a lack of a log item
> We SHOULD be seeing:
> DEBUG[XXXXX] res_pjsip_session.c: (null session): Setting external media
> address to 152.X.Y.Z
> This message is clearly lacking from the debug session where the
> incorrect media address is sent.  But there's not enough detail in the
> debugs to see why this decision was not made to use external_media_address
>
> By default we use nat settings for all our endpoints, but obviously it's
> not required here for an ITSP that has trustworthy media ports in the
> SDP.  Maybe a bandaid is turning off rewrite_contact for this endpoint?
> Going to try that as soon as possible.
>
> Why is external_media_address not being used all of a sudden?  Has
> anyone else seen this... is this a bug?--
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230818/7a79ec1c/attachment.html>