Is it correct to call it "forking", when a re-INVITE is sent to alternative IP addresses resolved from the DNS? In this case, no new dialog is established and the tags established in the dialog prevail, regardless of the number of branches that send final responses. If a Contact/Route (remote target, in the RFC snippet below) is established in a dialog which reesolves to multiple alternate addresses, the handling of the request, by any one of the hosts at those addresses, must be idempotent (except when they cannot handle a request due to resource unavailability (like 503), which could be host-specific.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Tate Sent: Tuesday, February 22, 2005 8:05 AM To: [email protected] Subject: RE: [Sip-implementors] "re-invite" > In RFC 3261 sec 14.1 "UAC Behavior" > describes why the re-INVITE will not be forked. > > "The reason a re-INVITE will never fork is that the Request-URI > identifies the target as the UA instance it established the dialog > with, rather than identifying an address-of-record for the user. " The statement is not normative and conflicts with other statements within RFC3261 and RFC3263 which allow forking within the dialog during error situations when a 503 response or no response is received. If a device supplies a Contact or Record-Route entry which resolves to more than 1 location, forking of a re-INVITE can occur. _______________________________________________ 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
