Upload
others
View
14
Download
0
Embed Size (px)
Citation preview
SIP, the IMS, and P2PSIP
2
Outline
� The protocol
– SIP
� Two ways (among others) to use SIP
– The IMS
– P2PSIP
SIP (Session Initiation Protocol)
4
� SIP is an application-level, end-to-end, client-server, extensible, text
based protocol.
� The design base was HTTP and SMTP
� SIP was originally used to establish, modify and terminate multimedia
sessions in the internet.
� SIP has evolved to be able to set-up a broad range of sessions:
– Multimedia (e.g., voice, video, etc)
– Gaming
– Presence and Instant Messaging
� SIP messages are either requests or responses.
� SIP messages carry zero or more “bodies”.
� Session Description Protocol (SDP) is the common body for session
initiation.
� SIP runs on any transport protocol (UDP, TCP, TLS, SCTP)
– The spec mandates UDP and TCP. Other transport protocols are
optional
SIP General Overview
Response
Request
Client Server
5
History of SIP
� In February 1996, Handley and Schooler submitted an Internet Draft on Session Invitation Protocol, SIPv1, to the Internet Engineering Task Force
– Sipv1 used Session Description Protocol (SDP) to describe sessions– Text-based– UDP-based transport
� Also in February 1996, Henning Schulzrinne submitted an Internet draft specifying the Simple Conference Invitation Protocol (SCIP) to the IETF
– SCIP was based on HTTP and was thus text-based– Defined its own format for session descriptions– TCP-based transport
� Presentations of SIPv1 and SCIP at the 35th IETF meeting in March 1996
� In December 1996, a new draft on Session Initiation Protocol (SIPv2) was submitted by Handley, Schulzrinne and Schooler
– SIPv2 merged SIPv1 and SCIP– SIPv2 was based on HTTP, and was thus text-based– Used both UDP and TCP– Used SDP to describe multimedia sessions
� In December 1997, the decision was made to split SIP into a base spec and extensions
� In February 1999, SIP reached the proposed standard level and was published as RFC 2543
� In June 2002, the current SIP specification, RFC 3261, was published
6
Overview of SIP Functionality
� SIP provides the following functionality:
– User location (not geographical location)
� Determination of the end system to be used for communication
– User availability
� Determination of the willingness of the other party to engage in
communications
– User capabilities
� Determination of the media parameters to be used
– Session set-up
� Establishment of session parameters at both called and calling
party
– Session management
� Transfer and termination of sessions, modifying session
parameters
� SIP does not provide services
– But it enables the system to provide services
– It has been demonstrated that it is easy to provide services with SIP
7
SIP Logical Entities� User Agent (UA): An endpoint
– User Agent Client (UAC): sends requests, receives responses
– User Agent Server (UAS): receives requests, sends responses
� Proxy server: A network host that proxies requests and
responses, i.e., acts as a UAC and as a UAS.
� Redirect server: a UAS that redirects request to other
servers.
� Back-to-back User Agent: a UAS linked to a UAC– Acts as a UAS and as a UAC linked by some application logic
� Registrar: A special UAS that accepts only registrations
Response
Request
UAC Proxy
Response
Request
UAS
Response
Request
B2BUA
ResponseRequest
8
Stateless and Stateful SIP Proxies
� There are several types of SIP proxies, depending on the
state they keep:
� Stateless proxy: a proxy that does not keep any state when forwarding requests and responses.
– A simple message forwarder
� Transaction stateful proxy, or stateful proxy: a proxy that stores state during the duration of the transaction.
– Maintains a server transaction and a client transaction
� Call stateful proxy: a proxy that stores all the state pertaining to a session (e.g., from INVITE to BYE).
– A call stateful proxy is always a transaction stateful proxy, but not the other way round.
9
The SIP Trapezoid
1. INVITE2. INVITE
Alice
atlanta.com biloxy.com
7. 180 (Ringing)
4. INVITE
6. 180 (Ringing)
3. 100 (Trying)5. 100 (Trying)
14. 200 (OK)
13. BYE
9. 200 (OK)
Bob
Bob is alerted
8. 180 (Ringing)Bob accepts
the session
10. 200 (OK)11. 200 (OK)
12. ACK
Media Session
Alice hangs up
Alice wishes to call Bob.
She sends an INVITE to
her proxy, atlanta.com
sip:[email protected] sip:[email protected]
atlanta.com proxy
server locates the proxy
server at biloxy.com
biloxy.com proxy server
consults a location service
to find Bob’s IP address
100 Trying indicates that
proxy is working on behalf of
Alice to route the INVITE
Indicates that Bob’s
phone rings
Indicates that the call
has been answeredConfirms the reception of
the 200 OK final response.
ACK is sent directly to Bob,
bypassing the proxies
When Alice hangs up, a
BYE message is sent
To call Bob,
Alice uses his
SIP identity, a
type of URI
called a SIP
URI
Terminates the
session
10
SIP Addresses
� SIP uses Uniform Resource Identifiers (URIs). At least, SIP
URIs and SIPS URIs are supported, although others (such as
TEL URL) are commonly supported.
– sip:[email protected]
– sips:[email protected]
– tel:+358-9-299-3283
– sip:proxy.atlanta.com:5060
– sip:another-proxy.biloxi.com;transport=UDP
� SIP and SIPS URIs must include a host name, and may
include username, may include port numbers, may include
parameters
� Non SIP/TEL URIs are also valid under certain circumstances:
HTTP, IM, PRES, MAILTO…
11
An Example of a SIP Request
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7Max-Forwards: 70Route: <sip:pcscf1.visited1.net;lr>, <sip:scscf1.home1.net;lr>From: <sip:[email protected]>;tag=171828To: <sip:[email protected]>Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITEContact: <sip:[5555::aaa:bbb:ccc:ddd]>Content-Type: application/sdp Content-Length: 248
v=0o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddds=-c=IN IP6 5555::aaa:bbb:ccc:ddd t=907165275 0m=audio 3458 RTP/AVP 97 96 0 15a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2a=rtpmap:96 G726-32/8000
Method
Request-URI
Version
Header
Body
Request
Line
Header Field
Header Field Name
Header Field Value
12
SIP Methods� INVITE: create a session
� BYE: terminates a session
� ACK: acknowledges a final response for an INVITE request
� CANCEL: cancels an INVITE request
� REGISTER: binds a public SIP URI to a Contact address
� OPTIONS: queries a server for capabilities
� SUBSCRIBE: installs a subscription for a resource
� NOTIFY: informs about changes in the state of the resource
� MESSAGE: delivers an Instant Message
� REFER: used for call transfer, call diversion, etc.
� PRACK: acknowledges a provisional response for an INVITE request
� UPDATE: changes the media description (e.g. SDP) in an existing
session
� INFO: used to transport mid-session information
� PUBLISH: publication of presence information
13
SIP Responses (1/2)
� SIP defines two types of responses– Final responses convey the result of the request processing, and are
sent reliably– Provisional responses provide information on the progress of the
request processing, but are not sent reliably in the core protocol (RFC 3261)
� Status codes ranges:– 100 – 199 Provisional (also known as informational responses)
� Server is performing some further action and does not yet have a definitive response
� Example: 180 Ringing – UA receiving the INVITE is trying to alert the user
– 200 – 299 Success� Request was successful� Example: 200 OK – the request has succeeded
– 300 – 399 Redirection� 3xx responses give information about the user’s new location or
about alternative services that might be available to satisfy the call
� Example: 302 Moved temporarily – retry the request at new address(es) specified in the Contact header
14
SIP Responses (2/2)
� Status code ranges continued:– 400 – 499 Client error
� Definitive failure responses from particular server� Client should not retry the same request without
modification� Example: 401 Unauthorized – request requires user
authentication
– 500 – 599 Server error� Server itself is the cause of the error� Example: 500 Internal server error – server encountered
an unexpected condition
– 600 – 699 Global failure� Server has definitive information about a particular user� Example: 600 Busy everywhere – the callee is busy and
knows that no other end system will be able to accept the call
15
SIP Routing and DNS System� SIP clients use DNS to route requests and find the next hop to route the
request
– By looking into a NAPTR (Naming Authority Pointer) record in DNS
– By looking into a SRV (Services) record in DNS
– By looking into A (IPv4) or AAAA (IPv6) records in DNS
� Example– Assumption: no transport and no port specified in the SIP URI
NAPTR response: _sip._tcp.example.com
NAPTR query: example.com
SIP server DNS server
SRV query: _sip._tcp.example.com
SRV response: server1.example.com:5060
server2.example.com:5060
A or AAAA query: server1.example.com
A response: 10.8.2.1
SIP request sent to 10.8.2.1,
port 5060, using TCP
16
SIP Registration
SIP server
and registrar
REGISTER sip:home1.net SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Public user identity
sip:[email protected] is
bound to the contact address
SIP/2.0 200 OK
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip: [email protected]>
1
2
play.home1.net
� The SIP registration function allows users to upload their current locations for use by proxy servers
– A REGISTER message associates a user’s SIP (or SIPS) URI with the
machine into which the user is currently logged
– The registrar writes this association into a database, from which it can be
fetched by a proxy server
17
Routing: SIP Server in Proxy Mode
SIP server
and registrar
p1.home1.net
INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Record-Route: <sip:p1.home1.net;lr>
SIP/2.0 200 OK
Contact: <sip:[email protected]>
Record-Route: <sip:p1.home1.net;lr>
2
3
INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:[email protected]>
1
SIP/2.0 200 OK
Contact: <sip:[email protected]>Record-Route: <sip:p1.home1.net;lr>
4
ACK sip:[email protected] SIP/2.0
Route: <sip:p1.home1.net;lr>5
ACK sip:[email protected] SIP/2.06
play.home1.netpc33.example.net
18
Routing: SIP Server in Redirect
Mode
SIP server
and registrarINVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:[email protected]>
SIP/2.0 200 OK
Contact: <sip:[email protected]>
4
5
INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:[email protected]>
1
pc33.example.net
SIP/2.0 302 Moved Temporarily
Contact: <sip:[email protected]>2
ACK sip:[email protected] SIP/2.03
ACK sip:[email protected] SIP/2.06
play.home1.net
19
Forking Proxies
� A proxy server can send an INVITE to a number of locations at the same time
– This type of parallel search is known as forking
� A proxy can route messages in parallel or in sequence– In parallel forking, all locations are attempted simultaneously
– In sequential forking, the proxy tries different locations one after the other
� Forking may result in multiple 2xx responses– Each will establish a dialog
Forking proxy
(1) INVITE
(2) INVI
TE
(3) INVITE
The IMS
(IP Multimedia Subsystem)
21
What is IMS?
• IP Multimedia Subsystem (IMS) is an
architecture for offering services on the
packet domain.
• Not just Voice over IP - IMS is a generic
architecture for offering multimedia
services.
• IMS is access agnostic, hence it is not
just for UMTS or GPRS, but will also
support WLAN, fixed line, etc.
IMSIMS
Multi Access
Packet Services
Rapid Services
IP Optimised
Mobile WorldInternet World
Technology
convergence
Increase
ARPU
22
IMS architecture
RNC
P-CSCF
I-CSCF
MRF
MGW
MGCF
IMSIMS
S-CSCF
MSC(Server)SGSN
GGSN
CNCN
MGW
BSC
UMTS/GPRSUMTS/GPRS
WLAN / WLAN / WiMAXWiMAX
Fixed AccessFixed Access
Corporate / HomeCorporate / Home
SIP Application
ServersSIP Application
Servers
HSS
CDMA 2000CDMA 2000
23
Terminal Terminal
Replicated - not reusable
Terminal Terminal
Common Functions
Routing & Discovery
Horizontal benefits of IMS
Vertically integrated services Horizontal integration
Common Functions
Routing & discovery
Application Logic
24
Terminal Terminal
Replicated - not reusable
Terminal Terminal
Common Functions
Routing & Discovery
Horizontal benefits of IMSVertically integrated services Routing & discovery
Common Functions
Routing & discovery
Application Logic
Numbering, Identification, Addressing
NNI
Routing
Service invocation
Authentication
SIP Reach ability & Capability negotiation
Registration
Re-Usable Components
25
Terminal Terminal
Replicated - not reusable
Terminal Terminal
Common Functions
Routing & Discovery
Horizontal benefits of IMSVertically integrated services Common Functions
Common Functions
Routing & discovery
Application Logic
Numbering, Identification, Addressing
NNI
Routing
Service invocation
Authentication
SIP Reach ability & Capability negotiation
Registration
Re-Usable Components
Common Directory
Common Deployment
Common Charging
Common Conferencing
Common Provisioning and O&M
Common Group / List Management
Common Presence
26
Advertising
Cross-selling
On demandVotingSharing
IMS Control for all Broadband Services
Control &
Connectivity
Service
Access
IMS Service Control
Ericsson IMS supports convergence
27
The IMS Eco System
• Operators
• Internet Providers
• Service Developers
• Content Providers
• Terminal Vendors
• Network Vendors
Telecom
Internet
Eco System
28
IMS Poker
Poker Application
Presence MessagingPush to Talk
Poker Application
PresenceMessaging Push to Talk
Other IMS operators
NNI
Messages (Game)
API API
UNIUNI
Presence
PoC Voice
Messaging
29
Architecture Elements
IM-SSF
I-CSCF
MRF
MGW
MGCF
HSS
CSE(SCP) SIP Application
Servers
OSA-SCS
SGW
OSA Application
Server
S-CSCFP-CSCF
BGFC
Database Elements
• HSS (Home Subscriber Server)
• SLF (Subscription Locator
Function)
IMS Control Elements
• S-CSCF
• P-CSCF
• I-CSCF
Control Plane Interworking
Elements
• MGCF - Media Gateway Control
Function
• BGCF - Breakout Gateway Control
Function
• SGW - Signaling Gateway
30
Other Elements
IMS Service Elements
• AS (Application Server)
External Service and Service
Interworking Elements
• OSA SCS
• OSA Framework
• OSA Application Server
• CAMEL elements - IM-SSF (IP Multimedia
Switching Service Function)
Resource Elements
• Media Resources Function (MRF)
Media Interworking Elements
• MGW (Media Gateway)
IM-SSF
I-CSCF
MRF
MGW
MGCF
HSS
CSE(SCP) SIP Application
Servers
OSA-SCS
SGW
OSA Application
Server
S-CSCFP-CSCF
BGFC
Steps:
1) Route
signalling to
A’s home
network
2) Route
signalling to
B’s home
network
3) Route
signalling to B
terminal
P-CSCFP-CSCF
S-CSCFS-CSCF
Home A
P-CSCFP-CSCFVisited A
Home B
I-CSCFI-CSCF
HSSHSS
I-CSCFI-CSCF
14
15
17
19
20 1
2
3
Visited B
78
9 6
12
13
S-CSCFS-CSCF
SGSNSGSN
Radio Access NetworkRadio Access Network
GGSNGGSN GGSNGGSN
SGSNSGSN
Radio Access NetworkRadio Access Network
ASASASAS
451011
16
User plane (RTP)
18
SESSION ESTABLISHMENT
MODEL
32
PoC Architecture
SIP/IP Core
(IMS Based)
Media Plane
Home PoC Server
Control
Plane
ISC
RTP/RTCP
� The PoC server acts as an application server– Implements the ISC (SIP-based) interface
– It may be distributed (control and media planes)
P2PSIP
(Peer-to-peer SIP)
34
Background
� P2P systems are already being used to share files, distribute content, and establish multimedia sessions
� They mainly provide– Signalling level: rendezvous
– Media level: NAT traversal
� P2P systems are supposed to reduce the cost involved in managing and operating a network
� The P2PSIP working group has been chartered at the IETF
– To use a P2P system to establish multimedia sessions� To do in a standard way what Skype does in a
proprietary way
– It will produce a standard solution based on SIP and DHTs
35
Traditional SIP Network
SIP
UA
SIP
UA
SIP Proxy SIP Proxy
Alice Bob
SIP Registrar SIP Registrar
first.com second.comSIP
UA
SIP
UA
SIP
UA
SIP
UA
36
SIP RegistrarSIP Registrar
SIP ProxySIP Proxy SIP ProxySIP Proxy
SIP Registrar SIP RegistrarSIP RegistrarSIP Registrar
SIP Proxy SIP Proxy
P2PSIP Network
first.com second.com
SIP
UA
SIP
UA
Alice Bob
SIP
UA
SIP
UA
SIP
UA
SIP
UA
37
Terminology
� Peer– They collectively run a distributed database algorithm
� Peer protocol (which is an overlay maintenance
protocol)
� Client– A client is a less capable peer
� It may not store records
� It may not participate in the maintenance of the
overlay
� It may not do either
– A client has one of more associated peers
– Communicates with peers using a client protocol
38
Peers, Clients, and SIP Entities
� Most peers and clients will be colocated with a SIP
entity– SIP UA, proxy, aplication server...
� But some may not be– Supernodes with no SIP functionality
39
Work at the IETF (1/3)In Scope
� Define a peer protocol:– Selection of P2P algorithm (likely a DHT)
� Define a client protocol.
� Protocols need to support NATs.
� Produce an architecture document:– Define how to create systems
– Media relays
� Also instant messaging and presence are in scope.
Source: P2PSIP
WG charter
40
Work at the IETF (2/3)Out of Scope
� The modification of the baseline SIP behavior �
Extensions handled in SIP WG.
� Not to develop new NAT traversal mechanism, if existing
ones can be used.
� Any research-like questions, e.g. how to assure unique
user id.
� To use something else than URIs for addressing
users/resources.
Source: P2PSIP
WG charter
41
P2PSIP Overlay
P2PSIP Bootstrap
Peer
P2PSIP Peer
P2PSIP Peer
P2PSIP Client
NAT
NAT
NAT
P2PSIP Overlay
<Resource-ID>
P2PSIP Resource
Record
Interacts with the P2PSIP
overlay through its associated
peer using the Client Protocol.
Does not run the distributed
database algorithm.
Participates in the P2PSIP
overlay and provides storage
and transport services to other
nodes.
Client Protocol
<Peer-ID>
First point of contact for a peer
joining the overlay. Can be located:
- By remembering peers from the
last time the peer was in the overlay
- Through multicast discovery
- Through manual configuration
- By contacting a bootstrap server
Peer ProtocolThe protocol spoken between
P2PSIP Peers to share
information and organize the
P2PSIP Overlay network.
Current understanding is that
SIP will not be used as the
Peer Protocol (SIP will be used
to initiated calls in the overlay
which has been organized
using the peer protocol).
The protocol spoken
between clients and
peers
Joining peer is a node
attempting to become a
P2PSIP Peer.
Admitting peer helps the joining
peer join the network.
42
P2PSIP Operations (1/2)
� P2PSIP peers are capable of performing different operations suchas:
– Joining and leaving– Get and put– Storing information on behalf of the overlay– Transporting messages
� To join a P2PSIP overlay, a joining peer needs to:– Obtain a Peer-ID and optionally a set of credentials
� The Peer-ID is a hash of a unique node identifier such as an IP address
– Locate a bootstrap peer for the overlay� The bootstrap peer will refer the joining peer to an
admitting peer– Contact an admitting peer
� The admitting peer will help the joining peer learn about other peers in the overlay and establish connections to them as appropriate
43
P2PSIP Operations (2/2)
� To perform a user registration (i.e. to insert the user’s contact
information into the overlay), a user needs to:
– Calculate a hash of her user name (e.g. [email protected]) to
produce a Resource-ID
– Locate the peer that is responsible for that Resource-ID
– Store a Resource-ID to contact address mapping in the
responsible peer
� To initiate a call:
– Calculate a hash of the callee’s user name to produce a
Resource-ID
� hash([email protected]) = 32B4A7F02C
– Locate the peer that is responsible for that Resource-ID in the
P2PSIP overlay
� A P2PSIP Resource Record with contact information is
obtained: [email protected] → 192.0.2.1:1234
– Send a SIP INVITE request to the callee
44
Vision for P2PSIP
� Some enterprises will use P2PSIP for their
communication systems, mainly to reduce their OPEX
� An Internet-wide P2PSIP network will exist. A standard
version of what Skype is today
� P2PSIP will be used between infrastructure nodes in
some architectures
� The peer protocol used by P2PSIP will be used to build
standards-based overlays that will not use SIP
45
Greatest Obstacles to P2PSIP
� Security and identity assertion– Is there a need for centralized components after all?
� Will the P2PSIP peer protocol be general enough to
support a large set of present and future DHTs?– Will we face interoperability problems?
� Performance– How much worse than a well-designed server-based
architecture?
� Battery and bandwidth constraint terminals– Will the use of a client protocol resolve this issue?
� Regulatory issues– Emergency calls, legal intercept, etc.
46