[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    [asterisk-dev] SIP autopeer bug and general retransmission
From:       "Kirill 'Big K' Katsnelson" <kkm () adaptiveai ! com>
Date:       2010-02-26 6:46:40
Message-ID: 4B876E50.5000207 () adaptiveai ! com
[Download RAW message or body]

I am trying to understand the general idea behind SIP retransmission 
implementation.

First, there is a related bug that makes manager event stream rather 
unusable: https://issues.asterisk.org/view.php?id=16908

The repro in the ticket is artificial; in real life the scenario happens 
when a reply to client's un-REGISTER packet is lost, and the client 
retransmits it.

As I am trying to follow the code path, it seems to me that in general 
there is no concept of true retransmission of a reply message. The code 
is supposed to rely on req->ignore flag, set if the request has a 
duplicate CSeq, but instead of just pulling the last reply from the 
dialog and sending it again, code calls the original incoming_* handler, 
assuming idempotence. I do not know about other handlers, but REGISTER 
messages for realtime and automatic peers are clearly NOT idempotent.

So the bug is actually TWO bugs: one is as described, and another is 
that the same thing occurs in a retransmission scenario. I can think of 
a fix that solves the latter issue alone, but none that would fix both.

Why is so complex an idea employed? Should that be changes -- can just 
the last reply be kept with the dialog and retransmitted when requested 
by the client, and why not if not?

  -kkm

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]