|
|
|
"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 just say if the request fails or
loops, to give up?" |
|
Proposal: Simplify by saying If request fails or
loops, give up. |
|
|
|
"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?” |
|
Proposal: Make Replaces and Join MUST for system - if
a UA does not support accepting, a B2BUA could implement on behalf. |
|
|
|
"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?” |
|
|
|
Proposal: Do not specify this in the document |
|
|
|
"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?" |
|
|
|
Proposal: Use NOTIFY instead of
PUBLISH when the Appearance Agent subscribes. |
|
|
|
Currently, draft says
select/seize everywhere but doesn’t fully define what this means. |
|
|
|
Proposal: Use definitions proposed by Francois |
|
|
|
Seizing: An appearance can be
seized by communicating an |
|
artificial state of
"trying" prior to actually initiating a dialog, |
|
in order to appear as it was
already initiating a dialog. The
appearance |
|
number is confirmed prior to
sending the INVITE. |
|
|
|
Selecting(or Not-Seizing): An
appearance is merely selected |
|
(i.e., not seized) if there is
no such communication of |
|
artificial state of
"trying" prior to initiating a dialog: i.e., the state is |
|
communicted when the dialog is
actually initiated. The appearance |
|
number is learned after the
INVITE is sent. This is a UI-only
issue. |
|
|
|
Clarifying registration
examples raised a question about 3rd party registration authentication. RFC 3261 in Section 10 talks about To URI
instead of From URI for authentication |
|
|
|
Proposal: Support these two modes: |
|
|
|
REGISTER |
|
To:
<sip:HelpDesk@example.com> |
|
From:
<sip:HelpDesk@example.com> |
|
|
|
Bob will need to have the
credentials for HelpDesk when challenged. |
|
|
|
REGISTER |
|
To:
<sip:HelpDesk@example.com> |
|
From:
<sip:Bob@example.com> |
|
|
|
And when challenged, Bob
provides his credentials. The
Registrar is provisioned to allow Bob to register against HelpDesk and
everything works. |
|
|
|
|