1. Oracle SBC Configuration and Administration

2. Oracle Communications Session Border Controller
Oracle Communications Session Border Controller is the industry-leading session border controller (SBC) for fixed line, mobile, and over-the-top (OTT) services.
Based on Acme Packet OS, Oracle Communications Session Border Controller operates on Oracle’s range of purpose-built hardware platforms and virtualized servers to deliver a unique combination of performance, capacity, high availability, and manageability that has made it the most widely deployed SBC in the world.

3. Overview
Oracle Communications Session Border Controller (OCSBC) enables service providers to deliver trusted, first-class real- time communications services across Internet Protocol (IP) network borders.
Services and applications ranging from basic Voice over IP (VoIP) to any services enabled by IP Multimedia Subsystem (IMS)—including Voice over Long-term Evolution (VoLTE), video conferencing and calling, presence, instant messaging, IP television (IPTV), GSM Association’s IP Exchange (IPX), and femtocell or Wi-Fi–enabled fixed-mobile convergenceleverage Oracle Communications Session Border Controller with its unparalleled control functions/ features, protocol support, programmability and manageability in any type of IP network

4. Overview
The functions offered by Oracle Communications Session Border Controller satisfy critical service provider requirements in five major areas: security, interoperability, reliability and quality, regulatory compliance, and revenue/cost optimization.

5. SIP Call Flow Scenarios SIP Security SIP Programming
Contents
SIP Overview
SIP in detail
SIP Call Flow Scenarios
SIP Security
SIP Programming

6. SIP Overview
What SIP is, Multimedia Protocol Stack, Short History and Related Protocols are included.

7. Why packet switching? Why SIP?
Technology evolution of PSTN

8. Session Initiation Protocol Overview
Application Layer Signaling Protocol
Used to establish, modify, and terminate multimedia sessions
Part of Internet Multimedia Architecture
Can use UDP, TCP, TLS, SCTP, etc.
Based on HTTP (Web)
Similar text-based structure
Uses URIs (Uniform Resource Indicators)
Applications include (but not limited to):
Voice, video, gaming, instant messaging, presence, call control, etc.
SIP is a key component of the Internet Multimedia Architecture. Other protocols including SDP, RTP, DNS, etc are needed to implement a complete service.
SIP was designed based on one of the most scalable and deployed Internet protocols Hyper Text Transport Protocol (HTTP) the underlying protocol of the World Wide Web (WWW).
SIP is about much more than just voice – supports all media.

9. Security & Privacy SIP Authentication
Challenge/Response based on shared secret - SIP Digest
Mechanism also used by HTTP
Used for client devices
Encryption using private/public keys
Used between servers
Privacy and security
SIP signaling can be encrypted
S/MIME (Secure/Multipurpose Internet Mail Extensions)
Defined in RFC 2633
SIP can be transported over
IPSec
Defined in RFC 2401
TLS (Transport Layer Security)
Defined in RFC 2246

10. Internet Multimedia Protocols
RTSP
The Internet protocol stack has four layers: application, transport, Internet, and physical/link layer. SIP resides at the application layer and can use a variety of transport layer protocols such as UDP and TCP. Any physical layer can be used including Ethernet, dialup, wireless, etc.

11. SIP Requests and Responses
SIP Responses use a numerical code and a “reason phrase”
1xx Informational
2xx Final
3xx Redirection
4xx Client Error
5xx Server Error
6xx Global Failure
SIP Request types are called “methods”
INVITE
ACK
OPTIONS
CANCEL
BYE
REGISTER
SIP is a client/server protocol that uses a request/response structure. Requests are called “methods”. Responses have a numerical code and a reason phrase – many are borrowed from HTTP including the common “404 Not Found” response. (Not all HTTP response codes are valid in SIP – only those defined in RFC 3261.)

12. Related Protocols: SDP
SIP carries (encapsulates) SDP messages
SDP specifies codecs and media termination points
Only one of many possible MIME attachments carried by SIP
SDP – Session Description Protocol
Used to describe media session.
Carried as a message body in SIP messages.
Is a text-based protocol
Uses RTP/AVP Profiles for common media types
Defined by RFC 2327
E.g. RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control”
Closely related protocols to SIP include Session Description Protocol (SDP) and Real-time Transport Protocol (RTP). SDP is a text-encoded media description language carried as a message body in a SIP request or response. RTP is used to transport media and identify codec. RTP is always sent end-to-end and bypasses SIP signaling chain.

13. RTP – Real-time Transport Protocol
Related Protocol: RTP
RTP – Real-time Transport Protocol
Used to transport media packets over IP
RTP adds a bit-oriented header containing:
name of media source
timestamp
codec type
sequence number
Defined by H. Schulzrinne et al, RFC 1889.
Profiles defined by RFC 1890.
RTCP for exchange of participant and quality reports.

14. SIP Uniform Resource Indicators (URIs)
Same form as addresses:
Two URI schemes:
is a SIP URI
Most common form introduced in RFC 2543
is a Secure SIP URI
New scheme introduced in RFC 3261
Requires TLS over TCP as transport for security
Two types of SIP URIs:
Address of Record (AOR) (identifies a user)
(Needs DNS SRV records to locate SIP Servers for mci.com domain)
Contact (identifies a device and is usually a Fully Qualified Domain Name, FQDN)
or (Which needs no resolution for routing)
One of the most powerful features of SIP is its use of Uniform Resource Indicators (URIs), also sometimes called Uniform Resource Locators (URLs). SIP can use a variety of URI schemes, but most commonly uses sip, sips, and tel (for telephone numbers). SIP URIs can be either an Address of Record (AOR) or a Contact depending on whether it references a user or a device.

