[asterisk-dev] [Code Review] 3168: PJSIP: Correct address to which ACK is sent in NAT situations

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3168/#review10721
-----------------------------------------------------------



branches/12/res/res_pjsip_nat.c
<https://reviewboard.asterisk.org/r/3168/#comment20216>

    You can't do this. Well, I mean, you can, it just won't persist. The contact here is from the rdata pool and will end up getting reset later or just get deallocated. You need to clone it using pjsip_hdr_clone from the dialog pool. 


- Joshua Colp


On Jan. 30, 2014, 7:59 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3168/
> -----------------------------------------------------------
> 
> (Updated Jan. 30, 2014, 7:59 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23106
>     https://issues.asterisk.org/jira/browse/ASTERISK-23106
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> In NAT scenarios where a call is placed to a Grandstream phone, res_pjsip will sometimes send the ACK to a 200 OK to the private address of the device behind the NAT instead of the address of the NAT device. This corrects that behavior by rewriting the address in the Contact header in the incoming 200 OK and the dialog's target address if necessary (since it has already been rewritten to the incorrect private address).
> 
> 
> Diffs
> -----
> 
>   branches/12/res/res_pjsip_nat.c 406916 
> 
> Diff: https://reviewboard.asterisk.org/r/3168/diff/
> 
> 
> Testing
> -------
> 
> Manual testing and a new testsuite test at https://reviewboard.asterisk.org/r/3169/
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140130/53200fbc/attachment.html>