SIP Loop Detection — Will it go Round in Circles

It is said that the definition of insanity is doing the same thing over and over again and expecting different results. I will venture to say that the technology variant is “Garbage in. Garbage out.” To stretch the phraseology one more inch, “You can’t make a silk purse from a sow’s ear.”

All of which brings me to today’s topic – loop detection in SIP.

Before I venture into the details, I want you to imagine a series of SIP proxies — A, B, and C. Each proxy has its own routing table to move calls around the network. Now, picture a situation where A receives a call that it routes to B. B checks its tables and routes the call to C. C checks its tables and routes the call to A. A checks its tables and routes the call to B. You see where this is going, don’t you?

The concept behind loop detection, sometimes referred to as loop avoidance, is the ability to recognize a call that is moving around the network, but never actually terminating at an endpoint. Without the ability to detect and stop looping calls, you will quickly consume the resources of your SIP servers causing slowdowns or worse, crashes. Loop detection allows a SIP entity to realize that it has seen a call one too many times and stop it dead in its tracks.

SIP comes built-in with a header that supports loop detection. The Max-Forwards header contains a numeric value that is set by the original sender of a SIP message. This value is decremented by one (1) every time it passes through a SIP server such as a proxy. If the value ever reaches zero (0), the message is rejected with a 483 Too Many Hops response.

After careful consideration of network topologies, the creators of SIP decided that the default for Max-Forwards should be 70. This number was chosen to guarantee that a message would not be improperly dropped when there were no actual loops. For a decent sized enterprise this number seems big, but when you consider SIP in the PSTN, it’s reasonable enough. A user agent is allowed to lower the number, but should do so only if it’s sure that it will not cause a loop to be detected where none exists.

Individual vendors can implement additional methods to detect loops and Avaya has done so with its Session Manager product.

Max-Forwards stops a looping message on the basis of how many times a server has seen that message. However, it does nothing in the way of how often that message is seen time-wise. Avaya decided that having a message pound away at a Session Manager is just as bad as seeing it one too many times and added another level of loop detection.

Within a Session Manager’s configuration, you will find three settings that assist in loop detection. These settings are:

Loop Detection Mode: The default value is Off. Setting it to On activates loop detection for all Entity Links associated with a SIP Entity.

Loop Count Threshold: The default value is 5. The allowed range is 2 to 10,000.

Loops Detection Interval (in msec): The default value is 200 msec. The allowed range is 10 msec to 10,000 msec.

Session Manager loop detection is defined as the following:

If the number of incoming requests with the same combination of SIP-URI, To, From, and PAI header values reaches the administered Loop Count Threshold value within the Loop Detection Interval time, Session Manager rejects these requests.

For example, if the successive loop call arrives at Session Manager after 40 milliseconds (because of the propagation delay of the intermediate hops) and the administrator needs to break the loop on the fifth loop call instance, the recommended Firewall configuration must have Loop Count Threshold as 5 and Loop Detection Interval as 200 milliseconds.

By using Max-Forwards and these Session Manager additions, loops can be detected and stopped by both the number of times a Session Manager sees a particular message and the frequency of its arrival.

However, even without Session Manager, there is no reason why you need to worry about doing the same thing over and over and over and over and over and over….again. Max-Forwards stops the insanity before it has a chance to take over.

Now, if only such a header could be set for some people I know.


  1. As always, Fantastic. My Max-Forward is set to infinite to read your article.

  2. Thank you! I wrote this one in response to a question someone emailed to me. I like it when someone helps me come up with a new topic to discuss.

  3. Paul Vice · · Reply

    Great info! I’ve worked on many SM’s and never knew there was additional level of Loop Detection. What release of SMGR-SM did this become available?
    I really appreciate the work you are doing here. Keep them coming!

  4. I am not sure when it became available in SM, Paul. It might have been there since release 1.0, but I don’t have the older documents. For more information, please refer to the following document.,d.b2I&cad=rja

  5. Shekhu · · Reply

    Hi Andrew, I was trying to understand SIP and stumbled upon your articles. They are short and clear. Really liked them. I have a question though on Max-Forwards.

    According to RFC 3261, Section 8.1.1, a request generated by UAC MUST contain Max-Forwards header. But, in section 16.3, Request validation, Max-Forwards check, it says:

    If the request does not contain a Max-Forwards header field, this check is passed.

    Could you please help me understand if Max-Forwards is really a mandatory header or not? If Max-forwards is not present in the request, why shouldn’t the proxy reject the message?


  6. Shekhu, I honestly don’t know why the RFC would say that. Perhaps if the header gets stripped out by an SBC, but I am not sure why it would do that. I would just write my code according to the RFC and assume that the non-existent case will never occur.

  7. Shekhu · · Reply

    Thanks Andrew.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: