[asterisk-bugs] [JIRA] (ASTERISK-20904) RFC1918 NAT Issue On Prune

[JoshE (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201215#comment-201215 ] 

JoshE commented on ASTERISK-20904:
----------------------------------

That's correct.  The version of the patch I supplied did fix the problem in Asterisk 10.  The version committed to branches/trunk did not, due to the way !found actually processes.

With a change with what appears to be the deprecation of nat=yes, the force_rport check now doesn't work properly either.  The patch I supplied fixed the issue for me when the fullcontact is in the form of:

sip:134 at 192.168.0.216:5061

Not sure there isn't a better approach, but the supplied diff does resolve a two step issue - the zeroing out of the ipaddr field (which ensures that the fullcontact private address is used) and the force_rport check within that conditional.
                
> RFC1918 NAT Issue On Prune
> --------------------------
>
>                 Key: ASTERISK-20904
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20904
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>            Reporter: JoshE
>         Attachments: rfc1918_patch.diff
>
>
> Issue is related to 20572, but appears to have been reintroduced in Asterisk 11.x.
> Bring up a realtime peer behind separated from the Asterisk server behind NAT.   When the peer is pruned and brought back up, the peer's external NAT address is replaced with the private IP from the contact header, if that address was present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira