[English] - [Français] - [Deutsch]
Messages ACK non traités et
retransmission de réponses 487 par Verizon
Emin Gabrielyan
Traduit par Christian Lathion
Switzernet
2007-05-24
Nous pensons
avoir trouvé une cause possible du problème du côté de Verizon. Nous avons
remarqué que Verizon utilise OpenSER v1.2.0 sous Solaris. Nous avons crée une
configuration de test en remplaçant la vrai serveur Verizon par un autre
serveur "pseudo-Verizon". Sur ce serveur nous avons reproduit à
l’identique le comportement erroné. Dans ce document nous expliquons l’erreur
et comment la réparer.
Simulation du problème du côté de Verizon
Rappel
du problème
Le graphe
ci-dessous rappelle le problème. Dans ce graphe, notre serveur SIP avec deux
interfaces (212.249.15.4 et 195.129.125.74) reçoit un INVITE de 128.179.67.76
et le relaie à Verizon à l’adresse 212.190.89.137. Quand l’appel est annulé,
Verizon nous envoie une réponse 487, et nous envoyons en retour un message ACK.
Cependant, Verizon ne termine pas la transaction et continue d’envoyer
plusieurs messages de statut 487.
[png]
Le diagramme de
la transaction au noeud précédent (128.179.67.76) est aussi disponible [png]
Ce qu’on
devrait obtenir
Lors d’un appel
normalement annulé, la transaction doit correspondre au schéma ci-dessous. Dans
cet exemple, le serveur SIP 192.168.1.15 représente notre serveur SIP ; le
serveur 192.168.1.16 représente Verizon. Dans le scénario présenté, le serveur "Verizon"
ne nous envoie pas la réponse 487après réception de notre ACK.
192.168.1.10 est
un téléphone SIP
[png]
Pour le scénario
présenté, nous fournissons le fichier de configuration du serveur SIP
"pseudo-Verizon" [cfg] (dans cet exemple à l’adresse 192.168.1.16).
Simulation
du problème du côté de Verizon
Nous avons pu simuler
le problème courant sur le serveur SIP 192.168.1.16, qui dans ce cas représente
Verizon. Dans le graphe ci-dessous, on voit le mauvais comportement de 192.168.1.16,
qui comme dans la vraie situation ne comprend pas le message ACK de notre
serveur (représenté par 192.168.1.15) et continue de retransmettre des réponses
487.
[png]
Le diagramme de
la transaction sur 192.168.1.16 (le pseudo-Verizon) est aussi disponible [png], ainsi que le fichier de configuration
erroné utilisé sur 192.168.1.16 [cfg]. Nous suspectons que Verizon utilise actuellement un fichier de
configuration comportant une erreur similaire.
Explication
de l’erreur
Si l’on se réfère
au RFC 3261, un proxy stateful doit gérer l’échange de ACKs de nœud à nœud
(hop-by-hop). Pour cette raison, on pourrait penser que la méthode t_relay() ne
doit pas être appelée pour les messages ACK. Cependant on doit considérer que
la méthode t_relay() du module de transactions d’OpenSER est assez intelligente
pour ne pas retransmettre de tels messages ACK. De plus, l’appel de t_relay()
est absolument nécessaire, dans ce cas pas pour la retransmission (comme son
nom le suggèrerait) mais aussi pour indiquer au module que la transaction est
terminée, et que la retransmission des messages 487 n’est plus nécessaire.
En conclusion, la
méthode t_relay() doit être appelée pour tous les types de messages ACK, qu’ils
soient traités dans la section loose_route() (correspondant aux appels
décrochés) ou aussi ceux qui ne sont pas traités par la section loose_route()
(soit les appels annulés).
Il faut noter que
les serveurs représentant les nœuds (hops) suivants doivent aussi être corrigés
(s’il y en a et s’ils présentent le même problème de configuration), car les un
ou deux premiers messages 487 reçoivent un ACK en réponse, mais les messages
487 suivants seront transmis en retour.
* * *