SIP
SIP sets up, changes and tears down calls. It is a text protocol that looks like HTTP and carries no audio at all — it negotiates where the audio will go, and RTP carries it separately. Connect uses SIP in two places: the inbound trunk that delivers realtime calls, and the browser softphone, which registers over SIP inside a WebSocket.
A call as a request and a response#
SIP borrows its shape from HTTP: a method, a target URI, headers, an optional body, and numeric responses grouped by first digit. A minimal call is an INVITE, a 180 Ringing, a 200 OK when the far end answers, an ACK, and a BYE from whichever side hangs up.
INVITE- Start or modify a session. Carries a session description offering codecs and a media address.
ACK- Confirms the final response to an INVITE. Its absence is a classic cause of a call that answers and immediately drops.
BYE/CANCEL- End an established call; abandon one that never answered.
REGISTER- Tell a registrar where a user can currently be reached, for a stated duration.
OPTIONS- A keep-alive and capability probe, often the thing that holds a NAT binding open.
REFER/INFO- Ask the far side to place a call elsewhere; carry mid-call information such as digits.
Responses run 1xx provisional, 2xx success, 3xx redirect, 4xx client failure — including 401 and 407 challenges, which are normal and expected on the first attempt — 5xx server failure and 6xx global failure. A 486 Busy Here and a 503 Service Unavailable mean very different things about whose problem it is.
Signalling and media are separate on purpose#
The INVITE carries a session description: which codecs the caller supports, and the address and port where it wants to receive audio. The answer comes back in the 200 OK. Once both sides have offered and answered, audio flows directly between the media addresses as RTP, which may take an entirely different network path from the signalling.
This split explains the two most common symptoms in SIP deployments. A call that connects and has no audio is a media problem — the signalling worked perfectly. A call that never connects at all is a signalling problem, and no amount of audio debugging touches it.
Registration versus trunking#
| Registration | Trunk | |
|---|---|---|
| Who initiates | The endpoint, repeatedly | Neither; the peering is standing |
| Identified by | Credentials, refreshed on a timer | Usually an IP address or a credential on the peer |
| Suits | Endpoints that move — a browser, a handset, a laptop | System-to-system links with a fixed address |
| Fails as | A binding that quietly expires; the device rings nowhere | A call that is delivered to an address nothing answers on |
A registration is a binding with an expiry, refreshed before it lapses. Nothing warns you when it stops being refreshed, which is why a softphone should derive every state it displays from actual SIP events rather than from the fact that a user clicked something.
Does Connect use SIP?#
Yes, in two distinct places, and neither is visible to a caller.
The realtime inbound path. The business number is linked at the carrier to an inbound trunk whose origination URI is the media platform's SIP host — given as host:5060, with no sip: prefix — and a dispatch rule spawns the voice worker on the room the call arrives in. Linking a number to a trunk is done in the carrier's console.
The browser softphone. A person's line registers over SIP inside a WebSocket using a per-person endpoint whose password is generated, stored encrypted, served only to its owner and individually revocable. Two consequences are worth knowing: the content security policy must name the SIP WebSocket address or the line silently never registers, and an endpoint that registers successfully but is not attached to the voice application can never place a call — because the carrier does not dial the number in the browser's INVITE. It posts to the application's answer URL, with the direction marked outbound, and does whatever that document says.
Questions#
The call connects but nobody can hear anything. Where do I look?
At media, not signalling. Signalling succeeded — that is what 'connects' means. Check the addresses and ports in the session description, whether one side is behind NAT and sending to an unreachable address, and whether a firewall is permitting the negotiated media range at all.
Why does my first SIP request get a 401?
Because challenge-response authentication is the normal flow: the first attempt is unauthenticated, the server challenges with a nonce, and the client repeats the request with credentials computed against it. A client that treats the challenge as a failure never authenticates at all.
Is SIP over WebSocket different from SIP?
It is the same protocol carried over a WebSocket connection so a browser can speak it, since browsers cannot open raw UDP sockets. The methods and responses are unchanged; what changes is the transport, and with it the need for the page's content security policy to permit that connection.