Duplicate INVITE Handling - sr-users

30 Aug 2010

Hello,
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:

ITSP (Bandwidth.com) --> INVITE --> KAMAILIO --> DISPATCHER --> Asterisk
(B2BUA)

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

$ci::$cs::$ft (as per RFC 3261).

If I get an invite for something which already has a key in the hashmap, I
am currently sending a  "482 Loop Detected", but I don'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.

This is what I am currently doing:

    ##
    ## Check to make sure we don't already have an active
    ## transaction for this call-id, c-seq, and from-tag
    ## RFC3261 - 8.2.2.2
    ##
    ## We are going to add a key for this unique record if one
    ## doesn't already exist.  The key automatically times out
    ## after 30 seconds, so we need not worry about cleanup
    ##
    if($sht(loop_check=>$ci::$cs::$ft) == null){
        xlog("L_INFO","No transaction found, adding to our
hashtable\n");
           $sht(loop_check=>$ci::$cs::$ft) = 1;
    }else{
           xlog("L_ERR","Loop Detected: $ci::$cs::$ft\n");
        sl_send_reply("482","Loop Detected - Duplicate Session
Presentation");
           exit;
    }

Can I just swallow the second INVITE and do an exit; in my script?
Should I do an sl_send_reply(100,"Trying")?

Any advice would be greatly appreciated.

Thanks,