Ci-dessous, vous trouverez les paramètres de base ou par défaut qui doivent être saisis dans chaque appareil SIP, en plus des données utilisateur (nom d’utilisateur et mot de passe). Vous trouverez également des informations à ce sujet dans le centre clientèle sous l’aide correspondante. Un peu plus loin, vous trouverez également des informations générales sur le thème TCP et le cryptage.
Veuillez noter que nous supportons officiellement IPv6 depuis 2014. Vous n’avez donc plus besoin de NAT ou de services de tunnel si vous avez une connexion IPv6 native (par exemple les clients de Deutsche Glasfaser) et si vous utilisez les FQDN correspondants des serveurs.
Les méthodes utilisées pour déterminer les adresses IP de nos serveurs SIP sont l’enregistrement DNS A, l’enregistrement DNS NAPTR et l’enregistrement DNS SRV.
Informations générales sur la configuration
IPv4 | DualStack | IPv6 | |
Paramètres par défaut | |||
Registraire SIP (également pour proxy SIP/sortie) Adresse du serveur (FQDN) | proxy.dus.net | proxy3.dus.net | proxyV6.dus.net |
Registraire SIP (également pour proxy SIP/sortie) Port du serveur | 5060 | 5060 | 5060 |
ATTENTION ! Uniquement en cas de cryptage (votre terminal doit le supporter) | |||
Enregistreur SIP/proxy sortant TLS+SRTP (FQDN) | secure.dus.net | – | secureV6.dus.net |
Enregistreur SIP/proxy sortant Port serveur TLS+SRTP | 5061 | – | 5061 |
autres réglages | |||
Adresse du serveur STUN (FQDN) | stun.dus.net | stun.dus.net | – |
STUN Port du serveur | 3478 | 3478 | – |
Port serveur STUN alternatif | 10000 | 10000 | – |
D’autres informations que vous ne devez saisir que si vous savez ce que vous modifiez. | |||
Charge utile DTMF | 101 | 101 | |
Serveur NTP (serveur de temps, FQDN) | ntp.dus.net | ntp.dus.net |
Infos sur le pare-feu
Service serveur | Serveur IPv4 | Serveur IPv6 | Protocole | Ports de-à |
Bureau d’enregistrement SIP | 83.125.8.71 | 2a04:2100:0:100::73 | TCP+UDP+TLS | 5060-5061 |
Proxy SIP/sortie | 83.125.8.71 | 2a04:2100:0:100::73 | TCP+UDP+TLS | 5060-5061 |
Relais média RTP | 83.125.8.150 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.154 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.155 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.156 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.158 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.159 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Relais média RTP | 83.125.8.160 | 2a04:2100:0:300::/56 | UDP | 10000-65535 |
Codes de service
Voici une liste de numéros spéciaux pour les clients dus.net.
Les codes de service sont toujours valables pour le raccordement SIP à partir duquel vous composez les codes. Veuillez composer les numéros tels qu’ils sont listés, sans préfixe ni autre chiffre :
Numéro interne de la boîte vocale : 00038711111
Numéro externe de la boîte vocale : 0211-23706687
Module de test DTMF en cas de problèmes avec les messages d’attente : 00038799998
Test d’écho pour la reproduction de vos signaux audio vers votre téléphone : 00038799999
Codes de service | |
*01 | Menu de la boîte vocale |
*02 | Annonce du crédit en EUR/cent |
*10 | Activer/désactiver la transmission du numéro de téléphone |
*11 | Activer/désactiver la messagerie vocale |
*12 | Activer/désactiver l’annonce des frais |
*20 | Activer/désactiver la redirection en cas de non-réponse |
*21 | Activer/désactiver la déviation si occupé |
*22 | Activer/désactiver la redirection en cas d’inaccessibilité |
*30 | Mettre en pause l’agent de file d’attente |
*31 | Rétablissement de l’agent de file d’attente |
Réveil
Vous pouvez commander un réveil simple en utilisant les codes de touches du tableau ci-dessous.
Réveil | |
*55*HHMM# | Commander un réveil HH = heures (format 24h) MM=minutes |
Exemple de réveil à 7h30 | *55*0730# Le numéro est appelé 2 fois à 5 minutes d’intervalle. |
#55*HHMM# | Annuler l’appel de réveil HHMM Heure réglée précédemment, par ex. 0730 |
*#55# | Interrogation sur les appels de réveil actifs. Tous les réveils actifs sont annoncés |
IPv4, IPv6, DualStack & DS-lite
La connexion de vos terminaux SIP aux serveurs de la dus.net se fait en général via une adresse IPv4. Les adresses IPv4 étant devenues très rares avec la multitude d’applications modernes possibles, le nouveau protocole IPv6 a vu le jour il y a quelques années. Bien entendu, la dus.net supporte également IPv6 depuis de très nombreuses années. Vous avez donc un choix illimité.
Cependant, l’IPv4 existe désormais dans une multitude de « versions différentes ». Il s’agit de la manière dont IPv4 est utilisé par les différents fournisseurs d’accès à Internet. De nombreux fournisseurs n’attribuent plus d’adresse IPv4 publique à leurs clients, mais uniquement des adresses IPv4 internes. Si une adresse IPv4 publique est attribuée, elle est également accessible de l’extérieur, c’est-à-dire que votre terminal, par exemple une FritzBox, reçoit cette adresse IPv4 publique et serait donc directement accessible de l’extérieur via cette adresse. En revanche, ce n’est pas le cas d’une adresse IPv4 interne, c’est-à-dire que le fournisseur d’accès à Internet place ici un routeur entre ses clients et Internet et fait en sorte qu’une adresse IPv4 publique soit accessible à plusieurs de ses clients sous la même adresse IP. Mais cela ne fonctionne que si les ports se distinguent les uns des autres, car c’est la seule façon de distinguer les clients les uns des autres.
Le problème ici est que les connexions sans adresse IP publique ne sont accessibles que de manière limitée. Dans ce cas, le terminal SIP doit généralement veiller à ce que la connexion à notre serveur SIP soit toujours ouverte afin de garantir une accessibilité continue. Cela est réalisé par les terminaux avec la fonction dite « Keep-Alive », qui doit principalement être activée par vous-même et/ou légèrement adaptée.
Outre les solutions classiques IPv4 et IPv6, dus.net offre également la possibilité de connecter des connexions dites DualStack. Dans le tableau en haut de cette page, vous trouverez les différentes formes de connexion. Parfois, il faut essayer un peu avec ces derniers, si ce n’est pas très clair de votre côté, comment vous êtes vous-même attaché.
Ports SIP & trunks SIP
Chez dus.net, tous les terminaux SIP (téléphones IP, softphones, FritzBox, etc.) sont connectés via leurs propres connexions SIP (également appelées comptes SIP, extensions, sous-comptes). Ainsi, chacun de ces terminaux est relié à notre serveur par une adresse IP et un port uniques, ce qui le rend accessible pour nous. Si deux terminaux différents sont connectés avec les mêmes données d’accès SIP, ils alternent l’enregistrement, c’est-à-dire que tantôt l’un, tantôt l’autre des terminaux est enregistré et donc jamais les deux ne sont accessibles en même temps.
Ici, si vous souhaitez gérer plusieurs numéros d’appel et les rendre accessibles indépendamment les uns des autres, cela doit donc être réalisé via le même nombre de connexions SIP. En conséquence, il est également possible d’inscrire plusieurs connexions SIP dans une FritzBox, par exemple, afin de garantir l’utilisation de différents numéros d’appel indépendamment les uns des autres.
Le trunk SIP n’est rien d’autre qu’une connexion SIP ordinaire, mais il est exclusivement associé à de véritables PABX. Contrairement aux terminaux SIP traditionnels, le PBX a également besoin des informations relatives au numéro d’appel composé dans le paquet SIP entrant, afin de permettre le routage vers le bon poste. Chez dus.net, cela est réalisé par la fonction DDI et est automatiquement disponible pour toutes les connexions SIP créées dans DUStel business flex.
SIP sur TCP et UDP
LeSession Initiation Protocol(SIP) est un protocole réseau permettant d’établir, de contrôler et de supprimer une session de communication entre deux ou plusieurs participants (source : Wikipedia). La signalisation des paquets SIP d’un appel téléphonique se fait généralement via UDP (User Datagram Protocol). Les données sont divisées en paquets qui peuvent avoir une taille théorique maximale de 1500 octets. Cette taille est toutefois réduite ou optimisée à une taille utilisable d’environ 1300 octets, malgré les informations supplémentaires et autres informations logiques. Si un tel paquet est envoyé, il contient à la fois l’adresse de l’expéditeur et celle du destinataire. Malheureusement, il n’y a cependant pas de retour à l’expéditeur pour savoir si le colis est bien parvenu au destinataire. Cela a pour conséquence qu’en cas d’utilisation de l’UDP, il faut en plus veiller et contrôler si un paquet a réellement atteint son destinataire. Cela se fait dans le protocole SIP au moyen de réponses d’accusé de réception. Dans ce cas, un « INVITE » (appel de A à B) est suivi d’un « TRYING », puis d’un « PROGRESS », etc. Si une quittance n’est pas reçue, le dernier paquet est envoyé une nouvelle fois à intervalles définis jusqu’à ce qu’une quittance soit reçue. Si l’absence de réponse persiste, la session entre dans un délai d’attente prédéfini et est interrompue.
Avec SIP via TCP (Transmission Control Protocol), le transport se comporte fondamentalement différemment. Comparable à une « lettre recommandée avec accusé de réception ». En raison de son concept, TCP est à bien des égards plus « robuste » que UDP, mais contrairement à UDP, il a aussi un certain surplus (overhead) de données et nécessite plus de bande passante que UDP pour la même quantité de données utiles. Toutefois, dans le cas de SIP, cet aspect est largement négligé. L’avantage de TCP est l’architecture du protocole en lui-même. Il contient des mécanismes intégrés permettant de reconnaître et de renvoyer de manière autonome les « paquets perdus ». De même, une connexion TCP est établie de manière dédiée. Cela signifie qu’avant que les données ne soient transmises, le destinataire sait déjà qu’elles vont arriver. Il existe encore d’autres avantages du TCP, qui sont également plus faciles à gérer pour le NAT (Network Address Translation) et donc pour les pare-feux que par rapport à l’UDP. Le choix du « meilleur » protocole n’a pas vraiment d’importance. Il doit répondre aux exigences pour vous en tant que client. La société dus.net GmbH vous offre la possibilité d’utiliser soit UDP soit TCP comme protocole de transmission pour SIP. Les réglages doivent être effectués exclusivement dans votre terminal respectif. Aucun réglage n’est nécessaire du côté de dus.net.
D’ailleurs, pour les données audio, c’est-à-dire la conversation téléphonique proprement dite, on utilise généralement UDP. La raison en est, entre autres, l' »overhead » nettement plus faible, c’est-à-dire la part importante de données utiles et les contrôles qui prennent moins de temps. Un éventuel renvoi de paquets n’a pas vraiment de sens dans une application en temps réel.
Cryptage avec TLS & SRTP
Ceux qui craignent pour la sécurité des données qu’ils transmettent sur Internet connaissent depuis des décennies le protocole SSL (Secure Socket Layer). Il s’agit d’un système de garantie basé sur des certificats.
TLS est l’abréviation de « Transport Layer Security ». Ici, tout comme avec SSL, n’importe quelle voie de transport (HTTP, e-mail, FTP ou même SIP) est sécurisée via le protocole TCP. Pour la téléphonie, cela signifie que les paquets responsables de l’établissement et de la suppression d’une conversation téléphonique, c’est-à-dire justement le protocole SIP, peuvent être sécurisés par TLS. La conversation (paquets vocaux) elle-même n’est toutefois pas cryptée avec TLS ( !!!). Cela se fait par défaut via le flux RTP non crypté. Si la conversation doit également être cryptée, le protocole SRTP entre en jeu.
SRTP
est possible dans de nombreuses variantes différentes et signifie « Secure Real Time Protocol ». Ce n’est que SRTP qui crypte les données vocales, c’est-à-dire la conversation proprement dite. La comparaison des clés pour le flux SRTP s’effectue toutefois normalement, si aucun autre mécanisme comme MIKEY n’est utilisé, via l’en-tête SDP du protocole SIP, mais ceci en texte clair. Même si un échange de clés sécurisé est garanti avec SRTP, cela n’est toujours pas complètement suffisant, car les numéros de téléphone, c’est-à-dire votre CLIP et le numéro de l’appelé, sont tout de même transmis en clair. Ainsi, un agresseur potentiel ne sait pas de quoi vous avez parlé, mais il sait tout de même à qui vous avez parlé.
En conclusion, il faut retenir qu’un flux RTP crypté associé à des paquets SIP non cryptés augmente le risque d’accéder à la clé maître et aux deux clés de session qui permettent de décrypter le flux SRTP.
En conclusion, seule une session SIP sécurisée par TLS/SSL en combinaison avec SRTP offre une protection complète, car l’accès aux clés cryptographiques pour SRTP se trouvant dans la partie SDP de la session SIP n’est plus visible sans autre.
Il va donc de soi que dus.net GmbH propose également SRTP en combinaison avec TLS, via IPv4 et IPv6.