jsip
  1. jsip
  2. JSIP-418

SIP stack sending "482 Loop detected" every second forever

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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(SIPServerTransaction.java:1169) [fireRetransmissionTimer() -- gov.nist.javax.sip.stack.SIPServerTransaction@bc655bf8 state Completed Transaction]
      DEBUG - gov.nist.javax.sip.stack.SIPServerTransaction.resendLastResponseAsBytes(SIPServerTransaction.java:1212) [resend last response SIP/2.0 482 Loop detected

      The repetition will never stop.

        Activity

        Hide
        vralev added a comment -

        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.

        Show
        vralev added a comment - 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.
        Hide
        vralev added a comment -

        Tests got broken. So reopening this issue.

        Show
        vralev added a comment - Tests got broken. So reopening this issue.
        Hide
        vralev added a comment -

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

        Show
        vralev added a comment - A better fix was applied. Now Timer H is started by the spec and times out accurately. Closing the case.

          People

          • Assignee:
            vralev
            Reporter:
            fre
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: