Requesting Answering Modes for the Session Initiation Protocol (SIP)
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>, sip mailing list <email@example.com>, sip chair <firstname.lastname@example.org> Subject: Protocol Action: 'Requesting Answering Modes for the Session Initiation Protocol (SIP)' to Proposed Standard The IESG has approved the following document: - 'Requesting Answering Modes for the Session Initiation Protocol (SIP) ' <draft-ietf-sip-answermode-08.txt> as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-08.txt
Technical Summary This document defines extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv-Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. Working Group Summary There is consensus in the working group to publish this document. The proposal was originally submitted as a P-header, but it was decided that this aspect should be brought out and made generally applicable to all SIP implementations. Early concerns about the possibility to use the header as a means of eavesdropping have been addressed in the security considerations. Document Quality There has been no indication of implementation. The document has been required in support of the OMA PoC feature, and it can be assumed that there have been implementations of the OMA work that have therefore used this feature. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings.