Incorrect LinkedID

Hi there,

We are having an issue in CDR that says a warm transfer does not contain the correct LinkedID on the second leg. Scenario looks like:

Caller dials agent1
Agent1 warm-transfers the call to Agent2
Agent2 speaks to the caller and then hangs up

We get 2 CDR entries as expected, however the second CDR has its own LinkedID which makes them difficult to tie together - in fact the only way we know a transfer has taken place is that the accountcode and userfield are present on the second CDR entry and are no longer on the first.

CEL shows the correct LinkedID throughout and so far is the only way to tie this together, however I am concerned that the LinkedID on the second leg is incorrect in CDR. Does anyone have any experience of this?

We are using cdr_adaptive_odbc to determine the fieldnames and do not have any Aliases configured in cdr_adaptive_odbc.conf that would be throwing this off, so Asterisk should be writing what it believes to be the LinkedID for the call to the cdrs.

Is there something I’m missing here?

With transfers, it is always important to indicate how they were initiated. E.g. the enquiry leg of a SIP attended transfer, is indistinguishable from a new outgoing call until the transfer actually takes place.

Also, I’ve not come across the term warm-transfer before. Asterisk uses the terms blind and attended. Some of the comments also use the term semi-attended, or “blond”, to refer to an attended transfer that is completed before the called party has answers. (Some SIP phones actually implement blind ones in the last mentioned way.)

Hi David55, thanks for your response

I use warm-transfer to refer to an attended transfer - I’ve heard of a cold-transfer being used to refer to an unattended transfer, I wonder if this is a UK colloquialism?

What you are saying regarding this being a new call does make sense however - I understand Asterisk will allow an attended transfer using hashcodes within a call, I will look into this and see if it resolves our problem.

Thanks again!