Tweet
Khi Cisco Unified Communications Manager gửi hoặc nhận cuộc gọi, hệ thống sẽ phát sinh một bản ghi CDR record khi cuộc gọi call kết thúc. Hệ thống system sẽ tiến hành ghi thông tin CDR vào flat file (text file).CUCM có 2 loại “record” cho lưu trữ lịch sử cuộc gọi (Call History) và các thông tin phân tích cuộc gọi (Diagnostic Information):
CDR(Call Detail Records) chứa thông tin Call Origination, Call Destination, Date & Time mà cuộc gọi call bắt đầu cuộc gọi, thời gian kết nối cuộc gọi (Time Connected), và thời gian kết thúc cuộc gọi (Time Ended). Cuộc gọi call được xem là bắt đầu (Started hoặc Originated) khi caller ở trạng thái Off-Hook. Cuộc gọi call được coi như là kết thúc khi Caller hoặc Called Party rơi vào trạng thái On-Hook.
CMR(Call Management Records) chứa thông tin về khối lượng dữ liệu đã gửi và nhận (Sent & Received), Jitter, Latency, và Lost Packets.
.
CallManager Services: thường được kích hoạt trên tất cả các node của cluster, CallManager đóng vai trò xử lý cuộc gọi (Call Processing) và ghi chú lại thông tin CDR, CMR data thành các flat file. Các file sẽ được tạo ra định kỳ theo khoảng thời gian thiết lập trong tham số “CDR File Time Interval” bên dưới “Enterprise Parameters”.
CDR Agent: đóng vai trò như một “network service” trên mỗi node của cluster, bao gồm cả Publisher. CDR Agent sẽ tiến hành lấy thông tin CDR, CMR flat file từ “Local Directory” định kỳ 6 giây một lần. Nếu tìm thấy các CDR, CMR flat files mới, nó sẽ đẩy CDR, CMR flat files từ node lên CDR Repository Node (Publisher). Sau khi gửi file thành công, hệ thống system sẽ tiến hành xóa các bản “local copy” của file đi.
CDR Repository Manager: hoạt động như một Network Service trên tất cả các nodes của một cluster. Tuy nhiên, trên thực tế thì chỉ có “CDR Repository Manager” trên Publisher là thực sự giữ vai trò chủ đạo, còn lại trên tất cả các nodes còn lại thì service được khởi động “starts up” nhưng lại ở trạng thái “sleep”. Service góp phần hình thành nên kiến trúc của “directory structure” được sử dụng bởi CAR services. Service cũng đứng ra quản lý các “flat file” nhận từ tất cả các node. CDR Repository Manager có thể lưu trữ các CDR file trong vòng 30 ngày trước khi xóa chúng hoặc có thể gửi các file này tới các “Billing Server”. CDR Repository Manager service trên CUCM (Publish) có thể gửi CDR files tới tối đa 3 Billing Servers thông qua FTP/SFTP.
CAR Scheduler: đóng vai trò như một Network Service trên tất cả các nodes của một cluster. Nhưng chỉ có CAR Scheduler service chạy trên Publisher là thực sự hoạt động còn trên tất cả các nodes còn lại thì service được khởi động “starts up” nhưng lại ở trạng thái “sleep”. Tùy vào thiết lập “CDR Loading Schedule”, CAR Scheduler tiến hành truy xuất tới các CDR/CMR files trong cấu trúc “directory structure” mà CDR Repository Manager service khởi tạo, các files sẽ được xử lý và thông tin CDR information sẽ được chèn vào CAR Database. Kích thước mặc định của “CAR Database” vào khoảng 6 Gb. CAR Scheduler sẽ tiến hành dọn dẹp “CAR Database” nếu kích thước vượt quá 6 Gb hoặc số lượng record vượt quá.
CAR Web Service: chỉ có thể được kích hoạt trên Publisher đóng vai trò như một feature service (Control Center – Feature Services). Ta cần kích hoạt dịch vụ “CAR Web Service” để có thể truy cập công cụ CDR Analysis & Reporting (CAR) tool.
SOAP - CDRonDemand Service: CDRonDemand Service là một SOAP/HTTPS-based service chạy trên CDR Repository node (Publisher). CDRonDemand Service sẽ lắng nghe các thông điệp SOAP request yêu cầu danh sách các CDR file name list từ “third-party server” định kỳ theo tham số user-specified time interval (tối đa lên tới 1 giờ). CDR onDemand Service cũng có thể xử lý các yêu cầu (Requests) phân phối các CDR file nhất định tới đích thông qua (s)FTP. Hệ thống system có thể kích hoạt (Activate) dịch vụ CDR onDemand service trên CDR Repository node có khả năng truy cập tới các CDR Files trong Repository.
Billing Servers: Hệ thống system có thể gửi các CDR files tới tối đa 3 “Billing Servers” thông qua giao thức FTP/SFTP. CDR Repository Manager trên Publisher chịu trách nhiệm transfer các CDR files tới billing servers. Cisco khuyến nghị sử dụng SFTP server được chứng nhận bởi Cisco Technology Developer Partner Program (CTDP) chẳng hạn như GlobalSCAPE, đã được chứng nhận là có thể tương tác tốt với các phiên bản version của Cisco Unified Communications Manager.
Service Interaction
Giả sử hệ thống có 2 servers trên cluster (một Publisher và một Subscriber). CallManager service chỉ được kích hoạt trên Subscriber. Các CDR, CMR files được quản lý như sau:
- CDR (Call Detail Records): Các “Data Record” chứa thông tin của từng cuộc gọi call được xử lý bởi CallManager.
- CMR (Call Management records): Các “Data Record” chứa thông tin QoS hoặc thông tin phân tích cuộc gọi (Diagnostic Information) còn được gọi là “Diagnostic Records”.
CDR(Call Detail Records) chứa thông tin Call Origination, Call Destination, Date & Time mà cuộc gọi call bắt đầu cuộc gọi, thời gian kết nối cuộc gọi (Time Connected), và thời gian kết thúc cuộc gọi (Time Ended). Cuộc gọi call được xem là bắt đầu (Started hoặc Originated) khi caller ở trạng thái Off-Hook. Cuộc gọi call được coi như là kết thúc khi Caller hoặc Called Party rơi vào trạng thái On-Hook.
CMR(Call Management Records) chứa thông tin về khối lượng dữ liệu đã gửi và nhận (Sent & Received), Jitter, Latency, và Lost Packets.
.
CallManager Services: thường được kích hoạt trên tất cả các node của cluster, CallManager đóng vai trò xử lý cuộc gọi (Call Processing) và ghi chú lại thông tin CDR, CMR data thành các flat file. Các file sẽ được tạo ra định kỳ theo khoảng thời gian thiết lập trong tham số “CDR File Time Interval” bên dưới “Enterprise Parameters”.
CDR Agent: đóng vai trò như một “network service” trên mỗi node của cluster, bao gồm cả Publisher. CDR Agent sẽ tiến hành lấy thông tin CDR, CMR flat file từ “Local Directory” định kỳ 6 giây một lần. Nếu tìm thấy các CDR, CMR flat files mới, nó sẽ đẩy CDR, CMR flat files từ node lên CDR Repository Node (Publisher). Sau khi gửi file thành công, hệ thống system sẽ tiến hành xóa các bản “local copy” của file đi.
CDR Repository Manager: hoạt động như một Network Service trên tất cả các nodes của một cluster. Tuy nhiên, trên thực tế thì chỉ có “CDR Repository Manager” trên Publisher là thực sự giữ vai trò chủ đạo, còn lại trên tất cả các nodes còn lại thì service được khởi động “starts up” nhưng lại ở trạng thái “sleep”. Service góp phần hình thành nên kiến trúc của “directory structure” được sử dụng bởi CAR services. Service cũng đứng ra quản lý các “flat file” nhận từ tất cả các node. CDR Repository Manager có thể lưu trữ các CDR file trong vòng 30 ngày trước khi xóa chúng hoặc có thể gửi các file này tới các “Billing Server”. CDR Repository Manager service trên CUCM (Publish) có thể gửi CDR files tới tối đa 3 Billing Servers thông qua FTP/SFTP.
CAR Scheduler: đóng vai trò như một Network Service trên tất cả các nodes của một cluster. Nhưng chỉ có CAR Scheduler service chạy trên Publisher là thực sự hoạt động còn trên tất cả các nodes còn lại thì service được khởi động “starts up” nhưng lại ở trạng thái “sleep”. Tùy vào thiết lập “CDR Loading Schedule”, CAR Scheduler tiến hành truy xuất tới các CDR/CMR files trong cấu trúc “directory structure” mà CDR Repository Manager service khởi tạo, các files sẽ được xử lý và thông tin CDR information sẽ được chèn vào CAR Database. Kích thước mặc định của “CAR Database” vào khoảng 6 Gb. CAR Scheduler sẽ tiến hành dọn dẹp “CAR Database” nếu kích thước vượt quá 6 Gb hoặc số lượng record vượt quá.
CAR Web Service: chỉ có thể được kích hoạt trên Publisher đóng vai trò như một feature service (Control Center – Feature Services). Ta cần kích hoạt dịch vụ “CAR Web Service” để có thể truy cập công cụ CDR Analysis & Reporting (CAR) tool.
SOAP - CDRonDemand Service: CDRonDemand Service là một SOAP/HTTPS-based service chạy trên CDR Repository node (Publisher). CDRonDemand Service sẽ lắng nghe các thông điệp SOAP request yêu cầu danh sách các CDR file name list từ “third-party server” định kỳ theo tham số user-specified time interval (tối đa lên tới 1 giờ). CDR onDemand Service cũng có thể xử lý các yêu cầu (Requests) phân phối các CDR file nhất định tới đích thông qua (s)FTP. Hệ thống system có thể kích hoạt (Activate) dịch vụ CDR onDemand service trên CDR Repository node có khả năng truy cập tới các CDR Files trong Repository.
Billing Servers: Hệ thống system có thể gửi các CDR files tới tối đa 3 “Billing Servers” thông qua giao thức FTP/SFTP. CDR Repository Manager trên Publisher chịu trách nhiệm transfer các CDR files tới billing servers. Cisco khuyến nghị sử dụng SFTP server được chứng nhận bởi Cisco Technology Developer Partner Program (CTDP) chẳng hạn như GlobalSCAPE, đã được chứng nhận là có thể tương tác tốt với các phiên bản version của Cisco Unified Communications Manager.
Service Interaction
Giả sử hệ thống có 2 servers trên cluster (một Publisher và một Subscriber). CallManager service chỉ được kích hoạt trên Subscriber. Các CDR, CMR files được quản lý như sau:
- CallManager Service trên Subscriber tiến hành phát sinh các CDR/CMR flat files cục bộ.
- CDR Agent Service trên Subscriber tiến hành transfers các CDR/CMR files tới cdr_repository directory structure trên Publisher. Sau khi tiến trình “transfer” hoàn tất, bản local copy các CDR/CMR files trên Subscriber sẽ được xóa đi (deleted).
- Nếu “Billing Servers” được cấu hình, CDR Repository Manager Service trên Publisher sẽ tiến hành transfer các flat files tới “Billing Servers”.
- Nếu tham số "Continuous Loading 24/7" được kích hoạt (enabled) trên CDR Analysis & Reporting tool, CAR Scheduler service trên Publisher sẽ tiến hành chèn thông tin cuộc gọi “Call Information” vào flat files trong CAR database trên Publisher.
- Đối với mỗi node chạy CallManager service, CDR Agent service trên node đó chịu trách nhiệu transfer thông tin các flat files tới cdr_respository structure trên Publisher. Nếu CallManager service được kích hoạt trên Publisher, dịch vụ CDR Agent service trên Publisher sẽ tiến hành transfer các flat files tới cdr_repository directory structure trên Publisher.