Thanks - it helps. Greetings,
Piotr "Tomasz Zieleniewski" napisał(a): Hi Piotr, In Your case transport error from point 4 appears when proxy B processes a response for ICTs corresponding to the described IST on server B. If there is a transport error then IST should transition to the terminated state. This will not break anything here, the Server A ICT will still complete because any final response received by Server B will be processed statelessly and send to server A. And If Server B receives INVITE retransmission it treats it as initial request and creates new IST. There is no dialog early or confirmed so nothing is wrong. Both Server A and Server B proceed without any problems. Kind regards, - Tomasz Zieleniewski 2009/7/23 Piotr Gutkowski <[email protected]> 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 [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
