Recording Cloud Storage

[mskenderian]

In version 69 the much anticipated:

 

Quote

EC2 recordings This version beginds to support storing recordings in the cloud instead of storing them locally.

Where are the settings for this?

isn’t it called S3 and not EC2?

I hope the way it was developed. It would still store it locally first in case the S3 endpoint is offline. And then move it to remote storage.

 

[Vodia PBX]

The EC2 integration is not very well tested and there are also some glitches with the playback from the web front end because of the content policy, however this is how we are using it right now. Once we have added this, we'll add this to the web front end to make it easier to set the values:

record_location: ec2://vodia-test-recordings/$*.wav
cloud_providers: {"ec2":{"provider":"amazon","AWSAccessKeyId":"AKIAQAD3PM5NTG7CYT6C","AWSSecretAccessKey":"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","AWSRegion":"us-east-1"}}

 

Setting this up on Amazon is a science in itself, especially granting the right permissions. We'll probably have to do a whole webinar about that.

[mskenderian]

25 minutes ago, Vodia PBX said:

The EC2 integration is not very well tested and there are also some glitches with the playback from the web front end because of the content policy, however this is how we are using it right now. Once we have added this, we'll add this to the web front end to make it easier to set the values:

record_location: ec2://vodia-test-recordings/$*.wav
cloud_providers: {"ec2":{"provider":"amazon","AWSAccessKeyId":"AKIAQAD3PM5NTG7CYT6C","AWSSecretAccessKey":"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","AWSRegion":"us-east-1"}}

 

Setting this up on Amazon is a science in itself, especially granting the right permissions. We'll probably have to do a whole webinar about that.

Is it really called ec2? that’s the compute module. Aren’t you referring to S3?

problem you will have is that tenants domains need to be all Whitelisted because of cors.

another options that’s possible. PBX get the request. Goes to s3 gets the file. Caches it locally let’s say 3 days. Then plays the file. Then we need a background process to cleanup the cache files every night.

cache is a good idea, since they may play the file a few times within a period of time.

 

[Vodia PBX]

22 minutes ago, mskenderian said:

Is it really called ec2? that’s the compute module. Aren’t you referring to S3?

It is S3.

29 minutes ago, mskenderian said:

problem you will have is that tenants domains need to be all Whitelisted because of cors.

Yes, that is still TBD. We might just whitelist EC2/S3 for now.

31 minutes ago, mskenderian said:

another options that’s possible. PBX get the request. Goes to s3 gets the file. Caches it locally let’s say 3 days. Then plays the file. Then we need a background process to cleanup the cache files every night.

cache is a good idea, since they may play the file a few times within a period of time.

Every recording that is not on the system anymore is a good recording. Keep in mind that some call centers generate many GB of recordings every day. 

[mskenderian]

I think this is a big feature. I am really looking forward to it. I would move to v69 just for this.

just keep in mind. We may have multiple PBX pointing to the same s3 bucket. So I don’t know the “file system” design you guys are considering.

how will the recording work? Will is be saved locally first and then uploaded? 
what if the s3 bucket is offline or credentials are wrong. How will the PBX handle that? 
email notification if s3 fails after a day.

api? To list call recording file name, with timestamp and file size?

api? Summary to just list number of files per tenants, and total disk space used for that tenants. Needs this for billing purposes.

Will it be a standard s3 complaint api where I can use any service provider that supports the s3 api. Like Backblaze or cloudflare?

[Vodia PBX]

Cloud storage including EC2/S3 is powerful. We are just scratching the surface. For example, we could add additional tags that can be used in search—then there is no need to include those tags in the WAV itself. 

The way it works right now that the recording is held in memory until it is uploaded. I doubt that we can hold recordings for the whole day, this would obviously exceed memory capacity. But an outage of EC2/S3 for the whole day would be quite an event, and there might be bigger problems that the PBX losing recordings. 

I was not even aware about S3 being a standard but if that's the case it should be relatively easy to send the recording a different direction.