As twilio said about simultaneous dialing that
You can use several and nouns within a verb to dial multiple phone numbers and clients at the same time. The first person to answer the call will be connected to the caller, while the rest of the call attempts are hung up.
I implement this functionality same as described but when someone dial to my twilio number I pass above twiml response and every client receive Incoming call but when one of all client pick the call by .accept() method ,nothing happens and call continuously ring for all client .
But if only one client is ready to receive call and accept incoming call ,everything works fine.
Please help me ,I am in big trouble .
Twilio Developer Evangelist here. Unfortunately I was unable to reproduce this problem, but if you are continuing to run into issues please e-mail help#twilio.com so we can dig a bit deeper into your account and figure out what is going on.
Related
My Post is about Minecraft and its multiplayer servers. I will mention often the information, which is given on this website : https://wiki.vg/Protocol#Login_Start . So, my question is quite a bit complicated I guess. Please take care, that I´m not yet very familiar with Streams. I want to create my own "Chatbot" for Minecraft, which is able to join on every Server without opening the Minecraft launcher. But therefor my programm must receive and send packets.
I know about the protocol, which I mentioned above. In generell, there are 2 big steps of joining on a Server. The first is, to send a handShake and "ping-pong" to make a connection. The second step, probably the most complicated one, is to authenticate my account on this Server. I´m supposed to send certain information to the server and get some information back. Of course, I use DataInput/DataOutputStreams for sending and receiving. Now the protocol above plays a major role, because it says what I have to send to the server and in which form.
Java sending handshake packets to minecraft server
The post above was very usefull for the first step, to create a connection! In fact, somebody has made a lot of effort for this post, so I dont want to copy his code for my post. Please remember, that I used his code in my Project, so every line is the same (And his code works very well!). So, now you know everything about my situation, I ask the question how to send / receive packets with the information required to authenticate my client.
Hopefully you understood what i wanted to ask. Thanks for your time !
I'm not sure how much detail you're expecting from me, but all the packets you need to send to the minecraft server & the requests to mojangs authserver are outlined here.
As for the question & code you referenced, that's currently sending a handshake packet with nextstate set to 1 (status) which is only used for pinging the server, not connecting to it. You'll need to set that to 2 (login) & follow the sequenced outlined in the link above instead of just sending a request & ping packets.
Using Twilio for Java, I want to know the process on how to be able to make our Call Client application receive calls from an Incoming call to a Twilio Number.
Whereas each "Call Client" is a web browser.
What are the steps to achieve this?
What is required in the web browser-based application to be able to receive calls?
What is the strategy to be able to "map" a Twilio Worker into a specific browser?
Twilio developer evangelist here.
What you want here is a combination of TaskRouter and Twilio Client.
TaskRouter will take care of queuing calls and routing them to available agents. Twilio Client will let you take calls in the browser.
To understand this better, I recommend you first go through this TaskRouter tutorial, followed by the Twilio Client JavaScript quickstart and that should give you enough to put the two together and take your TaskRouter routed calls in the browser.
One further thing, if you are looking to build out some sort of contact centre where agents can take calls in the browser and hook into other services, you might want to consider Twilio Flex which can do all of this out of the box for you and then gives you the flexibility to extend the way you want to.
Let me know how you get on.
A previous question asked how to dial from a web browser. Fair enough, but how do I dial a number from a soft-phone, like Jitsi, or an IP phone?
I would have to build an app for that purpose, using the client?
Oddly, incoming calls require almost no configuration for an IP phone and dialing from the API is fairly easy.
Think what you're looking for is SIP.
https://www.twilio.com/docs/api/twilio-sip/sending-sip-how-it-works
Making outbound and inbound calls using SIP domain
Using Asterix as an example, the call flow from 5000#example.sip.com(SIP endpoint) to alice#example.sip.us1.twilio.com should look like this:
SIP End point ----> YOURNAME(Asterix PBX) ----> Internet -----> Twilio cloud ----> SIP domain(example.sip.us1.twilio.com) -----> alice
Now once the call reaches alice, web hooks can be used to make the necessary modifications as per individual use case.
You can also use this concept to make an outbound call so lets say alice.example.sip.us1.twilio.com calls 5000#example.sip.com this can be achieved by using <SIP> which is a part of the <Dial> verb in TwiML.
Making outbound and inbound calls using SIP Trunking
Check out the getting started guide here.
The way SIP trunking works is best understood by the analogy of a pipe. You can route your calls towards the Twilio cloud (termination) or from Twilio cloud towards your infrastructure (origination). You also would need to set up an IP access list or credential list for security purposes.
Please let me know if this helps at all.
I have a web-service on my server that pushes the xml data to the clients that are communicating to it over internet.
In these cases we have challenge to receive acknowledgement from the
client.
Specific case like, once client has received the data and before
sending the acknowledge, if the communication channel goes down.
Example:
In case of the software updates on clients over internet, how the server makes sure every thing is processed fine.
If you want to go on the "push" path, and you absolutely must know if the update was succesful, then you have to build your service and clients in such a way that you do know.
Basically what you need to do is build a small protocol so that information is transmitted no matter the failures of the communication channel. This means two things:
Your service does re-transmissions;
Your clients can deal with duplicate messages;
For example:
service pushes a message, client acknowledges => all good;
service pushes a message, the connection goes down, the message is lost. The client does not acknowledge since it never got the message => service pushes that same message once again at some later time. Now hopefully you get to case 1.
service pushes a message, client acknowledges but the connection fails and the service does not receive the acknowledge => similar to 2, so the service pushes that same message once again some later time and now the client receives the same message twice. It must ignore the second message but still needs to send an acknowledge so the service does not send it a third, forth, ... nth time;
And so on and so forth...
This is a high level description of what TCP does, for example. TCP is a reliable protocol over an unreliable network. It handles dropped packets, duplicated packets, etc.
Now, that would be pushing. A more simple alternative would be to use "pull" instead. The clients periodically pull the updates from the server. This is simpler to implement (the download is succesful if it worked, otherwise you try again later) but it's not without its gotchas, like for example:
controlling when clients start to pull data from the service. You can't just have them all update at the same time or you might overload the server. Clients should first ask the server if it's OK to update now or comme back later when the service is not so busy;
are you downloading upgrades in the background, from user devices? Data charges might apply so maybe it's better to ask the user if it wants the update now or later instead of doing it behind the scenes;
updating in the background, even if there is no problem with data charges might still consume bandwith when the client needs that bandwith for something else;
And so on and so forth...
The thing is this is a large topic, with general solutions that might not apply given particular situations. But it is not a new topic. Others have had these issues before. Consider for example Windows updates, how each PC's OS updates itself. Something similar happened a while ago when thick clients needed updates. The world moved to thin clients but now thick clients are making a comeback. Have a look at how these issues are solved, you will find usefull information online.
I do not think there is a way to do that. I believe the reason you are asking is for the following reasons:
1) If you are asking because you are sending a lot of data and your client deny receiving it, perhaps you can paginate it. That way you will know when the last page was accessed. You can even go one step further and just put very little data on your last page, that way you are sure that the last page is called.
2) If you are genuinely concerned about ensuring that they receive the entire data. How about suggest they access a 2nd web service which contains the checksum for the data, and suggest that they compare it.
Assuming that your web service is RESTful, your server should be stateless. The client should make sure it receives the data properly.
You could define a service to get the hash value of the data, followed by the request to receive the data itself. The client can check after the download whether the hash value of the downloaded data corresponds to the value received by the first call.
Amongst others, you could use MD5, SHA-1 and SHA256 in standard Java, as described in the Oracle documentation. This will calculate the hash value of the data from the server side.
Assuming you use Javascript from the client side, there are many possibilities to calculate the hash code using the same algorithms (jsSHA, for example).
I hope it helps.
I'm developing a game both with sockets and RMI. The sockets part is done now i'm starting the RMI part. I want to be able to invite someone to play (A->B) and get the response(B->A).
Can you help me?
Thanks in advance. Cheers
EDIT : I've been researching and i'm currently implementing the client as a remote object as well (defining the interface and implementing it). I think it's called callback. Am I on the right path?
What i'm thinking is A calls a method on a remote object on B's computer. The server on B asks the client (which is also a server in the same computer) if it wants to play with A gets the response and returns it to A. Like i said i just finished implementing this game with tcp and udp sockets and now i have to do the same with RMI. There is no way for two clients to communicate directly, like they do over a TCP connection, using RMI, is there?
I've been researching and i'm currently implementing the client as a remote object as well (defining the interface and implementing it). I think it's called callback. Am I on the right path?
RMI is usually implemented as a client and a server. The client makes calls on the server which returns an object that can be consumed on the client. After reading the comments, they are correct that given the way you have described the problem, you will need to make the client also a RMI server. However, I'm not convinced this is necessary.
For example, let's say you have 2 clients that are both trying to play a game. The protocol might look something like this:
A contacts the server S. Server stores the address A and then returns a waiting-for-another-player type message to A.
A then contacts S every couple of seconds to see if the other player has shown up.
B then contacts S and a game is started between A and B. S returns a start-game message to B. S stores some sort of Game object in its memory (and/or on disk) which tracks the progress of the game.
The next time A contacts the server it also gets a start-game message.
So instead of the server needing to contact A or B, they poll every so often to get game updates and the like.
The method calls to S could also wait for the other player and not return until there is one. I think the polling option is better however because then S knows if A stops calling and A doesn't have to worry about S crashing and hanging.
Hope this helps.