Mark Murawski
2023-Aug-18 16:09 UTC
[asterisk-users] PJSIP Losing knowledge of external_media_address
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 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.log Type: text/x-log Size: 28770 bytes Desc: not available URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230818/b65ab0fa/attachment-0001.bin>
Joshua C. Colp
2023-Aug-18 16:41 UTC
[asterisk-users] PJSIP Losing knowledge of external_media_address
On Fri, Aug 18, 2023 at 1:09 PM 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 > ><snip>> > > 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 >Can't you just extend the debug and add further logging to understand the choices being made and why?> > 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. >I believe I've stated this once or twice when you've brought this issue up on IRC but rewrite_contact has no influence or impact on this. It rewrites incoming Contact headers to the source IP address and port of the SIP message. You can turn it on if you wish, but it is unlikely to do anything.> > Why is external_media_address not being used all of a sudden? Has > anyone else seen this... is this a bug?-- >With the limited insight into things it could be a bug. I haven't seen any other reports, and haven't received any reports from other Sangoma products. Is this with a mainline Asterisk, or is it your patched version of Asterisk? It should be confirmed on normal Asterisk. -- Joshua C. Colp Asterisk Project Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230818/6e6830ec/attachment.html>
George Joseph
2023-Aug-18 16:55 UTC
[asterisk-users] PJSIP Losing knowledge of external_media_address
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>