[asterisk-dev] [Code Review] PreDial - Ability to run dialplan on callee channel and caller channel right before actual Dial

[rmudgett]

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


Please indicate the ASTERISK issue in the bugs field for this review and https://reviewboard.asterisk.org/r/1230/

- rmudgett


On March 15, 2012, 12:49 p.m., kobaz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1229/
> -----------------------------------------------------------
> 
> (Updated March 15, 2012, 12:49 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> PreDial
>   
>   Say SIP/abc is calling SIP/def
>   You have: Dial(SIP/def)
>   SIP/def-123234 is created.  But how can you tell that from dialplan?
> 
>   You can use a pickup macro: M or U options to Dial(), but you have to wait till pickup to know.
>   'PreDial' new option 'b' to Dial(), will let you run dialplan on the newly created channel before it is connected to the end-device.
> 
>   New way:
>   Dial(SIP/def,,b(predial,s,1))
>   Dialplan will run on SIP/def-123234 and allow you to know right away what channel will be used, and you can set specific variables on that channel.
> 
> You can also run dialplan on the caller channel (option 'B') right before the dial, which is a great place to do a last microsecond UNLOCK to ensure good channel behavior.
> Example:  LOCK(foo)
>           do stuff
>           UNLOCK(foo)
>           Dial(SIP/abc)
> 
> With this above example, say SIP/123 and SIP/234 are running this dialplan.
> 
> SIP/123 locks foo
> SIP/123 unlocks foo
> due to some cpu load issue, SIP/123 takes its time getting to Dial(SIP/abc) and doesn't do it right away
> 
> Meanwhile... SIP/234 zips right by, lock 'foo' is already unlocked, it grabs the lock, does its thing and it gets to Dial(SIP/abc).  SIP/123 wakes up and finally gets to the Dial().  Now you have two channels dialing SIP/abc when there was supposed to be one.
> 
> If your intention is to ensure that Dial(SIP/abc) is only done one at a time, you may have unexpected behavior lurking.
> 
> New way:
>   LOCK(foo)
>   do stuff
>   Dial(SIP/abc,,B(unlock,s,1))
> 
> context unlock {
>   s => {
>     UNLOCK(foo);
>   }
> }
> 
> Now, under no circumstances can this dialplan be run through and execute the Dial unless lock 'foo' is released.
> 
> Obviously this doesn't ensure that you're not calling SIP/abc more than once (you would need more dialplan logic for that), but it will allow a dialplan coder to also put the Dial in the locked section to ensure tighter control.
> 
> 
> Diffs
> -----
> 
>   trunk/apps/app_dial.c 359606 
>   trunk/include/asterisk/pbx.h 359606 
>   trunk/main/pbx.c 359606 
> 
> Diff: https://reviewboard.asterisk.org/r/1229/diff
> 
> 
> Testing
> -------
> 
> context predial {
>   s => {
>     NoOp(I'm Here!);
>   }
> }
> 
>  Dial(SIP/def,,I(predial,s,1))
>    run predial on callee channel
> 
>  Dial(SIP/def&SIP/ghi&SIP/qrx,,I(predial,s,1))
>   runs predial on all three callee channels
> 
>  Dial(SIP/def,,B(predial,s,1))
>    runs predial on caller channel
> 
>  Dial(SIP/def,,B(predial,s,1)I(predial,s,1))
>    runs predial on callee channel and caller channel
> 
> 
> Thanks,
> 
> kobaz
> 
>

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