CDR Streaming interface¶
DIDWW Streaming API enables the streaming of CDRs to customers API. It’s a subscription-based mechanism that will deliver the CDRs using HTTP POST method within 3 seconds after call completion.
Configuration and usage¶
CDR Streaming is currently beta and it can enabled only by customers request to DIDWW technical support team at email@example.com
CDRs are delivered in batches, HTTP POST request can contain multiple CDRs. Maximum batch size is 1000. Destination API should be able to process multiple CDRs in same request.
If the destination API responds with 2xx HTTP code, streaming interface will consider all CDRs sent in that request as processed and they will be automatically deleted from the queue. In case of HTTP error (non 2xx response or timeout), CDRs will be stored in the queue and will re-attempt to deliver them after 3 seconds.
Queue length is limited to 10000 records per customer, long customers API downtime or increased delay to process the requests can cause data loss. Therefore, CDR Streaming mechanism can not be used as the only way to receive CDRs. See the API documentation for other CDR fetching mechanisms.
Requests are being sent from IPv4 address 18.104.22.168 and IPv6 address 2a01:ad00:2:3::148.
CDRs are serialized to JSON format. Request can contain multiple CDRs (multiple JSON objects) separated by n(LF) - also known as JSONEachRow format. Request Payload encoded as gzip so customer API should support gzip.
HTTP request headers example:
POST /cdr HTTP/1.1 Host: 192.0.2.5 User-Agent: CDR-streamer Accept: */* Content-Type: text/plain Content-Encoding: gzip Content-Length: 2358 Expect: 100-continue
Streamer supports CDR delivery for differrent DIDWW services. Payload format depends on the service type.