Hey, I do exactly as you say, I had no issues so far. I guess you can use the retvalue to do something else, I'm just not interested on doing anything else (as it handles retransmissions very well).
On Mon, Aug 30, 2010 at 2:36 PM, Geoffrey Mina <geoffreym...@gmail.com> wrote: > 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.rozenb...@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 <geoffreym...@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@lists.sip-router.org >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> > >> > > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
