1. 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
July 24, 2007
BLISS WG IETF-69

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. Components SIP Registrar/Location Service SIP Forking Proxy
| | | |
| 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 | | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| | | | | |
| | | | |
| | ) INVITE
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

9. 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
July 24, 2007
BLISS WG IETF-69

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

11. 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

12. 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

13. 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

14. 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

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