Hi,
Marc Petit-Huguenin wrote:
[snip]
Completed State for client-invite is reached only when the response was 3xx-6xx, and not any non-provisional response (I mean 200 ).
As per section 13.3.1.4 , 2xx retransmission is handled by UA core.A 2xx response is passed to Transport layer periodically, for all protocols, until an ACK is received. This retransmission starts at T1 seconds, and doubles until it reaches T2 seconds.
Finally if the there is no ACK, session SHOULD be terminated, by sending a BYE.
So Answer to your question : UAS must wait for an ACK, before accepting any request within the dialog.
Again, I disagree with this interpretation. If it was true, it means that the UAC must wait 32 seconds (64*T1) before sending the second reINVITE to be sure that the ACK is received by the UAS, or that a BYE is sent by the UAS in case all the ACK are lost.
UAC need not wait to send a re-Invite, it is the UAS that say no to the re-Invite, because the 3-way handshake of previous Invite(The original Invite) is not yet complete. It does not make any sense to change the parameters, until there "exist" some parameters (which will exist only after the Call is esatblished, i.e. Invite-Ok-Ack is Complete).
This means that a phone must wait 32 second after the establishment of a call before be able to put a call on hold. And wait again 32 seconds before be able to un-hold. No very useable.
Establishment of call means the RTP session has started. This wont until the 3-way handshake is complete.
Nope. The RTP session is not started by the ACK. The callee party can start the RTP session as soon the INVITE (with SDP) is received. The caller party can start the RTP session as soon a response with a SDP is received (both depending on the Content-Disposition value - or lack of)
A phone need not wait for 32 sec "After" establishment of the call. There after it can put on hold.
If we follow your explanation of the UAS behavior, we have to wait 32 seconds before sending the reINVITE to be sure that the reINVITE will not be rejected because the ACK is lost.
I think that if it was the intent of the RFC authors that the next reINVITE had to be rejected until an ACK is received for the previous INVITE, they would have say that the response must contain a Retry-After. This is what was done with the 491 response.
Also if we follow your explanation, the UAC will have to retry the reINVITE until it is accepted, i.e. until the UAS receive the ACK. But automatically generated reINVITE are explicitly discouraged in the spec (section 14).
So I think that you are right when you say that the phone must not wait 32 seconds to send a reINVITE, but this is because the UAS must not wait to receive a ACK before accepting the next reINVITE.
Hope this explains :) mukul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
