draft-ietf-bliss-shared-appearances-12.txt   draft-ietf-bliss-shared-appearances-13.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261, 4235 (if approved) M. Soroushnejad Updates: 3261, 4235 (if approved) M. Soroushnejad
Intended status: Standards Track V. Venkataramanan Intended status: Standards Track V. Venkataramanan
Expires: January 14, 2013 Sylantro Systems Corp Expires: January 31, 2013 Sylantro Systems Corp
July 13, 2012 July 30, 2012
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR) Record (AOR)
draft-ietf-bliss-shared-appearances-12 draft-ietf-bliss-shared-appearances-13
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2013. This Internet-Draft will expire on January 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 66, line 8 skipping to change at page 66, line 8
| |<-- INVITE F16<| | | | |<-- INVITE F16<| | |
| | | | | | | | | |
| |>F17 100 ----->| | | | |>F17 100 ----->| | |
|<- INVITE F18<| | | | |<- INVITE F18<| | | |
Figure 15. Figure 15.
12. Security Considerations 12. Security Considerations
Since multiple line appearance features are implemented using Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as semantics provided by SIP [RFC3261], the SIP Event Package for Dialog
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], State [RFC4235], and the SIP Event Framework
[RFC3903], security considerations in these documents apply to this [I-D.ietf-sipcore-rfc3265bis] and [RFC3903], security considerations
draft as well. in these documents apply to this document as well.
To provide privacy, NOTIFY or PUBLISH message bodies that provide the To provide confidentiality, NOTIFY or PUBLISH message bodies that
dialog state information and the dialog identifiers MAY be encrypted provide the dialog state information and the dialog identifiers MAY
end-to-end using the standard mechanisms such as S/MIME described in be encrypted end-to-end using the standard mechanisms such as S/MIME
[RFC3261]. All SUBSCRIBES and PUBLISHES between the UAs and the described in [RFC3261]. Alternatively, sending the NOTIFY and
Appearance Agent MUST be authenticated. Without proper PUBLISH requests over TLS also provides confidentiality, although on
authentication, a third party could learn information about dialogs a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and
associated with a AOR and could try to use this information to hijack the Appearance Agent MUST be authenticated. Without proper
or manipulate those dialogs using SIP call control primitives. authentication and confidentiality, a third party could learn
information about dialogs associated with a AOR and could try to use
this information to hijack or manipulate those dialogs using SIP call
control primitives.
All INVITEs with Replaces or Join header fields MUST only be accepted All INVITEs with Replaces or Join header fields MUST only be accepted
if the peer requesting dialog replacement or joining has been if the peer requesting dialog replacement or joining has been
properly authenticated using a standard SIP mechanism (such as Digest properly authenticated using a standard SIP mechanism (such as Digest
or S/MIME), and authorized to request a replacement. Otherwise, a or S/MIME), and authorized to request a replacement. Otherwise, a
third party could disrupt or hijack existing dialogs in the third party could disrupt or hijack existing dialogs in the
appearance group. appearance group.
For an emergency call, a UA MUST never wait for a confirmed seizure For an emergency call, a UA MUST NOT wait for a confirmed seizure of
of an appearance before sending an INVITE. Instead, the emergency an appearance before sending an INVITE. Waiting for confirmation
call MUST proceed regardless of the status of the PUBLISH could inadvertently delay or block the emergency call, which by its
nature needs to be placed as expeditiously as possible. Instead, a
emergency call MUST proceed regardless of the status of the PUBLISH
transaction. transaction.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP Event header field parameter 'shared', This section registers the SIP Event header field parameter 'shared',
the SIP Alert-Info header field parameter 'appearance' and the XML the SIP Alert-Info header field parameter 'appearance' and the XML
namespace extensions to the SIP Dialog Package. namespace extensions to the SIP Dialog Package.
13.1. SIP Event Header Field Parameter: shared 13.1. SIP Event Header Field Parameter: shared
 End of changes. 6 change blocks. 
19 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/