1

SESSION S8b: Efficient Network Control

A 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

Mobility and terminals in pervasive environments

• 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

(D1). (D2)

Personal device (C)

1-1

(D3)

(D4)

Multi: C+DSeveral possible Di’sOne used at a time with C(or C used alone)

10

SIP B2BUA and 3PCC (3rd party call ctr. / RFC 3725)

some event(e.g. httprequest)

RTPUser domain

User domain

Alice’sphone

Bob’sdevice

C• 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

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

some event(e.g. httprequest)

RTPUser domain

User domain

Alice’sphone

Bob’sdevice

C

12

C (B2BUA) on the endpoint (handheld)

• Note: The same architecture and Multi:C+D may also be used for incoming call (from Alice),– autoanswer

solves timeout issue also in the incoming case

– details later

RTPUser domain

User domain

Alice’sphone

Bob’sdevice

C

Correspondingentity

DiMulti:C+D

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):

Local Domain (enterprise)

streams

SIP

SIP signaling

Foreign domain

Req.1.2: Basic SIP

Media

• 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

Caller (Alice)

1.INVITE

2.INVITE3. OK 4. OK

media

BT SD

DEVICE INFO

BT SD

DEVICE INFO

User action

Handheld (PDA)C

Local deviceD1(VC)

Local deviceD2 (PC)

5. ACK 6. ACK

Autoanswer

Sip servers

Note: user action (Req. H.1) and autoanswer (to avoid timeout)

18

Architecture: separtion of SIP and SD (service discovery)

Cntrl

JAIN SIP

Blue-cove

Handheld controller (C)

Local Device (D)

Inquiry

BT client

Event

BTstack

SD-C

Blue-cove

BT server

BTstack

SD-S

SIPUA

Session Module

Response

• Note: • BT was

used in the prototype

• Evaluation of SD is for further work

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