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@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@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@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

Cool.

Thanks to you both for your input. I am promoted my new config to production and we'll see if we have any more failures with retransmissions. So far so good though.

Thanks, Geoff

On Mon, Aug 30, 2010 at 2:02 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

2010/8/30 Geoffrey Mina geoffreymina@gmail.com:

...

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

In case the transaction already exists t_check_trans() returns 0 so the script automatically terminates.

-- Iñaki Baz Castillo ibc@aliax.net