Skip to main content

WebRTC Voice SDKs Fundamentals

What & Why ​

These SDKs enable client-side applications to instantiate and control a Telnyx call leg.

As a result, developers of applications integrated with Telnyx voice platform are no longer constrained to working with inflexible and uncustomizable SIP UAs such as PBX, Asterisk, Zoiper etc.

Instead they can embed native voice capabilities client-side to work seamlessly with their voice application and achieve end to end visibility and control of the user experience.

How ​

These SDKs

  • Utilize the native client-end (browser or device) WebRTC API for cross browser/device compatibility, …
  • Adhere to the WebRTC standardization where Media is transported via RTP over DTLS, aka SRTP, aka DTLS-SRTP, … and
  • Implements the WebRTC session negotiation, aka signaling, via JSON-RPC messages over Secure WebSocket (WSS).

Availability ​

The following SDKs are offered

Common Usage Patterns ​

Two common primitive patterns are presented below. They can be augmented or used in combination with each other to achieve the user’s desired call flows.

Pattern 1 ​

This pattern is driven by the client-end application.

  1. A client-end application (Web or Mobile App) initiates a call.
  2. The call is temporarily parked by Telnyx.
  3. Telnyx issues a webhook event to the user’s backend service.
  4. User’s backend service performs additional processing using Telnyx Voice API, TeXML, or Conferencing API.
  5. Depending on user’s business logic, second call leg may be initiated by the user’s backend and bridged to the initial call leg, or the initial call leg be put into a queue or conference until bridge to another call leg.

Pattern 2 ​

This pattern is driven by a call from outside the Telnyx network.

  1. Telnyx receives a call from outside the Telnyx network, e.g. PSTN.
  2. Telnyx processes the call via TeXML instruction or Voice API commands.
  3. That call leg is placed into a queue or conference room
  4. User’s backend service initiates a second call leg towards a client-end application
  5. The two call legs are eventually joined via bridge command or conference join