Well, i read the documentation again, and found t_lookup_request, and 
t_check_trans.
Question 1 - t_lookup_request() creates the transaction if it doesn't exist, 
correct?  However, t_check_trans only checks to see if the transaction already 
exists, correct?

Question 2 - Assuming that t_check_trans only checks to see if the transaction 
already exists, then is the following correct?

Currently I do the following (after stripping out a bunch of stuff)

if (!t_relay()) {
   if (!is_method("ACK")) {
      sl_reply_error();
   }
}

should this, instead, actually look like the following?
if (is_method("INVITE")) {
   if (if !t_check_tran()) {
      t_relay();
   } 
} else if (!is_method("ACK")) {
   sl_reply_error();
}


      
----- Original Message -----
From: Klaus Darilion <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: users <[email protected]>
Sent: Thursday, December 14, 2006 2:06:01 AM GMT-0600
Subject: Re: [Users] Duplicate INVITEs

Mahesh Paolini-Subramanya wrote:
> We're seeing sporadic situations where fones 
> a) send an INVITE 
> b) ignore the 100-Trying response, and instead 
> c) send another INVITE with the same sequence number. 
> 
> The question is, What should happen here? 

If the message is completely identical then it is a retransmission. 
Retransmissions should be detected by tm module (e.g. t_relay()) and 
absorbed,

regards
klaus


> Currently, we send back a 500 response (server error). 
> Is this correct? (i think not, cause it invariably causes the fone to go fast 
> busy). 
> Is this some other response that should occur? 
> 
> poring over 3261 resulted in a headache, and no additional clarity... 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> [email protected]
> http://openser.org/cgi-bin/mailman/listinfo/users


-- 
Klaus Darilion
nic.at



-- 
*******************************************
Mahesh Paolini-Subramanya      (703) 386-1500 x9100
CTO                                         [EMAIL PROTECTED]
Aptela, Inc.                               http://www.aptela.com
"Aptela: How Business Answers The Call"
*******************************************


_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users

Reply via email to