I've got a bot up and running, most of the time it is working ok, but Twilio throws some 500 and 502 errors on every inbound SMS.
An attempt to retrieve content from https://sms.botframework.com/api/sms returned the HTTP status code 500.
or
An attempt to retrieve content from https://sms.botframework.com/api/sms returned the HTTP status code 502.
The 502 requests continue fine and responses are sent, but the 500s do not - the user doesn't get a response.
How can i get logging from the sms.botframework.com service to see what's going on? No errors are showing on the azure side for my bot.
Thank you
Right now the Bot Framework isn't set up for you to be able to get to the logs inside our SMS connector; the 502's are benign, but the 500's aren't something I normally see. If you wish, you can contact me with your botid at bf-reports#microsoft.com and I'll take a look, or DM me on twitter (#jameslew).
#Philnash happy to fill you in more on the BotFramework and how developers can use it with Twilio; just let us know how to contact you.
Related
We're using Twilio. We have webhooks set up so that when Twilio receives a call, it forwards it to a URL on our site.
This appears to have been working fine. But now I made a change to the code, and suddenly Twilio is having problems calling the webhook. We don't receive the message, and if I look in the Twilio log, it says it got a 403 error. (I can't swear that this has never happened before. I've never noticed a message to be lost, but maybe I missed it while debugging other errors, attributed a lost message to something else.)
The truly strange part is, about 2/3 of the message that come in are received and processed fine, but about 1/3 get the 403 error. This is on a test server where we don't have any load balancing, so all requests are going to the same instance of our app. The tests I've been doing today are all from the same cell phone to the same Twilio number.
We do have authorization on the app, but the authorization is all on sub-directories, not the top level, and the sub-directory with our web hook has no authorization set up.
The first thing my our web hook now does when it gets called is send me an email with the content of the message from Twilio. (For debugging purposes.) I'm not getting that email, so I'm very confidant it's not getting called. And as I say, I can look at Twilio's log and it says that it received the text message and got a 403 error trying to forward it to my webhook.
The fact that it's only like 1/3 of the time is particularly puzzling. It's from the same number, to the same number, hitting exactly the same URL on the same site. Why would it work sometimes and not other times?
I tried to reproduce the problem on my desktop by calling the URL directly, not going through Twilio, and that does not give the same error. (It occurs to me as I type that the next logical test is to hit the page on the server without going through Twilio.)
Oh, the server is ASP.NET. The code is in VB but I doubt that matters as we're not getting as far as executing any of our code when it fails. When it doesn't get the 403, the code is working fine.
Check your firewall configuration as it might block the requests.
If it does then whitelist requests originating from Twilio.
We're using AWS WAF and ran into a similar situation: We saw the requests erroring out with a 403 in the Twilio Debugger but the requests never hit our endpoints. Once we adjusted the whitelist the problem was gone.
Trying to make call from my app to a number using Twilio API's
When call is received, getting application error
and here is the debugger logs for that call:
Error - 11200 HTTP retrieval failure 502 Bad Gateway errors
Passing a URL when POST Request.
Can anybody help me through this?
have you taken a look at this information from Twilio? They give possible causes and possible solutions for the error you received. Did you specify the correct content-type header in your response?
If you could share your code, that would be great!
Hope this helps!
I am having an intermittent issue with Twilio. Once out of every 50 or 75 calls, we get a call that fails, and when I check the logs, it states that it is error 11200, and it gives a Bad Gateway 502 message "An upstream server received an invalid response".
I've taken a look at Twilio's suggestions regarding this error (found at https://www.twilio.com/docs/errors/11200). They list a bunch of probable causes for a bad gateway error:
1) Web server returned a 4xx or 5xx HTTP response to Twilio - as far as I can see in the logs, the web server is returning a 200 HTTP response to Twilio.
2) Misconfigured Web Server - We have checked the configuration of our web server, and believe it to be correct.
3) Network disruptions between Twilio and your web server - we have tested the ping response time, and the packet loss between www.twilio.com and our server. The ping time is < 100ms, and there seems to be no packet loss when testing with ping -n 100 www.twilio.com
4) No Content-Type header attached to response - we set our Content-Type to application/xml.
5) Content-Type doesn't match actual content - We set our Content-Type to application/xml and are using the TwiML language to send our responses back.
We have also checked all elements in Twilio's Possible Solutions section for this error.
A bit about what we are doing:
API Version: 2008-08-01
We only make outgoing calls.
We use TwiML to send a Say command, followed by a Gather. It is during the Gather that we get our intermittent error. The user will press a key, which gets sent back to us. Depending on which key is pressed, we then send another Say to Twilio - for example "You pressed 1. This offer has been accepted. Thank you." or "You pressed 2. This offer has been declined. Thank you."
I'm not ruling out that it's something at our end that is causing the issue, but we don't really know what to check next. The web server appears to be sending a 200 response back, but Twilio seems to be receiving a 502.
Does anybody have any suggestions that might help us out? Could it be a problem with the API we are using? Should we be upgrading to 2010-04-01?
Thank you in advance!
This problem was an internal networking issue on our side. It was not an issue with Twilio or their API
When my app contacts Twilio it passes a call back URL so Twilio can get additional info. I never see the request from Twilio but I get a call telling me that an application error has occurred.
When I check the Twilio debugging log it says it got a "502 Bad Gateway" error for the URL I passed it. However, when I try the same URL, I get a response just fine.
My app is running on a non-standard port but I'm pretty sure Twilio doesn't care about that.
What can cause Twilio to get a 502 when I don't
Here's the response I get when I hit the URL
<Response>
<Gather action="http://dev1.onshift.com/twilio/user_response_handler?sendID=38297795" method="POST" numDigits="1">
<Play>http://dev1.onshift.com/wavs/254_preamble.wav</Play>
<Play>http://dev1.onshift.com/wavs/8144924.wav</Play>
<Play>http://dev1.onshift.com/static/messages/handle_human_footer.wav</Play>
<Play>http://dev1.onshift.com/wavs/254_preamble.wav</Play>
<Play>http://dev1.onshift.com/wavs/8144924.wav</Play>
<Play>http://dev1.onshift.com/static/messages/handle_voicemail_footer_v2.wav</Play>
<Play>http://dev1.onshift.com/wavs/8144924.wav</Play>
<Play>http://dev1.onshift.com/static/messages/handle_voicemail_footer_v2.wav</Play>
<Play>http://dev1.onshift.com/static/messages/goodbye.wav</Play>
</Gather>
</Response>
From OP's comments above:
In my case there was a change on our network that blocked the server I
was working on from outside of our network. Your network people may be
wrong or confused. If you know the URL you're passing to Twilio you
can prove them right or wrong by seeing if you can hit that URL from
outside your network. You can try from home, or, what I did was turn
off wireless on my phone and tried to hit the URL from it. I couldn't
do it although it worked from my laptop on the company wifi. If you
can't hit the URL from outside your network neither can Twilio
Follow these suggested steps will help others begin to debug as they receive this error.
Initially I have been using the TwiML response to send response to my text messages. But since my requirement has changed and I need to send more than 10 messages in response to my text hence I am now using the Twilio API to send the message out. So to fix this now I am trying to send nothing as the TwiML response for my Text Messages and instead using the Twilio API to send the actual messages out. I also have a TwiML bin URL attached to my short code as a Message Fall Back URL in case Twilio is not able to connect to my REST API URL. So now when a Text message is received by Twilio it connects to my REST API and the response is sent. But I am getting the response from the Message FallBack URL first and then the actual response for my text message via the Twilio API. Is there anyway to avoid this? I can remove the Message Fall back URL but then what would happen in the actual case when Twilio is not able to connect to my server?
This is how I have added the code:
var twilioResponse = new Twilio.TwiML.TwilioResponse();
...... have code that uses Twilio API to send out more than 10 messages.
...... Since the messages are going out via Twilio API hence returning NULL to the TwiML response
return Request.CreateResponse(HttpStatusCode.OK, twilioResponse.Element);
More Updates:
As I mentioned earlier I'm using the REST API to send an SMS. When a Text request comes Twilio server calls my URL supplied to the REST call.
Sometimes my server is little slow in responding - in which case twilio gets the fallback URL message and passes on the text message.
How do I increase the timeout ? This timeout is the time the server responding with TWIML.
Please help - any pointers are appreciated.
Twilio evangelist here.
My first suggestion would be to check your accounts App Monitor to see if Twilio is logging any errors. The Fallback URL should not be getting requested unless Twilio fails to get a valid response from the primary URL.
The default timeout for a Twilio request is 15 seconds, so if your server is taking longer than that to respond there may be a bigger issue happening with your server or network.
Hope that helps.