| Summary: | ASTERISK-29202: res_pjsip: Cannot send OPTIONS to endpoint when transport= is unset and multiple explicitly bound transports | ||
| Reporter: | Mark Murawski (kobaz) | Labels: | |
| Date Opened: | 2020-12-07 20:55:37.000-0600 | Date Closed: | 2021-03-13 07:59:45.000-0600 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_pjsip |
| Versions: | 16.15.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Reasonably complex setup here, but nothing out of the ordinary. We have multiple ways to get in and out of this box, and we need to make sure Asterisk uses the right settings for the right subnet!
{noformat} -------------------------------- pjsip.conf ------------------------------- [transport-udp-lo] type = transport protocol = udp bind = 127.0.0.1:5060 external_media_address = 127.0.0.1 external_signaling_address = 127.0.0.1 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 [transport-udp-tun0] type = transport protocol = udp bind = 10.1.2.20:5060 external_media_address = 10.1.2.20 external_signaling_address = 10.1.2.20 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 10.1.2.0/24 [transport-udp-tun1] type = transport protocol = udp bind = 10.3.2.20:5060 external_media_address = 10.3.2.20 external_signaling_address = 10.3.2.20 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 10.3.2.0/24 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; WAN1 and traffic to PBX-A / PBX-B [transport-udp] type = transport protocol = udp bind = 10.13.13.38:5060 external_media_address = XX.YY.171.40 external_signaling_address = XX.YY.171.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 local_net = 10.13.13.0/24 [transport-tcp] type = transport protocol = tcp bind = 10.13.13.38:5060 external_media_address = XX.YY.171.40 external_signaling_address = XX.YY.171.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 [transport-tcp-tls] type = transport protocol = tls bind = 10.13.13.38:5061 external_media_address = XX.YY.171.40 external_signaling_address = XX.YY.171.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 local_net = 10.13.13.0/24 cert_file = /etc/asterisk/keys/asterisk.crt priv_key_file = /etc/asterisk/keys/asterisk.key method = sslv23 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; WAN2 [transport-udp-wan2] type = transport protocol = udp bind = 10.13.13.39:5060 external_media_address = ZZ.QQ.5.40 external_signaling_address = ZZ.QQ.5.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 [transport-tcp-wan2] type = transport protocol = tcp bind = 10.13.13.39:5060 external_media_address = XX.YY.171.40 external_signaling_address = XX.YY.171.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 [transport-tcp-wan2-tls] type = transport protocol = tls bind = 10.13.13.39:5061 external_media_address = ZZ.QQ.5.40 external_signaling_address = ZZ.QQ.5.40 external_signaling_port = 5060 allow_reload = yes tos = cs3 cos = 3 local_net = 192.168.181.0/24 cert_file = /etc/asterisk/keys/asterisk.crt priv_key_file = /etc/asterisk/keys/asterisk.key method = sslv23 -------------------------------- pjsip_wizard.conf - Via psql extconfig -------------------------------- 21005 | type | wizard 21005 | accepts_registrations | yes 21005 | accepts_auth | yes 21005 | aor/max_contacts | 4 21005 | aor/remove_existing | yes 21005 | endpoint/context | cos_internal+local+ld 21005 | endpoint/callerid | <21005> 21005 | endpoint/aggregate_mwi | yes 21005 | endpoint/mailboxes | 21005@internal 21005 | endpoint/set_var | __ExtenMailBox=21005@internal 21005 | endpoint/set_var | __Tenant=default 21005 | endpoint/set_var | __DeviceType=Exten 21005 | endpoint/set_var | __DeviceTenantName=default 21005 | endpoint/set_var | __ExtenDevice=SIP/21005 21005 | endpoint/set_var | __ExtenDeviceName=21005 21005 | endpoint/set_var | __ExtenPhoneNum=21005 21005 | endpoint/set_var | __ExtenPhoneGroup=internal 21005 | endpoint/ice_support | no 21005 | inbound_auth/username | 21005 21005 | inbound_auth/password | correcthorsebatterystaple 21005 | outbound_auth/username | 21005 21005 | outbound_auth/password | correcthorsebatterystaple 21005 | aor/qualify_frequency | 60 21005 | aor/qualify_timeout | 2000 21005 | endpoint/allow | ulaw,alaw,adpcm,gsm 21005 | endpoint/allow_subscribe | yes 21005 | endpoint/direct_media | no 21005 | endpoint/disallow | g723,slin,ilbc,lpc10,g729,speex,g726aal2,g722 21005 | endpoint/force_rport | yes 21005 | endpoint/log_subscription_error | no 21005 | endpoint/rewrite_contact | yes 21005 | endpoint/rtp_symmetric | yes 21005 | endpoint/rtp_timeout | 60 21005 | endpoint/rtp_timeout_hold | 60 21005 | endpoint/send_pai | yes 21005 | endpoint/send_rpid | yes 21005 | endpoint/subscribe_context | blf 21005 | endpoint/trust_id_inbound | no 21005 | endpoint/trust_id_outbound | yes -------------------------------- {noformat} Notes: Setting transport=transport-udp will 'work' and pjsip can successfully send SIP OPTIONS to this endpoint/contact, but if say the endpoint initiates a call to Asterisk via transport-udp-tun0, obviously asterisk will respond on the wrong transport and things will not work. Generic setting of having NO transport= will allow INVITEs to process from this endpoint to Asterisk properly and two way audio is successful and all that good stuff. But asterisk cannot 'reach' the endpoint, because now it considers it down -------------------------------- The situation: {noformat} [2020-12-07 16:26:06.157] VERBOSE[19882] res_pjsip_registrar.c: Added contact 'sip:21005@AA.BB.184.42:56567;ob;x-ast-orig-host=192.168.125.103:56567' to AOR '21005' with expiration of 60 seconds [2020-12-07 17:12:19.060] ERROR[3674] res_pjsip.c: Error 171060 'Unsupported transport (PJSIP_EUNSUPTRANSPORT)' sending OPTIONS request to endpoint 21005 {noformat} NOTIFY doesn't work either.... here's the core debug level 9 {noformat} [2020-12-07 21:53:09.056] DEBUG[3674] res_pjsip_registrar.c: Refreshed contact 'sip:21005@AA.BB.184.42:56567;ob;x-ast-orig-host=192.168.125.103:56567' on AOR '21005' with new expiration of 60 seconds [2020-12-07 21:53:09.056] DEBUG[3674] netsock2.c: Splitting 'AA.BB.184.42' into... [2020-12-07 21:53:09.056] DEBUG[3674] netsock2.c: ...host 'AA.BB.184.42' and port ''. [2020-12-07 21:53:09.056] DEBUG[3674] res_pjsip_nat.c: Re-wrote Contact URI port to 5060 [2020-12-07 21:53:09.056] DEBUG[3674] res_pjsip_nat.c: Restoring contact 38.94.171.40:5060 to 192.168.125.103:56567 [2020-12-07 21:53:09.056] DEBUG[25739] res_pjsip_mwi.c: Sending unsolicited MWI NOTIFY to endpoint 21005, new messages: 0, old messages: 0 [2020-12-07 21:53:09.059] DEBUG[25739] config.c: extract double from [3.0] in [-inf, inf] gives [3.000000](0) [2020-12-07 21:53:09.059] DEBUG[25739] config.c: extract uint from [0] in [0, 4294967295] gives [0](0) [2020-12-07 21:53:09.059] DEBUG[25739] config.c: extract double from [2000.000000] in [-inf, inf] gives [2000.000000](0) [2020-12-07 21:53:09.059] DEBUG[25739] config.c: extract uint from [56567] in [0, 4294967295] gives [56567](0) [2020-12-07 21:53:09.059] DEBUG[25739] config.c: extract uint from [60] in [0, 86400] gives [60](0) [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip.c: 0x7f27ac03d400: Wrapper created [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'AA.BB.184.42' [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip/pjsip_resolver.c: Transport type for target 'AA.BB.184.42' is 'UDP transport' [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip/pjsip_resolver.c: Target 'AA.BB.184.42' is an IP address, skipping resolution [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip.c: 0x7f27ac03d400: PJSIP tsx response received [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip.c: 0x7f27ac03d400: Callbacks executed [2020-12-07 21:53:09.059] ERROR[25739] res_pjsip.c: Error 171060 'Unsupported transport (PJSIP_EUNSUPTRANSPORT)' sending NOTIFY request to endpoint 21005 [2020-12-07 21:53:09.059] DEBUG[25739] res_pjsip.c: 0x7f27ac03d400: wrapper destroyed {noformat} | ||
| Comments: | By: Asterisk Team (asteriskteam) 2020-12-07 20:55:39.073-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) 2020-12-09 04:17:32.378-0600 If you add a transport which is bound to 0.0.0.0 does this alter the behavior? By: Mark Murawski (kobaz) 2020-12-09 08:38:50.808-0600 Having a transport explicitly bound do 0.0.0.0 will conflict, and prevent all the other transports from binding. If I *only* have a transport bound to 0.0.0.0, then yes, SIP OPTIONS can send correctly and all that, but then external media and external signalling is all wrong of course. By: Mark Murawski (kobaz) 2020-12-09 11:03:06.439-0600 It's almost like transports need to be not specifically bound to ip/port, but have one transport and then have like interface options Proposed Design PseudoCFG Example: [transport-udp] type=transport bind=0.0.0.0:5060 [transport-udp] type=transport_rule transport=transport-udp <-- link to the above transport interface=1.2.3.4:5060 <-- handle traffic to/from 1.2.3.4:5060 differently... endpoint can optionally set transport_rule=transport-udp external_media_address = XX.YY.171.40 external_signaling_address = XX.YY.171.40 external_signaling_port = 5060 other_rule=.... This accomplishes multiple things here... one, simplify the network level and have one bind for 5060 If an endpoint wants to register a contact over the internet via 1.2.3.4:5060... apply the above rules for communication with that endpoint/contact without needing an new stack bound Ie: set up a rule so that if an endpoint contact is contacting us on 1.2.3.4:5060, as shown above... use different external_* settings without having to bind another transport By: Joshua C. Colp (jcolp) 2020-12-09 11:06:16.121-0600 That's jumping to premature ideas without a true understanding of the underlying issue here. By: Mark Murawski (kobaz) 2020-12-09 11:07:16.257-0600 I agree it might not fix my issue, but I think it's a good idea to not require binds for differing transport rules. Which should be split off into its own issue. By: Joshua C. Colp (jcolp) 2020-12-09 11:09:44.197-0600 We don't currently accept feature requests on the issue tracker, which such a thing would be. By: Joshua C. Colp (jcolp) 2020-12-09 11:57:37.652-0600 If you remove the *wan2 entries does a transport get selected? By: Mark Murawski (kobaz) 2020-12-09 21:45:05.857-0600 With WAN2 completely removed. I get a different error, all else being equal: [2020-12-09 22:36:57.757] ERROR[24546]: res_pjsip.c:4361 endpt_send_request: Error 120022 'Invalid argument' sending OPTIONS request to endpoint 21005 This endpoint/contact is coming in via tun0 transport Same thing occurs when coming in via tun1 Same things occurs when coming in via wan1 (transport-udp) By: Joshua C. Colp (jcolp) 2020-12-10 10:15:34.165-0600 Do you have only tunnel interfaces for the transports? I was attempting to reproduce using strictly IP aliases on a single interface, and it did not occur. By: Mark Murawski (kobaz) 2020-12-10 10:30:55.618-0600 Hi Josh, The transports are all the ones listed in the original report. When you asked to disable wan2, and the problem still persists. I had the following transports: transport-udp-lo transport-udp-tun0 transport-udp-tun1 transport-udp transport-tcp transport-tcp-tls By: Mark Murawski (kobaz) 2020-12-10 10:32:55.015-0600 I have physical interfaces for the transports and some aliased. Here you go: You could simulate with multiple nic's on a vm to replication my setup eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.13.13.38 netmask 255.255.255.0 broadcast 10.13.13.255 inet6 fe80::250:56ff:fe98:d2b1 prefixlen 64 scopeid 0x20<link> ether 00:50:56:98:d2:b1 txqueuelen 1000 (Ethernet) RX packets 186100996 bytes 137264107722 (127.8 GiB) RX errors 0 dropped 11913 overruns 0 frame 0 TX packets 130909291 bytes 178101476954 (165.8 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.13.13.39 netmask 255.0.0.0 broadcast 10.255.255.255 ether 00:50:56:98:d2:b1 txqueuelen 1000 (Ethernet) lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 1770465537 bytes 650315372471 (605.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1770465537 bytes 650315372471 (605.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.1.2.20 netmask 255.255.255.255 destination 10.1.2.18 inet6 fe80::b02a:ead8:6201:a8fb prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 39711456 bytes 2097223819 (1.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 79349830 bytes 110789017750 (103.1 GiB) TX errors 0 dropped 9696 overruns 0 carrier 0 collisions 0 tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.3.2.20 netmask 255.255.255.255 destination 10.3.2.19 inet6 fe80::766:a7cb:ae9b:801b prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 1271856 bytes 418111602 (398.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1135856 bytes 411590761 (392.5 MiB) TX errors 0 dropped 6 overruns 0 carrier 0 collisions 0 tun2: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.20.1.1 netmask 255.255.255.255 destination 10.20.1.2 inet6 fe80::ee4e:ab41:32d:7796 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 31097351 bytes 43433594166 (40.4 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6679661 bytes 351878934 (335.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 From the outside world, we have WAN1 -> DNAT 10.13.13.38 and WAN2 -> DNAT 10.13.13.39 By: Mark Murawski (kobaz) 2020-12-31 12:44:04.610-0600 Hi Josh, Curious if there's been any headway in figuring out why a transport isn't available when one isn't explicitly specified in this scenario? By: Joshua C. Colp (jcolp) 2020-12-31 13:14:56.573-0600 There is noone actively working on this issue. If that changes then the assignee will be set, and said individual will post any update or comments here if they have any. By: Mark Murawski (kobaz) 2021-01-04 21:09:45.939-0600 With the main issue being that Asterisk is not utilizing the same transport that thee request came in on.... I've been experimenting with symmetric_transport = yes to no avail... the documentation seems to indicate that this is exactly the situation the setting is designed to handle: symmetric_transport When a request from a dynamic contact comes in on a transport with this option set to 'yes', the transport name will be saved and used for subsequent outgoing requests like OPTIONS, NOTIFY and INVITE. It seems to address some issues related to transport, but it does not seem to affect the RTP engine's source address however. By: Mark Murawski (kobaz) 2021-03-13 07:59:29.719-0600 I'm not sure what the difference is here, but I'm unable to reproduce the behavior in 16.16.1. This can be closed. By: Ilya Demyanov (Turbid) 2022-12-16 02:49:36.256-0600 I encountered a similar problem on Asterisk 20.0.1 - the response to INVITE comes from the correct transport, but on OPTIONS - from the wrong one. https://community.asterisk.org/t/wrong-transport-selection-to-reply-to-options/95046/5 | ||