Převod SIP URI na IP adresu

V telefonních sítích se z historických důvodů pro identifikaci uživatele nebo telefonního přístroje používají čísla. Přesněji řečeno telefonní čísla. Protokol SIPⁱ, který je dnes nejpoužívanějším protokolem pro VoIPⁱ, však převzal adresní schéma z emailu. Ačkoliv to většina uživatelů VoIP telefonů ani netuší, při vytočení telefonního čísla jejich telefon vygeneruje adresu se zavináčem, podle které je pak nalezen příjemce hovoru. V tomto článku objasníme technické pozadí adres protokolu SIP.

SIP URIⁱ

SIPovým adresám se říká SIP URI a jsou definovány v RFC3261 (sekce 19.1). SIP URI se píše s prefixem sip:, například:

sip:hudba@telegro.cz
sip:franta.novak@skymia.cz

Emaily by se správně měly psát s prefixem mailto:, tj. například mailto:redakce@telegro.cz, ale v případě emailů se prefix obvykle vynechává. U SIP URI se naopak prefix uvádí právě proto, aby se nepletly s emailovými adresami.

Směrování SIP paketů je téma na sérii článků. V tomto se omezíme jen na jeden typický případ, a to je směrování paketu s metodou INVITE při pokusu o sestavení nového hovoru.

Představme si, že uživatel má v telefonním seznamu svého přístroje uloženou adresu sip:hudba@telegro.cz a zavolá na tuto adresu. Předpokládejme, že telefon nemá nastaven odchozí proxy server Outgoing proxy. V takovém případě se pokusí kontaktovat server, jehož jméno je za zavináčem volaného SIP URI, tj. telegro.cz.

Převod SIP URI na IP adresu

K odeslání INVITE paketu musí telefon nejprve převést jméno serveru telegro.cz na IP adresu. Převod je překvapivě komplikovaný proces popsaný v RFC 3263 a zatím málokterý telefon ho podporuje celý.

V tomto článku se budeme zabývat typickým případem, kdy je za zavináčem jméno domény bez čísla portu. Prvním krokem je vyhodnocení NAPTR záznamu pro doménu za zavináčem. V linuxu můžete vypsat NAPTR záznamy domény pomocí příkazu

host -t NAPTR telegro.cz

          order pref flags service   regexp replacemnt
 IN NAPTR  80   50   "s"   "SIPS+D2T" ""     _sips._tcp.skymia.cz.
 IN NAPTR 100   20   "s"   "SIP+D2U" ""     _sip._udp.skymia.cz.
 IN NAPTR 100   60   "s"   "SIP+D2T" ""     _sip._tcp.skymia.cz.
 IN NAPTR 150   50   "s"   "SIP+D2U" ""     _sip._udp.telegro.cz.

Odpověď na tento dotaz může obsahovat více záznamů (v tomto případě čtyři). Výše uvedená odpověď je smyšlená, ve skutečnosti dostanete v odpovědi jen jeden záznam SIP+D2U, to se týká i dalších příkladů. Každý záznam obsahuje tato pole:

order

order určuje pořadí zpracování záznamů. Telefon musí rozdělit záznamy do skupin se stejnou hodnotou order. Přitom vynechává záznamy, které se netýkají protokolu SIP (to se pozná podle pole service, viz dále). Následuje zpracování skupin v pořadí daném hodnotou order, od nejmenších hodnot až po největší. Pokud se na základě záznamů nějaké skupiny podaří navázat hovor, zpracování končí a další skupiny se nevyužijí.

pref

Preference. Mají-li dva záznamy stejnou hodnotu order, tj. patří do stejné skupiny, může si telefon vybrat podle hodnoty pref a service. Měly by být upřednostňovány záznamy s nejnižší hodnotou pref, ale telefon může udělat výjimku, pokud některý typ služby nepodoporuje dostatečně dobře. Zatímco order určuje pořadí zcela jednoznačně, pref dává telefonu určitou volnost.

flags

Pro záznamy týkající se SIPu je hodnota vždy "s", což znamená že výsledek NAPTR dotazu má být použit jako vstup pro SRV dotaz.

service

Jméno služby. Pro SIP je jméno služby vždy ve tvaru SIP+U2X, nebo SIPS+U2X, kde X označuje transportní protokol. Pro UDPⁱ se používá označení D2U, pro TCPⁱ označení D2T a pro SCTP se používá D2S.

regexp

Tato hodnota má být prázdná a nepoužívá se.

replacement

Doména použitá pro případný SRV dotaz.

V našem případě záznamy z domény telegro.cz tvoří tři skupiny s hodnotami order 80, 100 a 150. Pokud telefon nepodporuje SIPS, vynechá první záznam a bude se rozhodovat mezi _sip._udp.skymia.cz s preferencí 20 a _sip._tcp.skymia.cz s preferencí 80. Nepreferuje-li telefon z nějakých důvodů TCP před UDP, měl by se rozhodnout vyzkoušet záznam s nižší preferencí, tedy UDP, jako první. V případě, že použití _sip._udp.skymia.cz nebude úspěšné, měl by telefon vyzkoušet TCP variantu.

Mechanismus NAPTR slouží především k volbě transportního protokolu. Podle specifikace musí každý SIP Proxy umět SIPS+D2T, SIP+D2U a SIP+D2T, přičemž SIPS by měl být preferovaný způsob komunikace. V praxi se SIPS zatím příliš nevyužívá. Připomeňme, že Asteriskⁱ není SIP Proxy, ale User Agent, takže toto doporučení se ho netýká.

