CODEWITHSUNDEEP
phpaudiotwilio
Apps-n-Add-Ons
Apps-n-Add-Ons

Reputation: 2146

Why do some audio files not play in Twilio Play?

I've got a strange issue with Twilio playing some audio files, while others give errors.

The twiml code is not the issue - here's a simplified version of what I'm using...

<?php
include('route\to\twilio');    
use Twilio\TwiML\VoiceResponse;
$response = new VoiceResponse;
$audio = "https://example.com/2190277108.mp3";
$response->play($audio);
header('Content-Type: text/xml');
echo $response;

The problem is that SOME files just don't play, while others give error codes in Twilio

For this particular .mp3 file, Twilio's Request Inspector shows a 502 error

POST https://example.com/twilio-answer-call.php 2020-06-19 14:13:21 UTC 915ms 200

Request

Response

Headers

Body

<?xml version="1.0" encoding="UTF-8"?> <Response> <Play>https://example.com/2190277108.mp3</Play> </Response>

GET https://example.com/2190277108.mp3 2020-06-19 14:13:23 UTC 1095ms 502

Request

Response

Headers

Content-Type text/html

Body

Twilio was unable to fetch content from: http://example.com/2190277108.mp3

Error: Empty/Invalid Response from Remote Host mydomain.com

Account SID: myTwilioAcct

SID: CA4b1

Request ID: 02-7e8-43-a6-0d448

Remote Host: example.com

Request Method: GET

Request URI: http://example.com/2190277108.mp3

URL Fragment: false

Yet, when I change the .mp3 (and only that...), it plays just fine....

$audio = "https://example.com/AnotherOneBitesTheDust.mp3";

The difference is that, on the 'song' one (that works), I see

Headers Content-Type audio/ulaw

Going directly to each link in Chrome, the audio plays just fine (which means little, other than the link is correct...), however, it fails in Twilio.

I've tried various ways to 'fake' the header (using some php code, various html autoplay, etc.) and can get the Header to be 'audio/ulaw', but the audio doesn't play...

With some variations, I have stacked the audios (the feature I've implemented places various 'stacks' of audio depending on the user's configuration) and again, SOME audio files have different reactions from Twilio.

I've spent hours trying to figure what files work, what doesn't.....

The problem ones are recorded on the PC - some recorded through the browser (I've used various methods, lately using https://github.com/muaz-khan/RecordRTC - all methods five same results...), some directly in Voice Recorder. I've also tried directly uploading the files as well as through PHP upload.

At one point (early in the development, which made me happy - then we found other bugs....) we had files working on Twilio and moved away from those tests as it seemed to work easy and fast. Then, we went back to do some final testing and found this 'some files work' issue.....

So, what I'm looking for is a consistent way to make files work.

What it seems to be is that the recording method isn't giving the right headers when played back directly through Twilio (the purchased song works, while internal PC recordings don't....), though I have no way to really prove that (that I know of - maybe getid3 would help????)

The perfect end result is to have a way to record through the browser, upload and have it play correctly. I've tried .m4a, .wav and .mp3 - all of which give the same results as above (some worked early on, now I can't find the 'magic' combo again.....)

Could be that I've just been at this one issue too long (20 hours or more...) and am missing something simple, but I just can't see it.

Any help/suggestions are welcome! Thanks!

Upvotes: 0

Views: 1281

Answers (1)

Max
Max

Reputation: 123

In my case the solution was to ensure the file server provides the correct (and supported) content-type. I had the same issue when serving files from my Azure Storage, while it was working fine when I uploaded the same files to Twilio Assets. When I uploaded the file to azure blob storage which would later server the file, this i how I set the correct file content-type:

public async Task<Blob> UploadBlob(IFormFile file)
{    
    var containerClient = this._blobServiceClient.GetBlobContainerClient(_blobStorageFolder);
    var blobClient = await containerClient.GetBlobClient(file.FileName);

    await using(Stream? data = file.OpenReadStream())
    {    
        await blobClient.UploadAsync(data, new BlobUploadOptions() 
        { 
            HttpHeaders = new BlobHttpHeaders() 
            { 
                ContentType = file.ContentType,
                CacheControl = "max-age=31536000" // we allow caching for a year, because we never update the file
            } 
        });
    }
}

In this example, file.ContentType must be one of the supported MIME types. In the header options of your file response, you can also include a header matching the desired caching strategy, so that Twilio uses caches and does not download the file every time.

Upvotes: 0

Related Questions