SRV und NAPTR

Lokalisieren von SIP-Dienstleistungen

Üblicherweise werden Server anhand des Hostnamens angegeben, die Aufösung des Standortes wird anhand eines DNS Eintrages realisiert der eine eindeutige Zuordung zulässt ohne die Flexibilität der Standortwahl einzuschränken. Genau so verhält es sich auch mit Services, wodurch eine flexible Trennung zwischen dem eigentlichen Service und der Maschine auf der das Service angeboten wird, erzielt werden kann.

Im RFC3263 wird DNS als die bevorzugte Methode für die Bestimmung der IP Adresse, des Ports und der Transportmethode des Hosts spezifiziert, zu dem ein SIP-Request geschickt werden soll. Die Methode muß festgestellt werden, da SIP-Requests via UDP, TCP, SCTP oder TLS over TCP für einen sicheren, verschlüsselte Session gesendet werden können.

Lokalisierung von SIP Servern

Für die Lokalisierung von Diensten innerhalb einer Domain (oder eines Hosts) existieren sog. Service Records (SRV) im DNS. Ein SRV Record ist vergleichbar dem MX-Record für die Mailzustellung. Ein SRV Record ist allerdings wesentlich allgemeiner gehalten.

Über einen SRV-Record können für einen spezifischen Dienst, ein oder mehrere Server angegeben werden. In der Regel werden diese Angaben auf Ebene der Domain hinterlegt. Der Service wird dabei über den Namen angesprochen unter dem er bei IANA registriert wurde. Damit keine Verwechslung mit realen Namen möglich ist, wird diesem sogenannten Servicenamen ein Unterstrich vorangestellt.

Das verwendete Transportprotokoll wird ebenfalls mit vorangestelltem Unterstrich als Subdomain angehängt, und damit wird eine Anfrage an das DNS mit Recordtyp SRV durchgeführt.

ein SRV Record (RFC2782) sieht folgendermassen aus:

  "_Service._Proto.Name TTL Class SRV Priority Weight Port Target"

zum Beispiel:

  "_sip._udp.sample.com 43200 IN SRV 10 10 5060 proxy.sample.com."
  • Das Service ist SIP.
  • Die Transportmethode ist UDP. Es kann aber auch TCP, SCTP oder TLS sein.
  • Die Cachezeit beträgt 12 Stunden (43.200 Sekunden)
  • Die Kategorie ist IN
  • Der Typ ist SRV.
  • Die Priorität ist 10. Bei mehreren SRV Records legt die Priorität die Reihung der Proxyabfrage fest. Niedrige Werte werden zuerst abgefragt.
  • Das Gewicht ist 10. Mit mehreren SRV Records gleicher Priorität, stellt das Gewicht proportional fest, wie häufig ein Proxy abgefragt wird.
  • Der Port ist 5060.
  • Die FQDN des Proxies ist calvin.comnect.at und wird - wie im DNS gefordert - mit einem Punkt abgeschlossen.


eine Abfrage liefert somit beispielsweise:

  dig srv _sip._udp.sipit.at
; <<>> DiG 9.2.4 <<>> srv _sip._udp.sipit.at
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13558
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;_sip._udp.sipit.at. IN SRV

;; ANSWER SECTION:
_sip._udp.sipit.at. 86400 IN SRV 0 0 5060 calvin.comnect.at.

;; AUTHORITY SECTION:
sipit.at. 15462 IN NS ns2.comnect.at.
sipit.at. 15462 IN NS ns1.comnect.at.

;; ADDITIONAL SECTION:
ns1.comnect.at. 84197 IN A 195.69.180.2
ns2.comnect.at. 84197 IN A 195.69.180.3

;; Query time: 38 msec
;; SERVER: 213.129.226.2#53(213.129.226.2)
;; WHEN: Tue Sep 20 15:46:04 2005
;; MSG SIZE rcvd: 141

Als Ergebnis erhält man ein oder mehrere SRV-Records die letztlich auf einen Host verweisen der den geforderten Dienst (hier SIP als UDP Dienst) unter dem angegebenen Port (hier 5060) anbieten.

In der Zone müssen entsprechende Records hinterlegt werden:

  $ORIGIN sample.com.
; Prio Weight Port Server
_sip._udp IN SRV 0 0 5060 proxy.sample.com.
_sip._tcp IN SRV 0 0 5060 proxy.sample.com.
_sips._tcp IN SRV 0 0 5060 proxy.sample.com.

Auswahl des Transport Protokolls

Ein SIP-Client kann als Transportprotokoll entweder UDP oder TCP verwenden. Zusätzlich ist eine sichere Variante des Protokolls (SIPS) über TLS und TCP definiert. Der Client muß eine Möglichkeit haben herauszufinden welche Protokolle von einem SIP Server angeboten werden, damit er anschließend eine entsprechende SRV-Abfrage durchführen kann. Für diesen Zweck werden laut RFC3263 NAPTR-Records verwendet. Diese werden hierbei, anders als bei der e164-Rufnummernauflösung über ENUM, mit dem Flag "s" verwendet, und stellen damit ein Mapping auf die oben angegebenen SRV Records dar.

Ein NAPTR Record (RFC3403) sieht folgendermassen aus:

  "domain TTL Class NAPTR order pref flags service regexp target"

zum Beispiel:

  "sample.com. 43200 IN NAPTR 6 5 "s" "SIP+D2U" "" _sip._udp.sample.com."
  • Die Domain nach der abgefragt wird. Das ist der Teil auf der rechten Seite von sip: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
  • Die Cachezeit beträgt 12 Stunden (43.200 Sekunden)
  • Die Kategorie ist IN
  • Der Typ ist NAPTR.
  • "order" ist 6, ähnlich SRV Record
  • "preference" ist 5, ähnlich SRV Record
  • Das flag ist s. Das Flag s kennzeichnet den Eintrag als "terminalen" Eintrag mit Verweis auf einen SRV Record. Dies bedeutet, dass im nächsten Schritt eine Anfrage an den angegebenen Service Record gestelllt werden muß.
  • Der Service ist SIP+D2U. Dieses spezifiziert das SIP-Protokoll via UDP. Andere mögliche Werte sind SIP+D2T für SIP over TCP, SIP+D2S für SIP over SCTP und SIPS+D2T für sicheres SIP over TLS over TCP. TLS over UDP wird nicht definiert.
  • regexp ist hier leer und kann für komplexere Abfragen verwendet werden
  • _sip._udp.sample.com ist das Ziel


Beispiel:

  $ORIGIN sample.com.
; order pref flags service regexp replacement
@ IN NAPTR 10 50 "s" "SIP+D2T" "" _sips._tcp.sample.com.
IN NAPTR 20 50 "s" "SIP+D2U" "" _sip._udp.sample.com.
IN NAPTR 40 50 "s" "SIP+D2T" "" _sip._tcp.sample.com.
 
 
 
© SIPit, 2005-2013 - Alle Rechte vorbehalten