I need to record a voice of my clients who is try to reach one of our advisors. This should happen when there is timeout
User calls -->Number-----> If timeout --> say(Record your message)--> on end of the recording it should call the recordingStatusCallBack
User Call --> Number --> answer call success --> On end of the call it should call method. Not sure where should we put the action either on number (statuscallback) or on the dial Action verb?
To achieve this I am try with the below twiML
<Response>
<Dial callerId="+123124" record="true" timeout="10">
<Number
statusCallback="https://<123134>.ngrok.io/ttwilio/callStatusCallBack"
statusCallbackEvent="completed"
statusCallbackMethod="POST">+1232424/Number>
</Dial>
<Say>Please Record you message</Say>
<Record
recordingStatusCallback=
"https://<123134>.ngrok.io/ttwilio/callStatusCallback"
recordingStatusCallbackMethod="POST"/>
</Response>
This works fine when there is a timeout but when the call is successfully ended twilio still ask for the user to "Please Record you message"
How to achieve this task?
Twilio developer evangelist here.
The behaviour of <Dial> when there is no action attribute is to continue with the TwiML below it once the call is finished, whether by timeout or through a successful call.
If you add a URL as the action attribute, then the behaviour changes and <Dial> will always make a request to the action URL once the call is completed. The important difference here though, is that the URL will be called with a DialCallStatus parameter that will be one of "completed", "answered", "busy", "no-answer", "failed" and "canceled". This way you can check if the call was busy or not answered and return the TwiML for recording a message. Or if the call was completed successfully, you can just return <Hangup/>.
Let me know if that helps at all.
I am using Twilio rest API for Php and want to create an application to send and receive text messages.
We have many senders and every one wants to send and receive their messages. And every one want to receive text messages on their cell phone.
Is it possible to send text message to some one and we get our reply to our cell phone?
I am new in tiwlio so please can you guide me the procedure of sending and receiving text messages.
I have implemented sending part and not getting how to receive messages back on cell phone if someone reply.
Thanks
Twilio developer evangelist here.
When someone replies with a message to a Twilio phone number, Twilio will take the message and send it to a URL you define as an HTTP request. You can then decide what to do with the message.
You can, for example, forward the message on to another number. There is a restriction here in that you cannot forward the message and make it appear to have come from the original sender, you have to set the caller ID as one of your Twilio numbers. You can include the original sending number as part of the message though.
To do this, you would need to respond to the HTTP request with some TwiML. This is a subset of XML that tells Twilio what to do with the message. To forward the message including the original sender number, you would use the <Message> TwiML element from PHP like this:
<?php
$from = $_REQUEST['From'];
$body = $_REQUEST['Body'];
$forwarding_number = "THE NUMBER TO FORWARD THE MESSAGE TO";
// we'll forward from the Twilio number that received the message
$caller_id = $_REQUEST['To'];
header("Content-type: text/xml");
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
?>
<Response>
<Message to="<?php echo $forwarding_number; ?>" from="<?php echo $caller_id; ?>">
Message from <?php echo $from; ?>: <?php echo $body; ?>
</Message>
</Response>
As I said though, there are limitations on this, the message will be sent to your users phone from your Twilio number. In reality, you likely want to be able to reply to the message again, so it's perhaps better to just send a notification to your users and build an application that can receive those messages and display them in a dashboard, using the API to respond to them.
I have started an example of this sort of app here on GitHub (it's built in Node.js, but might give you an idea).
Let me know if that helps at all.
im facing a problem with my jms messeages.
Case is:
in my mainPS i give an employeeId on request which routes to BS to get employees with emploeeId >= than given. Response is employees collecion.
On response action in mainPS I loop through whole collection and id like to add to JMS queue one by one employee as simple message. In every loop iteration im seting user-defined transport header in if statement as msgName 'even' or 'odd' depends on employeeId on Outbound Request. On loged result i can see that headers have added properly.
Then (still for every employee) I publish my JMS-BS which adds message to queue.
When I want to pull my messages in JMSConsumerPS there are no any transport headers which i have added. Consumer has Get All Headers property set as 'YES'.
Im logging in consumer my whole
$inbound/ctx:transport
and what i get is:
<con:transport>
<con:uri>myURI</con:uri>
<con:mode>request</con:mode>
<con:qualityOfService>best-effort</con:qualityOfService>
<con:request xsi:type="jms:JmsRequestMetaData" xmlns:jms="http://www.bea.com/wli/sb/transports/jms" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tran:headers xsi:type="jms:JmsRequestHeaders" xmlns:tran="http://www.bea.com/wli/sb/transports">
<jms:JMSDeliveryMode>2</jms:JMSDeliveryMode>
<jms:JMSExpiration>0</jms:JMSExpiration>
<jms:JMSMessageID>ID:<834866.1398327222060.0></jms:JMSMessageID>
<jms:JMSPriority>4</jms:JMSPriority>
<jms:JMSRedelivered>false</jms:JMSRedelivered>
<jms:JMSTimestamp>1398327222060</jms:JMSTimestamp>
<jms:JMSXDeliveryCount>1</jms:JMSXDeliveryCount>
</tran:headers>
<tran:encoding xmlns:tran="http://www.bea.com/wli/sb/transports">UTF-8</tran:encoding>
<jms:message-type>Text</jms:message-type>
</con:request>
Thanks for help.
Just a guess.
I was setting transport header in in-correct place. I had a "publish"
action in the proxy and I was setting transport header just before the
publish action. I moved the "transport header setting" to be done
inside the "publish" action/task . Now it works as expected.
Taken from https://community.oracle.com/thread/2155298?tstart=165, link most likely will be dead soon enough - Oracle community ...
Thank you very much for that. That was almost same issue. What I did was movig "transport header setting" into request action of published BS. Thing is i have tried it before asking but had no idea why it didnt work. Probably the reason could be that i turned on pass all headers through pipeline that time [?]. Had no idea if that can make such a mess. Thanks for replaying.
If a website user submits an HTML form with: (1) a post method; (2) a multipart/form-data enctype; and, (3) a large attached file, can the server upload a posted file, and send a server generated HTTP response before the file upload is completed, without using AJAX?
That's pretty dense. So, I wrote an example to illustrate what I mean. Let's say there is an image upload form with a caption field.
<form action="upload-with-caption/" method="post" enctype="multipart/form-data">
<input type="hidden" id="hiddenInfo" name="hiddenInfo" />
File: <input type="file" name="imgFile" id="imgFile" /><br />
Caption: <input type="text" name="caption" id="caption" />
<input type="submit" />
</form>
I want to store the caption in a database table with the the definition:
[files_table]
file_id [uniqueidentifier]
file_caption [varchar(500)]
file_status [int]
Then I want to upload the file to /root/{unique-id}/filename.ext.
file_status is mapped to a C# enum with the following definition:
enum FileUploadStatus{
Error = 0,
Uploading = 1,
Uploaded = 2
}
When the form submits, if the file is too large to process in 1 second, I want to send the webpage back a response that says it is currently uploading.
Can I do this with a single synchronous HTTP post?
Note: I will obviously want to check for the status updates later using AJAX, but that is not what this question is asking. I am specifically asking if the file can continue to upload after the response is sent.
HTTP is a synchronous protocol.
You cannot send a response until you receive the entire request.
Looking at the HTTP specifications alone (RFC's 753x), then the answer is Yes (and, the currently accepted answer is wrong). HTML specifically I don't think have anything to add.
The HTTP/1.1 protocol "relies on the order of response arrival to correspond exactly to the order in which requests are made on the same connection" (RFC 7230 §5.6). Timing has nothing to do with it.
Not only does the protocol allow for early responses, but some message semantics from categories 4xx (Client Error) and 5xx (Server Error) actually expects the response to be sent before the request has completed.
Let's take an example. If you intend to send five trillion billion million gigabytes to a web server (let's assume this number fit whatever data types are in use for the Content-Length header), when would you expect to receive a "413 Payload Too Large" response back? As soon as possible or only after a couple of decades when the request transfer completes? Obviously the sooner the better!
2xx (Successful) responses are a bit different. These responses "indicates that the client's request was successfully received, understood, and accepted" (RFC 7231 §6.3). Sending back this type of response early is likely to confuse the client.
Instead, what you probably want to send back as an early response belongs to the 1xx (Informational) category. These are referred to as "interim responses" meant to supersede but not obsolete the final response.
RFC 7231 §6.2:
The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress
prior to completing the requested action and sending a final
response.
RFC 7230 §5.6:
More than one response message per request only occurs
when one or more informational responses precede a
final response to the same request.
RFC 7231 §5.1.1 has a great example where a client is about to send a "presumably large" message but instead of immediately sending the body after the head, the client includes an Expect: 100-continue header and then goes into a short paus whilst expecting the server to either reject the message or welcoming the client to carry on by means of responding a "100 Continue" interim response. This then potentially avoids the client having to transmit bytes for nothing. Smart!
Finally, I thought long and hard about when would we ever want to send a 2xx (Successful) response back to the client before the request has completed? I can only come up with one single scenario - and this is certainly not a common case, but I am going to have it stated: If the server has consumed enough of the request in order to take action and the server wish to discard the remaining body because the residue is sufficiently large and at the same time of no more use to the server, then respond 202 Accepted and include a "Connection: close" header.
This is obviously not good for connection re-use and could also easily lead to confused clients and so the payoff why we're responding early should be 1) advantageous enough to mitigate the overhead of establishing a new connection, 2) advantageous enough to offset the danger of crashing clients that was not prepared for an early response, and 3) be well documented.
The "Connection: close" header will explicitly instruct the client to stop sending the request (RFC 7230 §6.3). And due to message framing, the connection is dead anyways as there is no way for the communication to resume with a new message exchange pair over the same connection. Technically speaking, the client can cleanly abort a chunked transfer (RFC 7230 §4.1) and thus save the connection, but this is details and not applicable in the general case.
It appears that when you make an XMLHttpRequest from a script in a browser, if the browser is set to work offline or if the network cable is pulled out, the request completes with an error and with status = 0. 0 is not listed among permissible HTTP status codes.
What does a status code of 0 mean? Does it mean the same thing across all browsers, and for all HTTP client utilities? Is it part of the HTTP spec or is it part of some other protocol spec? It seems to mean that the HTTP request could not be made at all, perhaps because the server address could not be resolved.
What error message is appropriate to show the user? "Either you are not connected to the internet, or the website is encountering problems, or there might be a typing error in the address"?
I should add to this that I see the behavior in FireFox when set to "Work Offline", but not in Microsoft Internet Explorer when set to "Work Offline". In IE, the user gets a dialog giving the option to go online. FireFox does not notify the user before returning the error.
I am asking this in response to a request to "show a better error message". What Internet Explorer does is good. It tells the user what is causing the problem and gives them the option to fix it. In order to give an equivalent UX with FireFox I need to infer the cause of the problem and inform the user. So what in total can I infer from Status 0? Does it have a universal meaning or does it tell me nothing?
Short Answer
It's not a HTTP response code, but it is documented by WhatWG as a valid value for the status attribute of an XMLHttpRequest or a Fetch response.
Broadly speaking, it is a default value used when there is no real HTTP status code to report and/or an error occurred sending the request or receiving the response. Possible scenarios where this is the case include, but are not limited to:
The request hasn't yet been sent, or was aborted.
The browser is still waiting to receive the response status and headers.
The connection dropped during the request.
The request timed out.
The request encountered an infinite redirect loop.
The browser knows the response status, but you're not allowed to access it due to security restrictions related to the Same-origin Policy.
Long Answer
First, to reiterate: 0 is not a HTTP status code. There's a complete list of them in RFC 7231 Section 6.1, that doesn't include 0, and the intro to section 6 states clearly that
The status-code element is a three-digit integer code
which 0 is not.
However, 0 as a value of the .status attribute of an XMLHttpRequest object is documented, although it's a little tricky to track down all the relevant details. We begin at https://xhr.spec.whatwg.org/#the-status-attribute, documenting the .status attribute, which simply states:
The status attribute must return the response’s status.
That may sound vacuous and tautological, but in reality there is information here! Remember that this documentation is talking here about the .response attribute of an XMLHttpRequest, not a response, so this tells us that the definition of the status on an XHR object is deferred to the definition of a response's status in the Fetch spec.
But what response object? What if we haven't actually received a response yet? The inline link on the word "response" takes us to https://xhr.spec.whatwg.org/#response, which explains:
An XMLHttpRequest has an associated response. Unless stated otherwise it is a network error.
So the response whose status we're getting is by default a network error. And by searching for everywhere the phrase "set response to" is used in the XHR spec, we can see that it's set in five places:
To a network error, when:
the open() method is called, or
the response's body's stream is errored (see the algorithm described in the docs for the send() method)
the timed out flag is set, causing the request error steps to run
the abort() method is called, causing the request error steps to run
To the response produced by sending the request using Fetch, by way of either the Fetch process response task (if the XHR request is asychronous) or the Fetch process response end-of-body task (if the XHR request is synchronous).
Looking in the Fetch standard, we can see that:
A network error is a response whose status is always 0
so we can immediately tell that we'll see a status of 0 on an XHR object in any of the cases where the XHR spec says the response should be set to a network error. (Interestingly, this includes the case where the body's stream gets "errored", which the Fetch spec tells us can happen during parsing the body after having received the status - so in theory I suppose it is possible for an XHR object to have its status set to 200, then encounter an out-of-memory error or something while receiving the body and so change its status back to 0.)
We also note in the Fetch standard that a couple of other response types exist whose status is defined to be 0, whose existence relates to cross-origin requests and the same-origin policy:
An opaque filtered response is a filtered response whose ... status is 0...
An opaque-redirect filtered response is a filtered response whose ... status is 0...
(various other details about these two response types omitted).
But beyond these, there are also many cases where the Fetch algorithm (rather than the XHR spec, which we've already looked at) calls for the browser to return a network error! Indeed, the phrase "return a network error" appears 40 times in the Fetch standard. I will not try to list all 40 here, but I note that they include:
The case where the request's scheme is unrecognised (e.g. trying to send a request to madeupscheme://foobar.com)
The wonderfully vague instruction "When in doubt, return a network error." in the algorithms for handling ftp:// and file:// URLs
Infinite redirects: "If request’s redirect count is twenty, return a network error."
A bunch of CORS-related issues, such as "If httpRequest’s response tainting is not "cors" and the cross-origin resource policy check with request and response returns blocked, then return a network error."
Connection failures: "If connection is failure, return a network error."
In other words: whenever something goes wrong other than getting a real HTTP error status code like a 500 or 400 from the server, you end up with a status attribute of 0 on your XHR object or Fetch response object in the browser. The number of possible specific causes enumerated in spec is vast.
Finally: if you're interested in the history of the spec for some reason, note that this answer was completely rewritten in 2020, and that you may be interested in the previous revision of this answer, which parsed essentially the same conclusions out of the older (and much simpler) W3 spec for XHR, before these were replaced by the more modern and more complicated WhatWG specs this answers refers to.
status 0 appear when an ajax call was cancelled before getting the response by refreshing the page or requesting a URL that is unreachable.
this status is not documented but exist over ajax and makeRequest call's from gadget.io.
Know it's an old post. But these issues still exist.
Here are some of my findings on the subject, grossly explained.
"Status" 0 means one of 3 things, as per the XMLHttpRequest spec:
dns name resolution failed (that's for instance when network plug is pulled out)
server did not answer (a.k.a. unreachable or unresponding)
request was aborted because of a CORS issue (abortion is performed by the user-agent and follows a failing OPTIONS pre-flight).
If you want to go further, dive deep into the inners of XMLHttpRequest. I suggest reading the ready-state update sequence ([0,1,2,3,4] is the normal sequence, [0,1,4] corresponds to status 0, [0,1,2,4] means no content sent which may be an error or not). You may also want to attach listeners to the xhr (onreadystatechange, onabort, onerror, ontimeout) to figure out details.
From the spec (XHR Living spec):
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
from documentation http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute
means a request was cancelled before going anywhere
Since iOS 9, you need to add "App Transport Security Settings" to your info.plist file and allow "Allow Arbitrary Loads" before making request to non-secure HTTP web service. I had this issue in one of my app.
Yes, some how the ajax call aborted. The cause may be following.
Before completion of ajax request, user navigated to other page.
Ajax request have timeout.
Server is not able to return any response.