Problem of repeating 487 messages of Verizon

Emin Gabrielyan

Switzernet

2007-05-25

As already reported [htm] in order to close the cancellation transactions, Verizon needs to t_relay() the non-loose-route ACKs of Switzernet. For such cases the t_relay() function will not forward the ACK message (as its name suggests) but will only close the transactions (which makes it indispensable). The ACK message can be processed in one of the following blocks:

if(loose_route())

{

#The ACKs of answered calls are processed here

t_relay();

#Here the ACKs are forwarded

exit;

}

...

if(method=="ACK")

{

#The ACKs of cancelled calls are processed here

if($si=="212.249.15.4" || $si=="195.129.125.74")

{

#You may need this part to avoid self-looping

#Use your IP addresses in the condition

exit;

}

t_relay();

#Here OpenSER will not forward the ACKs

exit;

}

In the first if-block the ACK messages are forwarded [png]. In the second if-block the t_relay() function does not forward the ACK messages, it ensures the correct closure of cancellation transactions.

The following example of an incoming cancelled call (from PSTN via Verizon to Switzernet) shows how the cancellation transaction should look like:

[png], the captures of all 14 messages [pdf], [txt], [ps]

By commenting in our current configuration file the t_relay() function for non-loose-route ACKs we can reproduce in our server exactly the same erroneous behaviour for incoming calls as we observe now for outgoing calls at your side.

You may wish to look at the currently used configuration file of our server for a reference (please report any eventual errors) [cfg].

Our last tests with outgoing calls (2007-05-25 14:30) shows that the error of your server (if our analysis is correct) is still present [png].

* * *