[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

[Matt Jordan]

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

(Updated Jan. 20, 2015, 9:39 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
-------

Addressed Mark's findings:
1) We now make sure it is a SIP response before checking the status code
2) We now ignore all 3xx responses in the multihomed module

Tests still pass, including the multihomed tests added recently.


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 (updated)
-----

  /branches/13/rest-api/api-docs/channels.json 430839 
  /branches/13/res/stasis/control.c 430839 
  /branches/13/res/res_pjsip_transport_websocket.c 430839 
  /branches/13/res/res_pjsip_nat.c 430839 
  /branches/13/res/res_pjsip_multihomed.c 430839 
  /branches/13/res/res_ari_channels.c 430839 
  /branches/13/res/ari/resource_channels.c 430839 
  /branches/13/res/ari/resource_channels.h 430839 
  /branches/13/include/asterisk/stasis_app.h 430839 
  /branches/13/channels/chan_pjsip.c 430839 

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/b3cc3a20/attachment.html>