A Gateway For SIP Event Interworking

- Sasu Tarkoma & Thalainayar Balasubramanian Ramya

MOTIVATION
Interworking of SIP event framework with the generic publish/subscribe system Challenges: SIP Event Framework does not support anonymous one-to-many event dissemination SIP Event Framework does not support expressive filtering Proposed Solution: Implementation of a gateway component enabling interworking between the SIP event framework, and publish/subscribe system Application of the proposed Gateway: Universal Data Access

BACKGROUND INFORMATION
Session Initiation Protocol (SIP) : a standard, text-based, application layer, signaling protocol developed by the Internet Engineering Task Force (IETF). Described in RFC 3261 Purpose of SIP: To establish, modify and terminate multimedia sessions over the IP network Acceptance as standard: Selected by the 3rd Generation Partnership Project (3GPP), as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS)

BACKGROUND INFORMATION
SIP Application Areas: Internet Telephony Control Applications E-Commerce Multimedia Conferences Instant Messaging

SIP EVENT FRAMEWORK

SIP Event Framework: An extension of Session Initiation Protocol, described in RFC 3265 Methods supported: SUBSCRIBE, NOTIFY
SUBSCRIBER NOTIFIER

SUBSCRIBE 200 NOTIFY 200 NOTIFY 200

Fig 1. SIP Event Subscription and Notification

SIP DOMAIN
DNS DNS lookup Forward notification to subscriber proxy Forward subscription to notifier proxy

Forward notification to subscriber

Forward SUBSCRIBE to notifier

Notification response to proxy

SIP Proxy1 (Redirect mode)

Forward SUBSCRIBE Proxy Update location server query

SIP Proxy2 (Redirect mode)

Forward request to notifier

Registrar
register

Location Server
register

UAC1

UAC2

UAC3
Fig 2. Working of SIP Domain

Forward notification to notifier proxy

COMPONENTS IN SIP DOMAIN

SIP Proxy: Receives SIP requests/responses from clients/ proxies, processes, and forwards it to the next hop or final destination SIP Client: Receives/Sends SIP requests/responses Registrar: Maintains registered clients information, queries and gets recent updates from Location Server Redirect Server (Redirect Mode): Provides the contacted clients current address to the contacting client Location Server: Stores updated client information

APPLICATION AREAS OF CONTENT BASED PUB/SUB EVENT MODEL

Active Badge Systems Proximity Sensors Information and Multimedia Delivery Services Positioning Systems

WORKING OF PUBLISH/SUBSCRIBE EVENT MODEL

Publishers Event Service
Pu bl is

Consumers

Subscribe() Subscribe
h

Publish()
Pu bl is h

Unsubscribe()

Unsubscribe

Fig 3. Publish/Subscribe Event model

GATEWAY DESIGN

Gateway SIP Domain

I I

Pub/Sub Domain
O O

Conversion, Mapping, State

Fig 4. Gateway Design

IMPLEMENTATION ARCHITECTURE

G subscribe/ A SIP clients notify T subscribe/ E Fuego JAIN-SIP publish W Clients Proxy A NIST-SIP Fuego Event Y STACK Service
Fig 5. Implementation Architecture

GATEWAY FUNCTIONALITIES
Receive SIP messages (requests/responses) Convert SIP message to pub/sub messages. Forward the converted messages to Fuego domain Receive pub/sub messages Convert pub/sub messages to SIP messages (requests/ responses). Forward the converted messages to the SIP domain Associate the received messages using unique identifiers. Call Identifier of the SIP and subscription identifier of the Fuego message are used for association. Generate and send SIP provisional responses to the SIP domain

SIP AND FUEGO SUBSCRIPTIONS/NOTIFICATIONS SIP DOMAIN GATEWAY FUEGO SYSTEM

SUBSCRIBE Mapping, reformat SUBSCRIBE Forward SUBSCRIBE Process subscription Subscription status Create SIP response PUBLISH Mapping, reformat PUBLISH

Forward SIP response Forward NOTIFY OK

Fig 6. SIP SUBSCRIBE and Fuego PUBLISH

SIP AND FUEGO SUBSCRIPTIONS/NOTIFICATIONS SIP Domain Gateway

SUBSCRIBE Forward SUBSCRIBE Process subscription OK NOTIFY Mapping, reformat NOTIFY OK Forward NOTIFY Mapping, reformat SUBSCRIBE

Fuego System

Fig 7. FUEGO SUBSCRIBE and SIP NOTIFY

MOBILITY IN THE INTERWORKING ARCHITECTURE

Intradomain mobility: Intradomain terminal mobility is possible in both the SIP and Fuego domains Disconnected operation should be supported for user mobility Interdomain mobility: Need buffering of messages at the gateway Roaming clients can send a signal to the gateway informing their location update, and get the buffered messages

ADVANTAGES OF THE GATEWAY COMPONENT

Advantages: + No modifications in the API of the interworked domains + Supports extensibe implementation + Transparent architecture Experimentatal observation: Performed scalability and performance test for the gateway Used the presence event package

Conclusion
Under heterogenous environments interworking of different event standards is essential Future Work: Enhancing gateway functionality by providing filtering support, and load balancing Investigate the possibilities to provide various mobility support such as session mobility

REFERENCES

Java APIs for Integrated Network (JAIN) Session Initiation Protocol (SIP) API: http://www.jcp.org/aboutJava/communityprocess/final/jsr032/ National Institute of Standards and Technology (NIST) SIP (Session Initiation Protocol) Stack and Proxy: http://snad.ncsl.nist.gov/proj/iptel/

QUESTIONS ?

THANK YOU !