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.
As always, Fantastic. My Max-Forward is set to infinite to read your article.
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.
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!
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. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCsQFjAA&url=https%3A%2F%2Fsupport.avaya.com%2Fcss%2FP8%2Fdocuments%2F100168166&ei=jeQyU4HTIKqw2wXoh4HwDw&usg=AFQjCNHlSMHkE7CuWRjLL9PRgNkDu7uaGg&sig2=vO3eYvWpDL-lYiqgDvT3Eg&bvm=bv.63738703,d.b2I&cad=rja
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?
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.
Came accross your valuable SIP blogs while searching for a solution to an ongoiung problem.
I have a Home Videophone system (Fasttel server) connected to a couple (2) DIVUS videoPhone Soft clients and to 1 gate station (front door).
One soft client keeps telling me Error 482 – Loop Detected.
I can’t find the reason; SIP server is set the exact way as on the other working device, it has it’s own extension (Sip USer and password).
Can you point me to the solution?
All I can suggest is looking at traces. Is the message really bounding around the network? Sorry I can’t help beyond that.
Hello Dear Andrew
Firstly thank you for this kind of articles, regarding Max-Forwards, I have a customer that is sending this parameter as Max-Forwards: 15
They have Good call and bad Calls , checking that on both traces, this parameter is equal, my question is if this value of 15 can impact on this scenario,
Just I noted that on Good call Via is:
Via: SIP/2.0/UDP 18.104.22.168:5060
And on Bad Call Via is:
Via: SIP/2.0/UDP 22.214.171.124:5060
And Bad Call is released with casue SIP : Status-Line: SIP/2.0 481 Call/Transaction Does Not Exist
We are expecting call from 126.96.36.199
Any comment will be appreciatted
I would expect a 403 Too many hops if Max_Forwards was reached.
Thank you for your prompt response.
In this case the bad Call is released with 481 Call/Transaction Does Not Exist , I asumed that it is due Via Header differences , it is OK?
Got SIP response 483 “Too Many Hops” back from xx.xxx.xx.xxx:5060
— No one is available to answer at this time (1:0/0/0)
Getting this error when making out going sip call
What is Max-Forwards set to?
in sip.cong Max-Forwards given as 70 and 250 also, but getting the same error.