On Mon, Aug 30, 2010 at 2:19 PM, Geoffrey Mina <
geoffreymina@gmail.com> wrote:
> 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,
>