Requirements and Implementation Options for the Multiple Line Appearance Feature using the Session Initiation Protocol (SIP) draft-johnston-bliss-mla-req-00 Alan Johnston <alan@sipstation.com> Mohsen Soroushnejad <mohsen.soroush@sylantro.com> Venkatesh Venkataramanan <venkatar@sylantro.com> Paul Pepper <paul.pepper@citel.com> Anil Kumar <anil@yahoo-inc.com> July 24, 2007 BLISS WG IETF-69

Naming the Feature Commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance, or Shared Call/Line Appearance (SCA) - and there are others… We use Multiple Appearances as the feature name Work is based on draft-anil-sipping-bla-04.txt first published in 2003 There are multiple implementations of this I-D. July 24, 2007 BLISS WG IETF-69

Feature Description Incoming calls to the AOR are offered to a group of UAs and can be answered by any of them. Each UA in the group knows the call status of the others in the group and typically renders this information to the user. Each call or session (incoming or outgoing) is assigned a unique "appearance" number from a managed pool administered for the AOR group. This number is used by the user interface for display of call information (e.g. the order of the lamp/button on the device) and out-of-band indications (e.g. "Sales pickup line 2, please"). Calls can be joined (also called bridged or conferenced together) or can be placed on hold and picked up (taken) by another UA in the group. July 24, 2007 BLISS WG IETF-69

Requirements REQ-1 Incoming calls to the AOR must be offered to a group of UAs and can be answered by any of them. REQ-2 Each UA in the group must be able to learn the call status of the others in the group for the purpose of rendering this information to the user. REQ-3 Calls can be joined (also called bridged or conferenced together) or can be picked up (taken) by another UA in the group in a secure way. REQ-4 The mechanism should require the minimal amount of configuration. UAs registering against the group AOR should be able to learn about each other and join the appearance group. REQ-5 The mechanism must scale for large numbers of appearances, n, and large numbers of UAs, N, without introducing excessive messaging traffic. REQ-6 Each call or session (incoming or outgoing) must be assigned a common "appearance" number from a managed pool administered for the AOR group. Once the session has terminated, the appearance number is released back into the pool and can be reused by another incoming or outgoing session. July 24, 2007 BLISS WG IETF-69

Requirements Continued REQ-7 Each UA in the group must be able to learn the line appearance status of the the group. REQ-8 There must be mechanisms to resolve appearance contention among the UAs in the group. REQ-9 The mechanism must allow all UAs receiving an incoming session request to select the same appearance number at the time of alerting. REQ-10 The mechanism must have a way of reconstructing appearance state after an outage that does not result in excessive traffic and processing. REQ-11 The mechanism must have backwards compatibility such that a UA which is unaware of the feature can still register against the group AOR and make and receive calls. REQ-12 The mechanism must not allow UAs outside the group to select or manipulate appearance numbers. REQ-13 For privacy reasons, there must be a mechanism so that appearance information is not leaked outside the group of UAs. (e.g. "So who do you have on line 1?") July 24, 2007 BLISS WG IETF-69

List Discussion How large can the group (N) be? Should quantify in draft instead of just “large” If N is too “large”, should NOTIFY be sent instead of INVITE? Ability to make exceptions: Emergency Call bypass of outgoing screening Privacy of certain users to opt-out Privacy of Contact URIs Temporary GRUUs proposed for this (privacy of appearance number is already addressed) July 24, 2007 BLISS WG IETF-69

Requirements Analysis A SIP Forking Proxy and Registrar/Location Service meets REQ-1. The SIP Dialog Package meets REQ-2. The SIP Replaces and Join header fields meets REQ-3. The SIP Registration Package meets REQ-4. The use of a State Agent for the Dialog Package meets REQ-5. REQ-6 suggests an “Appearance Agent” Not necessarily a server, could be one of the UAs in the group that elects to take on this function REQs 7-13 require some SIP extensions or conventions July 24, 2007 BLISS WG IETF-69

Components SIP Registrar/Location Service SIP Forking Proxy +----------------------------+ +----+ | | | | | Appearance Agent | | UA | ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | | | |(Event:reg) | | registration alice@example.com | | | V | | events V | | +--------------------+ +----------+7)Query+--------+ | | | (example.com) | | |<===== | | | | | |3) Store| Location | | Proxy | | | | Registrar |=======>| Service | | | | | | | | |=====> | | | | +--------------------+ +----------+8)Resp +--------+ | | ^ ^ | | | | | | 2) REGISTER (alice) | | | | | | | | | | +----+ +----+ | | | | | | | | | | | | |UA1 | |UA2 | | | | | ^ ^ ^ ^ | | | | | | | | | | | +----+ | | | | | | | | +--------------------------------------+ | | +----+-------------------------------------------+ | | 8) INVITE +--------------+ alice@example.com 5-7) SUBSCRIBE and/or PUBLISH (Event:dialog) SIP Registrar/Location Service SIP Forking Proxy Appearance Agent which includes a State Agent for the dialog package SIP User Agents that support this feature July 24, 2007 BLISS WG IETF-69

Implementation Options URI parameter E.g. Contact: <alice@pc.example.net;line=3> Separate Registration per line Line number exposed with remote target in dialog. Dialog Package parameter Appearance parameter added to XML Only one registration per line Appearance number never exposed in SIP signaling Needs additional mechanism for incoming calls E.g. Alert-Info appearance parameter July 24, 2007 BLISS WG IETF-69

Example of Dialog Package Parameter <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="6" state="partial" entity="sip:alice@example.com"> <dialog id="id3d4f9c83" direction="initiator"> <state>trying</state> <local> <target uri="sip:bob@example.com"> <param pname="appearance" pvalue="0"/> </target> </local> </dialog> </dialog-info> July 24, 2007 BLISS WG IETF-69

Comparison Summary Dialog package parameter approach better meets REQs 5, 10, 11, 12, and 13. URI parameter approach better meets REQ-9. However, the combined dialog package parameter approach and the Alert-Info parameter approach meets REQ-9. Or, the dialog package parameter and the NOTIFY instead of INVITE approach meets REQ-9 as well. July 24, 2007 BLISS WG IETF-69

Appearance Contention Resolution Two UAs could try to use the same appearance number for an outgoing request Resolution mechanism Before UA uses appearance number, it is sent (PUBLISH or NOTIFY) to Appearance Agent Appearance Agent decides who wins Winning UA uses appearance number after it gets NOTIFY from Appearance Agent. Loosing UA will get a 500 response with Retry-After from Appearance Agent. Issue Receipt of a 500 to a NOTIFY is problematic Use PUBLISH instead. July 24, 2007 BLISS WG IETF-69

PUBLISH vs NOTIFY UAs could PUBLISH dialog state to Appearance Agent NOTIFY dialog state to Appearance Agent after receiving SUBSCRIBE PUBLISH is better for contention resolution PUBLISH requires provisioning or Without a State Agent, NOTIFY is the normal dialog package usage. SUBSCRIBE/NOTIFY is needed for Appearance Agent to rebuild appearance state. Allow both methods or standardize on one, PUBLISH? July 24, 2007 BLISS WG IETF-69

Next Steps Validate feature description and requirements with working group Work protocol extensions in another draft draft-anil-sipping-bla-04.txt is a start to this. July 24, 2007 BLISS WG IETF-69

Thank You! July 24, 2007 BLISS WG IETF-69