05/05/2012
Call Detail Record (CDR) motoren i Asterisk er en fundamental komponent, der bruger Stasis Message Bus API'en til at opbygge registreringer for kanalerne. Efterhånden som en kanals tilstand og de broer, den deltager i, ændrer sig, sendes der notifikationer via Stasis Message Bus. CDR-motoren behandler disse notifikationer og skaber registreringer, der afspejler denne tilstand. I løbet af en kanals levetid kan der genereres mange CDR'er for eller involverende den pågældende kanal. Når en kanal ikke længere er til stede i Asterisk, afsluttes en kritisk del af denne proces, hvor alle CDR'er for kanalen sendes til registrering.

Denne artikel dykker ned i, hvordan Asterisk håndterer denne proces, specificerer CDR'ernes livscyklus, de forskellige tilstande de gennemgår, og hvordan komplekse opkaldsscenarier oversættes til detaljerede opkaldsregistreringer, der er afgørende for fakturering, analyse og systemovervågning.
Introduktion til Asterisk Call Detail Records (CDR)
En CDR (Call Detail Record) er en registrering af kommunikationen mellem en eller to parter. Som sådan adresserer en enkelt CDR altid kommunikationen mellem to parter: en Part A og en Part B. CDR'en afspejler opkaldets synsvinkel fra Part A's perspektiv, mens Part B er den part, som Part A kommunikerer med. Selvom CDR-systemet er enkelt og effektivt til hurtig implementering af faktureringssystemer, kan det have svært ved at udtrykke komplekse opkaldsscenarier. Med ændringerne i Asterisk 12 blev CDR-adfærden markant opgraderet for at håndtere mere avancerede situationer.
Det er vigtigt at bemærke, at Channel Event Logging (CEL) blev introduceret som et alternativ. I modsætning til CDR'er, hvor der produceres relativt få poster pr. opkald, giver CEL en sekvens af hændelser om kanalernes tilstand. CEL giver væsentligt mere information, hvilket gør det muligt at bygge skræddersyede og robuste faktureringssystemer. Dog er CDR'er stadig en central og velanvendt funktion.
CDR'ens Livscyklus: Fra Oprettelse til Afslutning
En CDR har en livscyklus, der er en delmængde af den kanal, den afspejler. En enkelt CDR for en kanal repræsenterer en kommunikationsvej. Når en kanal etablerer en ny kommunikationsvej, oprettes en ny CDR. Ligeledes, når en kommunikationsvej afbrydes, færdiggøres en CDR. Til sidst, når en kanal ikke længere er til stede i Asterisk, sendes alle CDR'er for den pågældende kanal til de registrerede CDR-backends for permanent lagring.
CDR'er gennemgår fundamentalt følgende tilstande:
- Single: En kanal udfører dialplan eller har ingen relation til andre kanaler. Dette er standardtilstanden.
- Dial: En kanal er involveret i en opkaldsoperation, enten som den, der ringer op, eller den, der bliver ringet op.
- Bridge: To eller flere kanaler deler en bro, hvor de potentielt kan tale sammen.
- Finalized: Forbindelsen er brudt. Den sidste tilstand af de involverede kanaler låses i CDR'en.
- Dispatched: CDR'en er blevet skrevet til backend-lagringen og fjernet fra hukommelsen.
Uddybning af CDR-tilstande
For at forstå, hvordan data fanges, er det vigtigt at kende de tilstande, en CDR kan være i, og hvordan den overgår mellem dem.
Single
Når en CDR oprettes, er den i 'Single'-tilstand. Den repræsenterer en kanal uden en Part B. En CDR kan være ubesvaret eller besvaret i denne tilstand. Overgange herfra sker, når kanalen begynder et opkald (til 'Dial'), går ind i en bro (til 'Bridge' eller 'Parked'), eller lægger på (til 'Finalized').
Dial
Denne tilstand repræsenterer et igangværende opkald. Part A kan enten være opkalderen eller den opkaldte part (hvis opkaldet er Originated). Under et parallelt opkald kan der oprettes flere CDR'er for Part A, én for hver part der ringes til. En CDR forlader 'Dial'-tilstanden, hvis opkaldet mislykkes ('Finalized'), besvares ('DialedPending'), eller går ind i en bro ('Bridge').
Bridge
Bridge-tilstanden repræsenterer en kommunikationsvej mellem Part A og en eller flere andre parter. Når en CDR går ind i denne tilstand, forsøger den at finde en Part B. Hvis den finder en, opdateres CDR'en. Hvis ikke, kan den midlertidigt blive færdiggjort. I en flerpartsbro oprettes nye CDR'er for hvert par af kanaler med CDR'ens Part A. Dette er grunden til, at en trevejs-samtale resulterer i tre CDR-poster.
Parked
Opkaldsparkering er teknisk set en anden type bro. Forskellen er, at i en normal bro viser man kommunikationsveje, mens deltagerne i parkering er uafhængige. En parkeret CDR ligner mere en dialplan-applikation, der er blevet eksekveret. Når en kanal forlader en parkeringsbro, overgår dens CDR til 'Finalized'-tilstanden.
Finalized
Når en CDR når 'Finalized'-tilstanden, er den færdig. Der kan ikke foretages yderligere opdateringer af partinformationen. Den eneste undtagelse er opdatering af linkedid under propagering. En færdiggjort CDR venter på at blive sendt til CDR-backends.

