intercomconf.com from the desktop browser, in the lower right corner Pavlik “wakes up” in the form of a chat and offers to play a game. Enter the number, click "Here is my number" - after that Pavel raises the session between your browser and our backend.
 
 

 
 
If everything has successfully risen and your number has not yet participated in the drawing, then Pavel will offer to call 8-800. Here the Voximplant cloud is already entering and the quiz starts:
 
 

 
Answer: deadline /deadline. The basis taken meme 3r340. This is fine
.
 
 
Yes, the puzzles were like this. Three attempts were made for each question: first there was a “complex” picture, then simpler and at the end the simplest. The first attempts gave the most points; after 5 puzzles, Pavel counted up the points and either gave a free ticket or a 10% -30% discount.
 
 
At the same time, our reptiloid is smart enough: it gave error messages (if you entered the phone number incorrectly, for example), determined that the number was already participating in the drawing (“I see the familiar number on the screen of my non-existing mobile phone. One attempt in one hand - these are the rules. ") And, most importantly, correlated the browser and the cloud. How did this bold IVR work?
 
 

In the mouth
madness
Reptiloid

 
3r361.
 
Answer: call center. Nuff said.
 
 
Speaking dryly, Paul 2.0 is an IVR running in our cloud. Therefore, all reptiloid logic should be spelled out in a JS script, right? Yes, but no.
 
 
The second version of Pavel is synchronized with the client’s browser: Pavel shows the rebuses on the website, and he hears your answers on the phone, depending on which pictures are replaced and the result is displayed. At first glance, such an interaction could be realized with the help of our HTTP API 3r35757. :
 
 
first, the browser would run the script using the 3r3381 method. StartScenarios . In response, the method gives the parameters media_session_access_url and media_session_access_secure_url which contain URLs for HTTP and HTTPS, respectively;
 
a running script could be communicated using the obtained URLs;
 
the script would tell the browser which pictures to use and update the score using the 3r3-300 method. httpRequestAsync
.
 
 
But how to "catch" a custom browser? Indeed, in 3r3-300. httpRequestAsync
You must pass a unique URL. And yes, pictures - they also need to be stored somewhere.
 
 
Therefore, in addition to the cloud JS-script, we used our backend on express.js paired with socket.io : when the visitor entered the number, the browser gave this number to the http http, after which the http session turned into a session on web sockets. As a result, the script constantly communicated with the backend via http, and already the backend used web sockets to quickly transfer pictures and points to the browser.
 
 
In part of the web sockets, the backend looked like this: [/b]
3r3119.