[SR-Users] Duplicate INVITE Handling

[Geoffrey Mina]

Cool.  So in theory, i should just be able to place

t_check_trans();

right inline in my script in place of all my incorrect logic and it will
just take care of everything, right?  If I am reading this correctly, I
don't even need to conditionally check to see the result as I am only
concerned about the retransmission scenario and the t_check_trans() call
will break/exit the script...

Thanks for your help.

On Mon, Aug 30, 2010 at 1:28 PM, Uriel Rozenbaum
<uriel.rozenbaum at gmail.com>wrote:

> Hi,
>
> Check t_check_trans() from tm module.
>
> It does all on its own
>
> http://kamailio.org/docs/modules/1.5.x/tm.html#id2509242
>
> Cheers,
> Uriel
>
> On Mon, Aug 30, 2010 at 2:19 PM, Geoffrey Mina <geoffreymina at 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,
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100830/07634107/attachment.htm>