[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

Mon Jan 19 13:16:48 CST 2015

> On Jan. 19, 2015, 10:25 a.m., Joshua Colp wrote:
> > /branches/13/include/asterisk/stasis_app.h, line 489
> > <https://reviewboard.asterisk.org/r/4316/diff/1/?file=70696#file70696line489>
> >
> >     Everything else has doxygen. Why not this?

Bad eyesight?

> On Jan. 19, 2015, 10:25 a.m., Joshua Colp wrote:
> > /branches/13/channels/chan_pjsip.c, lines 1394-1400
> > <https://reviewboard.asterisk.org/r/4316/diff/1/?file=70695#file70695line1394>
> >
> >     I think it may be useful to have AOR support here as well.

IRC conversation for posterity:

(01:00:16 PM) mjordan: file: Question! On r4316, when you refer to 'AoR support' - can you point me to a parsing example that does what you would like? I'm thinking that constructing a dial string isn't quite right, since it supports multiple contacts
(01:01:38 PM) file: mjordan, there isn't really one as everything else requires an endpoint
(01:07:25 PM) mjordan: file: Nuts.
(01:08:28 PM) file: mjordan, try to find endpoint, then AOR, then treat as URI?
(01:09:30 PM) mjordan: file: what would you have to specify to do that?
(01:09:35 PM) mjordan: PJSIP/foo/foo?
(01:09:58 PM) file: PJSIP/<endpoint>/<aor> is how a dial string works
(01:10:58 PM) mjordan: Hm.
(01:11:06 PM) mjordan: Except that you then would need a convenience dialplan function
(01:11:18 PM) mjordan: And how would you handle multiple contacts on an AoR in the redirect case?
(01:11:36 PM) file: use the first one, same as you are doing right now
(01:11:45 PM) file: or return all of them as Contacts and see what the endpoint does
(01:11:58 PM) file: HILARITY
(01:12:28 PM) mjordan: heh
(01:12:38 PM) mjordan: I guess I'm trying to see why specifying an AoR would be helpful
(01:13:04 PM) mjordan: What does specifying it buy us in this case, since (almost 99% likely) we only want to place one URI in the Contact header
(01:13:21 PM) mjordan: (And we can specify any arbitrary URI using PJSIP/sip:foo at foo.com)
(01:13:35 PM) file: we allow specifying an explicit AOR elsewhere when dialing so consistency - but if you don't want to I'm not going to fight it
(01:13:51 PM) mjordan: well, it's actually what I wanted initially
(01:14:05 PM) mjordan: I just couldn't see what it was buying me, since I could specify arbitrary URIs (unlike with dialing)
(01:14:11 PM) mjordan: which, unfortunately, makes sense
(01:14:22 PM) mjordan: as with dialing, I need to have codecs, and dialplan contexts, and SRTP, and stuff
(01:14:30 PM) mjordan: but in this case, we're just trying to slap a URI in a header on the way out the door
(01:14:57 PM) file: you could argue with the new PJSIP_AOR and PJSIP_CONTACT dialplan functions you don't need it at all
(01:15:00 PM) mjordan: I suppose if an endpoint had multiple AoRs it would make a difference, but I'm not sure we even look at it
(01:15:03 PM) mjordan: True
(01:15:25 PM) mjordan: shall we punt then?
(01:15:31 PM) file: SURE!

- Matt

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

On Jan. 18, 2015, 9:16 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4316/
> -----------------------------------------------------------
> 
> (Updated Jan. 18, 2015, 9:16 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 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/a39abb9a/attachment.html>