Thanks for the reply.

Here is my scenario : 


Client________Kamailio______Destination_1____Destination_2
  |_____INV_______|_______________|_______________|
  |---------------------->|______INV______|_______________|
  |_______________|---------------------->|_______________|
  |_______________|_______________|_______________|
  |_______________|____200_OK_____|_______________|  
  |_______________|<-----------------------|_______________|
  |____200_OK_____|_______________|_______________|
  |<-----------------------|_______________|_______________|                                                   
  |_______________|_______________|_______________|
  |___INV(Retr)____|_______________|_______________|
  |---------------------->|______INV______|_______________|                                                    
  |_______________|------------------------------------------------>|                                                                                                                   
  |_______________|_______________|_______________|

 


As you can see, the client never sends the ACK to Kamailio and retransmits the first INVITE (No To-TAG) again after more than 5s. After this Kamailio uses Dispatcher to send to a destination from a group and chooses Destination_2.

Since the INVITE is sent to Destination_2, my system treats this as a second call being created.

Should this scenario happen under the SIP stack rules? Shouldn't Kamailio send a "491 - Request Pending" on this scenario?

If not, how i can configure Kamailio to behave like that? In my code i have the following conditions for a Request to able to be sent by DISPATCHER : 

                - if( is_method("INVITE") && !has_totag() )

                - if(!t_check_trans())
                
                What other conditions can i setup in order for this INVITE to be treated like a retransmission or being rejected?
                
Best Regards,

A segunda, 13/04/2020, 13:31, Daniel-Constantin Mierla <miconda@gmail.com> escreveu:

By default the transaction that gets a final reply is kept for another 5sec or so in memory to deal with retranmissions, etc ... There is a wait_timer parameter in tm module.

The ACK after 200ok is separate transaction and has no influence on INVITE transaction. For the ACK after 300+ reply, there should be some retransmissons of the reply in the INVITE transaction.

The dialog module is influenced by the missing ACK after 200ok.

Cheers,
Daniel

On 13.04.20 13:18, Duarte Rocha wrote:
Sorry i didn't specify.

It is after the 200 Ok. Will it be different in a reply greater than 300?

Best regards

A segunda, 13/04/2020, 12:16, Daniel-Constantin Mierla <miconda@gmail.com> escreveu:

Hello,

is it about ACK after 200ok or the ACK after 300 or greater reply?

Cheers,
Daniel

On 13.04.20 13:04, Duarte Rocha wrote:
Greetings,

How much time will Kamailio keep a transaction active if the ACK to a INVITE is never received by Kamailio?

Best Regards,

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda