Mon blog

Le protocole SIP est normalisé dans le RFC 3261 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 RFC 3403 puis les enregistrements SRV du RFC 2782. 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 RFC 2543, 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.