[asterisk-dev] [Code Review] 2466: Pimp my SIP: Call forwarding & diversion headers

Kevin Harwell reviewboard at asterisk.org
Fri Apr 26 13:48:17 CDT 2013



> On April 25, 2013, 3:41 p.m., Joshua Colp wrote:
> > /team/group/pimp_my_sip/include/asterisk/res_sip.h, lines 331-332
> > <https://reviewboard.asterisk.org/r/2466/diff/2/?file=36390#file36390line331>
> >
> >     chan_sip has an option called "promiscredir" which follows the explicit SIP URI and does not just go to the user portion within the dialplan. Is this something we want to do as well here? (albeit maybe not the same way)
> 
> Kevin Harwell wrote:
>     I can add this option...and a call to ast_channel_call_forward_build right?  Or is that what you meant by not the same way?
> 
> Joshua Colp wrote:
>     Yeah. The conundrum for supporting it is how to expose it to the dialplan. Right now in chan_sip if you have the option enabled it sends a call to SIP/<the URI, minus the sip: at the front> - This won't really work since it has no endpoint and using the dialed endpoint seems wrong. How about exposing the SIP URI via a dialplan variable and sending the call to an explicit extension?
>     
>     ie: If enabled all diverted calls go to the "diverted" extension and the user can then decide what to do with the SIP URI they have been diverted to.
>     
>     Thoughts?
> 
> Kevin Harwell wrote:
>     If I understand correctly do we even need a "promiscredir" option?  Of do we just want to have the dialplan variable always available with the SIP URI for every redirect?  Or would that option disallow redirection all together?
> 
> Joshua Colp wrote:
>     If you don't have the option then we'd go to the user portion of the URI in all cases, which means the user would then have to do a match all and direct it elsewhere using the URI. It also means you couldn't easily support a case with that and without that. I think having an option is best.
> 
> Kevin Harwell wrote:
>     So I started to implement this and there does not seem to be a way to access the set dialplan variable on the new outgoing channel.  Is there something I am missing?  Is it possible to do this at redirection time?
> 
> Joshua Colp wrote:
>     Sadly you appear to be correct, and thus I am sad. May just have to produce a Gulp/ dial line using the same endpoint for now...
>     
>     Gulp/<endpoint name>/<URI>

Implementation of the "promiscredir" feature is going to be put in its own task.


- Kevin


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


On April 24, 2013, 8:09 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2466/
> -----------------------------------------------------------
> 
> (Updated April 24, 2013, 8:09 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21426
>     https://issues.asterisk.org/jira/browse/ASTERISK-21426
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Adds call forwarding support (Josh's patch) to the new SIP work being done in Asterisk.  This also includes the ability to add a diversion header to an outgoing response/request when appropriate.  The diversion header feature can be turned off by setting the send_diversion=false (defaults to true) on an endpoint within the configuration file.
> 
> 
> Diffs
> -----
> 
>   /team/group/pimp_my_sip/channels/chan_gulp.c 386451 
>   /team/group/pimp_my_sip/include/asterisk/res_sip.h 386451 
>   /team/group/pimp_my_sip/res/res_sip.c 386451 
>   /team/group/pimp_my_sip/res/res_sip/sip_configuration.c 386451 
>   /team/group/pimp_my_sip/res/res_sip_diversion.c PRE-CREATION 
>   /team/group/pimp_my_sip/res/res_sip_session.c 386451 
> 
> Diff: https://reviewboard.asterisk.org/r/2466/diff/
> 
> 
> Testing
> -------
> 
> Wrote a few testsuite tests to make sure calls are being forwarded and the diversion header is added/propagated appropriately.
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130426/910b6b87/attachment-0001.htm>


More information about the asterisk-dev mailing list