canmove, Confirmed users, Bureaucrats and Sysops emeriti
3,628
edits
No edit summary |
|||
| Line 63: | Line 63: | ||
Note: Needing to re-authentify the user to connect is an error. Having to login on the service provider's website shouldn't be required each time the browser is restarted. | Note: Needing to re-authentify the user to connect is an error. Having to login on the service provider's website shouldn't be required each time the browser is restarted. | ||
== | == Call Handling == | ||
Messages that handle calls, can go two ways from the Worker to the SPA and vice-versa. | |||
To send a message to the worker (e.g. incoming call): | |||
postMessage({topic: <topic>, data: <data>}) | |||
{topic: | |||
Receiving a message from the worker (e.g. call outgoing), listen for message of structure: | |||
{topic: topic, data: <data>} | |||
== | === Call Handling Data Structures === | ||
These are the data structures associated with calls | |||
* <code><peer></code> is a string which is the id of the peer that the call is with. | |||
{topic: "hangup", data: {peer: | |||
* <code><call id></code> contains the call id for a single call sequence. | |||
** This is used to ensure that messages from one call with a peer don't affect other calls/actions with the same peer. | |||
** Currently, sending a new call id for a call with a peer does not force a new call to be started. | |||
* <code><session desc></code> is a serialized object equivalent of [http://www.w3.org/TR/webrtc/#rtcsessiondescription-class RTCSessionDescription] | |||
** Type will be <code>offer</code> for an incoming call offer, and <code>answer</code> for a response to an offer. | |||
{ type: "answer", sdp: "v=0\r\no=Mozilla-SIPUA..."} | |||
* <code><ice candidate></code> is a serialized object equivalent of [http://www.w3.org/TR/webrtc/#rtcicecandidate-type RTCIceCandidate] e.g. | |||
{candidate: "candidate string", sdpMid: "media stream id", sdpMLineIndex: 2} | |||
=== Call Flows === | |||
==== Users Receives a Call ==== | |||
Send from the SPA to Talkilla: | |||
{topic: "offer", data: {peer: <peer>, offer: <session desc>, callid: <call id>}} | |||
When the user answers, Talkilla will post the following to the SPA: | |||
{topic: "answer", data: {peer: <peer>, answer: <session desc>, callid: <call id>} | |||
==== User Places a Call == | |||
Talkilla sends to the SPA: | |||
{topic: "offer", data: {peer: <peer>, offer: <session desc>, callid: <call id>}} | |||
When the other end answers, the SPA will send to Talkilla: | |||
{topic: "answer", data: {peer: <peer>, answer: <session desc>, callid: <call id>} | |||
Talkilla will time out call offers after 30 seconds, at this time a call hangup is sent (see below). | |||
==== Ending a Call ==== | |||
Either Talkilla or SPA can send a message: | |||
{topic: "hangup", data: {peer: <peer>, callid: <call id>}} | |||
== Handling ICE Candidates == | == Handling ICE Candidates == | ||
Firefox is capable of [http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00 Trickle ICE]. After an initial call offer or answer, there may be additional ICE candidates. Hence these may be sent from either side. | Firefox is capable of [http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00 Trickle ICE]. After an initial call offer or answer, there may be additional ICE candidates. Hence these may be sent from either side. | ||
ICE candidates may be sent from either Talkilla to the SPA or vice-versa depending on which part of the call they are coming from: | |||
{topic: "ice:candidate", data: {peer: <peer>, candidate: <ice candidate>}} | |||
When the ICE candidate list is complete, a message with a <code>null</code> data value will be passed | When the ICE candidate list is complete, a message with a <code>null</code> data value will be passed: | ||
{topic: "ice:candidate", data: {peer: <peer>, candidate: null}} | |||
{ | |||
=Data Channel API Documentation= | =Data Channel API Documentation= | ||
This is still being defined | This is still being defined | ||