<div class="gmail_quote">On Wed, May 20, 2009 at 11:33 AM, Atis Lezdins <span dir="ltr"><<a href="mailto:atis@iq-labs.net">atis@iq-labs.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">
</div></div>That's exactly how it was designed.<br>
<br>
There is going to be LinkedID soon (perhaps it's already merged in<br>
some 1.6.x branch), that will basically be uniqueid of first channel<br>
for a call. For now, You can just do<br>
<br>
if ("${call_id}"="") Set(__call_id=${UNIQUEID});<br>
<br>
</blockquote></div><br>LinkedID isn't really the same thing though, it serves a different purpose. Consider that what you said can't even be done (in the dialplan anyway) on a channel not in the dialplan. The LinkID is for figuring out which channel created which other channels. It doesn't uniquely identify a channel. But nothing does because even it's uniqueid can change.<br>
<br>Now there are some cases where it's sort of nice that the uniqueid doesn't change. Consider following queue events where an attended transfer completes after the join but before the connect. But if you were trying to track a certain channel by unqueid id, well the uniqueid changing is certainly going to cause you problems.<br>
<br>And Rename events don't do much to help really. Lets say you were logging certain events to a database. Image trying to do a sql join between two events based on their unqiueid, but they had multiple unqiue id's over the lifetime of the call, so you have to somehow factor in that it's uniqueid was X if the timestamp is between Y and Z, but it's A if the timestamp is because B and C.<br>