I have added a Callback in Sinch portal to handle app to app calls via our server. When a call reaches the Sinch platform, the system makes a POST request to our server's calling callback URL i.e. Incoming Call Event Callback (ICE) called.
In response to ICE event our server response it as
{
"instructions": [],
"action": {
"name": "connectMXP"
}
}
and callee receive incoming call notification. When Callee pick-up call the call get connected but it doesn't request to our server's callback URL, i.e. ACE event not called.
But as given in Answered Call Event Callback (ACE)
This callback is made when the call is picked up by the callee (person receiving the call). It is a POST request to the specified calling callback URL.
So the question is what is required to receive ACE event callback, is there anything missing which should be enable at Sinch side or our server side in code ? Thanks !
App2APp calls only support ICE and DICE events. If you authorized the Caller to Call the Callee user, why do you need another event notification? As the calls are mostly peer2Peer based we currently do not support ACE or PIE events for Data calls.
Related
I'm developing a chromecast custom receiver, and I need to send a request to the server once the sender disconnects from receiver. When I use ios or android senders, I can see that the 'sender disconnect' event is triggered, but when I use the browser, that event is not triggered.
Because of that, I'm trying to use the 'shutdown' event, to send that request, once the sender is disconnected.
I tried to pass an 'async/await' function as callback to the shutdown event, and tried to force an 'await' on the request, but I get the ' Application should not send requests before the system is ready (they will be ignored)'
I also tried to use the window 'beforeunload' event, but with no success.
Is there any way to send a request, once the 'shutdown' event is triggered?
Cheers
For us the Dispatching Shutdown event occurred in both cases. Web and Mobile senders. So I'm not sure what's happening on your end but will definitely need more information regarding what you're doing in order to look further into it.
Anyhow, if you are setting addEventListeners on your end like this:
context.addEventListener(cast.framework.system.ShutdownEvent,
()=>{
console.log("ShutdownEvent Called");
});
context.addEventListener(cast.framework.system.SenderDisconnectedEvent,
()=>{
console.log("SenderDisconnectedEvent called");
});
Which will result in your calls not firing. You should instead be doing:
context.addEventListener(cast.framework.system.EventType.SHUTDOWN,
()=>{
console.log("ShutdownEvent Called");
});
context.addEventListener(cast.framework.system.EventType.SENDER_DISCONNECTED,
()=>{ console.log("SenderDisconnectedEvent called"); });
Here's the docs for their reference: https://developers.google.com/cast/docs/reference/web_receiver/cast.framework.system#.EventType
I'm making an outbound call from my Twilio client to make outbound web browser calls. The calls are successfuly made and are fine, but...
Unfortunately I'm unable to see the agent/client name in your logs. I am currently using the agent/client name of 'Andy' but in Twilio's call logs it's showing the 'From' field as anonymous.
I have made a few changes to the JavaScript SDK and have added the following ''//CLIENT NAME clientName: 'Andy'' in the 'params' variable but this hasn't made a difference and the from field is still showing up as Anonymous in Twilio's call logs when I make an outbound call using the browser client.
How do I make this work? :(
Here is my code:
// Bind button to make call
document.getElementById('button-call').onclick = function () {
// get the phone number to connect the call to
var params = {
//CLIENT NAME
clientName: 'Andy',
//PARAMETERS THAT WILL BE SENT THROUGH TO TWILIO
To: document.getElementById('customer-number').value,
//THIS IS CUSTOMER CALLER ID WE'RE PASSING TO THE OUTGOING TWIML AS THE CALLER ID TO USE FOR OUTGOING CALL
CallerID: document.getElementById('source-number').value
};
console.log('Calling ' + params.To + '...');
Twilio.Device.connect(params);
};
Twilio developer evangelist here.
The parameters you pass into Twilio.Device.connect are not recorded by Twilio, but they are sent on as parameters to the URL you set as your application URL.
Client names are actually only required for incoming calls that are routed to a client. If you were to setup a client for outgoing calls only you need not setup a name. As such, client names are not captured by Twilio in the call logs.
If you need to track which clients are making calls you can do so within your own application by reading the clientName that you set in Twilio.Device.connect from the webhook parameters and associating it with the CallSid (also available in the webhook parameters).
Xmldoc states:
Adds a message handler to the service bus for handling a specific type
of message
But it does not require endpoint name. How then does it work? I tried this method, but nothing happened.
Is there any possibility to add handlers dynamically, while bus is running?
By connecting a handler to the bus after it has been started, messages can be sent to the bus's address directly. This is particularly useful for things like responses to requests, which should not be published and are sent immediately back to the endpoint.
When using bus.ConnectHandler(context => {...}) to add a handler to the bus dynamically, no subscriptions or exchange bindings are created on the broker. It's only possible to receive messages which are directly sent to the endpoint.
When a message is sent from the bus, such as a request, the SourceAddress is added to the message header. If a request is sent, the ResponseAddress is also set. A fault address can also be specified if you want to use a non-dynamic endpoint to capture faults (such as a failed command that is not awaited, IE, fire and forget) so that faults can be triaged and handled appropriately by another persistent endpoint.
I am using Autobahn and I have an implementation-specific question.
I am trying to figure out how to send a notice to all connected clients (including the newly subscribed client) upon a client subscribing to a topic. Here's the code (edited down for clarity):
#exportSub("", True)
def subscribe(self, topicUriPrefix, topicUriSuffix):
topic_uri = "%s%s" % (topicUriPrefix, topicUriSuffix)
self.client.dispatch(topic_uri, {"msg":"WTF"})
return True
Yet, I'm not seeing the newly subscribed message receive this dispatch. The dispatch call is returning None.
What's happening here?
I figured this out. A client must first be subscribed to a topic before receiving a message sent via dispatch(). This means that the dispatch() cannot be called inside subscribe if one expect the subscribing client to receive the message. I worked around this problem by building a simple message queue and calling dispatch on the protocol instance for any queued messages.
When people create real-time web apps, they are leaving a ajax request open/long running.
how do they do this in javascript?
There is really no difference from a normal ajax request. A callback is associated with the XMLHttpRequest. Once the request is complete the callback is invoked. The difference is on the server-side where the request is held open until data is ready for the client, or a timeout occurs. On the browser side, the callback is invoked as each successive request is answered. The callback must process the data from the server and initiate another request. The request is handled asynchronously, so the browser is not blocked.
A really good example of the whole thing is the chat demo included in Tornado.