1 / 12

Alan Johnston <alan@sipstation> Mohsen Soroushnejad <mohsen.soroush@sylantro>

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>

Download Presentation

Alan Johnston <alan@sipstation> Mohsen Soroushnejad <mohsen.soroush@sylantro>

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 <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> BLISS BOF IETF-68

  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. BLISS BOF IETF-68

  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. BLISS BOF IETF-68

  4. 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. Requirements BLISS BOF IETF-68

  5. 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?") Requirements Continued BLISS BOF IETF-68

  6. 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 BLISS BOF IETF-68

  7. 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 Components +----------------------------+ +----+ | | | | | 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) BLISS BOF IETF-68

  8. 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 BLISS BOF IETF-68

  9. 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> BLISS BOF IETF-68

  10. 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. BLISS BOF IETF-68

  11. 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. BLISS BOF IETF-68

  12. Thank You! BLISS BOF IETF-68

More Related