15. SIP “Trapezoid”
DNS Server
Location Server
DNS
SIP
Outbound Proxy Server
Inbound Proxy Server
SIP
SIP
SIP
The “Trapezoid” is a common SIP inter-domain architecture in which endpoints utilize SIP proxies to communicate. The SIP signaling flows between all the elements, but the media flows only along the bottom of the trapezoid.
Media (RTP)
User Agent A
User Agent B

16. SIP Elements – User Agents
Capable of sending and receiving SIP requests.
UAC – User Agent Client
UAS – User Agent Server
End Devices
SIP phone
PC/laptop with SIP Client
PDA
mobile phone
PSTN Gateways
are a type of User Agent
DNS Server
Location Server
DNS
SIP
Outbound Proxy Server
Inbound Proxy Server
SIP
SIP
SIP
User Agents (UAs) are the endpoints in a SIP network – they originate and terminate SIP requests and responses. They can be implemented as SIP phones, PC/laptop clients, PDAs, cell phones, or even as a PSTN gateway.
Media (RTP)
User Agent A
User Agent B

17. SIP Elements – Proxy Servers
DNS Server
Location Server
Forward or “proxy” requests on behalf of User Agents
Consult databases:
DNS
Location Server
Types:
Stateless
Transaction Stateful
Call Stateful
No media capabilities
Ignore SDP.
Normally bypassed once dialog established, but can Record-Route to stay in path.
DNS
SIP
Outbound Proxy Server
Inbound Proxy Server
SIP
SIP
SIP
SIP proxy servers are the intermediary servers that help UAs establish sessions using SIP. They typically consult databases and perform SIP routing (proxying) on behalf of UAs. They are catagorized based on they type of state information they keep – a stateless proxy keeps no state, a transaction stateful proxy only keeps state on pending transactions, while a call stateful proxy keeps state for the entire duration of a SIP session.
Media (RTP)
User Agent A
User Agent B

18. SIP Elements – Other Servers
DNS Server
Location Server
Database of locations of SIP User Agents
Queried by Proxies in routing
Updated by User Agents by Registration
DNS Server
SRV (Service) Records used to locate Inbound Proxy Servers
Location Server
DNS
SIP
Outbound Proxy Server
Inbound Proxy Server
SIP
SIP
SIP
Location Servers and DNS servers are two examples of databases often queried by SIP proxies (although DNS is often also queried by UAs). Location Servers are SIP registration databases, built by registrar servers. SIP can utilize DNS queries to resolve URIs using A (Address), SRV (Service), or NAPTR (Naming Authority Pointer Records) resource records.
Media (RTP)
User Agent A
User Agent B

19. SIP Client and Server SIP Elements are either A User Agent acts as a
User Agents (end devices that initiate and terminate media sessions)
Servers (that assist in session setup)
Proxies
Registrars
Redirect servers
A User Agent acts as a
Client when it initiates a request (UAC)
Server when it responds to a request (UAS)

20. SIP Registrar, 1
SIP server that can receive and process REGISTER requests
A user has an account created which allows them to REGISTER contacts with a particular server
The account specifies a SIP “Address of Record (AOR)”

21. SIP Registrar, 2 SIP Registrars store the location of SIP endpoints
Each SIP endpoint Registers
with a Registrar using it’s Address of Record and Contact address
Address of Record for John Smith in From: header
From: John Smith
Contact: header tells Registrar where to send messages
Contact: John Smith
SIP Proxies
query SIP Registrars for routing information
Incoming calls addressed to
now routed by the Proxy to the Contact: header URL

22. Proxy Server SIP Proxy servers route SIP messages
Stateless Proxies use stateless protocols like UDP to talk to endpoints
Low Proxy overhead
Ephemeral connections, dropped as soon as message is forwarded
Stateful Proxies use TCP or other stateful protocols to set up a permanent connection
High Proxy overhead
Endpoint connection must be set up, maintained and torn down for the duration of the session

23. SIP Proxy Server SIP Server which acts on behalf of User Agents
Receives a SIP request
Adds some headers
Modifies some of the headers
Forwards request to next hop server or client

24. Stateless vs. Stateful Proxy
Stateless Proxy
Forwards every request downstream and response upstream
Keeps no state (does not have any notion of a transaction)
Never performs message retransmissions
Stateless proxies scale very well
can be very fast
good for network cores
Stateful Proxy
Maintains state information for the duration of either the:
Transaction (request)
Transaction Stateful
Dialogue (from INVITE to BYE)
Dialogue Stateful
Performs message retransmission

25. SIP Redirect Server
Receives a request and returns a redirection response (3xx)
Contact header in response indicates where request should be retried
Similar to database query
All Server types are logical NOT Physical

26. Locating SIP Servers Manual provisioning DHCP SIP Option 120
RFC 3361
Multicast (deprecated)
DNS SRV method
Get local domain name automatically from DHCP server
Perform SRV record query through DNS on that domain for _sip._udp.<domain name>
Send SIP REGISTER message to resolved server
phone is up and running without user intervention

27. SIP in detail
Now, we are going to study SIP in detail including SIP Request, SIP Response and SIP Header

28. SIP Request Methods, 1
SIP used for Peer-to-Peer Communication though it uses a Client-Server model
Requests are called “methods”
Six methods are defined in base RFC 3261:
INVITE
ACK
OPTIONS
BYE
CANCEL
REGISTER

29. SIP Request Methods, 2 REGISTER INVITE/ACK/BYE/CANCEL/UPDATE MESSAGE
Register contact with Registrar
INVITE/ACK/BYE/CANCEL/UPDATE
Creates, negotiates and tears down a call (dialogue)
MESSAGE
Creates an Instant Messaging session
SUBSCRIBE
Subscribe to a service (like message waiting indication)
NOTIFY
Notify a change in service state (new Voic )

