Skip to main content
While some differences exist between the JS SDK and the mobile SDKs, they follow a similar client lifecycle and call flow. The JS SDK demo app is used here as it’s far easier to set up the application (just load up webrtc.telnyx.com) and perform debugging using browser tooling.

Overview

The SDK does two main things:
  • Establishes an active websocket connection to send and receive signaling messages to and from rtc.telnyx.com.
  • Establishes a media session for a call
To achieve the above, it employs the following suite of APIs:

Client Instantiation & Authentication

  1. Go to webrtc.telnyx.com
  2. Right click; Inspect; Select Network tab and filter WS traffic
  3. Follow this page to successfully register the demo app.
In the browser, the following sequence of JSON-RPC messages is observed. Message 1: client → rtc.telnyx.com
Message 2: rtc.telnyx.com → client
Message 3: rtc.telnyx.com → client
Message 4: client → rtc.telnyx.com
Message 5: rtc.telnyx.com → client
The above interaction is caused by the demo app instantiating and connecting the SDK client.
At a high level, when the client is instantiated, it… Invoking the connect method on the SDK client …
  • Initiates a WebSocket connection to rtc.telnyx.com
  • Once the socket is open, the login message is sent to rtc.telnyx.com.
At this point, Message #1 and #2 are observed. Message #3, #4, and #5, is the result of the logic here
  • A telnyx_rtc.clientReady event from rtc.telnyx.com triggers a telnyx_rtc.gateState query from the SDK client
  • A REGED event from rtc.telnyx.com bubbles up as telnyx.ready.
At this point, the SDK client is authenticated to make or receive a call.

Call Initiation

  1. In another tab, open chrome://webrtc-internals/
  2. Fill in “Call destination” with +18008648331 (United Airlines IVR)
  3. Click “Call”
In the browser, the following sequence of JSON-RPC messages is observed. Message 1: client → rtc.telnyx.com
Message 2: rtc.telnyx.com → client
Message 3: rtc.telnyx.com → client
Message 4: client → rtc.telnyx.com
Message 5: rtc.telnyx.com → client
Message 6: client → rtc.telnyx.com
Message 7: rtc.telnyx.com → client
Message 8: client → rtc.telnyx.com
At this point, the media will flow. All of the above interaction is the result of the following SDK API call.
Under the hood, the SDK performs many steps before Message #1 (INVITE) is even sent. Broadly speaking, the following are the essential steps with the relevant data picked out from the JSON dump.
  1. RTCPeerConnection is instantiated.
  2. getUserMedia is invoked to obtain user’s permission for audio and eventually the MediaStream
  1. addTransceiver is invoked to add the local stream to the sender of the RTCPeerConnection.
  1. The previous step triggers the negotiationneeded event.
  1. In the event handler, the SDK invokes createOffer.
  1. This API call will eventually create a RTCSessionDescription with information on the local media stream.
  1. The SDK will then invoke the setLocalDescription to set the SDP of the client peer.
  1. Concurrently, createOffer also kicks off the ICE candidate gathering.
  1. When all is done, icecandidate event triggers with candidate = null to indicate the process is completed. Subsequently, the existing local SDP parameters are augmented with the ICE candidates.
  2. At this point, all necessary info are present to send the invite to rtc.telnyx.com.
  3. As a result, on the websocket, Message #1 through #4 are observed.
  4. At Message #5, rtc.telnyx.com sends over its SDP in the telnyx_rtc.media events.
  5. Upon receipt of this message, the SDK invokes setRemoteDescription to set the SDP of the remote peer.
  1. Finally, two peers of the RTCPeerConnection are fully identified. connectionState changes from connecting to connected.
  1. Media will flow over UDP.