Mon blog

Une des fonctions les plus demandées d'un service de téléphonie, dans les entreprises, est la musique d'attente, cette insupportable ritournelle qu'il faut supporter en attendant un interlocuteur qui ne viendra peut-être jamais. Comment déployer ce service si on utilise SIP pour la téléphonie ? Il existe plusieurs méthodes et ce nouveau RFC en documente une. Il peut être utilisé comme exemple d'un service mis en œuvre au dessus de SIP, sans nécessiter de modification ou d'extension du protocole.

A priori, ce n'est pas évident. Rappelons brièvement comment fonctionne SIP (RFC 3261), lorsqu'Alice veut contacter Bob. Le client SIP de Bob s'est enregistré auprès d'un fournisseur SIP (SIP permet aussi du pair-à-pair, sans ces fournisseurs, mais c'est plus rare). Alice appelle le serveur SIP de Bob, et lui indique (dans un SDP, cf. RFC 4566) où envoyer le flux audio. Le serveur de Bob prévient son client et, si celui-ci accepte, il indique à son tour où envoyer le son. La communication est établie. Le flux audio ne voyage pas dans le même canal que la signalisation. Les machines SIP doivent indiquer où envoyer ce flux car elles sont souvent coincées derrière un routeur NAT et elles doivent d'abord faire un trou dans le NAT, par exemple avec STUN. Maintenant, si le serveur SIP de Bob ne peut pas établir la communication avec Bob tout de suite et qu'il veut envoyer une musique d'attente, genre « Les quatre saisons » de Vivaldi ? L'architecture de SIP fait que ce n'est pas complètement trivial. Plusieurs méthodes avaient été documentées (par exemple en section 2.3 du RFC 5359) mais avaient des effets parfois gênants, par exemple entraînaient des messages inattendus dans l'interface utilisateur du client SIP, ou bien marchant mal en cas d'authentification des partenaires.

D'où la nouvelle méthode décrite dans ce RFC (section 2) : comme dans la section 2.3 du RFC 5359, Bob envoie à son tour un message INVITE à Alice pour la mettre en attente, mais il ne fournit pas de SDP, pas de description des détails techniques de la session audio. Alice va alors en envoyer un à elle. Bob utilise l'option de la section 5.2 du RFC 4235 pour indiquer qu'il ne jouera pas le flux audio. Bob transmet le SDP d'Alice au serveur de musique d'attente, via un nouvel INVITE. Le serveur de musique va alors envoyer la musique en RTP (RFC 3550) à Alice. Cette sorte d'indirection (ici, Bob contactant le serveur de musique mais en lui disant d'envoyer le son à Alice) est très courant dans le monde SIP (et pose d'ailleurs d'amusants problèmes de sécurité).

Pour mettre fin à l'attente, le serveur de Bob ré-envoie un INVITE à Alice, un INVITE habituel, cette fois, avec un SDP de Bob. Et il coupe la session avec le serveur de musique d'attente.

Tiré du RFC (qui contient la session complète, avec tous les détails), voici la requête de Bob (ou plutôt du serveur de Bob) à Alice lorsqu'il la met en attente. Notez l'absence de SDP (de descripteur de session, le corps a une taille nulle) et le +sip.rendering="no" du RFC 4235 pour indiquer que Bob n'écoute pas, pour l'instant :

INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
    Via: SIP/2.0/TLS biloxi.example.com:5061
     ;branch=z9hG4bK874bk
    To: Alice <sips:alice@atlanta.example.com>;tag=1234567
    From: Bob <sips:bob@biloxi.example.com>;tag=23431
    Call-ID: 12345600@atlanta.example.com
    CSeq: 712 INVITE
    Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
    Supported: replaces
    Content-Length: 0

Et la sollicitation de Bob auprès du serveur de musique d'attente. Cette fois, un SDP est inclus, contenant l'adresse IP où Alice recevra le flux (192.0.2.69), le port où envoyer ce flux (49170) et le paramètre recvonly indiquant au serveur de musique qu'Alice écoutera mais ne parlera pas au dit serveur :

INVITE sips:music@source.example.com SIP/2.0
    Via: SIP/2.0/TLS biloxi.example.com:5061
     ;branch=z9hG4bKnashds9
    Max-Forwards: 70
    From: Bob <sips:bob@biloxi.example.com>;tag=02134
    To: Music Source <sips:music@source.example.com>
    Call-ID: 4802029847@biloxi.example.com
    CSeq: 1 INVITE
    Contact: <sips:bob@biloxi.example.com>
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
    Supported: replaces, gruu
    Content-Type: application/sdp
    Content-Length: [omitted]

    v=0
    o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
    s=
    c=IN IP4 192.0.2.69
    t=0 0
    m=audio 49170 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    a=recvonly

Les avantages de ce mécanisme (section 3) ? Pas de transfert du dialogue SIP donc les adresses affichées par les logiciels SIP ne changent pas en cours de session. Pas d'utilisation de la commande REFER, introduite dans le RFC 3515 mais peu déployée. Lien direct entre le serveur de musique et l'appelant mis en attente (Alice), ce qui évite le faire passer le flux audio par le répondant (Bob).

Et les pièges (section 4) ? Il y a un petit risque qu'Alice n'indique pas, dans le SDP, tous les formats audio que gère son logiciel, mais seulement ceux qu'elle a utilisé avec Bob. C'est une violation des sections 5.1 et 5.3 du RFC 6337 mais cela peut arriver. Et, dans ce cas, il pourra arriver qu'elle ne reçoive rien parce que le serveur de musique d'attente croit, à tort, qu'elle ne gère pas les formats qu'il possède. Si Alice (enfin, son logiciel SIP), gère les formats X et Y, que B gère les formats X et Z, et que le serveur de musique gère les formats Y et Z, si Alice n'annonce dans son SDP que le format X (le seul qu'elle a en commun avec Bob), le serveur de musique croira qu'il ne peut pas la satisfaire, alors que le format Y aurait convenu.

Quelques mots enfin sur la sécurité (section 5). Le serveur de musique est un tiers qui n'est pas forcément sous la même administration que le serveur de Bob. Il va récupérer quelques informations (l'adresse IP d'Alice) et il faut donc que Bob (enfin, son fournisseur SIP), veille à ce que la sécurité du serveur de musique soit assurée. Le RFC suggère que le plus simple est que le fournisseur de Bob évite la sous-traitance et utilise un serveur de musique d'attente installé chez lui.

Quelles mises en œuvre de SIP ont une fonction de musique d'attente conforme à ce RFC ? Apparemment (mais je n'ai pas vérifié), les téléphones SIP de Polycom, le système OnSIP, les Cisco (ex-Linksys), etc. Vous pouvez trouver un pcap d'un dialogue avec musique d'attente en http://wiki.sipfoundry.org/display/sipXecs/Phone+Certification+Process (cherchez music on hold).