Test d’envoi de paquets RADIUS Start et Stop
Created on 2010-01-20 by Nicolas Jorand
Switzernet
Le but de ces tests est d’analyser le comportement du Billing suivant le moment où il reçoit les paquets RADIUS Start et Stop. S’il voit que l’appel est effectué, s’il le facture, s’il relie correctement tous les legs de l’appel, etc.
Envoi des Start après les Stop
Envoi différé des Start-Stop
Nous allons observer ce qu’il se passe quand le Start et le Stop sont envoyés après que l’appel soit terminé. Voici la liste des scénarios étudiés :
- Appel sortant vers un téléphone IP enregistré sur un Porta-Sip
- Appel sortant vers un téléphone mobile
- Appel sortant vers un téléphone fixe
- Appel entre deux téléphones IP enregistrés sur l’Asterisk
- Appel entrant d’un téléphone IP enregistré sur un Porta-Sip
- Appel entrant d’un téléphone fixe
Remarque : Pour tous ces cas, le délai d’attente d’envoi des paquets Start-Stop a été fixé à 60 secondes après la fin d’appel.
[1] Appel sortant vers un téléphone IP enregistré sur un Porta-Sip
Dans ce cas, l’appel apparaît dans les Active Calls. Une fois l’appel terminé et qu’on a attendu le délai de 60 secondes, on peut chercher l’appel avec le Trace Call.
On peut voir que le Billing n’a pas réussi à relier les deux legs de l’appel. Le premier, en rouge, est créé par les Start-Stop du Porta-Sip et le second, en bleu, par l’Asterisk (donc 60 secondes plus tard). De ce fait, lorsque l’on fait un Trace Call immédiatement après avoir terminé l’appel, seul le leg rouge apparaît. Il faut attendre le délai de 60 secondes pour que le leg bleu s’affiche aussi. On peut également voir que les « Connect Time » et « Disconnect Time » sont décalés d’une seconde. Voici les logs de cet appel.
Dans le test suivant, les « Connect Time » et « Disconnect Time » sont identiques, mais la « Duration » est différente d’une seconde. Voici les logs.
[2] Appel sortant vers un téléphone mobile
Dans ce cas-là, l’appel n’apparaît pas dans les Active Calls. De plus lors du Trace Call, il faut attendre le délai de 60 secondes pour voir le leg s’afficher.
On peut voir qu’il n’y a qu’un seul leg. Cela vient du fait que seul l’Asterisk envoie des paquets Start-Stop, donc pas de problème de reliure pour le Billing. Voici les logs. Ici seul l’Asterisk envoie les Start-Stop au Billing.
[3] Appel sortant vers un téléphone fixe
Idem que pour un appel sortant vers un téléphone mobil, l’appel n’apparaît pas dans les Active Calls. De plus lors du Trace Call, il faut attendre le délai de 60 secondes pour voir le leg s’afficher. De nouveau, seul l’Asterisk envoie les Start-Stop au Billing.
Voici les logs.
[4] Appel entre deux téléphones IP enregistrés sur l’Asterisk
Du fait que les deux appareils sont enregistrés sur le même serveur, celui-ci envoie les Start-Stop une seule fois pour les deux. A l’inverse du cas [1]. Cet appel n’apparaît pas non plus dans les Active Calls et il faut attendre le délai de 60 secondes pour le voir dans le Trace Call.
Voici les logs.
[5] Appel entrant d’un téléphone IP enregistré sur un Porta-Sip
Comme pour le cas [1], on peut voir l’appel dans les Active Calls du fait que le Porta-Sip envoie ses Start-Stop normalement. On aura également les deux legs non reliés, un fait par le Porta-Sip et l’autre par l’Asterisk.
Voici les logs.
[6] Appel entrant d’un téléphone fixe
Dans ce cas là aussi, le Billing n’arrive pas à relier les deux legs. Le premier vient du serveur d’entrée de l’appel (Porta-Sip) de la ligne fixe et le second de l’Asterisk. L’appel est visible dans les Active Calls.
Voici les logs.
Observations et hypothèses
On peut voir que dans les cas où seul l’Asterisk envoie des Start-Stop, le Billing arrive à traiter correctement l’appel (facturation, etc..) même ces les Start-Stop sont envoyés après que l’appel soit terminé. En fait tant qu’il ne les reçoit pas, le Billing ne sait pas qu’il y a eu un appel. Valable pour les cas [2], [3] et [4].
Par contre quand il reçoit des Start-Stop de deux serveurs différents, dans ce cas il n’arrive pas à relier les deux legs ensemble. Cas [1], [5] et [6].
En étudiant les logs, on peut voir qu’à la fin de chaque appel, on a un block --CALL-- similaire à celui-ci :
CALL--
Jan 20 03:41:22: Removing call 582DAB5B 31B62BBA 5088CE17 195819E5/1
Jan 20 03:41:22: No logged in accounts, call lifetime reduced to 15
Jan 20 03:41:22: Cleaning up the call
Jan 20 03:41:22: Usernames in all accounting requests are ok
Jan 20 03:41:22: Processing answer/VoIP call leg
Jan 20 03:41:22: Processing originate/VoIP call leg
Jan 20 03:41:22: Processing answer/VoIP call leg
Jan 20 03:41:22: Skipping Start accounting
Jan 20 03:41:22: Processing originate/VoIP call leg
Jan 20 03:41:22: Skipping Start accounting
Jan 20 03:41:22: There are no unsaved CDRs for this call left
Jan 20 03:41:22: Call '582DAB5B 31B62BBA 5088CE17 195819E5/1' deleted from the cache
Jan 20 03:41:22: Call 582DAB5B 31B62BBA 5088CE17 195819E5/1 removed
--CALL
Dans les cas où le Billing n’arrive pas à relier les deux legs, on peut voir qu’il y a deux block --CALL--. Un après le Stop du Porta-Sip et un autre après celui de l’Asterisk. La structure est la suivante :
REQUEST--
.
< Asterisk >
< Authentification >
.
--REQUEST
REQUEST--
.
< Porta-Sip >
< Authentification >
.
--REQUEST
REQUEST--
.
< Porta-Sip >
< Start (originate) >
.
--REQUEST
REQUEST--
.
< Porta-Sip >
< Start (answer) >
.
--REQUEST
REQUEST--
.
< Porta-Sip >
< Stop (answer) >
.
--REQUEST
REQUEST--
.
< Porta-Sip >
< Stop (originate) >
.
--REQUEST
CALL--
.
.
.
--CALL
REQUEST--
.
< Asterisk >
< Start (originate) >
.
--REQUEST
REQUEST--
.
< Asterisk >
< Start (answer) >
.
--REQUEST
REQUEST--
.
< Asterisk >
< Stop (answer) >
.
--REQUEST
REQUEST--
.
< Asterisk >
< Stop (originate) >
.
--REQUEST
CALL--
.
.
.
--CALL
L’hypothèse est qu’avec le premier block --CALL-- le Billing termine complètement l’appel et que lorsqu’il reçoit les Start-Stop de l’Asterisk, il les traite comme un nouvel appel.
Remarque : Aucun des appels n’est resté bloqué dans les Active Calls.
Envoi différé des Stop
Nous allons observer ce qu’il se passe quand le Start est envoyé normalement, mais que le Stop est envoyé après un délai. Voici les deux scénarios étudiés :
- Appel sortant vers un téléphone IP enregistré sur un Porta-Sip
- Appel sortant vers un téléphone fixe
- Appel sortant quelconque avec envoi uniquement des Stop
Remarque : Pour tous ces cas, le délai d’attente d’envoi des paquets Stop a été fixé à 60 secondes après la fin d’appel.
[7] Appel sortant vers un téléphone IP enregistré sur un Porta-Sip
Même comportement qu’au cas [1], les legs ne sont pas reliés par le Billing. L’appel est présent dans les Active Calls du fait que le Porta-Sip envoie ses Start-Stop normalement.
En regardant dans les logs, on peut voir qu’il y a bien deux block --CALL-- (explications dans Observations et hypothèses).
[8] Appel sortant vers un téléphone fixe
Même chose qu’au cas [3], sauf que cette fois l’appel est visible dans les Active Calls du fait que les Start sont envoyés normalement. Par contre tant que le Billing ne reçoit pas les Stop, l’appel reste dans les Active Calls. Seul l’Asterisk envoie des Start-Stop, donc pas de problème pour le Billing. Comme on peut le voir dans les logs, il n’y a qu’un seul block --CALL--.
[9] Appel sortant quelconque avec envoi uniquement des Stop
Dans ce cas, seul les Stop sont envoyés avec un délai. Aucun Start n’est envoyés par l’Asterisk. Le comportement est le même que si on avait aussi envoyé les Start avant.
Exemple d’appel vers un appareil enregistré sur un Porta-Sip
On peut voir que les deux legs créés ne sont pas reliés par le Billing. Voici les logs.
Exemple d’un appel vers un téléphone fixe
Ici on voit qu’il y a un seul leg créé par l’Astersik. Voici les logs.
Envoi des Start après les Stop
Nous allons observer ce qu’il se passe quand le Stop est envoyé normalement à la fin de l’appel et que le Start est envoyé après un délai, donc après le Stop. Voici les deux scénarios étudiés :
Remarque : Pour tous ces cas, le délai d’attente d’envoi des paquets Start a été fixé à 60 secondes après la fin d’appel.
[10] Appel sortant vers un téléphone IP enregistré sur un Porta-Sip
L’appel se passe normalement, sauf qu’avec les Start envoyés en retard par l’Asterisk, l’appel sera bloqué dans les Active Calls. Voici les logs.
[11] Appel sortant vers un téléphone fixe
On peut voir l’appel dans le Trace Call grâce à l’envoi des Stop, par contre l’appel sera aussi bloqué dans les Active Calls à cause des Start envoyés en retard. Voici les logs.
* * *