[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

Tue Jan 20 20:59:55 CST 2015

> On Jan. 20, 2015, 3:39 p.m., Mark Michelson wrote:
> > /branches/13/res/ari/resource_channels.c, lines 169-172
> > <https://reviewboard.asterisk.org/r/4316/diff/2/?file=70750#file70750line169>
> >
> >     Should this send an ARI response?

Nope! That's what I thought too. However, find_control, in its off nominal paths, already constructs the appropriate 404 or 409 error responses.

> On Jan. 20, 2015, 3:39 p.m., Mark Michelson wrote:
> > /branches/13/res/res_pjsip_multihomed.c, lines 149-150
> > <https://reviewboard.asterisk.org/r/4316/diff/2/?file=70752#file70752line149>
> >
> >     I think there are a couple of problems with this change:
> >     
> >     1) You may be trying to access a union member within tdata->msg->line that doesn't make sense here. tdata->msg could be a request or a response. If it is a request, then accessing tdata->msg->line.status is going to get you some goofy values.
> >     
> >     2) Adding an exception for 302 responses is not always going to be correct. If we are redirecting to another resource on the same Asterisk server, then we want to rewrite the contact to use the publicly addressable host and port. However, if we are redirecting to a "foreign" URI, then we don't want to rewrite the contact to point back to us.
> 
> Mark Michelson wrote:
>     Oh, forgot one more thing
>     
>     3) If you are going to apply an exception for a 302 response, the same should be done for all 300-class responses as well.
> 
> Mark Michelson wrote:
>     I've been thinking about this more, and you can scrap my finding number 2) here. If people want to "redirect" a device to a resource on the same Asterisk system, they can do that with a Goto in the dialplan, or with the /continue resource in ARI. So anytime you're using an ARI redirect, you should be redirecting to a non-local URI.

Phew. I was really hoping I wasn't going to have to try and figure out if the URI here was 'local' or 'remote'.

- Matt

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

On Jan. 19, 2015, 1:17 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> -----------------------------------------------------------
> 
> (Updated Jan. 19, 2015, 1:17 p.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 430794 
>   /branches/13/res/stasis/control.c 430794 
>   /branches/13/res/res_pjsip_transport_websocket.c 430794 
>   /branches/13/res/res_pjsip_nat.c 430794 
>   /branches/13/res/res_pjsip_multihomed.c 430794 
>   /branches/13/res/res_ari_channels.c 430794 
>   /branches/13/res/ari/resource_channels.c 430794 
>   /branches/13/res/ari/resource_channels.h 430794 
>   /branches/13/include/asterisk/stasis_app.h 430794 
>   /branches/13/channels/chan_pjsip.c 430794 
> 
> 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/20150121/1daf99b0/attachment-0001.html>