30. SIP Methods - INVITE, 1 INVITE requests the establishment of a session
Carried in Message Body (SDP)
Type of session
IP Address
Port
Codec

31. SIP Methods - INVITE, 2
An INVITE during an existing session (dialogue) is called a re-INVITE
re-INVITEs can be used to
Place calls on or remove calls from hold
Change session parameters and codecs
The SIP UPDATE method is the proposed replacement for this technique

32. SIP Methods - ACK
ACK completes the three way session setup handshake (INVITE, final response, ACK)
Only used for INVITE
If INVITE did not contain media information
ACK must contain the media information

33. SIP Methods - OPTIONS
OPTIONS requests the capabilities of another User Agent
Response lists supported methods, extensions, codecs, etc.
User Agent responds to OPTIONS the same as if an INVITE (e.g. if Busy, returns 486 Busy Here)
Very basic presence information

34. SIP Methods – BYE and CANCEL
BYE terminates an established session
User Agents stop sending media packets (RTP)
CANCEL terminates a pending session.
INVITE sent but no final response (non-1xx) yet received.
User Agents and Proxies stop processing INVITE
Can be sent by a proxy or User Agent
Useful for “forking proxy”
Parallel search using multiple registration Contacts.
First successful wins, rest are cancelled.

35. SIP Methods - REGISTER
Registration allows a User Agent to upload current location and URLs to a Registrar
Registrar can upload into Location Service
Incoming requests can then be proxied or redirected to that location
Built in SIP support of mobility
UAs do not need static IP addresses
Obtain IP address via DHCP, REGISTER indicating new IP Address as contact

36. SIP Request URI
The Request-URI indicates the destination address of the request
Proxies and other servers route requests based on Request- URI.
The Request-URI is modified by proxies as the address is resolved.

37. SIP From and To Tags
Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg
INVITE request From header contains a tag
Any User Agent or Server generating a response adds a tag to the To header in the response
To:

38. SIP Method - INFO Used to transport mid-call signaling information
Only one pending INFO at a time
Typical use - PSTN signaling message carried as MIME attachment
E.g. ISDN User-to-User information
Defined in RFC 2976

39. SIP Method - REFER
Indicates that recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request
Typical Use: Call Transfer features
Allowed outside an established dialogue

40. SIP Method - PRACK Provisional Response ACKnowlegement
Used to acknowledge receipt of provisional response
183 Session Progress
Does not apply to 100 Trying responses
Only provisional responses may be sent reliably and acknowledged with PRACK
If no PRACK sent, response retransmitted
Defined in RFC 3262

41. SIP Methods – SUBSCRIBE and NOTIFY
SUBSCRIBE requests notification of when a particular event occurs
Use Expires=0 to unsubscribe
A NOTIFY message is sent to indicate the event status
Sample Applications
Presence
Message waiting indication for voic
Defined in RFC 3265

42. SIP Method - MESSAGE Extension to SIP for Instant Messaging (IM)
MESSAGE requests
carry the content in the form of MIME body parts
use the standard MIME headers to identify the content

43. SIP Responses
SIP Requests generate Responses with codes borrowed from HTTP
Classes:
1xx Informational
2xx Final
3xx Redirection
4xx Client Error
5xx Server Error
6xx Global Failure
Response example “404 Not Found”

44. SIP Responses: 1xx-3xx

45. SIP Responses: 4xx

46. SIP Responses: 5xx-6xx

47. SIP Message Details
INVITE SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
First line of a SIP message is Start Line which contains:
the method or Request type: INVITE (session setup request).
the Request-URI which indicates who the request is for
Note: Request-URI can be either an AOR or Contact (FQDN)
This Request-URI is a FQDN, but the initial Request-URI was an AOR (same as To URI)
the SIP version number SIP/2.0
This shows an example SIP message without the SDP message body.
As SIP is a very polite protocol, a request to establish a session is called an INVITE.
Since SIP is text-encoded, this is exactly how a captured packet would look “on the wire”.
The structure of a request is a start line then a list of SIP header fields. The actual order of SIP header fields does not matter (except for the relative ordering of multiple header fields of the same name).
The start line contains the method type (INVITE), the intended recipient of the request and the SIP version number (2.0) separated by spaces.

48. SIP Headers
SIP Requests and Responses contain Headers (similar to headers)
Required Headers To
From
Via
Call-ID
CSeq
Max-Forwards
Optional Headers:
Subject, Date, Authentication (and many others)

49. SIP Message Details Via headers show the path the request has taken
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
INVITE SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
Via headers show the path the request has taken
The bottom Via header is inserted by the User Agent which initiated the request
Additional Via headers are inserted by each proxy in the path
The Via headers are used to route responses back the same way
Required branch parameter contains a “cookie” (z9hG4bK) then a transaction-ID.
The next two lines begin the list of SIP header fields which have the general structure Header-Name: value. While method names are conventionally all upper case, SIP header fields are a mixture of upper and lower case and end in a colon.
The Via header field can appear multiple times in a SIP request or response, and contains a list of the SIP servers which have generated or processed the message. In this example, the bottom Via header field identifies the originating UA while the top Via header field identifies a proxy that has forwarded this request.
The set of Via header fields are like a “stack” – the set is built as the request is forwarded, then the values are used to route responses back through the same set of proxies, at which time each Via header field is removed from the response as it is routed.

50. SIP Message Details
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
INVITE SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
Max-Forwards is a count decremented by each proxy that forwards the request.
When count goes to zero, request is discarded and 483 Too Many Hops response is sent.
Used for stateless loop detection.
The Max-Forwards header field is used to prevent SIP message loops.
In RFC 2543, loop detection was performed by doing Via header field searches, but this has been deprecated in RFC 3261 in which the Max-Forwards header field is mandatory in all requests.

