> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Christina > Zhao > Sent: Thursday, July 15, 2004 12:31 PM > To: [EMAIL PROTECTED] > 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?
Yes, UA X can send a re-invite. > 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? IMO UA Y should definitely not send a 400 if it receives an INVITE when it is expecting ACK. Rather it should send 491. ( unexpected event). This would hopefully cause the other side to retransmit INVITE [ by which time ACK has been received and processed. Alternatively UA Y could be prepared to handle incoming INVITE while waiting for ACK. I am not sure the specs specify a behaviour one way or the other. Have you considered using tcp as SIP transport. thanks Arun > > 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
