This page is designed for information working with SIP at a packet level. It is expected the reader has complete knowledge of RFC 3261.
A number of status codes are sent back from our platform that can do with having a little more description attached to them to aid debugging.
Note that The our platform allows SIP requests to be sent to SIP URIs (incl starting sessions), so any error responses you get back from calling a remote party may have been returned by them, and not us.
To determine the history of a response and how it was received even through forking, we have initial support for the histinfo parameter: although privacy will possibly remove parts of the message it is none the less useful for debugging how a particular target was reached when the target is within our authority.
While this is not strictly an error code given by our platform, the most common case for seeing this message is requests being sent to voip.co.uk rather than proxy.voip.co.uk, or another authority other than proxy.voip.co.uk.
This is sent by our registrar when the time to service the request is higher than normal, and are thus requesting back off. Responses contain a Retry-After header in, and UAs should re-perform the request within a second. Any devices that do not re-attempt the registration are buggy, and the problem should be reported to your SIP vendor after ensuring the problem has not been fixed in the latest version of SIP firmware for your device.
There is some work being done on the SIP protocol itself to correctly handle overload situations. The root cause of this problem is that a number of SIP devices are not using SRV records, and thus are not load balancing themselves.
See http://tools.ietf.org/html/draft-ietf-sipping-overload-reqs/ for more information on the work within the IETF being done to better define how SIP elements should handle overloads.