We observed that the NAT gateways of certain customers change or expire the port mapping entry of the UA's SIP port, sometimes more frequently than the registration frequency of the UA. As a result, after a certain time the UA is not reachable for incoming calls. In this experience we send notify messages to all UA known to be registered on the SIP server and we account the rate of replies sent back by UA. If the port mapping of a user is gone, the UA will not respond. However, as we keep sending the notify messages (to the address recorded in the location table), as soon as the UA sends us a new register and provides us an updated port value, the flow of notify messages will mandatorily keep the NAT port open until the next registration. That is irrespectively of the delay it will take to come. This means that we have to observe high rate of losses of replies to notifies, which will drop gradually along the reception of registration updates coming from slow UAs. We are sending notifies to all users with intervals between the waves of notifies equal to 30 seconds. The wave itself takes about 4 seconds. Thus, the periodicity is of approximately 4 seconds.
The excel file [110621-astrad9-notify-chart.xlsx] containing the full data is attached as well.
On 2011-06-21 10:27, Oussama Hammami wrote:
Server: astrad9.switzernet.com
Date From: 2011-06-20 18:15
Date To: 2011-06-20 20:31
+---------------------+---------------------+-----------+-----------+ | START | STOP | COUNT = 1 | COUNT > 1 | +---------------------+---------------------+-----------+-----------+ | 2011-06-20 15:00:00 | 2011-06-20 15:30:00 | 208 | 26 | | 2011-06-20 15:30:00 | 2011-06-20 16:00:00 | 207 | 27 | | 2011-06-20 16:00:00 | 2011-06-20 16:30:00 | 208 | 26 | | 2011-06-20 16:30:00 | 2011-06-20 17:00:00 | 209 | 25 | | 2011-06-20 17:00:00 | 2011-06-20 17:30:00 | 209 | 25 | | 2011-06-20 17:30:00 | 2011-06-20 18:00:00 | 209 | 25 | | 2011-06-20 18:00:00 | 2011-06-20 18:30:00 | 223 | 11 | | 2011-06-20 18:30:00 | 2011-06-20 19:00:00 | 234 | 0 | | 2011-06-20 19:00:00 | 2011-06-20 19:30:00 | 234 | 0 | | 2011-06-20 19:30:00 | 2011-06-20 20:00:00 | 234 | 0 | | 2011-06-20 20:00:00 | 2011-06-20 20:30:00 | 234 | 0 | | 2011-06-20 20:30:00 | 2011-06-20 21:00:00 | 207 | 27 | | 2011-06-20 21:00:00 | 2011-06-20 21:30:00 | 208 | 26 | | 2011-06-20 21:30:00 | 2011-06-20 22:00:00 | 207 | 27 | | 2011-06-20 22:00:00 | 2011-06-20 22:30:00 | 207 | 27 | | 2011-06-20 22:30:00 | 2011-06-20 23:00:00 | 209 | 25 | +---------------------+---------------------+-----------+-----------+
On 2011-06-17 17:24, Emin Gabrielyan wrote:Below is a chart showing, contrary to all expectations, the increase of reply losses to notify methods.
We were expecting to have 0% losses after a while.
This increase is probably due to an error in the script that collected the data.
The script must be done again. BTW it must not consume 90% of CPU (and the reason is probably in the same error).
Attached you will find the Excel file computing this chart.
Emin
On 2011-06-17 16:21, Task-by Oussama Hammami wrote:Ci-joint les fichiers Excel représentant les résultats des testes d’envoi de Notify.
Astrad6 :
Sur ce serveur on a lancé le script d’envoi de notify ainsi que ngrep à 2011-06-16 16:02
On a arrêté le script ngrep à 2011-06-16 18:36
Notify ngrep: 110616-astrad6-notify-ngrep.xls
Location history: 110616+1-astrad6-location-history.xls
Astrad7:
On a uniquement lancé le script d’envoi de notify à 2011-06-16 16:11
Location history: 110616+1-astrad7-location-history.xls
