[asterisk-dev] [PJSIP] Controlling RTP Media Source IP?
LSV
basteon at gmail.com
Wed Jan 27 23:22:49 CST 2021
pin
ср, 6 янв. 2021 г. в 1:02, Mark Murawski <markm-lists at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210128/4b549965/attachment.html>
More information about the asterisk-dev
mailing list