51. SIP Message Details
INVITE SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
Dialog (formerly called call leg) information is in headers:
To tag, From tag, and Call-ID (Note: Not URIs)
To and From URIs usually contain AOR URIs.
All requests and responses in this call will use this same Dialog information.
Call-ID is unique identifier usually composed of
pseudo-random string hostname or IP Address
The To, From, and Call-ID header fields contain the dialog identifiers for this SIP session, called a dialog (formerly called a call leg in RFC 2543).
The dialog identifier consists of the To tag, From tag, and Call-ID which are compared as strings. Endpoints can have multiple separate SIP sessions established between them – each would have a unique dialog identifier.

52. SIP Message Details CSeq Command Sequence Number
INVITE SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
CSeq Command Sequence Number
Initialized at start of call (1 in this example)
Incremented for each subsequent request
Used to distinguish a retransmission from a new request
Also contains the request type (method) - INVITE
The Command Sequence number, CSeq, header field contains a integer and the method name for the request. Each subsequent request contains an incremented CSeq count while a retransmission of a request would reuse the CSeq count.

53. SIP Message Details
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
INVITE SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
Contact header contains a SIP FQDN URI for direct communication between User Agents
If Proxies do not Record-Route, they can be bypassed
If Record-Route is present in 200 OK, then a Route header is present in all future requests in this dialog.
Contact header is also present in 200 OK response
The Contact header field contains a URI at which the SIP device is directly reachable during the dialog. It usually contains a Fully Qualified Domain Name (FQDN).
SIP proxies can ensure that they remain in the signaling path for future requests during the dialog by using the Record-Route mechanism. Otherwise, SIP messaging goes directly between endpoints using the Contact URI.

54. SIP Message Details
INVITE SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 159
Content-Type indicates the type of message body attachment (others could be text/plain, application/cpl+xml, etc.)
Content-Length indicates the octet (byte) count of the message body.
Message body is separated from SIP header fields by a blank line (CRLF).
The final two header fields Content-Type and Content-Length contain information about the message body (shown on the next slide).
The message body is separated from the set of SIP header fields by a blank line.

55. SDP Message Body Details
v=0
o=Tesla IN IP4 lab.high-voltage.org
s=-
c=IN IP
t=0 0
m=audio RTP/AVP 0
a=rtpmap:0 PCMU/8000
Version number (ignored by SIP)
Origin (only version used by SIP )
Subject (ignored by SIP)
Connection Data (IP Address for media )
Time (ignored by SIP)
Media (type - audio, port , RTP/AVP Profile - 0)
Attribute (profile - 0, codec - PCMU, sampling rate – 8000 Hz)
This is the SDP message body not shown in the previous example. SDP uses a terse syntax in which a strict order of lines is enforced.
SIP utilizes on a subset of the SDP information which includes the IP address ( ) and port number (49170) at which the UA is listening for media, the media type (audio), Audio Video Profile (AVP) number (0), codec type (PCM m-law), and sampling rate (8000 Hz).

56. SIP Response Details
SIP/ OK
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76
To: Heisenberg
From: E. Schroedinger
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 173
v=0
o=Heisenberg IN IP
s=SIP Call
c=IN IP
t=0 0
m=audio RTP/AVP 0
a=rtpmap:0 PCMU/8000
This is an example response generated in response to the request example. Many of the header fields are directly copied from the request. The changed/new header fields and parameters are shown in bold.
The start line is replaced with the response code (200) and reason phrase (OK) indicating that the request to establish a session is successful.
A tag has been added in the To header field, which then becomes part of the dialog identifier.
The answering UA includes its own Contact URI and media information in the SDP message body.
This response would be routed back through the proxy.munich.de proxy server back to the caller using the Via header field URI set.
Via, To, From, Call-ID, & CSeq are all copied from request.
To now has a tag inserted by UAS
Contact and Message Body contain UAS information.

57. SIP Call Flow Scenarios
As followings …

58. SIP Call Flow Scenarios
Call Attempt - Unsuccessful
Presence Subscription
Registration
Presence Notification
Instant Message Exchange
Call Setup – Successful
Call Hold
Call Transfer
Call Flows and full message details:
“SIP Basic Call Flow Examples” I-D by A. Johnston et al.
“SIP Service Examples” I-D by A. Johnston et al.
The next section will introduce more SIP behavior using some common call flow scenarios.
The scenarios will utilize the SIP trapezoid to show how the work in an inter-domain environment.
The full details of most of these examples can be found in two IETF Internet-Draft documents “SIP Basic Call Flow Examples” and “SIP Service Examples”.

59. SIP Call Setup Attempt Scenario
DNS Server
Location Server
1. A “dials” SIP AOR URI User Agent A sends INVITE to outbound Proxy Server.
2. Outbound Proxy sends 100 Trying response.
Outbound Proxy Server
Inbound Proxy Server
1. INVITE
Contact: A
SDP A
Trying
In this SIP call setup attempt scenario, A wishes to call B and “dials” the AOR URI of B. User Agent A generates an INVITE and sends it to its default outbound proxy.
This proxy address can be manually configured or looked up using DNS.
The proxy server immediately returns a 100 Trying provisional response to indicate that it has received the INVITE but that the request is still pending.
User Agent A
User Agent B (Not Signed In)

60. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
3. Outbound Proxy does DNS query to find proxy server for mci.com domain
4. DNS responds with IP address of mci.com Proxy Server
Outbound Proxy Server
Inbound Proxy Server
1. INVITE
Contact: A
SDP A
Trying
The proxy server performs a DNS query and utilizes SRV records to locate the SIP proxy server for the destination domain.
User Agent A
User Agent B (Not Signed In)

61. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
5. Outbound Proxy sends INVITE to Inbound Proxy Server.
6. Inbound Proxy sends 100 Trying response.
5. INVITE
Contact: A
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
The proxy server the forwards (proxies) the INVITE to that proxy server for the destination domain which also immediately responds with a 100 Trying.
The 100 Trying response is not forwarded by the proxy server back to User Agent A – multiple 100 Trying responses do not convey an new information. As a result, the 100 Trying response is defined to only be a “hop-by-hop” response that is never proxied.
User Agent A
User Agent B (Not Signed In)

62. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
7. Inbound Proxy consults Location Server.
8. Location Server responds with “Not Signed In.”
5. INVITE
Contact: A
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
The inbound proxy server consults a location server for B’s current registration information. B is not currently signed in, so the location server returns this information.
User Agent A
User Agent B (Not Signed In)

63. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
9. Inbound Proxy sends 480 Temporarily Unavailable response.
10. Outbound Proxy sends ACK response.
5. INVITE
Contact: A
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Temporarily Unavailable
10. ACK
Trying
The proxy server uses this information to generate a 480 Temporarily Unavailable response.
This response receives an immediate ACK (Acknowledgement request) from the other proxy server.
This INVITE/failure-response/ACK exchange completes the SIP transaction between the proxy servers.
User Agent A
User Agent B (Not Signed In)

64. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
11. Outbound Proxy forwards 480 response to A.
12. A sends ACK response.
5. INVITE
Contact: A
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Temporarily Unavailable
10. ACK
Trying
Temporarily Unavailable
12. ACK
The proxy then forwards the 480 back to User Agent A and receives an ACK, completing the transaction between them. The ACK is not forwarded by the proxy as it has already sent an ACK in the previous exchange.
User Agent A
User Agent B (Not Signed In)

65. SIP Presence Example
DNS Server
Presence Server
1. A wants to be informed when B signs on, so sends a SUBSCRIBE
2. Outbound Proxy forwards to Inbound Proxy
3. Inbound Proxy forwards to B’s Presence Server
3. SUBSCRIBE
Outbound Proxy Server
2. SUBSCRIBE
Inbound Proxy Server
1. SUBSCRIBE
A wishes to receive a notification when B signs in and is available for communication.
User Agent A sends a SUBSCRIBE request requesting to be notified when B is available. The previous DNS query has been cached, so no new DNS query is needed for the request to be forwarded to the proxy in B’s domain. The inbound proxy then forwards the request to B’s presence server.
User Agent A
User Agent B (Not Signed In)

66. SIP Presence Example
DNS Server
Presence Server
3. SUBSCRIBE OK
4. Presence Server authorizes subscription by sending a 200 OK.
5. & OK proxied back to A.
Outbound Proxy Server
2. SUBSCRIBE
Inbound Proxy Server OK
1. SUBSCRIBE OK
The presence server authenticates the subscription and confirms it by sending a 200 OK response which is forwarded back to User Agent A.
No ACK is sent, as ACK is only used to confirm receipt of final responses to INVITE requests – only INVITE transactions use the 3 way handshake.
The SUSBSCIBE/200 OK exchange completes the transaction.
User Agent A
User Agent B (Not Signed In)

67. SIP Presence Example
DNS Server
Presence Server
7. Presence Server sends NOTIFY containing current presence status of B (Not Signed In).
8. and 9. NOTIFY is proxied back to A.
10. A acknowledges receipt of notification with OK.
11. & OK is proxied back to B’s Presence Server.
<Not Signed In>
7. NOTIFY OK
<Not Signed In>
8. NOTIFY
Outbound Proxy Server
Inbound Proxy Server OK
9. NOTIFY
<Not
Signed
In> OK
The presence server immediately sends a NOTIFY containing the current state of B, that is, not signed in. User Agent A responds with a 200 OK which is proxied back to the presence server.
This NOTIFY/200 OK exchange completes this transaction.
User Agent A
User Agent B (Not Signed In)

68. SIP Registration Example
DNS Server
Location Server
B =
2. Update database:
1. B signs on to his SIP Phone which sends a REGISTER message containing the FQDN URI of B’s User Agent.
2. Database update is sent to the Location Server
Outbound Proxy Server
Outbound Proxy Server
REGISTER
Contact:
Time passes, then B signs in by send a REGISTER request to through his proxy which forwards it to the registrar server for B’s domain.
The REGISTER contains B’s AOR and a Contact URI which identifies the device that B is currently using.
User Agent A
User Agent B

69. SIP Registration Example
DNS Server
Location Server
3. Location Server database update is confirmed.
4. Registration is confirmed with a 200 OK response.
B =
2. Update database:
3. OK
Outbound Proxy Server
Outbound Proxy Server
1. REGISTER
Contact: OK
Contact:
The location server updates its database with the information and returns a 200 OK to confirm. The Contact URI is also returned in the 200 OK along with an expiration time. To ensure continuous service, B will need to refresh the registration (by sending another REGISTER request) within the time interval.
The REGISTER/200 OK exchange completes the transaction.
User Agent A
User Agent B

70. SIP Presence Example
DNS Server
Presence Server
13. Presence Server learns of B’s new status from the Location Server and sends a NOTIFY containing new status of B (Signed In).
14. & 15. NOTIFY is proxied back to A.
16. A acknowledges receipt of notification with 200 OK.
17. & OK is proxied back to Presence Server.
13. NOTIFY
<Signed In> OK
<Signed In>
14. NOTIFY
Outbound Proxy Server
Inbound Proxy Server OK
<Signed In>
15. NOTIFY OK
The presence server is informed of the change in B’s availability and sends a NOTIFY to User Agent A containing this new information. The 200 OK response of User Agent A is proxies back to the presence server.
User Agent A
User Agent B

