[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