Talkilla/SPA API: Difference between revisions

Jump to navigation Jump to search
no edit summary
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.


==Receiving a call==
== Call Handling ==
postMessage({topic: "offer", data: {peer: "+16501231234", offer: {type:"offer", sdp:"v=0\r\no=Mozilla-SIPUA..."}}});


Talkilla will either reply with an 'answer' message:
Messages that handle calls, can go two ways from the Worker to the SPA and vice-versa.
event.data contains
{topic: "answer", data: {peer: "+16501231234", answer: {type:"answer", sdp:"v=0\r\no=Mozilla-SIPUA..."}}}


or reject the call: (not implemented yet)
To send a message to the worker (e.g. incoming call):
event.data contains
{topic: "reject", data: {peer: "+16501231234"}}


==Placing a call==
  postMessage({topic: <topic>, data: <data>})
event.data contains
  {topic: "offer", data: {peer: "+33615827492", offer: {type:"offer", sdp:"v=0\r\no=Mozilla-SIPUA..."}}}


The SPA can reply with an "answer" or "reject" message.
Receiving a message from the worker (e.g. call outgoing), listen for message of structure:
postMessage({topic: "answer", data: {peer: "webrtc@mailinator.com", answer: {type:"answer", sdp:"v=0\r\no=Mozilla-SIPUA..."}}});


"reject" is not implemented yet.
{topic: topic, data: <data>}


==Ending a call==
=== Call Handling Data Structures ===
Either the SPA or Talkilla can send a 'hangup' message:
 
From the SPA:
These are the data structures associated with calls
  postMessage({topic: "hangup", data: {peer: "+16501231234"}});
 
From Talkilla: event.data contains
* <code><peer></code> is a string which is the id of the peer that the call is with.
  {topic: "hangup", data: {peer: "+16501231234"}}
 
* <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.


From the SPA:
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:
postMessage({topic: "ice:candidate", data: {peer: "+16501231234", candidate: <candidate>}});


From Talkilla: event.data contains:
{topic: "ice:candidate", data: {peer: <peer>, candidate: <ice candidate>}}
  {topic: "ice:candidate", data: {peer: "+16501231234", candidate: <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:


<code><candidate></code> is an object containing parameters with values matching the [http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcicecandidate-type RTCIceCandidate] e.g.
  {topic: "ice:candidate", data: {peer: <peer>, candidate: null}}
 
  {candidate: "candidate string", sdpMid: "media stream id", sdpMLineIndex: 2}


=Data Channel API Documentation=
=Data Channel API Documentation=
This is still being defined
This is still being defined
canmove, Confirmed users, Bureaucrats and Sysops emeriti
3,628

edits

Navigation menu