Issue Details (XML | Word | Printable)

Key: JSIP-418
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: vralev
Reporter: fre
Votes: 2
Watchers: 2

If you were logged in you would be able to see more operations.

SIP stack sending "482 Loop detected" every second forever

Created: 20/Mar/12 04:26 PM   Updated: 27/May/13 10:47 PM   Resolved: 27/May/13 10:47 PM
Component/s: None
Affects Version/s: current
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Java Source File (16 kB) 20/Mar/12 04:26 PM - fre

Participants: fre and vralev

 Description  « Hide

When the same INVITE message is received several times by the sip stack, it begins sending "482 Loop detected" every second forever.

It's not so easy to reproduce it. I've patched the standard simplecallsetup shootist in "trunk\src\examples\simplecallsetup" (see attached file).
After the first connection has been established and terminated via BYE, my code begins after 4 seconds to resend the same INVITE message without transaction every seconds 30 times.

The shootme will detect this replayed message and calls DialogFilter.sendLoopDetectedResponse(). From now on it sends the "482" message every second.

When receiving the first shootist log line "[java] Response received : Status Code = 482 CSeq: 1 INVITE" you can stop shootist.
After having stopped shootist I've left shootme running for 3 minutes, then stopped it and took a look in the shootmedebug.txt.
You'll see the following lines more that hundred times:

DEBUG - gov.nist.javax.sip.stack.SIPServerTransaction.fireRetransmissionTimer( [fireRetransmissionTimer() -- gov.nist.javax.sip.stack.SIPServerTransaction@bc655bf8 state Completed Transaction]
DEBUG - gov.nist.javax.sip.stack.SIPServerTransaction.resendLastResponseAsBytes( [resend last response SIP/2.0 482 Loop detected

The repetition will never stop.

vralev added a comment - 25/May/13 03:29 AM

That was a very useful testcase and a hairy issue. It should be fixed in trunk now.

I think the 482 error by itself is fair, although not very accurate by the spec. The real problem is that the transaction leaks together with an active timer which is dangerous from DoS perspective. Similar issue affect all error invite transactions that are not ACKed so indeed the scope of the issue is quite big. Thanks for the report and the example code.

vralev added a comment - 27/May/13 06:01 PM

Tests got broken. So reopening this issue.

vralev added a comment - 27/May/13 10:47 PM

A better fix was applied. Now Timer H is started by the spec and times out accurately. Closing the case.