Optimize User Experience by Filtering Slow SIP Registrations

In the previous post we learned how to eliminate the “zombie” registrations – registrations which are not valid or reachable anymore. Nevertheless, things are not only black or white , we do have shades of gray – meaning we may have valid and reachable destinations, but with slower or faster response times. This may happen due to network aspects like slow data links, long IP routes or temporary congestion.

The slow registrations (slow to reach) may have a negative impact on the SIP service (more retransmissions, higher chances of a timeout of call setup), but also on the user experience, like an increased Post-Dial-Delay (PDD) for the caller.

Even more, in scenarios with multiple registrations (for a user), you may want to prioritize the fast responding registrations and avoid the slow ones.

So, what does OpenSIPS have to offer in order to detect and deal with such slow registrations?

Detecting slow registrations

As per the previous post, OpenSIPS is able to ping (with OPTIONS requests) the registrations in order to learn their status. The same pings can be used to learn the round-trip (or time to respond) for the registrations – yes, to learn how fast or slow they are.

The user location (usrloc) module provides means to report the slow registration via the latency_event_min_us and/or latency_event_min_us_delta module parameters – if a registration’s response time get below the threshold, an E_UL_LATENCY_UPDATE event will be raised.

A custom logic may be implemented (via the event routes, for example) in order to deal with the slow registrations – xlog’ing it, reporting it further or even deleting it.

# raise an event for any 425+ ms pinging latency
modparam("usrloc", "latency_event_min_us", 425000)
# raise an event only if a contact has pinging latency swings of 300+ ms
modparam("usrloc", "latency_event_min_us_delta", 300000)

event_route[E_UL_LATENCY_UPDATE]
{
    xlog("Registration $param(uri) of user $param(aor) is slow as $param(latency)\n");

    # remove only the detected contact
    remove("location", $param(aor), $param(uri));
}

Filtering the slow registrations

The registrar module (the module managing the SIP registrations) may be used in a more pro-active manner when comes to detecting slow registrations.

The simplest usage is to filter out – when performing registrations lookups – the registrations/contacts below a certain threshold of slowness. That’s it – if the registration is too slow, it will be discarded.

The lookup() function has a dedicated flag max-ping-latency for this purpose. When using this flag, be careful and enable the OPTIONS pinging (with delay detection) for the registrations.

...
# skip registrations slower then 0.5 seconds
if ( !lookup("location", "max-ping-latency=500000")) {
    send_reply(480,"Unavailable");
    exit;
}
...
t_relay();
...

Depending on the routing scenario you may have, it may be a good idea not to discard the slow registrations, but to use all the working ones. In such case, of course, you may consider using the slow registrations as a last resort. So yes, you want to have the registrations sorted based on their time to respond . First try the fast ones and if no answering, try the slow ones also.

The same lookup() function has a different flag sort-by-latency to trigger the sorting – latency based – of the available registrations. This may be useful in call forking scenarios. For example, the call may be subject to serial forking, from fast to slow registrations. This may be achieved via the serialize_branches() script function.

route{
   ...
   # sort registrations based on their latency
   if ( !lookup("location", "sort-by-latency")) {
       send_reply(480,"Unavailable");
       exit;
   }
   ...
   serialize_branches(1,1);
   next_branches();
   ...
   t_on_failure("serial_forking");
   t_relay();
   ...
}
failure_route[serial_forking]
{
   if (t_was_cancelled())
      exit;
 
   # consume the next available branch
   if (next_branches()) {
      t_on_failure("serial_forking");
      t_relay();
   }
}

Conclusion

OpenSIPS offers a wide range of possibilities when comes to checking the health of the registrations – from removing zombie registrations to filtering/sorting the registrations based on their latency.

Implementing such policies will increase the resilience and performance of your service, and it will also improve the user experience when comes to dialing.