BETA Feature: Call Recording

We've just rolled out a new BETA feature that will allow you to record calls and have them e-mailed to you as a .WAV file.

Information can be found under Features - BETA in your vPanel.

In order to use this feature, you first need to go to vPanel and setup a destination e-mail address for your recordings.

Usage Instructions:

Make sure you have setup a recording destination e-mail in vPanel.

To record a call simply dial *28 when you place the call.

Example: *288005558355 would record a call to 8005558355.

A .wav file will be e-mailed to the address specified here within minutes of completing the call.

Note: This feature is intended for occasional use only. When you record a call, the audio for the call is routed through our Call Recording server instead of our primary media gateways and as a result call quality may be reduced.

Please let us know what bugs you find with this.

Quote:

---

Originally Posted by VOIPoTim

Please let us know what bugs you find with this.

---

Interesting feature. I wonder how it will work out with long calls. wav files can get really large fast.

How about incoming? Any way to record those?

Quote:

---

Originally Posted by Brian

How about incoming? Any way to record those?

---

Take another look :).

Quote:

---

Originally Posted by VOIPoBrandon

Take another look :).

---

Neat!!!!!!

Just Recorded both an incoming and Outgoing about 30 minutes ago and have not received the recordings back as an e-mail. (Also have checked SPAM folder)

