avec SIP, quand utiliser TCP et non UDP?
je connais assez les différences entre les protocoles UDP et TCP en général (eg. http://www.onsip.com/about-voip/sip/udp-versus-tcp-for-voip)
Question: dans quelles circonstances L'utilisation de TCP comme moyen de transport présenterait-elle des avantages spécifiques dans le cadre des communications VOiP SIP?
5 réponses
beaucoup de gens associeraient généralement UDP avec voip et probablement le laisser à cela, mais en termes simples il y a deux parties à voip - connexion et transfert de données vocales.
SIP est un protocole très léger, une fois que les connexions sont établies, il est effectivement laissé inactif jusqu'à ce que l'événement rare de quelqu'un faisant un appel téléphonique. TCP (contrairement à UDP) va en fait réduire le trafic vers le serveur en éliminant le besoin de;
- Ré-enregistrer toutes les quelques minutes
- Actualiser/ping le serveur
vous pouvez exécuter SIP sur TCP puis utiliser (comme recommandé) UDP pour RTP.
Je n'ai pas pu m'empêcher de souligner les choses évidentes que j'ai examinées. Par exemple. nombre de périphériques connectés au serveur. Au fur et à mesure que le nombre augmente, L'équation penche en faveur de L'UDPs. Mais ensuite, vous devez également envisager les Agents utilisateurs SIP étendre pour couvrir plusieurs codecs, multimédia, vidéo et le partage d'écran. Les paquets D'invitation peuvent commencer à grandissez et potentiellement exécutez sur la taille du datagramme unique UDP en inclinant de nouveau l'équation en faveur de TCP.
tout cela étant dit, j'espère que vous avez assez d'information pour répondre à la question à laquelle vous cherchiez à répondre.
J'espère que cela vous aidera.
crédit: La merveilleuse discussion à l'onSip:https://www.onsip.com/blog/sip-via-udp-vs-tcp
SIP over TCP a un avantage significatif sur UDP pour les appareils mobiles. La raison est due à L'utilisation du NAT, et comment les entrées de table NAT dans un routeur sans fil ou un routeur de fournisseurs de cellules sont généralement programmées beaucoup plus rapidement pour UDP vs TCP. Comme il est nécessaire de conserver la même entrée dans la table NAT pour pouvoir recevoir des appels de manière fiable, SIP doit périodiquement envoyer des keep-alives pour maintenir l'entrée dans la table NAT. La fréquence de conservation requise est beaucoup plus élevée pour UDP (peut-être toutes les 30 secondes) vs TCP (peut-être toutes les 15 minutes), ce qui entraîne une utilisation nettement plus élevée de la batterie de l'appareil mobile. Souvent, quand vous voyez quelqu'un se plaindre de la façon dont leur utilisation de la batterie prend un grand coup en utilisant un client VOIP, c'est parce que le client utilise UDP.
donc, TCP l'emporte sur UDP pour les appareils mobiles.
notez que ce qui précède suppose que vous voulez être en mesure de recevoir des appels fiables sur votre appareil mobile. Si tout ce que vous voulez faire est de pouvoir passer des appels, alors c'est autre histoire.
si un message est de grande taille (à moins de 200 octets de la taille MTU), la section 18.1.1 de la RFC 3261 prescrit l'utilisation de TCP (pour être précis, elle prescrit l'utilisation d'un "protocole de transport contrôlé de la congestion, tel que TCP"). J'ai frappé que dans la pratique lors de l'envoi d'une initiale INVITE avec beaucoup d'en-têtes et un URI de requête complexe.
vous ne pouvez pas assembler de manière fiable un flux audio à partir d'un protocole TCP. En audio, il est de loin préférable de perdre un paquet que d'avoir un paquet retransmis en raison d'une perte de paquets. L'Audio ne fonctionne pas s'il y a un brouilleur excessif dans le timing du paquet. L'Audio est en temps réel et nécessite un protocole comme UDP pour fonctionner correctement. La perte de paquets ne casse pas l'audio, elle réduit seulement la qualité. La livraison parfaite de TCP n'aide pas l'audio en aucune façon, il ne peut pas y avoir de qualité si vous obtenez 100% de la les paquets, mais ils ne sont pas en temps réel. En audio, c'est le timing (latence, jitter) qui détermine la qualité plus que l'intégrité des données.
Ce sip fonctionne quand le signal et le contrôle sont sur TCP mais que les données vocales sont sur UDP.
j'ai travaillé avec la transmission de la voix numérique sur les protocoles de réseau depuis que j'ai conçu l'un des premiers smartphones en 1987 pour le réseau cellulaire numérique nouvellement émergeant au Japon. Depuis 1987, la seule l'aspect de la transmission de la voix numérique qui n'a pas changé est ce que je décris ici. La nature en temps réel de la transmission audio (voix) et la façon dont cela influe sur la conception du système est exactement la même que dans les jours de dinosaure d'où je viens.
TCP peut passer avec une clarté parfaite sur une connexion avec perte, quand UDP peut ne pas être compréhensible. Vous obtenez une latence plus faible avec UDP, mais cela ne vous aide pas si vous ne pouvez pas comprendre ce qui est dit.