Actually in TU, if the dialog doesn't go into the establishment state, it can go away after sometime. This should trigger all the IST which it has created to go away as well. In this case, the IST shall be in Proceeding state. So, there has to be user defined "establishment timer" at TU level.
We have similar situation in ICT proceeding state, where we can run similar timer. Regards, Somesh -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Piotr Gutkowski Sent: Thursday, July 23, 2009 3:12 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] INVITE retransmissions after IST transaction iskilled. Hello. Let's assume that we use unreliable transport like UDP and retransmissions are controlled by transaction mechanism. We have such scenario: 1. Server A ICT sends first INVITE request to Server B. 2. INVITE reaches Server B - IST is created, 100 Trying is send and lost. 3. Following INVITE requests retransmission are lost. 4. IST is killed because of transport error. 5. Long delayed (because of big transmission delay for example) INVITE retransmission comes to Server B. There is no matching IST transaction (because it was killed). Message is passed to the core. At this moment should IST transaction be recreated? What is the proper handling in point 4? If we use UDP should we stay in PROCEEDING state forever and don't kill the IST transaction? Greetings, Piotr _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
