[asterisk-dev] [Code Review] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports

Joshua Colp reviewboard at asterisk.org
Thu Nov 13 11:31:57 CST 2014


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



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

    Is there a potential race condition here between transport termination and dialog termination where either may point to invalid memory?


- Joshua Colp


On Nov. 13, 2014, 4:53 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4155/
> -----------------------------------------------------------
> 
> (Updated Nov. 13, 2014, 4:53 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24486
>     https://issues.asterisk.org/jira/browse/ASTERISK-24486
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This modifies contact rewriting to revert to the original contact URI for a dialog when persistent transports shut down.
> 
> Some calls can enter a condition where their contact URI from the initial incoming invite was rewritten for a reliable transport, but that transport has been shut down due to inactivity. Such reliable transports can not be re-established since the remote host was never listening on the associated port. In cases such as these, it is useful to be able to fall back to the original contact URI since it might be accessible and allow the call to continue normally.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/res_pjsip_nat.c 427735 
> 
> Diff: https://reviewboard.asterisk.org/r/4155/diff/
> 
> 
> Testing
> -------
> 
> Verified that this allowed the call to operate normally despite the original reliable connection being torn down where this situation was experienced.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141113/6a24d343/attachment-0001.html>


More information about the asterisk-dev mailing list