190 likes | 291 Views
Feature Interactions between SIP Call Control Services. Mario Kolberg University of Stirling. Introduction: SIP. SIP: Session Initiation Protocol, IETF used for signalling, setup, modification and termination of a session media is separate text based protocol, based on HTTP
E N D
Feature Interactions between SIP Call Control Services Mario Kolberg University of Stirling
Introduction: SIP • SIP: Session Initiation Protocol, IETF • used for signalling, setup, modification and termination of a session • media is separate • text based protocol, based on HTTP • 2 types of devices: end devices and servers • user agents: initiate and respond to signalling, send and receive media, may provide services, e.g. SIP phones, soft phones • servers: redirect, proxy, registrar
Location of User • SIP supports user mobility • email like addresses: sip:mko@cs.stir.ac.uk • but user may be located at discus.cs.stir.ac.uk and be logged on as mko0123 • public address vs. current location • users need to register with a registrar • work closely with proxy and redirect servers • invitations are sent from UA via a number of servers to another UA • can host services
A SIP Example Bob Laura (1) INVITE (2) 180 Ringing (3) 200 OK (4) ACK Conversation (5) BYE (6) 200 OK
Feature Interactions • truly distributed architecture • highly programmable components • servers may be under the control of different organisations • end users may deploy their own services • increased number of addresses
TP: B; (A, B) (A, C) Applied Approach • Triggering party • Connection type • Source, destination • Original connection • Connection after feature activation • Parties & Treatment
Applied Approach • Analysis pairs of features • Compare two feature descriptions according to four rules • Single User Dual Feature Control • Connection Looping • Redirection and Treatment • Diversion and Reversing
Single User – Dual Control CFB: TP: B; (A, B) (A, C) CFU: TP: B; (A, B) (A, C) AR: TP: A; (B, A) (A, B) HL: TP: A; (A, B) (A, B)
Connection Looping CFB: TP: B; (A, B) (A, C) CFU: TP: C; (A, C) (A, B)
Redirection and Treatment CFB: TP: C; (A, C) (A, B) OCS: TP: A; (A, B) (A, Treat) AR: TP: B; (A, B) (B, A) OCS: TP: B; (B, A) (B, Treat)
Diversion and Reversing CFB: TP: C; (A, C) (A, B) AR: TP: B; (A, B) (B, A) CFB: TP: A; (B, A) (B, C) AR: TP: B; (A, B) (B, A)
Application to SIP • SIP CGI (ish) • when a service gets executed its description is included into the message • descriptions are included using a new header (Contype) • if there is already a description, apply the rules to find interactions • services need to be surrounded by a cocoon which contains the description for that service and the algorithm
Resolution • if an interaction is detected resolution • results from second service are discarded • more elaborated approaches possible, policies • approaches may be tuned towards various goals • most services executed • execute all services which are subscribed to by the party who pays for the call • private environment: services of an organisation may have priorities over services of an individual • it’s all about priorities • currently, the priority is with the services executed first
Proxy (CFU) Alice Proxy (CFB) Bob INVITE Chris CFU Triggered INVITE Bob Contype: CFU INVITE Bob Contype CFU 486 Busy Contype CFU CFB Triggered FI detected between CFU and CFB Example Contype: ID=CFU; TP=sip:bob@d254203.cs.stir.ac.uk; OrigFrom=chris@discus.cs.stir.ac.uk; OrigTo=bob@d254203.cs.stir.ac.uk; FinalFrom=chris@discus.cs.stir.ac.uk; FinalTo=alice@d254203.cs.stir.ac.uk; • Not all services are triggered by INVITE messages • some are triggered by responses (486 Busy) • Contype header needs to be copied into responses
Experimentation – Example 2 • SER, Pingtel phone, kphone
Experimentation SIP/2.0 200 OK Via: SIP/2.0/UDP 139.153.254.50;branch=z9hG4bKafde.6e4854d4.0 Via: SIP/2.0/UDP 139.153.254.222 ConType: ID=CFU; TP=sip:alice@d254203.cs.stir.ac.uk; OrigFrom=chris@discus.cs.stir.ac.uk; OrigTo=alice@d254203.cs.stir.ac.uk; FinalFrom=chris@discus.cs.stir.ac.uk; FinalTo=bob@d254203.cs.stir.ac.uk Forwarded-To: <sip:bob@d254203.cs.stir.ac.uk> From: <sip:chris@discus.cs.stir.ac.uk>;tag=1c8060 To: <sip:alice@d254203.cs.stir.ac.uk>;tag=1A8019B3 Contact: "root" <sip:root@139.153.254.203:5062;transport=udp> Record-Route: <sip:alice@139.153.254.203;ftag=1c8060;lr=lr>, <sip:alice@139.153.254.50;ftag=1c8060;lr=lr> • Who sent this reply – Alice or Bob? • Contact header • Record route
Case Study + Results • 9 services • CFU, CFB, OCS, TCS, VM, AR, DND, HL, GR
Discussion • all distributed interactions are detected • single component interactions are an issue • if a service drops original INVITE which services is executed first? • are single component interactions in fact interactions in SIP? • usually a list of services to be executed on a component implicit ordering/priorities • ISSUES: multiple addresses for a party • identifying a party from a response message
Discussion cont. • some services are triggered differently than in the PSTN • CFB+TCS do not interact? Alice Proxy (CFB, TCS) Bob Chris INVITE Bob 403 Screened INVITE Bob 486 Busy INVITE Chris