[asterisk-dev] CDR uniqueid and unattended transfer

Steve Murphy murf at digium.com
Tue Oct 14 12:35:13 CDT 2008


On Tue, 2008-10-14 at 12:11 -0200, Daniel Ferrer wrote:
> Hi all,
> Based on the assumption that uniqueid is unique across a channel (I 
> cannot get 2 CDRs with same 'channel' and 'uniqueid' fields), I think 
> there's a bug in 1.4.22.
> 
> When doing an unnattended transfer (res_features.so), I get 2 cdr's with 
> same uniqueid and same channel name. Same but a little more complex 
> occurs using attended transfers. I think that it was introduced in rev 
> 142063.
> 
> Is this really a bug? What do you think? Should I open a bug in Mantis?
> 

I hope not. Unique ID in the CDR field is pretty useless; always has
been.
In some cases, it will stay the same in an xfer situation, in others, it
will not. The name alone has misled many folks, who thought it would
always
be unique (according to its name), and made it an index key into the
db... 

Name your exact scenarios; where you expect it to be the same, where
you 
expect it to be different. "Blind xfer" and "attended xfer" are not
specific
enough. Show exactly what buttons you hit on what tech of phone to
initiate
an xfer. With Zap, you can do xfers via flashhook, and also via the '#'
or
whatever features... it is important, the differences.

If you file a bug, I'll take a look at it. If I can, and if it used to
act that
way, I'll try to make it act that way again. But no guarantees. One bug
fix
begets 4 or 5 regressions, and sometimes, in the name of progress,
undocumented
relationships like this are bound to suffer.

You should be excited about CEL, and the stuff we did to help Brian
Degenhardt
in tracking call segments. In that branch, we intro a new CDR field, the
linkedID, which is viral between interacting channels, and *CAN* be used
to
track call legs across xfers.

Fixing the current CDR implementation is tiring and time consuming. Make
sure to thank Digium for funding this effort. I'll stop here.

murf



> bye
> daniel
> 
> Tilghman Lesher escribió:
> > On Thursday 04 September 2008 16:36:39 Daniel Ferrer wrote:
> >> I tested today 1.4.22-rc3, as I see it includes patch for issue #13409.
> >>
> >> This patch is causing me CDR problems, I use cdr_mysql (from addons
> >> package) as backend, and in a normal call A->B, this patch causes to
> >> post the CDR twice, giving me a constraint key violation (uniqueid is
> >> primary key in cdr table).
> > 
> > Well, that may be your first problem.  Uniqueid has never been guaranteed
> > to be unique across all CDRs.  It is only unique across a channel, and a
> > channel may have multiple CDRs.  You need to remove that primary key,
> > as its existence is based upon a faulty assumption.
> > 
> 
> 
-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20081014/1bad0a02/attachment.bin 


More information about the asterisk-dev mailing list