71. SIP Instant Message Scenario
1. A sends an Instant Message to B saying “Can you talk now?” in a MESSAGE request.
2., 3. & 4. MESSAGE request is proxied, Location Server queried.
5. Inbound Proxy forwards MESSAGE to B.
6. User Agent B responds with 200 OK.
7. & OK is proxied back to A.
DNS Server
Location Server
3. LS Query: B?
4. Response:
2. MESSAGE
<Can you
talk now?>
Outbound Proxy Server
Inbound Proxy Server OK
1. MESSAGE
<Can you
talk now?> OK
5. MESSAGE
<Can you
talk now?> OK
Knowing that B is now available, A types in an Instant Message (IM) to B. User Agent A generates a MESSAGE request containing the typed text in a message body. The location server query by the inbound proxy server now returns B’s Contact URI and the MESSAGE is routed to B.
User Agent B confirms receipt with a 200 OK. (Note that any typed response by B would not be returned in the 200 OK – it will be sent using a separate MESSAGE request sent from B to A as shown in the next slide.)
User Agent A
User Agent B

72. SIP Instant Message Scenario
1. B sends an Instant Message to A saying “Sure.” in a MESSAGE sent to A’s AOR URI.
2. & 3. DNS Server is queried.
4. Outbound Proxy forwards MESSAGE to Inbound Server.
5. & 6. Location Server is queried.
7. Inbound Proxy forwards to A.
8. User Agent A responds with 200 OK.
9. & OK is proxied back to B.
Location Server
DNS Server
5. LS Query: A?
6. Response:
2. DNS Query: globalipcom.com?
3. Response:
<Sure.>
4. MESSAGE
Inbound Proxy Server
Outbound Proxy Server OK
<Sure.>
7. MESSAGE OK
1. MESSAGE
<Sure.> OK
B types a reply to A. User Agent B generates a MESSAGE request and sends it to its local proxy. The proxy consults DNS to locate the proxy server for the globalipcom.com domain of A. The MESSAGE request is then forwarded to this proxy server which then forwards it to User Agent A. A 200 OK reply is sent which is proxied back to User Agent B.
User Agent A
User Agent B

73. SIP Call Setup Attempt Scenario
DNS Server
Location Server
1. to 5. A retries INVITE to B which routes through two Proxy Servers.
6. Location Server responds with the FQDN SIP URI of B’s SIP Phone.
7. Inbound Proxy Server forwards INVITE to B’s SIP Phone.
5. LS Query: B
6. Response:
3. INVITE
Contact: A
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
7. INVITE
Contact: A
SDP A
A again attempts to establish a session with B by sending an INVITE. This time, the INVITE is forwarded to User Agent B by the inbound proxy server.
User Agent A
User Agent B

74. SIP Call Setup Scenario
DNS Server
Location Server
8. User Agent B alerts B and sends 180 Ringing response.
9. & Ringing is proxied back to A.
Ringing
Outbound Proxy Server
Inbound Proxy Server
Ringing
Ringing
User Agent A being alerting user B and sends a 180 Ringing provisional response which is proxied back to User Agent A. User Agent A informs A that alerting is taking place, possibly by generating local ringtone.
User Agent A
User Agent B

75. SIP Call Setup Scenario
DNS Server
Location Server
11. B accepts call and User Agent B sends 200 OK response.
12. & OK is proxied back to A.
Ringing
Outbound Proxy Server
Inbound Proxy Server OK
Contact: B
SDP B
Ringing OK
Contact: B
SDP B OK
Contact: B
SDP B
Ringing
A accepts the call, so User Agent A sends a 200 OK success response which is proxied back to A.
Since the media is sent directly between A and B, it is possible that B’s “Hello” may reach A before the 200 OK. To avoid this clipping, User Agent A must be prepared to receive and play any RTP media packets as soon as the INVITE is sent.
Likewise, User Agent B must be prepared to receive and play media packets before the ACK from User Agent A is received.
The INVITE/200 OK completes the transaction (the ACK is not part of the same transaction for a success class response).
User Agent A
User Agent B

76. SIP Call Setup Scenario
DNS Server
Location Server
14. ACK is sent by A to confirm setup call bypassing proxies.
Media session begins between A and B!
Ringing
Outbound Proxy Server
Inbound Proxy Server OK
Contact: B
SDP B
Ringing OK
Contact: B
SDP B OK
Contact: B
SDP B
Ringing
14. ACK
In this example, neither proxy server inserts a Record-Route header field, so the ACK sent by User Agent B is sent to the Contact URI contained in the 200 OK sent by User Agent B, which bypasses the two proxies.
This ACK is a separate transaction, not related to the INVITE/200 OK transaction of the previous slide.
Media (RTP)
User Agent A
User Agent B

77. SIP Call Hold (re-INVITE)
DNS Server
Location Server
15. B places A on hold by sending a re-INVITE.
16. A accepts with a 200 OK.
17. B sends ACK to A.
No media between A and B.
Outbound Proxy Server
Inbound Proxy Server
15. INVITE
SDP a=sendonly
B decides to attempt to transfer A to another party, C. In preparation, B places A on “hold” by sending a re-INVITE (an INVITE sent within an existing dialog) in which the media stream is set to sendonly. (B also applies local mute, so no RTP packets are exchanged between A and B.) OK
SDP A
User Agent A
17. ACK
User Agent B

