Guide des ports SIP : signalisation VoIP sur les ports 5060 et 5061

SIP coordonne les sessions de communication. Un agent utilisateur SIP, un téléphone, un PBX, une ligne réseau ou un softphone envoie des messages tels que REGISTER, INVITE, ACK, BYE, OPTIONS et CANCEL pour établir et gérer les appels. Ces messages décrivent qui appelle, où le point final peut être atteint, quels codecs sont disponibles et comment les médias doivent être échangés.

SIP n'est que la couche de signalisation. Une fois qu'un appel est négocié, l'audio ou la vidéo circule généralement via RTP ou RTP sécurisé sur des ports UDP séparés. Cette séparation est la raison pour laquelle un appareil SIP peut apparaître en ligne alors que l'appel a un son unidirectionnel, aucun son ou un média qui s'interrompt après quelques secondes.

Le port 5060 est le port de signalisation SIP conventionnel. Il est couramment utilisé avec UDP, mais SIP peut également fonctionner sur TCP sur 5060 lorsque la plate-forme nécessite un transport fiable ou des messages plus volumineux. De nombreux téléphones, PBX et lignes réseau SIP utilisent toujours UDP 5060 par défaut.

Le port 5061 est couramment utilisé pour SIP sur TLS. TLS protège les métadonnées de signalisation en transit et aide les clients à vérifier le serveur avec lequel ils communiquent. Il ne chiffre pas automatiquement le flux multimédia ; les médias vocaux nécessitent SRTP ou une autre protection de couche multimédia lorsque la confidentialité est requise.

SIP indique aux points finaux comment démarrer, modifier et terminer un appel. RTP transporte les paquets audio ou vidéo réels une fois que les points finaux se sont mis d'accord sur les codecs et les adresses. Les plages de ports RTP varient selon le PBX, le fournisseur, le système téléphonique, le SBC ou la plate-forme vocale cloud, il n'existe donc pas de port RTP universel unique.

Les exemples courants incluent les plages UDP telles que 10 000 à 20 000, 16 384 à 32 767 ou les plages spécifiques au fournisseur. Ouvrez uniquement les plages requises par votre plate-forme vocale et indiquez si le trafic doit circuler des téléphones vers le PBX, du PBX vers le fournisseur ou dans les deux sens.

Ouvrez les ports SIP uniquement lorsqu'un téléphone, un PBX, un fournisseur de lignes réseau SIP, un contrôleur de frontière de session ou une passerelle vocale de confiance doivent échanger des signaux. Les déploiements typiques permettent aux téléphones d'atteindre un PBX interne, à un PBX d'atteindre une jonction SIP ou à un SBC pour assurer la médiation du trafic VoIP public.

N'exposez pas SIP à grande échelle simplement parce que les appels doivent fonctionner à distance. Les points de terminaison SIP publics attirent les scanners, les tentatives d'enregistrement, la fraude aux péages, l'énumération des extensions et les attaques par mot de passe. Préférez les VPN, le peering privé, les listes autorisées de fournisseurs, les SBC ou les réseaux sources à portée étroite.

Commencez par identifier le chemin vocal exact. Confirmez quel appareil possède la signalisation, quel côté initie l'enregistrement, quelle plage RTP la plate-forme utilise et si TLS ou SRTP est requis. Autorisez ensuite SIP 5060 ou 5061 uniquement entre les sources et destinations attendues.

Pour les environnements NAT, configurez le PBX ou le SBC avec l'adresse publique, les réseaux locaux, l'adresse de signalisation externe et l'adresse multimédia externe correctes. Évitez de vous fier aveuglément à SIP ALG, car il peut réécrire les paquets de manière incorrecte et créer des enregistrements intermittents ou des pannes audio.

Une vérification de base du port peut confirmer si un écouteur TCP tel que SIP sur TLS sur 5061 est accessible. Pour UDP 5060, utilisez des vérifications SIP dans la mesure du possible, car UDP ne se comporte pas comme une connexion TCP. Des outils tels que sipsak, sipvicious dans les tests contrôlés, les diagnostics du fournisseur, les journaux PBX et les captures de paquets peuvent indiquer si les messages SIP atteignent le bon point de terminaison.

Une fois la signalisation opérationnelle, effectuez un véritable appel test et vérifiez les médias. Vérifiez l'audio bidirectionnel, le temps d'établissement des appels, la négociation du codec, les adresses source et de destination RTP, les traductions NAT, les compteurs de pare-feu et si les paquets continuent après les premières secondes.

Si un téléphone ne peut pas s'enregistrer, vérifiez le DNS, les règles de pare-feu sortant, les informations d'identification, le domaine, le mode de transport, les certificats TLS, les listes autorisées des fournisseurs et si le PBX ou le proxy écoute sur le port SIP attendu. Les échecs d’enregistrement sont souvent dus à des problèmes d’authentification ou de stratégie, et pas seulement à des problèmes de port.

If calls connect but have no audio, inspect RTP ranges, NAT addresses in SDP, SIP ALG, symmetric RTP settings, provider media IP ranges, and firewall direction. Si l’audio fonctionne dans un seul sens, un côté peut généralement envoyer du RTP tandis que l’autre ne peut pas le recevoir.

Limitez l’exposition SIP aux fournisseurs connus, succursales, clients VPN, SBC ou réseaux privés. Désactivez les extensions inutilisées, exigez des mots de passe forts ou une authentification basée sur un certificat lorsque cela est pris en charge, limitez le débit des tentatives d'enregistrement et alertez en cas d'échec d'enregistrement ou de numérotation internationale inattendue.

Utilisez SIP sur TLS et SRTP lorsqu'ils sont pris en charge, mais rappelez-vous que le cryptage ne remplace pas le contrôle d'accès. Gardez les PBX, SBC, micrologiciels téléphoniques et passerelles vocales corrigés, examinez les enregistrements détaillés des appels pour détecter toute fraude et séparez les interfaces de gestion vocale des chemins de signalisation publics.