avec SIP, quand utiliser TCP pas UDP?
Je connais bien les différences entre UDP et TCP en général (par exemple. http://www.onsip.com/about-voip/sip/udp-versus-tcp-for-voip )
La question qui se pose est de savoir dans quelles circonstances l’utilisation de TCP en tant que transport aurait des avantages spécifiques pour les communications SIP VOiP?
Beaucoup de gens associent généralement UDP à la voix sur IP et la laisseraient probablement, mais en termes simples, il existe deux aspects à la voix sur IP - la connexion et le transfert de données vocales.
SIP est un protocole très léger. Une fois les connexions établies, il est effectivement laissé inactif jusqu'à ce que quelqu'un passe un appel téléphonique. TCP (contrairement à UDP) réduira réellement le trafic sur le serveur en éliminant le besoin de le faire;
- Ré-enregistrer toutes les quelques minutes
- Actualiser/ping serveur
Vous pouvez exécuter SIP sur TCP, puis utiliser (comme il est recommandé) UDP pour RTP.
Je ne pouvais pas m'empêcher de souligner les choses évidentes que j'avais examinées. Par exemple. nombre de périphériques se connectant au serveur. Au fur et à mesure que le nombre augmente, l'équation bascule en faveur des PDU. Mais vous devez également envisager d’agrandir SIP les agents d’utilisateur pour couvrir plusieurs codecs, le multimédia, la vidéo et le partage d’écran. Les paquets INVITE peuvent commencer à prendre de l'ampleur et potentiellement courir sur la taille de datagramme unique UDP, faisant basculer l'équation à nouveau en faveur de TCP.
Tout cela étant dit, j'espère que vous avez suffisamment d'informations pour répondre à la question à laquelle vous cherchiez à répondre.
J'espère que cela t'aides.
Crédit: La merveilleuse discussion sur onSip: https://www.onsip.com/blog/sip-via-udp-vs-tcp
SIP sur TCP présente un avantage considérable par rapport à UDP pour les appareils mobiles. La raison en est due à l'utilisation de NAT et à la façon dont les entrées de table NAT dans un routeur sans fil ou un routeur de fournisseurs de cellules sont généralement expirées beaucoup plus rapidement pour UDP vs TCP. Comme il est nécessaire de conserver la même entrée de table NAT pour pouvoir recevoir des appels de manière fiable, SIP doit périodiquement envoyer des connexions en attente afin de conserver l'entrée de table NAT. La fréquence requise des connexions persistantes est beaucoup plus élevée pour UDP (peut-être toutes les 30 secondes) par rapport à TCP (peut-être toutes les 15 minutes), ce qui entraîne une utilisation nettement plus importante de la batterie des appareils mobiles. Souvent, lorsque vous voyez une personne se plaindre du fait que son utilisation de la batterie prend un coup dur lors de l’utilisation d’un client VOIP, c’est parce que le client utilise le protocole UDP.
Ainsi, TCP l'emporte sur UDP haut la main pour les appareils mobiles.
Notez que ce qui précède suppose que vous souhaitez pouvoir recevoir des appels de manière fiable sur votre appareil mobile. Si tout ce que vous voulez faire, c'est pouvoir passer des appels, c'est une autre histoire.
Si un message est volumineux (moins de 200 octets de la taille de la MTU), la section 18.1.1 de la norme RFC 3261 exige l'utilisation de TCP (pour être plus précis, elle requiert l'utilisation d'un "protocole de transport contrôlé par congestion, tel que TCP"). C'est ce que j'ai constaté en pratique lors de l'envoi d'une INVITE initiale avec de nombreux en-têtes et un URI de demande complexe.
Vous ne pouvez pas assembler de manière fiable un flux audio à partir d'un protocole basé sur TCP. En audio, il est de loin préférable de perdre un paquet que de le retransmettre à cause d'une chute de paquet. L'audio ne fonctionne pas s'il y a une gigue excessive dans la synchronisation des paquets. L’audio est en temps réel et nécessite un protocole tel que UDP pour fonctionner correctement. La perte de paquets ne casse pas l'audio, elle ne fait que réduire la qualité. La livraison parfaite de TCP n’aide en aucun cas l’audio. Il ne peut y avoir de qualité si vous obtenez 100% des paquets, mais ils ne sont pas en temps réel. En audio, c'est la synchronisation (latence, gigue) qui détermine davantage la qualité que l'intégrité des données.
Ce message fonctionneMEILLEURlorsque le signal et le contrôle sont sur TCP mais que les données vocales sont sur UDP.
Je travaille avec la transmission de protocoles vocaux numériques sur réseau depuis que j'ai conçu l'un des premiers smartphones en 1987 pour le nouveau réseau cellulaire numérique au Japon. Depuis 1987, le seul aspect de la transmission vocale numérique qui n’a pas changé est ce que je décris ici. La nature en temps réel de la transmission audio (vocale) et son impact sur la conception du système sont toujours exactement les mêmes qu'à l'époque des dinosaures dont je suis originaire.