Hi All, All this is also based on whether the Offer/Answer is complete or not. Once an Offer/Answer exchage is complete, the endpoint can always send a ReINVITE. If not say the UAC has sent an INVITE without an Offer and got an offer in the 200, it has to send an answer in the ACK. In this case neither the UAC nor the UAS can send a ReINVITE that changes the SDP. However can a ReINVITE for remote target refresh can always be sent...?
-Badri -----Original Message----- From: Marc Petit-Huguenin [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 4:51 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] reINVITE Mukul Purohit wrote: >>> 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