Centrale CDR-attributter og Felter
Selvom en CDR kan have mange attributter, har alle CDR'er to parter: en Party A (altid den kanal, der ejer CDR'en) og en valgfri Party B. De fleste attributter afspejler kanalens tilsvarende attributter på det tidspunkt, hvor CDR'en blev færdiggjort.
Standardfelter i en CDR
| Felt | Type | Beskrivelse |
|---|---|---|
| accountcode | String | En kontokode tilknyttet Party A-kanalen. |
| src | String | Opkalderens ID-nummer. |
| dst | String | Destinations-extension. |
| dcontext | String | Destinations-kontekst. |
| channel | String | Navnet på Party A-kanalen. |
| dstchannel | String | Navnet på Party B-kanalen. |
| lastapp | String | Den sidste applikation, Party A-kanalen udførte. |
| start | Dato/tid | Tidspunktet, hvor CDR'en blev oprettet. |
| answer | Dato/tid | Tidspunktet, hvor Party A blev besvaret. |
| end | Dato/tid | Tidspunktet, hvor CDR'en blev afsluttet. |
| duration | Integer | Tiden i sekunder fra 'start' til 'end'. |
| billsec | Integer | Tiden i sekunder fra 'answer' til 'end'. |
| disposition | Enum | Den endelige status for CDR'en (f.eks. ANSWERED, NO ANSWER, BUSY). |
| linkedid | String | Et unikt ID, der forener flere CDR-poster fra samme logiske opkald. |
| sequence | Integer | Et sekvensnummer, der unikt identificerer en CDR-post sammen med uniqueid og linkedid. |
CDR-eksempler i Forskellige Opkaldsscenarier
For at illustrere, hvordan CDR'er fungerer i praksis, er her nogle almindelige scenarier. Bemærk, at disse tabeller er forenklede for læsbarhed.
Grundlæggende to-parts opkald
Alice ringer til Asterisk, som ringer til Bob. Bob svarer. De taler, og så lægger Bob på.
| src | dst | channel | dstchannel | duration | billsec | disposition | linkedid |
|---|---|---|---|---|---|---|---|
| 100 | 200 | SIP/alice-000... | SIP/bob-000... | 120 | 112 | ANSWERED | ...276.2 |
Blind Transfer
Alice taler med Bob. Bob foretager en blind transfer af Alice til Charlie. Charlie svarer, de taler, og Alice lægger på. Dette skaber to separate CDR-poster, forbundet af 'linkedid'.
| src | dst | channel | dstchannel | duration | billsec | disposition | linkedid |
|---|---|---|---|---|---|---|---|
| 100 | 200 | SIP/alice-000... | SIP/bob-000... | 30 | 20 | ANSWERED | ...276.2 |
| 100 | 300 | SIP/alice-000... | SIP/charlie-000... | 65 | 60 | ANSWERED | ...276.2 |
Tre-vejs opkald
Alice taler med Bob. Bob starter et tre-vejs opkald og tilføjer Charlie. Alle tre taler sammen. Dette scenarie genererer flere CDR'er for at repræsentere hver kommunikationsvej (Alice-Bob, Bob-Charlie, Alice-Charlie).
| Party A | Party B | duration | billsec | disposition | linkedid |
|---|---|---|---|---|---|
| Alice | Bob | 120 | 110 | ANSWERED | ...276.2 |
| Bob | Charlie | 20 | 15 | ANSWERED | ...276.2 |
| Alice | Charlie | 70 | 70 | ANSWERED | ...276.2 |
| Bob | Charlie | 70 | 70 | ANSWERED | ...276.2 |
Ofte Stillede Spørgsmål (FAQ)
Hvad er den primære forskel mellem CDR og CEL i Asterisk?
CDR (Call Detail Record) producerer en eller få poster, der opsummerer et opkaldssegment, primært til faktureringsformål. CEL (Channel Event Logging) producerer en detaljeret strøm af mange små hændelser for en kanal (oprettelse, besvarelse, afslutning, transfer osv.), hvilket giver et meget mere detaljeret billede af opkaldets forløb.
Hvordan påvirker et opkald på hold (Call Hold) en CDR?
Call Hold er en ændring i mediestrømmen, ikke i bro-strukturen. Derfor afspejles det ikke i CDR'er. En CDR vil vise den samlede tid, to parter var i en bro, uanset om de var på hold i en del af tiden.
Hvorfor genereres der flere CDR'er for ét enkelt opkald?
Der genereres en ny CDR for hver unik kommunikationsvej. Ved en transfer, en konference eller et parallelopkald oprettes der nye veje mellem forskellige parter. Hver af disse veje får sin egen CDR. Feltet 'linkedid' bruges til at binde alle disse relaterede CDR'er sammen til ét logisk opkald.
Hvad sker der præcist, når en kanal forsvinder?
Når en kanal lægger på eller på anden måde forsvinder fra Asterisk, bliver alle CDR'er, hvor denne kanal er Party A, implicit færdiggjort ('Finalized'). Når alle CDR'er for en kanal er færdiggjort, sendes ('Dispatched') de samlet til de konfigurerede CDR-backends (f.eks. en CSV-fil eller en database) for permanent lagring. Herefter fjernes de fra Asterisks aktive hukommelse.
Hvis du vil læse andre artikler, der ligner Hvad sker der, når en Asterisk-kanal forsvinder?, kan du besøge kategorien Teknologi.
