<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1229/">https://reviewboard.asterisk.org/r/1229/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On November 5th, 2011, 4:03 p.m., <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Does this new b() option run on all forked channels: Dial(SIP/abc&SIP/def,,b(predial,n,1))?</pre>
</blockquote>
<p>On November 6th, 2011, 10:15 p.m., <b>kobaz</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yeap. It does.
The code for the b option is done in the loop that goes through the newly created channels.
In this part:
/* loop through the list of dial destinations */
2143 rest = args.peers;
2144 while ((cur = strsep(&rest, "&")) ) {
2145 struct chanlist *tmp;</pre>
</blockquote>
<p>On November 6th, 2011, 10:34 p.m., <b>kobaz</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I did notice my xml documentation is wrong, I have the docs on the options flipped. So, 'b' is on the callee side and 'B' is the caller side
SIP/foo is calling SIP/bar
SIP/foo is the caller,
SIP/bar is the callee,
SIP/baz is another callee,
example 1:
<SIP/foo-123> Dial(SIP/bar,,B(predial,s,1))
<SIP/foo-123> Executing predial,s,1
<SIP/foo-123> calling SIP/bar-124
example 2:
<SIP/foo-123> Dial(SIP/bar,,b(predial,s,1))
<SIP/bar-124> Executing predial,s,1
<SIP/foo-123> calling SIP/bar-124
example 3:
<SIP/foo-123> Dial(SIP/bar&SIP/baz,,b(predial,s,1))
<SIP/bar-124> Executing predial,s,1
<SIP/baz-125> Executing predial,s,1
<SIP/foo-123> calling SIP/bar-124
<SIP/foo-123> calling SIP/baz-125
</pre>
</blockquote>
<p>On February 20th, 2012, 9:07 a.m., <b>schmidts</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">i have found this review by searching for a possibility to set different sip headers for different forked channels and this might be a solution. But by thinking of this i see a major problem which could happen here. If the gosub which is called before the dial tooks too long it might happen that one channel is allready ringing while the other one is still in the gosub and when the ringing one is answered you have a deadlock problem cause chan is locked during the gosub.
i dont know if there is a big chance that this might happen but imho it could be possible.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Have you run into this deadlock or is this just based on looking at the code? I would be interested in a dialplan example, but I'll try to create that and test that situation.</pre>
<br />
<p>- kobaz</p>
<br />
<p>On November 5th, 2011, 10:22 a.m., kobaz wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By kobaz.</div>
<p style="color: grey;"><i>Updated Nov. 5, 2011, 10:22 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>trunk/apps/app_dial.c <span style="color: grey">(343488)</span></li>
<li>trunk/include/asterisk/pbx.h <span style="color: grey">(343488)</span></li>
<li>trunk/main/pbx.c <span style="color: grey">(343488)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1229/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>