> 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:[email protected]) (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@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
