Paul/Christina, * I think in step 8 the UA Y should send 491[unexpected event]. This should cause the UA X to re-initiate second re-invite transaction [ step 7]
* Hopefully the UA Y would get ACK before the next re-INVITE and the dialog should recover. * Afcourse you could use tcp as transport and not have that problem at all. thanks Arun 1. I think in step 7 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Marc > Petit-Huguenin > Sent: Friday, July 16, 2004 9:33 AM > To: Paul D.Smith > Cc: SIP-IMPLEMENTORS WG > Subject: Re: [Sip-implementors] question for re-re-invite > > > Sorry Christina to hijack > > Paul D.Smith wrote: > > Christina, > > > > See RFC3261, section 14.2, page 89. To quote... > > > > If a UAS generates a 2xx response and never receives an ACK, it > > SHOULD generate a BYE to terminate the dialog. > > > > So UA Y should have BYEd the session. > > No. In step 9 a retransmission is received, meaning that it > was less than > 64*T1 seconds after sending the first 200. Section 13.3.1 > says "If the > server retransmits the 2xx response for 64*T1 seconds without > receiving an > ACK, the dialog is confirmed, but the session SHOULD be > terminated. This is > accomplished with a BYE..." > > > It is possible that for some > > reason the BYE never reached X in which case Y believes the session > > is gone. For the second re-INVITE I would therefore have expected a > > 481 not a 400. > > > > So to answer your questions, in step 7, the UA (X) can reINVITE > > because it has no way of knowing that the ACK didn't reach UA Y. > > > > In step 8, I would have expected a 481 error, but a 400 might > > occur - I would need to see the actual messages exchanged to > > comment further. > > > > FYI, if the UA (Y) believed that the reINVITE of step 4 were > > outstanding, it should have sent a 491 response to the reINVITE of > > step 7 (as per RFC3261, 14.2). > > > > Paul D.Smith > > Network Protocols Group > > Data Connection Ltd (DCL) > > Tel: +44 20 8366 1177 Email: [EMAIL PROTECTED] > > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf > Of Christina > > Zhao > > Sent: 15 July 2004 17:31 > > To: SIP (E-mail) > > Subject: [Sip-implementors] question for re-re-invite > > > > > > I met a problem when I study the SIP Spec. Can anyone give > me his/her > > advice for that? Thanks a lot. > > > > The scenario is: > > 1. UA Y invited UA X. > > 2. UA X 200ed UA Y. > > 3. UA Y acked UA X. (SIP Session is established) > > > > 4. UA X re-invited UA Y. > > 5. UA Y 200ed UA X. > > 6. UA X acked UA Y. (It seems that UA Y doesn't get it because UA X > > receives retransmission of 200 in step 9) > > > > 7. UA X re-invited UA Y AGAIN (Is it valid?) > > 8. UA Y 400ed UA X. (Is it valid?) > > > > 9. UA X received retransmission of step 5. > > > > Q1: > > For UA X, we think step 7 is valid because the first re-invite > > transaction is already over, is that true? > > Q2: > > We are not very clear about step 8. For UA Y, the 2nd > re-invite comes > > before it receives ack of 1st re-invite. What should UA Y do? > > > > Regards > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
