Subject: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-03.txt

From: [email-masked]
Date: Mon, 13 Jul 2009 15:15:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF.

	Title           : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
	Author(s)       : A. Johnston, et al.
	Filename        : draft-ietf-bliss-shared-appearances-03.txt
	Pages           : 64
	Date            : 2009-07-13

This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA).  When implemented using the Session Initiation
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
feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment.  This document
discusses use cases, lists requirements and defines SIP extensions to
implement this feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 14 Jul 2009 09:47:43 -0500

All,

I have revised the draft based the three reviews received.  There are 
four open issues in the draft - if we can close them, I think it is 
ready for WGLC.  They are:

Section 5.3:

"Upon initialization, the UA SHOULD subscribe to the dialog event
   package of the AOR and refresh the subscription per RFC 3265.  If the
   SUBSCRIBE request fails, loops back to itself, or returns a 482 Loop
   Detected, then no Appearance Agent is present and this feature is not
   active for this AOR.  The UA MAY periodically retry the subscription
   to see if conditions have changed.

      OPEN ISSUE: Do we need to specifically call out the 482 response,
      or is just saying if the request fails or loops, to give up?"

and

   "User Agents SHOULD support sending and receiving an INVITE with a
   Replaces [RFC3891] header to allow the Call Pickup operation.  User
   Agents SHOULD support sending an INVITE with a Join [RFC3911] header
   field to initiate bridging.  UAs SHOULD either support receiving a
   Join header field or be configured to use a conference server or
   B2BUA which supports the Join header field.

      OPEN ISSUE: Replaces and Join support is a SHOULD.  This means
      that taking and bridging/joining calls could fail if the UA does
      not support them.  Can we make these a MUST so that we can avoid
      these failures?"

Section 7.1.3

   "This UA is the typical 'business-class' hard-phone.  A number of
   appearances are typically configured statically and labeled on
   buttons, and calls may be managed using these configured appearances.
   Any calls outside this range should be ignored, and not mapped to a
   free button.  Users of these devices often select/seize specific
   appearance numbers for outgoing calls, and the UA will need to
   select/seize the appearance number and wait for confirmation from the
   Appearance Agent before proceeding with calls.

      OPEN ISSUE: We currently have no upper limit on the appearance
      number in the specification.  Do we need a way for an Appearance
      Agent to indicate to a UA that no more appearances are available?"

Section 10.13

 "In this scenario, the Appearance Agent does not have any way of
   knowing Bob's dialog state information, except through Bob. This
   could be because the Appearance Agent is not part of a B2BUA, or
   perhaps Bob is remotely registering.  When Bob registers, the
   Appearance Agent receives a registration event package notification
   from the registrar.  The Appearance Agent then SUBSCRIBEs to Bob's
   dialog event state.  Whenever Bob's dialog state changes, a NOTIFY is
   sent to the Appearance Agent who then notifies the other other UAs in
   the group.

      OPEN ISSUE: Does Bob PUBLISH to select/seize an appearance, or
      does he just NOTIFY the Appearance Agent?"

Comments on the document and these open issues are most welcome.

Thanks,
Alan

[email-masked] wrote:
> ------------------------------------------------------------------------
>
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>