1	Shared Appearance of a SIP AOR draft-ietf-bliss-shared-appearances-03 Alan Johnston <alan@sipstation.com> Mohsen Soroushnejad <mohsen.soroush@sylantro.com> Venkatesh Venkataramanan <venkatar@sylantro.com>
2	Changes since -02 Detailed reviews by Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Harsh Mendiratta Thank you! Lots of clarifications and corrections Some open issues identified and discussed on list and today Removed Appendix on discussion of alternative techniques draft-alexeitsev-bliss-alert-info-urns reved thanks to Laura Liess and now referenced: Alert-Info: <urn:alert:tone:normal>;appearance=0
3	Open Issue: 482 Response "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.
4	Open Issue: Replaces and Join "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.
5	Open Issue: Appearance Limit "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
6	Open Issue: NOTIFY "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.
7	Open Issue: Seize Terminology 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.
8	Open Issue: Registration Authentication 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.
9	Next Steps Close open issues on list WGLC?