[asterisk-dev] Wrong IP-address in SDP when on NAT in challenged Invite

[Michael Maier]

Hello Joshua,

On 06.05.21 at 20:21 Joshua C. Colp wrote:
> On Wed, May 5, 2021 at 4:40 PM Michael Maier <m1278468 at mailbox.org> 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