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 protected] wrote:
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.
------------------------------------------------------------------------
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
