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

[opticron]

> On Nov. 10, 2014, 8:24 a.m., Joshua Colp wrote:
> > branches/12/res/res_pjsip_nat.c, line 230
> > <https://reviewboard.asterisk.org/r/4155/diff/1/?file=68767#file68767line230>
> >
> >     Just a question - is this already on the dialog? (Do you need to clone it?)
> 
> Joshua Colp wrote:
>     Or can you steal it like a thief.

The uri is allocated on the rdata and not on the dialog, so the clone is necessary.


- opticron


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


On Nov. 6, 2014, 9:49 a.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4155/
> -----------------------------------------------------------
> 
> (Updated Nov. 6, 2014, 9:49 a.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 425222 
> 
> 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/20141112/a5f5a931/attachment.html>