Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite
On 07.05.21 at 00:12 Michael Maier wrote: Hello Joshua, On 06.05.21 at 20:21 Joshua C. Colp wrote: On Wed, May 5, 2021 at 4:40 PM Michael Maier wrote: Hello! When running asterisk on a system holding WAN and local IP, the IP used for SDP in an outgoing call in the challenged INVITE is the local one instead of the WAN IP when using a NATed transport instead of a transport bound to the WAN IP. The SDP in the initial INVITE is absolutely correct. But the following Invite with the Auth header contains the wrong IP in SDP (the IP in the SIP Contact and Via header are correct). After digging in the code, I could see, that in session_outgoing_nat_hook (res_pjsip_session.c) the nat rewrite is stopped, because of an existing hook (I figured it out by some additional debug outputs): /* SDP produced by us directly will never be multipart */ if (!transport_state || hook || !tdata->msg->body || !ast_sip_is_content_type(&tdata->msg->body->content_type, "application", "sdp") || ast_strlen_zero(transport->external_media_address)) { return; } [...] The only thing that comes to mind is the code in res/res_pjsip/pjsip_message_filter.c that alters the SDP in some scenario to update it for the transport the message is going out on. True - there is a dedicated function checking for multihomed environments. Maybe this one changes back the IP (not tested though). Meanwhile I modified the above check for aborting the nat rewrite this way, that the check for an existing hook follows after the execution of the NAT rewrite. Now, it's working. Another question follows now, which is firewall related: At which point exactly starts asterisk to send outgoing RTP? Problem disappeared after restarting of asterisk. This happened quite often unfortunately, that restart solved strange behavior after doing reloads in consequence of doing changes in FreePBX - even if they are not transport related. The DNAT rules are needed anyway, but now it's possible to add a established INPUT rule, so things are working as expected. Finally I can say, that I got it working after applying two patches to correctly get NAT working on a multihomed server (including WAN IPv4): res/res_pjsip_nat.c @find_transport_state_in_use if (transport_state && ((details->transport && details->transport == transport_state->transport) || (details->factory && details->factory == transport_state->factory) || ((details->type == transport_state->type) && (transport_state->factory) && !pj_strcmp(&transport_state->factory->addr_name.host, &details->local_address) && - transport_state->factory->addr_name.port == details->local_port))) { + (transport_state->factory->addr_name.port == details->local_port || transport_state->factory->addr_name.port == 0 { return CMP_MATCH; } => This ensures, that transports used as client can be found, too if they can't be directly found. This patch solves the problem, that the ACK sent by asterisk after a received 407 during INVITE sequence gets the correct IP in the Via header. The second patch is needed to ensure, that the INVITE after the 407 containing the auth header gets the correct IP (= WAN) in the SDP: res/res_pjsip_session.c session_outgoing_nat_hook(pj /* SDP produced by us directly will never be multipart */ - if (!transport_state || hook || !tdata->msg->body || + if (!transport_state || !tdata->msg->body || !ast_sip_is_content_type(&tdata->msg->body->content_type, "application", "sdp") || ast_strlen_zero(transport->external_media_address)) { return; } Move the check for the hook after executing the NAT functionality: @@ -5492,6 +5512,12 @@ static void session_outgoing_nat_hook(pj } } + /* There is a hook - don't do it again */ + if (hook) { + ast_debug(5, "stop - hook\n"); + return; + } + for (stream = 0; stream < sdp->media_count; ++stream) { /* See if there are registered handlers for this media stream type */ char media[20]; If there are others having problems during NAT they may try those patches. I know of at least one provider which doesn't care about those errors, but there are others which care and therefore calls are failing. Some more information: It's important to add to *all* transports the following parameters: external_media_address=external.mydom.org external_signaling_address=external.mydom.org local_net=192.168.0.0/16 or whatever you need I enabled dnsmgr, which should take care of always correct WAN IP via periodic lookups of external.mydom.org. But not yet tested, if it finally works (if the WAN IP changed). That's finally the reason I'm trying to use NAT because this way I can bind a
Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite
On Thu, May 6, 2021 at 7:12 PM Michael Maier wrote: Another question follows now, which is firewall related: At which point > exactly starts asterisk to send outgoing RTP? > > Why am I asking? Given is an outbound call e.g. Portfilter opens > incoming port as soon as it has seen an outgoing packet. If there is no > outgoing RTP, the incoming RTP packages will be dropped because > portfilter doesn't know what to do with them (no conntrack information > there). > > After applying a DNAT-rule, things are working fine - but that's not a > good solution. > > Now I'm wondering why asterisk doesn't always start sending RTP after a > 200 OK sdp (or an any other arbitrary SDP) containing a=sendrecv and > correct media and dest port. > > Sometimes asterisk begins to send RTP not until it receives RTP from > Callee - though the Caller already sends RTP - therefore there is no > reason to not send anything. I'm quite puzzled. > > This behavior is 100% reproducible for certain numbers. > > > Do you by chance have any idea? > As soon as Asterisk has received media and the media has gotten past strict RTP protection, it should then forward that media outward to the target in the SDP. RTP debug and core debug shows when this is happening. -- 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
Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite
Hello Joshua, On 06.05.21 at 20:21 Joshua C. Colp wrote: > On Wed, May 5, 2021 at 4:40 PM Michael Maier wrote: > >> Hello! >> >> When running asterisk on a system holding WAN and local IP, the IP used >> for SDP in an outgoing call in the challenged INVITE is the local one >> instead of the WAN IP when using a NATed transport instead of a >> transport bound to the WAN IP. >> >> The SDP in the initial INVITE is absolutely correct. But the following >> Invite with the Auth header contains the wrong IP in SDP (the IP in the >> SIP Contact and Via header are correct). >> >> After digging in the code, I could see, that in >> session_outgoing_nat_hook (res_pjsip_session.c) the nat rewrite is >> stopped, because of an existing hook (I figured it out by some >> additional debug outputs): >> >> /* SDP produced by us directly will never be multipart */ >> if (!transport_state || hook || !tdata->msg->body || >> >> !ast_sip_is_content_type(&tdata->msg->body->content_type, "application", >> "sdp") || >> ast_strlen_zero(transport->external_media_address)) { >> return; >> } >> [...] > The only thing that comes to mind is the code in > res/res_pjsip/pjsip_message_filter.c that alters the SDP in some scenario > to update it for the transport the message is going out on. True - there is a dedicated function checking for multihomed environments. Maybe this one changes back the IP (not tested though). Meanwhile I modified the above check for aborting the nat rewrite this way, that the check for an existing hook follows after the execution of the NAT rewrite. Now, it's working. Another question follows now, which is firewall related: At which point exactly starts asterisk to send outgoing RTP? Why am I asking? Given is an outbound call e.g. Portfilter opens incoming port as soon as it has seen an outgoing packet. If there is no outgoing RTP, the incoming RTP packages will be dropped because portfilter doesn't know what to do with them (no conntrack information there). After applying a DNAT-rule, things are working fine - but that's not a good solution. Now I'm wondering why asterisk doesn't always start sending RTP after a 200 OK sdp (or an any other arbitrary SDP) containing a=sendrecv and correct media and dest port. Sometimes asterisk begins to send RTP not until it receives RTP from Callee - though the Caller already sends RTP - therefore there is no reason to not send anything. I'm quite puzzled. This behavior is 100% reproducible for certain numbers. Do you by chance have any idea? Thanks Michael -- _ -- 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
Re: [asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite
On Wed, May 5, 2021 at 4:40 PM Michael Maier wrote: > Hello! > > When running asterisk on a system holding WAN and local IP, the IP used > for SDP in an outgoing call in the challenged INVITE is the local one > instead of the WAN IP when using a NATed transport instead of a > transport bound to the WAN IP. > > The SDP in the initial INVITE is absolutely correct. But the following > Invite with the Auth header contains the wrong IP in SDP (the IP in the > SIP Contact and Via header are correct). > > After digging in the code, I could see, that in > session_outgoing_nat_hook (res_pjsip_session.c) the nat rewrite is > stopped, because of an existing hook (I figured it out by some > additional debug outputs): > > /* SDP produced by us directly will never be multipart */ > if (!transport_state || hook || !tdata->msg->body || > > !ast_sip_is_content_type(&tdata->msg->body->content_type, "application", > "sdp") || > ast_strlen_zero(transport->external_media_address)) { > return; > } > > The same behavior can be seen on the system which doesn't contain a > global IP - but the outgoing SDP IP is still correct here. > > I'm wondering now, why the IP in the first case is wrong and in the > second case ok? What changes the IP? I couldn't find any point in > Asterisk. I'm suspecting pjsip changes something under the hood? > > Would be glad if somebody could shed some light on this strange > behavior. Maybe an idea where to look at. > The only thing that comes to mind is the code in res/res_pjsip/pjsip_message_filter.c that alters the SDP in some scenario to update it for the transport the message is going out on. -- 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