Have you thought of any means of initiating a recording on-the-fly? For example, if a call is in progress, make it so a Voipo user can flash over to the "second channel" and initiate a 3-way call to feature code *28 (without a phone# afterwards) or *280? Similarly (though more difficult, if even possible), flashing over to *280 to stop a recording in progress would be a nice addition.

Keep in mind, I'm thinking outside the box (and outside the programming department!), so I don't know how easy or difficult these ideas would be to work into your system...

Quote:

---

Originally Posted by fisamo

Have you thought of any means of initiating a recording on-the-fly? For example, if a call is in progress, make it so a Voipo user can flash over to the "second channel" and initiate a 3-way call to feature code *28 (without a phone# afterwards) or *280? Similarly (though more difficult, if even possible), flashing over to *280 to stop a recording in progress would be a nice addition.

Keep in mind, I'm thinking outside the box (and outside the programming department!), so I don't know how easy or difficult these ideas would be to work into your system...

---

With the way our system is setup, doing it on the fly isn't really possible. We'd have to be proxying 100% of audio. Since we don't handle audio most of the time, we'd have no way to be "in the call" to intercept the command.

I just tried a test call and am quite impressed with the quality! Great feature guys!

tested incoming and outgoing both, works great
dvijen

Just now had the chance to play w/ it. All recordings (both in/out calls) get emailed to me as 314 byte files, unplayable. Obviously a problem if the files are only 314 BYTES (not kb).

Quote:

---

Originally Posted by frankd1

Just now had the chance to play w/ it. All recordings (both in/out calls) get emailed to me as 314 byte files, unplayable. Obviously a problem if the files are only 314 BYTES (not kb).

---

Could you please PM which filename this was (sent to you) -- thanks!

Edit: (4:25am, over looked the fact you said ALL) -- just to further clarify you do mean ALL? Exactly 314 bytes each? Thanks!

Quote:

---

Originally Posted by VOIPoBrandon

Could you please PM which filename this was (sent to you) -- thanks!

Edit: (4:25am, over looked the fact you said ALL) -- just to further clarify you do mean ALL? Exactly 314 bytes each? Thanks!

---

ALMOST all:

Size Timestamp (PST)
314B 7/22 12:51a
314B 7/22 12:52a
350B 7/22 1:27a
314B 7/22 2:04a

Quote:

---

Originally Posted by frankd1

ALMOST all:

Size Timestamp (PST)
314B 7/22 12:51a
314B 7/22 12:52a
350B 7/22 1:27a
314B 7/22 2:04a

---

Frank,

Ok thanks for that information -- it looks like what may be happening is that we are processing these recordings "too fast" as far as sending them out before they are completely rendered/ready. I've added a slight delay to it ~ 3 minutes -- could you re-test this feature, and let me know your end results, thanks!
________
Pregnant shemale

Quote:

---

Originally Posted by VOIPoBrandon

Frank,

Ok thanks for that information -- it looks like what may be happening is that we are processing these recordings "too fast" as far as sending them out before they are completely rendered/ready. I've added a slight delay to it ~ 3 minutes -- could you re-test this feature, and let me know your end results, thanks!

---

Just tried one outbound call, and still got the 314 byte file. Didn't have time to try inbound call.

Quote:

---

Originally Posted by frankd1

Just tried one outbound call, and still got the 314 byte file. Didn't have time to try inbound call.

---

Frank, I'm almost curious as to if there may be some other issue at hand going on, such as a limitation / error with the receiving end / mail transfer agent.

I see your full file sizes here, what I'm going to do is mark them at "un processed", so you will be resent the audio files. If you could just advise if they are still the same size, or in completion now, this should prove / disprove this theory. Thanks!

The "resends" are still 314 bytes, and unplayable. My main email address is an Exchange hosted account, so I added a Yahoo address to the vpanel recording page, and I get the same, less than 1K unplayable .wav attachment at the Yahoo address as well (I kept my Exchange address listed, and still got the 314 byte attachment there too). Let me know if there are any specifics I can provide to track this down.

Quote:

---

Originally Posted by frankd1

The "resends" are still 314 bytes, and unplayable. My main email address is an Exchange hosted account, so I added a Yahoo address to the vpanel recording page, and I get the same, less than 1K unplayable .wav attachment at the Yahoo address as well (I kept my Exchange address listed, and still got the 314 byte attachment there too). Let me know if there are any specifics I can provide to track this down.

---

I also tried a third, IMAP-focused address I used to use (fastmail), and had the same problem at that address too. FWIW, the message header for the Exchange address includes the following error:

X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: couldn't parse head;
error near:;
UklGRiQxCwBXQVZFZm10IBAAAAABAAEAQB8AAIA+AAACABAAZG F0YQAxCwCUAOQA0P+I/1gA+P+o;
/yAASADo/+D/QAA4ANj/fP98/4j/sP/o/9D/sP84AKQAWACg/3z/+P+w//D/JAHkAPj/8P9YAGgA;
MADw/5j/0P/4/8j/CAA4AMj/wP/g/3z/2P8gAJj/0P94AAgAbP8YA[...]

From my testing I found that you have to dial the 10 digit phone number for this to work. 7 digit dialing does not work. Also, I would like to suggest the ATA be setup to give you the second dial tone like you did with *67

The short call I made to test it recorded fine and the audio was clear. File size was 533 KB on a call less than 2 minutes. Overall I think its a very nice additional feature. Thanks guys!

Just tested Call Recording and this is 'partial' email. No attachment.

Content-Type: multipart/alternative; boundary="PHP-alt-891dc76df8e03209ae3c63c413fa8231"

--PHP-alt-891dc76df8e03209ae3c63c413fa8231

Content-Type: text/html; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

<p>You have received a new VOIPo recording, file is attached as wav format.</p>

--PHP-alt-891dc76df8e03209ae3c63c413fa8231--

Content-Type: audio/x-wav; name="9544713433_20090724-141949.wav"

Content-Transfer-Encoding: base64

Content-Disposition: attachment

UklGRmRlBQBXQVZFZm10IBAAAAABAAEAQB8AAIA+AAACABAAZG F0YUBlBQAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA

Suggestion. Why not make it so recorded calls stay on the server for 24 hours instead of being emailed and then the user could login Vpanel after the call and just download and delete it? Oh, and limit the file size to keep it from crashing the server. You could even have it zipped up to speed up transfer.

I think the issues I am seeing are being caused by either their email provider or their email client.

Quote:

---

Originally Posted by Xponder1

Suggestion. Why not make it so recorded calls stay on the server for 24 hours instead of being emailed and then the user could login Vpanel after the call and just download and delete it? Oh, and limit the file size to keep it from crashing the server. You could even have it zipped up to speed up transfer.

I think the issues I am seeing are being caused by either their email provider or their email client.

---

I have to disagree on the email provider/client being the problem. In my case, I tried three different providers, all of them architechturally different (one a MS Exchange acct, one a mass market webmail acct, and one high performance "email only company" acct). And in addition to Outlook, each of these three accts have wildly different webmail interfaces and underlying construction.

I initially thought the same as you when I first encountered the problem with my main acct (the Exchange one), but after I tested with the other two accts, there's absolutely no similarity between the three accts (and nothing exotic or unique to distinguish them from those of you who aren't having problems).