Architecture
Blendlix Call Service separates business authorization from realtime calling. The application backend decides whether a call is allowed. Blendlix Call Service manages short-lived call sessions, signaling, presence, and call state.
Application Client
|
v
Application Backend
|
v
Blendlix Call Service
|
+-- WebSocket signaling
|
+-- WebRTC session setup
|
v
Peer-to-peer audio
Layer responsibilities
| Layer | Responsibility |
|---|---|
| Application client | Shows call UI, requests a call token from its backend, connects to WebSocket, captures microphone audio, and creates the WebRTC peer connection. |
| Application backend | Authenticates the user, checks whether the caller can call the receiver, requests a session token, and returns safe connection data to the client. |
| Blendlix Call Service | Validates product credentials, issues short-lived session tokens, authenticates WebSocket clients, routes signaling events, tracks call state, and returns ICE server settings. |
| WebSocket signaling | Delivers call invite, accept, reject, cancel, end, and WebRTC signaling messages between authorized participants. |
| WebRTC audio | Sends encrypted audio directly between participants where possible, using STUN/TURN for connectivity. |
Why this design
This architecture keeps permissions inside the application backend while keeping realtime call infrastructure reusable across many applications.
- Business rules stay in the application that owns the user, account, and context.
- Clients only receive short-lived call tokens.
- Product credentials stay on the application backend, never in the client.
- WebSocket handles realtime signaling.
- WebRTC handles low-latency audio.
- TURN/STUN improves connection success across different networks.
Important boundary
Blendlix Call Service does not decide application business rules. It trusts the application backend to request tokens only after checking permissions.
Examples of checks that belong in the application backend:
- whether the caller is logged in
- whether the receiver belongs to the same conversation, task, booking, session, or workflow
- whether the call context is still active
- whether calling is enabled for the organization
Recommended call flow
1. Client asks application backend for a call session.
2. Application backend checks permissions.
3. Application backend calls Blendlix Call Service with product credentials.
4. Blendlix Call Service returns a short-lived token, WebSocket URL, and ICE servers.
5. Client connects to WebSocket using the token.
6. Caller sends call.invite.
7. Receiver accepts or rejects.
8. Participants exchange WebRTC offer, answer, and ICE candidates.
9. Audio flows through WebRTC.
10. Either participant ends the call.