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]
Yes, certainly. But UA Y is still wrong to send a 491 without real cause.
By the same reasoning, why do not always respond to an INVITE by a 500? This is correct from the RFC3261 point of view - but it does not made the system very useful, does it?
* 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.
No, TCP does not solve the problem. The reliability of the 200 is assured end to end. This means that even if TCP is used here UDP can still be used somewhere between two proxies or a proxy an a UA, and the 200 or the ACK can be lost somewhere.
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
