From: Richard Good <[EMAIL PROTECTED]> I have a query regarding the 302 (Temporarily Moved) message flow shown in RFC 3665.
Essentially if a SIP client receives a 302 message in response to an INVITE it should ACK this message and then using the address in the contact field send a new INVITE request. "... and then using the address(es) in the contact field(s) send new INVITE request(s)." In the message flow shown in RFC 3665 (see section 3.6. Session via Redirect and Proxy Servers with SDP in ACK) the new INVITE request has the same To field, From field, To Tag and Call ID - the Request URI uses the address specified in the Contact field of the 302 response. Essentially this new INVITE is part of the same dialog but has a different Request URI. Yes, it is a fork of the original request. My questions are: Is the 302 response not a final response? Does it not end the dialog? Like any final response, it ends one fork of the original request. The transaction ends based on the propagation back toward the UAC of the final response(s). The transaction is ended when ultimate final response is returned to the application function in the UAC. Whether there is a dialog in existence after that point depends on what the request and final response was. Think of the INVITE transaction as a dynamically-growing tree. In this instance, the very root of the tree can grow additional branches. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
