> RFC 3261 Section 14.1 said... "The rules for transmitting > a re-INVITE and for generating an ACK for a 2xx response to > re-INVITE are the same as for the intital INVITE". Consider > the following re-invite scenerio > > A B > ---- RE-INVTE (cseq 1) ---> > ---- RE-INVTE (cseq 1) ---> /* re-transmission */ > > <------ 200OK (cseq 1) ------ > ----- ACK (invite 1) ---> > > ---- RE-INVTE (cseq 2) ---> > <------ 200OK (cseq 1) ------ /* response to the first > re-transmission re-invite */ > <------ 200OK (cseq 2) ------ > ----- ACK (invite 1) ---> /* should the ua reply the > ACK for the > re-transmission 200 OK within 64*T1? */ > ----- ACK (invite 2) ---> > > My question is "should the ua reply the ACK for the > re-transmission 200 OK within 64*T1"?
Yes. RFC3261 section 13.2.2.4 discusses it a little. And the proposal of others to introduce a delay at UAC between re-INVITEs is not really needed and not mentioned within rfc3261. However some vendors might do it as a work around. RFC3261 is potentially a little ambiguous concerning what to do if a re-INVITE is received prior to ACK. Thus if ACK not really important (SDP not expected), some vendors might allow re-INVITE to continue at UAS. If UAS desires the ACK before handling subsequent re-INVITE, a 500 with Retry-After might be returned. Or the UAS might silently discard the re-INVITE and wait for resending of ACK and re-INVITE when non reliable transports being used. Or the UAS might queue the re-INVITE until the ACK is received. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
