Transcript IP_tec - iptel.org

Multimedia Communication in the Internet
SIP: Advanced Topics
Dorgham Sisalem
Mobile Integrated Services
FhG Fokus
1
SIP Service Space
2
What’s the Killer App?
• Q: Added-value services expected to be major source of
revenues. So what is the killer app?
• A: If I saw raw gold on the street I would not tell you either.
• It is believed that the convenience of integrated services will
be the killer.
• Couple of examples follow...
3
IN-like Services with SIP
•
Most of IN services may be easily
implemented with SIP in
proxies/redirect servers/UAs:
–
–
–
–
–
–
–
(Un)conditional call forwarding
abbreviated dialing
Screening
distinctive ringing
call distribution
call transfer
etc.
•
Sometimes, implementation logic
may completely differ.
– Televoting and IVRs likely to be
replaced by Web in the long run.
– Call-waiting is end-device
implementation issue with no protocol
support.
– Music-on-hold may be played localy.
The real benefit is those services beyond IN: straight-forward
integration with web, email, instant messaging, etc.
4
draft-ietf-sip-cc-transfer
Call Transfer
• Accomplished using the REFER method.
• The REFER method indicates that the recipient (identified by the RequestURI) should contact a third party using the contact information provided in
the method.
• New header fields: Refer-To, Refer-By.
• NOTIFY method used to report on result of referral.
• Note: No changes to proxy behavior required.
• Variants:
– With Consultation Hold (SIP Hold and unattended transfer)
– Attended Transfer, I.e., with a short conference
5
Example:
Call Transfer Call Flow
#1
A
A is having a call with B. A decides to
transfer B to C. It sends a “REFER” to
B with C’s address. Eventually, A is
notified on successful transfer using
NOTIFY (#6).
B
REFER B
To: B
Refer-To: C
Referred-By: A
#2 202 Accept
#3
#4
#6
#5
NOTIFY (OK)
#7
INVITE C
Referred-By: A
C
200 OK
200 ACK
200 OK
media
timeline
6
3rd Party Call
Control (3pcc)
• 3pcc = Ability of a party to establish a session between other parties.
• Examples of use:
– a click-to-dial service within a web phone-book
– Operator services
– Scheduled calls
• Design objective: use SIP “as is”
• Solution: send “empty INVITES”, and swap replies with SDP ACKs
• Controller may issue either its own or other’s party “forged” From
address. (Its real identity may be still verified using authentication.)
• Controller often called back-2-back user agent
– Act as two user agents acting back-2-back
– Manipulate messages coming from one agent before sending to the
other
– Main state information about the two sessions
draft-rosenberg-sip-3pcc
7
draft-rosenberg-sip-3pcc
Example: 3pcc call flow
#1
Controller C (e.g., co-located
With a web server)
INV w/o SDP
#2
A
200 SDP A1
#3 ACK on-hold
#6
#4
#5
INV SDP B
#7
#8
200 SDP A2
INV w/o SDP
B
200 SDP B
200 ACK w/A2’
#9 ACK
media
timeline
8
Answering Machine
•
•
•
Old-times behavior: set-up number of rings, plug-in, if you do not answer the
machine will
Easy to mimic with SIP: AM acts as a SIP UA; you need to set-up an answer
timer, let the answering machine register using your credentials; when an
invitation arrives it is forked both to your phone and your answering machine
Added value examples:
– Unified messaging: SIP answering machine can turn voice messages into email
messages that follow you or comprehensive web-pages (cf. voice navigation)
– Programmability allows to play variety of customized prompt messages:
• If (caller  friends) then play (“You can reach me at Venice beach or leave a message”) else
play (“leave a message please”);
#1 INVITE
#2 Trying
#3 INVITE
#4 Ringing
#5 CANCEL
#6 OK
#7 INVITE
AM
9
Programming SIP Services
10
Programming SIP
• Examples
– “discard all calls from Monica during my business hours”
– “redirect authenticated friends to my cell phone, anyone else to my
secretary”
– “if busy, return my homepage and redirect to recorder”
• Users and third parties may program
• SIP follows HTTP programming model
• Mechanisms suggested in IETF: CGI, Call Processing Language
(CPL), Servlets
11
Goals
• Minimize Time To Market
– Implement SIP applications without detailed SIP
knowledge
– Reduce Lines Of Code by using abstraction functions
• Improve Quality Of Service
– Avoid software bugs by using abstraction programming
interface
• E.g.: call.forward (“sip:[email protected]”) works independent of caller’s
and callee’s actual state
12
Service Execution Layering
Servlets
User Code
Interpreters
CPL scripts
CGI Scripts
(Perl, Python,
C, …)
Java
Servlets
SIP-CGI
SIP Messages
CPL
SIP Actions
Protocol stack
SIP
13
Call Processing Logic Example
The call processing
logic may be designed
using various
mechanisms: CPL, SIPCGI, servlet,
proprietary ones.
Jku’s call processing logic:
If ($caller is in {Jane, Bob})
proxy to [email protected]
else proxy to [email protected]
#2 pass invitation
to call processing
logic
Jku’s call processing
logic:
If ($caller ==Jane)
play Mozart
else
play Smetana
#3 return an
action
#5
#4a INVITE jku@cell
#1 INVITE jku
#4b INVITE voicemail@trash
14
Where May Signaling Services
Live?
• Some services have to live in the network:
– call distribution
– services for dial-up users without always-on IP connectivity
– network servers may be located on users’ premises (PBX-like) or operator’s
premises (Web-hosting-like, NetCentrex-like)
• Some services can be implemented in both places:
– forward on busy
• Some services work best in end-devices:
– distinctive ringing
15
Service Location Examples
F eature
D istin ctive Rin ging
V isual call id
C all W aitin g
C F Busy
C F N o A n sw er
C F N o D evice
L ocation h idin g
T ran sfer
C on feren ce Bridge
G atew a y to PST N
Firew all C ontrol
V oicem ail
E nd -device
Y es
Y es
Y es
Y es
Y es
No
No
Y es
Y es
Y es
No
Y es
P roxy
C an assist
C an assist
No
Y es
Y es
Y es
Y es
No
No
No
No
No
Source: H. Schulzrinne: “Industrial Strength IP Telephony”
16
SIP Common Gateway Interface
RFC 3050
(CGI)
• Follows Web-CGI. Unlike Web-CGI, SIP-CGI supports proxying and
processes responses as well.
• Language-indpendent (Perl, C, ...)
• Communicates through input/output and environment variables.
• CGI programs unlimited in their power. Drawback: Buggy scripts may
affect server behavior easily.
• Persistency token (cookie) is passed between SIP server and CGI to keep
state across requests and related responses.
17
SIP-CGI I/O
•
•
•
Script input: environment variables (AUTH_TYPE, CONTENT_LENGTH,
REQUEST_URI, etc.) and SIP message on stdin
Script output: set of messages consisting of action lines, CGI header fields and
SIP header fields on stdout
Action lines:
– Generating a response: status line
– Proxying:
• CGI-PROXY-REQUEST <dest-url> <sip-version>
• Additional header fields may be followed – they will be merged with the original request.
– Forward response: CGI-FORWARD-RESPONSE <token> <sip-version>
– Set cookie for subsequent messages: CGI-SET-COOKIE <token> <sip-version>
– Determine if the script should be called for the next message belonging to the same
transaction: CGI-AGAIN ("yes" | "no") <sip-version>
18
Call Processing Language
•
•
•
•
•
•
•
•
Special-purpose call processing language.
CPL scripts define a decision tree which may result in signaling (proxy, redirect,
reject) or non-signaling (mail, log) action.
CPL scripts triggered by SIP messages.
May be used by both SIP and H.323 servers.
Target scenario: users determine call processing logic executed at a server.
Limited languages scope makes sure server’s security will not get compromised.
Portability allows users to move CPL scripts across servers.
Scripts may be manually written, generated using convenient GUI tools, supplied
by 3rd parties, ...
draft-ietf-iptel-cpl
19
CPL Example
<incoming>
<address-switch field="origin" subfield="host">
<address subdomain-of="example.com">
<location url="sip:[email protected]">
<proxy timeout="10">
<busy> <sub ref="voicemail" /> </busy>
<noanswer> <sub ref="voicemail" /> </noanswer>
<failure> <sub ref="voicemail" /> </failure>
</proxy>
</location>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
20
Example: Creating CPL Scripts
iptel.org: CPL Composer
21
http://java.sun.com/products/jain/
JAIN: SIP Servlets and API
• JAIN: Java APIs for Integrated Network Framework
• Compromise between security and power: still a powerful generic
language but security provided by Java “sand-box”.
• JAIN is a protocol independent API applicable to almost any
signaling (SIP, H.323, PSTN, etc.)
– Java servlets are a high-level API building on top of HTTP servlet API
(package javax.servlet.sip)
– JAIN SIP is a low-level API for complete control over a SIP stack.
(package jain.protocol.ip.sip)
– Further JAIN Protocol API Specifications: ISUP, MGCP, H.323, etc.
– JAIN App API Specs: Call Control
– Technology Compatibility Kit (TCK) tests an implementation of the JAIN
SIP interfaces for compliance with the JAIN SIP Specification
• http://java.sun.com/products/jain/index.html
22
JAIN Components
•
•
•
JAIN SIP Events: Within the API, SIP messages are encapsulated as Message
objects that are passed between the JAIN SIP Provider and the JAIN SIP Listener.
JAIN SIP Provider: Within the API, the JAIN SIP Provider is defined as the entity that
provides an application access to the services of the SIP stack.
JAIN SIP Listener: Within the API, the JAIN SIP Listener is defined as the entity that
uses the services provided by the JAIN SIP Provider.
23
JAIN Classes and Methods
• SipListener
– processRequest
– processResponse
– Process Timeout
• SipProvider
– sendResponse
– sendRequest
– addSIPListener
• SipURL
• Message
– addHeader
– getBodyAsBytes
– removeViaHeaders
• Request
– setRouteHeaders
• Response
– setStatusCode
Note: methods shown here are only subsets of all available method!
24
Call Processing Tradeoffs
• Generality versus security
– multipurpose programming languages provide a huge service
space
– but also a huge vulnerability space
• Performance versus portability
– portable languages (CPL) need to be interpreted
• higher processing delay
– portability needed if services deployed at multiple servers or
end-devices (e.g. if stored at USIMs)
25
Which Service Creation Method
Should I Use?
•
choice of appropriate service creation mechanism depends on deployment
scenario
– where the service is executed (operator’s proxy vs. user’s end-device)
– by whom the service is maintained (user vs. administrator)
– demanded service logic
•
•
Scenario #1: A SIP site administrator wants to allow customers to define their
personalized call forwarding preferences
– CPL is chosen for best security
– Web CPL editor is provided for user convenience
Scenario #2: A SIP site administrator wants to define an access control list for
protecting a PSTN gateway pool
– Call processing logic depends on authentication data and call destinations -> CPL is
not sufficient (no authentication switch) -> CGI or Servlets
•
Scenario #3: An enterprise SIP proxy used for 3-rd party apps
– Servlets used for generality and portability
26
Other Work
• There seems to be a huge interest in creating call
control APIs. Other efforts include:
–
–
–
–
–
Parlay
TAPI
JTAPI
CTI
...
27
SIP and Mobility
28
SIP and Mobility
• Solutions space by layers
– Application layer: SIP-based mobility support
• drawback: application specific, needs to be re-implemented for every
application
– IP layer: Mobile-IP
• drawback: IPv4 triangle routing, nobody knows when IPv6 happens
– lower layers
• current cell phone networks
• wireless IP (WaveLANs ?)
29
SIP and Terminal Mobility
• Terminal can move between subnetworks
• Realised today with GSM and wireless LAN
• Issues to consider:
– Handoff performance
– Redirection authentication
• Mobile hosts (MH) inform their home proxy about their new
locations using REGISTER
• Mid-call mobility (Session mobility) is dealt with using
reINVITE
30
SIP and Terminal Mobility
Home Network
HP
REGISTER
#2
Cell 2
Signalling
FP
REGISTER
Cell 1
#1
Visited Network
31
SIP and Terminal Mobility
Home Network
#1
INVITE
HP
#4
#2
INVITE
Cell 2
Signalling
Data
FP
Cell 1
INVITE
#3
Visited Network
32
SIP and Terminal Mobility
Home Network
HP
reINVITE #3
#1
#4
REGISTER
#3
Cell 2
Signalling
Data
FP
REGISTER
Cell 1
#2
Visited Network
33
SIP and Terminal Mobility
Home Network
HP
reINVITE #3
#4
REGISTER
#3
Cell 2
Signalling
Data
FP
REGISTER
Cell 1
#2
Visited Network
34
SIP and Personal Mobility
•
•
•
•
Person uses different Devices and possibly address
REGISTER binds a person to a device
Proxy and redirect translate address to location and device
Issues to consider:
– Authentication: finger print, IR, password ..
– Binding different addresses to single person: LDAP ..
35
SIP and Service Mobility
• Use same services from different locations and devices
– Speed dial, address book, media preferences, call handling
• Services located at home server
– RECORD-ROUTE home proxy to force calls to be processed by home
servers
– Services located at end systems
– retrieve with REGISTER
• Issues to consider
– Services need to be device independent: standardised service
description (CPL) ..
– User recognition and authentication
36
SIP and Mobile-IP
• Mobile-IP is a well established standard for mobile communication in the
Internet
• Allow hosts to be reached under the same address regardless of location
• Mobile hosts register a care-of-address with home agent
• Correspondent nodes (CN) send data to home agent
• Home agent tunnels traffic to care-of-address
• MH sends traffic directly to CN
• Triangular routing increases delay
• Tunnelling increases bandwidth consumption
37
Mobile-IP (Registration)
Home Network
HA
Registration #2
Cell 1
FA
Registration
Cell 2
#1
Visited Network
38
Mobile-IP (Communication)
Home Network
#1
HA
#4
#2
#7
#5
Cell 1
Signalling
Data
FA
#3
Cell 2
#6
Visited Network
39
SIP and Mobile-IPv6
• IPv6 is especially interesting for mobile Internet
• Mobile-IPv6 uses Binding updates similar to SIP registration
and reinvitations to avoids triangular routing
• Use routing header option to avoid tunnelling
• Could be a solution for providing a unified protocol for mobile
data and voice communication??
40
SIP Robustness
41
Robust Protocol Design
• Robustness determined by state maintenance model
• Amount of state in SIP Servers minimized
– servers may be stateless (SL) or maintain transaction state (TS) or
session state (SS)
– The less state the more robustness; failure of a SL or TS proxy does
not affect existing sessions
– transactional state is needed to enable services such as
forking/forward-on-busy or if SIP runs over TCP
– session state may be needed for maintaining firewalls or generating
failure-resistant CDRs; keep-alive possible using re-INVITEs and
session timer
• SIP INVITEs convey full signaling state
• Subsequent messages may take different path
42
DNS for Failure Recovery &
Load Balancing
•
Unavailable SIP servers can be dealt with using DNS in the same way as mail
servers are:
– DNS servers maintain multiple prioritized SRV entries
– callers initiate calls to high-priority server; if unavailable, they proceed to lower-priority
server
•
Load balancing can be accomplished similarly
– DNS servers maintain multiple SRV entries with equal priority
• Phone do not support this very often these days
– a random pick is chosen out of the server list
•
Notes on DNS
– it’s good do have multiple DNS servers for each zone of authority;
– DNS may be a pain ...
43
Other Load Balancing Methods
• A front-end proxy may dispatch calls to a proxy farm
• Load-balancing NAT may be used
• Call processing logic may be off-loaded to end-devices
44
SIP and QoS Control
45
draft-ietf-sip-manyfolks-resource
QoS: SIP and QoS Control
• SIP DOES NOT provide QoS support.
• QoS is coupled with SIP through the notion of preconditions.
• Objective is to ensure that resources are made available before the
phone rings.
• Invitations might indicate in SDP that QoS assurance is mandatory.
– Call setup should only proceed after satisfying the preconditions
• SIP extended method (UPDATE) indicates the success or failure of the
preconditions.
• “confirm” attribute in SDP tells the other party to indicate met
preconditions. If both parties send “confirm”, session originator sends
UPDATE last.
46
SIP and QoS Control
[email protected]
INVITE sip:[email protected]
#1
m=audio 49170 RTP/AVP 0
a=qos:mandatory sendrecv confirm
183 Progress
m=audio 49170 RTP/AVP 0
a=qos:mandatory send confirm
#4
#5
#10
#3
Proxy
183 Progress
m=audio 49170 RTP/AVP 0
a=qos:mandatory send confirm
ACK
200 OK (INVITE)
#8
200 OK (UPDATE)
#7
UPDATE
#11
INVITE sip:[email protected]
m=audio 49170 RTP/AVP 0
#2
a=qos:mandatory sendrecv confirm
PRACK
#9
#6
[email protected]
Reserve
47
Media stream