On Tue, Jan 5, 2021 at 11:02 AM Mark Murawski <markm-li...@intellasoft.net> wrote:
<snip> 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.... > In previous times it may have, but to support modern DNS methods with IPv4 and IPv6 by default it currently binds to the wildcard. This allows it to failover between IPv4 and IPv6 easily. The API could be better extended to potentially allow it to recreate the entire RTP instance for the transition but that hasn't been done and doesn't exist. > > 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 > <snip> > > > 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. > There is no such information in there. I don't recall when exactly the RTP instance is created, but you may be able to examine the INVITE session on the session and the dialog to get the underlying SIP URI that is being targeted or has been received from, and then from that try to determine the underlying transport that would be used to determine the IP address to bind RTP to. > > 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 > -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org
-- _____________________________________________________________________ -- 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
