pin ср, 6 янв. 2021 г. в 1:02, Mark Murawski <markm-li...@intellasoft.net>:
> Hi! > > I have the following situation here: > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ; WAN1 and traffic to PBX-A / PBX-B > > [transport-udp] > type = transport > symmetric_transport = yes > protocol = udp > bind = 10.13.13.38:5060 > external_media_address = XX.94.171.40 > external_signaling_address = XX.94.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 > symmetric_transport = yes > protocol = tcp > bind = 10.13.13.38:5060 > external_media_address = XX.94.171.40 > external_signaling_address = XX.94.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-tls] > type = transport > symmetric_transport = yes > protocol = tls > allow_reload = yes > bind = 10.13.13.38:5061 > external_media_address = XX.94.171.40 > external_signaling_address = XX.94.171.40 > external_signaling_port = 5061 > tos = cs3 > cos = 3 > cert_file = /etc/asterisk/keys/asterisk.crt > priv_key_file = /etc/asterisk/keys/asterisk.key > method = tlsv1_2 > local_net = 192.168.181.0/24 > local_net = 10.13.13.0/24 > > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;;; WAN2 > ; > [transport-udp-wan2] > type = transport > symmetric_transport = yes > protocol = udp > bind = 10.13.13.39:5060 > external_media_address = YY.9.5.40 > external_signaling_address = YY.9.5.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-wan2] > type = transport > symmetric_transport = yes > protocol = tcp > bind = 10.13.13.39:5060 > external_media_address = YY.9.5.40 > external_signaling_address = YY.9.5.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-wan2-tls] > type = transport > symmetric_transport = yes > protocol = tls > allow_reload = yes > bind = 10.13.13.39:5061 > external_media_address = YY.9.5.40 > external_signaling_address = YY.9.5.40 > external_signaling_port = 5061 > tos = cs3 > cos = 3 > cert_file = /etc/asterisk/keys/asterisk.crt > priv_key_file = /etc/asterisk/keys/asterisk.key > method = tlsv1_2 > local_net = 192.168.181.0/24 > local_net = 10.13.13.0/24 > > I then have the following call > > INVITE > (Call is attached) > > Packet from: ZZ.75.184.42 > Packet To: -> YY.9.5.40 (Ie: WAN2), Then firewall DNATs to > 10.13.13.39:5061, and asterisk gets the call > > Use Case: > Now... in order for this dual-wan to operate correctly... say WAN1 is > down. Asterisk needs to be able to send RTP traffic (not just SIP > Signalling) using the correct rtp bind, associated to the correct return > transport and external_media_address > > My expectation here is that since Asterisk knows it's using > transport-tcp-wan2-tls, and it has set the correct media source in the > SDP to YY.9.5.40, that the RDP engine would then send media from > 10.13.13.39. But it does not.... > > During the above call, the outgoing RTP looks like this from tcpdump: > 08:52:13.234702 IP 10.13.13.38.16384 > ZZ.75.184.42.7078: UDP, length 182 > > The closest thing I've found so far in digging deeper to resolve this > is: res_pjsip_sdp_rtp.c > > static int create_rtp(struct ast_sip_session *session, struct > ast_sip_session_media *session_media, > const pjmedia_sdp_session *sdp) > { > ....snip.... > transport = > ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "transport", > session->endpoint->transport); > if (transport) { > struct ast_sip_transport_state *trans_state; > > trans_state = > ast_sip_get_transport_state(ast_sorcery_object_get_id(transport)); > if (trans_state) { > char hoststr[PJ_INET6_ADDRSTRLEN]; > > pj_sockaddr_print(&trans_state->host, > hoststr, sizeof(hoststr), 0); > if > (ast_sockaddr_parse(&temp_media_address, hoststr, 0)) { > ast_debug_rtp(1, "Transport %s > bound to %s: Using it for RTP media.\n", > > session->endpoint->transport, hoststr); > media_address = > &temp_media_address; > } else { > ast_debug_rtp(1, "Transport %s > bound to %s: Invalid for RTP media.\n", > > session->endpoint->transport, hoststr); > } > ao2_ref(trans_state, -1); > } > ao2_ref(transport, -1); > } > > > Here we check if the transport is explicitly bound, and if so, we use > it.... now if I do explicitly set the transport to > transport-tcp-wan2-tls instead of leaving it unset, then RTP is sourced > from the correct address. > > But this is a dynamic contact which could be talking to asterisk either > on the 'WAN1' transports or the 'WAN2' transports. > > Given that SIP OPTIONS and such will go back to the correct transport, > given the transport configuration above, it seems logical we should also > be able to send RTP using the associated transport settings as well. > > So the issue here is that in res_pjsip_sdp_rtp.c, create_rtp(). I don't > see a way to find the associated endpoint/contact... it's all pointing > to null at this time. > > Am I in the right place? Is there a further down the line place to > handle rtp source, or is there a way to pull up the dynamically stored > AST_SIP_X_AST_TXP here? > > Also... speaking of AST_SIP_X_AST_TXP, it doesn't appear to be set in > all situations either. Looking at core debug, logging and hits to > 'res_pjsip/pjsip_message_filter.c: Set transport', result in absolutely > no usage of any of the -tls transports when OPTIONS come in from this > peer, or any peer using tls. > > Examples: > [2021-01-04 23:57:41.328] DEBUG[16309] res_pjsip/pjsip_message_filter.c: > Set transport 'transport-udp' on OPTIONS from 192.168.181.5:5060 > [2021-01-04 23:57:41.927] DEBUG[16309] res_pjsip/pjsip_message_filter.c: > Set transport 'transport-udp' on OPTIONS from 192.168.181.5:5060 > > But, that's it... when getting OPTIONS over TLS, this is not tracked. > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev