Le protocole SIP est normalisé dans le qui décrit en détail la communication entre
un client et un serveur SIP. Mais comment le client trouve t-il un
serveur ? C'est l'objet de ce RFC d'accompagnement.
SIP est surtout utilisé pour la
téléphonie sur Internet. L'ancien
numéro de téléphone y est remplacé par un
URI, tel que
sip:support@apnic.net. Mais un client SIP (par
exemple un UAC, le logiciel avec lequel interagit directement
l'utilisateur, son téléphone : mais aussi un relais SIP que l'UAC
aurait utilisé) doit, pour établir une connexion avec le
serveur SIP, trouver son adresse, alors qu'il n'a que cet URI et donc
uniquement un nom de domaine (et que SIP peut
fonctionner sur plusieurs transports).
La méthode est donc d'utiliser le DNS. Le client va utiliser les
enregistrements NAPTR du puis
les enregistrements SRV du . Suivons la section 4.1 du RFC qui nous donne un
exemple, où on cherche à joindre
sip:helpdesk@example.net. Le domaine
example.net contient les enregistrements NAPTR
suivants :
; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com
IN NAPTR 120 50 "s" "SIP+D2S" "" _sip._sctp.example.com
On notera que le champ regexp est vide : quel que
soit l'URI de départ, le résultat est donné par le champ
replacement. Ici, quatre NAPTR sont intéressants
(ceux dont le service est de type SIPx+D2x). Le
premier spécifie un transport sécurisé par TLS
au dessus de TCP. Le second un transport TCP
simple, le troisième un transport UDP, le
quatrième un SCTP.
Une fois obtenu ces noms de domaines grâce aux NAPTR, on utilise
les enregistrements SRV pour avoir les serveurs et leurs numéros de
port. Par exemple, _sip._tcp.example.com aura les
SRV suivants :
; Priority Weight Port Target
IN SRV 0 1 5060 main-server.example.com.
IN SRV 10 1 53456 backup-server.example.com.
Le client tentera alors de se connecter à
main-server.example.com (on notera que cela
nécessitera une requête DNS supplémentaire, pour trouver son adresse
IP) se rabattant, s'il est inaccessible, sur
backup-server.example.com.
Le prédécesseur de notre RFC, le , n'utilisait pas
les NAPTR, uniquement les SRV. Dans l'exemple ci-dessus, les serveurs
étant dans un domaine différent de celui de l'URI, il aurait donc
échoué.
Notons enfin que la section 5 du RFC décrit comment un serveur SIP
trouve un client. Si ce dernier le contacte directement en TCP, c'est
trivial mais il existe des cas où le client est en fait un relais et
où la réponse doit suivre un cheminement analogue (avec recherche de
SRV - mais pas de NAPTR) pour le trouver.