ReINVITE Handling softarmor再邀请处理softarmor.pptVIP

Re-INVITE Handlingdraft-camarillo-sipping-reinvite-00.txt Gonzalo.Camarillo@ To Roll Back or not to Roll Back: That is the Question What are the semantics of an error response to a re-INVITE? Section 12.2.2 of RFC 3261 says: “Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed.“ What are the state changes associated with a re-INVITE? State Changes Changes performed by the re-INVITE and any transactions within it Dialog target refreshes Generally accepted that target refreshes are special and are never rolled back Offer/answer exchanges Situation as Specified Today Initial INVITEs and Re-INVITEs are treated equally The semantics are based on the method, which is INVITE Full Roll Back Error response (e.g., 4xx) Two issues The error response modifies the session parameters but cannot be rejected by the UAC Offer/answer glare detection mechanisms do not consider error responses The Session Modification Cannot be Rejected On receiving a 4xx, the UAC may not be able to return to the pre-re-INVITE state Similar issue as offers in 2xx responses to re-INVITEs, described in Section 14.2 of RFC 3261 “The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer.” The pre-re-INVITE state may not overlap with the current state (e.g., IP address change) Solution Glare Conditions (1) Glare Conditions (2) Glare Conditions (3) Alternatives to Address These Issues Clarify how to use the current specs to avoid them Specify new different semantics for error responses to re-INVITEs Additional proposals Additional Proposals Classify session modifications into different categories and specify different rules for different categories Complex in a number of ways Need logic to classif