Wat is SIP?

Telefoonsystemen van verschillende leveranciers hebben een gedeelde manier nodig om een gesprek overeen te komen.

SIP draagt geen media, en die grens verklaart waarom een verbonden gesprek geen audio kan hebben.

Wat doet SIP precies?

Het zorgt dat twee partijen overeenkomen dat een sessie moet plaatsvinden, en op welke voorwaarden.

RFC 3261, de specificatie van juni 2002 die het definieert, beschrijft SIP als "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". De vijf taken zijn het vinden van de andere kant, beslissen of die het gesprek aanneemt, overeenstemming over de media, laten overgaan, en later ophangen of doorverbinden. De specificatie somt ze op als:

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.

Geen van de vijf is het dragen van de audio. Dat is het volledige mandaat.

Waarom is mijn gesprek verbonden zonder audio?

Omdat de audio nooit de taak van SIP was, en de twee paden onafhankelijk kunnen falen.

De specificatie is expliciet over zijn eigen reikwijdte:

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 loopt over RTP, onderhandeld tijdens de opzet en daarna zelfstandig stromend, vaak tussen eindpunten die de signalering nooit heeft geraakt. De signalering kan afronden en beide kanten kunnen het erover eens zijn dat een sessie actief is. Audio kan toch niet aankomen omdat een firewall, een netwerkadresvertaler of een routeringsregel tussen de media-eindpunten het heeft laten vallen terwijl de signalering ongeraakt bleef.

Daarom zijn eenrichtingsaudio en geen audio een eigen diagnostische categorie in plaats van een variant van gespreksfouten. Het gesprekslog toont een verbonden gesprek omdat een verbonden gesprek precies is wat de signalering heeft bereikt. Probleemoplossing voor spraak werkt de symptomen door. De eigen testgesprek-tool van Bird drukt een piek-audiosamenvatting af per richting, waarbij een nul aan één kant het eenrichtingsaudio-symptoom is uitgedrukt als getal.

Diezelfde scheiding maakt dat andere dingen er naadloos op aansluiten. RFC 3261 formuleert het als "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." Voicemail, hunt groups, gespreksopname en een AI-agent zijn allemaal gebouwd op de bouwstenen in plaats van gedefinieerd door het protocol.

Moet ik een client registreren voordat die kan bellen?

Nee. Bird-trunks authenticeren gesprekken zonder clientregistratie.

SIP definieert wel een registratiefunctie, waarmee een user agent het netwerk vertelt waar hij momenteel bereikbaar is. Het is wat een bureautelefoon vindbaar maakt wanneer iemand een toestelnummer belt. Maar registreren en bellen zijn aparte handelingen, en een systeem dat alleen gesprekken initieert hoeft nooit vindbaar te zijn.

Een SIP INVITE is de methode die een gesprek aanvraagt. Bird authenticeert elk gesprek tegen de IP-allowlist van de trunk of via een wachtwoorduitdaging. Clients registreren zich niet bij de trunk. Configureer Bird als trunk in plaats van als geregistreerd account: geen type=registration-sectie in Asterisk, register=false op een FreeSWITCH-gateway, registratie op none in FreePBX of 3CX. Als een softphone geen manier biedt om registratie uit te schakelen, is de mislukte registratiepoging cosmetisch en bellen werkt gewoon, omdat het platform reageert op de uitnodiging in plaats van op de registratie. SIP-clientconfiguratie bevat de uitgewerkte configuraties.

Het gevolg is waar de inloggegevens naartoe gaan. Je client stuurt twee verschillende identiteiten. Het beller-ID staat in de From-header en moet een nummer zijn dat je hebt geverifieerd. De digest-gebruikersnaam is bird op elke trunk. Als je het beller-ID in het authenticatieveld zet, krijg je een authenticatiefout in plaats van een fout die beller-ID noemt.

Waarom lijken de antwoorden op HTTP?

Omdat het protocol zo is ontworpen, tot en met de nummerbereiken.

SIP is een tekstgebaseerd request-en-responseprotocol met methoden en headers. De antwoorden komen terug in dezelfde zes klassen met dezelfde vertrouwde nummers, een 404 voor een bestemming die niet bestaat en een 486 voor een bezet eindsysteem. De gedeelde structuur laat je een SIP-trace lezen vrijwel zoals je een HTTP-trace zou lezen.

Er zijn twee uitzonderingen. Een zesde klasse, 6xx, heeft geen HTTP-equivalent en betekent dat geen enkele server het verzoek kan afhandelen, niet alleen deze. Eén veelvoorkomende code heeft op Bird ook een betekenis die de standaard niet beschrijft. Wat betekenen SIP-antwoordcodes behandelt beide, inclusief waarom een 503 van Bird meestal een weigering is die het platform niet toelicht op de lijn in plaats van een overbelasting.

Waar kom ik SIP tegen op Bird?

Bij de trunk, het adres waarnaar je apparatuur stuurt.

Elke trunk heeft een vast SIP-domein en accepteert UDP of TCP op 5060, of TLS op 5061 als je de signalering onderweg versleuteld wilt. Wat er naartoe mag sturen bepaal je zelf, en een nieuwe trunk accepteert niets totdat je dat aangeeft. Wat is een SIP-trunk behandelt die keuze en de drie mechanismen erachter. Wat is een voice-API behandelt hoe de SIP-helft en de HTTP-helft het werk verdelen.