78. SIP Call Transfer Scenario
DNS Server
Location Server
18. B transfers A to C using REFER.
19. Transfer is accepted by A with 202 Accepted response.
20. Notification of trying transfer is sent to B in NOTIFY.
21. B sends 200 OK response to NOTIFY
Outbound Proxy Server
Inbound Proxy Server
18 REFER Refer-To:
B initiates the transfer by sending a REFER to A which receives a 202 Accepted response. This success-class response indicates that User Agent A has received the REFER and will attempt the transfer. However, the final outcome of the refer (success or failure) is not yet known.
User Agent B sends an initial NOTIFY indicating that it will be trying to send an INVITE to User Agent C, which receives a 200 OK response.
Accepted
20. NOTIFY <100 Trying>
User Agent A OK
User Agent B

79. SIP Call Transfer Scenario
DNS Server
Location Server
1. to 5. A sends new INVITE to C which routes through two Proxy Servers.
6. Location Server responds with the FQDN SIP URI of C’s SIP Phone.
7. Inbound Proxy Server forwards INVITE to C’s SIP Phone.
5. LS Query: C?
6. Response:
3. INVITE
Contact: A
Ref-By: B
SDP A
Outbound Proxy Server
Inbound Proxy Server
Trying
7. INVITE
Contact: A
Ref-By: B
SDP A
1. INVITE
Contact: A
Ref-By: B
SDP A
Trying
User Agent C
Acting upon the REFER, User Agent A generates an INVITE and sends it to the URI in the Refer-To header field in the REFER. A Referred-By header field contains B URI, telling C that A has been transferred by B.
User Agent A
User Agent B

80. SIP Call Transfer Scenario
DNS Server
Location Server
8. User Agent C alerts C and sends 180 Ringing response.
9. & Ringing is proxied back to A.
11. C accepts call and sends 200 OK response.
12. & OK is proxied back to A.
14. ACK is sent by A to confirm setup call.
Media session between A and C begins.
Ringing
Outbound Proxy Server
Inbound Proxy Server OK
Contact: C
SDP C OK
Contact: C
SDP C
Ringing OK
Contact: C
SDP C
Ringing
14. ACK
User Agent C begins alerting, sending 180 Ringing. C accepts the call and User Agent C sends a 200 OK. Again, no proxy Record-Routes, so the ACK is sent directly to C’s Contact URI.
User Agent C
Media (RTP)
User Agent A
User Agent B

81. SIP Call Transfer Scenario
DNS Server
Location Server
20. Notification of successful transfer is sent to B in NOTIFY.
21. B sends 200 OK response to NOTIFY
22. B hangs up by sending a BYE.
OK response to BYE is sent.
Outbound Proxy Server
Inbound Proxy Server
20. NOTIFY <200 OK>
User Agent A sends a NOTIFY to User Agent B informing him that the transfer was completed successfully. As a result, User Agent B disconnects with A by sending a BYE.
If the transfer had failed, User Agent B could have attempted another transfer by sending another REFER or could have taken A off hold and continued the media session. OK
22. BYE
User Agent A OK
User Agent B

82. SIP Security Nicolas FISCHBACH
Senior Manager, IP Engineering/Security - COLT Telecom -

83. Authorization
SIP uses standard HTTP Digest Authentication with minor revisions
Simple Challenge/Response scheme
REGISTER >
<- 407 Challenge + nonce
REGISTER + MD-5 hash (pw + nonce) ->
<- 200 OK
Password is never sent in the clear, just the MD-5 hash generated with the password and nonce
Defeats Man-in-the-middle attacks since source address can’t be spoofed or second REGISTER will never arrive
Required by many Internet Telephony Service Providers (ITSPs)
Service Provider supplies Username and password
SIP leverages Digest Authentication features to do this

84. TLS and sips:
Implementation of TLS is mandatory for proxies, redirect servers and registrars
The ;transport=tls URI parameter value is deprecated
A sips: URI scheme (otherwise identical to the sip: scheme) indicates that all hops between the requestor and the resource identified by the URI must be encrypted with TLS.
If the request is retargeted once the resource is reached, it must use secured transports.

85. S/MIME Provides end-to-end security of message body and/or headers.
Certificate identified by end user address
Public key can be transported in SIP
Entire message can be protected by “tunneling” the message in an S/MIME body
Header Fields
Header Fields
Body
Signature

86. Attacks IPhreakers Protocol implementations The human element
IP knowledge
Known weaknesses
Evolution 2600Hz -> voic /int’l GWs -> IP telephony
Internal or external threat ?
Targets: home user, enterprise, government, etc ?
Protocol implementations
PROTOS
The human element

87. Attacks : denial of service
Network
Protocol (SIP INVITE)
Systems / Applications
Phone
Availability (BC/DR)
Requires: power
Alternatives (Business Continuity/Disaster Recovery) ?
E911 (laws and technical aspect)
GSM
PSTN-to-GSM

88. Attacks : fraud Call-ID spoofing User rights takeover Effects
Fake authentication server
Effects
Access to voic
Value added numbers
Social engineering
Replay

