<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/1985/">https://reviewboard.asterisk.org/r/1985/</a>
</td>
</tr>
</table>
<br />
<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, Terry Wilson, Tilghman Lesher, and rmudgett.</div>
<div>By Matt Jordan.</div>
<p style="color: grey;"><i>Updated June 14, 2012, 3:24 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Changes</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;">So after some more thought, I addressed rmudgett's finding by checking that both the p->owner and p->chan->_bridge cdr pointers are non-null before doing the swapping. It'd be an incredibly rare event for either to be NULL, but there's no point in risking it.
Additionally, this now destroys the variables on p->chan->_bridge before copying over p->owner's variables. While it may be conceivable that someone would want p->chan->_bridge's variables to be preserved, this runs into two difficulties:
1) Its pretty difficult to set the CDR variables as it is on the chan->_bridge channel (which is why this stuff is getting set on the Local channel (p->owner) in the first place)
2) This keeps the semantics of "user defined stuff on the Local channel is kept; user defined stuff on the channel masquerading into the Local channel is not", as opposed to a 'merge' type operation
In testing this kept the other CDR fields intact, as desired:
"","1","2","default","1","SIP/phone_b-00000000","SIP/phone_a-00000001","Dial","SIP/phone_a","2012-06-14 20:15:09","2012-06-14 20:15:11","2012-06-14 20:15:13",4,2,"ANSWERED","DOCUMENTATION","1339704907.2","foo"
In the above example, userfield 'foo' was set on the Local channel, while phone_b-00000000 masqueraded into the Local channel.</pre>
</td>
</tr>
</table>
<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;">This patch preserves CDR information that was set on a Local channel before it is masqueraded into by another channel. This includes accountcode, peeraccount, userfield, amaflags, and any variables that were set.
Consider a scenario in which a Local channel bridges two SIP channels (possibly the result of a channel originate Local/foo@default extension bar@default). This would look something like the following:
SIP/A <--> Local;1 <> Local;2 <--> SIP/B
In this scenario, currently, the only opportunity for setting CDR information on the resulting call occurs on the Local channels - both SIP channels are created as the result of outbound calls. As a result, it is desirable to have the CDR information that was set on the Local channel, i.e., Local;2, persist through the masquerade. At the same time, most of the CDR information, e.g., caller ID information, channel information, etc., should be swapped with the channel being masqueraded away.
This patch does this by copying over the information in local_fixup - this is only an improvement that should be done with respect to local channels. This should prevent impacting other masquerade operations (such as on SIP transfers).</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;">Tested the following scenario:
exten => 100,1,NoOp()
same => n,Set(CDR(userfield)=foo)
same => n,Dial(SIP/A)
exten => 101,1,NoOp()
same => n,Set(CDR(userfield)=bar)
same => n,Dial(SIP/B)
Performing "channel originate Local/100@default extension 101@default" prior to the patch would produce the following CDR record:
"","","100","default","","Local/100@default-5160,2","SIP/A-00000000","Dial","SIP/A","2012-06-11 19:10:40","2012-06-11 19:10:42","2012-06-11 19:10:42",2,0,"ANSWERED","DOCUMENTATION","1339441840.1","foo"
"","100","101","default","100","SIP/A-00000000","SIP/B-00000001","Dial","SIP/B","2012-06-11 19:10:42","2012-06-11 19:10:43","2012-06-11 19:10:45",3,2,"ANSWERED","DOCUMENTATION","1339441840.2",""
Performing the same post patch produces the following CDR:
"","","100","default","","Local/100@default-5160,2","SIP/A-00000000","Dial","SIP/A","2012-06-11 19:10:40","2012-06-11 19:10:42","2012-06-11 19:10:42",2,0,"ANSWERED","DOCUMENTATION","1339441840.1","foo"
"","100","101","default","100","SIP/A-00000000","SIP/B-00000001","Dial","SIP/B","2012-06-11 19:10:42","2012-06-11 19:10:43","2012-06-11 19:10:45",3,2,"ANSWERED","DOCUMENTATION","1339441840.2","bar"</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> (updated)</h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/channels/chan_local.c <span style="color: grey">(368965)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1985/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>