Yeti Switch

Appearance

WebRTC ​

Yeti-Switch is able to act as a WebRTC gateway.

Prerequisites ​

This part is out of scope of this document. You have to complete the following steps yourself:

  1. Yeti Load balancer should be installed and properly configured.
  2. WS/WSS transport should be enabled on the load balancer. his includes domain name A/AAAA record configuration and proper TLS certificate installation.
  3. SRTP should be enabled in SEMS configuration.

Gateway configuration ​

From Yeti's point of view, a WebRTC client is the same as any other SIP stack, so the configuration logic is the same: a gateway and customer auth should be created to process incoming calls and send outgoing calls. The only difference is that specific mechanisms should be enabled for WebRTC gateways:

Registered AoR Mode
Usually WebRTC clients have no static IP, so SIP Registration mechanism should be used to deliver calls from Yeti to WebRTC client. Should be Use AOR as is or Use AOR, replace userpart with dst number.
Media Encryption Mode
Should be SRTP DTLS
ICE Mode
Should be Initiate
RTCP Mux Mode
Should be Initiate
RTCP Feedback Mode
Should be Initiate

Read more about such settings in Gateway documentation

Username/passwords Authentication ​

Since WebRTC clients usually have no static IP, you have to use additional authentication mechanisms like username/password authentication.

WARNING

Usually, the WebRTC media stack is used in pair with a SIP stack working over WebSocket transport. In most cases, this is a JS-based stack like JsSIP or SIP.js running in the end-user browser. It is not safe to share long-term usernames and passwords with such clients, so we recommend using short-term JWT tokens for authentication.

Short-term tokens Authentication ​

With this mechanism, Yeti expects the SIP client to include an Authorization header with a JWT token signed by a trusted private key in all initial INVITE and REGISTER requests.

Example:

Authorization: Bearer <token>

To enable this mechanism for gateways, just set the incoming_auth_allow_jwt flag in the gateway settings.

INFO

JsSIP SIP stack has built-in support for this mechanism. Read more about parameter_authorization_jwt

To generate JWT tokens, you may use your own service or use the Yeti Customer API, which provides a resource for this.

Call routing ​

  • Incoming call routing works as usual - call will be authenticated by customer auth matching logic, then routing will be done according to routing plan.
  • Outgoing call routing works as usual - just create Dialpeer with MS Teams gateway and Yeti will send call to proper trunk.