[asterisk-dev] [Code Review] 4316: ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis dialplan application to another system; improve and fix PJSIP's transfer ability

[Mark Michelson]

> On Jan. 19, 2015, 4:25 p.m., Joshua Colp wrote:
> > /branches/13/res/res_pjsip_multihomed.c, line 155
> > <https://reviewboard.asterisk.org/r/4316/diff/1/?file=70700#file70700line155>
> >
> >     There's no guarantee that the host will be NULL terminated.

If you're looking for how we typically go about printing pj_str_t, you can find examples in res_pjsip.c. Taking a quick look, there are two examples in register_service_noref().


- Mark


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


On Jan. 19, 2015, 3:16 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> -----------------------------------------------------------
> 
> (Updated Jan. 19, 2015, 3:16 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24015 and ASTERISK-24703
>     https://issues.asterisk.org/jira/browse/ASTERISK-24015
>     https://issues.asterisk.org/jira/browse/ASTERISK-24703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch adds a new feature to ARI to redirect a channel to another server, and fixes a few bugs in PJSIP's handling of the Transfer dialplan application/ARI redirect capability.
> 
> *New Feature*
> A new operation has been added to the ARI channels resource, redirect. With this, a channel in a Stasis application can be redirected to another endpoint of the same underlying channel technology.
> 
> - Preemptive question: why 'redirect', and not 'transfer'? Mostly because 'transfer' was always kind of a bad name. If the channel isn't answered, we aren't transferring, we're forwarding. If it is answered, the type of transfer being performed is somewhat vague - is it blind? Is it attended? 'redirect' - while also a slightly loaded term - is a bit more generic and yet descriptive of what is happening: we're redirecting the channel to somewhere else. Answered, not answered, it doesn't matter: your channel is no good here!
> 
> *Bug fixes*
> In the process of writing this new feature, two bugs were fixed in the PJSIP stack:
> (1) The existing .transfer channel callback had the limitation that it could only transfer channels to a SIP URI, i.e., you had to pass 'PJSIP/sip:foo at my_provider.com' to the dialplan application. While this is still supported, it is somewhat unintuitive - particularly in a world full of endpoints. As such, we now also support specifying the PJSIP endpoint to transfer to.
> (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by updating its Contact header. Alas, that resulted in the forwarding destination set by the dialplan application/ARI resource/whatever being rewritten with very incorrect information. Hence, we now don't bother updating an outgoing response if it is a 302. Since this took a looong time to find, some additional debug statements have been added to those modules that update the Contact headers.
> 
> 
> Diffs
> -----
> 
>   /branches/13/rest-api/api-docs/channels.json 430751 
>   /branches/13/res/stasis/control.c 430751 
>   /branches/13/res/res_pjsip_transport_websocket.c 430751 
>   /branches/13/res/res_pjsip_nat.c 430751 
>   /branches/13/res/res_pjsip_multihomed.c 430751 
>   /branches/13/res/res_ari_channels.c 430751 
>   /branches/13/res/ari/resource_channels.c 430751 
>   /branches/13/res/ari/resource_channels.h 430751 
>   /branches/13/include/asterisk/stasis_app.h 430751 
>   /branches/13/channels/chan_pjsip.c 430751 
> 
> Diff: https://reviewboard.asterisk.org/r/4316/diff/
> 
> 
> Testing
> -------
> 
> Tests were written both for the PJSIP stack as well as the new ARI operation. See https://reviewboard.asterisk.org/r/4352.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

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