What is SIP?

Phone systems from different vendors need a shared way to agree on a call.

SIP does not carry media, and that boundary explains why a connected call can have no audio.

What does SIP actually do?

It gets two parties to agree that a session should happen, and on what terms.

RFC 3261, the June 2002 specification that defines it, describes SIP as "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". The document lists the five jobs it takes on:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

The five jobs do not include audio. They cover finding the far end, deciding whether it will take the call, agreeing on codecs, ringing, and later hanging up or transferring. That is the whole remit.

Why is my call connected with no audio?

Because the audio was never SIP's to carry, and the two paths can fail independently.

The specification is explicit about its own scope:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

Media travels over the Real-time Transport Protocol (RTP), negotiated during setup and then flowing on its own, frequently between endpoints that the signalling never touched. The signalling can complete and both sides can agree that a session is active. Audio can still fail to arrive because a firewall, a network address translator or a routing rule between the media endpoints dropped it while leaving the signalling untouched.

This is why one-way audio and no audio are their own diagnostic category rather than a variety of call failure. The call log will show a connected call because a connected call is exactly what the signalling achieved. Voice troubleshooting works through the symptoms, and Bird's own test-call tool prints a peak-audio summary for each direction for this reason, where a zero on one side is the one-way-audio symptom stated as a number.

The same separation is what lets other things slot in cleanly. RFC 3261 puts it as "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." Voicemail, hunt groups, call recording and an AI agent are all built on the primitives rather than defined by the protocol.

Do I have to register a client before it can call?

No. Bird trunks authenticate calls without client registration.

SIP does define a registration function, which is how a user agent tells the network where it can currently be reached. It is what makes a desk phone findable when someone dials an extension. But registering and placing a call are separate acts, and a system that only originates calls never needs to be findable.

Bird authenticates each SIP INVITE method that requests a call against the trunk's IP allow list or through a password challenge, and clients do not register with the trunk. Configure Bird as a trunk rather than as a registered account: no type=registration section in Asterisk, register=false on a FreeSWITCH gateway, registration set to none in FreePBX or 3CX. Where a softphone offers no way to turn registration off, the failing registration attempt is cosmetic and dialling still works, because the platform acts on the invitation rather than on the registration. SIP client setup has the worked configurations.

The corollary is where the credentials go. Your client sends two different identities: the caller ID in the From header, which has to be a number you have verified, and the digest username, which is bird on every trunk. Putting the caller ID in the authentication field causes an authentication error rather than an error that mentions caller ID.

Why do the responses look like HTTP?

Because the protocol was designed to, down to the number ranges.

SIP is a text-based request and response protocol with methods and headers, and its responses come back in the same six classes with the same familiar numbers: a 404 for a destination that does not exist, a 486 for a busy end system. The shared structure lets you read a SIP trace much as you would read an HTTP one.

There are two exceptions. A sixth class, 6xx, has no HTTP equivalent and means no server anywhere can fulfil the request rather than merely this one. One common code also carries a meaning on Bird that the standard does not describe. What do SIP response codes mean covers both, including why a 503 from Bird is usually a refusal it declines to explain on the wire rather than an overload.

Where do I meet SIP on Bird?

At the trunk, which is the address your equipment sends to.

Each trunk has a fixed SIP domain and accepts UDP or TCP on 5060, or TLS on 5061 where you want the signalling encrypted in transit. What may send to it is yours to decide, and a new trunk accepts nothing until you say so. What is a SIP trunk covers that decision and the three mechanisms behind it, and what is a voice API covers how the SIP half and the HTTP half divide the work.