Paper by: L ill Kristiansen, ntnu and Egil. C. Østhus, Tandberg

1. SESSION S8b: Efficient Network ControlA personal communication service in a pervasive office environment using SIP B2BUA on the endpoint Paper by: Lill Kristiansen, ntnu and Egil. C. Østhus, Tandberg Presented by:lill.kristiansen@item.ntnu.no

2. Outline • End-point centric or network centric? • Personal Pervasive Communication (PPCom) use cases • Terminals in pervasive environments • SIP and 3PCC as enablers • Requirements • System design and implementation • Discussion

3. Network centric or endpoint centric? • The authors have previously worked together with Telenor R&I on a context based service called ENME (ENriched MEdia). • Similar to EMNE the new service PPCom is aiding the user in locating video equipment. • ENME handled context on central server(s) and via central SIP servers for signaling • This time we use a fully distributed service discovery. In PPCom we are putting the endpoint center stage

4. More on network centric vs endpoint centric • SIPcenter.com [14]: • “The traditional network model gives service providers ultimate control, “ • “IMS is clearly rooted in this approach” • “[IMS] defines only the network core and has little to say about edge devices” • Our approach is different: • We are using B2BUA on the endpoint itself • In this way the endpoint itself becomes a kind of FMC intagrator

5. Scenario 1 • Incoming call from customer with PPCom: • A customer calls Tom from outside the company's domain. • The customer Allan calls Tom on Tom's single URI tom@acme.com from his video-equipped computer. • Tom receives the call on his handheld, and chooses to answer the call with a nearby video-phone.

6. Incoming vs outgoing calls • Note that previous papers has described outgoing calls combining several devices • Research shows that it is more important to cover the case of an (unplanned) incoming call (see e.g. Belotti and Bly [2])

7. Scenario 2 • Incoming call from boss with PPCom: • Tom is in a meeting room with some other employees. His boss Jane is placing a call to tom@acme.com. Since all calls appears on his handheld terminal before possibly transferred, he is in control of all calls wherever he is. • Depending on the social situation and the caller ID the human (Tom) choose either not to accept the call, or to accept the call and to use the wall mounted VC equipment in the room, or his personal lap top or just use his handheld phone.

8. Leaving the room suddenly • Sc. 2b (enhancement; leaving the room) • Tom might also choose to start by using the VC equipment, but decide to leave the room at some stage. He will then bring his handheld with him in order to have a confidential talk. He might then replace the streams on the VC equipment with voice on the handheld.

9. We do not cover full personal mobility We also assume that the callee is inside the enterprise using other devices (D) also within the same enterprise domain When outside of office environment plain SIP (MMoIP) is used Mobility and terminals in pervasive environments Multi: C+D Several possible Di’s One used at a time with C(or C used alone)

10. Controlling entity C (B2BUA) may be several places e.g.: in core network (IN-like) call from the blue (outgoing) at a (soft) PBX Issues: SDP negotiation timeout SIP B2BUA and 3PCC (3rd party call ctr. / RFC 3725)

11. The timeout issue • Figure shows flow 1 from RFC3725 which in general has a timeout problem • The Controller is not able to respond immediately to the message 2 (200 OK), which may cause A to timeout before 6 is received. • This limitation requires a quick answer to the INVITE (message 3) for this flow to succeed. We use autoanswer

12. Note: The same architecture and Multi:C+D mayalso be used for incoming call (from Alice), autoanswer solves timeout issue also in the incoming case details later Di Multi:C+D Correspondingentity C (B2BUA) on the endpoint (handheld)

13. Human and social factors • We leave to the human user and social rules in the workplace to decide: • when to turn the personal device (phone) on silent (’meeting profile(s)’) or completely off. • It is important to note that this is contrary to the approaches taken in e.g. [4] and [11]-[12] where a ’smart system’ is assumed. • It is however in line with research such as [3]. • Formulated as Req.H.1 and Req. H.2

14. Techn. requirements • Req. 1.1 The value added service PPCom shall work with SIP as the underlying signalling protocol. • Req. 1.2 Only one of the parties (caller or callee) need to be aware of the existence of PPCom. The non-PPCom subscriber shall not need any special software or device to participate beyond standard based MMoIP equipment.

15. Req. (cont.) • Req. 2 PPCom shall detect suitable contexts (e.g., terminals fitting the proposed media types better that the current terminal at hand). • This knowledge shall be used in a way allowing human decisions. • Req. 3 The PPCom shall support mobility: • Multi:C+D-paradigm is used (not personal mobility in general) • User is inside the (virtual) enterprise

16. Illustration (incoming call): • Much related work ignores req. 1.2 and add their ownSIP extensions on the external interface (even non-SIP extensions) • Req. 1.2 enables a stepwise introduction of the smart environment

17. Incoming call flow Note: user action (Req. H.1) and autoanswer (to avoid timeout)

18. Note: BT was used in the prototype Evaluation of SD is for further work Architecture: separtion of SIP and SD (service discovery)

19. Related work • Paper by Acharya et al. [1] (IBM) considers the case of using a personal wearable device (a watch) as a controller. • There are no media on the controller, but otherwise the solution has similarities with our solution. • The papers [11]-[12] by Shacham et al. • These two papers seem to favor ‘smartness’ in the system. This is contradictory to our human involvement requirements Req.H.1 and Req.H.2. • A more fine grained view of devices

20. Discussion • Relevant former work either contradicts our req. on human involvement or Req.1.2 (use of Basic SIP externally) • RFC 3725 discuss the advantage of Flow 1 (which we use) to be that controller (C) need not modify SDP • Not at all relevant in our case • Modification of SDP is relevant for Scenario 2b when Bob must leave the office (unplanned)

21. Relations to IMS and NGN • In line with NGN concept [6] we assume that the connectivity provider (bearer capabilities) is separate from the call/session capabilities. • It seems that IMS mostly rely on QoS reservation mechanisms integrated into the session initiation phase (e.g. at P-CSCS). • This mechanism may not be suibable in our case.

22. Issues of charging and QoS • In our case the PDA acts both as an endpoint and as a SIP 3PCC entity and it seems that this raise some issues regarding QoS (as well as charging) in IMS.

23. Conclusion • PPCom is a value added service PPCom adding context information to SIP sessions to aid the user to route calls to suitable video devices. • We show how 3PCC may also support incoming calls. • Our solution allows the call to be transferred from fixed device (D) to the handheld (C) since C stays in the loop at all times (Scenario 2b)

24. Further work • SD needs further work: BT is simple and works in the prototype, but other options for SD should be investigated • There are several issues related to the user interface and actual use of PPCom in a work environment that needs further work (real life experiments)

25. Thank you for your attention

26. Extra: Granularity of entities in a pervasive environment • Multi:C+D is simpler than MDS from [12] • Pros and cons, we have chosen ’coarse grained’ devices