[SR-Users] Duplicate INVITE Handling

Uriel Rozenbaum uriel.rozenbaum at gmail.com
Mon Aug 30 19:40:17 CEST 2010


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 <geoffreymina at 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.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
>> >
>> >
>
>



More information about the sr-users mailing list