89. Attacks: interception
“Who talks with who” (Network sniffing, Servers (SIP, CDR, etc)
LAN
Physical access to the LAN
ARP attacks
Unauthenticated devices (phones and servers)
Different layers (MAC address, user, physical port, etc)
Where to intercept ?
Where is the user located ?
Networks crossed ?
Lawful Intercept
CALEA
ETSI standard
Architecture and risks

90. Attacks : systems Attacks : phone Systems (S)IP phone
Mostly none is hardened by default
Worms, exploits, Trojan horses
Attacks : phone
(S)IP phone
Startup
DHCP, TFTP, etc.
Physical access
Hidden configuration tabs
TCP/IP stacks
Firmware/configuration
Trojan horse/rootkit

91. Defense Signaling: SIP Transport: Secure RTP (with MiKEY)
Secure SIP vs SS7 (physical security)
Transport: Secure RTP (with MiKEY)
Network: QoS [LLQ] (and rate-limit)
Firewall: application level filtering
Phone: signed firmware
Identification: TLS
Clients by the server
Servers by the client
3P: project, security processes and policies

92. B2BUA
Session border controllers are usually implemented as SIP Back-to-Back User Agents (B2BUA) that are placed between a SIP user agent and a SIP proxy.
The SBC then acts as the contact point for both the user agents and the proxy.
Thereby the SBC actually breaks the end-to-end behavior of SIP, which has led various people to deem the SBC as an evil incarnation of the old telecom way of thinking.
Regardless of this opposition, SBCs have become a central part of any SIP deployment.

93. B2BUA
The B2BUA is special combination of two other SIP components – the User Agent Client (UAC) and the User Agent Server (UAS). 
The UAC is a SIP entity that sends SIP messages and receives SIP responses and the UAS is a SIP entity that receives SIP messages and sends SIP responses. 
You often see applications that implement both UAC and UAS functionality. 
You may hear this referred to as a SIP User Agent Client Server (UACS)  A SIP phone is such a beast. 
It sends a SIP INVITE when it wants to make a call and it receives a SIP INVITE when being called.

96. B2BUA
A B2BUA is also the combination of a UAC and UAS, but unlike a SIP phone which can be thought of as a destination for SIP traffic, a B2BUA is part of the path from sender to receiver. 
For instance, a B2BUA might sit between two SIP phones in order to add value to the communications process.
A B2BUA is both a UAC and a UAS.  What makes it different from a UACS is that when the UAS half receives a SIP message it regenerates that message and passes it to its UAC side which sends the new message to the next hop.  This message regeneration is very important because it allows the B2BUA to perform a number of important tasks.

97. B2BUA A B2BUA provides the following functions:
Call management (billing, automatic call disconnection, call transfer, etc.)
Network interworking (perhaps with protocol adaptation)
Hiding of network internals (private addresses, network topology, etc.)
Often, B2BUAs are also implemented in media gateways to bridge the media streams for full control over the session.

98. Session Border Controller
A Session Border Controller is a device used in select VoIP networks to exert control over the signaling and usually also the media streams involved in setting up, conducting, and tearing down calls.
The SBC enforces security, quality of service and admission control mechanism over the VoIP sessions.

99. Session Border Controller
The Session Border Controller is often installed in a point of demarcation between one part of a network and another.
Most Session Border controllers will be installed between peering service provider networks, between the enterprise network and the service provider network, or between the service provider network and residential users.
A Session Border Controller is like a Firewall for VOIP. They are often configured as a SIP Back-To- Back User Agent.

101. What an SBC eliminates….
Among the threats that an SBC has been developed to help eliminate are the following:

102. Service theft and fraud
These attacks happen when a hacker (or organized group of hackers) accesses an inadequately secured VoIP system to route traffic across the network without paying for it.
Not only do the hackers use up network resources without paying for them, but also the enterprise or service provider often ends up paying for the unauthorized toll charges.

103. Spoofing
Spoofing attacks come into play when people deliberately modify or disguise their identities (for example, caller ID phone numbers) on the network. This threat may occur to intercept calls intended for another (legitimate) party or simply in order to confuse or annoy.

104. Denial-of-service (DoS)/Distributed denial-of-service (DDoS) attacks
DoS attacks and their bigger, badder brother DDoS attacks seek to flood a server or SBC with requests in order to take it out of commission. DoS attacks typically originate from a single point/user, while DDoS attacks can involve sometimes hundreds or even thousands of zombified computers (known collectively as a botnet, for robot network).

106. Acme Packet OS
Oracle Communications Session Border Controller is based on Acme Packet OS, which delivers comprehensive multiprotocol signaling, programmability, and control functions and features.

107. Oracle SBC
Oracle Communications Session Border Controller supports all commonly used IP signaling protocols including SIP, SIP-I, SIP-T, Diameter, H.323, MGCP, H.248, Message Session Relay Protocol (MSRP), and Real Time Streaming Protocol (RTSP), allowing service providers to extend services to the greatest number of endpoints, as well as services offered via interconnect borders.
Extensive signaling protocol Interworking Function (IWF) allows service providers to consolidate signaling traffic within their networks. This reduces the number of required network elements, simplifies management, and reduces capital and operating expenditures.

108. Oracle SBC
Oracle Communications Session Border Controller IWF also allows the integration of next-generation SIP with legacy networks and endpoints, maximizing service revenues.
Oracle Communications Session Border Controller implements a full back-to-back user agent (B2BUA) approach that divides each session flowing through Oracle Communications Session Border Controller into two discrete segments.
In this way, Oracle Communications Session Border Controller maintains session state with each endpoint simultaneously, empowering the application of a wide range of control functions over the end-to-end session without modification to either the behavior or configuration of either endpoint.

109. Oracle SBC
Oracle Communications Session Border Controller may be run as a Virtual Network Function (VNF).
The supported hypervisors include Oracle Virtual Machine (OVM), Kernel-Based Virtual Machine (KVM), and VMware.
As a VNF, Oracle Communications Session Border Controller may be deployed as a standalone instance or within an orchestrated Network Function Virtualization (NFV) environment, and offers the same level of security, interoperability, and reliability as it does on purpose-built platforms.
Instances of virtualized Oracle Communications Session Border Controllers may be clustered with their counterparts on purpose-built platforms, known as “hybrid clusters”, providing a way for their gradual introduction and for even greater deployment flexibility and network agility.