Hi,
Marc Petit-Huguenin wrote:
Reposted, as I really would like to have a definitive answer on this.
Thanks.
I would like to have a confirmation that an UAS must be ready to
receive a
new INVITE in a dialog as soon a response was sent for the previous
INVITE.
More precisely, the UAS must not wait for the ACK before accepting
the next
INVITE.
My reasoning is based on the fact that RFC3261 section 14.1 says that
"If
there is an outgoing INVITE client transaction, the TU must wait
until the
transaction reaches the completed or terminated state before
initiating the
new INVITE." As an INVITE transaction reaches the completed or
terminated
state as soon a non-provisional response is received, the next INVITE
can
be sent at the same time the ACK for the 200 response is sent. As the
packet ordering can change, the INVITE can arrive at the UAS before the
ACK. So this mean that the server should be prepared to receive the next
INVITE before receiving the ACK.
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. A phone need not wait for 32 sec
"After" establishment of the call. There after it can put on hold.
Hope this explains :)
mukul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
