1 / 16

SHARED CALL APPEARANCES

SHARED CALL APPEARANCES. Suhas Suhas (ss3474) COMS 4995 VoIP Security Professor Henning Schulzrinne. Department of Computer Science Columbia University Fall 2008. What is shared call appearances? Requirements

JasminFlorian
Download Presentation

SHARED CALL APPEARANCES

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. SHARED CALL APPEARANCES Suhas Suhas (ss3474)COMS 4995 VoIP Security Professor Henning Schulzrinne Department of Computer Science Columbia University Fall 2008

  2. What is shared call appearances? • Requirements • Implementation • Shared appearance dialog package extensions • Getting into detail… • Shared appearance user agent • Appearance agent • Example message flows • Appearance selection for an incoming call • Implementations options • Example of dialogue package parameter • Comparison • References

  3. Consider a small software development office, Discusses the problem with dev2 and directly takes the call from dev2’s phone without having to go back to his desk  Incoming call to Puts on hold and Developer 1 goes to developer 2 Another example, Assigning boss’ extension to a button on secretary's phone You don't have to transfer a call to someone's extension, just put it on hold and they can grab it wherever they are without "Park" and "Pickup" operations!

  4. A variant of this feature is known as Single Line Extension • In traditional telephony, the line is physical. A common scenario in telephony is for a number of business telephones to share a single or a small number of lines • A common scenario in SIP is for a number of business telephones to share a single or a small number of Address of Record (AOR) URIs

  5. REQ-5 The mechanism must scale for large numbers of appearances and UAs, 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 • REQ-7 Each UA in the group must be able to learn the appearance status of 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-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 conference 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

  6. REQ-13 For privacy reasons, there must be a mechanism so that appearance information is not leaked outside the group of UAs • REQ-14 The mechanism must support a way for UAs to request exclusivity on a line appearance • REQ-15 The mechanism should support a way for a UA to select a particular appearance number for outgoing requests prior to sending the actual request • 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

  7. As we observe many of the requirements can be met using standard SIP mechanism • Entity to manage appearance resource ? • Following Figure illustrates normal sip operations to implement parts of Shared Appearance

  8. Appearance Agent UA 1) SUBSCRIBE (Event : reg) 4) NOTIFY Registration Events INVITE sip:alice@example.com 7) Query (Example.com) Registrar Location Service Proxy 3) Store 8) Resp 2) REGISTER (alice) UA1 UA2 8) INVITE Sip:alice@example.com 5-7) SUBSCRIBE and/or PUBLISH (Event:dialog)

  9. <appearance> element • Used to convey appearance number of a dialog • <appearance>2</appearance> • Used by both UAs and Appearance Agents • <exclusive> element • Used to indicate whether the UA will accept Join or Replaces INVITEs for a dialog • UA can also not share dialog identifiers with Appearance Agent • <joined-dialog> element • Used to indicate which dialogs have mixed media • <replace-dialog> element • Used to convey dialog identifiers of any other dialogs which will be or have been replaced with this dialog

  10. Desired behavior of user agent supporting this feature • Should a UA be able to publish to the group AOR ? • Accurate rendering of other UAs in group is an important part of this feature • When should a UA send PUBLISH request • Only if its likely that the UA will be answering incoming calls, it should register against the AOR

  11. An Appearance Agent defined in this specification: • Must have a way of discovering the dialog identifiers of incoming INVITEs • On receiving a PUBLISH: • Case 1: with an appearance number • Case 2: an appearance number and without the 'shared' event package parameter • Case 3: without an appearance number but with the 'shared' event package parameter • Controls the rate of dialog state publication using the Expires header field in 200 OK responses to PUBLISH requests • May choose to implement rate limiting to reduce the amount of notification traffic, during dynamic situations

  12. Forking Proxy Appearance Agent Carol Alice Bob F1 INVITE F2 NOTIFY F3 200 OK F4 NOTIFY 200 OK F5 100 F6 F7 INVITE (Appearance=1) F8 INVITE (Appearance=1) Ringing 180 F9 180 F10 180 Ringing F11 180 F12 200 OK F13 200 F14 PUBLISH F15 F16 200 OK F17 CANCEL 200 OK F18 Request Cancelled 487 F19 F20 ACK F21 ACK F22 ACK Both way RTP established F23 NOTIFY 200 F24 F25 NOTIFY F26 200 OK

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

  14. <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" version="6" state="partial" entity="sip:alice@example.com"> <dialog id="id3d4f9c83" from-tag="3423" to-tag="a3f423j88uju1" direction="initiator"> <sa:appearance>2</appearance> <sa:exclusive>false</exclusive> <sa:joined-dialog call-id="sdfg" from-tag="832d1" to-tag="4542454" /> <sa:joined-dialog call-id="873287876" from-tag="433" to-tag="jwjwuf5" /> <state>connected</state> <local> <target uri="sip:bob@pc.example.com" /> </local> </dialog> </dialog-info> ...

  15. Differences in the number of registrations and subscription with dialog package approach requiring n times fewer in both cases • The security model for the dialogue package parameter approach is much cleaner where as the security model for the URI parameter approach would likely require a B2BUA resulting in undesirable properties • Dialog package parameter approach better meets REQs 5, 10, 11, 12, and 13 • URI parameter approach better meets REQ 9

  16. http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-01.txthttp://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-01.txt http://www.ietf.org/proceedings/07mar/slides/bliss-2/bliss-2.ppt http://mediumbusiness.verizon.com/documents/resource_library/Verizon_HostedIPCentrex_Preso.pdf http://www.comptel.org/files/ipngn_taylor.pdf http://www.skccom.com/shared/Documents/avaya/Webinar/IP%20Phones%20&%20Apps.ppt http://forum.voxilla.com/asterisk-support-forum/broadsoft-enhanced-sip-shared-call-appearance-13213.html http://www.opensourcesip.org:8080/clearspacex/thread/4428 http://www.asterisk.org/node/48342 http://www.3cx.com/forums/shared-line-appearance-1642.html

More Related