Po nalezení NAPTR záznamu se pole replacement použije pro SRV dotaz.

Neexistují-li pro doménu žádné NAPTR záznamy, sestaví telefon SRV dotazy na základě domény (telegro.cz) a protokolů, které podporuje (například SIP přes UDP a SIPS přes TCP). Vzniknou tak dva SRV dotazy _sip._udp.telegro.cz a _sips._tcp.telegro.cz. Telefon pak v pořadí jaké mu vyhovuje vyzkouší navázat hovor pomocí těchto kontaktů.

Všimněte si, že první tři NAPTR záznamy v našem příkladu míří na doménu skymia.cz, zatímco bez použití NAPTR vzniknou SRV dotazy pro telegro.cz. Většina telefonů NAPTR stále nepoužívá, takže existence SRV záznamů v doméně telegro.cz je prakticky nutnost (a povinnost podle RFC 3263).

Zpracování SRV dotazu

Obecné zpracování SRV záznamů je popsáno v RFC 2782. Chcete-li zjistit výsledek SRV dotazu, můžete použít příkaz host -t SRV _sip._udp.skymia.cz. Odpovědí může být libovolný počet záznamů, například

	priority weight port target
 IN SRV 10      120     5060 pbx1.skymia.cz.
 IN SRV 10       60     5060 pbx2.skymia.cz.
 IN SRV 10       20     5060 pbx3.skymia.cz.
 IN SRV 20        0     5060 pbx.skymia.cz.

Telefon nejprve seskupí a seřadí záznamy podle hodnoty priority, stejně jako v případě NAPTR podle order.

Je-li ve skupině se stejnou hodnotu priority více záznamů, je potřeba je seřadit a telefon pak postupně zkouší kontaktovat servery, na které záznamy ukazují.

Řazení se provádí pomocí losování. Vezměme si jako příklad první skupinu s hodnotou priority 10. V této skupině jsou tři záznamy s váhami 120, 60 a 20. Telefon váhy sečte a vyjde mu hodnota 200. Následně vygeneruje náhodné číslo od 1 do 200 (hodnoty součtu). Je-li číslo od 1 do 120, byl vylosován záznam pbx1.skymia.cz s váhou 120. Je-li číslo od 121 do 180, byl vylosován záznam pbx2.skymia.cz s váhou 60. Všimněte si, že interval 121 až 180 obsahuje přesně 60 hodnot. A nakonec, bylo-li číslo mezi 181 a 200, byl vylosován záznam pbx3.skymia.cz. Tímto způsobem je zajištěno, že záznamy s větší váhou jsou vylosovány nejčastěji (mají ve svém intervalu nejvíce hodnot). Vylosovaný server je umístěn na první místo v seznamu a následuje losování mezi zbylými záznamy o druhé místo. Byl-li například vylosován záznam pbx2.skymia.cz, jsou zbylé záznamy pbx1 a pbx3 s váhami 120 a 20. Mezi nimi je losováno analogickým způsobem (tentokrát se generuje hodnota od 1 do 140) a vylosovaný záznam je umístěn na druhé místo. Algoritmus pro řazení záznamů ve skupině zajistí, že servery s největší váhou jsou častěji na prvních místech. Váhy tak umožňují rozložit zátěž na jednotlivé servery.

Je-li ve skupině jen jeden záznam, měl by mít váhu nula.

Po seřazení záznamů ve skupině zkusí telefon kontaktovat záznam na prvním místě. Nepodaří-li se jej kontaktovat, je použit záznam na druhém místě atd. Všimněte si, že díky náhodnosti může být SIP request se stejnou destinací směrován různými trasami. Tato možnost by teoreticky mohla ohrozit monitorování hovorů, pokud by například paket s metodou BYE (požadavek na ukončení hovoru) putoval po jiné trase než INVITE. Protokol SIP tyto problémy ošetřuje, ale detaily jsou nad rámec tohoto článku.

Ke kontaktování serveru nakonec slouží číslo portu a DNS jméno serveru z polí port a target. DNS jméno serveru se převádí na IP adresu pomocí obyčejného dotazu typu A nebo AAAA (viz host -t A pbx.skymia.cz).

Neexistuje-li NAPTR záznam, ani SRV záznam, vyzkouší telefon postupně všechny protokoly, které ovládá. Přitom adresu odvodí pomocí dotazu na typ A nebo AAAA z doménového jména za zavináčem (host -t A telegro.cz) a jako číslo portu použije výchozí hodnotu (pro SIP 5060, pro SIPS 5061).

Shrnutí

Je-li za zavináčem SIP URI jméno domény, telefon by měl nejprve vyzkoušet NAPTR záznamy a z nich odvodit dotaz na SRV záznam. Neexistuje-li žádný NAPTR záznam, měl by sestavit SRV dotazy sám. Ze SRV dotazu telefon získá port a jméno serveru. Z jména serveru lze pomocí dotazů A či AAAA získat IP adresu serveru. Neexistuje-li NAPTR ani SRV záznam, použije telefon rovnou A/AAAA. Většina telefonů NAPTR nepodporuje a začíná celý převod se SRV.

V některém z příštích článků si ukážeme instalaci a konfiguraci doménového serveru pro SIP.