User Story
CallCabinet provides call recording and analytics service. Their end-users are companies that use IP Centrex or SIP Trunking services. CallCabinet normally do not sign contract directly with end-users. They have Partners - service providers (like ECN, VOX, XDSL) who resell their service to their customers.
They basically provide two types of services:
- Call Recording storing. They have basic packages (Base call recording service) based on monthly consumption of stored hours (up to 200, 500, 1000, 4000, 10000, 20000, 50000, 100000, 250000, 500000, 1000000 hours). The allowed consumption package changes automatically based on the length of stored recordings.
- Additional service of Quality Control: QC Analyst, QC Supervisor, Agent Screenshot Capture, PCI Module. Each service is provided for additional licence per company (location).
CallCabinet charge Customers based on the stored hours.
CallCabinet needs to receive recordings of the SIP Trunking / IP Centrex customers that are subscribed to their service. Thus to get recordings from PortaSwitch. CallCabinet already works with a number of PortaOne Customers. For them they use the following approach: API gets call recordings from PortaOne in .wav format together with information about: customer, site, from, to, duration. The issue is that for CSP such an approach will not work due to number of subscribers and recordings. This may put too big load on system thus decreasing its stability and operational power.
That is why some other approach is required that will not load system and provide ability for CallCabinet to get recordings.
CallCabinet sees solution in moving recordings to dedicated storage in .wav format with meta file that contains metadata of the call (from, to, Customer, site etc). With this information they will be able to download recordings from dedicated server and upload to CallCabinet system for further analysis and storage.
In order to analyze call records Call Cabinet needs to get .wav files and recordings meta-information to their system. Meta-information includes:
- CallCabinet Customer and Location (Branch office) Identifier
- Call Direction
- Called Party
- Calling Party
- Call Time
- Call Duration
- PortaOne call identifier (h323-conf-id)
Some of Service Provider Customers use both CallCabinet and PortaBilling call recording services thus both of them should be available for Customers.
Use Cases
Use case #1: Call recordings storage on external server for fetching recordings by CallCabinet
Roles: Admin, PortaSwitch, CallCabinet
Preconditions:
Service Provider resells CallCabinet service
There is possibility of enabling call records and meta-information storing on external storage on per Billing Environment basis
Service provider has two Billing Environments: pb and Ocs_IP.
Service Provider has his hosted PBX and SIP Trunking customers in pb environment that want to use CallCabinet along with PB
In 'pb' env there is SIP Trunking customer ABC with two sites (locations) in pb environment: Cape Town, Pretoria. ABC has Office Hierarchy enabled and has two branch offices set up: Cape Town, Pretoria . Each has the following trunks:
~ Cape Town: 1.1.1.1; 2.2.2.2; 3.3.3.3
~ Pretoria: 4.4.4.4
Use scenario #1.1: Enabling storage of call recordings locally and on external storage for CallCabinet for environment
- Service Provider enables external storage for call recordings for billing environment 'pb' in addition to local PortaBilling call recording storage.
- Environment 'Ocs_IP' has only local call recording enabled.
Use scenario #1.2: Saving calls on external storage
- continued after 1.1
- ABC requests to have call recording of Cape Town calls.
- ABC informs about CallCabinet Customer GUID and Site GUID.
- CSP admin PortaBilling custom fields for ABC Customer. He sets up
- CallCabinet Customer GUID b1654edb-8761-426a-a122-864863fa1607 and
- CallCabinet Site GUID ba0d7a3d-c304-482d-88bc-569843c276a5 for CapeTown site.
- Admin separately enables call recording service for every trunk of Cape Town: 1.1.1.1; 2.2.2.2; 3.3.3.3 in PortaBilling.
- Users of ABC Cape Town make 10 calls of total length 2 hours. Users of ABC Pretoria make 20 calls of total length 3 hours.
- Call records and information about them (including CallCabinet Customer GUID, CallCabinet Site GUID) are passed to external storage.
- Information on each call includes:
CallCabinet Customer GUID: b1654edb-8761-426a-a122-864863fa1607
CallCabinet Site GUID: ba0d7a3d-c304-482d-88bc-569843c276a5
Call Direction:
Called Party:
Calling Party:
Call Time:
Call Duration:
PortaOne call identifier (h323-conf-id): - CallCabinet fetches them. Users can open CallCabinet, see Cape Town 10 calls and total duration of recordings is 2 hours.
- ABC opens PortaBilling web interface and can see call recordings of his users.
Use scenario #1.3: Storing calls in PortaBilling
- continued after 1.2
- Customer ABC from pb environment contacts Service Provider and requests to enable call recording for Pretoria site without CallCabinet.
- Admin enables Call Recording for ABC Pretoria Branch SIP Trunks and do not add ABC Pretoria SIP trunk 4.4.4.4 to Call Cabinet.
- ABC Pretoria Branch users make calls 10 calls of total length 2 hours. ABC Pretoria Branch user goes to PortaBilling Self Care interface and can download recordings from it.
- Calls records and information about them are passed to external storage.
- Information on each call includes:
CallCabinet Customer GUID: b1654edb-8761-426a-a122-864863fa1607
CallCabinet Site GUID:
^^^^ empty CallCabinet Site GUID - CallCabinet does not fetch them as there is no relevant CallCabinet Site GUID.
- ABC Pretoria Branch recordings are not present in CallCabinet .
Use scenario #1.4 Recording and CallCabinet is not available for another billing environment
- continued after 1.1
- There is customer Star in Ocs_IP Billing Environment. He wants to use CallCabinet service. He contacts Service Provider.
- Ocs_IP does not have contract with CallCabinet thus it is not enabled for his Billing Environment. Ocs_IP admin informs that this service is not available at the moment.
Other requirements / constraints
Non-functional requirement #1: Processing time ( latency )
The customer would benefit from recordings quickly appearing on the external storage - "a minute or 2 after the call completed should be acceptable". (here are links to their reply JFH: TT#664084#txn-44156832 and TT#664084#txn-44166016 ). This is not strict, just their vision of optimal latency / processing time.
Non-functional requirement #2: Performance figures - current amount of recordings
Current number of recordings per day: 200,000
(if we assume that they only happen during 7 business hours) - it would be 200000/7/3600=8 recordings per second on average, meaning that there may be spikes of higher load
Current storage time: 62 days for the source files
Estimated size on disk: ~200GB per day