----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4316/#review14223 -----------------------------------------------------------
/branches/13/channels/chan_pjsip.c <https://reviewboard.asterisk.org/r/4316/#comment24682> I think it may be useful to have AOR support here as well. /branches/13/include/asterisk/stasis_app.h <https://reviewboard.asterisk.org/r/4316/#comment24681> Everything else has doxygen. Why not this? /branches/13/res/res_pjsip_multihomed.c <https://reviewboard.asterisk.org/r/4316/#comment24683> There's no guarantee that the host will be NULL terminated. /branches/13/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4316/#comment24684> There's no guarantee that host will be NULL terminated. /branches/13/res/res_pjsip_transport_websocket.c <https://reviewboard.asterisk.org/r/4316/#comment24685> Etc. - Joshua Colp 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@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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
