March 20, 2007BLISS BOF IETF-681 Requirements and Implementation Options for the Multiple Line Appearance Feature using the Session Initiation Protocol (SIP) draft-johnston-bliss-mla-req-00 Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan Paul Pepper Anil Kumar

March 20, 2007BLISS BOF IETF-682 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.

March 20, 2007BLISS BOF IETF-683 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.

March 20, 2007BLISS BOF IETF-684 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.

March 20, 2007BLISS BOF IETF-685 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?")

March 20, 2007BLISS BOF IETF-686 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” REQs 7-13 require some SIP extensions or conventions

March 20, 2007BLISS BOF IETF-687 Components | | | | | Appearance Agent | | UA | | | | | ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | | | |(Event:reg) | | registration | | | V | | events V | | )Query | | | (example.com) | | |<===== | | | | | |3) Store| Location | | Proxy | | | | Registrar |=======>| Service | | | | | | | | |=====> | | | | )Resp | | ^ ^ | | | | | | 2) REGISTER (alice) | | | | | | | | | | | | | | | | | | | | | | |UA1 | |UA2 | | | | | | | | | | | | | | | | | ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | | | | 8) INVITE ) 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

March 20, 2007BLISS BOF IETF-688 Implementation Options URI parameter –E.g. Contact: –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

March 20, 2007BLISS BOF IETF-689 Example of Dialog Package Parameter <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="6" state="partial" trying

March 20, 2007BLISS BOF IETF-6810 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.

March 20, 2007BLISS BOF IETF-6811 Next Steps Validate feature description and requirements with group Work protocol extensions in another draft –Draft-anil-sipping-bla-04.txt is a start to this.

March 20, 2007BLISS BOF IETF-6812 Thank You!