Hello,<br>I have a question about what the proper way to handle a duplicate presentation of an INVITE is.  On occasion I am seeing some packet loss and/or timing issues which are causing some of my end-points to retransmit the INVITE.  Here is what I am doing in the most basic sense:<br>
<br><br>ITSP (Bandwidth.com) --&gt; INVITE --&gt; KAMAILIO --&gt; DISPATCHER --&gt; Asterisk (B2BUA)<br><br><br>I am seeing Bandwidth.com send an INVITE which I already received.   I keep track of all running transactions in a htable which has a key of <br>
<br>$ci::$cs::$ft (as per RFC 3261).<br><br>If I get an invite for something which already has a key in the hashmap, I am currently sending a  &quot;482 Loop 
Detected&quot;, but I don&#39;t think that is correct as it causes the whole call
 to tear down instead of letting it continue and assuring Bandwidth.com that I received the initial INVITE and am currently working on it.<br><br>This is what I am currently doing:<br><br>    ##<br>    ## Check to make sure we don&#39;t already have an active<br>
    ## transaction for this call-id, c-seq, and from-tag<br>    ## RFC3261 - 8.2.2.2<br>    ##<br>    ## We are going to add a key for this unique record if one<br>    ## doesn&#39;t already exist.  The key automatically times out <br>
    ## after 30 seconds, so we need not worry about cleanup<br>    ##<br>    if($sht(loop_check=&gt;$ci::$cs::$ft) == null){<br>        xlog(&quot;L_INFO&quot;,&quot;No transaction found, adding to our hashtable\n&quot;);<br>
           $sht(loop_check=&gt;$ci::$cs::$ft) = 1;    <br>    }else{<br>           xlog(&quot;L_ERR&quot;,&quot;Loop Detected: $ci::$cs::$ft\n&quot;);<br>        sl_send_reply(&quot;482&quot;,&quot;Loop Detected - Duplicate Session Presentation&quot;);<br>
           exit;<br>    }<br><br>Can I just swallow the second INVITE and do an exit; in my script?<br>Should I do an sl_send_reply(100,&quot;Trying&quot;)?<br><br>Any advice would be greatly appreciated.<br><br>Thanks,<br>