Multiple Dialog Usages in the Session Initiation Protocol
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, sipping mailing list <email@example.com>, sipping chair <firstname.lastname@example.org> Subject: Document Action: 'Multiple Dialog Usages in the Session Initiation Protocol' to Informational RFC The IESG has approved the following document: - 'Multiple Dialog Usages in the Session Initiation Protocol ' <draft-ietf-sipping-dialogusage-07.txt> as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-07.txt
Technical Summary Several methods in the Session Initiation Protocol can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. Working Group Summary There was strong consensus within the WG that this was an important issue that needed to be documented in an RFC. Protocol Quality Jon Peterson is the Responsible Area Director. The PROTO shepherd for the document is Gonzalo Camarillo. Gen-ART review was provided by Pasi Eronen. Note to RFC Editor Section 5.4 OLD: Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified in a bug against RFC3565) and REFER (clarified in a bug against RFC3515 ). NEW: Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER .